どうも（自称）若手分析官の岡部です。
年齢のことはさておき3年目ですので名実ともに立派な（？）若手だったりします。
（とはいえインターンでお邪魔していたり、なんだかんだで色々ごにゃごにゃしていたりしたので「お前は一体何年目なんだ？」との疑問もよく受けますが、、、）
本記事では自分のようなひよっこがひよっこながらに仕事をするなかで考えた仕事に対する姿勢を紹介します。
この記事は今年の2月だかに弊社のデータサイエンス事業部定例でお話しさせていただいた内容に基づきます。その時には話した内容をすぐに記事にしようと思ってました。
思ってたんですが、「まとまりがねえな、もうちょいまとめてからにすっか」とつい先延ばししてしまった経緯があります。
そして先延ばしは良くない（戒め）。全くまとめる時間など取らず結局こんな梅雨時期まで引き伸ばしてしまった。（2022年6月末現在、東京は猛暑に襲われ連日30度越えの真夏日を観測、故にすでに梅雨ですらないまである）
その間季節は流れ、新入社員の方々をお迎えし、5月病の季節を乗り越え、そして猛暑の6月へ。どうしてこうなった。。。ウッディだったらとっくに会社辞めてる。
とまあこんな経緯があり書くタイミングを逃したのも事実。しかし、ブログを書かないのもなんだし、まとまりないのもそれはそれで若手が必死に格闘してる証拠で生々しい気もします。本当は僕だってもっとMECEとか使ってまとめたい。でもないものねだりしても仕方ない（ってヒル魔も言ってた）ので書きます。
長くなりましたが前置きはこれくらいにして本文にいきましょう。
何をなぜ話すか
- 一般的に、経歴の長い上司からのアドバイスは抽象度が高く新卒の人はそもそも理解できない（理解できてたらそもそも悩まない）
- ゆえに、新入社員に近い自分がこの2年で得られた教訓を出来るだけ具体的に記述
【注意事項】
- 職種に関係なく成り立つことだとは思うが、自分の観測者バイアスがかかっている可能性大（あくまで元は社内向けに作ったものだったので特に）
- 自分自身が完璧にできているわけではない、むしろ自分への戒め的意味もふんだんに込められている
- 長くなったのでタイトルだけ見て気になったところだけ読むのがいいかもしれません
【総括】他者視点を持って相手に伝えること
タイトルの「たったひとつの考え方」とはこれです。
図らずもUSJのカスタマーセントリック的なやつと似てますね。
こうやってキーメッセージにするとやはり大量の背景を切り捨てることになります。そこで少しだけ補足すると、ここで言いたいことは「相手の立場で物事を考える」ということです。必要なのは想像力です。
どんなに頑張っても100%人の気持ちはわからない。
気持ちはわからないのですが、立場や状況を想像することはできます。
それをやろうということです。
決して自分の都合よく相手にへり下る「忖度」のことを表しているわけではありません。
忖度の場合は、相手に与することで自身がメリットを享受しようとしている点で、あくまで視点が自分ですから。
あれれ〜？おかしいぞ〜？具体的に、って言ってたのに抽象的じゃない？
と思った方、しばしお待ちください。これから少しずつ具体的に説明していきます。
結論から・全体像から・簡潔に
相手に伝える時は結論から話し、全体像を提示し、簡潔に話しましょう（有言実行）。
なぜ大事かというと陳腐ではありますが、報告相手は忙しいからです。
そんな忙しい相手の立場で考えると、なんの話をしていて（全体像）、何が言いたい（結論）かを１秒でも早く知りたかったり（簡潔）します。
「昨日さ〜ウチさ〜渋谷に行ったじゃん？友達まってて〜マックに寄ったんだけど〜」
といった雑談や
「その時地下にワインを取りに行っていたAさんには当然犯行は不可能、また指紋が現場に残っていたBさんもこの考え方でいくと犯人ではない。そう犯人は、、、ギィー（扉の閉まる音）」
といった居眠り探偵の謎解きのような話し方は私生活ではよくある（？）かもしれませんが、仕事では持って回った言い方は好まれません。
単刀直入に「犯人はCさんです。なぜなら証拠のハンカチが右ポケットにあるからです」と話しましょう。
とまあ理想論を言えば上で言った通りなんですが、これ言うは易く行うは難しで、実際に報告する状況になると結構テンパってどうでもいい話から始めちゃったりします。
そんな時僕が心がけているのは単純なんですが「一呼吸おく」ことです。
- 相手に自分から話しかけるケースでは一旦落ち着いて整理してから話し始める。
- 相手から話しかけられたケースでは焦って適当なことを言う前に、一呼吸おいて話しの流れを整理する。
もしかすると「なんだこいつ、反応鈍いな」と思われるかもしれませんが、支離滅裂なことを話して「もういい！話にならん！」となるよりは100倍マシでしょう。
案外その3秒の一呼吸が、相手と自分の時間を10分節約することになったりします。
あと、どうしてもまとまらなかったり相手の質問に即答できないケースではそれを率直に相手に伝えた方がいいと僕は考えてます。
例えば
- まだあまり整理できていないのですが、迷っていることがあって〜〜なんですが、、、
- それはまだ検討できてませんでしたが、直感的には〜な気がします。後ほど詳細を確認しておきます。
的な枕詞が最初にあれば、少なくとも相手は「あぁ、まだ頭の中がまとまってないだけなんだな」ということを念頭に会話できるからです。
最悪なのは、自分の状況や意図を何も伝えないまま、自分都合で話し始めてしまうこと。
これは聞いてる側からすると辛い。
（うーん、相談なのか、依頼なのか、何を聞かされてるんだろう、、、）となります。
「結論がまだない」という結論や「全体像が描けてない」という全体像を伝えましょう。（ドヤ顔）
母集団の定義・総数やフィルタ条件を明示（特に資料作成時）
これは分析業務をする人向けなので対象者は限られるかもしれません。ですが、大半の仕事は数字で話をすると思うので、対象者は多いと思ってます。
唐突ですが、以下のようなケースを考えましょう。
- サービスの解約モデルを作りました、精度は90%でした。このモデルを本番運用に回すべきだと思います。
- 頼まれていた昨年一年の売上を集計したところ1億円でした。
- アンケート結果によると95%のユーザーが新しい商品を欲しいと言っています。
こんな報告をする時です。
どうでしょう？おかしいところに気づくでしょうか？
一見すると別におかしなところはないように見えます。
ですが、数字が頭に入っている上司やクライアントの方であれば、矢継ぎ早に質問されること間違いなしです。
- 予測対象のユーザー抽出条件は？その時のユーザー数は？どの期間のユーザーの話？
- 1億？少なすぎない？セクションは？エリアは？プロダクトは？どこの何を集計したの？
- アンケート総数は？用意されている選択肢は？そのうちどの選択肢を欲しいと定義したの？95%って高すぎるよね、大半が20代女性のアプリユーザーだけに聞いたんじゃないの？
などなどといったような質問です。
確かに口頭ベースであれば、まだ会話を重ねることでこれらの疑問は解消できます（できるようにしておきましょう。）
しかし、資料となると話は変わります。相手がその資料を読んでいる時にあなたが目の前にいるとは限らないのですから。
相手の頭に大量に疑問が湧くようでは資料自体も読んでもらえません。当然作成する資料の目的にも依存するのですが、少なくとも相手が持ち帰って確認するような資料では集計定義や抽出期間、フィルタ条件、（割合だけでなく）総数、などを記述するようにしましょう。
同時にある程度は自分で検算できるとなおよきです。
自分が出した1億という数字は果たして正しいのか？多すぎないか？少なすぎないか？
とかそのようなイメージです。（この検算に関してはたくさん言いたいことがあって長くなりそうなのでまた別の機会に書こうと思います。）
資料作成では口頭での説明がなくても伝わるように
一つ上の項目と被る部分も多いのですが、こちらは数字によらずより一般的に情報に不足のない資料を作ろうといったニュアンスなので分けました。
例えば、
- 資料やデータの格納場所
- 参考文献があるならその引用、Webサイトであればリンク
- このページで言いたいことはなんなのか？そのメッセージ
特に3番目。プレゼン時には自分が喋っているし、自分にとっては自明なので口頭で補足しがちです。でも相手には伝わりません。
特に資料だけを読んでいる人はちんぷんかんぷんです。
こうやって書くと当たり前のことばっかなんですが、僕は意外と気づくのに時間がかかりました。自分にとっては自明ばかりだからですね。
ただやっぱり相手の立場で考えると検証したい時にデータの場所がわからないと困るわけです。メッセージがなく図だけ見せられても分からないわけです。
ということで意識的に「何も知らない人」の目線で資料を見返すようにしています。
報告相手の報告相手のことを考える（上司・社長・クライアント・株主 etc.）
さて、資料を受け取った相手はどうするのでしょうか？
「その資料の内容を他の人に説明する」のです。
例えば
- クライアントへの報告資料は、そのクライアントの上司への報告資料に使われる
- 上司への説明資料はその上司への説明資料に使われる
- 社長への報告資料は株主やメディアへの説明に使われる
などなど、自分が作った資料は自分が報告する相手以上に広がって行きます。
だからこそ、報告相手は細かいことや理解を確認するような質問を次々にしてくるのです。そうしないと自分が説明できないから。
とすると「良い資料」というのはなんでしょう？
上記のことを勘案すると、報告相手が資料を作りやすいような資料、というのがそのひとつの解になるのではないでしょうか。
そしてそのためにまずは、上でいった「定義や集計方法を明示」や「データの場所やソースを明示」といった基礎的なことを徹底することが重要だと考えます。
実はこれ以外の項目はビジネスだけでなく、学術の世界でも共通してることばかりなんですが、この項目だけはビジネスの世界特有です。（と僕は感じてます）
大規模な実験グループなどを除くと、学術の世界では人に報告してもらうというケースがあまりない一方で、ビジネスの世界では報告のための資料のための資料を作るケースは若手であってもままあるので。
個人的には企業で働き始めて一番目から鱗だったのがこの項目だったりします。
言葉遣いには細心の注意を（相手の言葉遣いに合わせる・言語によって思考は規定される）
言葉遣いには細心の注意を
僕が入社したての頃です。
Google Analyticsの分析報告で「セッション」と「ページビュー」をごちゃ混ぜにして話していたことがあり、その時に上司から「タイ米と日本米を同等のものとして話すな」といったご指導を承ったことがありました。
博士研究者というバックグラウンド的に、自分はそこそこ注意深く言葉を定義していると思っていたのですが、なんてことはない。
意識しないと言葉の定義が曖昧なまま分析を進めてしまうわけです。
それ以来反省し、言葉の定義には最新の注意を払うようにしました。そして気がついたのですが、これは何も相手に伝えるためだけではなく、自分の理解の手助けにもなります。
例えば上の例で言うと「セッション」と「ページビュー」を明確に定義することで、Webサイトデータ集計の際の基本的な考え方が身につきました。
言語によって思考は規定される
後から知ったのですが、言語学は哲学の一大分野でもあるようです。
自分なりに本などで読んだ知識を簡単にまとめると以下のようになります。
- 人間は言葉によって思考する
- その際、命名という行為は区別することに対応する（例えば「セッション」と「ページビュー」）
- 従って、名前を持っているものは意味があって（他の対象との区別のために）命名されており、それは思考する上で重要な違いである
（色々他にも面白いトピックがあるので別の機会で詳しく書きたい）
ということで、やはり思考する上でも命名や定義は非常に本質的な役割を持つのです。
相手の言葉遣いに合わせる
例えば会員識別IDのことでクライアントや別部署の人と話したいケースを想定しましょう。
この時、分析をしている自分は会員識別IDのことを、データベースでの名称「member_id」で呼称します。だって分析するときに頭の中でそう呼んでるから。
一方で相手が、Webサイトの運営に従事している方の場合、会員識別IDのことをWebサイトに準じて「会員番号」と普段から呼称していたりします。
はい、この瞬間にミスコミュニケーション発生です。
「え？member_idって何？会員番号のこと？ならそう言ってよ」となります。
（は？それくらい伝われし）という気持ちはグッと堪えましょう。
これくらいのケースであればすぐに解消されると思うのですが、頑なに「member_id」と呼び続けると意外とバカにならない心の壁を相手に作らせてしまう気がしてます。
コミュニティに属する、同じ村人として親近感を持ってもらうためには、同じ言葉遣いであることが同じ釜の飯を食うのと同じくらい重要なので（自分調べ）。
冗談はさておき、つまらないことで障壁を作ってしまって、通したい意見も通らなくなるのはあまりにも勿体無いです。特にこだわりがない言葉に関しては相手の言葉遣いをなるべくトレースしましょう。
上司含め忙しい人に報告するときは判断材料を準備しておく
自分が悩んでいることは上司からしたら屁でもなかったりします。
「もうどうしたらええか分からん」となった時は素直に相談しましょう。
考えることは重要ですが、悩むことは本当に生産性がありません（自分への戒め。）
その時に重要なのが、判断材料を用意すること。
全体像の話とも関係しますが、
「選択肢A,B,Cがあって、それぞれこんなメリデメがある。検討したが決められなかった。どうしたらいいでしょう？」
といった材料さえあれば大抵1秒で「んーBだね」と判断してくれます。
なので、行き詰まった時は悩むのではなくて、相談する。そのための材料を整理する。
それが重要だったりします。そして案外整理すると自分でも選択肢が絞れてきたりするものです。
たまに上司も「えっ、それは、どれだろ、、、？」ってなる時がありますが、その時は本当に現時点で特にベストな選択肢があるわけではない可能性が高いです。
その時はもう、決める勇気を持ち、選んだ選択肢で納得できるようなロジックを組み立てることがやることになります。（次の項目に続く）
論理的≒「選んだ選択肢（＝結論）に納得してもらえるような道筋の提示」
論理的。
深い言葉です。
仕事ともなれば1日100回は耳にする言葉。
しかし、その意味するところは人によって違ったりする。
この話題も言いたいことはめちゃくちゃあるので詳しくは別記事で書きたいんですが、仕事で重要な「論理的」は僕の中ではなんとなくこれじゃないかなというのがあります。
それは、「選んだ選択肢に納得してもらえるような道筋の提示」です。
数学の世界では論理的に思考していけば解に辿り着きます。これが数学の世界での「論理的」です。
一方で、現実の世界では論理的にいくら考えても解が絞り込めないケースがままあります。
そんな時はもうカンや度胸で決めて「なんとなくこれがいいと思うんや！」と押し切るしかないのでしょうか？
いいえ、そんなことはありません。それでは周りは納得してくれず反対も多いでしょう。
そこで「論理」を使うわけです。
ここでの論理は「正解を選ぶための論理」ではなく「選んだ選択肢を正解にするための論理」ということになります。
「確かにこの道筋で考えていくと、その選択肢を選ぶのがいいように思えるな」
と相手に納得してもらうこと、それが仕事で重要な「論理的」だと僕は考えています。
納得してもらえなくても、道筋さえ通していれば
「なるほど君の言いたいことはわかった、でもこの部分は本当なのか？」などと建設的なディスカッションができるようになります。
なので自分の考え（なぜその選択肢か）を相手に理解してもらうようにしましょう。
ここでも相手の立場や状況、前提知識を想像しつつ伝えることが重要になります。
上司から期待されていることを知る
最後は自分に期待されてることを知りましょう、という話。
それを語る上で面白い記事を見つけたのでまずはそれを紹介します。
管理職と新入社員の意識比較調査、意識のズレから生じたギャップ
管理職1,000人、新入社員4,000人を対象にしたアンケートで
- 管理職には部下に新入社員時代のうちに身につけてほしい能力」
- 新入社員には「社会人1年目で身につけたいスキル」
をそれぞれ尋ねたものです。結果は両者の間に乖離があり、
- 管理職の人はタイムマネジメントや傾聴力を新入社員が思っている以上に求めている
- 逆に新入社員が思っているほどパソコンスキルやロジカルシンキング、マナー、専門性のようなわかりやすい個人の能力は求められていない
もちろんバイアスのあるサンプルではあるので注意は必要ですが、この結果に激しく異議を唱える上司の方もそうはいない気がします。
要は、エクセル術・BIツール・機械学習・統計学・SQL・Webフレームワーク etc.の前にまずは大前提としてタイムマネジメント力が新入社員には求められているのです。
なぜかというと管理職の方は爆速で煌びやかな結果を出すことを期待しているわけではなくて、とにかくスケジュールと比較して進んでいるのか遅れているのかが知りたいから。
遅れていたらサポートしたり追加で人を増やしたりできます。
でもそんな管理職の気持ちすら慮らず、「できます！」と言って期限直前で「やはりダメでした、、、」。これが一番困るのです。
別に遅れること自体はそこまで困らないはず。
新入社員のリスクなど織り込み済みだし、早めにわかれば割となんとでもなるので。
というわけでタイムマネジメント能力は意識して身につけましょう。
そしてこれは僕が一番苦手な能力だったりします。集中力のなさ、計画性のなさ、持続性のなさ、、、僕の歴史はこのタイムマネジメントとの戦いの歴史と言っても過言ではありません、、、（この話も長くなるのでまた別の記事で。しかし何本別記事を書くのか）
ちなみに新入社員がわかりやすい能力を求めがちなのも非常によくわかります笑
特に今の世の中は「ジョブ型雇用が〜」「個人の能力が〜」「キャリアアップが〜」「老後の資金が〜」といった責任を個人に帰して不安を煽るようなプロパガンダで溢れてます。
そんな時にタイムマネジメントとか傾聴力とか言われても「それって転職で有利なの？」とかって思っちゃうからです。
とすると分かりやすく履歴書に書くことができて、手に職感のある専門性を身につけたいと思うのはある意味必然でしょう。
しかし、このような行き過ぎたプロパガンダも一過性のもので、組織で働く能力は永久に大事であり続けると僕自身は考えています。
このことは歴史を紐解けば明らかで、仕事、もっというと社会活動というのは結局「分業」だからです。それは個人で完結するものではなく、人と人とのつながりの中にのみ存在します。だから「相手の立場になって考える」ことは「仕事ができる/できない」といった（これまた一過性の）評価を得ることだけでなく、より良い社会を形成していくために必要なことなんじゃないかな〜と、僕はぼんやりとそう思ってます。
（最後はきな臭いポエムになっちゃいましたが、技術記事でもないし良いかなって。）
まとめ
こんなセクションを作りましたが、特にまとめることもありません笑
誰かの参考になれば幸いです。
