要求を明らかにする

　「要求を明らかにする」―これは言うまでもないことなのですが、しかしながら、現実には「要求」を正しく捉えないでスケジュールを書いていることが多いし、中には、「要求」が出ていないのに、スケジュールが存在していることもあります。

　そういうところでは、たいてい「作業」を並べる形でスケジュールが作られてしまうことになります。（この問題は後段＝「作業の成果物をイメージする」に譲ります）

　「要求を明らかにする」ということは、

　　・自分たちがこれから取り掛かる作業の「ゴール」は何なのか？
　　・どういうものを作り出すことが求められているのか？

を明らかにすることであり、各自の中でゴールがイメージ出来ることです。言い換えればこれが「最終成果物」です。これを外した状態でスケジュールを書いても、リワークになるだけで、要求を満たせる可能性は低いといわざるを得ません。

　例えば、最終成果物の

　　・機能
　　・性能
　　・品質（製品としての品質と、そのプログラム自分の品質）
　　・納期
　　・納入物
　　・納入方法・条件

などを明らかにすることによって、この後のスケジュールの策定に取り掛かることが出来るのです。また、場合によっては、そこで開発方法や開発手順も指定されるかも知れません。

　あるいは、“段階的開発”を要求されたり、設計手法なども指定されるかも知れません。この問題は本稿のテーマではありませんので、これ以上は深入りしませんが、いずれにしろ、最終成果物が納められる姿をイメージできることが条件になります。

　また、途中で「デモ」などが求められる場合がありますが、これなどは開発方法や段取りに大きく影響しますので、早い段階で顧客の要求をしっかり確認しておくことが重要です。あとで、こんな要求が出てきたら、スタッフの気分は大きく損なわれることを、マネージャーや責任者は認識しておいて下さい。

　「エンジニアは壊れ物（FRAGILE!）」なのです。

　ですから、よく分からない状態で、スケジューリングやその後の作業に入ることは避けて下さい。もっとも、１人のメンバーだけで「避ける」ことはできないかも知れませんね。マネージャーか適当なリーダーがその判断をしてくれないと、難しいかも知れません。

　実際問題として、それでも“スケジュールを書け”と要求されたどうしようもないかも知れませんね（つらいな〜）。実際に、「スケジュールを書いてくれないと、顧客と詳しい話ができない」なんて本末転倒なことを言いだす営業の人もいます。

　中でも、最終成果物以外の納入物が忘れられることが多く、そのため、最後になって、慌てて用意することになります。もちろん、リワークです。関連する納入物が開発過程で作られていたとしても、最初から納入することを想定していない以上、それに対して何らかの加工が必要になります。それがリワークなのです。その結果、次のプロジェクトの着手が遅れることになります。

　勿論、要求は後から変化することがあり、それを何時までも“確定”するまで待っているわけには行きません。どこかで走ることになりますが、走るに必要な内容だけは明らかにするようにして下さい。（要求管理に関しては、それだけで奥が深いので、別の機会に譲ります）