規模で選ぶ開発アプローチの使い分け

大規模システム開発においては、ウォーターフォールモデルという開発手法が一般的です。この手法では、要件定義、基本設計、詳細設計といった各工程を順序立てて進め、各段階で詳細な設計書やドキュメントを作成します。これにより、開発チーム全体で目標とするシステムの姿を共有し、品質を担保することができます。特に、金融システムや公共システムなど、高い信頼性が求められるプロジェクトでは不可欠なアプローチとなっています。

一方、中小規模のシステム開発では、アジャイル開発と呼ばれる柔軟な手法が採用されることが増えています。アジャイルでは、必要最小限のドキュメントを作成し、早期にプログラミングに着手します。短いサイクルで開発と改善を繰り返すため、要件変更にも柔軟に対応できる利点があります。また、開発チームとステークホルダーが密接にコミュニケーションを取りながら進めることで、より実用的なシステムを効率的に構築できます。

どちらの手法を選択するかは、プロジェクトの規模、予算、時間的制約、要件の明確さ、セキュリティ要件など、様々な要因を考慮して判断する必要があります。

設計書の必要性と現実的な課題

建築業界では、詳細な設計図面なしでの建築は法的にも実務的にも不可能ですが、システム開発の世界では状況が異なります。特に中小規模のシステムでは、基本的な要件の概要さえあれば、開発に着手することが可能です。理想的には、詳細な設計書を作成し、要件を綿密に詰めてから開発を進めることで、後々のトラブルを未然に防ぐことができます。

しかし、現実には設計書の作成には多大な時間と労力が必要で、システムの実装と同等、あるいはそれ以上のコストがかかることもあります。また、設計段階で予見できなかった技術的制約や、開発過程での要件変更により、詳細な設計書が必ずしも最適な成果物につながらないケースも存在します。

そのため、中小規模のプロジェクトでは、必要最小限の設計ドキュメントを作成し、実装とフィードバックを繰り返しながら、徐々にシステムを成長させていく方法が採用されることが多くなっています。この approach は、限られたリソースの中で最大の効果を得るための現実的な選択として認識されています。

設計書の粒度とその背景にある要因

中小規模のシステム開発で設計書が簡素化される背景には、複数の要因が存在します。最も大きな要因は、発注側の予算制約です。多くの中小企業では、システム投資に割ける予算が限られており、詳細な設計書の作成にコストを割くことが困難です。建築業界では、建築基準法や消防法などの法規制により、必要な図面や書類が明確に定められています。

これにより、品質や安全性が一定水準で担保されています。一方、システム開発業界では、法的な規制が少なく、必要なドキュメントの種類や詳細度が標準化されていません。そのため、開発会社や個々のエンジニアの判断に委ねられ、品質にばらつきが生じやすい状況となっています。

また、発注側のITリテラシーの差も、設計書の質に影響を与えています。システム開発の経験が豊富な企業では詳細な設計書を要求しますが、そうでない企業では必要性を理解していない場合もあります。業界全体として、適切な設計書の基準を確立し、品質を標準化していくことが課題となっています。

ドキュメント管理の実態と課題

中小規模のシステム開発における設計書の問題は、その存在自体が危ぶまれる状況にまで及んでいます。小規模プロジェクトでは、限られた予算の中で機能の実装が優先され、ドキュメント作成が後回しにされる、あるいは完全に省略されるケースが少なくありません。

また、システムの運用開始後も問題は続きます。システム自体は日々の運用の中で更新や機能追加が行われていくにもかかわらず、設計書やドキュメント類は更新されないまま放置されることが多々あります。その結果、実際のシステムと設計書の内容が大きく乖離してしまい、ドキュメントとしての価値を失ってしまいます。さらに深刻な問題として、システム保守ベンダーの変更や組織の改編等により、設計書が紛失してしまうケースも報告されています。これらの状況は、システムの長期的な保守や改修を困難にし、結果として企業の技術的負債を増大させる要因となっています。

また、担当者の異動や退職時の引き継ぎも、適切なドキュメントがない状態では極めて困難です。この問題に対する解決策として、設計書のデジタル管理やクラウドでの一元管理、自動ドキュメント生成ツールの活用などが検討されていますが、まだ十分な効果を上げているとは言えない状況です。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われます。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかります。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がります。

つまり、非エンジニアが単純に開発費用を値切るとプログラミング以外の重要な情報を削っていくことになります。
設計書が属人的だったり粗末であったりすると、後の工程の解釈にブレが生じて、システム開発の全体的な時間が積算的に増えていくことになります。

どのようなシステムを作るのか、現在の状況や未来の理想など、システム開発を取り巻く環境を適切な粒度で分析することが、全体的な費用や工数を適正化する唯一の方法といえます。セカンドオピニオンは、複合的技術に経験豊富なアタラキシアDXにご依頼くださいませ。