- ここでは略語は一旦忘れ、意思決定プロセスについて見ていこう
- 人は誰でも自分で小さな決定をしていくべき
- 大きな決断は慎重に行うべき
- シンプルな５ステップの意思決定プロセスに従うだけ
- 決断を下すのになぜ数日待つ必要があるのか？
- 決定事項をよりスマートに実行に移すには
- １つのキーポイント: 決断するのに十分な時間を取ろう！
ここでは略語は一旦忘れ、意思決定プロセスについて見ていこう
前章の「コミュニケーションのピラミッド」をさらに実践へと移していきましょう。この章では、私たちチームの意思決定プロセスについてお話します。気を利かせた(S.M.A.R.T.のような) 略語は出てきませんが、とてもストレートで分かりやすいものとなっています。まずは私たちの意思決定プロセスはどのようなものなのかを説明し、その後で実例を挙げて示したいと思います。
人は誰でも自分で小さな決定をしていくべき
マイクロマネジメントは過去のものです。少なくとも、現代的なチームにおいては、それは過去のものでなければいけません。チームのメンバーはそれぞれが何らかの分野の専門家であり、その人が変更や改善できる点を見つけたならば、直感を信じてそのままそれを行うべきです。
次のシンプルなルールに従ってください:
事前に許可を求めるのではなく、後で許してもらいなさい！
小さな決定であっても、それは小さな結果を伴うことなので、自分自身でこうと決めて実際に行った後で１つや２つのミスをしたとしても、たいていはそれらのミスは簡単に修正することができるものです。私はいつも新入社員にこう説明しています。ミスをしても解雇されることはないけれども、前進していく姿勢がなかったり、成果物を出せなかったり、価値を生みだせなかったりしたしたら、そのときは解雇の可能性があります、と。
大きな決断は慎重に行うべき
ここで言う「大きな決断」とは、より多くの人々の関与を必要とする決定を意味します。決定のプロセスに多くの人が参加することが前提であったり、決定によって多くの人が影響を受けるということです。そのような決断はその場の勢いで行われるべきではありませんが、その一方で、現在的なチームにおいては、誰かが最終決定するまでずっと待っている時間が長くてもいけません。そのために、前の章でも触れたプロセスを私たちは取っていますが、ここではまずそれを要約してみます。
シンプルな５ステップの意思決定プロセスに従うだけ
まずは、あなたが解決しようとしている問題を特定し、それから、時間をかけて考えて調査し、その上で解決策を生み出します。次に、チームや自分自身のためにも、その解決策を書き出します。その後、週次の会議の中でそれについて議論し、修正したり導入に移行します。
とても簡単ですよね？それでは、実例を挙げて説明していきましょう。ここでは、私たちがアプリに新しい機能を実装するという時の例を用います:
ステップ１: 問題を特定する
私は何人かの顧客と話し、彼らの話を聞いている中で、Nozbe Teamsアプリに取り組むべき問題があることに気づきました。
ここで私は、プロダクトVPへ「Nozbe Teamsにこういった機能を追加する必要があるよ！」 と書くのではなく、異なる手順を踏むようにしています。まずは、「Nozbe Teamsデザイン」のプロジェクトにタスクを作成し、翌日の数時間をスケジュールし、それについて考え解決策を練る時間を作ります。
ステップ２: 調査して解決策を考える
次はリサーチをする時間です。私は通常、以下のことをミックスしながらリサーチしています:
- 過去のタスクやドキュメントをチェックして、過去にこの問題についてアプローチしたことがないかを確認する
- 他社が似たような問題にどのように対処しているのかをインターネットで調べる
- このテーマについての本や記事を手に入れる
- YouTubeで参考になるようなビデオを見る
- タスクのコメントでチームの誰かに聞いてみる
ここではきちんと時間をかけて調査するということが重要です。初動の調査には、私は通常最低でも２時間はかけるようにしています。その後は直感で、調査にあとどのくらいの時間が必要かを判断しています。
ステップ３: チームや自分のために書き出す
さて、いよいよ書き上げる時間です。次の「デザイン会議」は火曜日なので、遅くとも月曜の夜までに問題に対する解決案を書き上げ、Dropbox Paperドキュメントに更新します。それが終わったら、Nozbe Teamsのタスクもアップデートし、そのタスクを「次の会議でのアジェンダ」のセクションに移し、会議で議論したい私のトピックスとして誰でも見れるようにしておきます。
そうして、火曜日の午前中には、午後の会議に先立ち皆がコメントをポストできるようにするのです。こうすることで、実際には会議が始まる前からコメントで取り上げられ、議論が行われるのです。
ステップ４: 会議で解決策を話し合う
会議がスタートしたら、部屋にいる人は (私たちの場合には “バーチャルルーム” ですが) 皆、事前に問題や解決案について読み、コメントで最初の反応をポストしているはずですので、
わざわざ最初から説明するということに時間を取られずに、すぐに、私のニュアンスの説明や、アイデアの深いところに入っていきます。第８章でも、会議の中でいかにして議論して、主張して、コミットするかについて説明しました。そして、最終的にいかにして結論に到達しているかも説明しています。
ステップ５: 決断を下す
この意思決定プロセス全体は、以下の３つの成果のうちいずれか１つに到達することを目標としています:
- 提案された解決案の実装に移行する
- 解決策についてもう１週間フィードバックを再考し修正する時間を設け、次の会議で再び議論する
- 提案された案を完全に却下する (他のタスクを作成し、問題に対する新しいアプローチを練る)
これだけです。決断はこの３つの選択肢に帰着します。時には、解決案が非常に明解であるため、少し議論しただけでそのまま、あるいは少しだけ手を加えてすぐに実装に移るということもあります。ある時は、さらにフィードバックや修正を取り入れるためにもう一週間の時間が必要なこともあります。解決策を提案した人は全てのフィードバックを消化した上で再考し、次の週の会議で修正案を提示します。またある時には、問題だと思っていたことが実はそれほど大きな問題ではないと判断されたり、自分たちが考え出した解決策が好ましくないと判断されたり、まだ時期尚早だと判断されたりということもありますが、そういう時には案を完全に破棄します。
決断を下すのになぜ数日待つ必要があるのか？
私たちも含めアクションを素早く起こすことに価値を置いているチームにとっては、時に、次の週の議論まで待つことが難しいこともあります。私たちは小さなチームというのが売りで、それは機敏で軽快でスマートなチームであるべきなのですから。だから、とりあえずやってみよう！
という訳には、実はいきません。
これまでの私たちの経験から言えることですが、ほとんどの意思決定においては、数日かけて検討し、分析し、フィードバックを求めるというのは大したことではなく、それどころか、決定をより良いものにしてくれるのです。
小さな決定は自分の直感ですばやく行ってください。しかし、大きな決断には時間をかけましょう。
ここで定期的に任意の会議を開くことが、より大きな意味を持つようになってきます (第７章で説明しています)。今日すぐに大きなことを決断するのではなく、数日かけて分析し、もっと考え、書き出してフィードバックを交換し、その上で次の会議で議論するのです。決定は数日遅れてしまいますが、結果としてより良いものとなるのです。
多くの場合、この数日が違いを生みます。問題を他の文脈から考えたり、より多くの情報を収集したりできる時間につながるからです。また一方で、それはたかが一週間だけの遅れとも考えることができます。あまりにも長い間決定を先延ばしにしているというのでもなく、いわゆる分析マヒに陥っているというわけでもありません 1。
決定事項をよりスマートに実行に移すには
OK、あなたは意思決定プロセス５つのステップを全て経て来たけれども、まだ自信が持てないとしましょう。あなたは決定を実行するのに ほとんど準備はできている のですが、まだ少し疑いを持っているという状態です。もしかしたら、間違っているかもしれない？もしかしたら、まだ早すぎるかもしれない？もしかしたら、もっと良い方法があるかもしれない？そんな状況の時でも前進していくために、私たちはいくつかの切り札を用意しています。
「安っぽい」方法が一番
「安い」の辞書での定義は、安価で質が悪い を意味しますが、これはまさに私たちがここで目指しているものです。決定したものに確信が持てないけれども、とりあえず試してどのように 感じるか 見てみたい時には、「最も安いやり方」でやってみます。経費をかけすぎず、最小限のデザインで・・・決定事項を実際に実装して見てみるのです。そのような「安っぽい」やり方で導入した決定をもし気に入ったら、完全なフル装備の実装に着手します。
私たちの製品では、ユーザーにお知らせすることなく新しい機能を追加することもしばしばあります。ユーザーがそれに気づくかどうか、それを使ってくれるかどうか、それをどれだけ気に入ってくれるかどうか、もっと改善してほしいと感じているかどうか、などを観察します。
影響を数人に絞る
決定事項にまだ迷いがある時には、それによって影響が生じる人を制限します。私たちの製品の開発、特にNozbe Teamsでは、新しい機能をまずはチームだけにリリースします。これを「ドッグフーディング」と呼んでいます 2。
社内で新しい方針を導入する時にも、しばしば少ない人数や少ない部署に限定して適用し、その影響を観察します。それからフィードバックをもらい、その後チーム全体へと展開していきます。
このやり方はマーケティング活動では一般的です。経験豊富なマーケティング担当者は、まず最初に小さなターゲットグループに向けて広告をテストしてそのインパクトを測定します。初期テストの後、見込みのあるより大きなグループへと広告を展開していくのです。
決定事項は変更不能ではないので、レビューする日を決める
決定されたものは一時的なものにすぎないという前提を持っておきます。多くの場合、私たちは決定事項を導入した後で、２～３ヶ月後に「修正会議」を設定し、決定事項の見直しを図っています。
その会議の中で “OK” だったものや、”OKでなかった” もの、改善すべきもの、などの分析をします。バーチャルビデオ会議の中では、通常、議長のホストがそれらのポイントを視覚化したマインドマップをシェアスクリーンして皆で議論しています。フィードバックがあるごとにマインドマップを更新していきます。会議が終わった後には、ホストが結論と将来への提案を示すようにしています。
１つのキーポイント: 決断するのに十分な時間を取ろう！
大きな決断をする時には少し時間を取るというのが賢いやり方です。なぜなら、私たち人間は、焦って早まった決断をしてしまうという傾向があるからです。ここで説明した５ステップのプロセスに従いながら、まずは 安っぽい 方法で実行してみることを恐れないでください。
私たちのこのプロセスは、ライアン・シンガー (Ryan Singer) 著「Shape Up」3にインスパイアされています。ぜひ一読することをお勧めします。