Lean Baseball

No Engineering, No Baseball.

エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること

f:id:shinyorke:20201010151053j:plain
エンジニアの辛い仕事を消す本かも(多分)

2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです.

リクルートに入ったとき, そしてその後の転職先*1などなどで,

  • 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc...
  • コードじゃなくて, ドキュメントを書く仕事の辛さ.
  • プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2

みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが.

そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう.

...ということを, 前回のブログの執筆中および反響で改めて思い*3,

そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだことでいい感じにしたかも🤔

と思い立ったので, いい感じに言語化しようと思います.

前半戦は, コンサルタントの仕事術の基本をシンプルに言語化した「コンサル一年目が学ぶこと」を元に,

コンサル一年目が学ぶこと

コンサル一年目が学ぶこと

  • 作者:大石哲之
  • 発売日: 2014/07/31
  • メディア: Kindle版

エンジニアでも明日から真似すべきことを紹介しつつ, 後半戦は主にデータサイエンティスト寄りだったりプロダクトマネジメント寄りの事をしている方向けに,

アクセンチュアのプロが教える AI時代の実践データ・アナリティクス」からいい感じに学べる所を紹介します.

TL;DR(要約すると)

  • 「期待値コントロール」をするためコミュニケーションをしっかりとって, ドキュメントを通した言語化も雑でいいから爆速でやろう. これで33.4%くらいのツラミは減ると思う.*5
  • 仕事のための資料読み, 特に技術書を読む時は「検索式読書術」を意識して飛ばし読みすると良き.
  • データサイエンスに必要なビジネス力だったり仮説力も, 「期待値コントロール」「言語化」重要なので鍛えましょう.

ということを, 「コンサル一年目が学ぶこと」「アクセンチュアのプロが教える AI時代の実践データ・アナリティクス」の話を下敷きに自分の話としてこの先エイッと書きます.

おしながき

コンサル一年目に学ぶエンジニア仕事術

コンサル一年目が学ぶこと」はちょっと前の本なのですが, Kindle Unlimitedでおすすめされて暇つぶしに読んだらとてもいい本でした.

コンサル一年目が学ぶこと

コンサル一年目が学ぶこと

  • 作者:大石哲之
  • 発売日: 2014/07/31
  • メディア: Kindle版

この本で一番「オオッ」ってきたのが,

人を動かすのできる本当に説得力のある話は、論理と感情面、どちらも高いレベルで完成されているものです。

※「コンサル一年目が学ぶこと」第1章05「感情より論理を優先させる」より抜粋

感情面は人それぞれなので一旦置いておいて(どういう持ち方であれ感情面でマジになるのは大事です*6),

「論理思考力」が基本スタンス・スキルの一つであるエンジニアが学ぶべき所結構あるよね!(&そういえば自分もやってた)

出典:自分の感想

と思いました.

自分が思うに, 先程あげた辛い仕事 「コミュニケーション」「ドキュメンテーション」はコンサルの論理的・省力的なテクニックで解決できます.

書籍から引用しながらいくつか紹介します.

「期待値」揃えるコミュニケーション

3日の100点を求めているのか、3時間の60点を求めているのか。事前にしっかり確認しなければ、上司の期待を満たすことはできません。

※「コンサル一年目が学ぶこと」第1章09「上司の期待値を超える」より抜粋

「上司」の部分は「お客さん」「同僚」とかに読み替えてもらうとして(もちろん上司の場合もあるでしょう).

仕事には「このレベルのアウトプットが出てOK出たら優勝!」という「期待値」が存在するのはご存知かと思います*7.

「このレベルのアウトプット」という奴がお互い合意できてるか?が一番重要(かつ一番揉める)所で, ここが一番コミュニケーションすべきところです.

書籍の中では,

  • 「期待値」を定量化するため, 質問によって推し量る
  • 具体的には, 「資料にすると4, 5枚くらいでまとめればいいですか?」的な, 「お互いが会話できる共通単位」で確認する
    • 「いや, 2, 3枚でいいよ」であればラフにまとめてぶつければ良さそう
    • 「それぐらいじゃない?」であれば期待値として合ってるので進める
  • アウトプットの目的を聞く
    • チーム・社内共有なのか(雑に作ってOKとわかる)
    • 大事なプレゼンに使うのか(ちゃんと作り込まなきゃ(使命感))
  • スピード重視か, クオリティ重視か. 上記の「アウトプットの目的」ともシンクロする.

