システム開発の難しさ その３
 顧客が説明した 要件 |
 プロジェクト リーダーの理解 |
 アナリストの設計 |
 プログラマの コード |
 営業の表現、約束 |
 プロジェクトの 書類 |
 実際の運用 |
 顧客への請求金額 |
 得られたサポート |
 顧客が本当に 必要だったもの |
プロジェクトの書類
ブランコの開発に関する記録が何も残っていません。何も残ってないのですが、影や痕跡だけはある、という状態です。
振り向けば開発に関するドキュメントの類が残っておらず、ファイルサーバーを探しても影のようにつかみどころがないメモや議事録しか残っていないのです。
仕様がコロコロと変わるため記録しても意味がないのかもしれません。しかも顧客から次々とやってくる追加要求を安請け合いしたため、情報量的には膨らんでいるかもしれません。
また開発スタッフも、仕様書を丁寧に書いたところで開発成果に直接繋がらないうえ、上司からもそんな仕事は評価されない（中身も見てもらえない）ため誰も書きたがらないのでしょうか。
後々、開発メンバーが交代したりするとシステム保守・改良がやり難くなる一因にもなるはずですが、そんな余裕すらないのでしょう。
仮に設計段階において綿密に仕様が検討されドキュメントがしっかり整備されていたとしても、当初の設計では想定していなかった振る舞いがシステムの動作試験の段階になってから発見されることがあります。
そうなると、システムは再設計を余儀なくされコードも書き直されていくため、オリジナルの設計書の内容は覆され陳腐化してしまうのです。
「設計書は後回し。まずは動くプログラムを作る。それから書き起こす。しかもシステムが本番を迎えた後に。」ということが、デスマーチを迎えた開発現場ではよく見られる光景です。
実際の運用
ロープ一本だけが枝からぶら下がっています。とりあえず、枝からぶら下がって揺られて遊ぶことはできます。
かろうじて顧客の要望を叶えている状態です。
あるいは顧客の説明が朝令暮改で、現場にはここまで単純化された要求しか残らなかったのでしょうか。
当初の設計案をすべて盛り込むには納期に間に合わないと判断され、予定よりも大幅に縮小された機能だけを載せて納期に間に合わせて顧客へ渡ってしまいました。
約束されたシステムとは程遠い不完全で使い勝手の悪い状態で顧客は運用を強いられることとなります。
顧客の日常業務がこのシステムに依存・維持させるために、システム導入前以上に手間とコストかかるものにならないか心配されます。
この時点では、一体何を目的としてシステム導入を検討していたのかを覚えている人も少なくなっていると推察されます。
顧客への請求金額
ジェットコースターらしき遊具が設置されています。
ブランコの設置という顧客の要望に対し、紐を１本ぶら下げたものを納品しただけなのに、ジェットコースターを建造できるレベルの法外な額を請求しようということでしょうか。
もしくは、「高速で乱高下する」ジェットコースターを請求金額に例えて、「追加料金の連続で、当初の見積額からうなぎ登りに上昇」→「運用開始した顧客に実態がバレて叩かれだした途端、運用自体は何も変えてないのに急激に安くなる」という手の平返しを皮肉っているのかもしれません。
何にせよ「顧客の要件」「営業の約束」「実際の運用」といったこれまでの要素とは隔絶した額を要求しているのは間違いないようです。
特に５番目の「営業の約束」をも上回る額を請求しているようにすら見えます。
システム開発の難しさ その３ 関連ページ
PR
