システム開発の難しさ その２
 顧客が説明した 要件 |
 プロジェクト リーダーの理解 |
 アナリストの設計 |
 プログラマの コード |
 営業の表現、約束 |
 プロジェクトの 書類 |
 実際の運用 |
 顧客への請求金額 |
 得られたサポート |
 顧客が本当に 必要だったもの |
アナリストの設計
アナリストがプロジェクトリーダーの構想を分析した結果、このままではブランコが動かないことに気づきました。
そのため、ブランコがなんとか揺れることができるように改良されています。
しかし、支えの棒が脆弱ですぐに崩壊しそうです。
プロジェクトリーダーの意図はとりあえず反映してみたものの、そもそも当初の見通しが間違っているため、顧客の要求と両立させるために不自然で歪んだシステムが設計されてしまいました。
妥当性を検証し、上流工程に差し戻してやり直しを要求することは立場として難しいのでしょうか。
あるいは、アナリストとして腕の見せ所と張り切った結果でしょうか。
設計段階で流行技術を無批判に導入したがる設計者が多いのも問題です。2026年現在、クラウドネイティブ化、生成AIやLLMの組み込み、ブロックチェーン統合、ビッグデータ分析といった先進技術が注目を集めていますが、これらが本当に必要なのかを検証せずに導入してしまうケースは多いのです。
マイクロサービスアーキテクチャやサーバーレス、IaC（Infrastructure as Code）やGitOpsといった現代的な手法も、形式的に導入されるだけでは、かえってシステムの複雑性と運用コストを増すだけです。
セキュリティ対応（ゼロトラスト、多要素認証、認可管理の強化）も重要ですが、過度に複雑な実装がなされることもあります。
本来の要件を見失い、テクノロジーバズに乗せられることで、スケジュール遅延、予算超過、メンテナンス性の低下につながるのです。
プログラマのコード
木の幹にブランコが繋がれている状態です。
第三者の目にはかなり異様な光景に映りますが、「木と板を２本の紐でつなぐように」としか説明されなかった薄給のプログラマが形だけ作ってみたものです。
2026年現在でも、古い開発手法を続けている企業は存在します。プロセスの自動化が不十分で、テスト駆動開発（TDD）やペアプログラミングといったプラクティスが導入されていない職場では、バグが増殖しやすくなります。GitHub、GitLab、Jiraといった開発ツール、GitHub ActionsやGitLab CI/CDなどのパイプラインは一般的になってきましたが、形式的に導入しているだけで、コード品質管理が疎かになっている現場も多いのです。
あるいは、どの幹に結んでも結局は折れるので、要件仕様を満たそうとするとこうするしかない、という現場の苦悩でしょうか。
これはブランコの設置なので、見た目はまだ分かりやすいですが、プログラマの労働の成果であるプログラムのコード、アーキテクチャ、セキュリティを第三者が手早く評価したり欠陥を見抜くのは容易ではありません。
コードレビュー、自動テスト、静的解析（SonarQube、ESLint等）といった品質確保の仕組みが不十分な現場では、セキュリティ脆弱性も増殖しやすくなります。
設計者の意図は正しくプログラマに伝わっておらず、Slack、Mattermost、Confluenceなどのコミュニケーションツールを導入していても、実質的な意思疎通が成立せず、まともに動かないシステムが生まれゆく状況を示しています。
木とブランコが「とりあえず繋がっている」ので、ユーザー受け入れテスト（UAT）では「表面上は間違ってはいない」という説明はできます。
プログラマが顧客の本当の要求を知る術もないため、ここでも成果物の妥当性を検証する機会はないようです。
見かけ上の成果（コミット数やリリース数、ベロシティ）は増えていき、進捗遅れもなく開発が順調に進んでるように見えますが、後々メンテナンスが困難となったり、本番環境で障害を起こすプログラムが大半を占めるのです。
営業の表現、約束
立派な肘掛け椅子を搭載した無駄に豪華なブランコです。
第三者の目にはかなり異様な光景に映りますが、売り込みに熱心な営業担当者はそんなことは気にしません。
まさに絵に描いた餅です。
システムの本質を満たしていない上に、過剰な機能の搭載を売り込んでしまう営業。
生成AI機能の搭載、データ分析・機械学習の統合、リアルタイムデータ処理、ブロックチェーン連携など、一見最先端に見える機能を無理矢理組み込んでしまいます。
製品はまだできていないので、何とでも言えるのです。
また、顧客の要望が既存の枯れた技術で十分に実現できる可能性に気づいていても、営業側から顧客に言い出すことはありません。
顧客側から「もっと安く代替できるのでは？」と指摘されても「でもこの生成AI機能の方がビジネス競争力が高いですよね。」「クラウドネイティブなマイクロサービス化なら運用コストも削減できます。」「セキュリティ対応も強化できます。」と誘導していくのです。
なるべく高価で大量に機能を盛り込んだ豪華なプランを、さもお得であるかのように見せかけて契約を取るのが彼らの仕事だからです。
この手法は顧客が技術的なことを理解できない場合はなおさら有効です。
ところで、営業担当者たちは実際の開発現場とどんな交流があるのでしょうか。
現実には交流はほとんどありません。
というより、営業担当者本人が技術的なことを全く理解できてない場合も多く、クラウドアーキテクチャ、マイクロサービス、DevOps、SRE（Site Reliability Engineering）といった基本的な知識すらないこともあります。
そのため、「こんな凄い生成AI機能を組み込んだシステムがたったこれだけの工数でできてしまうんです！」
「クラウドネイティブ化とコンテナ化ですか？任せてください！簡単なことですよ！！」
「機械学習による予測分析も搭載できちゃいます」となんの根拠もなく豪語してしまうのです。
競合他社がいる場合、出来ないことを知っていても、開発側に丸投げすることすらあります。
とりあえず、案件を取りさえすれば自分の手柄になるのだから、後のことは知ったことはないのです。
当然、開発現場には「営業が約束した豪華なAIシステムを、当初の予算と納期で作れ」と要求します。
地獄の始まりです。
もちろん営業側は満足した顔でさっさと定時で帰ってしまうのです。
ITエンジニアのキャリアアップを検討しているなら
システム開発の難しさ その２ 関連ページ
PR
