情報伝達タスク、意思決定者のボトルネック…　エンジニアチームを“膨張→成長”導く2つの方針3つの施策

エンジニアが倍になっても成果はあがらなかった

保立馨氏（以下、保立）：よろしくお願いします。保立と言います。今日はチームビルディングの話をできればと思います。

資料はTwitterに載せましたが、緊張し過ぎてちょっと載せるのが早すぎたかもしれないので、探してください。ふだんはRailsとAndroidアプリのエンジニアをしていて、「kakari」というサービスと、「kakari for Clinic」というサービスを開発しています。チームのエンジニアを統括していて、マネジメントの視点から、今日の発表をできればと思います。

チームビルディングの話をするので、僕のチームの現況について説明します。フルリモートになる前、2020年の2月末は、エンジニアが6人の小規模チームでした。そこから1年3ヶ月の現時点（2021年5月末）で、エンジニアが倍以上になり、かなり大きなチームになりました。

チームが大きくなればどんどん開発が進むのか、というとそうでもなく、最初はいろいろな問題が出てきました。情報伝達のタスクが多いとか、1日中ミーティングしていてぜんぜん開発ができないとか。人が増えても成果があがっていないのでは？　という問題がありました。

この資料ではそれを「膨張するチーム」と説明します。対比して「成長するチーム」にどんどんしていこうということで、どう違うのかを紹介します。そのあとに、そのためにやった方針2つと、施策3つを紹介します。

膨張するチーム

メンバーが増えてチームが拡大するときには、ただ人数が増えている“膨張”と、質の向上も伴う“成長”の2種類があります。まず“チームの膨張”のほうは、僕の経験からいうと、タスクを振る人とタスクを振られる人に完全に分かれてしまい、タスクを振られる側は、ただ自分の作業をやるだけで、自発的に課題発見が行えない状況でした。

あとは、小さなチームのときから意思決定する人が変わらずに、チームがどんどん大きくなり、意思決定することがどんどん増えてくることで、意思決定者がボトルネックになる問題がありました。これを改善した「成長」するチームになると、各自がプロジェクトの目的を認識して、自ら課題を見つけて解決する様になります。

僕のチームでも、メンバーが増えたら適切に権限委譲を行い、意思決定者がボトルネックにならないチームにしてきました。

成長するチーム

“成長するチーム”をもう少し詳しく見ていきます。意思決定、課題発見はチームの全員ができるようにしたい。権限は、メンバーが増えたりメンバーが成長したら常に最適化して、どんどん権限委譲を促していきたい。コミュニケーションも特定のキーマンが忙しくなるのではなく、職種や経験の垣根を超えて、各自でコミュニケーションが取れるような状態にしたいという思いがありました。

コミュニケーションの部分は、特にリモートワークだとなかなか難しいです。対面でコミュニケーションを取りたい場合は、相手の予定などを見て、予約を埋めなければいけません。コミュニケーションを取るのに時間がかかって、情報が局所化されて、課題などがなかなか共有されず、自発的に課題発見、問題解決がしづらい問題があります。

あとはマネージャーをやっていると、“自分がやったほうが早い”が永遠のテーマだと思います。コミュニケーションを取るのにも時間がかかって、メンバーを教育するのにも時間がかかってとなると、なかなか権限委譲しづらい問題が出ると思います。そのため、リモートワーク環境でチームが拡大したときは、今まで以上に膨張を防ぐことを意識しなければいけません。

成長するチームを作るための2つの方針

方針と施策について紹介します。まず方針を2つ決めました。1つ目は「自発的に課題解決する動機づけを行う」です。全メンバーがサービスに対して当事者意識をもち、自ら課題を発見して問題解決する姿勢をもってもらいます。2つ目は「意見を出しやすい環境を作っていく」です。課題発見するための情報提供をして、その課題を共有、議論できる場を用意しました。では具体的にどんな施策をしたかを見ていきます。

1つ目の施策「行動指針からの目標設定と適切な権限委譲」

1つ目の動機づけでは、1on1で行動指針から目標を設定して、適切な権限を渡すことをやっていきました。“目標設定”というと、よくあるケースでは「キャリアプランから目標を決めていくのがいい」という話があると思っていて。僕もそれをやってみましたが、たぶん力不足もかなりの要因があり、うまくいったケースもあれば、うまくいかないケースもありました。

うまくいかないケースとしては、僕もそうですが、キャリアプランがころころ変わる場合があげられます。ふだん意識していなくて、節目などでしか思い出さないケースが該当します。キャリアプランは変わるものだということを許容して、目標を設定して動機づけをしないといけません。

より不変的、かつチーム全員が共感できる何かをベースに動機づけをしていく必要があったので、僕は会社の行動指針に目をつけました。こちらがメドピアの“Credo”という行動指針です。1on1や目標設定、あとはその目標の振り返り面談などは、Credoにある“当事者意識をもって課題解決していきましょう”というところを軸に、いつも話すようにしています。

そこにその人のやりたいことや得意なこと、興味あること、挑戦したいことを紐づけて目標設定したり、アサインを決めていくようにしました。興味があることや挑戦したいことは1ヶ月後とかには変わるケースもよくあると思いますが、自分から当事者意識をもって課題解決するところをベースにやっていきましょう、と。

興味があることや挑戦したいことが変わっても、そこはぶらさずにやりましょうということでコミュニケーションを取っています。

