システム開発の難しさ　その１

トップページ＞ SE雑記帳＞システム開発の難しさ　その１

システム開発の難しさ　その１

※ 本ページにはアフィリエイト広告（PR）が含まれます。

顧客が説明した要件	プロジェクトリーダーの理解	アナリストの設計	プログラマのコード	営業の表現、約束
プロジェクトの書類	実際の運用	顧客への請求金額	得られたサポート	顧客が本当に必要だったもの

出典：ニコニコ動画　顧客が本当に必要だったもの

これはITビジネスにおける複雑なシステム開発プロジェクトの実態を風刺した絵です。2026年のクラウドファースト時代、生成AIの急速な導入、マイクロサービスやコンテナオーケストレーションの普及にもかかわらず、この問題は依然として深刻です。

情報システム開発における要求仕様策定の困難さを示す代表的事例として、アジャイル開発やスクラム手法が業界標準となった現在でも、様々なプロジェクト管理の実務ガイドや学術論文で引き続き引用されています。

要点をまとめると、発注側の顧客が期待したシステムが完成しなかった原因は、開発側の技術的判断の誤りやアーキテクチャ設計の欠陥だと思われがちですが、実は「最初の段階で顧客自身が自分のビジネス課題を正確に説明できていなかった」ことが根本原因であることを示しています。

つまり、顧客自身も自分たちが本当に必要とするビジネス価値や解決すべき経営課題を、開発チームに対して的確に伝えることができていなかったのです。
さらに言えば、開発側もそうした齟齬に早期に気づかず、十分に指摘することなく、プロトタイピング、ユーザーインタビュー、ペルソナ分析、ワイヤーフレーム検証といった手段を活用して問題を明確化していませんでした。

アジャイル開発、スクラム、リーンUX、DDD（ドメイン駆動設計）、そしてAIアシストによる仕様レビューなどの最新手法が普及している2026年であっても、本質的な課題は変わっていません。Kubernetes、Docker、サーバーレスといった最先端技術スタックを採用しても、各メンバーが自分の解釈だけで進めてしまう悪習は今なお存在するのです。

それでは、それぞれの絵が象徴するところを詳しく解説していきましょう。

顧客が説明した要件

「顧客が説明した要件」の内容は以下の通りです。

①　それは木の枝に2本のロープでつながれている。
②　2本のロープの下には、腰かけるためのものがある。

実装仕様が曖昧で、機能要件も過剰になっているブランコの製造依頼となっています。
この時点で既に、完成形に対するビジョンが共有されていません。

インターネットで見かけた類似サービスを参考に、素人考えで仕様を提案しているレベルです。もちろん、発注者はお金を払う立場だから、という自信を持って要件を示してきています。

もちろん、顧客がお金を払う立場なので、システム開発を請け負う側も率直な指摘をしづらい状況が生じます。2026年ではクラウドAIやGPTを活用した自動化が常識化していますが、依然として顧客と開発者の間には技術知識の大きなギャップが存在しています。

開発側も対価を受けてシステムを構築するプロフェッショナルなので、顧客のニーズを最大限汲む必要があるのですが、このような曖昧な表現だけで顧客の真の意図を読み取ることは、どんなベテランエンジニアでも困難です。

ここで最も重要なのは、「本当に解決する必要があるビジネス問題の本質を何度も確認すること」です。顧客のビジネスニーズ把握、現状の業務プロセス分析、実現すべき将来状態の可視化などが不足していると、その後どんなに優れたコード品質やマイクロサービスアーキテクチャを実現しても、全く意味のないものになってしまいます。

他の人が勝手に提案してきた「解決策」のようなものに、検証なく飛びついてはいけません。要件定義フェーズにこそ、十分な時間をかけて対話を重ね、相互理解を深める投資が必要です。

また、最終的に「顧客が本当に必要だったもの」を見れば明らかですが、顧客自身が自分たちのニーズを相手に伝わるように表現する力がないと、いくら優秀なシステムエンジニアやソリューションアーキテクトが携わっていても、現場では正確に伝わらず、このように誤解されてしまいます。

完成品に対して明確なビジョンを持ち、それを関係者全員で共有できるように「視覚的・言語的に翻訳すること」が不可欠です。ワイヤーフレーム、ユースケース図、プロトタイプ、マインドマップ、ジャーニーマップなど、複数の手段を組み合わせたコミュニケーションは、現代開発においても極めて有効です。

要件記述が曖昧だと、その後の各工程で個々のチームメンバーが独自の解釈を補足しながら作業を進めることになり、結果として誰も全体像を説明できないプロダクトが完成してしまいます。DevOpsやCI/CDパイプラインが導入されている環境では、曖昧な要件定義がむしろ逆効果になる危険性が高くなります。不正確な要件のまま高速デプロイされると、本番環境での障害や顧客満足度の低下が加速するからです。

プロジェクトリーダーの理解

「木にぶら下がるブランコを納品する」という顧客の要求は、プロジェクトリーダーによってなんとか解釈されました。
さらに、顧客の提案における不必要な要素（過剰な3枚の板）を技術の専門家として排除することができています。
その結果、木の枝への荷重分散を考慮したリーダーが導き出した解決案がこの絵です。

木の枝の負荷軽減には成功しているものの、そもそも木の幹が邪魔になって、ブランコが機能しません。スケーラブルなマイクロサービスアーキテクチャやKubernetesでのコンテナオーケストレーション、クラウドネイティブ設計といった知識を持つメンターが側にいれば、このような誤りを検証できるはずです。しかしそうした体制が構築されていないようです。

プロジェクトリーダーは、顧客に最も近い位置で開発チームに必要な情報を取り入れ、顧客のビジネス目標と技術実装を調整し、開発チーム全体に完成品の共通イメージを浸透させるべき立場であるはずです。ところが既にこの段階で、顧客との認識にズレが生じてしまっています。

さらに、実際に動作するかどうかが不確実なシステム設計が構想されているのに、スケーラビリティ、セキュリティ、保守性、運用効率を含めた総合的な設計レビューや検証プロセスを持っていないのでしょう。2026年ではDXの重要性が高まり、レガシーシステムの最適化やクラウド移行が急務になっていますが、この段階での意思疎通不全が原因で失敗するプロジェクトは多いのです。

同情的に見れば、設計検証に必要な予算や時間が確保されていない制約があるのかもしれません。しかし別の観点では、プロジェクトリーダーの過信や自信過剰とも解釈できます。スプリント計画やレトロスペクティブといったアジャイルプラクティスを導入している場合でも、リーダーの認識ズレがあれば、チーム全体の方向性も同じようにズレていきます。特にAIやLLMを開発に組み込む際は、その判断の誤りが増幅される可能性があります。