...といった具合で, 「3日の100点を求めているのか、3時間の60点を求めているのか」を推し量れると, 手戻り少なくいい感じにやれることでしょう的なことが書いてありました(自分の解釈ですが).

少なくとも, 「チャット・ISSUEトラッカーでコメントして終わり」なのか「資料作る必要あるのか」ぐらいは確認取る癖を作るだけでも違います&指示する側もそこを添えるといいでしょう.

とはいえ, 「ほしい!」という側も迷う・どうしたらいいか🤔となるのは人として当然*8なので,

相手の指示の曖昧な部分を補い、こういうことではないかという自分なりの仮説を立ててコミュニケーションをとる、これが正解です。

※「コンサル一年目が学ぶこと」第1章09「上司の期待値を超える」より抜粋

という考え方・技術を覚えて合わせて使う(≒仮説力を鍛える)となお良いかと思います*9.

「1章1メッセージ」ドキュメント

コミュニケーションをいい感じにとって「期待値」を合わせたらアウトプット...そう, 嫌いな人は嫌いなドキュメントを書く作業があります.

これに関しては, 書籍の中で明確にいい事を言ってます.

仕事を始める時点で、最終アウトプットの骨組みを作ってしまい、そのアウトプットから逆算して作業する。

※「コンサル一年目が学ぶこと」第3章19「最終成果物から逆算して、作業プランをつくる」より抜粋

ドキュメント(に加えてプログラミング)もそうなのですが,

  • 最終アウトプットとなるモノの章立てを先に作る
  • 各章・各セクションで書くこと・語ることは「一つの事象」に絞る

これを意識して作ると, シンプル・わかりやすいアウトプットが割と早めにできちゃいます.

アウトラインから作る

これは仕事のアウトプットより, ブログの例で言う方がわかりやすいかもですね...

例えばこのブログですが, どういった順番で書いてるかと言うと,

  1. タイトル
  2. Top画像作成(サムネイル・OGPで使う)
  3. h1レベルの見出し
  4. h2レベルの見出し
  5. 序章を書く
  6. h1〜h2見出しに従って本文を執筆

という順番で書いてます.*10

この順番で書く良いことは,

  • 比較的早い段階で全体像が見える. 具体的には4.(h2見出し)の時点で全体像が見える.
  • h2見出し(4.)ぐらいまでは試行錯誤の連続なので構成・順番が頻繁に変わる...が, 手戻りが圧倒的に少ない. なぜなら文章書いてないから.
  • (今回はありませんが)文字数や時間の制限がある場合, 途中の見出しを取ったり(もしくは足したり)といった調整ができる.

という利点があります.

エンジニア的には, 仕様書や長めの文章(社内で共有するドキュメントやテックブログなど)で同じ用に実践すると良くて,

  • タイトルと見出しを先にガツッと書く
  • 上記ができた時点で一度レビューしてもらう
  • レビュー結果が来たら軌道修正, Goが出たら一気に書く

とかすると, 「いきなり全文書いて期待はずれでした...」ということが無くなると思います.

ちなみにこれはプログラミング的なノリで言うと, 「とりあえず最小限のモノを作って, フロントエンド⇄サーバーサイド⇄DBが導通しました!これからガツッと作ります!!」的なやり方と全く一緒です.*11

1章1メッセージ

書籍の中では, 「ワンスライド・ワンメッセージの原則」と呼ばれてるやつです.

これは時の如くで,

ワンスライド(1枚のスライド)では、ワンメッセージ。1枚に1つです。

この原則を守ると、資料がシンプルになり、また再利用の差し替えが便利で生産性も上がります。

※「コンサル一年目が学ぶこと」第3章17「最強パワポ資料作成術」より抜粋

