チームをちょっとだけアジャイルにするキックオフミーティング

on


顧客とのプロジェクト・キックオフミーティング
プロジェクトをスタートするときに、普通、顧客とキックオフミーティングをします。契約を結んでこれから約束した期日に向けて顧客とチームでdeliverable、つまり、システムを届けるためのスタートポイントとしてのミーティングを開催します。

このスタートラインとなるミーティングは、これから毎日顔を突き合わせる顧客と良い関係を築くためのタイセツな位置づけになるものです。

  • deliverableの確認
  • スケジュールとマイルストーン
  • プロジェクトの進め方
  • 具体的なプロジェクト管理方法
  • 会議体の設定
  • 次回agendaと宿題依頼など


これらを顧客とキチンとできて、気持ちよくスタートできたとして、さて、チームとのキックオフはどうなっているのだろう？
いくら、顧客と良いスタートが切れたとしても、チームとのスタートがなおざり(おざなりではなくて)になっていたりしないのだろうか。

契約が決まり、プロジェクトを立ち上げるとき、相当ドタバタするものですね。チームメンバのアサインや諸々の手続きやら、顧客とのスケジュール調整やらで。

実際、チームをカタチなりにも編成しても、チームビルディングするための時間が取れず、「顧客とのキックオフミーティングを見ておいて！」と投げっぱなしになっていることありませんか。

それ、あとあとに重大なリスクを発現させるタネを蒔いているかもしれないのですよ。後になって、今まで進めてきたことを全部ひっくり返ってしまうようなことは避けたいものです。それも、チームのフォルトが原因だったりしたら、今まで費やしてきたコストをドブに捨てて一からやりなすことになります。
＃想像するだけでもうんざり。

なら、最初からチームの中でボタンを掛け違わないように何らかしておかないといけないわけです。それをちょっとだけ、チームの時間を充てることで回避できるとしたら、やらないわけには行かないですよね。
＃それ、やりましょう。


顧客より、チームの方が知りたがっている
顧客は、顧客の要求をある時期にそのとおりに出来上がっているか受け入れ可能か確認すればよいですが、チームは顧客の要求をdeliverableとして実現する責を追います。だから、早い段階から、より多くの情報を知りたいと思うものです。

なぜって、顧客に届ける期日は決められていて、その届けるdeliverableは顧客からしか出てこないから、顧客の要求を早く知り、チームの時間を少しでも多く確保したいため、です。
＃そんなことは分かっているのに、実際、そのために時間を割くことをしないのはなぜでしょうかね。


少ない情報でも実現仕様を考えてしまうエンジニア
エンジニアの悲しい性で、契約なり提案仕様を見ただけで、頭の中でゴリゴリと

「あ、それならアレとコレをこう組み合わせて、こんな風にしたらできるかな？」
とか、
「それムズイなー。あれが引っかかるゾ。」


とか、そこまで頼まれてもいないのに実現仕様の設計をはじめちゃうものです。早く作りたい、早く届けたい。作ることが楽しいと思っているエンジニアは、よりその傾向が強いものです。だから、その考えるためのえさが欲しくて、情報クレクレと口をパクパクさせるわけです。
＃エンジニア魂というか性と言うか。


チームに、顧客以上のキックオフミーティングが必要なわけ
さて、顧客とのキックオフミーティングに前後して、チームともプロジェクトキックオフミーティングするのだけれど、限られた時間のミーティングになるで、とても1回では終わらないものです。だから、段階的にやるものだと思って望んだほうがよいです。

で、どのようにやろうかと。

プロジェクトの目的は、“顧客と契約したdeliverableを決められた日までに届ける”こと。もちろん、コストの上限や適用するソフトウェアなどの制約があるけれど、本質的には、約束した日までに届けることで。

最初のキックオフミーティングでは、契約を基本として何をdeliverableするか、からはじめよう。

  • チーム全員が参加できるように日程を調整しよう。　＃全員参加しないと意味がない
  • チームは何をdeliverableするか、確認しよう。　＃全員認識しないと忘れる
  • それはどのような形なのかを図をたくさん描いて理解しよう。　＃手書きの方が印象に残る
  • 最初のキックオフミーティングでは、概念レベルまでにしておこう。　＃仔細を話したくなるけれど、そこはグッと我慢して
  • この図を元にどこにシステムデザイン上、プロジェクトの課題になるかを書き留めておこう。　＃未来を想像しよう
  • 図で表現しにくいことは、表にしてMECEになるようにしよう。　＃概念レベルでも曖昧さを作らない
  • マスタースケジュールで時間軸を体感しよう。　＃あくまでも今時点であって随時変わるものとして
  • スケジュールのマイルストーンを確認しよう。　＃乗り換え遅れがでないように
  • そのマイルストーンまでに、何が“完了”していなければならないかを共有しよう。　＃完了の状態を定義しよう
  • このスケジュールとマイルストーン上で、何がプロジェクトの課題になるかを書き留めておこう。　＃遅れたら何が起きるかを想像しよう


一番初めは、契約ベースでの概念レベルをチーム全員で共有することが、プロジェクトの“大きな方向性を見誤らせないため”にとてもタイセツなことです。