It’s hard enough making decisions on our own. Sandwich or salad? Coffee or tea? T-shirt or button-down? Now imagine if your whole team was in your closet, helping to choose your outfit. The teams we work with represent a wide variety of expertise and experience, and that can cause conflict when a decision needs to be made. Here’s how my team makes decisions.
情報源: Inside Atlassian: how to make team decisions without killing your momentum | Atlassian Blogs
自分で決定を下すというのは難しいものです。サンドイッチにするかサラダにするか? コーヒーにするかお茶にするか? Tシャツかボタンダウンの服にするか? でももし、あなたのチームの全員がクローゼットにいて、服を選ぶ手伝いをしてくれると想像してみてください。
チームには様々な専門知識や経験を有するメンバーがおり、決断を下す際にはその多様性が衝突のもとになる場合があります。個人的なフラストレーションの原因となるだけでなく、衝突の結果決断が遅れれば業務の妨げとなります。チームが長い時間を検討に費やせば、行動を起こすのに使えたはずの時間を浪費することにつながるのです。
ひとつの決断を下すために何か月もかけることを目的とするチームというのはありえません。ところが、実際に起きているのはまさにそれなのです。
私はアトラシアンで開発チームを率いています。チームの担当は製品全般のアカウント作成とログインで、顧客に対しても会社に対しても大きな責任を負う立場にあります。なので、意思決定の難しさについてはよくわかっています。
チームはセキュリティーと個人情報を扱っているため、複雑な決断を下す場合が多くなります。意思決定の過程を改善するために私たちは努力を重ね、「分析まひ」を回避すべく努めています。チームの目標は、プロジェクトの勢いを失うことなく正しい決定を下すことです。それからは決定に沿って行動し、フィードバックを得て、必要とあればイテレーションを行います。
ここでは、大きくかつ困難な決断を下す際に私のチームが行っていることを紹介しましょう。
図に起こす
話し合いが堂々巡りに陥って、『ウエスト・ワールド』に登場する記憶をリセットされるロボットのような気分になった時は、一歩下がって進展しない原因を探ってみるべきです。不確実なことがらを視覚化するというのは便利なテクニックです。私のチームでは、問題や意思決定がかなり厄介になったと判断された時にはすぐにこの手を打つようにしています。
意思決定を視覚化し、その妨げとなる要因を探るためには、問題をグラフで書き表します。
図を使って意思決定を行う目的とその理由(要件)、そしてどう解決するのか(解決方法)を検討します。この2つをグラフに書き表すと、意思決定の困難さ、および困難な理由を探る手がかりがおぼろげながら見えてきます。要件についての意見の不一致と、解決方法にまつわる不確実さと、問題の要点はどちらなのでしょう? (あるいは両方が等しく絡む問題なのかもしれません)
意思決定の一番難しい部分を突き止めたなら、まずは問題を複雑にしている要因について考え、それを解消するようにしましょう。
分解する
要件と解決方法が両方とも込み入っている場合、意思決定はこの上なく難しくなります。私のチームでは、扱いづらいログインと認証のユースケース(方法)の問題を抱えています。これについて議論する際は往々にして、アカウントの所有権とプライバシーに関する哲学的原則(要件)がつきまとってきます。
方法と要件が両方とも複雑な場合は、可能であればそれを扱いやすいサイズまで分割します。グラフから方法よりも要件の方が複雑だとわかった場合は、要件についてコンセンサスを得るまでは方法に関する議論を控えます。そしてどうするかの議論に踏み込む前に、なぜこれをやるのかという疑問に取り組むのです。
要件の比重が大きい場合、方法は要件から導き出されます。私のチームに関わる例としては、原則と顧客体験に焦点が当たる意思決定があります。
例として、アトラシアンの製品全体についてシングルサインオンの改善に着手したとしましょう。その場合、ソフトウェア管理者の体験とエンドユーザーの体験のどちらに焦点を当てるべきか議論している段階で技術実装について考えても意味がありません。何に焦点を当てるかについてチーム内のコンセンサスが得られれば、残る解決策の決定は「方法が単純か複雑か」というレベルまで落としこみやすくなります。
決定権を持つ
チームの意思決定にとって何より重要なのは、決定権をチームが持っていることです。なぜなら決定権を持っているということは、意思決定のプロセスを支える一番の柱になるからです。最終的に誰が決定を下すのかがわからない状態では、人は決定を先延ばしにしたり、誰か別の人が取りかかっているものとみなしてしまいます。
意思決定には、チームのコンセンサスが得られればそれだけで済むようなシンプルなものもあります。他方、難しい意思決定の場合は、関係者が各々の役割を正確に理解しておけばスムーズに進みます。 私のチームでは、DACIと呼ばれる意思決定のフレームワークを活用し、意思決定のプロセスで各々が果たすべき役割を明確にしています。DACIでは、各人の役割を以下のように分類します:
- D = ドライバー(Driver)。ステークホルダーを集め、必要な情報を全て照合し、スコープを定め、期日までに意思決定を完了させる責任を負う人物。
- A = アプルーバー(Approver)。決断を下す唯一の人物。担当者を一人だけにすることで、受動的な「承認印」ではなく能動的な「意思決定者」としての役割を担わせる。
- C = コントリビューター(Contributors)。主題となることがらについての知識を持ち、忠告を行える人物。忠告はするが、意思決定には参与しない。
- I = インフォームド(Informed)。担当する仕事が決定内容の影響を受ける人物。決断が下されれば、それについて報告を受ける。忠告をせず、意思決定にも参与しない。
最終決定が一人だけに委ねられると聞いて身構える人もいるかもしれません。しかしプロセス自体はチーム全体で行うものです。各人がそれぞれ役割を持ち、チーム外の人間でもコントリビューターとして参加する機会があるのです。
DACIは私たちの発明ではありません。多くの企業でさまざまなチームがDACIを活用しています。インターネットで検索すれば(あるいはここを見れば)DACIを導入する際の基本的な情報が得られますが、ここでは私のチームからのアドバイスをいくつか紹介しておきましょう。
- 複雑あるいは混沌とした意思決定の際には、アプルーバーとドライバーは早期に協同し、プロジェクトを進めるように意思決定のプランニングを行うのがよいでしょう。協力してスコープを定め、タイムラインを定め、チーム内外の依存関係を把握しましょう。その後、意思決定に関わる対話がコンセンサスを得たスコープから外れないようにするのはドライバーの責任となります。スコープを外れる事柄は一旦保留し、チームが本筋から脱線しないようにしましょう。
- アプルーバーは意思決定のプロセス全体に能動的に携わりましょう。またフィードバックやコントリビューターからの忠告は、寄せられると同時にレビューをしましょう(後回しにして期日ギリギリにちょっと目を通すだけ、とはならないように)。
- 意思決定のプロセスを進めていく責任はドライバーにありますが、困難な方向に迷い込みそうな時には軌道修正ができるよう、アプルーバーへのエンパワーメントも必要です。プロセスが何らかの面で機能不全に陥った時などはアプルーバーの出番です。結局のところ、最終的な決断を下すのはアプルーバーの仕事となります。
- コントリビューターの役割を担う人は可能な限り、自分の忠告の根拠となる研究結果やデータ、および自分の経験を示しましょう。求められるのは根拠のない意見ではなく、裏付けのある卓見なのです。
立ち止まるよりも行動する
問題のグラフやDACIを使うコツは、時間をかけすぎないことです。いずれは決断を下すべき時がやってきます。そして決断が早ければ素早く行動に移ることができ、選んだ方法が効果的かどうか判断するためのデータを早期に集めることができます。最良の決断を下そうと長期間苦闘したところで勢いに乗ることはできません。勢いとは実際に行動し、イテレーションを行うことで得られるものであり、勢いこそが最終的に成功をつかむ原動力なのです。
「モメンタム (Momentum = 勢い) は、確実な意思決定でなく、成功を導くためのものである」
チームの全員が決定内容に満足することはありえないでしょう。しかし、いったん決断が下されれば熱心に取り組むものです。
私のチームでは「違う意見を持って、熱心に取り組むべし」という言い方をします。異なる意見を持ち、自分の視点を伝え、データでそれを裏付けるというのは健全なあり方です。とはいえ結局のところ、私たちは決定事項に従い、成功に向けて取り組んでいきます。決定事項についてどう思おうが、それは関係がないことです。
完璧な決断にこだわるよりも、良い決断をして行動に移る方がよいのです。そもそも完璧な決断など存在しないかもしれないのですから。