3年間の業務と1on1を経て学んだ、よりよい仕事の進め方
こんにちは、ひぐです。新卒から3年間弱、データサイエンティストとして働いていました。
3年間で業務や、多くの方との1on1を通じて様々な仕事の進め方を教わりました。(1on1の議事録はA4 400ページ分くらいありました。。。！）
本記事では、これまで教わったことを忘れないように、また共有できるように、経験をまとめてみました。「カッツモデル」というスキル分類方法(ヒューマンスキル・テクニカルスキル・コンセプチュアルスキル)に基づいてそれぞれ分けたので紹介します。
なお、メンバーとして受けたフィードバックや業務を元にしたものが中心になります。また、各項目に関連する書籍やブログを載せるので、良ければ参照してください。
1. ヒューマンスキル
1.1 テキストコミュニケーション
1.1.1 自己完結し、場に応じた粒度の情報を共有する
ビジネス文書の主な目的は他者に読んでもらい、情報共有を経て、理解や意思決定を促すためにあります。そのため、受け手が素早く読める上に、次のアクションを簡単に起こしやすいような自己完結した文章を渡すようにしています。
例えばデータ分析なら、グラフを貼るだけでなく、読み取れる示唆や次に行うべきこと、各選択肢のメリット・デメリットなども一緒に提供するといった感じです。(受け手が事実だけを求めることもあるためケースバイケースですが)
また、slackでレポート結果など長い文章をリンクで共有する際も、リンクだけでなく、サマリを伝えてあげると、どれだけすぐ読むべきかなどの判断がつくので親切だと思います。
1.1.2 受け手が欲しい情報の粒度・応答速度・内容を推定して伝える
情報を渡す際に、は受け手が欲しい情報の粒度・応答速度・内容を推定して伝えると素早くコミュニケーションできます。
異なる立場の人々（実行者、他部署のメンバー、マネージャーなど）とのコミュニケーションでは、関心の粒度や知識のレベルが異なるため、特に注意が必要です。(実行者はより細かい点に注目し、専門用語を使用しがち)
施策の結果共有なども、相手が大まかな成功の概要をただちに知りたいのか、あるいはより正確な数値を後で詳しく知りたいのかを相手の立場に立って考えることが重要です。
1.1.3 使う単語の一貫性を保つ
日本語には似たような単語が多くあり、気をつけないとテキスト内で異なる同義語を同じ意味で使ってしまいます。これにより文章の理解を難しくしたり、認識齟齬を招きます。
仕事で文章を書くときは、特に使用する単語の一貫性に注意を払いました。特定の単語を一貫して同じ意味で使用したり、複数の似た単語を使わないようにしています。この文章内では「この単語をこの意味で使う」と明記したり、チームの中で共通の辞書(ユビキタス言語)を作るのも効果的です。
自分が過去の業務で使った、混同しやすい単語の例では、「目的変数・メトリクス・評価指標・KPI・NSM」や「課題・問題・解決策・イシュー」などがあります。
1.1.4「行う」「変化する」など抽象的な表現を避ける
日本語には、具体的な行動や変化を示さない抽象的な表現が多く存在します。たとえば、「行う」という曖昧な表現の代わりに「実装する」、「変化する」の代わりに「低下する」のように、具体的な動作や変化を示す単語を使うことで、文章の意図を短く、かつ迅速に伝えることができます。
1.2 オーラルコミュニケーション
1.2.1 不確実でも良いから、包み隠さず早く応答する
相手が欲しいものは何かを考え、答え・結論から伝えるようにしてます。
難しいお題、答えづらい議論は、つい考えを巡らせて黙ってしまいますが、
その場合も、「いま考えてます」だったり、「30秒考えさせてください」のように回答をした方がよいです。
また、確証を持てない場合は「確度20%ですが」等と自分の意見に対して確信度を前置きした上で答えるとよいでしょう。
事実なのか、憶測なのかは意思決定において非常に重要であり、意外と明示的に言わないと認識齟齬が生まれてしまいます。
1.2.2 プレゼンテーションは構成とスライドの作成フェーズを分ける
プレゼンテーションのスライドは下記の順序で作成しています。
聴衆を想定し、伝えるメッセージを決める
箇条書きで話す内容・順序を完全にFixさせる
作成した箇条書きをスライドに書き起こし、微修正する
スライドを先に作ってしまうと、構成が微妙だなと思ってもサンクコストバイアスにより良い構成に、作り替えづらくなります。また、スライド(ビジュアル)と構成の修正は、脳みその使い方が異なるためマルチタスクになってしまいます。
1.3 セルフマネジメント
1.3.1 すべての課題がこの瞬間に解決すると思わない
思うようにパフォーマンスが発揮できないときに、自責の念に駆られたり、何とかしようと行動したくなります。しかし、組織の中で働く以上、実は自分の行動ではどうにもならないことや、すぐに解決できないことなども往々にして存在します。
例えば、ドメイン知識や経験に基づく直感が必要であったり、組織構造上解決がしにくい、そもそも自分の不得手など。そういったときは、ある種諦め、すぐに解決しようと悩み過ぎず、ある程度自分を俯瞰し、解決の時間軸を長くおくとよいでしょう。
やり過ぎると、すぐ諦める癖がついてしまいますが、近視眼的になりすぎず、今解くべき課題か、じっくり解くかを考えられるようになると自身のメンタルマネジメントがしやすくなると思います。
1.3.2 ご機嫌でいる
不機嫌な状態でいることは、下記の強いデメリットをもたらすため、セルフマネジメントを行い、ご機嫌でいるようにしています。
キャパシティオーバーであると思われ、メンバーなら難しい仕事が降られなくなる。マネージャーなら、メンバーから話しかけづらくなる
雰囲気を悪くし、チーム・組織全体のパフォーマンスや働きやすさを下げる
仕事は大変なことも多くあり、不機嫌で人をコントロールしたくなる場面もありますが、2.4.1や2.4.2を試したり、そもそも数ある仕事の中で自由意志でこの仕事に就いていることを思い出したり、言語化するとよいでしょう。
1.3.3 フィードバックは、ヒトとコトを分離して受け入れる
仕事で良いアウトプットを作る上では、コトに対する厳しいフィードバックは欠かせないが、慣れてないと、自分の人格を傷つけられたように感じてしまいます。
往々にして難しいが、コトに対してフィードバックを受けていると強く意識しています。自分とコトとフィードバック内容を書き出して、矢印などで紐付けると分離しやすいです。
1.4 キャリアマネジメント
1.4.1 会社のMustと自身のWillを言語化し、揃える
仕事では、集団で行動するため、自分がやりたいことと、身につけたいスキルと、会社から求められることは違うことはよくあると思います。そういったときは、自身と会社のやりたいこと・できること・すべきことをそれぞれ書き出すとよいでしょう。
書き出すことで、そもそも会社からの期待値がわかっていなかったり、マネージャーに自分のWillが伝わっていないということがわかると思います。書き出した上でマネージャーとすりあわせると、自身のやりたいことと期待値を揃えることができます。
特にやりたいことがなければ、会社のMustを自分のWillにできるようにするにはどうすればいいか考えたりするのも有効です。
1.4.2 まず期待値を超えてから次のことに挑戦する
上長から言われたやり方と、自分のやり方が会わなかったり、自分のWillと会社のmustが違うなど、意見が食い違うときがあると思います。
そういったときに、上長のまず言われた通りにやり方で成果を出してから、別のプランに取り組むようにしています。
つい、自分が正しいと思う、興味があることから進めたくなりますが、言ったことが伝わらない、優先順位を決められないと思われてしまいます。評価は期待を超え続けることで上がるので、まず自身の期待値を把握し、求められることを超えることが肝要です。
ただし、完全に食い違うときは、そもそも実行者の方が詳しく、上長が見えてない懸念があるかもしれないのです。丁寧にすりあわせる必要があります。このときは、別プランの懸念や、その別プランに何日間かけるか、等を先に伝えておくと良いでしょう。
1.5 チームワーク
1.5.1 フォロワーシップを高める
組織で働く意義は、個々で働く以上のアウトプットを出すことにあります。
組織として良いアウトプットを出すには、全員で同じ方向を向く必要があります。これには、リーダーに加え、すぐついて行くフォロワーが必要です。
フォロワーシップを高めるため、仕事を進めるとき、組織やチームリーダーのトップダウンの施策には早く、わかりやすく反応しています。火起こしで、火種が消える前に空気を送るイメージです。
ただついて行くだけでなく、フィードバック等があれば隠さずすぐ伝えるのも重要です。
1.5.2 ムーブメントを作る
一人でできることには限界があるため、チーム・組織として解決したい課題がある場合、なるべく個人でやらず複数人で取り組むようにしています。
例えば、技術負債の返済など。似たような課題を持っている人は組織の中にいるはずなので、個人的に声をかけて小さく始め、徐々に大きくします。
仕事をしてる人は大体自分のことで忙しいので、なるべく見える形でムーブメントを起こそうとしていることを主張するのも大切です。
2. テクニカルスキル
2.1 データ分析
ほとんど過去に書いたブログと登壇資料にポイントがまとまっていました。本記事ではこのブログの補足事項を記載します。
2.1.1 データ分析単体では価値は生まないと意識する
データ分析は何か次のアクションの確度をあげたり、共通認識を作るために行うものなので、次のアクションが変わらないデータ分析は顧客への価値は生まないです。
データサイエンティストとして働いていると、意思決定の支援においては、データ分析が第一想起になりますが、インタビューや定性評価などの代替手段があるなかのひとつであることを意識しています。
2.1.2 鳥の目と、虫の目を行き来して解像度を上げる
基本的にデータ分析は、多くのデータを集約・可視化し、示唆を出す行いですが、そのときに集約単位・抽象度合い上下することで解像度を上げることができます。
生データをあえて見たり、統計量ではなく分布を見るなど、情報量を絞らず、見ることで、統計量の裏側で何が起きているのか解像度を上げられます。
2.1.3. 時には仮定をおき、指標と解釈を簡単にする
集計対象が複雑な場合、あえて強い仮定をおいて指標を簡単にするとよいでしょう。
例えば、ユーザに表示しているコンテンツの並び順をA/Bテストし、それぞれどれくらい興味があるモノを含められているかを集計するケースを考えます。このとき、各ユーザのコンテンツ閲覧時間の分布を比較することもできるが、10秒以上閲覧したら興味ありと仮定し、興味ありユーザーの割合を比較することもできます。
あえて正確性をやや捨てて、解釈性をあげることもできる。わかりやすさ vs 正確に伝えるかのトレードオフを、ケースバイケースで行うとよいでしょう。
2.2 プログラミング
2.2.1 回避策を回避する
プログラミング実装時、ライブラリの機能が自分のユースケースだとうまくいかないとき、アドホックな解決策でその場を凌ぐことがあります。
実は公式ドキュメントを読み込むと解決策が提供されていることがあります。状況に応じては必要ですが、思っているよりもソフトウェアは多くの人が読むし、長きにわたって使われるので、なるべくその場しのぎの回避策は回避した方が良いです。
自分は回避策を使うときは、下記の2点を見直してます。
公式ドキュメントやgithub issueなど一次ソースを読みに行き、解決策がないか探す
そもそも、公式が提供しているユースケースと異なる方法で実装する自分の実装方針は必要なのか、思い直す
2.3 機械学習モデリング
2.3.1 データ形式が変わりづらい箇所を見定め、コンポーネントを分ける
機械学習コードは対象のデータに対して、収集・加工・学習・推論と複数のコンポーネントを通して、所望の推論結果を得ます。このような複数のコンポーネントは加工対象が同じなので、気をつけないと簡単に密結合してしまい、対象箇所だけの改善・修正が難しくなってしまいます。
これを防ぐためには、各コンポーネントがどのようなアウトプットをするか、どこがアウトプットの形式が変わりづらいかを見定め、コンポーネントを疎結合に保つとよいです。各コンポーネント間はあらかじめ決めたスキーマを約束し、連携するイメージです。
一例として、特徴量生成・学習・推論の3つでコンポーネントを分けるFeature/Training/Inference (FTI) Pipelines などがあります。
2.3.2 小さく実験できる状態を保つ
多くの機械学習アプリケーションは、大量のデータを利用するため、処理に時間がかかり、フィードバックのループが遅くなり、開発速度が低くなりやすいです。このような状況を避けるために、小さく実験できる状態を保つことを気をつけています。
例えばDEBUGフラグを用意して、フラグを指定したら、5%のデータでコンポーネント全体を流す、単体テストから書いて、各メソッドを独立にデバッグ可能に記述するなどの工夫ができます。
3. コンセプチュアルスキル
3.1 プロジェクトマネジメント
3.1.1 プロジェクトは始まりと終わりが最も難しいことを意識する
プロジェクトは、始まりと終わりが最も難しいと感じます。
始まりは最も不確実性が高く、最後は80%のクオリティをユーザに提供できる状態に磨き上げる必要があるためです。
自分のプロジェクトが全体のどの段階にあるか、逆算し、開始時期なら密にコミュニケーションを取るなど、意識レベルをあげるとよいと思います。
3.1.2 スコープとリリース日もトレードオフの一つであると意識する
あらかじめて置いていたリリース日に間に合いそうにないときは、焦りや、事前に言ったことを守れない後ろめたさから、計画を変えずに不完全な状態でリリースを目指したり、報告が雑になってしまうことがあります。
プロジェクトマネジメントはQCD(クオリティ・コスト・デリバリー)の3つのトレードオフを調整するモノなので、必要に応じて、リリース日も調整しましょう。
(ただし広報のタイミングが決まってるなど、ハードデッドラインがあるケースもある)
マネジメント側の期待としては、途中の動きが全くわからず、リリース直前になって欠陥が見つかる、延期の連絡が来るということが一番辛いので、早め早めに当初のリリースできそうか、そもそも開始時にQCDのどれをなどを優先するか、すりあわせておくと良いと思います。
3.1.3 可能な限り問題を小さくし、列挙する
経験的にプロジェクトが進まないときは、何をやればいいのかが不明瞭になって、あれもこれも手をつけたりすることが多いです。そういうときは下記の2点を行うと良いです。
やるべきことを可能な限り小さいタスクに書き出し、TodoListに列挙する
どこまでをいつまでに終わらせるのか、マイルストーンを立ててチームに見えるようにする
これを行うと、下記の効果が生まれ、プロジェクトが進み出します。
やるべきことが一つの小さなことに定まり、マルチタスクを防げる
小さいステップで進んだ感が生まれ、作業興奮により集中できる
有言不実行な人と思われないように、頑張るという外的モチベーションが生まれる
自分はLinearというタスク管理ツールに記載することが多いです。
自作MLライブラリを作ったときのタスクリスト
3.2 問題解決
3.2.1 思考の生煮え度によって、アウトプットの手段を変える
思考は曖昧な状態から徐々に明確になっていきます。この思考の進行度に応じて、アウトプットの手法を変えることで、より迅速に考えを整理することができます。
自分は下記のように考えることが多いです。
Step1: 散歩をしながら幅広くアイディアを発散する
Step2: ホワイトボードやMiroでアイディアを書き出し、二次元的に配置・関係性を洗い出す
Step3: 箇条書きで各アイディアを取捨選択したり、肉付けする
Step4: 文章に直す
Stepの後半に行くほど、アウトプットの方向転換をするコストが上がるが、正確性が上がります。思考が初期段階のうちは方向転換が頻繁に起こりやすいため、容易にアイディアを変更できる手法を選ぶとよいでしょう。
3.2.2 そもそも問題に解が出せそうか & 解く意味が大きいかを考える
課題が与えられると、どうやって解くべきか、について考えを巡らせてしまうが、「そもそも解く必要があるのか、解を出すことができるモノ」なのかを考えた方が良いです。
特に、SQLクエリの作成と結果の可視化など、How自体に工夫のしがいがあるものだと、解く意義の過多に問わず、仕事をやった感がでてしまうので要注意です。
3.3 学習
3.3.1 やる気や意志力でなく、習慣を使う
やる気や意志力は有限の資源かつ、日によって左右されるので、これを使って継続的な学習することは難しいです。なるべく、良い習慣を身につけて、特に何も考えずに勉強したりできると良いでしょう。
自分は下記のような取り組みを行いました。
習慣の負荷を極端に下げ、頻度を上げる
目標と習慣を他者に報告・管理してもらう
悪い習慣に取り組むのを難しくする
無意識的なものを含め、自身の習慣をすべて言語化する
詳しくは下記の記事に書いてます。
3.3.2 アウトプット駆動でインプットする
自分が物事を理解した気になっても、人に説明できるような理解度にするには思った以上に乖離があります。
このようなわかった気で放置しないためには、人に説明できるようなブログを書いたり、外部登壇したり、アプリケーションを作るのが良いです。
また、登壇資料やブログはあとで自分で参照したり、チームメンバーに提供したり、自社の採用における認知の材料や、自身の転職活動時のアピール材料などに活用できる、「資産」になるため非常におすすめです。
3.3.3 業務の中で学ぶ
業務外の時間で自習するのも、とても大切ですが、業務時間中に学んでしまうという方法も有効です。
下記のような工夫をすることで業務中で少しずつできることを増やすことができます。
少ししか知らないことでも手を上げて、学びながらできるようにしていく
自分が関心があることを、会社における必要性を訴えて、挑戦させてもらう
いつも使っているツールをショートカットキーを使って高速化を計る
特に自分より詳しいことをやっている人がすでに社内にいる場合、その人のアウトプットやツールの使い方などを学びに行くと効率が良いと思います。
3.4 目標設定・達成
3.4.1 叶えたくなる目標と小さいステップを踏める指標を置く
OKRの考えに沿って、目標設定は自分がこれを達成したら嬉しいなと思えるような叶えたくなる目標(O)とそこに近づけるための小さいステップを踏める指標(KR)が両方あると達成しやすくなります。
KRは、遅行指標や、外的要因により変化が大きいモノだと、モチベーションを維持しづらいので、なるべく自分の努力に対して、早くすぐ相関する指標にすると良いでしょう。今年の自分の個人OKRは下記のようなモノでした。
Objective
データチーム立ち上げ期に一人目として入っても結果を出せる人材相当にスキルをつける
KR
ブログ12本書く
6回外部登壇する
本を12冊読む
施策を4回成功させる
Twitterのフォロワーを2000人にする
採用する
etc..
3.4.2 達成癖をつける
立てた目標は必ず達成する、習慣を身につけるように努力しました。達成しない癖がついてしまうと、目標にも意味が薄れてしまいます。
達成癖をつけるには、人に言って回って逃げられなくする、週次で細かく進捗を報告する等が有効でした。とはいえ、自分は個人OKRを達成できなかっですが。。。(反省)
まとめ
3年間の業務と1on1を経て学んだ仕事の進め方をまとめてみました。
改めてまとめると、仕事の失敗は、自分と相手との立場の差や、自分の直感的にやりたいことと、本質的に価値のある行為にズレがあることから起きることが多いなと思いました。例えば下記の通りです。
自分がやってきた作業の細かさに引きづられて、相手が求めるアウトプットの粒度より細かく情報を伝えてしまう
その場の作業興奮を優先したり、 フィードバックによる傷つきを恐れて、人に仕事を見せず、大きく手戻りする
自分がよくどんな失敗をするか、どこにバイアスがあるかをなどを認識できればある程度解決できると思うので、日々振り返ってみたいと思いました！
最後までお読みいただきありがとうございました〜
この記事が気に入ったらサポートをしてみませんか？