1on1 とフィードバック

1on1 を「進捗どうですか」で始めると、その30分はまるごと進捗確認になります。 進捗はデイリーとチケットで分かるので、同じことを2回やっているだけです。

この章では、1on1 で何を扱うのか、そして言いにくいことをどう伝えるのかを、 実際のセリフの形で書きます。

1on1 で扱うもの、扱わないもの

まず、扱わないものをはっきりさせます。ここが混ざると 1on1 は毎回進捗確認になります。

扱わない	どこでやるか
タスクの進捗	デイリー、チケットのステータス
コードの具体的な相談	その場、ペアプロ、チャット
レビュー指摘の内容	PR のコメント
仕様の確認	担当者との個別のやりとり

そのうえで、1on1 でしか扱えないものは次の4つです。

扱うもの	具体的に何を聞くか
困っていること	まだ誰にも言えていない詰まり、聞きにくさ
期待値のズレ	「何ができていれば順調か」の認識差
キャリア・興味	どこを伸ばしたいか、今のタスクとの距離
コンディション	睡眠、負荷、チームへのなじみ具合

共通点は、どれも本人が自分から言い出しにくいことです。 言い出しやすいことは日常の場で流れてくるので、わざわざ時間を取る必要がありません。 1on1 は、日常では出てこないものを拾うために存在します。

とはいえ、新人は 1on1 でまず進捗を話します。それが一番安全な話題だからです。 遮る必要はありません。進捗を入口にして、そこから降りてください。

「その調査、3日かかったって言ってたけど、どこで時間を使った？」

進捗そのものではなく、進捗の裏側にある詰まり方を聞けば、それは 1on1 になります。

頻度と長さ

最初の1〜2ヶ月は、週1回30分を推奨します。慣れてきたら隔週に落として構いません。

時期	頻度	長さ
1〜2ヶ月目	週1回	30分
3ヶ月目以降	隔週1回	30〜45分
異動・担当変更の直後	週1回に戻す	30分

週1回30分は、月に2時間です。これを「忙しいから隔週で」に変えた瞬間、 問題の発見が最大で2週間遅れます。

新人が最初の2週間で作る詰まりは、2週間放置すると詰まりではなく癖になります。 月2時間は、癖になったものを直す時間より確実に安いです。

1on1 の型

毎回ゼロから組み立てると、話しやすい話題だけで30分が終わります。型を決めてください。

時間	やること	主に話す人
0〜5分	コンディションの確認。近況、体調、負荷	相手
5〜15分	相手が話したいこと。困っていること、聞けていないこと	相手
15〜25分	こちらから伝えること。フィードバック、期待値のすり合わせ	受け入れ側
25〜30分	次回までのアクションを確認し、記録に残す	双方

型の要点は2つです。

1. 冒頭は必ず相手の話から始める

こちらの伝えたいことを先に出すと、相手の話題は残り時間に押し込まれます。 そして押し込まれた話題は、たいてい「特にないです」に変わります。

2. 話す量は相手7・自分3

受け入れ側が話し続ける 1on1 は、内容が良くても失敗です。 その30分で、相手が言えなかったことは翌週まで持ち越されます。 「今日はいい話ができた」と受け入れ側だけが満足している回は、だいたいこの状態です。

「困ってることある？」では何も出てこない

この質問は 1on1 で最も使われ、最も機能しません。理由は3つあります。

1. 答えるために、まず自分が困っていると認める必要がある。新人にとってこれは負荷が高い
2. 範囲が広すぎる。何を困りごとと呼んでいいのか、判断基準が本人に無い
3. 「特にないです」が最も安全で、かつ会話が早く終わる。一度成功すると次回も使われる

対策は、範囲を狭め、時間軸を区切り、事実として答えられる形にすることです。

使える質問例

目的	質問
詰まりを見つける	「今週いちばん時間を使ったのはどこ？」
詰まりを見つける	「そのうち、想定より時間がかかったのはどれ？」
聞けなさを見つける	「今、聞きたいけど聞けていないことはある？」
聞けなさを見つける	「今週、誰かの手を止めるのを我慢した場面はあった？」
こちらの改善点を拾う	「私のやり方で分かりにくいところはある？」
ドキュメントの穴を拾う	「読んだ資料で『これ書いてないな』と思った箇所は？」
見積もり感覚を見る	「今のタスク、あと何時間くらいで終わりそう？」
孤立を見つける	「チームの中で、何をしている人か分からない人はいる？」
不安を先取りする	「来週、いちばん不安なのはどれ？」
成長を可視化する	「この1ヶ月で、できるようになったと思うことは？」

