コーチングだけでは越えられない場面
100スキありがとうございます！
励みになります！
これは、開発チームのリーダーとして悩んだ話です。
マネジメントや育成について学んでいると、「コーチング」「信頼関係」「心理的安全性」といった言葉によく出会います。
Googleのマネジメント講座などでも、部下の考えを引き出すこと、結果だけでなくプロセスに対してフィードバックすること、まず信頼関係を築くことの重要性が語られています。
私自身も、その重要性はよく理解しています。
雑談で普段から話せる関係を築いたり、よくあるコーチングテクニックで考えを引き出したり、目指したいキャリプランを加味したフィードバックしたり、いろいろ試してみています。
しかし、実際の現場では、それだけではうまくいかない場面もあります。
今回書きたいのは、開発チームのリーダーとして後輩育成に向き合う中で、「本人を育てたい」という思いと、「足元のプロジェクトを成功させなければならない」という責任の間で葛藤した経験です。
きれいなマネジメント論ではなく、現場で実際に迷いながら、最終的にどう考えを整理したか。
私自身、まだ正解を持っているわけではありません。
それでも、同じように後輩育成やチーム運営で悩んでいる方にとって、何かしら考える材料になればと思い、書いてみます。
後輩に、アプリ開発全体を見られる人になってほしかった
私は現在、開発チームのリーダーをしています。
私のチームでは、Webとネイティブアプリの両方を開発・保守・運用しています。
私は主にWeb全体とアプリのバックエンド(外注管理含む)を見ており、チーム内にはネイティブアプリのフロントエンド(外注管理含む)を担当している後輩メンバーもいます。
彼には、将来的にアプリ開発全体を見られる人材になってほしいと考えていました。
ここで言う「アプリ開発全体」とは、単にフロントエンドとバックエンドの製造だけではありません。
フロントエンドとバックエンドの接続、リリースまでの一連の流れ、企画チームとの認識合わせ、進捗管理やスケジュール管理、影響範囲の把握なども含めた全体感です。
背景として、企画側からの課題感もありました。
アプリ開発について、フロントとバックを含めて全体を把握している窓口が唯一でないのでやりづらい。
いま何がどこまで進んでいて、何に詰まっていて、いつリリースできそうなのかが見えにくい。
本来は、全体把握と情報共有はリーダーである私の役割です。
ただ、後輩本人にもより広い役割に挑戦したいという意向があったため、徐々に役割を拡張していく方針としました。
ただし、そのゴールを目指そうとすると、まだまだギャップがあるのが現状です。
ギャップは、エンジニアリングの技術やプロジェクト管理のスキル的な部分だけではありません。
非エンジニアとのコミュニケーションにおける翻訳力や、適切なホウレンソウの粒度とタイミング、個人のタスクの優先順位付けなど、ソフトスキル面でも伸びしろがあります。
これらを含めて、一旦のゴールとして「開発と企画との定例において、フロントエンドだけでなく、バックエンドの進捗やリリース予定まで説明できる状態」を目指そうという方針にしました。
この目標をベースに、後輩メンバーが次のステップに進むための機会にしたいと考えていました。
最初は、コーチングで向き合おうとした
今あるギャップを埋めるアクションを決めるため、私はできるだけ本人の考えを聞こうとしていました。
目標達成に向けて足りないことは何か
それらを解決するには何が必要か
進めるにあたってのボトルネックは何か
これらを、私が答えを提示するのではなく、後輩メンバー本人がどう考えているかを毎週の1on1のなかで
「どう思う？」
「もっと詳しく聞かせて？」
「具体的には？」
「まとめると？」
などの質問を駆使して引き出そうと試みていました。
しかし出てくる答えは、企画側の要件整理や優先順位付けなど、外部要因に関するものが中心でした。
もちろん、それらも実際に重要な課題です。
一方で、私としては「その状況の中で、自分たちはどう動けるか」まで引き出したかったのですが、なかなかそこまで踏み込めませんでした。
これは、私のヒアリング力・コーチング力が弱いのだと思い、私の上長にアドバイスを求めました。
すると、「フィードバックは行動の結果だけではなく、行動の過程に対して行うべきだ」というアドバイスをいただきました。
これはGoogleが提唱するSBIモデルに近いものだと理解しました。
たとえば、何かの伝え方が分かりにくかったときに、単に「この言い方は分かりにくい」と指摘するのではなく、
なぜその伝え方をしたのか
そのとき相手は何に困っていると捉えていたのか
その返答で相手は次に何を判断できると思ったのか
といった形で、本人の思考プロセスを聞くのが良いということです。
なので、目標に向けてのアクションを考える際も、その思考過程に重きを置いて掘り下げるのが良さそうだと考えました。
以上の方針は、コーチングや信頼構築の考え方としては間違っていないと思います。
頭ごなしに否定せず、本人の認識を確認する。
どうすれば次により良くできるかを一緒に考える。
関係性を壊さずに、成長につなげる。
私自身、これまでの社会人生活のなかで、事細かに指示されたり強く叱られて伸びたという感覚があまりありません。
自分の上司も、その上司も、細かく指示したり叱るタイプではなく、どちらかと言えば本人の意思を尊重して自分で考えさせるタイプでした。
だからこそ、私もできるだけ穏やかに、本人が納得できる形で育成したいと考えました。
しかし、現場では問題が進行していた
私は闘病のためにしばらく休職しており、その間は私の上長・後輩メンバー・他部署からの製造サポートメンバーでモバイルアプリの開発を進めていました。
その体制のときから、後輩メンバーはフロントエンドの責任者として、他のメンバーや外注さんにタスクを振ったり、成果物のレビューを実施したりしていました。
私が復職した直後もその体制で上手くやってくれていそうだったので、私の方でマイクロマネジメントはせず、全体の進捗やスケジュール感だけ把握するようにしていました。
先ほどあった後輩メンバーの役割を拡大するという育成方針を実現するにあたって、彼の業務量やボトルネックを把握し、溢れないように調整する必要があると考えました。
そこで、改めてチームメンバーそれぞれと1on1を実施して、現場の課題をヒアリングしていきました。
すると、とある実態が見えてきました。
当時の体制では、プロジェクトマネジメント、特にタスク管理の仕組みが十分に整っていませんでした。
ざっくり2か月規模の開発において、基本設計時に大まかな作業分担は決めていました。
しかし、それぞれの担当者に具体的に何が残っているか、今はどこを進行中なのか、当初スケジュールに対して進んでいるのか遅れているのか、これらを判断できる状態にはなっていませんでした。
本人としては、こういう言い分がありました。
残タスクを洗い出すこと自体に工数がかかる。
すでに余裕のないスケジュールなので、そこに工数を割きたくない。
進捗を細かく可視化すると、差込み対応などで時間をとられ思うように進んでいない現実と向き合うことになり、心理的な負荷が高い。
正直、その気持ちも分かる部分もあります。
プレイヤーとして実装も抱えている中で、管理に時間を使うのはしんどい。
特にスケジュールに余裕がないときほど、「管理している暇があるなら実装したい」と思ってしまうのも自然です。
ただ、リーダーの立場としては、そのまま進むのはかなり危険であると判断しました。
残タスクが見えていなければ、そもそも間に合うかどうかを判断できない。
間に合うかどうかが判断できなければ、スコープ調整することも、企画と優先度を相談することも、サポートメンバーとの分担調整や他チームとのリソース調整をすることもできません。
最悪のシナリオは、順調と言っておきながらリリースターゲット間近になってから「間に合いませんでした」となる可能性です。
チームの信用を損なうため、これは避けなければいけません。
実装面でも、進捗や品質が見えにくい状態がありました。
PRがまとまって後半に出てくることでレビューが重くなったり、指摘事項の対応が後ろ倒しになったりして、結果としてリリース前の不確実性が高まっていました。
一方で、これを見てリリースターゲットに強い危機感を持ち、実作業を巻き取ろうとしてくれているメンバーもいました。
この構図は、かなり危ういです。
誰かの負荷を下げようとした結果、別の誰かの善意に任せて負荷が寄っている。
プロジェクトの不安だけでなく、チーム内の不公平感も生まれ始めている。
ここで私は、かなり悩みました。
一番悩んだのは、「育てたい」と「間に合わせたい」の板挟み
私には、チーム内のメンバーにより広い役割を担えるようになってほしいという思いがありました。
後輩メンバーには将来的に、アプリ全体を見られる人材になってほしい。
そのためには、否定や指摘されて受動的に動くのではなく、現状の課題を自ら把握し打ち手を自身で考えられる流れが必要だと思っていました。
一方で、プロジェクトは待ってくれません。
企画側からすれば、中長期的な育成は開発側でやってほしい。
まずは、足元のプロジェクトが本当に間に合うのかを見えるようにしてほしい。
しごく当然の話です。
今振り返ると、私は「育成」と「プロジェクト成功」を同じ土俵で考えすぎていたのだと思います。
育成のために任せたり考えさせたりすることは大事です。
しかし、任せた結果としてプロジェクトの進行が不安定になり、別のメンバーに負荷が寄り、企画からの信頼も落ちるのであれば、それはリーダーとして・組織として・事業として成功とは言えません。
私が成すべきは何か、そこを改めてシャープにする必要があると感じ始めました。
第三者の言葉で、自分の甘さに気づいた
この件について、妻にも相談しました。
すると、かなり厳しいことを言われました。
「その人は進捗がないのが可視化されるからメンタル的にきついとか言っている場合ではない」
「会社員なのだから、リーダーから必要だと言われたことは責任を持ってやるべき」
「本人の事情を聞くことは大事だけれど、あなたがそれをはっきり伝えられずに必要な基準まで曖昧にしてしまうと、結果的にチームの他の人に負担が寄るのではないか」
正直、耳が痛かったです。
自分でも、どこか分かっていたことでした。
けれど、本人の気持ちも分かる。関係性も壊したくない。強く言いすぎて、やる気をなくされたり、辞められたりするのも怖い。
でも、その結果として、別のメンバーが残業で巻き取っている。企画側が不安不満を抱えている。プロジェクト全体の見通しが立たない。
それなら、優しくしているつもりでも、それは甘えかもしれない。
ここで考えたのが、「叱る」と「怒る」は違うということでした。
感情をぶつけることは必要ありません。
人格を否定することも必要ありません。
ただし、職務上必要な期待値に届いていないことは、曖昧にしてはいけない。
優しくすることと、甘くすることは違う。
本人を尊重することと、基準を下げることも違う。
この線引きは言葉としては理解していたものの、あらためてその重要性に気付かされました。
育成とプロジェクト成功は、分けて考える
周囲からも、メンバーの成長に期待する声はありました。
その成果を測る指標として、直近のプロジェクトの成功を見るのはどうかと提案をもらいました。
しかし最終的に、私はこう整理しました。
プロジェクトの成功は短期。
メンバー育成は中期。
この2つは、分けて考える必要がある。
今動いているプロジェクトについては、リリースターゲットに間に合わせることを最優先とする。
そのために、私自身が進捗管理や要件整理に入る。
一方で、後輩メンバーには今は製造に注力してもらいながら、私がどう進捗管理し、どう要件を整理し、どう企画と認識を合わせるかを見てもらう。
つまり、「任せて育てる」段階から、一度「型を見せて育てる」段階に戻すことにしました。
(これは、育成を諦めたわけではなく、育成の順番を変えるということです。)
守破離で言えば、まだ「守」の型がない状態で、「破」を求めてしまっていたのだと思います。
まずは、リーダーである自分が型を作る。
その型を見せる。
型に沿って動いてもらう。
その後で、少しずつ任せる範囲を広げていく。
最初から「自分で考えていい感じに進めてほしい」と期待するのは、本人にとっても難しかったのかもしれません。
こちらが期待値を明確にしないまま、自走だけを求めてしまっていた面もあったと反省しました。
今回実施することにした具体的なアクション
プロジェクトの成功を最優先としたので、その達成に向けて私が決めたアクションは大きく7つあります。
1. タスク分解の推進
タスク分解自体に工数がかかるため後回しになりやすい状態でしたが、進捗を正しく把握するには不可欠です。
そこで後輩メンバーにゼロからすべてのタスクを洗い出してもらうのではなく、企画仕様書をもとに、私が画面単位でのタスクリストの叩き台を作ることにしました。
そのうえで、どれが終わっていてどれが残っているのか、判断しやすい形にチーム内で適宜切り分けてもらうようにしました。
2. 進捗管理のフォーマット
タスクは、単に未着手・作業中・完了で見るだけでは不十分だと感じました。
今回は作業ステータスを以下で振りました。
完了
作業中
残 Must
残 Want
作業中と残タスクについては、毎日の朝会のなかで以下をヒアリングするようにします。
不明・不安・課題となるポイントは？
企画の判断待ちになっている箇所は？
これにより、見積もり時点で積んでおいたバッファを食いつぶしそうなのかどうかを、作業者視点で言語化してもらいます。
3. リリースターゲットの整理
企画側へのコミュニケーションとしては、具体的な開発作業の課題ではなく、以下を整理する必要があります。
見積に対して進んでいるか遅れているか
企画側でハンドリング可能な要素はなにか(要件詰めやスコープ調整など)
それらを織り込んで最終的にいつリリースできそうなのか
企画側と話す前に、開発側でタスク状況とリリース見通しを整理する時間を設けるようにしました。
企画との定例の前に30分時間をとり、チームに対して、俯瞰したタスク状況の認識が合っているかどうかを確認し、リリースターゲットに対する確度を主観ベースでヒアリングしました。
XX月XX日リリース：かなり難しい
理由・課題：〜〜〜
対策：〜〜〜
XX月XX日リリース：順当に進めば可能
XX月XX日リリース：余裕をもって可能
このように整理することで、開発側のタスク分解・進捗状況を、企画側が知りたい情報の粒度に変換しました。
4. 差し込みタスク優先度の認識合わせ
開発現場では、大きな施策開発のほかに、スポットでの運用作業(問い合わせ対応、不具合対応、調査タスクなど)が差し込まれます。
それによって本丸施策がどれだけ影響を受けるのか可視化できておらず、すべて最優先で次々に差し込まれる事態が発生していました。
差し込みタスクが発生した場合は、一旦、開発メンバー全員に見えるところにリスト化する。
作業が特定のメンバーに偏らないように担当者を調整する。
各タスクを最優先で対応した場合、なにがブロックされ、リリースターゲットにどう影響するか可視化する。
こうすることで、差し込みタスクの負荷を分散しつつ、必要に応じて企画とのスコープ調整や優先度調整をしやすくします。
5. 要件調整フローの改善
差込みタスク以外に、製造に集中しづらくなっていた要因のひとつは、企画や外注先との要件調整コミュニケーションでした。
外注の開発者から寄せられる質問に対して、まず質問の意図を整理し、これは開発側で判断すべきか企画側に判断を仰ぐべきか、企画側へ持っていく場合はどのように翻訳すべきか、各ステップで悩む時間が大きかったようです。
この場合、質問意図理解も企画への接続も、対面・口頭でやりとりした方が早いと判断しました。
いわゆる「15分ルール」を取り入れ、15分考えたり悩んだりしたことは毎日の夕会に持ち込み、口頭で会話するルールにしました。
口頭ですり合わせたことを、テキストでログとして残しておくイメージです。
6. PR運用の見直し
製造の進捗や品質を見えるようにするため、リリース直前にPR(プルリクエスト)を出すのではなく、着手時点でDraft PRを作る運用にします。
これまでは、一通り製造しきってからPRを出す運用となっていました。
実装者のペースで進められる反面、一度の差分が大きいことでレビュアーの負荷が上がったり、クリティカルなレビュー指摘が遅れることで手戻りが膨らんだり、リリーススケジュール次第ではレビュー指摘を修正しきれずに負債が溜まることもありました。
早期にPRを出して細かくレビューすることで、レビュアーの負荷を下げつつ、実装者が早めの軌道修正をできるようにし、さらに製造の進捗状況や詰まっているポイントを把握しやすくするのが狙いです。
7. レビュー基準のすり合わせ
レビュー指摘がボトルネックとならないよう、コーディングルールや思想をすり合わせる場を設けました。
まず、チーム内でペアプロを行なうことで、レビューより前の段階で思想のずれを無くしたり、レビュー後には指摘の意図を正しく理解するようにしました。
次に、別のチームも含めたレビュー会を実施することで、チーム内のオレオレルールではなく、会社組織として満たすべき品質基準の意識を揃えるようにしました。
さらに、以上で出てきた内容や既存のコーディングルールをできるだけドキュメント化し、人によって判断がぶれにくい状態を目指しました。
コーチングは大事。でも、万能ではない
今回の経験を通じて、コーチングの重要性を否定したいわけではありません。
本人の考えを聞くこと。
プロセスに対してフィードバックすること。
信頼関係を築くこと。
心理的安全性を大切にすること。
これらは、今でも大事だと思っています。
一方で、コーチングだけでは足りない場面もあります。
特に、まだ型がない人に対して、いきなり自走を求めるのは難しい。
本人に考えさせる余白を作ることは大事ですが、その前提として、何をどう見ればよいのか、何を管理すべきなのか、どの水準なら十分なのかという型が必要です。
型がない状態で「考えてみて」と言っても、本人は迷います。
迷った結果、重要なことが抜け落ちたり、必要以上にスタックしてしまう。
それを周囲が善意で巻き取る。
そして、問題が表面化しにくくなり、余計に迷いを生む。
このループは、チームとしてかなり危険です。
心理的安全性とは、楽しくわいわいやって責任を曖昧にすることではない。
優しさとは、基準を下げることではない。
「今の状態では、プロジェクトの見通しが立たない」
「このタスク管理は、リーダーとして必要な水準に届いていない」
「このままだと、別のメンバーに負担が寄ってしまう」
こうしたことを、感情ではなく、事実と影響として伝える。
これが、リーダーとして必要なことだと学びました。
リーダー自身も、育成されている
今回の件はむしろ、私自身がリーダーとして試された経験だったと思っています。
私は、叱ることが苦手です。
できれば穏やかに進めたい。
本人の言い分も聞きたい。
納得感を持って動いてほしい。
これが行き過ぎると、必要な基準を曖昧にしてしまう。
本人にとっても、チームにとっても、かえって不親切になる。
優しく育てたいと思うなら、なおさら、どこまでは期待しているのかを明確にする必要があるのだと感じました。
育成には、コーチングだけでなく、時には型を見せるようなティーチングも必要です。
そして、型が身についてきたら、少しずつ任せる範囲を広げていく。
ティーチング、コーチング、デリゲーション。
どれか一つが正解なのではなく、チームとメンバーの状態やプロジェクトの状況に応じて切り替えることが大事なのだと思います。
今回、私はその切り替えがうまくできていなかったことが反省点です。
任せるべきタイミングだと思っていたけれど、実際にはまだ型を見せる段階だった。
育成のために任せているつもりが、結果として周囲の善意に支えられていただけだった。
ここに気づけたことは、自分にとっても大きな学びでした。
まとめ
マネジメントや育成の理論は、どれも大事です。
コーチングも、信頼関係も、心理的安全性も、軽視してよいものではありません。
私自身、これからも大切にしていきたい考え方です。
ただし、現場ではそれだけでは足りない場面があります。
プロジェクトには期限があります。
企画側の期待があります。
一緒に働くメンバーの負荷もあります。
誰かの善意で問題が吸収され続けている状態は、長くは続きません。
育成とプロジェクト成功は、どちらか一方を選ぶものではない。
ただし、時間軸は分けて考える必要がある。
短期では、プロジェクトを守る。
中期では、人を育てる。
そのために、今は任せるのではなく、型を見せる。
型を守れるようになってから、少しずつ任せる。
今回の経験を通じて、私はこう整理しました。
後輩を育てるつもりで向き合っていたはずが、実際には自分自身もリーダーとして育てられていたのだと思います。
きれいな理論を、現場でどう使うか。
どこまで任せ、どこから介入するか。
優しさと甘さを、どう切り分けるか。
これからも、きっと同じような場面に何度も出会うはずです。
そのたびに迷いながらも考え行動し、少しずつリーダーとして成長していきたいです。
