待つことを、デザインする
沈黙の3分が、人を変えることがある
仕事と組織の中で繰り広げられる様々な対話。その中の「余白」が人と組織を成長させると私は考えています。今回のエピソードは、まだ私が組織の中にいたときの話です。もちろん、詳細はあれこれ変えており、セミフィクションとして読んでいただけるとありがたいです。
私が管理職になったのは40歳になったときでした。会社の中では遅咲きともいえる年齢でしたが、部の中では最年少マネジャーでありつつ、部全体は若いという構造。つまり、若手が集まっていたのです。その中で、人を育てることの難しさとやりがいを感じることになりました。
私が在籍していた部署はAIやデータ分析技術を活用した技術コンサル兼新規事業創出チーム。プロフィットでもあり、新しいことをやりながら利益を出し、しかもデータサイエンティストを育てなくてはならないという、なかなかハードなミッションでした。
ここで出合ったのはBさん。20代前半の男性で、私のチームの仕事が増えたことでジョインしてくれたのでした。当時は、分析プロジェクトが加速度的に増えていた時期で、常に人が足りなかったのです。
彼は非常に意欲的で一定のスキルがあるとの定評がありました。実際話をしてみると、とてもアグレッシブ。どんどん任せてほしいと頼もしい限り。その一方で、過去の経験や語り口からデータ分析スキルは初歩的なものだという直観がありました。
そんな時、非常に難易度の高い分析案件がやってきます。外部クライアントの案件。これは自分でも厳しいなと思ったものの、公式にマネジャーが手を動かすわけにはいかないので、彼に任せてみることに。実践投入が実力を測る上で有益と考えたからです。
当時は、外部クライアントに対するデータ分析支援のプロジェクトはたいてい3カ月間を1クールとしたものでした。そして、1カ月目、2カ月目、3カ月目の終わりに報告会が入るという形。
つまり、分析を開始して、初めの成果を出すまでに1カ月ほど猶予があるわけです。しかし、初めて関係性を持った外部のデータ分析チームが成果を出すには短すぎる時間です。なぜなら、クライアントの業務や組織文化の背景を十分に理解できていない状態で、期待値だけが上がっている可能性があるからです。
これは、受託型の技術支援サービスでよく起こることです。特に、コンサル特化型の会社でなく、製造業や受託SI系の会社がその業態の中で受託サービスをすると必ず生じる問題でもあります。なぜなら、クライアントは、委託者のことをコンサルではなく、ITのソリューション提供者とみているからです。
過分にもれず、今回のプロジェクトもそうした雰囲気が漂っていました。したがって、1カ月目の初回の報告会は信頼を得つつ、期待値の置き所を探るという非常にナイーブなミーティングになります。
こうした難しい状況で、しかもデータ分析タスクとして中々難しいプロジェクトになりました。詳しくは書けないのですが、予測モデルやレコメンドエンジンを作ればOKという類の話ではありませんでした。
タレントマネジメントの実現が本質的な課題でした。しかし、商談の入り方として、「人事作業が楽になる」という営業トークからスタートしてしまったので、いろいろねじれていたのです。
ここで、プロジェクトの1カ月目の目標は予測モデルやレコメンドエンジンを作ることではなく、組織の実態を探り、その特徴を明らかにするということに方向付けました。これはクライアントと私の間で調整したものでした。
私は「予測モデルやレコメンドエンジンを検討するには、データの特徴を把握する必要があります。ですので、そこからやらせてください」という話をしたのです。そして、その初期分析という時間の中で、組織実態を可視化して人事課題の対話に持ち込む作戦でした。
ガチのコンサルであればこうした案件は筋が悪いと思うことでしょう。しかし、業者にすぎない私たちが戦うには、こうしたボトムアップ的なアプローチこそ有効だったのです。
一方、データ分析者としてアサインしたBさんにもこうした事情を説明し、分析プランを練ってもらうことにしました。しかし、Bさんはキョトンとした顔で次のようなことを言いました。
目的変数と説明変数は何ですか？ 予測モデルを作るのですよね。予測モデルなら1週間あればつくれますよ。
この返答を聞いた時点で、私は彼の現在地をある程度理解しました。
確かに、きちんと整備されたデータテーブルがあり、目的変数と説明変数が指示されていれば、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分間の余白がポイントだったと思っています。
データ分析者の育成や内製化には時間がかかるものです。技術をコツコツ学ぶことも大切ですが、プロジェクトの中で余白を作り、実践から学ぶ環境を整えることがより重要だと考えています。