素早い課題解決を実現する「自己組織化」されたチームづくり

私はCTO室の責任者として、社内のチームビルディングを推進しています。

変化の激しいインターネット業界で勝ち抜いていくために重要なのは、少しでも早くサービスを改善し、ユーザーに価値を提供することです。

そのためには、1人ひとりが自身で課題を解決できる、「自己組織化されたチーム」を作る必要があります。

言い換えると、経営陣ではなくチーム自身が、あるいはマネージャーではなくメンバー自身が、課題を素早く解決できる状態です。

例えば新しい技術に挑戦する時にも、「合宿する」「できる人を連れてくる」といった解決策を自分たちで考えて実行できるほうが、圧倒的にスピードが早いですよね。

一方でこのような状態を妨げるのが、「メンバーの指示待ち姿勢」「課題解決アクションのマネージャーへの集中」「認識の相違から生まれる不要な衝突」などです。

私は2016年に入社したのですが、当初はトップダウンのカルチャーがあり、意思決定はマネージャーがするものだと考える組織風土でした。

課題解決が素早く進む状態ではなかったので、それを改善すべく、自己組織化されたチーム作りを進めてきました。

相互理解を進める「ドラッカー風ワークショップ」

チームビルディングを行う上でまず重要なのが、チーム全員がメンバーとプロジェクトに対して共通認識を持つことです。

チームの成熟過程を説明する「タックマンモデル」では、チームビルディングは「お互いを全く知らない状態から、相互理解を進めて関係を構築する」という形成期からスタートするとされています。

▼チームの成熟過程を定義したタックマンモデル（画像はこちらの資料から引用）

そして次に、実際にプロジェクトを進める中で、意見の衝突が生じる混乱期が訪れます。その後、共通認識が作られる中で、統一期、機能期という形で、チームが出来上がっていくという考え方です。

弊社ではまず、この形成期における関係構築を進めるために、「ドラッカー風ワークショップ」を行いました。

このワークショップでは、4つの質問に対してポストイットで回答し、メンバー間の相互理解と期待値の擦り合わせをします。

▼ワークショップのイメージ（画像は編集部が作成）

まず最初は「何が得意なのか？」という質問で、自分の特技をシェアします。

すると例えば「今はiOSの開発をしているけど、この人は本当はQAもやっていたんだ」と、相手のバックグラウンドをより理解することができます。

次に「どうやって貢献するつもりか？」という質問に対して、チーム目標に対する貢献の仕方を書きます。

そして、「大切に思う価値観は何か？」という質問で、「早くアウトプットしてフィードバックをもらいたい」や「定時以降は連絡してほしくない」ということを書きます。

その人が大切にしたい考え方を理解しておくことで、発言の裏側にあるコンテキストが読み取りやすくなり、不要な衝突を避けることができます。

最後に「メンバーが自分にどんな成果を期待していると思うか？」という質問で、自分が周囲からどのようなことに期待されているかを想像して書きます。

その上で他のメンバーが、一番やってほしいことに「星」、次にやってほしいことに「丸」をつけます。

最後に、他のメンバーが、実際に本人に対して期待していることも書いてもらうことで、「自分はこの部分に集中すれば良いんだな」「実はこういう貢献はいらないんだな」という理解が進み、期待と違う方向に向かうことを避けることができます。

「インセプションデッキ」で、仕事を進める上での合意を形成

そして、チームの目的や業務の進め方に関する衝突が発生する混乱期では、それらを擦り合わせるために「インセプションデッキ」を実施しました。

メンバーのパーソナリティへの理解を深めるドラッカー風ワークショップに対して、インセプションデッキでは、10の質問に答える中で、プロジェクトに対する共通認識を築いていきます。

▼インセプションデッキで問われる質問（画像は編集部が作成）

例えば「我々はなぜここにいるのか」は、チームのあるべき理想の姿について、全員で共通の理解を持つための問いです。

Pairsで言うと、カップルが知り合ったきっかけとして「Pairsで知り合ったんです」と普通に言えるような状態を作る、というような目標を掲げます。

また、「やることやらないことリスト」では、「たとえ物凄く忙しくても、中長期の施策には必ず取り組む」「無意味な数字出しをやめる」といったことを明文化します。

あるいは、「トレードオフスライダー」では、「納期と品質」といったトレードオフ関係にある事項について、優先順位を明確にします。そうすることで、「それ、なんでやっているの？」という感情が生まれることを防ぎます。

