どうやって統計的な発想をしているのですか？ その方法を教えてください。

この問いに答えるのは容易ではありません。これは暗黙知そのものであり、単にこういうものですと説明しても応用できないからです。

一方、こうした暗黙知こそ、伴走支援の余白を使って伝えるとうまくいくことを経験してきました。今回のエピソードは、そんな独立後の伴走支援の中での話です。

詳細はあれこれ変えており、セミフィクションとして読んでいただけるとありがたいです。

独立後に、ピープルアナリティクスの専門家という看板を掲げ、データ分析プロジェクトのお手伝いをしてきました。その中のあるプロジェクトでご一緒したのがCさんです。

Cさんは30代前半の女性エンジニア。大手インフラ系企業の中で、社内SEからHRの中の分析チームに異動してきた彼女は、データ分析プロジェクトを経験するのが初めてという状況でした。

当時、私はデータサイエンティストとしてプロジェクトに入り、あるピープルアナリティクスの分析案件にどっぷりつかっていました。Cさんは、そのプロジェクトでサブリーダとしてアサインされており、メンバーのコンフリクトを調整をするなど大変優秀な方でした。

その一方で、キャリアとしてはインフラSEの道をずっと歩んでいたので、データ分析の経験はないとのこと。基幹システムからデータを抽出したり、クロス集計をしたりすることはできるのですが、分析のアプローチがわからないという悩みがあったようです。

プロジェクトが終盤に差し掛かったころ、公式なプロジェクト進捗会が終わったタイミングで、Cさんから私に「課題の相談があるのでこの後時間ありますか？」と声がかかりました。そして、1on1で話をすることに。

そして、プロジェクト課題についてサクッと話が終わった後に、少し間をおいて彼女はこのように打ち明けてくれました。

自分でも分析できるようになりたいという非常に前向きな気持ちを感じつつも、同時に、前職であるインフラSEとの違いに戸惑っているのだろうと想像しました。

世間からみると、SE (System Engineer)とDS (Data Scientist)はIT系ということで似たような職種に見えるかもしれません。しかし、SEとDSは似て非なる職業です。スキルセットの違いはもとより、頭の使い方が180度違うといっても過言ではありません。

なぜそう言えるかというと、私自身がアプリケーションSEからDSに転じて七転八倒した経験があるからです。私は不器用でしたので、その転換に4年近くもかかりました。

私はCさんから相談を受けたときに、ぜひ協力したいと申し出ました。私はそのデータ分析プロジェクトに携わっていたものの短期的な契約であり、いつか誰かにバトンを渡す必要があると考えていたからです。

それを見越して、分析報告書だけでなく、分析に利用したPythonコードも「非公式な参考情報」としてお渡ししていました。

引き続きのときに工数を取ってトランスファーするのだろうと想像していましたが、すでに読み込んでくれていると聞いてとてもうれしくなりました。彼女には今の職場で新しいスキルを身に着けたいという意欲があったのです。

そして、契約外ではありましたが、プロジェクトの中で個別に時間を取って技術アドバイスや解説をするようになりました。

それから1か月後、プロジェクトは最終日を迎えました。その振り返りをしているミーティングの中で、Cさんは上司に「引き続き武田さんのアドバイスを受けたい」と上申したのです。大変ありがたい話でした。

その後、諸々の調整を行った上で、Cさんがメインの分析者、私がアドバイザ兼サブリーダとして育成と進捗を管理することになりました。実際の分析プロジェクトを1つ通してやることで、実践的スキルを身に着けるというものでした。

これが、私にとって初めての伴走支援の実践となりました。

伴走支援がスタートして最初のミーティングでのことです。Cさんとその上司、私の3人で分析プランニングを行いました。

テーマは組織サーベイの分析。従業員満足度のスコアを目的変数として、男女差やその他人事属性との関連を探るというもの。カチッとした因果推論でなく、ベーシックな重回帰で傾向を見出すという基本的なものに決まりました。

