昨日の「隠蔽体質が動かないコンピュータ経験を生かさない（上）」に続き，システムに関連する自らの失敗体験を，その後のシステム開発プロジェクトに教訓として生かしているかどうか，あるいはどう生かすべきかについて，読者の皆さんからいただいたご意見を基に考えたいと思います。
大胆なご提案ですが，拙速でも動かすという教訓もありました。
巧遅より拙速。ユーザーは実際に動く物を見る(触る)まで自分の事として考えない。とにかく動くものをつくって意見を募り修正していく。この方が，会議が踊って何も決まらないまま時間が過ぎるより100倍マシ。
要件定義などに時間がかかったため，一部のユーザー部門が独断で業務をスタートさせてしまい，開発中のものとの擦り合わせに工数がかかってしまった。結局，運用が始まってからも擦り合わせが手間で，業務改善にならなかった。
ご指摘のように、「会議が踊って何も決まらない」状況は、プロジェクトの大敵だと思います。とにかく動くものをつくって後から修正のきくシステムであれば、まず動かすという手段も有効かもしれません。
正確に見積もりしてないプロジェクトも多い
プロジェクトが迷走する大きな要因に仕様変更があります。仕様変更についての教訓もいただきました。
仕様変更によるシステムへの影響力と，どこまでの仕様変更なら開発に組み込めるかをユーザーに分かってもらうための説明が必要となる。仕様変更を行わない方向で対処する場合，ユーザーにきちんと理解してもらわないことには，永遠にシステムを稼働できない（場合によっては訴訟問題にまで拡大する可能性もある）。
詳細設計フェーズで要件定義の変更が多発したため，要件定義からやり直しとなった。1年半たった今も，要件定義作成中。
ご指摘のようにすべての要望を受け入れ，その度に仕様を変更していては，システムは完成しません。以前，動かないコンピュータ・フォーラムで「Noと言えるインテグレータ」というテーマを取り上げたことがあります。インテグレータが，いかにNoというべきかを含めて対処すべき事態があることは否定できません。
仕様変更に関連する教訓については以下のようなご意見もあります。やはり契約は重要です。追加開発とそれにまつわる費用の問題だけでなく，プログラムの著作権の扱いもトラブルの種になることがあります。
・見積もりを提出する際に安易な妥協はしない。
・仕様変更が頻繁に発生することが予想される場合には契約形態を変更することを考える。
ベンダーと顧客との間で要件が固まらないため詳細設計・製造を進めることができずにいた。大まかな仕様を基に，プログラムを作成したが結局は一から作り直すこととなった。
見積もりも重要なテーマです。10月17日号の日経コンピュータ特集「その後の動かないコンピュータ」では，専門家による座談会を開き，動かないコンピュータが発生する原因について語ってもらいました。この記事の中で，ある専門家の方は，日本のIT業界における見積もり力のなさをはっきりと指摘されています。システムの開発規模をどう正確に見積もっていくかは，真剣に検討すべき課題だと思います。もう一つ、見積もりについて触れたご意見を紹介します。
・得た教訓
1.プロジェクトマネジメントの重要性
2.当初から見えていたリスクは常に監視すべき
3.継続的に見積もり精度の向上を目指す
システム稼動時期を当初予定より1年半遅らせる結果となった。
過去の事例の分析を続けることでしか、見積もり精度を向上させるのは難しいでしょう。継続的な努力が見積もりの精度を向上させる一番効率的な道かもしれません。
プロジェクトの進捗も一筋縄ではない
プロジェクトの進め方全般にかかわる教訓もいくつもいただきました。
・進捗管理についてベンダー任せにしない。
・ベンダーの言葉を鵜呑みにしない。
・開発スケジュールに遅れが出た場合は何らかの対応策を必ず実施する。
・一人だけ頑張っても限界がある。
・仕様変更が発生したら間違いなく工数は増える（何らかの対策を打たなければ必然的に遅れが発生する）。
・製作・テスト段階で検知した設計の不備対応は，できるだけその場しのぎにしない（システム全体に及ぶ基本的な設計ミスの場合，大幅な工数増加となる可能性が高いため，なるべく工数のかからない応急処置的対応となりやすい）。
・設計ではデータの修正・取消機能について気を付ける（要件定義は，正規データで，処理が上から下まで問題なく進むことを前提に記述されている場合が多く，各処理フェーズで問題があった場合の対応については，設計段階で気が付く場合が多い）。
汎用機のシステム開発案件で，開発の一部を外注に委託した。開発作業が遅れているのを知りつつ，外注先SEの言葉を信じて，本番稼働に向け総合テストを実施したが，予想通り不完全な状況だった。徹夜で不備に対応していったが，間に合わず，本番稼働日の早朝に本番稼働の延期を決定せざるを得ない状況となった。
プロジェクトの状況を把握する，ベンダーに依存しない，実施するのは難しいかもしれませんが，システム開発プロジェクトを進めようというユーザーにとって，いずれも必須の能力だと思います。もし，こういった力がなければ以下のような状況になりかねません。逆説的な表現のご意見ですが，参考になる部分も多いのではないでしょうか。
業者とユーザーの知識と認識のギャップ。現場の無知と意固地。システム部門の調整能力の欠如。それからはシステムの大幅な改訂には二の足を踏み使いづらいシステムをいじっている状況
生産管理システムが，現場の頻繁な計画変更に追随できず使われないままになって，Excelなどで手計算している。
では，どのような力が必要なのでしょうか。以下のご意見はその回答の一つだと思います。
・プロジェクトによって欠陥のあるプロセスは異なるが，「やるべきことをやっていない」ということに尽きる。
・顧客に力（特にマネジメント力）がないとプロジェクトはうまくいかない。力のない顧客に限って，丸投げしてしまう。
巨大な開発プロジェクトが最終段階で品質要求を満たしていないことが発覚し，いく度となくその応援に借り出された。
もちろん，一夕一朝にマネジメント力を高めることはできません。以下のご意見にあるように，日ごろからPM教育を充実させ，体制を整えてプロジェクトに臨むべきです。
社内PMOの設置，PM教育の充実。大工さんだけががんばっても，住みやすい家はできない。住む者（ユーザー）が考える（考えさせる）ことなしに，ユーザーが満足できるものはつくれません。
完成の大幅な遅延
完成させる意義を見失うな
マルチベンダー化の進展によって，ソフトやハードのブラックボックス化が進んでいます。メーカーの製品を信頼しすぎると思わぬしっぺ返しをくうことがあります。以下の教訓は，この事実に示したものです。
市販品を使ったインフラ構築では，設計段階からベンダーの協力を得て，とことん検証し，できない要件があれば案を作成し，顧客に早い段階から判断してもらう。
システムのインフラ構築において，選定したハードと市販のソフトをインストールしたところ，設計した機能を実現できないことが判明した。
最後に，あるユーザーの方からのご意見をご紹介します。
システムは，完成させる意義を見失った時に「動かなく」なる。何のために構築するのかを見つめ，極めて現実的な判断をすることが求められる。
カットオーバーの複数回の延期
このご意見はトラブルの渦中にある方に向けられたものでしょうか。日経コンピュータの特集「その後の動かないコンピュータ」でも触れたのですが一度，トラブルに陥ったプロジェクトを当初考えていた状態で完成させるのはほぼ不可能です。「極めて現実的な判断をする」という言葉に重みを感じます。
なお，動かないコンピュータ・フォーラムの今後のテーマ，あるいは動かないコンピュータについてのご意見や情報がおありの方は，日経コンピュータ編集部の専用フォームあるいは，専用のメール・アドレス（ugokanai@nikkeibp.co.jp）宛てにご連絡いただければ幸いです。今後の参考にさせていただきます。これまでに議論したテーマはバックナンバーでご覧になれます。
