インタビューガイドの作り方 - puttinpuddinのブログ

突如ハウツーを投稿するシリーズ。いつだったか、チームメンバー向けに書いたものを転記。

ジュニアの頃は仮説検証作業を割り振られやすい訳だが、「作業」と呼ばれるものもそれなりの抽象度と非定型性を持っているため、習熟にはそれなりの時間と関心を要する。そのため、問題解決プロセスの全体像やチーム内での実践方法に不慣れな人は目の前の作業に追われて全体観を失い、結果として質の低いガイド作成とインタビュー実行に終始してしまう。

そんなことに問題意識を持ち、問題解決のプロセスやチームとしての当該プロセスの実践との接続を意識してもらうために書いた。

------

インタビューガイドの作り方

インタビューガイドの作成は、１.インタビューガイドに盛り込む項目の導出、２.各項目に対する聞き方の作成の2ステップから成ります
- これらを明示的に区別せずに実施/指示すると、投下時間の割にいまいちなインタビューガイドが出来あがります

手続き１．インタビューガイドに盛り込む項目を導出する

インタビューはプロジェクトが行う仮説検証の一環ですので、①論点、②論点に対する答えの仮説、③仮説に対する検証方法、の順に整理し、インタビューの位置づけを明確にしていきます
- 「①論点」は、プロジェクトを通じて答えたい問いになります
  - プロジェクト受注時に作成している「主要論点と検討アプローチ」を、検討及びクライアントとの討議を通じてアップデートします
  - 例えば、「新規事業xxxに取り組むべきか」という論点があるとしたら、ブレークダウンして、(a)どういった現状があり、(b)課題は何で、(c)どのような変化があれば課題が解消され、(d)それはサービスとして収益化可能か、の4つの問いに分けられます
- 「②論点に対する答えの仮説」は、プロジェクトチームとしてそのとき持っている上記(a)～(d)に対する仮の答えになります
  - 調査によって進化させていくことになりますが、現有の情報から極力細かい粒度で組み立てます
- 「③仮説に対する検証方法」では、②に対して、具体的にどのような方法で検証するかを決めることになり、ここで一つの手段として「xxxxさんへのインタビュー」といった検証方法を検討することになります
  - この際、あくまで、検証したい項目ありきで、それを検証するためにインタビュー対象に求める人材要件は何かを整理します
  - その人材要件を元に、合致するエキスパートの抽出を依頼し、候補者リストを準備してもらいます
  - 導出された要件に対して、エキスパートの候補者を突合し、この人の経歴を前提すると、どの仮説を検証できるかを識別します

手続き２．各項目に対する聞き方を作成する

エキスパートは我々が行いたい仮説検証の人材要件を完全には満たしていない場合が多く、また、奇跡的に満たしていたとしても仮説検証の背景を共有していないため、仮説をそのままぶつけても期待する答えは得られません
従い、「聞き方」を考える必要性が出てきますが、これは則ち、④エキスパートがどんな経験を積みどんな知識を得て問題意識を涵養してきた人かを想像し、それを踏まえて上記仮説の提示の仕方を変えることを意味します
聞き方を考える上でのポイントとして、以下3点を意識するのが望ましいと考えられます
※ここは私の経験から導いた仮説なので、他にも色々あると思います
- 相手の日常業務に近いレベル感の、具体的に語りやすいことを中心にする
  - 上記②の仮説は抽象度が高いことが多いですが、抽象的になればなるほど、エキスパートの洞察が正確さを欠きやすくなりますし、似たような話に収束して価値も低くなるので、一次情報に近い具体的に語れることを中心に話を聞きます
  - 抽象度のギャップは我々の解釈で埋めます
- 相手が強い問題意識を持っている（であろう）ことをちりばめる
  - 「これまでの経歴からこういったことに苦労しているであろう」というアタリをつけて、その内容をちりばめます
  - そうすることで、その人ならではの深い洞察が引き出せる可能性が高まりますし、それが叶わなくても、心理的な距離が近くなって色々話を聞けるようになります
- SCQAを明示する

チームとしての実践の要諦

インタビューガイドに盛り込む項目の精度を上げる（＝プロジェクトチームでの仮説検証の有効性と効率性を上げる）には、上記手順を正しく踏むことに加え、以下をチーム運営＋メンバー個々人の努力において意識するのが有効です
- ①②では、プロジェクトチームとしてどれだけ短サイクル・高解像度で情報を持ち寄って思考を同期できたか
  - 論点や仮説は上述の通り、プロジェクトでの検討を通じて更新されていきます
    - 余談ですが、仮説の更新がほとんど発生しないプロジェクトは、初期仮説の精度が高かったという観点では高く評価できますが、組織として新しい領域に挑戦しているテーマではないことを表しており、仮説の更新頻度はそれ自体では善でも悪でもありません
  - こうした論点や仮説の更新はチーム内で共有しようとしても、絶対にタイムラグが発生するので、個々のメンバーがこれを意識し、自ら同期を図る必要があります
    - 本来的にはこのタイムラグを極少化することがマネージャーの一義的な仕事ですが、実際にはリソース不足などの理由からタスクの実行工程も掛け持つことになるマネージャーが多いため、現実的にはタイムラグが生じます
    - 従い、マネージャー側からの情報の提供を前提とするのではなく、個々のメンバーが情報を取りに行く努力が必要になります
- ③では、人材要件とエキスパートとのギャップを明確にすること
  - 往々にして発生する問題が、仮説検証上必要な人材要件と我々がアクセス可能なエキスパートの経験との間のギャップです
    - 我々が伝手を辿ってアクセスできるエキスパートの範囲には限界があるため、ドンピシャな条件のエキスパートには巡り会えるケースは稀です
    - このギャップは、専門領域や職位のズレという形で顕れますが、エキスパートの発言内容にバイアスをかけることになります
  - こうした問題に対しては、「この人の立場はxxxxxなので、xxxxxと解釈するのが妥当だ」といった解釈を加えることになります
    - なお、当然のことではあります、事実と解釈は必ず弁別してクライアントに示す必要があります
  - このギャップとそれに対する解釈の必要性を事前にどれだけ具体的に想像できるかによって、どのような項目を盛り込むべきか/盛り込まないべきかの判断が変わります