2つ目の施策「意見の出しやすい環境の醸成」

続いて、2つ目の意見を出しやすい環境の醸成です。自ら課題解決する動機づけができても、そこから「どんな問題があるか」という現在の状況を共有したり、何か課題が思いついて発信できる場を用意をする必要があります。

施策の2つ目は「意思決定の理由をなるべく共有する」です。「どうしてこの機能を開発するのか」がわからないと、その機能に対する改善案などがなかなか出せないのがエンジニアリングだと思います。どうしてこの機能を開発するのか、を深く理解するためには「どういうニーズがあるのか」もわかっているとなおよいです。もっと「ニーズに直結しているのはこういうことじゃないか」というのが提案しやすくなります。

実装も同様で、どうしてそれを導入したのかがわからないと、変えることはなかなかやりづらいと思います。そのため、新しい機能を追加したり、新しいライブラリを導入したりするときは、GitHubのissueや、技術的な部分であれば、プルリクエストとかコミットコメントなどでなるべく共有することをチームとして心がけています。

3つ目の施策「課題の共有・議論の場の作成」

施策の3つ目は「課題を共有・議論する場を作る」です。これはKPTのようにまとめてふり返るかたちではなく、専用のSlackチャンネルを作成して、業務中にふと発見した課題や改善案を、誰でも気軽にすぐ発信できる場を用意しました。それが#just_ideaチャンネルと、#dev_team_kaizenの2つです。

#just_ideaはプロダクトに関することです。些細なことでもつぶやけるようにしています。#dev_team_kaizenはどちらかというとプロジェクトのに関することです。開発フローや会議体、いろいろな開発に関わる部分、フローに関わる部分などです。

「実績」に今までの実績は書いていますが、#just_ideaはプロダクトに関することでいろいろ投稿しやすいと思うので、2営業日にだいたい1回ぐらい誰かしらつぶやいて、議論していたりします。

KPTとかだと決まった時間で議論を終えないといけないと思いますが、Slackの専用のチャンネルにすることで、興味がある人でワイワイ議論しやすい。投稿が流れてしまうことも専用のチャンネルだとなかなかないと思うので、じっくり議論できるのがいいところだと思います。

というようなかたちで施策を3つして、自ら課題を考えて、周りに共有して議論できるという場を設けられたのかなと思います。ご清聴ありがとうございました。

質疑応答

司会者：ありがとうございます。質問がいくつかきています。「1on1などで動機づけをしていくなか、目標設定などのあたりで、定量的に何かできるようなことはありますか？」。

保立：なるほど。まず、その人がどういったものをやりたいかを共通認識としてもちます。例えば「開発をどんどんしていきたい」とか、「パフォーマンスをどんどんよくしていくことに興味がある」「企画の部分に興味がある」とか。僕のチームにもいろいろなパターンの人がいますが、僕は定量的に定めるのはそこまで意識はしていなくて、とりあえず何をやるか。

どちらの方面に向かうかをとりあえず定めてもらって、チーム全体に共有する。「そこは俺に任せろ」「アサインを振ってくれ」みたいな状態にはとりあえずしています。できれば定量的にやる、というぐらいです。

司会者：そうですね。僕もけっこうそんな感じです。評価するときに、定量的な評価軸をけっこう重要視しがち、定量しやすい量を設定しがちなので、メドピアではそのあたりを注意しています。「バグ数などを入れないでくれ」と僕はよく言います。

他に意見の出やすい環境作りのところで、「意思決定の理由をシェアしていく」みたいな話があったじゃないですか。これはどういう頻度でシェアしているんですか？

保立：そうですね。技術的な開発に関わる部分であれば、ふだんの開発から変更した理由や、参考にしたリンク。そういったものはコミットコメント、もしくはプルリクエストの本文に載せていくことを徹底しています。

あとは週次でサーバーサイドとミーティングをしたり、モバイルアプリは週に2日やっていますが、共有したいことや悩んでいることを共有することで、議論できるようにして、議事録を残していくのをやっています。

機能の部分のほうは、その機能開発をするタイミング。要件定義が降ってきたタイミングでみんなで議論して、それをissueに残していく感じのことをやっています。

司会者：確かにコミットログやプルリクエストなどに残っていると、あとから入ってきた人もわかりやすい。

保立：そうですね。

司会者：あと「#just_ideaや#dev_team_kaizenであがってきたものの、棚卸はしているんですか？」と。

保立：Slackだと、その都度議論になります。なので棚卸をあまりする必要がなくて。例えば#just_ideaだと、チケットを起票するか・しないかでいったんゴールが決まるので、その場でパッとみんなで議論して、何人かでやっていく感じです。

#dev_team_kaizenのほうは、もし修正が必要となったらissueを切るなり、修正チームを作るみたいないろいろはありますが、その場で初動は決まって。棚卸をするのは今まで1回もないですね。

司会者：なるほど。

保立：その場で誰が何をするか、もしくはissueを切るのがゴールだったら、issueを切ると決まっちゃう感じです。ぜひやってみてください。

司会者：棚卸はしていないと。ありがとうございます。あとは「スクラムですか？」。

保立：スクラムではないです。

（一同笑）

保立：アジャイルチックという感じで。

司会者：よく聞くやつだ。

（一同笑）

司会者：なるほど。わかりました。では時間になったので、ありがとうございました。

保立：失礼します。ありがとうございました。