A06. アメリカでのプロジェクトマネジメント
■関連する記事はこちら。
”未来の管理”
アメリカでは、全体的な傾向として「過去は変えられない。起きてしまったことは変えようがない。それに時間を費やすよりは未来に目を向けて、現状よりも少しでも良い状態に持っていこう」と考えられている方が多かったです。
そのためプロジェクトを進めるときでも、未来の話、つまり今後の計画の話に時間を費やすことが多かったです。
今取り組んでいる課題に対して、現状の取り組みは〇〇である、そして何月何日までに解決策(たとえば改善ソフトウェア)がリリースされる予定である。
これを各サブシステムのチームから提示してもらい、「それでは×月×日までにシステムソフトをリリースしましょう」となります。このとき、その課題が発生したことに関して、その要因を明らかにした上で解決策を提示することが求められます。
しかし、このとき課題が発生したことに対して、再発防止策を綿密に議論して関係各所から完璧なまでに事前承認を得るようなことはしません。つまり、過去に起きてしまったことは変えようがない、だからできるだけ自分達がコントロールできること(つまり未来)に集中しよう、そこに資源を投下しよう、と考えます。
この進め方はとても合理的な進め方だと、個人的には思っています。
”過去の管理”
翻って日本でのプロジェクトマネジメントのあり方はどうでしょうか。日本においては、何か課題が発生した時に、なぜそれが発生したのか細部に至るまで原因を突き止めようとします。
そして課題の解決策をリリースする際に、課題が発生した経緯や解決策に至るプロセスを事細かに完璧なまでに見事に説明しようとします。そしてようやく解決策をリリースします。
このとき重要なことは、過去にこだわりすぎてしまうために、未来の計画つまりリリースコンテンツのリリーススケジュールの策定がおろそかになってしまっていることです。
大規模なプロジェクトの場合は、ひとつのチームでなく多くのチームが参加しているわけであり、あるサブシステムのリリースコンテンツは他のサブシステムに大きな影響を与えることがほとんどです。
ここで、そのサブシステムが過去にこだわりすぎて、未来の計画に時間をかけないと、周りのサブシステムがまだ準備できていない状態で解決策がリリースされることがあり、その結果システム全体で不整合が起きることがあります。
そのため、事前にリリースする内容とそのリリース時期を事前に周りのサブシステムと共有することがとても重要になります。
筆者の経験からいえば、1〜2ヶ月前にはそれを共有しておくのがよいでしょう。少なくとも2〜3週間前にはそれを共有しておきたいところです。ただし、いったん品質が安定したシステムソフトがリリースされたあと、つまり保守期間に入っている場合などは、6ヶ月前ぐらいの期間でも問題ないことでしょう。
解決策は”リリースコンテンツ&スケジュール”リスト
このような課題を未然に防ぐために、筆者がよく使っていたのが”リリースコンテンツ&スケジュール”リストです。
これは、筆者がアメリカに駐在している時に現地のアメリカ人から教わったプロジェクトマネジメント手法のひとつです。
まず、エクセルの縦方向に”リリースコンテンツ”を並べます。このとき、可能であれば、そのコンテンツに紐づいた課題管理番号が一緒に並べられているとなおよいでしょう。
つぎに、エクセルの横方向に”リリーススケジュール”をそのコンテンツごとに並べます。このときリリース予定日を何月何日レベルまで詳細に記載するとよいでしょう。
この”日付を記入する”ということが大規模プロジェクトでは特に重要です。これによって、アメリカのソフトウェアインテグチームの準備であったり、インドのソフトウェアテストチームの準備であったり、イギリスのソフトウェア開発チームの準備が計画されます。
つまり、この”日付”に合わせて、各署のチームが各署のリソース配分の調整を始めるわけです。
そして、できるだけ無駄のないリソース配分を決めて、そのリリース日までにできること、やらないことなどを割り振って決めます。それによって、全体として無駄のない効率的な開発を進めることが可能になります。
これはシンプルなようで、とても有効なマネジメント手法です。みなさんもぜひこれを検討してみてください。
まとめ
■過去の記事はこちら。