翻訳記事

本記事は、「Why Minimize Management Decision Time」の翻訳です。著者の Johanna Rothman さんの快諾を得て翻訳いたしました。誤字脱字や誤訳がありましたらご指摘ください。

はじめに

私は、2年ほど前に「 Unearthing Your Project's Delays 」という記事を執筆しました。マネージャーのクリフが、「なぜプロジェクトがこんなに遅れたのかを理解したい」と思ったことについて記事に書きました。

そして、この記事についていくつか対話をしてきました。ある細かいことを見逃さない鋭い研究者が私に「T0 から T1 までの時間はどれくらいかかったのか?」と尋ねました。

私は、「マネージャーは、四半期では少なく、1〜2年で仕事をします。その期間の間で、マネージャーは、チームにプロジェクトの予測について尋ね続けることになります。それは、T2 から T5 までの期間よりも長くなってしまうのです。」と答えました。

研究者は悲しそうに、そしてニヤリとしながら「うん、そう思いました。」と言いました。

私の経験上、組織がアジャイルなアプローチをとるか、何らかの方法で移行や変革をしたいと思う時、マネージャーは、チームと共に取り掛かります。チームで人と仕事をしたり、チームと仕事をしたり、マネージャーと仕事をしたりすればするほど、チームと共に取り掛かることは、取り掛かり方としては誤った結末になると確信するようになりました。アジャイルなアプローチはチームの改善に役に立ち、多くのチームは、より早く価値をリリースできます。

チームは、サイクルタイム(Cycle Time )を計測することで、チームの遅延を管理することができます。彼らは仕組み的な問題や遅延に遭遇することになりますが、チームとチームのマネージャーは、これらの問題に取り組めるほど十分に賢いことが多いです。

しかしながら、それでもチームは、チームのマネージャーの遅延を管理することはできないのです。

マネージャーの意思決定が遅れる理由とは

マネージャーが、いつも1年間のプロジェクトポートフォリオをプランニングしているとしましょう。四半期ごとのプランニングに移行することで、とんでもない価値を得ることができるかもしれません。そして、チームが十分に早く成果を出すことができるならば、毎月のポートフォリオのプランニングに移行することだってできます。

ある条件下で: どれくらいの情報で、マネージャーはチームの成果に対しての意思決定をすることができますか?

私は今でも、多くのチームが、何年も未着手なままのプロジェクトの見積もりに、一回に数週間も使っているのを目にしています。または、製品や機能を購入したり、利用したりするかどうかについて確認するための小規模な実験を行っていない場合には、誰かが ROI (費用対効果)を推定するはずです。

私は、大きさの順序や日数の範囲の予測には価値があると思っています。

私は、いつも本にかかる時間を見積もっています。そしてそれはいつもズレます。執筆と出版のあらゆる部分の見積もりと実際を見直すことで、自分の執筆プロセスをどう変えればよいかに気がつきました。今でも私は、本を書くのを早くするための試行錯誤を続けています。

でも、実質的な見積もりは、プロジェクトポートフォリオの議論において付加価値を与えるものではありません。「どれくらい費用がかかるのか?」や「いつ完了するのか?」よりも、「どれくらい投資した方がいいのか?」という方が有用な質問です。

意思決定の遅延による影響

意思決定の遅れがあるチームに与えた影響を示します。

マネージャーは、ポートフォリオの意思決定ミーティングを開始しましたが、チームからの予測をえるための機会を一時中断したとします。チームは、およそ1日をかけて予測の作業を行いましたが、マネージャーは、3週間の間、チームから予測を聞く機会を取りませんでした(訳注: 上手の一番左のステップに着目してください)。

その後、マネージャーは、いくつかのフィーチャーセットの詳細見積もりを求めてきました。チームは、その詳細見積もりの作成に1週間かかりました。しかし、マネージャーはさらに3週間、ミーティングを行いませんでした(訳注: 上図下部の"Wait time"の左から2つ目に着目してください)。

マネージャーは、6週間の遅延を引き起こしたことになります。

その後に、マネージャーは、次の四半期のポートフォリオについて意思決定しました。この意思決定には2時間を要しました。マネージャーの作業時間(Work Time)は、6時間です。マネージャーの待ち時間(Wait Time)は、1,008 時間になります。この意思決定に対するサイクルタイムは、1,014 時間になります。