パワポじゃなくても, 社内ブログ・WikiやREADME.md, テックブログなども同じで, 1章の中で1メッセージに絞ると,

  • 差し替えが楽になる. 順番変えたり, 途中で新しいモノを追加するときもつじつま合わせやすい.
  • 再利用が楽になる. 例えば30分のプレゼン資料で作ったやつの15分バージョンとかを作りたい場合は途中のスライドを減らしたり, 別の資料を作る場合も引用してそのまま使いやすい.
  • 文章・資料としてシンプルで見やすくなる.

という利点があります.

前の章で触れた, 「アウトラインから作る」ことを実現するためにも, シンプルなメッセージで資料を作るのは重要かなと思います.

これもプログラミングで例えると, 「凝集度が高いクラス・メソッドを作る」「適切な単位でモジュール・パッケージ化する」的な考え方になると思います.

「検索式読書術」で爆速インプット

良いコミュニケーション, アウトプットを行うためにインプットは重要で, たくさんのコード・本を読むなんてことはたくさんあると思います.

これは(対象は違えど)コンサルタントも一緒で,

コンサルタントは、未知の分野に取り組む際に、短時間でひと通りの勉強をして、一定レベルまでキャッチアップをする必要があります。

(中略)

インプットのスピードが遅いと、仕事についていけなくなることがあります。

※「コンサル一年目が学ぶこと」第3章20「コンサル流検索式読書術」より抜粋

数百ページの資料を読む, 色んな人にヒアリングして読んで整理etc...資料の山に埋もれるのはザラにあります.

といった中で, インプットして整理した上でアウトプットを出す...を高速でやる「検索式読書術」というのが書籍内で紹介されていて,

  • 読書の目的を絞る、明確にする
  • ウェブを検索するように目次ベースで該当箇所を拾っていき、重要な部分だけ読む
  • なるべく多くの文献を広く浅く当たる

※「コンサル一年目が学ぶこと」第3章20「コンサル流検索式読書術」より抜粋

これ, そのままエンジニアの読書術になるじゃん!, と思いました.

自分の場合, 実際にあった例として,

  • アルゴリズムを知りたい場合はアルゴリズムの本を読む(Pythonの本じゃないのは確か).
  • 「今はベイズ推定のことが知りたい」という目的であれば該当箇所を目次から探してそこを集中して読む.
  • 一冊の本だけだと解像度が低い可能性あるので類似している本を複数読む(同じく, アルゴリズム系かつ該当箇所を目次から探して)

漫画や小説であれば「隅から隅までガッツリ読む」のが正解ですが, 技術書は大抵の場合「目的の知識が得られればOK」なはずなので最後まで読む必要はないのです*12.

ちなみにこの辺は「Action Reading」というノウハウが役立つので気になる方は抑えるといいでしょう.

コンサル仕事術とデータサイエンス

データサイエンスの世界でも...いや, データサイエンスの世界だからこそコンサルから学ぶことがかなりあります.

ということを「アクセンチュアのプロが教える AI時代の実践データ・アナリティクス」を読んで改めて思いました.

これは, 前回のブログでも「推し本3冊」の1冊として紹介しましたのでご参考にしていただければと.

shinyorke.hatenablog.com

前回のエントリーにおける「ビジネススキル」の部分がまさにそれで,

  • 専門家ではない人たちを相手に「要件を言語化」しつつ「相手の方をリード」してプロジェクトを進める力
  • アルゴリズム・システムアーキテクチャの理解とその最適な選択・推薦ができる. 上記の「アプリ」「インフラ」スキルのサマリーが理解できてる・実践できてる
  • 相手の方に「機械学習しなくてもできますよ」という提案ができるロジカルシンキングと度胸

前回のブログより抜粋

これは機械学習をしってる・コード書ける...だけでは解決できる課題じゃないよ, と言及させてもらいましたがもうちょっと掘ると,

  • 「専門家ではない人たち」に理解を頂いてプロジェクトを進めるためには「期待値コントロール」「言語化」が必要. 技術選定も同様.
  • 「機械学習しなくてもできますよ」を見定める調査・分析もスピード上げてやるのにコンサル力(インプット/アウトプットの速さと正確さ)が欠かせない.

と言えると思っていて, 「ああ, この辺ってやっぱコンサルの特性とシンクロするよね」と思いました.

