フィードバックの伝え方と例文30｜SBIモデルでエンジニアに伝える型

フィードバックとは、相手の行動とその結果を本人に伝え、次の行動を決める材料にしてもらうことです。 伝え方の型として広く使われているのがSBIモデルで、状況（Situation）・行動（Behavior）・影響（Impact）の3つを順に伝えます。

この記事では、開発チームで起きやすい6つの場面について、ポジティブと改善の例文を合わせて30本載せます。穴埋め式のテンプレート、あいまいな言い方を事実に直す言い換え表、口頭・チャット・レビューコメントでの書き分け、ほかの型との比較表もまとめました。伝える1回分の文面に絞った内容で、人事評価の決め方は扱いません。

確認環境（確認日 2026-10-05）：例文30本の本数と、あいまいな語が入っていないことは Python 3.11.15 のスクリプトで点検しています。SBIモデルの定義は Center for Creative Leadership（CCL）の公開ページを開いて確認しました。

この記事の結論

• 状況・行動・影響の3文で、事実だけを伝える。 「いつ・どこで」「何をしたか」「その結果どうなったか」の順です
• 評価の言葉と人格への言及を入れない。 「雑」「やる気」「いつも」を外し、見えた行動と数字に置き換えます
• 改善のときは、最後に相手の考えを聞く1文を足す。 「どう考えていましたか」と聞くと、一方通行の指摘が対話になります
• ポジティブなフィードバックも同じ型で伝える。 「助かりました」だけでなく、どの行動が何に効いたかを伝えると、次も同じ行動を選びやすくなります

フィードバックの伝え方の早見表

SBIモデルとは：3つの要素の定義

SBIは、リーダーシップ開発の機関である Center for Creative Leadership（CCL）が紹介しているフィードバックの型です。CCLのページでは、3つの要素を次のように説明しています。

同じページでは、SBIに「意図（Intent）についての問いかけ」を添えるとさらに役立つと書かれています。意図を尋ねることで、フィードバックが一方向の伝達から、意図と影響の差を確かめ合う双方向の対話になる、という説明です。この形はSBIIと呼ばれます。この記事の改善の例文に付けた「相手の考えを聞く1文」は、この考え方に沿ったものです。

穴埋め式テンプレート

ポジティブ（3文）

【状況】（いつ）の（場面・成果物）で、
【行動】（相手がしたこと・書いたこと）してくれました。
【影響】そのおかげで、（誰に・何が・どれくらい）なりました。

改善（4文）

【状況】（いつ）の（場面・成果物）で、
【行動】（見えたこと・書かれていたこと）でした。
【影響】その結果、（誰に・何が・どれくらい）起きました。
【問いかけ】（その場面での考え・事情）は、どうでしたか。

伝える前のメモ（タブ区切り）

伝える前に1行で書き出しておくと、3文が事実になっているかを落ち着いて確かめられます。

日付  相手  種類  状況  行動  影響  問いかけ    伝える手段
2026-10-05  田中  改善  月曜に出してもらった貸出機能のプルリクエストで、    画面の修正とテーブル変更を合わせた約900行が1件にまとまっていました。    差分を追い切れず、レビューに2日かかりました。 分け方について、どう考えていましたか。 口頭（一対一）

場面別の例文30本

名前や機能名は、架空の「備品予約システム」の開発チームを想定しています。どの例文も、状況・行動・影響をつなげて読むと、そのまま伝えられる文面になります。

コードレビューの例文（No.1〜5：ポジティブ3本・改善2本）

設計の例文（No.6〜10：ポジティブ2本・改善3本）

障害対応の例文（No.11〜15：ポジティブ3本・改善2本）

見積もりの例文（No.16〜20：ポジティブ2本・改善3本）

会議の例文（No.21〜25：ポジティブ3本・改善2本）

報告の例文（No.26〜30：ポジティブ2本・改善3本）

例文30本のタブ区切り版

表計算ソフトに貼り付けて、自分のチームの場面に書き換えて使えます。