Cさんは元SEということもあって、Pythonの使い方に長けていました。また、公式なマニュアルや技術本からの学びも早く、手を動かすことも得意。そのため、その次の内部ミーティングでは、早々に重回帰の結果を出してくれました。

しかし、モデルの精度が上がらず、苦戦しているということでした。確かに、決定係数はほとんどゼロに近く、記述的分析としても考察が難しいという状況でした。

その後、彼女の上司から様々なアイデアや確認が矢継ぎ早に投下されていきました。例えば、

• 目的変数はどんな分布をしている？ 必要だったら対数変換したら？

• 残差は確認した？

• この変数は差分を取ったほうがいいよ。

• 交互作用はないかな。非線形な関係は仮定できない？

といった具合です。

しかし、Cさんの様子を見ていると、受け止めるだけで精一杯な様子が見えてきました。キーボードをたたいてメモを取りつつ、「それはどうやったら実装できますか？」というコメントが増えていきました。これは、分析思考からタスク思考に切り替わっていることを示すシグナルです。

そこで、私から次ような話をそっと持ち出しました。

このようにして話を一度止めて、議論をスローダウンさせたのです。そして、変数の差分を取ってみるという基本的な話にフォーカスしました。

実は、このアイデアが最も優れていたわけでも、実装が簡単というわけではありませんでした。しかし、データのハンドリングというシンプルで難しいタスクを通して、統計的な考え方を伝授できるという直観が働いたのです。

データサイエンティストにとっては、差分を取るという言葉でおおよそのイメージがわくはずです。もちろん、それは文脈によって変わり、ひとつの変数において時系列的な差分を取る場合もあれば、変数同士の差を取ることもある。また、その変数の平均との差分を取ることもあるわけです。

しかし、「差分」という言葉はSEにとっては全く別の意味を持ちます。多くの場合、ソースコードのメンテされた部分のことをイメージするのではないでしょうか。そして、差分という操作の「仕様」を知りたくなり、結果としてオペレーティブな思考に入ってしまうのです。これはまさに私が苦労した点でした。

今回はある変数について、部署ごとの平均との差分を取るという話になりました。これは別の言葉でいうと、部署別に中心化するということです。

これは、その変数（たとえば時間外や人事評価値）のベースラインが部署ごとに大きく異なるときに有効な手段です。絶対的な数字で比較するよりも相対的に比較すると異なる見え方ができるわけです。

こうした何気ない変数の操作においても、比較可能性・相対化という重要な考え方が潜んでいます。

問題は、こうした考え方の本質が腹落ちしないまま、Pythonコードを書いてもスキルは向上しないということです。

しかし、上司からタスクが振られれば、とにかく間に合わせるために、難しいことをわきに置いて実装に走ってしまうはずです。そうしなければ、次回の進捗会で困ったことになるのですから。

そのため時間がないときでも、いったん余白を取って考える時間が必要なのです。

この例では、現実に存在するタスクから一つを引っ張り上げて、じっくりと考える時間を取りました。ホワイトボードを使ってゆっくり解説し、Cさんの考えや疑問を引き出しつつ、最終的には実装方法のヒントをお伝えしました。

さて、ある程度落ちついたところで、私は意図的に次の言葉を投げ込みました。

この言葉によって、一瞬にして場の空気が変わったのを覚えています。

この問いかけは、彼女の発想の転換を促すうえでかなり重要だったようです。後々になって、「あの時の話でだいぶ統計的な考え方がわかるようになりました」という感想をいただきました。

これはデータ分析の経験がない人が普通にやることなのですが、一般的に表形式のデータテーブルがあった場合、その意味を取るために行(レコード)を横に見ていくことが多いです。

SEの目線ではレコードを一つの画面でエントリーされたものと捉えます。一方、機械エンジニアの目線では、そのレコードの背後にある設計図や仕様書をイメージしがちです。また、事務の方であれば伝票を想像するでしょう。

