コラム ｜ AIツールで効率的に詳細設計書が作成できる？！
古いシステムの設計書再構築の必要性とは

システム設計書の役割とは？

システムの設計書は、システム運用や開発において欠かせない資料です。設計書はシステムの全体像を把握するための基本資料であり、以下のような役割を果たします。

• システムの全体像を把握

  設計書にはシステムの機能や構成、データフローなどが詳細に記載されています。これにより、システムの動作や各コンポーネントの役割を明確に理解することができます。

• 業務プロセスの改善

  システム設計書は業務プロセスに関連する重要な情報を含んでいます。これにより、業務の流れや要件定義を確認し、システムの改善点を見つける手助けになります。

• トラブルシューティングの支援

  問題が発生した際、設計書があればシステムの内部構造やデータフローを参照することで、原因を特定しやすくなります。

再構築の必要性が高まる理由

古いシステム設計書の再構築が必要とされる理由は以下の通りです：

• システムの進化と変化

  時間とともにシステムは進化し、新しい機能や技術が追加されます。これにより、古い設計書が現在のシステムの状態を正確に反映していない場合があります。再構築することで、最新のシステム状態を正確に記録することができます。

• 設計書の不完全性

  古い設計書は、情報が不完全であったり、更新が行われていないことがあります。新しい設計書を作成することで、より詳細で正確な情報が提供され、システムの理解が深まります。

• 技術の変化への対応

  技術の進化により、新しいツールや方法が導入されています。古い設計書が新しい技術に対応していない場合、設計書を再構築することで、最新技術の導入やシステムの最適化が進めやすくなります。

システム設計書の重要性

• ➀ 効率的なシステム運用

  明確な設計書があれば、システムの運用やトラブルシューティングがスムーズに行えます。

• ② 業務プロセスの最適化

  現在の業務プロセスに合わせた設計書を持つことで、業務の効率化が図れます。

• ③ システムの改善点発見

  新しい設計書を通じて、システムの改善点や更新点が明確になります。

古くなってしまったシステム設計書の再構築は、システムの安定運用と効率化に繋がる重要な作業です。次章では、設計書再構築の具体的なメリットとデメリットについて詳しく解説します。

基本設計書と詳細設計書と仕様書の違いとは？

システム開発において、設計書はプロジェクトの成功を左右する重要な文書です。しかし、設計書にはいくつかの種類があり、それぞれの役割と違いを理解することが不可欠です。ここでは、基本設計書、詳細設計書、仕様書の違いについて詳しく解説します。

システム運用における設計書の重要性

設計書は、システム開発の際に使用して終わりではなく、システムの運用や管理においても重要な役割を果たします。

• ＜運用のガイドライン＞

  設計書にはシステムの全体構成や各コンポーネントの役割が記載されているため、運用担当者がシステムを適切に管理するためのガイドラインとなります。長く使用するシステムになればなるほど運用担当者の変更も起こりうるでしょう。それでも変わらぬ運用をするために、共通のガイドラインが必要となります。

• ＜変更管理＞

  システムの運用中に変更が必要になった場合、設計書を参照することで変更の影響を評価し、適切な対応ができます。「ある部分を変更したら思わぬプログラムに影響が出た」というのは、開発者にとってよくある事であり、避けねばならぬことです。設計書がない場合は作業者が1つ1つ構造を紐解き検証をしてから変更する必要があり、大変非効率です。

• ＜ドキュメントの整備＞

  設計書が整備されていると、問題が発生した際にも問題の発生源を素早く特定し迅速に対応できるため、システムの安定運用が可能になります。整備されたドキュメントはトラブルシューティングで大いに役立ちます。

設計書、特に詳細設計書はシステムの開発から運用、トラブルシューティングまで幅広く活用される重要な文書です。次章では、設計書再構築のメリットとデメリットについて具体的に見ていきます。

設計書再構築のメリット

もちろん、設計書の再構築には多くのメリットがあります。下記のように、システム開発の効率化、詳細化、エラー削減などの効果が期待できます。

• 効率化

  最新の設計書を整備することで、システムの理解が深まり、開発者や運用者が効率的に作業を進めることができます。特に、新しいメンバーがプロジェクトに参加する際に、迅速に業務を理解するための重要な資料となります。

• 詳細化

  設計書を再構築することで、システムの細部に至るまでの情報が整備されます。これにより、システムの仕様や動作がより明確になり、開発や保守作業がしやすくなります。

• エラー削減

  設計書に記載された情報を元に、システムのテストやデバッグを行うことで、エラーを早期に発見・修正することが可能です。これにより、システムの品質向上が期待できます。

設計書の整備不足が引き起こすトラブル

前述したようなメリットは皆様も納得の上かと思いますが、その一方で設計書を整備し続けるのは簡単なことではありません。ここでは、設計書の整備不足が引き起こすシステム再構築の現場で起こりうる問題についてご紹介します。

2.「現行踏襲」のギャップ

再構築において「現行踏襲」という要求がしばしば発生しますが、これがユーザー企業とベンダ企業の間で認識の違いを生むことがあります。ユーザー側は「動作している現行システム」のそのままの再現を期待しますが、ベンダ側はそれを具体的に仕様として落とし込む必要があります。この際、ドキュメントやソースコードに記載された内容と実際に稼働しているシステムとの間に乖離が生じることがあります。