どれも「困っている」と認めなくても答えられる形になっています。 時間を使った場所や分かりにくかった箇所は、単なる事実なので口に出しやすいのです。 そして事実を話しているうちに、困りごとの方から出てきます。

フィードバックを SBI で組み立てる

フィードバックが失敗するのは、内容が厳しいからではありません。 人格の評価になっていて、本人が修正のしようがないからです。

SBI モデルは、フィードバックを3つの順番に並べます。

要素	内容	書き方の基準
Situation（状況）	いつ、どこで	日付と場面が特定できる
Behavior（行動）	何をした・しなかったか	録画に写るものだけ
Impact（影響）	それが何を引き起こしたか	誰の、何が、どれだけ

順番が重要です。事実から始めるので、相手は身構える前に状況を思い出せます。

悪い例

「最近ちょっと意欲が低いように見えるんだけど、どうかな」

この一文には問題が4つあります。

• 「意欲」は観測できません。観測できたのは行動だけのはずです
• 事実が無いので、相手は何の話をされているのか分からない
• 反論できない。「そんなことないです」しか返せず、会話が終わる
• 何を変えればいいのかが示されていない

良い例

「先週の火曜、認証まわりのタスクで丸一日手が止まっていたよね（S）。 それが分かったのは水曜の朝会で、火曜の時点では相談が無かった（B）。 こっちが気づくのが1日遅れたので、リリース前のレビュー時間が半日減った（I）。 次からは、30分手が止まったら、状況が整理できていなくても書いてほしい」

最後の1文が依頼です。SBI で事実を共有したら、必ず「次にどうしてほしいか」まで言います。 ここが無いと、相手は「怒られた」という記憶だけを持ち帰ります。

言い換えの練習

よくある言い方	SBI で言い換える
「もっと主体的に動いてほしい」	「先週の計画会で、担当の決まっていないチケットが3件残った（S）。その時に手が挙がらなかった（B）。結果として私が3件とも持つことになって、レビューが半日遅れた（I）」
「コードの品質が低い」	「昨日の PR で、エラーをそのまま握りつぶしている箇所が2つあった（S・B）。本番で起きた時に、ログに何も残らないので原因を追えない（I）」
「報告が遅い」	「水曜に聞いた API の仕様変更、気づいたのは月曜だったと言っていたね（S・B）。その2日、フロント側が古い仕様のまま実装を進めていた（I）」

褒め方

褒めることの目的は、気分を良くすることではなく、良かった行動を再現してもらうことです。 だから「すごいね」「助かったよ」だけでは足りません。何を再現すればいいのか伝わらないからです。

伝わらない	伝わる
「あの PR よかったよ」	「あの PR、変更を3つのコミットに分けてくれていたから、レビューが15分で終わった。あの粒度で続けてほしい」
「調査ありがとう、助かった」	「調査結果に『試したが違った仮説』まで書いてあったから、私が同じ調査をやり直さずに済んだ」
「早いね」	「仕様の確認を着手前に済ませていたから、手戻りがゼロだった」

構造は SBI と同じです。状況 → 行動 → 影響。影響がプラスになるだけです。

褒める場所も重要です。 1on1 の中だけで褒めると、効果は半分になります。

• チームのチャンネルで、何が良かったかを添えて書く
• 朝会やスプリントの振り返りで、名前を出して事実として言う
• 本人がいない場で褒める（回り回って本人に届く上に、チーム内の評価が上がる）

新人にとって、チーム内での立ち位置は不安の大きな部分を占めます。 第三者に伝わる場で褒められることは、チームに居ていいという確認になります。

言いにくいことは、早く・小さく伝える

言いにくいことを溜める理由は、たいてい「もう少し様子を見よう」です。 しかし様子を見ている間に、コストは確実に増えます。

伝えるタイミング	相手にとって何になるか
気づいた翌日	1回の出来事。指摘も軽く、直すのも一瞬
1ヶ月後	すでに癖。「今まで何回もやっていた」という重さがつく
3ヶ月後の評価面談	評価が確定した後の通告。修正の機会が無かったことになる

3ヶ月ためて評価面談で初めて言うのは、フィードバックではありません。 本人から見れば、「知らないうちに減点されていた」という体験です。 このとき失われるのは、その指摘への納得だけではなく、あなたへの信頼です。

伝える時の入り方は、大げさにしないのがコツです。

