できるだけ早期にユーザーを巻き込む

これまでのソフトウェア開発は、ユーザー要求を確認したら、あとは秘密のベールに隠れてコーディングとテストを進めるというものでした。どうせユーザーは、私たちがやっていることなんて理解していません。プロジェクトの終盤、マジシャンの魔法の布をさっと取り除けば、ユーザーは出来上がったもののすばらしさに「おおー」とか「わあ」とか感嘆の声を上げるはずです。ところが残念ながら、ほとんどの場合、そうではありません。「あぁ、君たちがよくやっていたのは知ってるよ。でも本当に望んでいたのはね……」と言うのです。

プロジェクトを成功させる秘訣は、何か見せられるものができたらすぐにユーザーを巻き込むことです。プロジェクト完了後に問題が見つかるよりも、開発の初期に問題が見つかる方が、はるかによいことだからです。

スケジュールが進むにつれ、変更のコストはどんどん高くなっていきます。さらに改善しようとプログラムを直して再びテストする時間も、まわりにある関連コードとのインテグレーションをテストする時間も、プロジェクトを大幅に遅らせます。また、変更があまりに大きすぎて、変更管理委員会（Change Control Board）の承認プロセスを通さなくてはならなくなると、時間もコストも危機にさらされます。

たとえ非常に些細な問題に対する実装上の判断であり、ソフトウェア開発者とプロジェクト・マネジャーにとっては完全に筋が通っていたとしても、ソフトウェアを実際に利用している現場では大変なことになっているかもしれません。

私は発注ソフトウェアの再設計に500 万ドルもかけた巨大な研修会社を知っています。これまでのシステムでは、アイテム番号が各製品に対応しており、ある論理的な方法で番号が付けられていました。例えば、4125 は学生用マニュアル、4225は学生練習用の付属ディスク、4325 は講師用マニュアル、4425 は販促用の講座概要といった具合にです。4x25 という一連のアイテムはすべて、同一画面で注文できるようになっていました。

世界140 か所にいる運営コーディネータは1 日に何度も同じ教材を発注するので、すぐにそのアイテム番号を覚えてしまいます。学生用マニュアルの番号を覚えると、調べなくてもすぐに他の関連するアイテムの番号も入力できるようになりました。おかげで彼らはすばやく注文することができました。

このソフトウェアを再設計するにあたり、担当したプロジェクトチームは、実際の現場で使われていた発注プロセスについて考慮するのを忘れてしまいました。新しい設計では、アイテム間の論理的な関係が失われてしまったのです。以前は4125 だった学生用マニュアルは6358 になりました。そして学生練習用の付属ディスクは8872 に、同じクラスの講師用マニュアルは3392 になりました。

ユーザーは新しいアイテム番号を調べないといけなくなり、また、以前の番号と発注システムのことを忘れなくてはなりませんでした。しかも、関連するアイテムは別のページになってしまいました。

運営コーディネータは、それはもう激怒しました。発注に時間がかかるようになってしまったのですから。結局やり直して、そのプロジェクトは決められた時間とコストをはるかにオーバーしてしまいました。

プロジェクト・マネジャーとして、あなたはユーザーとソフトウェア開発者が早期にかつ頻繁に話し合えるようにしなくてはなりません。