例えば、仕様変更時に関連する業務のドキュメント更新が漏れたり、障害対応時にソースコードの修正だけが行われてドキュメントが更新されなかったりするケースがあります。このような乖離が生じると、ユーザーとベンダの間での「現行通り」の認識にズレが生じ、トラブルの原因となります。

設計書再構築のデメリットと注意点

詳細設計書を現行システムと一致させる必要性についてお伝えしましたが、実際問題そんな簡単に再構築できないのが現実です。実際、再構築する上では下記の点に留意しなければなりません。

• 高コストと時間の投入

  設計書の再構築には、通常、多大な時間とコストがかかります。既存のシステムが複雑であるほど、設計書の再構築にはリソースを投入する必要があります。これにより、プロジェクト全体の予算が膨らんだり、他の業務に影響が出たりする可能性があります。また、再構築の過程で見落としがあった場合、後で追加のコストが発生するリスクも考慮する必要があります。

• 知識の継承とギャップの問題

  古いシステムの設計書を再構築する際、当時の設計者や開発者がすでに退職していることが多く、そのシステムに関する詳細な知識が失われている場合があります。これにより、再構築チームが過去の決定の背景や意図を理解するのが難しくなり、設計書の再構築において誤りが発生するリスクが高まります。

• ドキュメントの複雑化と冗長性

  設計書の再構築を行う際、システムの歴史的な変遷や複数のバージョンが存在する場合、それらをすべて網羅的に記載することは現実的ではなく、また混乱を招く可能性があります。結果として、ドキュメントが過度に複雑化し、冗長な内容が含まれることで、利用者が必要な情報を迅速に見つけにくくなる可能性があります。

＜現行システムの分析＞

• ➀ 機能の把握

  現行システムの全機能を洗い出し、それらがどのように実現されているかを明確にします。これには、ユーザーが日常的に使用する機能だけでなく、バックエンドプロセスや管理ツールも含まれます。

• ② ドキュメントと実際のシステムの比較

  既存の設計書や仕様書が、現在のシステムの実装とどれだけ一致しているかを確認します。この作業により、古いドキュメントが実際のシステムの動作と異なる場合に、それを補正するための情報が得られます。

• ③ パフォーマンスの評価

  現行システムのパフォーマンス要件が満たされているかを評価し、再構築後に同様のパフォーマンスを維持または向上させるための対策を検討します。

＜業務要件の明確化＞

• ➀ 新しい業務プロセスの反映

  業務要件が変更されている場合、新しい業務フローやプロセスを設計書に反映します。これは特に、業務プロセスがシステムにどのように影響するかを理解するために重要です。

• ② 利害関係者の要件調整

  利用部門や経営層などの利害関係者からの要件や期待を整理し、それらが現行システムのどの部分に影響を与えるかを確認します。特に、新しい機能やサービスの追加に伴う要件の確認が重要です。

• ③ コンプライアンスと規制対応

  新しい法規制や業界標準がある場合、それらがシステムに与える影響を考慮し、設計書に反映させます。これにはデータ保護規制やセキュリティ標準も含まれます。

＜ユーザーのフィードバック＞

• ➀ ユーザーインタビューとアンケート

  ユーザーからのフィードバックを収集し、日常的な操作やシステムに関する不満点、改善点を把握します。この情報は、システムの使いやすさや効率性を向上させるための重要なデータとなります。

• ② ユーザー要望の優先順位付け

  全てのフィードバックがすぐに対応可能なわけではないため、ユーザーの要望を優先順位付けします。これは、最も影響の大きい変更や修正を優先的に行うために役立ちます。

• ③ ベンチマーキング

  他社のシステムや業界標準と比較し、自社システムの強みと弱みを評価します。この評価に基づき、改善点を設計書に組み込みます。

＜ドキュメントと現行システムの乖離解消＞

• ➀ 現行システムの機能マッピング

  現行システムの各機能がどのように動作しているかを明確にし、それに対応する設計書やドキュメントを更新します。これにより、設計と実装のギャップを解消します。

• ② 一貫性の確保

  ドキュメントとシステムの実装に一貫性を持たせるためのプロセスを確立します。特に、設計書の変更管理とバージョン管理が重要です。

• ③ 定期的なレビューと更新

  設計書の内容が常に最新であることを確認するため、定期的なレビューと更新を行います。この作業は、システムが進化する中で設計書が取り残されないようにするために不可欠です。

これらのチェックポイントを徹底することで、設計書再構築の成功率を高め、システムの安定性と品質を確保することができます。

AIリバースエンジニアリングサービスの特徴

• 特長１：

  生成AIを活用するため、従来の手法と比較して低コスト・短期間でリバースエンジニアリング

• 特長２：

  高い技術のITエンジニアが生成AIの結果を検証。高精度のリバースエンジニアリング

• 特長３：

  対象システムの状態やお客様のご要望に柔軟に対応。ITエンジニアによるコンサルティング、運用保守サポート

サービスの詳細はこちらをご覧ください。ぜひ一度ご相談ください！