一方、データ分析においては、ひとつの列に同じタイプのデータ値が存在していることを前提に、その分布を見ることが基本行動になります。つまり、データは縦に見るものなのです。

このように、一般的な思考のクセとデータ分析に求められる観点は大きく異なりますが、その違いは両方を経験してはじめて実感します。また、その視点の切り替えの大変さは、敷居をまたいだ人にしかわかりません。

先ほどの問いかけはその敷居の存在を明示する言葉でした。しかし、この言葉を出すタイミングというのは結構難しいものです。

相談者が「わかるようでわからない」「でも、わかりたい」「わかったような気がするが違う気がする」という実感を持った瞬間。そこで示すことが大切です。

ここで取り上げた余白は、時間としては20分ほどだったと思います。60分のアドバイザリセッションの中では贅沢な時間の使い方になりました。

しかし、この20分こそが、彼女が統計的な思考法と向き合う効果的な一歩目になりました。

私が管理職になったのは40歳になったときでした。会社の中では遅咲きともいえる年齢でしたが、部の中では最年少マネジャーでありつつ、部全体は若いという構造。つまり、若手が集まっていたのです。その中で、人を育てることの難しさとやりがいを感じることになりました。

私が在籍していた部署はAIやデータ分析技術を活用した技術コンサル兼新規事業創出チーム。プロフィットでもあり、新しいことをやりながら利益を出し、しかもデータサイエンティストを育てなくてはならないという、なかなかハードなミッションでした。

ここで出合ったのはBさん。20代前半の男性で、私のチームの仕事が増えたことでジョインしてくれたのでした。当時は、分析プロジェクトが加速度的に増えていた時期で、常に人が足りなかったのです。

彼は非常に意欲的で一定のスキルがあるとの定評がありました。実際話をしてみると、とてもアグレッシブ。どんどん任せてほしいと頼もしい限り。その一方で、過去の経験や語り口からデータ分析スキルは初歩的なものだという直観がありました。

そんな時、非常に難易度の高い分析案件がやってきます。外部クライアントの案件。これは自分でも厳しいなと思ったものの、公式にマネジャーが手を動かすわけにはいかないので、彼に任せてみることに。実践投入が実力を測る上で有益と考えたからです。

当時は、外部クライアントに対するデータ分析支援のプロジェクトはたいてい3カ月間を1クールとしたものでした。そして、1カ月目、2カ月目、3カ月目の終わりに報告会が入るという形。

つまり、分析を開始して、初めの成果を出すまでに1カ月ほど猶予があるわけです。しかし、初めて関係性を持った外部のデータ分析チームが成果を出すには短すぎる時間です。なぜなら、クライアントの業務や組織文化の背景を十分に理解できていない状態で、期待値だけが上がっている可能性があるからです。

これは、受託型の技術支援サービスでよく起こることです。特に、コンサル特化型の会社でなく、製造業や受託SI系の会社がその業態の中で受託サービスをすると必ず生じる問題でもあります。なぜなら、クライアントは、委託者のことをコンサルではなく、ITのソリューション提供者とみているからです。

過分にもれず、今回のプロジェクトもそうした雰囲気が漂っていました。したがって、1カ月目の初回の報告会は信頼を得つつ、期待値の置き所を探るという非常にナイーブなミーティングになります。

こうした難しい状況で、しかもデータ分析タスクとして中々難しいプロジェクトになりました。詳しくは書けないのですが、予測モデルやレコメンドエンジンを作ればOKという類の話ではありませんでした。

タレントマネジメントの実現が本質的な課題でした。しかし、商談の入り方として、「人事作業が楽になる」という営業トークからスタートしてしまったので、いろいろねじれていたのです。

ここで、プロジェクトの1カ月目の目標は予測モデルやレコメンドエンジンを作ることではなく、組織の実態を探り、その特徴を明らかにするということに方向付けました。これはクライアントと私の間で調整したものでした。

