※この記事は 2024年09月03日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。
チームリーダーとしての責任
Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手を動かすことでチームに貢献できていていた私にとって、チームづくりははじめての経験でした。
プロセス改善！改善！改善！
前述の通り、当時の私は技術面でのリードはしてきた一方、チームづくりに関してはずぶの素人でした。「チームの状態づくりには何が必要だろう？」というところからのスタートでした。自分なりに考えたのは「標準化」でした。誰が開発しても、一定以上のパフォーマンスで品質・速度を担保できる状態を作ることがカギだと考えました。そこで取り組んだのが「プロセスの仕組み化」でした。
開発する中で出てきた課題に対して、技術的な仕組み化はもちろん、人間が手を動かす具体的なプロセスにもチームに提案し、取り組んでいきました。以下はその一部です。
Pull Request(以下PR) が本番環境にデプロイされるまでの時間短縮を目的とした ペアプログラミング（以下 ペアプロ）やモブプログラミング（以下 モブプロ）を中心にした開発
見落としやすい不具合がないかを確認するチェックリストを PR テンプレートに追加。「テストケースを洗い出したか」「API の破壊的な変更を考慮しているか」など
PR で何を動作すべきかの標準化を目的としたコードの変更に合わせたテストタイプ(ユーザーストーリーテスト／リグレッションテスト／アドホックテスト／シナリオテスト)の使い分けをガイドライン化（こちらは QA が主導して取り組んでくれました）
当番制で 毎週 Datadog 上の RUM（Real User Monitoring。ユーザーの画面操作を録画して確認できる機能）を使い新機能の利用状況を確認したり、APM(Application Performance Management) をみてレイテンシを確認するルール追加
チームのパフォーマンスの計測指標として、Four keys を採用し、毎週チームのエンジニアで確認し、改善案を検討
うまくいった取り組みは継続的にチームに取り入れ、うまくいかないものは別のアプローチを試す。試行錯誤の中、この時の私は、「この調子でプロセスをどんどん改善していけば、チームの動きが変わってき、チームがより効果的に働ける方向に進んでいけるのでは…！」と考えていました。実際、計測していた「デプロイ頻度」や「サイクルタイム(PR の 最初のコミットから本番に変更が加わるまでの時間)」はよくなっているし、変更障害率も低く抑えられていました。
しかし、この良かれと思ってとってきた行動がチームに思わぬ副作用をもたらしていきました。
チームメンバーが感じた「窮屈さ」
私たちのチームでは毎週全員で振り返りを行っていました。一方「全員がいる場では話しづらいこともあるだろう」と考え、エンジニアメンバー全員と月一の 1 on 1 も設定しました。そこでいくつかの懸念が浮かび上がってきました。
「自分のペースで仕事ができない感じがする。ペアプロやモブプロは開発がスムーズに進むんだけど自分のペースで考えられないというか」
「稼働時間が長いわけではないが、どこか仕事にゆとりがないように感じる」
「以前まで 個人的に Datadog をよくみていたけど、当番制になってから自分の意思で確認という気持ちが薄れてしまった」
「チームでやっていることは正しいと思うが、たまに自分には合ってないと感じる」
「なんか自分の強みを活かしきれていない気がする」
少しずつ、フラストレーションが溜まっていることに気づきました。ただ、全員からそのような声が上がっているわけではなく、メンバーの一部だったこともあり、個人に起因する問題なのか、体制の問題なのか私には特定できませんでした。「じっくり考えたい時は、ペアプロ・モブプロではなく、一人で考える時間を確保してみてもいいのではないでしょうか」といった表面的なアドバイスしかできてませんでした。この感覚の真の原因がわからないので、お得意の「プロセスに組み込む」ことができないのです。また、機能のリリース速度はプロセス改善を経ていい方向に進んでいたため、今のプロセスに問題があるから変えよう、というアクションまで起こせませんでした。
そうして根本的な改善に至らないうちに、ついに業務委託のエンジニアの方から「契約終了を考えている」と打ち明けられました。私を含むチーム全員からの信頼がとても厚く、技術的にもチームで一番優れていた方でしたので私はとてもショックでした。そして、自分の起こしてきたアクションが、チームメンバが気持ちよく働けない環境を作り上げてきたことに恥ずかしながらここで気付かされたのでした。
前述の通り、チームリーダーとしての責任は「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。いくら生産性が良くても、チームメンバーにとって気持ちよく働ける環境でなければ、人は離れ、持続的に効果的に働き続けるチームにすることはできません。対応は急務でした。
多様なメンバーが気持ちよく働けるチームになるには
とはいっても、何をどう変えればいいのか、見当もつきませんでした。「新しいプロセスに変えたら、他の人にとって合わないものになってしまうんじゃないか」「これまでやってきた改善プロセスをやめたら、以前の問題が再発して品質と速度が落ちるんじゃないか」「チームのやり方に合っている人だけをチームに集めればいいのか？ でも同質のメンバーを集めたチームがいいとは思えない…多様なメンバが活躍できるチームであることはマストだけど…」と思考がぐるぐる巡って、何をしたらわからない状態でした。今思えば Tebiki社に入ってから、一番気持ち的に落ちていたのがこの時期だと思います。
最終的に、一人で考え切るのは難しいと考え、チーム全員で考えることにしました。「多様なメンバーが気持ちよく効果的に働けるチームになるには」というタイトルでミーティングの場を設け、丸1日分の時間を確保させていただきました。以下のアジェンダで臨みました。
この会のゴールの共有
この会を開こうとした背景の共有
現状抱えている課題の定義（※ここまでの内容は事前に一人一人に個別に説明し、事前合意がされていました。個人とチームの相性の問題ではなく、チームのプロセスに問題がある点は特に認識を合わせました。）
会をうまく進めるためのお約束事の合意
現状のプロセスについてどう思っているかをお互いに知る
現状のプロセスの継続・破棄
破棄したプロセスに替わる新しいプロセスの提案・合意
この会を成功させるために、私は会のファシリテーションに徹しました。なぜなら、これまでのように自分の案や意見を出すことで同じような状態が再発することを恐れたためです。私は、この会できまったプロセスをもとに動く開発者張本人ではありませんでした。自分たちのプロセスを自分たちの意思で納得感のあるものにしてもらいたいという意図がありました。私は、メンバーに問いかけ、意見を引き出し、対立があれば相互の意見とメリットデメリットを整理し、また別の道がないか考えてもらう、といった行動をとりました。(ちなみに、チームリーダーになる上で辞書のように参照していた「ファシリテーションの教科書」という書籍がとても役に立ちました。)
ミーティングの趣旨を説明するために実際に使われた資料（個人名はマスキング、一部整形しています）
ファシリテーションの教科書―組織を活性化させるコミュニケーションとリーダーシップ
ファシリテーションとは、会議や議論で参加者・チームの意見をどう引き出し、より良い結果を導き出せるか、そのマネジメントの手法である。著者は、大手企業やビジネススクールで数多くのファシリテーションを行い、ファシリテーターの「プロ」育成も手がけて…www.amazon.co.jp
丸一日かけて試してみたい新プロセスを考え、全員が合意しました。明らかになったのは、「自分が良かれと思って取り入れたプロセスの意図が正しく伝わっていなかったこと」「意図は理解していたが、そのプロセスが最適だとは思っていなかったこと」「一律のプロセスにすると、時に過剰なケースがあるので、固定するのべきではないこと」などでした。もうボコボコですね。率直に意見してくれたメンバーと、Tebiki社のカルチャーには感謝しかないです。
Tebiki社のカルチャー。共感できるメンバーが集まっているからこそ、建設的な会話がいつもできています。
この会で、チーム内で納得感の薄いプロセスはたくさん破棄されていきました。決まり事が減り、個人の裁量で判断するゆとりが増えました。特にTebiki社の看板でもあったペアプロを中心とした開発も破棄し、ソロ中心で開発、選択肢としてペアプロ・モブプロを選べる状態になりました。
ペアプロをチームが選択する意義について立ち返った。ペアプロ以外のやり方でもメリットを享受できる道を見つけられた。
その後どうなった？
契約終了を検討されていた業務委託の方に「新しいプロセスで、もう少し試してみませんか」とお伝えしたところ、承諾してくださりました。また、「一人で考えるゆとりが確保できるようになった」といった声も聞くことができるようになりました。
一方、いいことばかりではありませんでした。慣れないプロセスになったり、開発している内容に依存する部分もありますが、Cycletime は倍以上に伸び、 デプロイ頻度 は半減したり、リリース計画が後ろにずれ続けたりと、チーム外の人から見たチームのパフォーマンスが一時的に落ち込みました。破棄されたプロセスが持つ効果性が失われたことや、慣れないプロセスによるものがチームとして効果的に働ける状態を損なった要因の一部であると考えています。このような課題があったとき、私個人でまた改善プロセスを提案するのではなく、チームで課題について理解を深め、チームで解決策を導き出していきました。持ち直すまでの間にもいろいろなことがありましたが、それは別の機会で記事にできればと思っております。
この記事を書いている現時点では、パフォーマンスは持ち直し、チームメンバーも増え、プロセス改善前以上に、プロダクト価値を高めていける効果的なチームになったと思っています。また、これは私の感覚ですが、以前よりもチームメンバーによる課題提起や活発な議論が増えたような印象があります。これは、メンバーが自ら考える「ゆとり」とやるべきことへの「責任」を取り戻していくことができたことが起因しているのではと考えています。逆に言えば、それらを私が奪ってしまっていたとも言えます。同じ状態に戻らないよう、同じことを繰り返さないような行動を心がけています（本当にできているかは自分でもわからないです…）。
最後に私の学びを整理してこのブログを締めていこうと思います。
今回の失敗①: 責任を果たすべき人からプロセスを奪ってしまっていた
私は、このチームでは開発者としての活動ではなく、チームの状態づくりがメインの仕事でした。しかし、開発者のプロセスを主体的に変えていくよう動いていました。つまり、自分と異なる役割を持つ人のプロセスに対するオーナーシップを奪い取ってしまったのです。結果として、チームに合っていないプロセスでメンバーを縛ってしまい、チームが気持ちよく効果的に働ける状態を奪ってしまいました。アジャイルについて書籍で学んだり、Certified ScrumMaster の研修を会社に受けさせてもらったにも関わらず、チームの自律性を奪い、アジャイルでない状態にしてしまったのです。
現在は、「この状態でこのまま進むと、こんなことが起きるのでよくない」といった問題提起はしますが、チームでどう対処していくか、プロセスを変えるのか、今は許容するのか、といったことはメンバーと話し合いながら決めていくことを徹底しています。多少時間がかかっても、チームの納得感を大事にしています。
そしてもう一つ「Try」という価値観もチームでは大事にしています。Try は KPT などの振り返り手法でも使われています。私たちのチームでは、「期待する結果を生むか試しにやってみたい取り組み」というものを 「Try」 と呼んでいます。改善案に対し、常にチームメンバーの意見が満場一致するわけではありません。やってみないとわからないこともある中で、満場一致でなければ試せない環境では細かい検査と適応ができません。これではチームの改善の機会損失をし停滞が続いてしまいます。私たちのチームでは毎週の振り返りで、チームメンバーが気軽に Try としてやりたいことを決めることができるようになっています。翌週の振り返りの時間で、その Tryに対し「期待通りの効果は見込めたか」「これからも取り組みたいか」といった有効性をチーム全員で検査し、別のTryをしてみたり、有効なものはルール化したりします。
チームメンバーが自らの責任を果たすために自らプロセスを改善していけるチーム状態をこれからも守っていきたいと考えています。
今回の失敗②: ルールが人に及ぼす力学を理解していなかった
チームメンバーとの 1 on 1 に出てきた「以前まで APM や ユーザーモニタリングを個人的に見ていたが、チームでみるプロセスがルール化されてから自分の意思でみようと思わなくなってしまった」という話ですが、調べてみると心理学で「アンダーマイニング効果」が当てはまることがわかりました。
行動を持続的に遂行するには、その行動自体に魅力を感じること、いわゆる内発的動機づけが不可欠である。内発的動機づけが報酬のような、その行動に随伴する外的制約によって低下する現象は「アンダーマイニング効果」と呼ばれる。 Juming JIANG1, Ayumi TANAKA2. ”個人特性がアンダーマイニング効果に及ぼす影響”. 2017. https://www.jstage.jst.go.jp/article/pacjpa/81/0/81_1D-071/_pdf/-char/ja（参照 2024–8–25）
今回の場合、自発的にお客様の利用状況をモニタリングし、チームに共有したり、パフォーマンスチューニングをしてくださっていたメンバーの内発的動機を、プロセスを強制されるという外発的動機が奪ってしまったのです。
現在は、各メンバーの役割を果たすべき責任（What）となぜそれを果たすべきか（Why）の部分はチームで合意し、責任をどう果たすか（How）の部分にはできるだけ干渉しないよう心がけています。メンバーが結果責任をどう果たせていない場合はプロセスを変えるのではなく、現状を率直にフィードバックし、チームとして今後どう果たしていくと良いかなど対話を重ねることで責任を果たせるよう支援していくことにしています。この動きにまだ慣れておらず、うまくできているか自信はないですし、これが正しい保証もないですが、今はこれが答えだと思って取り組んでいます。
ちなみに、ルールが及ぼす影響に関しては 江崎貴裕さんの 「数理モデル思考で紐解く RULE DESIGN -組織と人の行動を科学する-」という書籍でルールが人間の行動に及ぼす影響についてたくさん言及されています。書籍を読むのが苦手な私でも大変読みやすい内容でした。 数理モデル思考で紐解くRULE DESIGN -組織と人の行動を科学する- Amazon.co.jp: 数理モデル思考で紐解くRULE DESIGN -組織と人の行動を科学する- eBook : 江崎貴裕: Kindleストアwww.amazon.co.jp
まとめ
今回は、自分の失敗談と学びを共有させていただきました。突き詰めると、アジャイルソフトウェア宣言の「プロセスやツールよりも個人と対話を」の部分が重要という話に行き着くのかなと思っています。プロセスも大事だが、それ以上に個人との対話をより重視すること、これを損ねてしまっていたのではないかと思っています。
ケーススタディの一つとして学びある内容になっていたら幸いです。同じ悩みがどこかで一つでも解消されたらこの記事を書いて成功だったのかなと思います。
私たちは仲間を募集しています！
現在、エンジニア、人事、デザイナー、営業のポジションを積極採用中です。
今回「自分も同じような課題をチームで感じててちょっと意見交換したいな」「〜って書いてるけど、こういう時はどうしてるの？」「俺ならもっといいチームが作れるぜ！教えてやろう」そんなことを少しでも思ってくださった方、ぜひ私とカジュアルにお話ししましょう！(そうでない方以外の方も大歓迎です！) Tebiki株式会社 の全ての求人一覧 Tebiki株式会社 の全ての求人一覧です。herp.careers
