一般的に、自律型のチームは他律型のチームよりも開発のスピードが早く、問題を未然に対処できると言われています。自律型のチームに不可欠な要素として、「何でも言いやすい雰囲気」「居心地の良さ」の創出があります。これらは「心理的安全性」とも呼ばれ、米グーグル社が「チームの生産性を高める唯一の方法」として発表したことで大きな注目を集めています。
本記事では、2018年に公開した「心理的安全性を0から80ぐらいに上げた話」が1300以上ものはてなブックマークされたCAMPFIREの久津佑介さんに、心理的安全性をチーム内に創出した実体験をお伺いします。
「バグや障害の多発」「エンジニアの離職率の高さ」「リリースの延期」といった現場の問題解決に心理的安全性がなぜ効いたのか。心理的安全性を創出したプロセスと失敗から学んだ教訓など、現場担当者の視点を対談形式でお伺いします。
■自己紹介（左から）
- CAMPFIRE プロダクトマネージャー 久津 佑介（ひさつ・ゆうすけ）さん
印刷会社でエンジニア、開発会社でエンジニアチームのマネージャーを経て、2019年に株式会社CAMPFIREに入社。プロダクトマネージャーとして、新規サービス開発のマネジメントなどを行う。 - アジャイルライダー 長沢 智治（ながさわ・ともはる）さん
大手IT企業でソフトウェアエンジニアリングと業務改善の経歴をもち、現在はエバンジェリストやアジャイルコーチとして様々な企業に顧問として携わる。
目次
「お通夜状態な会議」のエンジニアチームを立て直す
長沢：久津さんが2018年に公開した「心理的安全性を0から80ぐらいに上げた話」は、技術者のあいだでとても話題になりましたね。今日はこのスライドをもとにお話をお伺いします。まず、このスライドを作成した当時のお話をお伺いできますか？
久津：私は現在、CAMPFIRE金融事業本部でプロダクトマネージャーを担当しています。この心理的安全性のスライドは、前職のリクルートでエンジニアチームのマネージャーとして子会社に出向して、チームやプロダクトの立て直しをした当時の実体験となっています。
長沢：エンジニアチームの立て直しで出向したということですが、どのような問題が起きていたのでしょうか？
久津：出向先で開発していたアプリが、リクルートの経営戦略で重要である一方で、品質が伴っておらず、立て直しが必要でした。それで私にチームの立て直しの話が舞い込んだのです。
アプリ開発チームは、業務委託先のエンジニアメンバーで構成されていて、アプリのエンジニアが6名、サーバーエンジニアが3名という状況でした。当時の状況としては、製品自体にバグや障害が多い、エンジニアの離職率も高い、リリースも延期になりがちで、とにかく問題が多かったのです。
長沢：問題がいたるところに広がっていたのですね。会議などはどうでしたか？
久津：チームで会議をしても意見がまったく出てこない、まるでお通夜のような状態でした。会議後に裏で聞くと、社内政治的なところで愚痴が出てくるという状況でした。経営者が参加している会議でも本質的な議論は展開されていませんでしたね。
ただ、チームメンバーの責任感や仕事へのやる気はあったので、建設的な会話ができれば改善されると確信していました。
CAMPFIRE プロダクトマネージャー 久津 佑介さん
長沢：出向先に久津さんのチーム立て直しプロジェクトの理解者はいたのでしょうか？
久津：部門は違いましたが、リクルートから企画部門に出向していたメンバーがいたので彼女が理解者でしたね。あと出向先にも同じように課題感を感じていたメンバーと私の上司がいたので、4人でタッグを組んでいました。理解者がいなかったら私自身の心理的安全性を保てなかったでしょうし、中途半端な結果に終わっていたかもしれません。
エンジニアチームが抱えていた「バッドサイクル」という問題
長沢：久津さんは「エンジニアチームビルディングジャーニー」のスライドで、当時のチームが抱えていた状況をバッドサイクルを例に話されていますね。具体的にどのような問題があったのでしょうか？
久津：当時のチームの問題は、ステークホルダー・エンジニアチーム・プロダクトの3つにまたがっていました。
具体的に、ステークホルダーは、プロダクトやエンジニアチームの状況を考慮せずに次々と要望を出したり、ネガティブな緊急の仕様変更を頻繁に依頼したりしていました。そこで起きた失敗はエンジニアチームの責任にする、というバッドな構造ができていました。
そうなると、エンジニアチームのモチベーションもほぼ皆無で、コミュニケーション自体も希薄でした。もともと業務委託で構成されているチームだったので、プロダクト愛はあまりなく「なぜこんなことをやるのか」というスタンスだったので、エンジニアがすぐ辞めてしまっていました。
開発するリソースがないので、プロダクトのバグ・障害の発生につながったり、テストフェーズで機能不備が多発したことで、リリースの延期なども起きていました。
長沢：なるほど、そうした問題がバッドサイクルにつながっていたのですね。
久津：そうですね。『カイゼン・ジャーニー』（市谷聡啓／新井剛 著）という本に「組織の成功循環モデル」が紹介されていますが、バッドサイクルの場合、この循環モデルが「成果が上がらない」という結果の質から始まります。
そこから、対立や押し付けなどの関係の質につながり、おもしろくなく受け身になるという思考の質により消極的な行動になります。最終的に「さらに成果が上がらない」という結果にたどり着きます。
これを改善して、グッドサイクルを回す、というのが私が目指す姿でした。
長沢：バッドサイクルを改善してグッドサイクルを回すために、まずどこから着手しましたか？
久津：まずは、エンジニアと話し合いをして現状把握するところからはじめました。すると、プロダクトの質が低かったり、リリースができなかったりする問題の本質は、エンジニアチームだけではなく、ステークホルダーを含めた組織全体にあるとわかったのです。
ただ、いきなりトップダウンで改善することはできないので、ボトムアップではじめていこうということで「改革」と名付けて、エンジニアチームの課題解決からはじめました。
技術的負債の可視化でステークホルダーから理解を得る
長沢：改革とは、具体的にはどのようなことをしたのでしょうか？
久津：アプリのフルリニューアルプロジェクトをキックオフするために3つの改革のステップがありました。1.外部環境を整える 2.内部環境を整える 3.成長サイクルをまわす というステップです。
長沢：外部環境を整えるためにどんなことをされたのでしょうか？
久津：外部環境である役員や管理職などのステークホルダーには、改革をはじめる前にエンジニアチームを改革することを宣言しました。具体的には「『アプリをスピーディに開発できるチーム』を目指したい」と相手のメリットをきちんと言語化することを意識しました。
さらに、エンジニアチームで起きていたバグの多さに注目して、技術的負債の問題を解消することの重要性をステークホルダーに伝えました。あわせて技術的負債を可視化して、「この期間は新規案件は受け付けられないリファクタリング期間である」ということを伝えました。
エンジニアはプロジェクトの遅延などで一番責められる立場にいるので、とにかくステークホルダーのなかでエンジニアのプレゼンスを上げるようにしましたね。
エンジニアの環境を整備するために、ステークホルダーにメリットを訴求できる「改革宣言」をしたと話す久津さん
長沢：ステークホルダーからの理解を得るために、技術的負債はどのように可視化したのでしょうか？
久津：障害の件数とそれを解決するための工数を可視化するところからはじめました。ツールはFirebaseのような監視ツール、プロジェクトの進捗管理にBacklogも使いました。
改革前は、プロジェクトの進捗管理もグダグダで、課題の期限切れが当たり前で、ちゃんとした運用ができていなかったので、運用ルールは見直しました。
具体的には、期限と担当者は常に最新にする、というルールです。週一の定例会議があったので、期限切れのタスクは「なぜ期限切れになってしまったのか？」理由を必ず尋ねました。
長沢：プロジェクトの進捗管理をしっかりしたことで、エンジニアチームに変化はありましたか？
久津：はい。チームの信頼関係の構築につながりました。心理的安全性を創出したきっかけにもなったと思います。
たとえば「期限日が守れていない」「きちんと運用ができていない」の原因は、作業担当者がタスクの内容を理解できていなくて、期限も想定できない、とりあえず当てで入れたけど変更したいと言えない、ということだったのです。
なので、作業担当者が現実的な期限を設定できるように、課題の詳細欄に「目的（何のためにこれをするのか）」「成果物（最終的なアウトプットイメージ）」を記入する運用に変えました。逆に、記入できないということはタスクの分解が足りていないからだと認識して、私の方で分解しました。
こうした運用を続けたことで、最初は棚卸しができなかったが、次第にできるようになってきましたね。
1on1ミーティングで重視したのは「心理的安全性」
長沢：エンジニアチームの内部環境はどのように整備したのでしょうか？
久津：打ち合わせでまったく発言が出ないけど、裏で聞いてみるといろいろと意見が出てくる、という状況に着目して、チームメンバーのモチベーションと自己肯定感を上げることをに注力しました。
チームのやる気や責任感はあったので、チームメンバーにポジティブなマインドを表に出してもらうようにしました。建設的な議論ができればチームがよくなると確信していたので、メンバーへ信頼感を示して、意思決定を尊重していることを1on1ミーティングで伝えるようにしました。
アジャイルライダー 長沢 智治さん
長沢：組織に不信感を抱いているメンバーの心を開くのはなかなか大変だと思いますが、それはどうやって乗り越えたのでしょうか？
久津：ずばり「傾聴」です。1on1などで相手の不満にとことん耳を傾けました。その上で、私の方で期待していること、期待していないことを具体的に言語化して伝えました。
実務のときはメンバーの仕事には極力口は出しませんでした。「信頼している」と宣言した後に細かくチェックしていたら言行不一致になるじゃないですか。
次に、メンバーから指摘された問題は私の方で解決していきました。たくさん問題を指摘するメンバーもいましたが、そういうクレームも1週間に2回は解決するようにして、少しずつ、信頼関係を築いていきました。「この人は問題を解決してくれる」と認識してもらえると、情報が自然と集まってくるんです。
長沢：1on1はどのように進めていったのでしょうか？
久津：初期の1on1では、チームへの不満や問題に加えて「どういうチームにしたいのか」を聞き出すように意識しました。
エンジニアは「自分の開発スキルを上げることを最優先とするタイプ」と「プロダクトの目的達成を最優先とするタイプ」の主に2つのタイプがいると思うのですが、この質問をすることでどちらのタイプがわかるのです。私のチームでは、後者のタイプのほうが多いことがわかりました。なので、仕事の目的をしっかりとメンバーに伝えるようにしました。
長沢：問題の本質が見えてくる前と後では1on1の進め方が変わっていきそうですね。
久津：はい。問題の本質が見えた次に意識したのは、メンバーの心を開くことです。話してくれそうな人からどんどん情報を集めて、不安や不満の根本の原因は「知らない、分からないこと」にある、というのがわかってきました。
あるメンバーから「マネージャーからの仕事の渡され方が雑だ」という話が出てきたのですが、よくよく話を聞いてみるとそういうわけでもない。問題はメンバー層とマネージャー層の意思疎通がうまくできていないことにあったんです。そこをうまくつないでいくのが私の役目かなというのが徐々に見えてきました。
長沢：1on1を通じて、久津さんの振る舞い方も変えていったんですね。
久津：そうですね。最初はメンバーの危機感はあまり高くなくて「アプリの開発を助けてくれる人が来た」というような感じだったので、プロジェクトマネージャーとしてどうやってそこを認識してもらえるかは考えました。反発自体もまったくなかった訳ではないので、そういう人は特に話し合いを重ねるようにしました。
バグ・障害数が9割減！グッドサイクルによる効果
長沢：1on1による小さな改革を繰り返して、内部環境と外部環境を改善していくことで、最終的にチームは変わっていきましたか？
久津：エンジニアチーム内で成長サイクルを回せるようになりました。チームで協力しながらメンバーが自律的に仕事を進めるようになったので、私がチームに介入するのは、難易度が一段高いことに挑戦しようとしたときに丁寧に導くことだけになりました。
長沢：チームの成長サイクルができるとアウトプットやプロダクトにも好影響が生まれそうですね。
久津：まさにその通りで、1年前は散々だったプロダクトも、バグや障害数は9割減り、リリースも予定通り進められるようになりました。
エンジニア間でスキル差を埋めるために、勉強会やモブプロが行われるようになり、離職率も劇的に低下しました。ステークホルダーとの関係も良好になり、「緊急の仕様変更」なども頻発しなくなりました。
グッドサイクルの効果を「バグ・障害数が9割減ったこと」と話す久津さん
長沢：サクセスストーリーですね。久津さんのお話を聞くと、取り組みを開始した時点で「心理的安全性」を意識していたわけではなく、チームの課題を解決していたら結果的に心理的安全性に行き着いた印象があります。
久津：そうですね。最初から問題が内部のエンジニアチームの環境にあるとは思っておらず、Googleが「re:Work」内で提唱する「心理的安全性」は後から知って、当てはまると気づきました。
心理的安全性による弊害「スキルが高いメンバーの独裁」
長沢：エンジニアとステークホルダーの心理的安全性が醸成されるのは良いことですが、心を開いていく過程で、久津さんに要望が集中してきそうですね。
久津：そうですね。言いやすい関係になっていたので、要望や問題提起はどんどん増えていきました。すると、どう問題をさばいて行くかが課題になってきたので、相手の事情とこちらの事情とをうまく折り合いをつけて折衷案を出していましたね。
長沢：心理的安全性を意識した結果わがまま放題の組織になった、というような事例も聞くので、そのあたりのさじ加減は難しそうですね。
久津：そうですね。エンジニアは縛られるのが好きでなく、個性が強い人も多いです。それをまとめるのがマネージャーの仕事ですが、やっぱり負担は大きいと思います。
長沢：他にも心理的安全性が醸成されたことで起きた弊害みたいなものはありましたか？
久津：スキルが高いメンバーの独裁化ですね。アプリチームにとても技術力が高いメンバーが1人いたのですが、その人の発言力が強くて、他のメンバーが何も言えない状態になってしまったんです。一度できあがった心理的安全性が徐々になくなっていく状況です。
その人には発言を控えてもらったり、若いメンバーに仕事を任せてレビューをしてもらったりするようにお願いしたんですが、それもあまりうまくいかなかったんです。個人としては本当に仕事ができる方だったので、その人を残すか、チーム全体の底上げをすべきか悩みました。
最終的には、その方は業務委託だったこと、一人がずば抜けていても、チームで開発を進めた方が長期的には利点が多いと考え、プロジェクトから外れていただく判断をしました。
長沢：スキルが高いメンバーを外してしまうと生産性が落ちてしまうと思うのですが、そういった影響は考慮しましたか？
久津：そうですね。苦渋の選択でしたが、長期的に見るとチーム全体が成長する方が最終的にはプロジェクトがうまくいくと考えました。マネージャーとしてできることは、そういったチームメンバーの要因による生産性の一時的な落ち込みも見込んで、プロジェクトスケジュールを調整することだと考えています。
「組織で取り組まないと持続はしない」心理的安全性の落とし穴
長沢：久津さんは現在CAMPFIREに転職されましたが、プロジェクトから抜けた後もチームは円滑に回っているんでしょうか？
久津：概ね問題はないようですが、まだ課題が残っているという話も聞きます。
私はプロジェクトをマネジメントするときに「マネジメントを始めて2年後には自分がいなくても回る組織」を意識しています。前職のプロジェクトでは、エンジニアチームに関しては、チームメンバーに自分の権限移譲ができるところまで持っていけましたが、他の一部の部門に関してはほぼ手つかずで終わってしまいました。
心理的安全性は一つの部門でできていても意味がないですし、ビジネス全体でできている必要があります。
長沢：ある種の「心理的安全性の落とし穴」という部分でもありますね。
久津：そうですね。心理的安全性が無い方が楽なことって実は多いんですよ。
例えば、自分で考えて意見を言うのってパワーが必要ですよね。人はどうしても楽な方に流れてしまうので「自分で意見を考えてビジネスを動かしていくのが楽しい」と思えるような仕組みを作っていかないと、結局は心理的安全性は持続しないと思います。
心理的安全性が持続する環境では「自分で意見を考えてビジネスを動かしていくのが楽しい」というマインドが必要
過去の成功体験がまったく通用しない状況での葛藤
長沢：前職リクルートでの成功体験をCAMPFIREのチーム作りにどう活かしていますか？
久津：正直なところ、前職の成功体験は活かせていないのが現状です。前職は大手の既存サービスで、CAMPFIREはベンチャーの新規サービスなので、状況や勝手がまったく異なっていたんです。
CAMPFIREでも、前職のリクルートのように「会議で意見が出ない」「目的も不透明な状況だったので1on1を実施したら少しづつ意見が出てくるようになった」という流れは同じでしたが、その後に意見がまとまらないで混乱が起きたんです。
長沢：なぜ前職の成功体験が通用しなかったのでしょうか？
久津：私が所属している部門は、メンバーのバックボーンがバラバラで、エンジニアだけではなく、ビジネス開発のメンバーなど混成しています。
だからこそ、各々で意見が言えるようになったことで、プロダクトづくりではなく、ビジネスモデルやあるべき姿の話に話題が傾いてしまって、プロダクトづくりが進まないという状況が起きてしまいました。新規事業なので誰も正解がわからず、基本的に議論は発散するばかりでした。
長沢：前職と現職では規模感、チーム構成、スピード感が違ったということですね。
久津：そうですね。前職の順番では無いやり方でチームのテコ入れをすべきでした。私一人では収拾がつかず、結局別のメンバーがトップダウンでテコ入れをしました。
前職の私のアプローチとはまったく違う「リーダーがやることを決めて、メンバーにどんどん振っていく」方式です。新規事業の立ち上げでは、個人のスキル設計よりも、とにかく一度アウトプットをだす、というやり方の方が結果的に合っていましたね。
長沢：人のモチベーションや感情的な部分に大きく左右される心理的安全性は、勝ちパターンがないのが難しいですね。
久津：そうですね。私がチームビルディングをするときの参考にしている本に「今いるメンバーで「大金星」を挙げるチームの法則――『ジャイアントキリング』の流儀」というのがあります。
この本では、チームの発達段階を自分の役割を明確にして量をこなす時期のフォーミングと徐々にチームの成果や他のメンバーの成果に目が向くストーミングに分けています。これに照らし合わせるとフォーミングの段階に、ストーミングのアプローチをしてしまったことがうまくいかなかった原因だと感じました。
心理的安全性をチームに創出するのに正解はない
長沢：なるほど。久津さんとお話しして、心理的安全性の創出は、サービスのコンセプトや段階を踏まえることが成功のカギだと感じました。
久津：私自身も今回の経験を通じて実感しました。混成チームだと、メンバーのバックボーンが本当に様々で、前提条件の共通認識がないんです。
それに加えて、新規事業でサービスがそもそもリリースされていないので、仮説だらけで判断基準がなく、それ自体が不安を生み出すんですよ。実際、9月11日にプロダクトマネジメントをしていた「CAMPFIRE Owners」をローンチしたのですが、ある程度回してみてから目指すチームの姿を考えようとしています。
ただ、それはある意味、しようがない部分なのかなとも感じています。新規事業という括りもそうですが、クラウドファンディングという市場自体がまだまだ若いので、がちがちに目的を決めて動いてしまうと2、3ヶ月後に通用しなくなってしまうというのはあるんですよ。また、新しい人材も急に必要になるので、バックボーンはどうしても揃わなくなってきます。
前職はある意味整った組織だったので、現職とのこうした違いも楽しんでいこうと思います。
(執筆/山田モヤイ 企画・編集/井上美穂)
■ この記事を読んだ方にこちらもおすすめ
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com