エンジニアであれITコンサルであれ、抽象的で不確実性の高い、要は「いい感じに進めて！」的なフワッとしたタスクは避けて通れません。

• 目的: 目指したい姿は決まっている
• 仮説: 現状の課題はヒアリング結果からざっくり候補はある。正解とは限らない
• 方針: どう解決するか未議論

例えば、データガバナンスの文脈で説明すると、「全社でデータ利活用促進させたい」というゴールに向けて、現状の「データ権限管理が厳し過ぎるかも」とか、「データ共有文化が無いから」などの仮説があり、「どう持っていくのが良いんだろうね？」とチームで議論が始まったような状況を、ここでは想定します¹。

「目的」自体を否定しないのでなければ、よくある進め方は、やるべき「具体的な課題」が何であるか分析・分解・仮説を立てること。そして仮説の真偽を、ヒアリング・実データ・試行などから検証する流れ。課題さえ明確にできれば、対応方針はよりクリアに考えることがでます。

目的が迷子になる

ところが、そういったなぜやるのか（Why）見失ったまま、How（検証などの実作業）を進めてしまうアンチパターンもある。

• 「判断材料が少ない。とりあえずシステムの権限データをまとめよう！」
• 「どうも制御対象のデータへ業務分類に応じたタグを付けていくと、10個に大別できそうだ！」

その結果、レビューで次の指摘を貰う。

• 「この整理、何のためにやってるんだっけ？」

このとき、一言で作業目的を言えず、やってきたことをつらつら説明し始めたら黄色信号。目的がズレている可能性が高いでしょう。

こういった、いわゆる「作業の目的化」について、同僚とSlackのスーパー雑談チャンネルで議論しました。持つべきものは悩みを共有できる仲間。そこで出た意見をまとめます。

なお、課題とその対応について方向性が見えている状況であれば、むしろ手を動かしながら考えることが正解な場面もある。例えば、データ分析での仮説検証やPoCやアジャイル開発がある。この場合は、クイックに手を動かして、可視化結果やモノを見せながら、話を進めることが普通で、その有効性については論じるまでもないでしょう。

手を動かす仕事の魅力

ビジネスの問いは、答えが一つではない。フワッとしたお題に向き合うのは、結構なエネルギーを消耗する。

また、この手に共通する前提として、どう進めるのが良いか、だれも正解は持っていないです。

• 本当に権限設定に問題があるのかは不明。仮に問題があるとしても良いが、何らかの裏取りは必要
• データ共有文化が無いというのは、どういうことだろうか。それがどういう問題を生んでいるのだろうか
• 他に課題は無いのだろうか。そもそも、現状どのようなデータ利活用のユースケースがあり、現場では何に困っているのだろうか？

上記のように、状況を整理しつつ、目的（データ利活用促進）を進めるうえで本当に解くべき課題を特定する。そのために現時点で一番もっともらしく思える仮説をおいて、証拠を集める。仮説思考。

しかし、仮説思考での仕事の進め方は、ジュニアやシステム構築に特化したキャリアの人には、「正直どこから手をつけるべきか分からない」と映る人も。こういった抽象的な仕事に比べると、眼の前の具体的な作業が持つ魅力は確かにあります。

• やればやっただけ確実に “アウトプット” を出せる安心感
  • 作業報告が楽
• 作業イメージが湧きやすく、手を付けやすい
  • 手を動かしている最中は作業に集中できるため、悩まなくても済む

不確実性という名のストレスから逃れるため、「とりあえず手を動かす」ことが一種の逃避になっているかも。そして、何か成果を出さないという焦りもある。または、「できそうなことがそれしかなかった」というのも正直ありそう。また、具体を手を動かしながら整理する中で答えが見つかるのでは無いかという淡い期待もあると思う。帰納法的な思想。

しかし、フワッとした仮説で、作業を始めてはならない。仮説の解像度が低いまま具体的な作業を行うと、それ自体が目的になってしまう。これは、旅先が山か海かも決まっていないのに、履いていく靴を決めるために今の流行を調査しているようなもの。

これが、仮説を作り出すためのインプットとして、短時間だけざっと具体に目を通すのであれば良い。むしろ、ある程度インプットがないともっともらしい仮説は生まれないため必要作業でしょう。問題なのは、仮説なしでそのままインプット資料から、遷移図やマトリクス図などに、答えを探して整理を始めること。

途中で目的を見失う

前節の亜種で、作業途中に目的を見失うことも多い。純粋に作業が楽しくてというのは余り聞かない。多くは、作業を進めていく中で、当初の「仮説」が崩れてしまい、そのまま進めても意味がなくなってしまったにも関わらず、手を動かし続けてしまうパターン。これは中堅になっても陥りがち。

迷ったら、常に「なんでこの作業をやっているんだっけ？」と自問自答する。目的や仮説を振り返って、今の作業がそれからズレているのであれば、なるべく早めに軌道修正すべき。もし、自分で答えが出ないようであれば、すぐにリーダーにエスカレーション。

作業を完遂させることは必須条件では無く、目的を果たせれば何でも良いためです。

手戻り

例にあげたケースにおいて、逃避しても結局は手戻りを生みます。

真面目に作業したアウトプットをレビューに出すと、「これが、何の目的でしたっけ？ だれの何を解決するために作ったんでしたっけ？」と問われる。レビュアー側も意地悪をしたいわけではない。せっかく作った作成物を無駄にしないよう、作業の意味を再定義したり、別の場面で活かせないかの努力も試みるが、上手くいくかは運次第。儚い。

基本的に、手を動かすような検証作業は、「仮説」に紐づいていないと意味がない。今回だと、仮説は、目的を達成するために解くべき課題のこと。例えば、現在のデータ利活用が進まない課題の原因を、データ特性に見出すという「仮説」を置いているのであれば、その検証には意味があります。