四半期に入って2週間でポートフォリオに変更があったとしましょう。

問題はありますか?外部の市場からのチカラにより、マネージャーの意識改革の必要性がでてきます。

以下は、その時の費用:

  • チームが、現在のプロジェクトで価値を完成させるのではなく、総見積もりを予測するのにかかった時間
  • チームが、現在のプロジェクトで価値を完成させるのではなく、詳細見積もりにかかった時間
  • マネージャとチームが、最終の意思決定までに何度も切り替えるコンテキストの数

予測と見積もりは、マネージャーの意思決定に違いをもたらすのでしょうか?

あるシニアマネージャーは、ため息をつきながら、「いいえ。最初のミーティングで上位3つのプロジェクトが決まっていた。その場で決めることができたのです。正直なところ、この3つのプロジェクトにもっと多くのチームを投入して、もっと早くに完成させることができたのではないでしょうか。良い意思決定をするための予測や見積もりのデータは必要なかったでしょう。」と言いました。

このシニアマネージャーは、しばらくの間立ち止まり、「私たちは一緒に仕事をするべきだったが、それは難しいことでした。」と言いました。

意思決定までの時間が重要な理由

意思決定までの時間が重要だという要因は以下です:

  • より多くの情報を依頼するたびに、チームは、現在の作業を中断しなければならない
  • それよりも重要なのは、チームは、現在の作業を終わらせることではなく、将来の作業を模索し始めること
  • マネージャーは、すぐに意思決定をしなければならないコンテキストを見失ってしまう

私は、先を見通すことに大賛成なので、早々に選択肢を削除しないでください。問題は誰が何の先を見据えているか?なのです。

  • このプロジェクトでは、チームはプロダクト戦略の先を見据えています。
  • 今後の作業のために、マネジメントチームは、組織の戦略を検討します。

異なるコンテキスト、異なる先の見据え方、異なる意思決定があります。

マネジメントチームの意思決定が早ければ早いほど(特にポートフォリオを変更しないならば)、チームが現在の作業を中断することは少なくなります。チームは早く仕事を終えられます(プロジェクトポートフォリオミーティングにて、「無問題、今のところ変更なしです」と言えます)。

マネージャーが、T0 から T1 までの時間を短縮すると、チームは、ビクつくことがなくなります。チームは、自分たちの仕事に集中できます。

意思決定までの時間の短縮を阻むものとは?

プロジェクトポートフォリオにおけるマネジメントの混沌具合を見るたびに、組織の報酬体系が根本原因になっていると感じます。

組織の報酬体系が何か(MBOか、OKRか)は問題ではありません。マネージャーたちは、チームのために、マーケティングの時間のために、プロダクトマネジメントのために、プロダクトのニーズに対して何でも、個別の報酬をもっているときに、お互いに競争してしまいます。マネージャーたちが共に仕事をすることはありません。

マネージャーたちの競争が激しくなればなるほど、意思決定までの時間が長くなります(詳しくは、「 Modern Management Made Easy Book 3 」の個々のマネージャーの目標に対する具体的な対処法を見てみてください)。

マネージャーたちに、チームとしての報酬を与えたとすれば、意思決定の時間(マネジメントのサイクルタイム)が短縮され、チームのサイクルタイムも短縮されます。すべては、誰もが優れた目標のために最適化するからです。

アジャイルな文化を作りたいのであれば、マネージャーたちから始めましょう。マネージャーがフロー効率化に従い仕事をすると、意思決定の時間が短縮できます。そして、チームにも恩恵がもたらされます。

本記事の翻訳者:

長沢智治

長沢 智治 - アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

PSPO II - Professional Scrum Product Owner II
PSPO I - Professional Scrum Product Owner I
PSM II - Professional Scrum Master II
PSM I - Professional Scrum Master I
PSD I - Professional Scrum Developer I
PAL-EBM - Professional Agile Leadership - Evidence-Based Management
PAL I - Professional Agile Leadership I
SPS- Scaled Professional Scrum
PSU I - Professional Scrum with User Experience
PSK I - Professional Scrum with Kanban I
PSF - Professional Scrum Facilitation Skills
PSPBM - Professional Scrum Product Backlog Management Skills
認定スクラムマスター
DASA Accredited DevOps Trainer
DASAアンバサダー

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール