ボロボロのチームを立て直したエンジニアリングマネージャーのお話
久津（@Nunerm）です。リクルートでPM/EMをやってます。
この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。
普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。
さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど…
今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。
※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。
序章：ボロボロのチームにジョイン
とある事情で「チームとして機能していないスマホアプリ開発チーム」の立て直しをすることになりました。まずはどれくらいボロボロだったのかを説明します。
客観的事実を列挙します。
- バグ・障害の発生頻度が多すぎる
- テストフェーズで機能不備が多発しリリース延期が続出
- 仕様がブラックボックスすぎる
- iOSとAndroidの意図しない機能差が多い
- エンジニア間のコミュニケーションが皆無
- エンジニア間のスキル差が大きすぎて権威勾配が大きい
- エンジニアがすぐ辞めてしまうのでナレッジが貯まらない
特に１つ目が深刻で、バグFIXのためのリリースを１つすると、新しいバグが２つ増えていつまでたっても障害対応から逃げられないような状況でした。にも関わらず次から次へと企画部門から開発案件が降って来て、それを無理やり対応するからまたバグが混入する…といった負のスパイラルが発生していました。それを繰り返していたためエンジニアのモチベーションもどん底状態でした。まさにボロボロです。
とにかく問題点が多すぎて「どこから手をつければいいんだ…？」と途方に暮れながらも１〜２ヶ月とりあえずもがいてみました。すると少しずつボロボロになってしまった原因と打ち手が見つかってきました。
そして１年以上にも渡る「立て直しプロジェクト」の幕が開いたのです…！
第一章：外部環境を整える
1-1.改革の宣言・ブランディング
まず外部環境の整備から始めました。外部環境というのは、開発チームのステークホルダーである営業部門や企画部門、コーポレート部門などの組織との関係性です。
チーム改革の実行中は周りにそれなりに迷惑をかけます。ただでさえバグ対応で手一杯で依頼された案件をまともに受けられていなかったのに、今まで以上に案件を受けられなくなります。よって事前にそのことを伝える必要があります。「改革に伴いご迷惑をおかけするかもしれませんがご協力くださいm(_ _)m」的な。
またその際に同時に「どういう開発チームを目指すのか」を言語化してブランディングしました。
自分の場合は「継続的進化をするチーム」という目標を掲げました。要はステークホルダーの方々に「今後はどんどんアプリもチームも良くなって案件をたくさん受けられます」と、改革による直接的なメリットを訴えて協力を仰ぎました。
1-2.意思決定プロセスの整備
開発チームがボロボロだったのは紛れもない事実ですが、同時に組織全体の案件や戦略の意思決定プロセスにも大きな問題がありました。
開発チームに案件依頼として降りてきても、途中で何度も仕様変更が発生したりリリース直前で急遽延期になったりしていました。それが市場変化にスピーディに対応するような「ポジティブな仕様変更」であればよいのですが、ただの検討漏れだったり調整不足に起因する「ネガティブな仕様変更」だったため、エンジニアのモチベーションを大きく下げる一要因となっていました。
これではせっかく開発チームの改革を行っても決して良い開発はできません。なのでこちらにもテコ入れし、開発チームに依頼が来る前の企画部門の意思決定プロセスの可視化とシンプル化を行うことで、無駄な仕様変更や方針変更を最小限にすることができました。
詳細は長くなるので割愛しますが、別記事でまとめているのでよろしければご参照ください。
productmanager55.hatenablog.com
1-3.技術的負債の可視化と解消によるメリットの説明
バグ地獄から抜けられない最大の原因が「技術的負債の肥大化＋ブラックボックス化」でした。ソースコードが汚すぎる上に誰も作りや仕様を把握していないので、何をするにも調査から始めないといけません。これが丸１日かかったり、調査が不十分で結局また新たなバグを埋め込んでしまって再びバグ地獄に突き落とされたり…ここに関しては1~2ヶ月もがいてみても光明が差す気配が感じられませんでした。
これはリファクタリングというレベルではどうしようもなさそうなので、フルリニューアルすることを決めました。
となると、より一層長い期間新しい案件は受けられなくなります。営業がせっかく受注を取ってきても企画部門が新しい戦略を立ててもアプリでは何もできない。これはビジネスにとっては一大事です。
なので「技術的負債の可視化と解消によるメリットの説明」を丁寧に行いました。
可視化といっても、コードの品質を計測するツールを使って数値化したりはしていません。度重なる障害のおかげで品質が悪いことは全員わかっていたので、ここの可視化にはそれほどパワーをかけずにすみました。過去の障害の原因を深掘りして、技術的負債が起因しているものを列挙したぐらいです。
メリットの説明は、中長期的に見てこのタイミングでのリニューアルが後の事業成長の最大化につながることを訴えました。つまり「大きくジャンプする前にはしゃがみ込みが必要なんだ」ということです。これはただのハッタリではなく、その時点で既に大きなプロジェクトの予定が決まっており、それを迎える前にリニューアルしない限りそのプロジェクトが失敗する確信がありました。 なので熱量を持って説明することができ、おかげで周りを納得させることができました。
これらの「外部環境の整備」を事前にやっておくことで、改革に集中することができ、かつ周りの協力を得ることも可能になりました。
第二章：内部環境を整える
2-1.メンバーへの信頼を示す
兎にも角にもエンジニアのモチベーションを上げることを最優先としました。モチベーションが低い状態では改革は進まないと思ったためです。
私の前任マネージャーが強権政治・マイクロマネジメント・エンジニアに意思決定をさせないタイプのマネージメントを行なっていました。実装方法までエンジニアに指示をして、気に入らない書き方だと叱責をするようなタイプでした。
それによってエンジニアが萎縮してしまっていたため「エンジニアに意思決定をさせる」ことを目指しました。「組織に使われている」という意識から「自分で決めている」という意識へのシフトチェンジです。
そのためにマネージャーである私からメンバーへの「信頼」を示し、メンバーの意思決定を尊重する姿勢を全面に出しました。
信頼を示すために実施したことは２つ。
- 具体的に信頼していることを相手に伝える
- メンバーの仕事に極力口を出さない
信頼は形として見えないものです。いくら内心で信頼していたってそれが相手に伝わるとは限りません。逆に「信頼してるよ〜」と調子いい感じで伝えるだけだと、口だけであることが必ずバレます。
なので各メンバーの仕事のうち、具体的に「何を信頼しているのか」と「何には期待していないか」を伝えました。例えば「○○さんはドキュメント作成は苦手だから期待しないけど、コーディングは信頼しているよ」みたいな感じです。もちろん自尊心を傷つけない範囲でです。
信頼していると宣言した後に、その仕事に対して細かくチェックしていたら言行不一致になってしまいます。よってその仕事には極力口を出しません。元々私もエンジニアなので、ソースコードレビューとかしたいタイプなんですが我慢しました。もちろん質問や不安ごとの相談には乗りますが、こちらから細かいチェックや小言は言いません。
それによって最初は問題も起こります。メンバー個人のスキルへの依存度が高くなるため、凡ミスによる障害も多々発生しました。ただこれも「産みの苦しみ」として耐えました。これには時間と勇気と我慢が必要です。
2-2.チームビジョンの再定義
1-1.で行なったブランディングをチーム内部に向けても行いました。
「継続的進化をするチーム」を目指すこと、逆に推奨されないこと、そのチームになるためのアイディアをいつでも受け付けることなどをキックオフで高らかに宣言しました。
2-3.多様な内発的動機と向き合ってくすぐる
1on1を繰り返して、各メンバーの内発的動機を確認しました。
内発的動機とは、給料や地位などではなく、自主性ややりがい、成長などを仕事の動機にすることを言います。
ダニエル・ピンクの著書「モチベーション3.0」という本では＜モチベーション3.0＞という言葉で内発的動機を定義しています。
＜モチベーション3.0＞には三つの重要な要素がある。一つは＜自律性＞。自分の人生を自ら導きたいという欲求のこと。二番目は＜マスタリー（熟達）＞。自分にとって意味のあることを上達させたいという衝動のこと。三番目は＜目的＞。自分よりも大きいこと、自分の利益を超えたことのために活動したい、という切なる思いのことだ。
1on1で各メンバーの内発的動機が「自分の意思で仕事を決めたい」（＝自律性）なのか、「技術力を高めたい」（＝マスタリー）なのか、「意味のある仕事をしたい」（＝目的） なのかを見極めました。
それに応じてインプットの仕方を変えました。
自律性タイプのメンバーには"Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決められるようにする。
マスタリータイプのメンバーには"Why/What/When"をインプットして極上の"How"をアウトプットすることを期待する。
目的タイプのメンバーには"Why"を丁寧にインプットして"What"を一緒に考えてもらう。
※私はPMも担っているので"Why"の定義をメンバーに委ねることは絶対にしません。それはPMの責務として明確に区別しました。
このような感じで、各メンバーの多様な内発的動機をくすぐりながらモチベーションを上げ、最終的にはパフォーマンスを上げることに成功しました。
2-4.心理的安全性の担保
心理的安全性はGoogleのre:Workというサイトで以下のように説明されています。
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。
効果的なチームを作る５つの要素で最も根幹となる重要な要素です。
心理的安全性の担保に関するアプローチに関しては広木さん（@hiroki_daichi）の神記事が最近世に放たれたので、そちらに丸投げしますw
ここでは具体的に実施した小さい取り組みの積み重ねを箇条書きで列挙するに留めます。
- ミーティングではとにかく明るく振る舞う
- メンバーの話を聞くときは顔を見て聞く（キーボード打ちながらは絶対NG）
- 問題をチームで解決する場を作り「もしこれでも解決しなかったら○○さんに声かけて」「○○さんはその時こう助けてあげて」と、具体的な解決方法まで提示してあげる
- メールやチャットでは即レス
- もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に言う
- メンバーから出てきた意見はしっかり拾って、必ず何かしらの答え（採用するか見送るか）とその理由を伝える
- 定期的にライトな1on1を行う（大々的に「不満を言え」と仕立てると、他のメンバーがどういう不満を言ったのかも気になってしまうので、こっそり聞くのが良い）
第三章：自ら成長できるチームへの変貌
3-1.チームのカオスエンジニアリング
この言葉はEMFMのep7の中で出てきました。
一度あまりにも忙しくて、申し訳ないなと思いながら普段自分がやっている仕事をメンバーに丸投げしてみたら、あっという間にメンバーができるようになりました。全然自分がその仕事を持つ必要がなく、メンバーがやってくれた方が圧倒的にスピードが早かったことがわかりました。
このように「役割と仕事分担」や「会議やミーティング設計」を一度意図的に壊してみると、無駄が除去されてパフォーマンスが上がったりします。断片化したハードディスクのデフラグみたいなイメージですね。これを定期的に行うと、メンバーからも無駄の指摘が出やすくなります。
EMFMの中でも「会議を一切やらない週を作る」とか「マネージャーが定期的に長期休暇に入る」とか具体的な方法が出てきました。これは一度聴くことをオススメします。
3-2.階段を刻み、踊り場で遊ばせる
この言葉は「無理・無意味から職場を救うマネジメントの基礎理論」という書籍からの引用です。
これはメンバーを成長させるための機会の与え方を表しています。
まず「階段を刻む」。
メンバーを１階から２階に上げる為に、どのくらいの高さ（＝難易度）と歩幅（＝導き方の丁寧さ）の階段を用意するかが重要です。難易度が高すぎたり導き方が雑すぎる最初から諦めてしまうし、逆に難易度が低すぎたり無駄に導き方が細かすぎたりすると意義を感じられなくなります。
適切な高さと歩幅の階段を、各メンバーのスキルや特性、内発的動機に合わせて作って上げる必要があります。
次に「踊り場で遊ばせる」。
メンバーが階段を順調に上ったら、すぐに次の階段を上らせるのではなく、達成したレベルの範囲内で遊ばせる、つまり自由にやらせます。前の階段で得られたスキルを応用することでスキルの装着度が高まります。マネージャーの責任の範囲内で周りやユーザーに影響の出ない範囲の「踊り場」を用意し、その中では自由に遊ばせることでモチベーションの向上とスキルアップの両方を実現することができます。
終章：１年後…
このような様々な取り組みを約１年続けた結果、今は大変いいチームになっています。
朝会ではメンバーが積極的に意見を言い合い、そこで出た意見は[Try]というタグをつけてチケット起票され、メンバーが自発的に改善活動をし、週一回の振り返りでは「もっとこうしてほしい」といった文句も出る。
しかもこのミーティングは私はファシリテートしていません。ただコーヒーを飲みながら眺めてニヤニヤしているだけです。
まさに「継続的進化をするチーム」ができてきました。
そして結果も出てきています。
まずプロダクト（アプリ）が大きく改善されました。リニューアルは成功しブラックボックスは解消、その後の大きなプロジェクトも先日リリースされました。今は２週間に一度のペースでリリースを行うことができているし、ステークホルダからの開発依頼にもスピーディに応えられています。
もちろんまだまだ改善点はあります。もっと開発スピードは上げないといけないし、もっとメンバーから出たアイディアを実現する流れを作らないといけません。が、１年前と比べると見違えるような変化です。
実際にはこの改革が合わなくて辞めたエンジニアも数人います。改革の途中ではメンバー同士の喧嘩が怒って空気が最悪になったりもしました。ただそういう辛さも乗り越えて作り上げたこのチームに誇りを感じています。
今はメンバーが楽しそうに仕事をしている姿を遠くからニヤニヤして見ている時間が楽しくて仕方がありません。そんな時「エンジニアリングマネージャーって面白いなあ」と思います。
気づけば6千字を超える長文になってしまいました…！
読んでいただいた方には感謝申し上げます。
多くの方からフィードバックをいただきたいので、もし少しでも面白いと思っていただいたらSNSでシェアして頂けると助かります。そして何かご意見なども頂けると嬉しいです。TwitterでのDMもお待ちしております。
明日はnaosim_さんの記事です！お楽しみに！
