記事のサマリー（TL;DR）
- SmartHRが「リリース後の学習ループ」パイロットを4か月かけて完走し、Decision Review・Decision Logの最終評価を実施
- 自己評価バイアスを防ぐため「アンケート結果を見る前に予測・判定基準・主張強度を文書化・凍結」する手法を導入
- 予測の当たり外れには根拠の種類（本人発言 vs 行動からの推定）が関係することが判明し、確信度の調整ルールを整備
自己評価バイアスを構造で防ぐ——プロダクト組織が学べる評価設計の考え方
「自分が立ち上げた施策を、自分で評価して、自分で報告する」という構造は、どの組織にも存在します。SmartHRの事例が示すのは、「正しく評価しようという心構え」だけでは都合のいい方向に寄っていくバイアスを防ぎきれないという現実です。
日本のSaaS・EC開発現場では、PMや施策オーナーが自ら振り返りを設計して報告書をまとめるケースが多く、評価プロセスを外部化する仕組みが整っていないことが多いです。「予測の事前凍結」「主張の強弱ルール」「根拠の種類を記録する」という3点は、SmartHR固有の話に留まらず、kintoneや社内Notionで管理するロードマップレビュー、あるいはShopify Plusのリリース後計測プロセスにも応用しやすい考え方です。計測指標と判断基準をリリース前に決めてロックしておく習慣は、リリース後の振り返りの質を大きく変えます。
詳細
パイロット概要と最終結果
SmartHRの技術統括本部でアジャイルコーチを務めるshooën氏は、「リリース後の学習ループ」を定着させるためのパイロットプロジェクトを推進してきました。2026年4月のProduct Management Summitで途中経過を発表し、5月に同内容を記事化。その後、学習ループを最後まで一周して最終評価を終えたため、今回その結果を公開しています。
パイロットは2チームで実施。使用した仕組みは2つです。
- Decision Review（旧称：Learningレビュー）：観測結果の確認と判断を行う定例の場
- Decision Log：判断の記録を蓄積するドキュメント
この2つをまとめて「型」と呼んでいます。
当初の仮説は「リリース後の観測から判断を更新するという学習ループが回せていないのではないか」というものでした。この仮説は「限定的にしか判定できなかった」というのが結論です。型がなくても観測自体はしていただろう、と答えたチームがあったためです。型が加えたのは「観測する行為」ではなく、「観測結果を事前に決めた基準に照らして次の判断につなげるステップ」でした。
最も確かに確認できた付加価値は「PMが持っていた判断の前提がエンジニアに共有されて目線が揃う」ことでした。これは4月の発表時点から変わらない知見です。ただし、効果が出たのはリリース後ではなく、「リリース後に何を観測するかをリリース前に決める」フェーズでした。
リリース後に観測結果を受けて判断を更新した場面も3件ありました。うち1件では、指標の範囲と打ち手をリリース前に決めておいたにもかかわらず、最終的には「即実行せず、もう一段強い根拠を確かめる」という判断がレビューの場で出ました。事前設計通りには動かないこともある、という実例です。
なお、当初「付加価値」として挙げていた「事前の判断設計」は、最終的に付加価値から外しました。これは型に付随して生まれる効果ではなく、型を回すこと自体に含まれるステップと判断したためです。
結果を見る前に決めておく——評価バイアスへの構造的対処
ここからが記事の中核です。
今回の評価にあたって、shooën氏は振り返りアンケートの回答を見る前に以下の3点を文書化・凍結しました。
- 判定の基準
- チームがどう答えるかの自分の予測
- どの結果が出たらどの主張をどの強さで立てるか
日付入りで凍結することで、「回答を見てから『こう来ると思っていました』と書く」ことを防いでいます。予測を先に書いていなければ、当たり外れの数も、どこがずれていたかも分からないまま、「当たっていた感覚」だけが残ります。
予測の外れパターン分析
片方のチームについて、当たった予測と外れた予測を比較したところ、根拠の種類に差がありました。
- 当たった4件：本人が言ったこと、実際に残っている記録を根拠にした予測
- 大きく外れた3件のうち2件：こちらが見た行動から相手の意識を推定した予測
最も大きく外れたのは「今後チームだけで型を回せそうか」への回答予測でした。shooën氏は「エンジニア2名は回せそうと答えるだろう」と予測していましたが、実際にはその2名を含めた3名全員が慎重な回答でした。しかも3名全員が「外からの客観的な視点がなくなることがハードル」と指摘しました。
shooën氏自身が「チームの中からは出てこない問いを投げる」という役割を果たしていたにもかかわらず、その寄与を予測に含めていなかったのです。「自分の寄与を過小に見積もる方向へ外れていた」と振り返っています。
対処策として導入したルール：予測を書く際に根拠の種類も明記する。「本人が言ったこと」か「こちらが見た行動」かを区別し、後者の場合は確信度を最初から1段下げて記載する。
アンケートの聞き方と読み方で注意したこと
振り返りアンケートは、2チーム計6名に対して実施しました。自分がやったことを自分で聞く構造である以上、遠慮や気遣いによって肯定的な答えに寄るリスクがあります。
聞き方の工夫
「型がなかったとしたら」という仮定条件で問うことを意識しました。感想ではなく、実際のDecision Reviewで下した判断を設問文に書き込み、その場面に限定して「もし型がなかったらどう違っていたか」を聞く形にしています。具体的な設問例は以下の通りです（固有名詞・数値は〔〕に置換）。
「最後のDecision Reviewで、〔リリース後の観測結果〕をふまえて『〔ある箇所〕に課題がある可能性がある』と判断し、『追加の検証を検討する』という次アクションを決めました。こうしたリリース後の観測と判断が、もしDecision Reviewがなかったとしたら、どう違っていたと思いますか。」
読み方の工夫
「書かれたことをそのまま受け取らない」を意識しました。片方のチームでは「あまり価値を感じなかった点」に3名とも無回答でした。「不満がなかった」と読みたくなりますが、この設問は任意記入形式でした。不満がなかったのか、記入負担や遠慮で書かれなかったのかは空欄では判断できません。設問文自体に原因がある可能性が残るため、この空欄からは何も読み取らないと決めています。
2チームの回答が真逆に分かれた設問
「今後チームだけで型を回せそうか」については、2チームで正反対の回答になりました。
- チームA：3名とも「回せそう」寄り。うち2名が形骸化を心配
- チームB：3名とも慎重。PMは「暗黙の前提やチーム内のバイアスを問い直しにくくなる」と記述。エンジニア1名は「客観的な視点で疑問を投下してくれる役割がいなくなる分、チームだけで同じ質で回せるかは結構怪しいかも」と回答
この差を追うと、チームBは案件について「どちらかといえば読めない部分が多かった」と答えており、不確実性の高い案件に取り組んだチームの方が慎重な回答をしている傾向が見られました。チームAは3名とも「もっと不確実性の高い案件で試すとよい」と答えていたチームです。
この知見は「進行役をチームに引き継ぐタイミングをどう判断するか」に直結します。「自分たちだけで回せそうですか」という自己評価だけで引き継ぎを決めると、不確実性が高い案件をこなしたチームほど慎重に答えるという傾向があれば、「回せそう」という答えが引き継げる状態を意味しない可能性があります。ただし2チームの結果なので、傾向の候補として留めており、今後は「進行役の問いが実際の判断に影響した場面があったか」もチームの評価と対で記録することにしています。
主張を強める・弱める際のルール設計
結果を見たあと、凍結した主張を書き換えたくなるケースもあります。かといって一律に書き換え禁止にすると、間違いに気づいても修正できません。そこで以下のルールを設けました。
主張を強める場合：結果を見る前に条件を決めておき、該当した場合のみ書き換える。
例：「計測の準備にチームが自ら時間を割くようになる」という効果の候補について、「確認できた」と書いてよい条件を「開発メンバーの複数名が、実際にそうなっていると書いていること」と事前に設定。実際にそう書いたのは1名だったため、条件未達として「確認できた」とは書かない。ただし「なかったことにする」のとは別で、そう書いた事実は残しつつ、効果として主張はしない扱いにしています。
主張を弱める場合：妥当な理由があれば、事前に条件を決めていなくても書き換える。「控えめすぎました」となるより「言い過ぎでした」となる方がはるかに困るためです。
実例：片方のチームの結果だけを根拠に「自走のハードルは能力ではない」と断定していた主張が、もう片方のチームの結果と整合しなくなりました。想定外のケースだったため凍結文書には書いていませんでしたが、断定をやめて「2チームで結果が分かれた」という書き方に修正しています。
見積もりを外した話
パイロットは「8週間のうちに最低1回はリリース後の観測まで一周する」計画で始まりましたが、実際には4か月前後かかりました。観測したいことが観測できる状態になるまでの期間を甘く見積もっていたことが原因です。片方の案件ではリリースから1か月時点でまだ使われておらず、観測を2か月後まで延ばしています。
現在は、パイロット開始前に「いつ何が観測できるようになりそうか」をチームと確認し、観測期間の目安を合わせることにしています。
事前凍結という評価手法から見えたこと
今回の報告は「うまくやれた話」ではありません。予測は外れ、読み取れない設問を作り、期間の見積もりも甘かったという記録です。
ただ、事前に凍結していたからこそ「どこがどう外れたか」を後から特定でき、次に何を変えるかを決められました。「予測に根拠の種類を書き添える」という改善策も、外れた事実を特定できたからこそ出てきたものです。
正しく評価しようという心構えだけでは、都合のいい方向へ寄っていくバイアスは止められません。事前に決めたことと実際の結果との差分を記録しておく仕組みが、評価の信頼性を支えます。