私は「予測モデルやレコメンドエンジンを検討するには、データの特徴を把握する必要があります。ですので、そこからやらせてください」という話をしたのです。そして、その初期分析という時間の中で、組織実態を可視化して人事課題の対話に持ち込む作戦でした。

ガチのコンサルであればこうした案件は筋が悪いと思うことでしょう。しかし、業者にすぎない私たちが戦うには、こうしたボトムアップ的なアプローチこそ有効だったのです。

一方、データ分析者としてアサインしたBさんにもこうした事情を説明し、分析プランを練ってもらうことにしました。しかし、Bさんはキョトンとした顔で次のようなことを言いました。

この返答を聞いた時点で、私は彼の現在地をある程度理解しました。

確かに、きちんと整備されたデータテーブルがあり、目的変数と説明変数が指示されていれば、1週間とは言わず1日でプロト的なモデルは作れるでしょう。

しかしながら、今回のプロジェクトにおいては、①予測モデルを作れば終わりという単純なものではなく、②仮にモデリングをするにしても回帰的な問題ではない、ということがわかっていました。つまり、問題設定も分析手法も理解ができていない状態です。

ここから作戦を大幅に変えていくことにしました。

まずは、1カ月目はデータの可視化しかしないという宣言をしました。

本来であれば、1カ月目は可視化ベースでクライアントと握りつつも、可視化とモデリングを同時にやって問題の難しさを測るのが王道でした。しかし、そうした複雑な話ではうまくいかないだろうと思ったのです。

そこで、各変数の基本的な分布や関係性を見るようにお願いしました。もちろん、後々のモデリングで重要になる属性や特徴量を指定した上での話です。

より単純なタスクに見えますが、探索的なデータ分析でもあり、地味に工数がかかります。さらに、今回クライアントから受領したデータは一切加工がされていないデータであり、分析には全く適していないものでした。

慣れていなければ、前処理だけで2-3週間かかることでしょう。

そんな中、彼は元気よく分析計画書を作ってくれました。前処理に3日間、可視化に1週間、報告書に3日間というスケジュール。

「これはできないんじゃないかな」と内心思いつつ、そのまま任せてみることにしました。つまり、ここで余白を設けたわけです。

おそらくですが、やってみて実感しないとその難しさに気づけないと思ったからです。もちろん、タスクを絞ったことがうまく効くかもしれません。この段階ではどちらに転ぶか分からないというのが正直なところでもありました。

そこで、成果が出ない期間があることを想定しつつも、気づきのための時間を取ったのです。

さて、1週間後のチーム内進捗会でのこと。オンラインでの会話です。

Bさんより遅れているという報告がありました。原因を尋ねてみると、データ量が多すぎて前処理に時間がかかっているということでした。データ量が多いのは確かでしたが、私たちの分析サーバで処理できない量ではありませんでした。

そこで、処理が速くなる一般的なテクニックをいくつか伝えました。そうすると「わかりました！」と元気よく答え、来週早々にはできると約束してくれたのでした。

この段階で、分析（というか前処理）が終わらないことを予感した私は、同時並行で作業をやることしました。もちろん、彼には言わず、あくまでバックアップとしてです。そうすると、土日の2日ほどで前処理と基礎分析が終わりました。これで大きな問題は回避できる土台は整いました。

つまり、クライアントへの成果は最低限担保しつつ、じっくりBさんの成長を待つことができます。

翌週、進捗会にやってきたBさんの表情はさえませんでした。どうやらまだ前処理が終わっていない様子。話を聞いてみると、複雑な履歴データから年度末毎の情報をスナップショットで取ることに苦戦しているというのです。

実は、この処理はとても難しいものです。人事データ特有の難しさが潜んでいて、単にSQLで引っ張れるというものではないのです。そこで、問題の所在を確認し、解決策のディスカッションを始めました。