No  場面  種類  状況  行動  影響  問いかけ
1   コードレビュー ポジティブ   昨日の予約一覧APIのプルリクエストで、    変更の理由と確認手順を説明欄に5行で書いてくれていました。   読む前に全体をつかめたので、20分でレビューを終えられました。 
2   コードレビュー ポジティブ   火曜に私が出した検索条件の修正のレビューで、  日付の境界値のテストが抜けていることを、再現する入力つきで指摘してくれました。 リリース前に月末日の不具合を1件直せました。  
3   コードレビュー ポジティブ   今週のレビュー依頼3件について、    どれも依頼から半日以内にコメントを返してくれました。  待ち時間がなくなり、3件とも予定の日にマージできました。    
4   コードレビュー 改善  月曜に出してもらった貸出機能のプルリクエストで、    画面の修正とテーブル変更を合わせた約900行が1件にまとまっていました。    差分を追い切れず、レビューに2日かかりました。 分け方について、どう考えていましたか。
5   コードレビュー 改善  水曜の田中さんへのレビューコメントで、 「この書き方はわかりにくい」とだけ書かれていました。  田中さんが直し方を決められず、修正が翌日に持ち越されました。  どんな形にしてほしかったのか、聞かせてもらえますか。
6   設計  ポジティブ   先週の予約取消の設計書レビューで、   取消できる期限について、案を2つ並べて利点と注意点を表にしてくれました。    会議の30分で方針を決められました。  
7   設計  ポジティブ   備品マスタのテーブル設計で、  既存の3テーブルとの関係をER図に書き足してくれました。    影響範囲が見え、修正が必要な画面を2つ早い段階で見つけられました。   
8   設計  改善  木曜に共有された通知機能の設計書で、  送信に時間がかかったときの動きが書かれていませんでした。    実装の担当者が再送の回数を判断できず、質問が3件出ました。   エラー時の動きは、どこまで決まっていますか。
9   設計  改善  昨日の設計レビュー会で、    画面遷移図が当日の朝に差し替えられていました。 参加者4人が以前の版を読んできたので、最初の20分が読み直しになりました。   差し替えの連絡は、どのタイミングならできそうでしたか。
10  設計  改善  API定義書の予約登録の項目で、    日時の形式が「文字列」とだけ書かれていました。 画面側とサーバー側で形式が食い違い、結合テストで2件の不具合になりました。   形式を決めるうえで、迷っていた点はありますか。
11  障害対応    ポジティブ   月曜朝の予約画面が開けなくなった件で、 発生から10分以内に、影響範囲と次の報告時刻をチャットに書いてくれました。   問い合わせ窓口が同じ案内を出せて、利用者への説明がそろいました。    
12  障害対応    ポジティブ   先週の夜間バッチが止まった件で、    原因の調査と並行して、手作業での再実行手順を先に用意してくれました。  朝9時の業務開始までにデータがそろいました。  
13  障害対応    ポジティブ   昨日の振り返りで、   発生から復旧までの操作を時刻つきで一覧にしてくれました。    同じ事象が起きたときの手順書を、その日のうちに作れました。   
14  障害対応    改善  火曜の検索が遅くなった件で、  設定を変更したことが、復旧後の報告で初めて共有されました。   その間、別の担当者が同じ箇所を調べていて、1時間ほど作業が重なりました。    あの場面で、共有しづらい事情はありましたか。
15  障害対応    改善  金曜の通知メールが届かなかった件で、  原因が特定できるまでの2時間、状況の連絡がありませんでした。  窓口の担当者が見通しを答えられず、同じ問い合わせが5件続きました。   途中の連絡は、どんな形なら出しやすいですか。
16  見積もり    ポジティブ   帳票出力機能の見積もりで、   作業を8つに分け、それぞれに前提条件を書いてくれました。    依頼元との確認で、範囲に入らない作業を2つその場で合意できました。   
17  見積もり    ポジティブ   今月の機能追加の見積もりで、  前回の類似機能の実際の工数を並べて根拠にしてくれました。    見積もりの説明が10分で済み、追加の質問は出ませんでした。   
18  見積もり    改善  先週の検索機能の見積もりで、  テストと設計レビューの時間が含まれていませんでした。  着手後に3日ぶんの作業が増え、リリース日を1週間動かすことになりました。    見積もりに入れる範囲を、どう決めていましたか。
19  見積もり    改善  月曜の朝会で、 予約変更機能は「たぶん3日くらい」と口頭で答えてくれました。  根拠が残らなかったので、5日かかったときに何が増えたのかを追えませんでした。  3日と考えた内訳を、一緒に書き出してみませんか。
20  見積もり    改善  水曜に出してもらった見積もりで、    調べる必要がある箇所も、他の作業と同じ精度の数字で書かれていました。  幅があることが依頼元に伝わらず、1つの数字で予定が組まれました。    幅のある部分は、どう書くと伝わりそうですか。
21  会議  ポジティブ   昨日の仕様確認の会議で、    終了5分前に、決まったこと3点と担当を読み上げてくれました。  議事録を待たずに、全員がその日のうちに着手できました。 
22  会議  ポジティブ   火曜の定例で、 議論が実装の細部に入ったとき、「この件は別の時間に」と切り分けてくれました。  予定の議題4つを時間内に終えられました。    
23  会議  ポジティブ   今週の設計相談会で、  発言の少なかった伊藤さんに、具体的な質問を1つ向けてくれました。    伊藤さんから入力チェックの抜けの指摘が出て、設計に反映できました。   
24  会議  改善  木曜の進捗会議で、   議題が当日の開始時に初めて画面に映されました。 参加者が数字を準備できず、2つの議題が次回に持ち越されました。 事前に送るうえで、手間になっている点はありますか。
25  会議  改善  昨日の打ち合わせで、  高橋さんの説明の途中に、3回続けて発言を重ねていました。    高橋さんの案が最後まで共有されず、後から同じ内容を確認し直すことになりました。 あのとき、気になっていた点は何でしたか。
26  報告  ポジティブ   金曜の週次報告で、   予定との差を機能ごとの日数で書き、遅れている1件に対策を添えてくれました。   その場で応援の担当を決められました。  
27  報告  ポジティブ   昨日の夕方、  テスト環境の不調に気づいて15分以内に、わかっている範囲を知らせてくれました。 他の3人が同じ調査をせずに済みました。 
28  報告  改善  今週の日報で、 3日続けて「順調です」の1行でした。  木曜に2日の遅れがわかったとき、打てる手が限られました。    書きづらいと感じている点はありますか。
29  報告  改善  水曜の依頼元への報告メールで、 結論が最後の段落に書かれていました。  先方から「結局いつ終わりますか」という確認が1件返ってきました。    結論を先に書く形にすると、困る点はありそうですか。
30  報告  改善  月曜に共有されたテスト結果で、 件数の合計は書かれていましたが、未解決の不具合の内訳がありませんでした。    リリースしてよいかの判断を、翌日に延ばすことになりました。   内訳を出すうえで、手間になっている点はありますか。

