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

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

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

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

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

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

得られたサポート

切り株だけが存在している状態です。あるいは、ブランコが設置されていた木が根本から切り倒されてしまい、支援体制が完全に崩壊した状態とも言えます。

「実際の運用」の局面において、顧客からの「ロープに腕だけでぶら下がるのは負担が大きいので、もっと利用しやすい形に改善してほしい」という改善要望に対して、開発・運用チームが場当たり的に対処した結果でしょう。

このように、システムの本来の機能や価値を根幹から損なうような不適切なサポート対応が実施されることは、現在でも珍しくありません。クラウドへのマイグレーション時の予期しないトラブル対応、AI・機械学習システム導入後の予測不能な問題への場当たり的な対処、また新しい基盤技術（Kubernetes、マイクロサービス、DevOps環境）への移行時の失敗も、すべてがこのパターンに該当しています。

あるいは、顧客が実際に受け取ったサポートの質・量・継続期間が、当初の約束よりも大幅に下回っていたことを示しているのかもしれません。さらに悪い場合は、「運用サポートの打ち切り」「システム自体の運用凍結・放置」という事態にまで至るケースも存在します。
こうした状況は、顧客の当初の要件、営業との約束、契約で謳った実装内容とは全く異なるものです。

そしてこれらに投じられた開発費用・運用コストは一切戻ってこないのです。

顧客が本当に必要だったもの

タイヤをぶら下げたシンプルなブランコです。

豪華で複雑な遊具ほどではありませんが、木にぶら下がって揺れて遊ぶという顧客の本質的な要求を十分に満たす機能を持った、実用的で堅牢な遊具が、顧客が本当に必要だったものです。

高級な材料を使った複雑なシステムと比べても、この実装は遥かに低コストで実現できます。さらに言えば、タイヤも新品である必要はなく、廃材を活用することすら可能です。シンプルでメンテナンスしやすく、機能要件を満たしながら不要な複雑性を排除した設計こそが、実務レベルで求められるアプローチなのです。

このような最適解は、顧客の視点だけでは見えていなかったり、あるいは開発側のビジョンが顧客に十分に伝わっていなかったために、検討対象から外れてしまうことがあります。さらに悪いケースでは、関係者全員がこのような解決策の存在に気付いていない可能性さえあるのです。

こうした理想的な実装形態に辿り着くためには、顧客と開発側が密にコミュニケーションを取り、互いの制約条件や考え方を理解した上で、到達すべき目標を一緒に定義していくことが不可欠です。

ただし、現実的な課題として、タイヤを使ったブランコ型の遊具（顧客が必要とする機能要件は網羅しながらも、複雑な技術スタックを必ずしも必要としないシンプルで保守性の高い実装）を、顧客が「これで十分、わが社の運用要件を満たし、将来の拡張も現実的に対応できる。導入に値する」ときちんと理解し、納得・受け入れてくれるかどうかという課題は残ります。

また、先ほどの9つのパターンすべてを平均的に考慮しても、この最適な解決策に到達しない可能性が高いことも事実です。
だからこそ、顧客も自分たちの理想像を一方的に説くのではなく、実装後の運用思想・保守体制・人員配置といった実務的な観点も併せて開発側と共有していくことが重要なのです。