今日のフォーカス
テーマ：課題定義・選択肢生成・意思決定フレームワークの3層——依頼された「要求」の奥にある本当のJobを掘り当てて課題を再定義し、意思決定は「誰が推薦し・誰が合意し・誰が実行するか」を役割ごとに明示して停滞を防ぎ、そもそも一意の正解が存在する問題なのか、関係者ごとに問題の定義自体が食い違う厄介な問題なのかを見極める。
「CSVエクスポートが欲しい」という顧客要求をそのまま実装しかけるプロダクトリードが、Jobs to be Doneで要求の奥にある本当の仕事を掘り当て、解決策を選び直す（Q1）。与信モデル切り替えを巡り3週間停滞した意思決定を、RAPIDで「誰が推薦し・誰が合意し・誰が最終決定するか」の役割を明示して打開するVP（Q2）。AI時代のエンジニア評価制度を巡り、価値観の異なる3派が対立するCEOが、Wicked Problemの視点で「一発で完璧な制度を設計する」という発想そのものを手放し、継続的な対話と試行に切り替える（Q3）。PM/CTO移行期に問われる「答える前に、何を・どう・そもそも何を決めるべきかを設計する」メタ規律を3問で鍛える。
Jobs to be Done
顧客の要求（Solution）ではなく、その奥にある「片付けたい仕事（Job）」を機能的・感情的・成功指標の3層で掘り当て、解決策を選び直す。
RAPIDフレームワーク
Recommend・Agree・Perform・Input・Decideの役割を関係者ごとに明示し、「誰もが拒否権を持つ」ように見える停滞を、役割の設計で解きほぐす。
Wicked Problem
技術的に一発で解ける「Tame Problem」と、関係者ごとに問題の定義自体が異なる「Wicked Problem」を区別し、後者は解決ではなく継続的な調整で扱う。
Q1
★★★☆☆ 基本
Jobs to be Done——「CSVエクスポート機能が欲しい」の奥にある本当の仕事を掘り当てる
シナリオ — B2B経費精算SaaS「ExpenseFlow」（従業員45名・中堅企業向け） / プロダクトエンジニアリングリード
大口顧客（従業員800名の製造業）の情報システム部長から、カスタマーサクセス経由で「経費データをCSVでエクスポートできる機能を追加してほしい。最優先でお願いしたい」という要望が届いた。プロダクトバックログにはすでに類似の要望が3件溜まっており、あなたはこの四半期のロードマップにCSVエクスポート機能を組み込むかどうかの判断を迫られている。開発工数は見積もりで3週間。しかし、あなたは念のためカスタマーサクセス担当に「なぜCSVが必要なのか、顧客に聞いてもらえないか」と依頼した。返ってきた答えは「毎月末、経費データを社内の別システム（会計システム）に手作業で転記するのに、画面から一件ずつコピーしていて時間がかかりすぎる。CSVがあれば一括で取り込めるはず」というものだった。
問い
- Jobs to be Done（JTBD）の考え方に基づき、この顧客が本当に「雇いたい仕事（Job）」は何か。「CSVエクスポート機能が欲しい」という要求（Solution）と、その奥にあるJobを区別して言語化せよ
- 「CSVエクスポート機能をそのまま3週間かけて作る」という対応が、Jobの解決として不十分・不安定になりうる理由を、Jobの構造（機能的Job・感情的Job・成功の指標）の観点から説明せよ
- このJobを起点に、CSVエクスポート以外にどのような選択肢がありうるか、開発コストとJobの解決度の両面から比較し、あなたの推奨案を提示せよ
Jobs to be Doneは「顧客は製品や機能を買っているのではなく、自分の生活・仕事の中で片付けたい"仕事（Job）"を進めるために製品を"雇っている"」と捉える考え方。実務では、顧客から届く要望はほぼ常に「解決策（Solution）」の形で届き、その奥にあるJobが省略されている。要求された解決策をそのまま実装すると、工数をかけた割にJobを十分に解決できない、あるいは局所最適な機能を作ってしまう、という失敗が頻発する。要求の表面（What）で止まらず、その奥の目的（Why＝Job）まで掘り下げてから解決策を選び直すという、課題定義の基礎体力を鍛える。
罠：顧客が使った言葉（「CSVが欲しい」）をそのまま要件として受け取り、要望に応えたと考えてしまう。しかし顧客はエンジニアではなく、自分が知っている手段（CSV）でしかJobを表現できないだけであり、CSVが最適解とは限らない。
判断の軸：「この解決策は、顧客が言った言葉ではなく、顧客が本当に片付けたいJob（作業時間の削減・ミスの削減・心理的負担の軽減）を、どれだけ確実に・どれだけ多くの顧客に対して解決するか」を基準に選択肢を比較する。
① 本当のJobの言語化
機能的Job
月末の経費データを、手作業のコピー＆ペーストによるミスや時間のロスなしに、社内の会計システムへ正確かつ迅速に反映させたい
感情的Job
単純作業に忙殺される月末の憂鬱さ・入力ミスによる後日の訂正対応への不安から解放されたい
成功の指標
転記にかかる時間（現状：おそらく数時間）と、転記ミスの発生件数
顧客が言葉にした要求は「CSVエクスポート機能が欲しい」（Solution）。しかしその奥にあるJobは「月末の経費データを、手作業のミスや時間のロスなしに、社内の会計システムへ正確かつ迅速に反映させたい」という機能的Jobであり、感情的Jobを伴う。CSVはこのJobを解決する数ある手段の一つに過ぎず、顧客が「自分の知っている手段」として提示しただけである。
② CSVエクスポートが不十分・不安定な理由
機能的Jobへの適合度が中途半端
CSVエクスポート単体では、顧客側でCSVを会計システムに再度手作業でインポートする作業が残る。「一括で楽になる」度合いは上がるが、「正確かつ自動的に反映される」というJobの核心までは届かない感情的Jobへの適合度が読めない
「ミスへの不安」を解消するには、データ移動だけでなくフォーマットの整合性チェックや反映結果の確認のしやすさも関わる。CSVという手段だけでこの不安が本当に解消されるかは検証していない他の顧客への一般化が不透明
バックログの類似要望3件が同じJob（会計システムへの反映の手間）を指しているのか確認せずに「CSV」という同じ解決策で束ねると、実際には解決していない要望が混在するリスクがある③ 選択肢の比較と推奨案
| 選択肢 | 開発コスト（目安） | Jobの解決度 |
|---|---|---|
| A. CSVエクスポート機能（顧客要求どおり） | 3週間 | 中（手作業コピペは減るが、会計システムへの再入力の手間は残る。ミス削減効果は限定的） |
| B. 主要な会計システムとのAPI連携・自動同期機能 | 6〜8週間（対象システム次第で変動） | 高（転記作業自体をなくし、ミスも構造的に削減。感情的Jobにも直接効く） |
| C. まず他要望3件も含めてヒアリングを行い、Jobの共通性を確認したうえで機能範囲を決定 | 1週間のヒアリング＋設計後に本開発着手 | 未確定だが、投資対効果を最大化できる可能性が高い |
推奨案：まずCの通り、バックログの類似要望3件について「なぜ必要か」を1週間以内に確認し、Jobが共通しているか（会計システムへの反映が主目的か）を確かめる。共通していればB（API連携・自動同期）が両方のJobに最も強く効くため優先候補とする。ただし即座にBへ踏み切れない場合は、CSVエクスポート（A）を「暫定策」として位置づけ、"最終的にはAPI連携に置き換える"というロードマップを顧客に明示したうえで着手し、局所最適な機能への投資に終わらせない。
実践への応用
実務・キャリアへの展開
- プロダクトマネジメント全般：「顧客の声（VoC）」をそのまま機能要件化するのではなく、Jobまで掘り下げてから解決策を選び直す規律は、機能の乱立とロードマップの局所最適化を防ぐ。
- エンジニアリングリードの意思決定：見積もり工数だけで優先度を決めず、「このJobをどれだけ確実に・どれだけ多くの顧客に対して解決するか」という軸を加えることで、実装コストとビジネスインパクトの両方を踏まえた判断ができる。
- グローバル文脈：異文化間では要望の伝え方（直接的か婉曲的か）が異なるため、「言葉どおりの要求」と「奥にあるJob」の乖離が特に大きくなりやすい。JTBDのヒアリング型の問いは文化を問わず機能する。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q2
★★★★☆ 標準
RAPIDフレームワーク——「誰が推薦し、誰が合意しなければならないか」を役割ごとに明示して意思決定の停滞を断つ
シナリオ — オンライン与信・後払い決済サービス「PayLater」（従業員110名・複数の銀行と提携） / VP of Engineering
新しい与信スコアリングモデルへの切り替えを巡り、意思決定が3週間停滞している。プロダクトチームは「承認率が8%改善する」というデータを根拠に即座の切り替えを推している。リスク管理部門は「新モデルの貸し倒れ率への影響が3ヶ月分のデータでは検証しきれていない」と慎重姿勢を崩さない。法務・コンプライアンス部門は提携銀行との契約上、モデル変更に事前通知義務があるかもしれないと指摘するが、まだ正式な見解を出していない。あなたはCEOから「エンジニアリング側で進めてほしい」と言われているが、誰が最終的に決定権を持つのか、誰の合意が必須なのか、誰が単に意見を述べる立場なのかが、これまで一度も明文化されたことがない。結果として全員が「自分こそが止める権利を持っている」と考えて動けなくなっている。
問い
- RAPID（Recommend＝推薦する人・Agree＝合意が必須な人・Perform＝実行する人・Input＝意見を提供する人・Decide＝最終決定する人）の各役割を、この意思決定における関係者に割り当てよ
- なぜ「誰が合意（Agree）を持つか」を事前に明文化しないまま議論を進めると、全員が拒否権を持っているかのように振る舞い、意思決定が停滞するのかを説明せよ
- RAPIDの役割設計を踏まえ、あなたがVPとしてこの3週間の停滞を打開するために、次に取るべき具体的な進め方を提案せよ
RAPID（Bain & Companyが提唱）は、意思決定における関係者の役割を「推薦する・合意が必須・実行する・意見を提供する・最終決定する」の5つに明確に分離するフレームワーク。実務でよくある停滞は、役割が曖昧なまま「関係者全員の合意」を暗黙の前提にしてしまい、本来は意見提供（Input）に留まるはずの立場の人が、実質的な拒否権（Agree）を持っているかのように振る舞うこと。特に複数部門・規制業種が絡む意思決定では、「誰が本当に止める権利を持つか」を最初に明示しないと、声の大きさや部門間の力関係で議論が長引く。技術力はあっても組織横断の意思決定設計に不慣れなエンジニアリングリードが陥りやすい罠を診断させる。
罠：リスク管理部門やコンプライアンス部門のように「懸念を示す権限」を持つ部門を、自動的に「拒否権（Agree）を持つ部門」と同一視してしまう。規制上の必須要件がなければInput（意見提供）に留めるべき場合もあれば、逆に必須要件があるのに扱いを誤ると重大なコンプライアンス違反に発展するリスクもある。
判断の軸：「この部門の合意なしに決定を実行した場合、法的・契約的・安全上の重大なリスクが生じるか」を基準にAgreeとInputを切り分ける。感情的な影響力の強さや声の大きさで判断しない。
① RAPIDの役割割り当て
| 役割 | 該当者 | 理由 |
|---|---|---|
| Recommend（推薦） | プロダクトチーム＋エンジニアリングチーム（共同） | データに基づき「切り替えるべき」という具体案を作成し提案する立場 |
| Agree（合意必須） | リスク管理部門、法務・コンプライアンス部門（契約上の通知義務が確認された場合のみ） | 貸し倒れ率の悪化は事業存続リスクに直結し、規制業種として法的義務違反は致命傷になりうるため、拒否権を持たせる正当な理由がある |
| Perform（実行） | エンジニアリングチーム | 実際にモデルを切り替えるシステム変更を行う |
| Input（意見提供） | CEO、カスタマーサクセス | 決定に有用な情報は提供するが拒否権は持たない |
| Decide（最終決定） | VP of Engineering（あなた）、またはCEOと共同 | CEOからの権限委譲がある以上VPが最終決定者。対立が解消しない場合はCEOにエスカレーションする経路を残す |
法務部門については「契約上の事前通知義務があるかどうか」がまだ未確認のため、現時点では暫定的にAgree候補とし、正式な見解が出た時点で「義務があればAgree確定」「義務がなければInputに格下げ」と扱いを切り替える設計にする。
② なぜ役割の未明示が停滞を生むか
役割が明文化されていない状態では、各部門は「自分たちの懸念が却下されるかもしれない」という不安から、声を上げ続けることでしか自分の意見を反映させる手段がないと感じる。その結果、本来はInputで十分なはずの立場の人も、実質的に「自分が合意しなければ止められる」かのように振る舞い、議論が「誰の懸念が優先されるべきか」という力関係の綱引きに変質する。加えて、Decide（最終決定者）が明確でないと、対立が生じたときに誰が裁定を下すかが分からず、全員が相手の譲歩を待つ膠着状態に陥る。RAPIDを明文化することは、どの意見が拒否権を持ち、どの意見が判断材料に留まるかを事前に合意しておくことで、議論そのものを建設的にするための土台になる。
③ 停滞打開のための進め方
最初にDecideを確定させる
CEOに「エンジニアリング側で進めてほしい」という発言の意味を確認し、VPが最終決定者であることを書面で明確化してもらう法務の見解確定を最優先で取り付ける
「契約上の事前通知義務があるか」を法務に期限（例：3営業日以内）を切って確認依頼する。ここが最大のボトルネックRAPIDの役割表を関係者全員に共有する
役割の割り当てを1ページの文書にまとめ、「Agreeを持つのはリスク管理部門と法務のみであり、他は意見提供である」ことを明示的に合意してもらうAgreeを持つ部門との個別協議を先に行う
全員を集めた会議ではなくリスク管理部門と1対1で懸念の中身をすり合わせ、条件付き合意（例：限定的なA/Bテストを経て全面切り替え）に落とし込む全体会議は「確認の場」として設計する
個別協議で大筋合意が取れた後に全員を集め、RAPIDの役割どおりに最終確認を行う。この順序で会議が意見の応酬の場になることを防ぐ実践への応用
実務・キャリアへの展開
- 規制業種でのプロダクト開発：金融・医療などコンプライアンスが絡む領域では、Agreeを持つべき部門を早期に・正確に見極めることが、スピードと安全性を両立させる鍵になる。
- エンジニアリングリードのキャリア移行：PM/CTOに向かうほど「誰がどう決めるかの設計」が価値を持つ場面が増える。RAPIDのような役割設計を標準装備すれば、部門間の対立を個人の交渉力ではなく仕組みで解消できる。
- グローバル文脈：多国籍企業や複数拠点の意思決定では、拠点ごとに「誰が権限を持つか」の暗黙の前提が異なることが多い。RAPIDの明文化は文化的な力関係の違いを超えて意思決定プロセスを揃える実務的な手段になる。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q3
★★★★★ 応用
Wicked Problem——「AI支援コーディング時代のエンジニア評価制度」に唯一の正解はない
シナリオ — プロダクト開発企業（従業員140名・エンジニア60名） / VP of Engineering
過去1年でAIコーディングアシスタントの利用が全エンジニアに広がり、個人のコード生産量は平均で2倍以上に増えた。しかし人事評価制度は依然として従来の生産性指標をベースにしており、経営陣から「評価制度をAI時代に合わせて刷新してほしい」と指示された。エンジニアたちの意見は真っ二つに割れている。ある一派は「AIをどれだけ使いこなして成果を出したかを評価すべき」と主張し、別の一派は「AIに頼りすぎると設計力・デバッグ力が育たない。基礎力を評価に残すべきだ」と反論する。さらにシニアエンジニアの一部は「そもそも個人のアウトプット量で評価すること自体が時代遅れで、チーム全体への貢献や意思決定の質を評価すべきだ」と、評価軸そのものの前提を疑う。あなたが試しに1つの評価基準案を提示すると、それぞれの立場から「その基準では自分たちの働き方が正当に評価されない」という反発が返ってくる。
問い
- Rittel & WebberのWicked Problem（厄介な問題）の特徴に照らし、この評価制度刷新がなぜ「一度で解決できる技術的問題（Tame Problem）」ではなく「Wicked Problem」なのかを説明せよ
- 「唯一の正しい評価基準を設計してから展開する」というアプローチがなぜこの状況では機能しにくいのかを、Wicked Problemの性質から説明せよ
- Wicked Problemに対する実務的な対処法を踏まえ、あなたがVPとしてこの評価制度刷新にどう向き合うか、具体的な進め方を提案せよ
Wicked Problem（厄介な問題）は、都市計画研究者のHorst RittelとMelvin Webberが1973年に提唱した概念で、「技術的に解けば終わる問題（Tame Problem）」と「関係者ごとに問題の定義自体が異なり、解決策を試すことでしか問題の輪郭が見えてこない問題（Wicked Problem）」を区別する。ソフトウェアエンジニアは日常的に「正しい解が存在する問題」に取り組んでいるため、組織・評価制度のような複雑な問題にも無意識に「唯一の正解を設計して展開すれば解決する」という技術的問題の解き方を適用しがちである。2026年時点で現実に多くの組織が直面している、正解が定まっていない問題を題材に、Wicked Problemであることを見極め、"解決"ではなく"継続的な対話と調整"に切り替える判断力を試す。PM/CTOへのキャリア移行において最も重要な認知の転換の一つ。
罠：技術的な問題解決に慣れたエンジニアリングリードほど「正しい評価基準はこれだ」と一つの案を作り込んでから展開しようとする。しかし対立の根は情報不足ではなく何を"良い仕事"とみなすかという価値観そのものの相違にあるため、緻密な分析を重ねても合意に至らない。
判断の軸：「この制度案を、いま完璧な最終形として展開しようとしていないか？"当面はこれで試し、3ヶ月後に見直す"という前提を関係者と最初に共有できているか？」を基準に進め方を設計する。
① なぜこの状況はWicked Problemか
| 特徴 | この状況での現れ方 |
|---|---|
| ①問題の定義自体に決定版がない | 「AI活用度を評価すべきか」「基礎力を守るべきか」「チーム貢献を評価すべきか」——そもそも"何を評価すべきか"の合意すらない |
| ②正しい/間違っているではなく良い/悪いの程度問題 | どの評価基準案も、ある立場からは「妥当」、別の立場からは「不公平」に見える |
| ③試した解決策は元に戻せず、次の試行に影響する | 一度基準を導入すればエンジニアの行動はその基準に最適化され、後で変えても簡単には元に戻らない |
| ④問題の理解と解決が分離できない | AI時代にどんな貢献が価値を生むかは、評価制度を運用しながらでしか見えてこない |
| ⑤利害関係者ごとに問題の捉え方が異なる | 3派はそもそも解こうとしている問題自体が異なる（AI活用促進／基礎力の劣化防止／個人主義からの脱却） |
技術的な問題（Tame Problem）であれば、十分な情報収集と分析によって「これが正しい評価基準だ」という結論に到達できるはずである。しかしこの状況は情報不足ではなく価値観の相違が対立の根にあり、分析を重ねても収束しない。これがWicked Problemである所以である。
② 「唯一の正しい基準を設計してから展開する」が機能しない理由
Tame Problem（技術的問題）
Wicked Problem（この評価制度）
問題の性質
要件定義→設計→実装の順で進められ、十分な分析があれば一意に正しい答えに到達できる
問題の性質
解決策を試すことでしか問題の輪郭が見えず、価値観の相違ゆえ分析を重ねても収束しない
とるべき解き方
完璧な設計を作り込んでから展開すればよい
とるべき解き方
"当面のところ受け入れ可能な"打ち手を試行し、兆候を見ながら継続的に調整し続ける
一度導入した基準はエンジニアの行動を変えてしまうため、「まず完璧な案を作ってから展開する」というアプローチは展開した瞬間に状況が変わり、作り込んだ案の前提が崩れるというジレンマを避けられない。「完璧な設計→展開」という技術的問題の解き方そのものが、Wicked Problemの構造と根本的に噛み合わない。
③ VPとしての進め方——「解決」ではなく「継続的なマネジメント」への転換
最初の1ヶ月
経営陣・全エンジニアに「今回は完璧な最終制度を作らない」ことを明示し、"仮の運用"を試し3ヶ月ごとに見直すプロセスそのものを制度化する
対話の場を設計
3つの立場の代表者を交えたワーキンググループで、「どの基準が正しいか」ではなく「それぞれが最も守りたい価値は何か」を言語化するセッションを行う
仮の複合的な評価軸を"試行"として導入
個人のアウトプットの質・チームへの技術的貢献・問題解決の難度への挑戦を定性・定量の両面から評価者が総合判断する枠組みを、最終形ではなく3ヶ月間の試行運用として導入する
早期警戒シグナルを設定
AI活用推進派の離職・エンゲージメント低下、若手のスキル低下の兆候、チーム貢献が評価されないという不満の再燃を定性的にモニタリングし、3ヶ月ごとにレビューする
恒久的な"正解"を出さない文化を定着
評価制度は継続的に見直す対象であることをVP自身が繰り返し発信し、次の見直しが「また作り直すのか」ではなく「予定どおりの調整」として受け止められる土壌を作る
実践への応用
実務・キャリアへの展開
- 組織運営全般：評価制度・カルチャー設計・組織構造の多くはWicked Problemであり、「一度で完璧に解決する」という発想自体が失敗の元。PM/CTOへの移行期に最も重要な認知の転換の一つは、技術的問題の解き方を組織問題にそのまま適用しないことである。
- プロダクト戦略：「顧客のニーズに応える正しいプロダクト」を一度で定義しようとする姿勢もWicked Problem的な誤りに陥りやすい。仮説検証を繰り返しながら"当面の最適解"を更新し続ける発想は、プロダクト開発とも共通する。
- グローバル文脈：多国籍・多文化のチームでは「良い仕事とは何か」という価値観の相違がさらに大きくなるため、唯一の基準をトップダウンで押し付けるのではなく、地域・チームごとの対話を通じた調整プロセスの設計がより重要になる。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
今日のまとめ・次回へ
次回への接続（明日: EQ-B 対人スキル・関係管理）
今日Q2・Q3で扱った「部門間の対立」「価値観の異なる関係者との合意形成」の背後にある、対話を通じて信頼を築き、異なる立場の相手の懸念に共感しながら折り合いをつける対人スキルに直結する。決め方の設計（Thinking）だけでなく、決め方を実際に運用する対話そのもの（EQ）を明日は鍛える。