グロースエクスパートナーズグループのリレーブログ企画2日目担当の岡田です。
前回の記事は「/speckit.next という発想」でした。
まだご覧になっていない方は、ぜひそちらもチェックしてみてください！

はじめに

今回は、エンジニアリング経験のないメンバーを対象に実施した3か月間の育成を、日常的な支援やフィードバックを行ったリーダーの視点から振り返ります。

今回の育成は、次の3名で進めました。

メンバー：育成対象者
- 入社後、UI/UX設計に関する業務を1年間経験
- HTML、CSS、JavaScriptは学習済み
リーダー：日常的な支援やフィードバックを行う筆者
マネージャー：週次2on1に参加し、必要に応じて説明の補足や心理的なフォローを行う

育成の目標は、単にソースコードを書けるようになることではなく、開発チームの一員として、必要な確認や相談を行いながら、自分が担当するタスクを完了まで進められるようになることでした。

そのために、次の2つに取り組みました。

「目標・現状・手段」を育成シートに整理する
週次2on1で育成シートを振り返り、メンバーとリーダーの認識差をすり合わせる

本記事では、育成シートと週次2on1の運用方法を、CIエラーへの対応をきっかけに認識をすり合わせた事例とともに紹介します。

「自分で進める」に対する認識が異なっていた

育成を始めた当初、メンバーは開発タスクを、渡された内容に沿って実施する「作業」として捉えているように見えました。

また、技術的な細かい部分を含めて、すべて自分一人で理解し、解決できなければならないと考えていました。

一方、リーダーとして期待していたのは、すべての技術を一人で把握することではありませんでした。

最初に目指していたのは、次のような状態です。

タスクの目的を理解する
現在の状態を調査する
完了までに必要なことを整理する
不足している情報を周囲に確認する
自分で調べることと、相談することを使い分ける
必要な確認や報告を行いながら、タスクを完了まで進める

既存コードや一般的な技術については、検索やAIエージェントを使うことで効率的に調査できます。

一方、案件固有の仕様や過去の経緯は、リーダーや他のメンバーに確認した方が早く解決できる場合があります。

そのため、すべてを一人で解決することではなく、利用できる手段を組み合わせながら、自分が担当するタスクを完了まで進めることを重視しました。

ただし、「もっと自主的に動いてほしい」と伝えるだけでは、具体的にどのような行動が求められているのか分かりません。

リーダーが考える「自主的」と、メンバーが考える「自主的」が同じとも限りません。

そこで、リーダーが期待する状態とメンバーが認識する現在地を明文化し、その間を埋める行動を育成シートに整理することにしました。

育成シートを作成した

最初に、育成期間を通して使用する育成シートを作成しました。

育成シートは、「目標・現状・手段」の3つの要素で構成しました。

項目	内容
目標	育成期間を通して、できるようになってほしいこと
現状	現在できていることや、これまでにできるようになったこと
手段	現状から目標へ近づくために実践すること

育成シートは、次の順序で作成しました。

リーダーが「目標」を書き出す
メンバーが「現状」を書き出す
メンバーから「現状」を共有する
リーダーから「目標」を共有する
リーダーが「手段」の案を書き出す
メンバー、リーダー、マネージャーで内容を確認する

リーダーが先に目標を説明すると、メンバーがそれに合わせて現状を書いてしまう可能性があります。

そのため、目標と現状はそれぞれ個別に整理した後、メンバーから先に現在地を共有しました。

育成シートは、フロントエンド、開発プロセス、コンピテンシー、UI/UXなどの分類に分けて整理しました。

フロントエンド開発に関しては、既存のマスタ情報一覧画面を題材として、たとえば次のような内容を設定しました。

項目	例
目標	タスクの修正範囲を整理し、必要な確認や相談を行いながら完了まで進められる
現状	UIとコードの関係を少しずつ追えるようになったが、問題が発生した際に一人で抱えやすい
手段	処理の流れを整理し、実施したこと、不明点、次に確認したいことを書き出す

