システム開発の難しさ その５（まとめ）
 顧客が説明した 要件 |
 プロジェクト リーダーの理解 |
 アナリストの設計 |
 プログラマの コード |
 営業の表現、約束 |
 プロジェクトの 書類 |
 実際の運用 |
 顧客への請求金額 |
 得られたサポート |
 顧客が本当に 必要だったもの |
どうすればよかったのか？
このように、「顧客が本当に必要だったもの」を実現するのは非常に難しいのです。
実際、この寓話が示す罠にハマって失敗したり、デスマーチに陥るプロジェクトは現在でも後を絶ちません。
システム開発の本質的な難しさは、関係者の意思疎通（コミュニケーション）にあるのです。
必ずしも、開発側の分析力や技術力の不足だけが原因ではありません。
それでは、どうすればよかったのでしょうか。
回答の一つとしては、「顧客が本当に必要なもの」をあらかじめしっかりと分析して顧客と合意すると共に、プロジェクト関係者の間でそれを共有すること、があげられるのではないでしょうか。
正しいゴールが設定され、共有されていれば、全ての関係者がそれに向かって作業すれば良いだけなのです。
しかし、現実には、その「正しいゴール」を見極めるのが最も難題だったりします。
特に、予見可能性の低いビジネス分野においては、全関係者が一丸となって「誤ったゴール」に向けて邁進する、という羽目になる可能性は高いのです。
また、過去の開発・運用経験や他者の成功事例に引きずられて、現在解決すべき独自の問題を（無意識に）それらに無理やり当てはめて解決を図ろうとする恐れもあります。
このようなことを避けるために、2010年代から「アジャイル開発」という手法が普及し、現在ではシステム開発の業界標準として確立されています。
「アジャイル開発」とは、スプリント（短期の反復サイクル）を通じて機能を段階的に完成させ、各段階で顧客からフィードバックを得て方向修正していくという開発手法です。スクラムやカンバンといった具体的な実装手法が確立されており、開発チームと顧客の間で継続的に対話することで、「顧客が必要としないシステム」を作ってしまうリスクを大幅に減らしていくのです。
現在では、CI/CD（継続的統合・継続的デリバリー）とDevOps文化により、開発からクラウドインフラストラクチャ上の本番運用までを統一された環境で管理できるようになっています。Kubernetesなどのコンテナオーケストレーション技術やInfrastructure as Code により、より頻繁に、より安全に新機能をリリースできるようになりました。さらにユーザーテストやA/Bテスト、ログ・メトリクス・トレースなどの可観測性（Observability）を組み込むことで、実際のユーザー行動とシステム挙動に基づいた改善が可能になり、「本当に必要な機能」をデータドリブンに判断できるようになってきました。
また、リモート・分散開発の普及により、チーム内のコミュニケーションをいっそう重視する必要が増してきました。ポストモーテム文化やインシデント管理の導入により、失敗から学び、継続的に改善していく姿勢がより重要になっています。加えて、生成AIの登場により、開発プロセスの自動化やコード品質向上の新たな可能性が広がっています。
しかし、いかに優れた開発手法を採用し、最新のツールやテクノロジーを導入しても、基本原則は変わりません。開発チーム、顧客、経営層、そしてユーザーが一体となって、「本当に解決すべき問題は何か」「本当に必要な価値とは何か」を常に問い直し、定期的かつ心からのコミュニケーションを取ることが最も重要なのです。
アジャイル開発、DevOps、SRE（Site Reliability Engineering）、クラウドネイティブ設計などについては、詳しく解説している書籍やオンラインコース、学習プラットフォームが豊富に提供されていますので、時間があれば学んでみてください。
ITエンジニアのキャリアアップを検討しているなら
システム開発の難しさ その５（まとめ） 関連ページ
PR