あいまいな言い方を事実に直す言い換え表

直し方は3つです。回数や時間を数字にする、成果物の場所を示す、基準の文書を示す。 数字がすぐ出ないときは、「先週の火曜の件」のように場面を1つに絞るだけでも事実に近づきます。

下書きをスクリプトで点検する

あいまいな語が下書きに入っていないかを、Pythonで機械的に点検できます。次のコードは、上のタブ区切りを feedback.tsv として保存したうえで、30本の本数と語の有無を調べるものです。

import csv

VAGUE = ["いつも", "毎回", "ちゃんと", "しっかり", "きちんと", "全然", "普通は", "当たり前",
         "なるべく", "早めに", "やる気", "責任感", "意識", "性格", "雑", "べき"]


def check(text):
    return [w for w in VAGUE if w in text]


with open("feedback.tsv", encoding="utf-8", newline="") as f:
    rows = list(csv.DictReader(f, delimiter="\t"))

print("■ 場面別の本数")
scenes = []
for r in rows:
    if r["場面"] not in scenes:
        scenes.append(r["場面"])
for s in scenes:
    pos = sum(1 for r in rows if r["場面"] == s and r["種類"] == "ポジティブ")
    imp = sum(1 for r in rows if r["場面"] == s and r["種類"] == "改善")
    print(f"{s}\tポジティブ{pos}\t改善{imp}")
print("合計", len(rows), "本")

print("\n■ 例文30本の点検")
ng = 0
for r in rows:
    text = r["状況"] + r["行動"] + r["影響"] + r["問いかけ"]
    found = check(text)
    no_question = r["種類"] == "改善" and not r["問いかけ"].endswith("か。")
    if found or no_question:
        ng += 1
        print(r["No"], found, "問いかけなし" if no_question else "")
print("あいまいな語を含む例文:", ng, "本")

print("\n■ 直す前の文を点検")
for t in ["いつもレビューが遅いよね。もっと早めにお願い。",
          "ちゃんとテストしてから出すべきだと思う。",
          "火曜のレビュー依頼に、木曜の夕方にコメントが付いていました。"]:
    print(check(t) or "該当なし", "←", t)

実行結果です。

■ 場面別の本数
コードレビュー ポジティブ3  改善2
設計  ポジティブ2  改善3
障害対応    ポジティブ3  改善2
見積もり    ポジティブ2  改善3
会議  ポジティブ3  改善2
報告  ポジティブ2  改善3
合計 30 本

■ 例文30本の点検
あいまいな語を含む例文: 0 本