育成シートの「手段」には、このほかにも次のような内容を設定しました。

VueファイルとPiniaのstoreが担う役割を整理する
修正内容を画面側とstore側に分けて書き出す
サブタスクの作業内容と順番を整理する
現在の状態が分かるように作業ログを残す
間に合わない可能性がある場合は早めに共有する
エラーが発生した場合は、一つ試したうえで相談する

育成シートを運用するうえで注意したのは、「手段」を実施すること自体を目的にしないことです。

たとえば、作業ログを書く目的は、決められた形式を埋めることではありません。

現在の状態や実施したことを整理し、タスクの状況を正しく把握できるようにすることが目的です。

そのため、手段を実践できたかだけでなく、その結果として育成シートの目標に近づいているかを継続的に確認する必要がありました。

週次2on1で育成シートを振り返った

育成シートは、最初に作成して終わりにはしませんでした。

週に1回、30分の2on1を実施し、育成シートに設定した目標と手段に対する実践結果を振り返りました。

2on1は、基本的に次の流れで進めました。

メンバーとリーダーが「やったこと」と「つぎやること」を書く
メンバーから先に内容を共有する
リーダーが自分の記載内容を共有する
両者の認識が異なる部分を確認する
次に取る行動を合意する

その場で振り返りを書く

最初の5分間で、メンバーとリーダーが育成シートを見ながら、それぞれ振り返りを書きました。

メンバーは、その週に実践したことと、次に実践することを書きます。

リーダーは、次の2つの視点から書きました。

リーダー自身が支援のために行ったこと
メンバーの行動に対する観察やフィードバック

事前に準備する形式ではなく、同じ時間に同じ育成シートを見ながら書くことで、その時点での認識を比較できるようにしました。

メンバーから先に共有する

共有は、メンバー、リーダーの順で行いました。

先にリーダーが話すと、メンバーがリーダーの見方に合わせてしまう可能性があります。

メンバーから先に共有してもらうことで、本人が自分の行動や現在地をどのように捉えているかを確認してから、リーダーの見方を伝えられます。

ここでは、単なるタスクの進捗報告ではなく、育成シートに設定した目標や手段に対して、何を実践できたかを説明してもらいました。

記載内容の違いを確認する

双方の共有が終わった後、認識が異なっていた内容を中心に話しました。

たとえば、次のような違いです。

メンバーは手段を実践できたと考えているが、リーダーは目標につながっていないと考えている
メンバーは技術的な問題と捉えているが、リーダーは確認や報告の問題と捉えている
タスクの完了状態に対する認識が異なっている
次に実施しようとしていることが、育成シートの目標からずれている

認識差があった場合も、リーダーの考えを一方的に正解として伝えるのではなく、なぜそのように考えたのかを説明しました。

そのうえで、育成シートの目標に近づくために、次にどのような行動を取るかを合意しました。

時間が余った場合は、メンバーが困っていることや、リーダーに支援してほしいことも共有してもらいました。

マネージャーは基本的に聞き役となり、説明の補足や、フィードバックが厳しく伝わった可能性がある場合の心理的なフォローを行いました。

CIエラーを通して「自分で解決する」の意味をすり合わせた

週次2on1で認識差を確認した具体例として、CIでエラーが発生した際の出来事を紹介します。

起きたこと

メンバーがソースコードを修正してプッシュしたところ、CIでエラーが発生しました。

しかし、メンバーは必要なコードの修正が終わったことで、実装作業自体は完了していると考えていました。

そのため、CIエラーが残った状態でPull Requestのレビューを依頼していました。

リーダーからCIでエラーが発生していることを共有し、エラーを解消するよう依頼しました。

メンバーとリーダーで、問題の捉え方が異なっていた

その後の2on1で、メンバーは次の内容を「つぎやること」として挙げました。

インデントについて、フォーマッタの部分がうまくできていなかったため、改めて設定や動作について確認・調査したい。

メンバーは、今回の出来事をフォーマッタに関する技術的な問題として捉えていました。