そうすると、彼はやや持ち直した声で「やっとわかりました。もう大丈夫です。1日で前処理を終わらせ、3日で可視化を終わらせて取り戻します」と言ったのです。

ここがターニングポイントだと直観した私は、いつもの雰囲気のまま次のような問いかけをしました。

そうすると、彼は絶句。

息をのむ音がヘッドセットから聞こえてきたまま応答がありません。しかし、彼が言葉を出すまでの間、じっと待つことにしました。

とても長く、重たい沈黙でした。

そして待つこと3分。

彼は小さな声で「…わかりません」と回答したのです。

この3分間はとても重たいものでしたが、彼が自分が置かれた状況や実力を理解するには十分意味のある時間でした。そして、プロジェクトにとっても、現在地を正確に把握する上で重要な分水嶺になりました。

この沈黙は、対話の中の「余白」といってもよいでしょう。
この余白は私がタイミングを計り、意図的に作り出したものでした。

振り返ってみると、初学者であるBさんのモチベーションを保ちつつ、その力量と成長点を見極めるために、セーフティネット貼りつつ数週間任せた。それ自体がプロジェクトの余白なのですが、その中の対話でさらに3分間の余白を生み出したというわけです。

おそらく彼にとってみると、とてもつらい数週間と3分間だったことでしょう。しかし、彼と私が現在地を理解し、良い方向に向かうために必要な余白でした。

その後、彼は大きくスタイルを変えることになりました。

指示内容がわからなければキチンと質問し、作業上のリスクを言語化する。そして、私と一緒に実装方法まで議論することで、成果を上げていく――。

こうすることで飛躍的に分析スキルが向上した彼は、プロジェクトの2カ月目には主戦力として自立した分析作業を行えるようになっていました。

その様子を見て、私は人が変わったのかと思うほどでした。

駆け出し管理職として試行錯誤の一手ではありましたが、とても意味のあるプロジェクトだったと今でも思います。

データ分析のような複雑な専門スキルを身に着ける過程では、「わからないことがわからない」という状態に陥りがちです。それは私自身もそうで、SEからデータ分析者に転じたときに、前にも後ろにも進めない状況になったのを覚えています。

Bさんは吸収力も意欲もあったのですが、自分自身の現在地を把握できていないという課題がありました。これはかつての私の姿と完全に重なるものでした。

* * *

このエピソードのポイントは、余白でメタ認知を高めたということにあります。具体的には、3つの意図的な仕掛けがありました。これが余白のデザインです。

1つ目は、タスクをあえて絞ること。1カ月目は可視化だけという宣言。全体像が見えていない初学者に複数の目標を同時に持たせると、現在地がさらに見えなくなる。シンプルなタスクに絞ることで、何ができて何ができないかが浮かび上がりやすくなります。

2つ目は、セーフティネットを黙って張ること。私が並行して前処理を走らせていたのは、クライアントへの成果を担保するためでもありましたが、それ以上に「Bさんが自分の限界に向き合う時間を確保する」という意図がありました。これは場としての余白です。

3つ目は、問いかけて、待つこと。「初手を具体的に教えてください」という問いは、答えを引き出すためではなく、彼自身が現在地を見るための鏡として機能させたものでした。そして、答えが出るまで沈黙を破らない。この3分間の余白がポイントだったと思っています。

データ分析者の育成や内製化には時間がかかるものです。技術をコツコツ学ぶことも大切ですが、プロジェクトの中で余白を作り、実践から学ぶ環境を整えることがより重要だと考えています。

独立を宣言して半年後のことでした。古巣でお世話になった方から久々に連絡が来たのです。一緒に仕事しない？と。

当時、独立のきっかけとなったAI活用支援コンサルの仕事が早々に終息してしまい、長い長い夏休みを過ごしていたところだったので、本当にありがたい話でした。