このように、インセプションデッキを通して、仕事を進める上での合意形成、言い換えるとワーキングアグリーメントを形成します。すると、判断の迷いや衝突がなくなり、
プロジェクトを進めるスピードを落とさないようにできるんですね。

「振り返り会」で事実に基づいた課題を共有し、解決策を検討

このようにメンバーやプロジェクトに対する共通認識を作ったとしても、日々の業務の中では当然、次々と課題が発生します。

そこで大切なことは、まず、その課題を放置しないよう、可視化してチームで共有することです。

また、課題を自分たちで解決できるものと、自分たちだけではコントロールできないものに分け、それぞれに対して適切な解決策を検討することが重要です。

前者の自分たちで解決できる課題については、2週間のスプリント単位で業務を強制的に止めてでも、立ち止まって、このプロセスは良かったのか？　を話し合う「振り返り会」を通して解決策を議論しています。

振り返り会は、全員が発言をしやすいよう「誰かを責めるのではなく、どう改善できるか」にフォーカスした上で、KPT（※）形式で実施しています。

※Keep（良かったこと）、Problem（悪かったこと）、Try（試したいこと）を共有して行う振り返りの手法

そして、適切な解決策を考えるためにも、意見ではなく、まずは事実を述べるようにします。「こうすればいいのに」という話をすると、Howから始まってしまい、それが事実に基づいているのかどうかわからないからです。

実際の振り返り会で、「プロダクトバックログ（※）がレディーでない」という課題が出たことがありました。受け入れ条件（完了定義）が曖昧で、適切な状態で開発を進めることができなかったんです。

※プロダクトバックログ：これから開発を進める項目に関する要件のこと

この場合だと、課題として「受け入れ条件が十分に定義されていなかった」「プロダクトオーナーだけで受け入れ条件を決めていた」という事実を挙げていきます。

▼実際の振り返り内容

そこで「受け入れ条件をチーム全員で決めてから開発を始める」ということを決めました。

これは、「プロダクトオーナーだけではなく、エンジニアを含めた全員で書けば、受け入れ条件が不足せずに明確になる」という仮説から生まれた解決策です。

そして、解決策を実行する際は、それが適切だったのかどうかを確かめる指標を必ず設定します。このケースだと、次のスプリントで、プロダクトバックログがレディーになった件数が増えたら、うまくいったということになります。

このように課題の解決策に対しては、効果を検証するための指標をもたせた上で、小さく試すプロセスを、チームで素早く回すことを意識しています。

自分たちで解決できない課題は、外向きにオープン化する

また、自分たちでコントロールできない課題については、それらを「妨害リスト」としてTrello上で共有して対処しています。

例えば、「iOSのエンジニアがチームにいない」という課題だと、自分たちではなく、人事に採用に動いてもらうようお願いする形になります。

▼Trello上で共有される妨害リスト

通常、こういった課題は、マネージャーが溜め込みがちです。ただ、見える化しておくことで、ふらっと立ち寄ったエグゼクティブがそれを見て、「こうしたらいいんじゃないか」と解決策を提案してくれたりします。

このように、妨害リストによって、課題をエスカレーションしやすい状態を作っているんですね。自分たちではコントロールできない課題が、チーム内に溜め込まれないように工夫をしています。

自ら課題に気づき、解決できる「自己組織化」されたチームに成長

このような取り組みを通して、様々な課題が共有された結果、「より自分たちはユーザーのことを理解しなければならない」という話になりました。

そして、実際にユーザーを社内に呼んで、インタビューをするというような動きがすごく増えたんです。

自分たちが足りないことに気付き、それを解決しようとする姿勢が生まれたことは、とても良いことだと感じています。

また、チームの課題を、チーム自身で考えられるようなったので、パフォーマンスの問題を自分事として捉えることができるようなりました。その結果、課題解決の素早く進み、開発スピードも向上させることができました。

人は、集まっただけではチームではありません。共通認識をしっかりと持ち、課題を自ら解決できるようになってこそ、チームと言えるのだと思います。

今後も、組織の成長に伴い、新しいメンバーを迎え入れることも増えてくるかとは思います。引き続き強いチーム作りを進めて、ユーザーに価値を提供できるサービスを開発していきたいですね。（了）