そのため、自分でフォーマッタの設定や動作を調べ、仕組みを理解して解消しようとしていました。

この行動自体は間違いではありません。

しかし、リーダーが問題だと考えていたのは、フォーマッタの知識だけではありませんでした。

リーダーは、自分自身に対する「つぎやること」として、次の内容を書きました。

「実装が完了している」とはどのような状態なのかをすり合わせる。

また、メンバーに対しては、当初次のように記載していました。

CircleCIでのエラーに関しては、まだ解消できていないと思うので、適宜相談してもらえたらと思います。

しかし、これでは「CIエラーが出たら相談する」という個別の指示にしかなりません。

そこで、育成シートの目標につながる、より上位の考え方として次のように修正しました。

いきなりすべてを一人で解決するのは難しいので、現状を把握し、必要な情報を整理したうえで、適切に報告・連絡・相談する。

「実装完了」の条件を共有した

メンバーは、必要なコードを書いたことで、実装が完了したと認識していました。

一方、リーダーは、少なくともCIを通過し、他のメンバーがレビューできる状態まで進んでいることを、実装完了の条件として考えていました。

ただし、CIの仕組みや、チームとして何をもって実装完了とするのかを、リーダーが十分に説明できていなかった点にも問題がありました。

そのため、「CIエラーを直してください」と伝えるだけでなく、次の内容を共有しました。

コードを書き終えることだけが実装完了ではない
CIを通過し、レビューできる状態にする必要がある
エラーを解消できない場合も、現在の状態を共有する必要がある
問題が残っている状態でレビューを依頼する場合は、その内容を明示する

これにより、個別のエラー対応ではなく、チームにおけるタスクの完了状態をすり合わせました。

「自分で解決する」の範囲を共有した

メンバーは、エラーの原因を自分ですべて調べ、仕組みを理解したうえで解消しなければならないと考えていました。

一方、リーダーは、最初からすべてを一人で解決する必要はないと考えていました。

一定時間は自分で調査する必要があります。

しかし、経験のない仕組みについて長時間悩み続けることが、必ずしもタスクの完了につながるとは限りません。

分かる人に前提を確認すれば、その後の調査を自分で進められる場合もあります。

そこで、「最後まで一人で解決すること」ではなく、次のような進め方を共有しました。

現在起きていることを確認する
自分で分かる範囲を調査する
試したことと分からないことを整理する
必要に応じて、分かる人へ相談する
得られた情報を使ってタスクを完了まで進める

重要なのは、すぐに答えを聞くことでも、最後まですべてを一人で抱えることでもありません。

タスクを完了させるために、どの時点で、誰に、何を共有する必要があるかを判断することです。

その後の変化

この2on1以降、エラーが発生した際に、一人で長時間抱え続けることが減りました。

自分で調査しても解決できない場合には、現在の状態、確認した内容、試したことを整理して相談してくれるようになりました。

表面的にはCIエラーへの対応に関するフィードバックでしたが、実際にすり合わせたのは、次のような考え方です。

何をもってタスクを完了とするか
自分で調査する目的は何か
どの時点で周囲に相談するか
相談するために、どのような情報を整理するか

育成シートを週次2on1で継続的に振り返っていたことで、今回だけの対応方法ではなく、今後のタスクにも利用できる考え方として共有できました。

実施して分かったこと

抽象的な目標は、共有するだけでは認識が合わない

育成シートに「できるようになってほしいこと」を記載しても、その言葉をメンバーとリーダーが同じ意味で理解しているとは限りません。

たとえば、「自主的にタスクを進める」という言葉だけでも、次のように解釈が分かれます。

すべてを一人で解決する
相談せずに作業する
自分から必要な確認を行う
周囲を活用しながら、完了まで責任を持つ

抽象的な目標を育成シートに記載するだけで、認識差をなくすことは困難です。

実際の行動を振り返りながら、「今回の行動は育成シートの目標に近づいていたか」「リーダーは何を期待していたか」を継続的に確認する必要がありました。

双方が振り返ることで、考え方の違いが見える