また, 「アクセンチュアのプロが教える AI時代の実践データ・アナリティクス」の書籍中では,

  • 分析プロセスをいい感じに回すための課題定義・仮説立案・チーム作り
  • ビジネス活用(PoCから本運用へ)の壁をどう乗り越えるか?

ということが過不足なく書かれており, これもコンサルの道に繋がる感じかつ自分もそういえばそうだったな...と思ったので抑えて読んでおくと良いかもしれません.

結び

だいぶいい感じのボリュームで「エンジニア的に辛い仕事はコンサルの仕事術を参考に撲滅できるやで!」という話を書きました.

この手のネタは今まであまり書こうと思ったことが無かったのですが,

  • エンジニアの興味関心, (自分も含めて)言語とかツールとか本とかのHowに拘りがち. 本質から迫る意味ではWhyに目を向けるべきだよね.
  • 自社でWeb/アプリ等のサービス・商材を持ってる会社に所属して6年が経過した今, 仕事術・マネジメントの視点でコンサル時代に学んだことが今になって活きてきている.
  • 上記視点で気がついたことも結構あるし, これを一度公開したらどういうフィードバックが来るだろう🤔

という思いが巡り, 書いて公開することにしました.

誤解を招かない用に言うと, 「コンサルが最高!」と言いたいわけではありません.

個人的には「仕事術・プロセスのアプローチは大いに学ぶべき」とは思っていますが, 「コンサルのカルチャー・文化・仕事そのものへのリスペクトは個々人の価値観でしょ」という認識でいます.

という訳でネガティブ・ポジティブ双方でフィードバックお待ちしています.

しばらく本とかレポート系のブログ続いたので次あたりはコード出てくるようなテックなブログ書けるようがんばります, 野球も(個人的には)終わっちゃったし.*13

*1:ちなみに今は「技術わかる上司・技術に理解ある人達」という環境に変わった以外, 多かれ少なかれ日々この手の課題と戦っています.

*2:大切なので2度言いますが今はこれあんまりないです.

*3:特に, 「アクセンチュアのプロが教える AI時代の実践データ・アナリティクス」および, 「コンサル一年目が学ぶこと」がリアルおよびネットでもいくつかフィードバック・反響があって, これは掘った方が良さそうと思い続編的に書くことにしました. アクセンチュアの方は推しなので驚かなかったですが, コンサル一年目の方がここまで反応あったのは驚き.

*4:リクルートに入る前, 新卒の会社から転職して入った2社目がベイカレント・コンサルティングで, そこでエンジニアからの最終的にはテクニカルリードっぽいポジションで色々やって後リクルートに行きました.

*5:なんでや🐯関係ないやろ

*6:モチベーションとかパッションとか, ホントに仕事にコミットメントできますか?の文脈と自分は捉えています. 今回は仕事術とかプロセスの話なのでそっと置いておきます.

*7:初見であれば, そういうものだとここで覚えてください.

*8:昨今のエンジニアリングタスクは, 不確実性高いネタが多いというのが私の持論でもありまして, エンジニアから見ても不確実なのに上司とかお客さんとかみたら...ねえ?というのは許容範囲かなあというお気持ちあります. とはいえ, 指示・お願いする側も「不確実だよね」的な認識は必要かと思いますが.

*9:「心理的安全性を作る」的なニュアンスでよくでる「傾聴」というテクニックがあると思いますが, これがそのまま使えます. ひたすら聞いて曖昧な部分を因数分解して返す, を繰り返す的な.

*10:このエントリーに限らず, 自分が書くドキュメントはだいたいこのノリです.

*11:結合する部分, インターフェース持ってる部分が一番リスクあるのは皆さん承知かと思います, これを先に通したほうが結果的に後戻り少ない的なやつです.

*12:「最後まで読まないと書いた人に失礼じゃん!」という話もあると思いますがこれはどちらかといえば「感情」の話で, 仕事を素早く一定のクオリティで終わらせるという視点では「目的を達成したら終える」が正解かなと.

*13:メジャーはアスレチックスがPO敗退, プロ野球は日ハム(ryなので, ドラフト会議を楽しみに今は生きています⚾️