そもそも、何も置いていないのであれば、「じゃあ何のためにやったの..？」に答えることができない。お互い辛い時間です。

まず、データ利活用の促進のために、何をやるべきか？という問いに向き合うべきであった。その問いのために現状の課題を集めたり、何が課題かのファクトを集めることができなければ、仮説を置いて何が問題であるかを分解、整理すべきでした。

どうすべきか

作業の着手「前」のすり合わせが大部分。

リーダー視点

• 作業目的の「腹落ち」を徹底させる
  • 作業の達成条件やなぜ行うべきかの「Why」をすり合わせる
• どれから着手するか目線合わせ
  • これからやろうとしているのは、仮説を出そうとしているのか、仮説を出すためのインプットを行うのか、目的自体の妥当性を考え直そうとしているのかなど、何をどういう順番で行おうとしているか、進め方を認識合わせする
• 背景知識を同期する
  • もし、認識合意するために欠けている情報があれば、この場で潰しこむ
• 作業の背景と指示は言語化して、チャットで備忘しておく
  • 信頼できるメンバーならともかく、この手の作業に慣れていない場合、思ったよりも目的を見失いがちである。そのため口頭でのすり合わせやGeminiによるメモだけに頼らない方が良い。Geminiによるメモは基本、メンバーは読まないと思った方が良い

後は、実践を繰り返すのみ。次に何をしようとしているか聞けるタイミングで、「その作業で解決しようとしていること確認して良い？」と聞いて、視座を引き上げる。愚直な取り組みで大変ですが、これしか無いと思います。

スケジュールというかタスクの期限感は最初に指定すべきでしょうが、個人的に難しい。厳しくし過ぎるとアウトプットをかさ増しするために、仮説ではなく手を動かす作業に向かいやすい傾向にも感じる。いっそ思い切って1, 2時間考えてみて結果を教えて、といったマイクロマネジメントをしても良いかもしれないが、マネジメントの負荷が半端ないし、おそらくお互いワクワクしない。

難易度を下げるのも大変だけど有効。ストレッチゾーンになるように調整するのはコーチ側の責務。

• 上段部分は巻き取る（難しい最初に考え方はマネジメント側で決めてしまう）
• テンプレートを渡す（思考の枠組みだけはこちらで決めてしまう）

調査など手を動かすタスクが別にあれば、そちらを任せるのも１手。しかし、成長観点だとどうなんだろうか。問題の先送りと言えなくもない。

メンバー視点

• タスクを腹落ちさせる
  • 以下のどちらかの言葉が出るまで理解度を深める
    • 「その目的とこの状況なら、確かにこのタスクから着手すべきですね」
    • 「その目的とこの状況なら、このタスクはやらなくても良いとか、優先度が低いんじゃないですか？」
• 次にやる作業の背景にある仮説を、一文で説明できなければ着手しない
  • ❌️「ユーザーの傾向を掴むために、データを分類する」ではまだ弱い
  • ✅️『〇〇という理由で解約が増えている』という仮説を検証するために、顧客データと利用履歴を××の軸で分類してみる
  • 一文が出てこない場合は、仮説を練り直すサイン
• どこから手を付けてよいか分からなくても、やることを変えない
  • リーダーと合意を取ったことと違うことをやることになったら、すぐに方向性を確認する
• 仮説が作れない場合は、だれかと話す
  • Geminiでも良いかもしれないけど、できればチームメンバーを捕まえて壁打ちすること
  • 「今、こういう目的のために、こういう仮説を立てて、この作業から始めようと思うんですが、どう思いますか？」
• 伸びる人の条件についてSlackで話したにも書いたけど、検討内容はなるべくオープンにしつつ、なるべく早くチームメンバーに共有してフィードバックをもらう。1日がかりの仕事を否定されるのは辛いことだが、30分だったら諦めがつく。座礁したと感じたら、早く出して楽になろう
  • 早めに方向性をすり合わせる

これは、仮説思考の話をしている？

Yes。今回話した話は、仮説を持って作業をしよう。また仮説を見失ってしまわないようにしよう、とシンプルに言い換えることができます。このあたりの話は、先人が様々な言い方で教えてくれている。多くの人の思考モデルを知っておくと、自分に響く考え方が見つかるかもしれないし、メンティーにあった響かせ方ができるようになるかもしれない。

• 【ブログ】エンジニアが持っておくと幸せになれるビジネス視点
  • 『すべての活動において重要なのは「目的を見失わない」こと。目的を定め、必要な事実（ファクト）をしっかりと収集する。そして、「目的」と「手段」をつなぐために「方針」として言語化する』など、秀逸
• 【書籍】コンサルティング会社 完全サバイバルマニュアル
  • 4章がまるまる「論点思考」「仮説思考」 について解説してくれている
• 【書籍】コンサル一年目が学ぶこと
  • 2章のコンサル流思考術は良いぞ。「考え方の考え方」も良いし、「仮説思考」もバッチリ説明がある

もしこの手の作業が初めてのメンバーであれば、上図のような作業フローの全体感は早めに作成（提供）しておくと認識齟齬が減るため、お勧めです。

まとめ

焦ってアウトプットを出そうとすると、つい目の前の「How」に没頭してしまう時があります。やった感は出るけど、相手のためにならないものを作っても意味はない。プロダクトアウトではなくマーケットイン。ズレたまま進んでは手戻りです。

手を動かす誘惑に打ち勝って、不確実性と向き合おう。できる限り最初に腹落ちさせつつ、途中で迷ったら「すいません、今何をやっているか目的がわからなくなってきました。壁打ちしてもらえませんか？」と対話を選ぶようコントロールすると良さそうです。