■ 直す前の文を点検
['いつも', '早めに'] ← いつもレビューが遅いよね。もっと早めにお願い。
['ちゃんと', 'べき'] ← ちゃんとテストしてから出すべきだと思う。
該当なし ← 火曜のレビュー依頼に、木曜の夕方にコメントが付いていました。

語のリストは、チームでよく出る言い方に合わせて足していきます。

口頭・チャット・レビューコメントでの書き分け

同じ内容（例文No.4）を、3つの手段で伝える場合の文面です。

伝えるタイミングは、行動から2〜3日以内を目安の例にします。 時間がたつと状況を思い出しにくくなり、「状況」の1文が伝わりにくくなります。

SBI・SBII・DESC・サンドイッチ型・ペンドルトン型・KPTの違い

SBIとSBIIの構成は、CCLの公開ページで確認した内容です。ほかの型は、一般に紹介されている構成をまとめています。

どの型を選ぶかの判断表

迷ったらSBIで下書きし、改善なら問いかけを1文足す、という進め方で多くの場面に対応できます。 ほかの型を使う場合も、事実を伝える部分はSBIの3文で書けます。

同じ内容を型ごとに書くと

例文No.24（議題が当日に初めて共有された件）を、3つの型で書いた例です。

フィードバックを受け取る側の3つの型

伝える側の型と合わせて、受け取る側の返し方も決めておくと、やり取りが短く済みます。

確かめて分かったこと

• CCLのページでは、行動（Behavior）の説明に「意見や判断を入れない」と明記されている。 「評価の言葉を入れない」は応用のコツではなく、型の定義そのものでした
• 意図の問いかけは、SBIの発展形としてCCL自身が紹介している。 問いかけを足した形にはSBIIという名前が付いています
• 影響（Impact）は、良い影響にも好ましくない影響にも使うと説明されている。 SBIは改善のための型と思われがちですが、ポジティブなフィードバックにも同じ3文が使えます
• あいまいな語の点検は、短いスクリプトで機械的にできた。 16語のリストで、直す前の文の「いつも」「早めに」「ちゃんと」「べき」を検出し、例文30本は該当0本でした
• 30本を書き出すと、影響の文には数字が入れやすい。 「20分で」「2日かかり」「3件」のように、時間か件数のどちらかを入れると事実の文になりました

つまずきやすい点と整え方

よくある質問

Q. SBIモデルとは何ですか？ A. 状況（Situation）・行動（Behavior）・影響（Impact）の3つを順に伝えるフィードバックの型です。事実を3文で伝えるので、評価の言葉を入れずに済みます。

Q. SBIとSBIIの違いは何ですか？ A. SBIIは、SBIの3つに意図（Intent）についての問いかけを足した形です。相手の事情や考えを聞くことで、伝えるだけの場が対話になります。

Q. ポジティブなフィードバックにもSBIは使えますか？ A. 使えます。「昨日のレビューで、再現する入力つきで指摘してくれたので、リリース前に1件直せました」のように、行動と影響を伝えます。

Q. フィードバックとフィードフォワードの違いは何ですか？ A. フィードバックは起きた行動とその結果を伝えること、フィードフォワードはこれからの行動について案を出し合うことです。SBIで事実を伝えたあとに問いかけを足すと、自然にこれからの話に移れます。

Q. 改善のフィードバックを受け止めてもらえないときはどうすればよいですか？ A. 行動の文に解釈や評価の言葉が入っていないかを見直します。「雑」「いつも」などを外して数字と成果物に置き換え、最後に相手の考えを聞く1文を足します。

Q. チャットで改善点を伝えてもよいですか？ A. 軽い内容なら個別メッセージで伝えられます。背景を聞く必要がある内容は、チャットでは事実と「話す時間をください」までにして、口頭で話します。

まとめ

• フィードバックは、状況・行動・影響の3文で事実を伝える
• 行動の文には、見えたこと・書かれていたことだけを書く。 評価の言葉と人格への言及を外す
• 改善のときは、相手の考えを聞く1文を足して4文にする
• ポジティブも同じ型で。 どの行動が何に効いたかを伝える
• あいまいな語は、数字・成果物の場所・基準の文書に置き換える
• 手段は内容の重さで選ぶ。 背景を聞く必要がある改善は一対一の口頭で
• 型に迷ったらSBIで下書きし、目的に合わせてDESCやペンドルトン型に組み替える

参考・出典

• Center for Creative Leadership「SBI Feedback Model & Talent Development Conversations」 https://www.ccl.org/articles/leading-effectively-articles/sbi-feedback-model-a-quick-win-to-improve-talent-conversations-development/ （Situation・Behavior・Impact の説明、意図についての問いかけ）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。