「1つだけ気になったことがあって、小さいうちに言っておきますね」

小さく伝えるためのルールを4つ挙げます。

• 1回に1つだけ。 3つ並べると、内容にかかわらず人格否定として受け取られます
• 「いつも」「毎回」を使わない。 回数を盛ると、話が事実から感情に移ります。「先週の火曜と、今週の木曜」と言えば十分です
• 質問で終わらせない。 「どう思う？」だけだと、何をしてほしいのかが伝わりません。依頼まで言い切ります
• その場で言えるものは 1on1 まで持ち越さない。 1週間経つと、相手はその場面を覚えていません

期待値のすり合わせ

新人が最も不安なのは、失敗そのものではなく、自分が遅いのかどうか分からないことです。 これは「何ができていれば順調なのか」を誰も言語化していないから起きます。

例として、時期ごとの期待を言葉にすると次のようになります。

時期	順調と言える状態
1週目	環境が動く。1行変えて PR を出せる。詰まったら聞ける
1ヶ月	小さいチケットを、仕様確認から PR まで自分で回せる。30分詰まったら相談できる
3ヶ月	見積もりが出せる。レビュー指摘の大半が軽微になる。他人の PR を読んでコメントできる

これは評価基準ではなく、順調かどうかの目安として渡すものです。 数字にしなくて構いません。言語化して共有されていること自体に意味があります。

そして 1on1 で、ズレていないか確認します。

「今のところ、私は『小さいチケットを1人で PR まで持っていける』状態なら順調だと思っています。 ここ、ズレてますか？」

ズレは「共有していないこと」が原因

期待値のズレを見つけた時、どちらかが悪いと考えると解決しません。実際にはこうなっています。

受け入れ側の前提	新人の前提
30分詰まったら聞いてほしい	半日は自力で粘るのが礼儀だ
分からないところは PR に書いてほしい	分かっていないと思われたくない
見積もりは外れてもいい	外したら評価が下がる
会議では気になったら発言してほしい	何も分かっていないのに発言するのは失礼だ

どの行も、両方とも善意です。どちらも相手のことを考えて行動しています。 問題は片方の姿勢ではなく、前提が一度も口に出されていないことです。

だから「なぜ聞かないのか」ではなく、「30分で聞いてほしい」と先に言う方が早く解決します。

なお、口頭で1回伝えた期待値は、翌週にはまず残っていません。入社直後は情報量が多すぎるからです。 1on1 の記録に書いて、次回の冒頭で参照してください。 「先週話した『30分ルール』、今週は使えた？」と聞くだけで、期待値は具体的な行動に変わります。

記録を残す

1on1 の記録は、次の3つのために取ります。

• 次回に引き継ぐ。 「前回言っていた◯◯、その後どう？」が言えるかどうかで、1on1 の質が変わります
• 評価の時に事実で語れる。 印象ではなく、日付と出来事で説明できます
• 担当が変わっても続く。 メンター交代のたびに関係をゼロから作り直さずに済みます

書式は4行で十分です。凝ると続きません。

• 今日話したこと
• 相手が困っていること・詰まっていること
• 伝えたフィードバック（SBI の形で）
• 次回までのアクション（誰が・何を・いつまでに）

4つ目を必ず書いてください。受け入れ側のアクションも書きます。 「手順書のここを直す」「レビューの返答を翌営業日までにする」など、 こちら側の宿題が記録に残ると、1on1 が一方通行になりません。

この章のまとめ

• 1on1 で扱うのは進捗ではなく、本人が自分から言い出しにくいこと（困りごと・期待値のズレ・キャリア・コンディション）
• 最初の1〜2ヶ月は週1回30分。隔週にすると問題の発見が最大2週間遅れる。短縮はしても延期はしない
• 型を決める。冒頭は相手の話から、話す量は相手7・自分3。受け入れ側が話し続ける回は失敗
• 「困ってることある？」は機能しない。時間を使った場所や分かりにくかった箇所など、事実として答えられる形で聞く
• フィードバックは SBI（状況 → 行動 → 影響）で組み立て、最後に「次にどうしてほしいか」まで言い切る
• 褒める時も具体的に。第三者に伝わる場で褒めると効果が大きい
• 言いにくいことは早く小さく伝える。3ヶ月ためて評価面談で言うのは、修正の機会を与えていない
• 期待値のズレは、どちらかが悪いのではなく共有していないことが原因。「何ができていれば順調か」を言語化する
• 記録は4行でいい。受け入れ側のアクションも書き、本人に見せられないことは書かない