先方はSE時代に現場で一緒に戦った同志であり、SEからデータサイエンティストに転じた後もたまに連絡を取り合っていました。今は独立IT系開発会社の役員をされているとのことでした。

早速お話を伺ってみると、自社コーポレートサイトをリニューアルしたいという話でした。自社サイトは2000年ごろに構築してからほとんど変えておらず、デザインが古くて何とかしたいと。

実際にWebサイトを見てみると、非常に懐かしい雰囲気のサイトデザイン。古き良きインターネットの香りがあり、これはこれで味があると思ったものの、新着情報が十数年近く更新していないこともあって、稼働している会社かどうかわからないという問題がありました。

先方のご依頼は、エンジニアとしてWebサイトをリニューアルしてほしいという話でしたが、残念ながら私はそれを専業にしていません。そこで、ITコーディネータの知見を活かしてアドバイスをさせてほしいという話をしました。

ご希望と異なる提案だったので無償で動きはじめたのですが、先方よりきちんと対価を払うから一緒に完遂してほしいというお話をいただきました。

本来はこちらから有償コンサルの提案をすべきだったところ、クライアントから逆提案をされるという事態に。本当にありがたい話で、胸が熱くなりました。

本格的にコンサルを開始し、要件定義を行っていきました。しかし、いきなり要件定義書を作ることは避け、対話中心のアプローチをとることにしました。

というのも、サイトデザインやコンセプトに関する具体的な要望が見えてこないという状況だったのです。

もちろん、この段階でも、「要件定義書」や「RFP（提案依頼書）」のひな型を作ってガリガリ具体化していくことはできたでしょう。しかし、この状態で理詰めで具体化しても、何かよくないんじゃないかと直観的に思っていました。

そこで、要件に関する話はミーティングの3割程度に留め、残りの時間をゆっくり使って事業の課題を探ることに。

とはいえ、Webサイトの要件の話をしているときに「事業の課題は何ですか」と尋ねてもまずうまくいきません。そのため、まずは次の問いからはじめていきました。

そうすると、「新しい人を採用できたんだけど、うちのWebページをみて入社を躊躇したって言ってたんだよね。入ってくれたからよかったけど」というエピソードを語ってくれました。

これまでもサイトデザインの問題は見えていたものの、優先順位は低いままだった。しかし、人を増やしていく中で、問題が顕在化しつつあったということでした。つまり、採用戦略上の問題があり、そのことがこの会社にとって重要な課題だったのです。

このようにして、コストをかけてWebサイトをリニューアルするという話に経営がGOをした背景が、少しずつ見てきました。つまり、解くべき課題の正体がはじめてわかったのです。

一方、一度のミーティングで課題が言語化されたわけでは決してありません。先ほどの問いを入口として、少しずつその輪郭が見えてきたというのが実際のところです。

Webサイトリニューアルの要件定義書を作るという目的を念頭に置きつつも、性急に結論を急がず言葉を重ねていったことが、このプロジェクトの成功要因となりました。

私は、こうした対話の時間を「余白」と呼んでいます。
余白とは、単なる空白ではなく、対話の中で意図的に作られた空間です。

それにより、アドバイザーはクライアントに起きていることを注意深く観察する。一方、クライアントは、自身が直面している課題の根本や本音を自然と体現する機会を得るわけです。

こうした相互作用により、テーブルに並べられた問題を超えた真の課題を発見したり、新たな解決策を見出したりすることができます。まさに、対話が創造性を生み出す瞬間です。

私は、技術系リーダーとの1on1や、ピープルアナリティクスの伴走支援をする中で、無意識に余白を活用していることに気づきました。

あなたの周りに、余白を必要としているリーダーを見かけたことはないでしょうか。あるいは、あなた自身、日々課題解決に追われているのに、達成感が得られないと感じることはないでしょうか。

そんな時は、いったん手足を止めて余白に入ることで、全く違う風景が見えてくるかもしれません。