メンバーだけが振り返りを書く場合、本人が気づいていない変化や課題は記載されません。

反対に、リーダーだけが評価する場合、メンバーがどのような意図で行動したのか分かりません。

双方が同じ育成シートを見ながら「やったこと」と「つぎやること」を書くことで、同じ出来事をどのように捉えているか比較できました。

CIエラーの例では、メンバーは「フォーマッタを調査する」という技術面の課題を挙げました。

一方、リーダーは「完了状態と相談方法をすり合わせる」という、タスクの進め方に関する課題を挙げました。

双方の記載があったことで、表面的な行動だけでなく、その背景にある考え方の違いを見つけられました。

行動だけでなく、目的と判断基準を共有する

リーダーから「次はこのようにしてください」と具体的な行動だけを伝えると、メンバーは再び、渡された作業を実施する状態になってしまいます。

そのため、フィードバックでは次の順序を意識しました。

育成シートに設定した目標や、その目的を共有する
リーダーがどのように考えたかを説明する
考え方を実現する行動例を示す
実際に取る行動は、可能な範囲でメンバーに委ねる

たとえば、「30分調べたら必ず相談する」とルールだけを決めると、30分経過したかどうかが判断基準になってしまいます。

本来共有したいのは、次のような考え方です。

一人ですべてを理解することが目的ではない
担当するタスクを完了まで進めることが目的である
自分で調査することも、周囲に相談することも手段である
相談する際には、相手が判断できる情報を整理する

具体的な行動例は必要ですが、その行動だけを固定的なルールにしないことが重要だと感じました。

運用には関係性と評価方法が必要になる

今回の方法では、リーダーからメンバーへフィードバックする機会が多くなります。

両者の関係性が構築できていない場合、目的や考え方のすり合わせではなく、一方的な指示や評価として受け取られる可能性があります。

リーダーは正解を伝える立場ではなく、自分が何を期待し、なぜそのように考えているかを説明する必要があります。

また、メンバーからも、フィードバックに対する意見や疑問を共有できる状態が必要です。

今回はマネージャーにも同席してもらいましたが、マネージャーが参加することで、反対にメンバーが発言しにくくなる可能性もあります。

参加者や役割は、メンバーとの関係性やチームの状況に合わせて調整する必要があります。

また、今回の取り組みでは、確認や報告の仕方に変化が見られた一方で、その変化を客観的な指標では評価できませんでした。

たとえば、次のような項目は計測していませんでした。

一人で問題を抱えていた時間
問題が発生してから相談するまでの時間
質問時に共有できた情報の量や質
タスクの手戻り回数
リーダーからの追加確認回数
育成シートに設定した目標ごとの到達度

今回の成果は、主にリーダーから見た行動の変化をもとに判断しています。

今後同じような取り組みを行う場合は、育成シートを作成する段階で、観察する行動や評価基準も設定しておくと、育成の効果をより説明しやすくなると考えています。

まとめ

今回の育成を通して、未経験者に目標を提示するだけでは、仕事の進め方に対する認識差は埋まらないと分かりました。

特に、「自主的に動く」「自分でタスクを進める」といった抽象的な言葉は、人によって意味が異なります。

そこで、「目標・現状・手段」を育成シートに整理し、週次2on1でメンバーとリーダーがそれぞれの捉え方を書き出しました。

双方の記載を比較することで、個別の作業に対する指摘だけでなく、次のような考え方をすり合わせやすくなりました。

タスクの目的をどのように捉えるか
何をもって完了とするか
どこまで自分で調査するか
いつ、誰に、何を相談するか
育成シートの目標に近づくために、次に何を実践するか

未経験者育成では、正しい行動を一方的に教えることよりも、実際の出来事に対するメンバーとリーダーの認識を言語化し、その違いを継続的にすり合わせることが重要だと感じました。

育成シートは目標を記録するためだけの資料ではなく、メンバーとリーダーの認識差を見つけ、次の行動を方向修正するための共通の基準として活用できました。