未経験者歓迎！知識ゼロからシステムエンジニアを目指す

「システム開発の難しさ　その２」からの続き

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

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

プロジェクトの書類

システム開発に関する記録・ドキュメント資産が形として残っていません。書類は存在するはずなのに、共有フォルダやSlack、Teamsといったコミュニケーションツール内を探してみても、影や痕跡だけしかないという状態です。

プロジェクトを振り返ると、設計書や要件定義書といった開発ドキュメント資産が体系的に整備されておらず、GitHub、Jira、Confluence、Notionといった管理ツール上にも、つかみどころのないメモや会議録の断片だけが散在しているのです。

仕様がアジャイル開発のスプリント実行中に次々と変更されるため、ドキュメントを丁寧に書いても追いつかないのかもしれません。クラウドネイティブ化やマイクロサービス化に伴い、従来のウォーターフォール型の仕様書に頼ることが難しくなった面もあります。それに加えて顧客から追加機能をたびたびリクエストされているため、情報量的には膨れ上がっています。

さらに開発スタッフは、テスト駆動開発（TDD）や振る舞い駆動開発（BDD）を実践する方が、従来の紙やドキュメント管理ツールでの仕様書を書くよりも納期短縮につながると判断し、自動テストケースを要件の定義として機能させようとしています。一部のチームは、コード自体をドキュメントとし、AIによる自動コメント生成やAPIドキュメント自動抽出を活用する例も増えています。ただし上司や顧客からも、一般的な仕様書の整備に関しては強く求められていないため、誰も本腰を入れて書こうとしないのでしょう。

後々、開発メンバーが交代したり、プロジェクト体制が再編成されると、システム保守・改良が一気に難しくなる一因になるはずですが、デリバリー急迫の中ではそんな余裕はありません。

たとえ設計フェーズで綿密に要件が検討され、Confluenceなどのドキュメント管理ツールで文書が整備されていたとしても、実装フェーズやテスト工程において、当初設計では想定していなかった動作や例外ケースが次々と発見されることがあります。

そうなると、システムは再設計を余儀なくされ、コードもGitでの修正が重ねられていくため、オリジナルの設計ドキュメント内容は覆され陳腐化してしまうのです。Infrastructure as Code（IaC）でインフラ構成を管理していても、ドキュメント管理の煩雑さは解決しないのが実情です。

「設計ドキュメントは後付けとする。まずはMVP（最小限の実装）を動かす。その後、リリース前に整備し直す。本番環境でのカナリアリリースやA/Bテストの結果を見てから正式化する。」というプラクティスが、2026年の迅速な開発現場ではよく見られる光景です。

実際の運用

ロープ一本だけが枝からぶら下がっています。とりあえず、枝からぶら下がって揺られて遊ぶことはできます。
かろうじて顧客の基本的な要望は満たしている状態です。
あるいは顧客の要件説明が何度も変更されるうち、現場には最小限の要求だけが残ってしまったのでしょうか。

当初の設計案で予定していた全機能を実装するには、納期までのリードタイムでは間に合わないと判断されました。DevOpsのCI/CDパイプラインを導入していても、スコープ管理が破綻すれば意味がありません。そのため、予定していた機能の大幅なカットが実施され、MVP（最小限の実装可能製品）のみが納期に合わせてリリースされてしまったのです。

当初約束されたシステムとは大きく異なる、不完全で使い勝手の悪い状態で顧客は運用を開始することになります。

顧客の日常業務がこのシステムに依存するようになる一方で、当初期待していた業務自動化やコスト削減が実現せず、むしろシステム導入前以上に手作業と運用コストがかかるものになってしまいます。

この時点で、そもそも何を目的としてシステム導入を検討していたのか、その本来の価値を覚えている関係者もほとんど残っていないと推察されます。クラウドベースのリモートチーム化に伴い、プロジェクト初期段階の顧客との共通認識も薄れやすくなっています。

顧客への請求金額

ジェットコースターらしき遊具が設置されています。
ブランコの設置という顧客の要望に対し、紐を１本ぶら下げたシステムを納品しただけなのに、ジェットコースター並みの莫大な開発費を請求しようということでしょうか。

もしくは、「高速で乱高下する」ジェットコースターに請求金額の増減を例えて、「スコープ管理が破綻し、追加機能リクエストの度に請求金額が急騰」→「本番運用を始めた顧客に実装内容との乖離がバレて、ステークホルダーから強く異議を唱えられる」→「運用内容は何も変わっていないのに、急転して契約金額を減額する」という不可思議な価格変動を皮肉っているのかもしれません。

スコープのゆらぎに伴って請求金額が変動するのは、要件定義の曖昧さとプロジェクト管理の脆弱さの表れです。DevOpsやアジャイル導入企業でさえ、見積もり精度の問題には頭を悩ませています。

いずれにせよ「顧客の要件」「営業の約束」「実際の運用」といった前段階の要素とはかけ離れた額を要求しているのは確実です。

特に５番目の「営業が約束した価値」さえをも上回る額を請求しているように見えます。

システム開発の難しさ　その３ 関連ページ

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

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

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

システム開発の難しさ　その５（まとめ）

メキシコ人の漁師とアメリカ人旅行者の話

銀行強盗と既得権益集団

いつまで政党政治を続けるのか

不正する隙を与えないシステムの構築

ハンディキャップを持つ人のために

ブラック企業に入社してしまった場合