この記事はテックタッチアドベントカレンダー9日目の記事です。
こんにちは、バックエンドエンジニアのcanalun(twitter: @i_am_canalun_)こと佐藤可奈留です！
最近はいまさらマンガでナルトを読んで、ストーリーはもちろん、コマ割りやカメラワークがもたらす演出の妙に感銘を受けました！ナルト、めちゃくちゃ面白いですね！？面白すぎて、気に入った戦闘シーンはアニメでも確認しています🥷ﾆﾝﾆﾝ!
この記事の内容と目的
さて、ナルトの話は置いておいて。
本稿では、2ヶ月前まで経営コンサルタントとして働いていた私が、エンジニアとして働く中で感じたエンジニアとコンサルタントの仕事の違いについてお伝えできればと思います！
働き方の側面にフォーカスさせて頂くため、一部の内容は「エンジニアとコンサルタント」という対比を超えて、「プロダクトをつくる人たちとビジネスをまわす人たち」という対比にまで敷衍される余地があると考えています。
この記事がエンジニアやコンサルの方、もっと言えばものづくりやビジネスに携わる方にお互いの違いを理解するためのヒントになれば、もしくは私のように境界をまたいでチャレンジしようとする方やそのような仲間が周りにいる方の変化に適応するためのヒントになれば幸いです🤗
それでは本題に入っていきましょう……と言いたいところですが、その前に注意点です！
注意点
本稿ではエンジニアやコンサルタントの業務内容や働き方について述べますが、いずれも一般論ではなく、あくまでも私の経験とそれに基づいた考えに過ぎません🙇♂️
同じ職種でも会社が違えば業務も考え方も違うなんてことはよくある話で、全てのエンジニアやコンサルタントについて話したいわけでは決してありません🙇♂️
それでは今度こそ本題に入っていきましょう！
そもそも業務内容はどう違うのか
まずは前提として、エンジニアとコンサルタントそれぞれの業種で私が経験した業務の説明を少しさせてください。
- エンジニア
- 期間と場所: 2021年10月から約2か月間、Techtouchに勤務
- 業務内容: 自社のプロダクト開発(バックエンド)に従事。チームやプロジェクトが大きく変わることはあまりない
- 業界: toBの業務効率化SaaS
- コンサルタント
- 期間と場所: 2018年4月から約3年間、McKinseyに勤務
- 業務内容: クライアント企業の意思決定や施策実行を支援。チームとプロジェクトが数ヶ月単位で変わる
- 業界: 製造業から金融業までいろいろ
なおチームやプロジェクトの変更については、Techtouchにおいてもスクラムチーム編成の組み替えや担当施策の変更があります。ただ、前職のように全く初対面のチームメンバーとイチから関係を築いたり、全く知らない業界の知識を詰め込んだりということは少なそうなので、そこはかなり違います。
さてさてようやくになってしまいましたが、ここからは上記の経験に基づき、エンジニアとコンサルタントで働き方が違うように感じている点を書いていきます！
働き方についてどのような違いを感じるか
成果物の仮説性
最も大きな違いとして感じているのは、成果物それ自体が仮説的であるかどうかです。
ビジネスサイド、特に意思決定の世界で求められるのは「現時点で最も正しいと思われる仮説」、すなわち「暫定解」です。
それは、意思決定がそもそも見通せるはずのない未来をどうにか予想して行うものであることに起因します。絶対に正しい未来予想図なんて描けないのだから、現時点で最大限正しいと考えられる仮説を基に決めようという算段です。
対して、エンジニアリングなどのモノづくりにおいては、モノが意図した通りに動かなければどうにもなりません。最大限正しいと思える仮説でコーディングしても、動かなかったらやり直しです。 求められているのは「きっちり動くモノ」です。
もちろん設計や要件定義といった上位の工程についてはビジネスサイドのような暫定解の世界なのでしょうが、実装のプロセスにフォーカスすれば仮説は中間生産物でしかなく、動かしてナンボの世界です。
コンサルタントの現場では「80:20で仕事をする」ことが矜持として語られます。ちなみに「80:20」は「エイティートゥウェンティー」と読まれます(――余談ですがカタカナの言葉が多いのはどちらの業種も同じだったので良かったです🤗 )。
この「80:20」なる言い回しはパレートの法則、すなわち「ある事象の大部分(80%)は、その事象を引き起こしている要素群の少ない一部(20%)によって生じる」という法則に由来したものです。例えば「売り上げの8割は顧客の2割によって生み出されている」という現象がよく引き合いに出されます。
「80:20で仕事をする」とは、パレート法則的に「アウトプットの8割が労力の2割で生み出されている」と考え、「アウトプットの価値は、アウトプットが8割の完成度に達したならほぼ実現されている」として仕事を進めることを指しています。また、意思決定は暫定解を求めるという先ほどの文脈の中では「8割正しいと思える仮説を10割正しいと思えるレベルに持っていこうとするのは悪手である」くらいの意味で捉えられることもあります。
このような姿勢は、仮説で物事を進めるビジネスならではのものかと思います。
エンジニアの私が「8割は動きます」なんて言って動かないものを持ってきてもどうにもなりません(そもそも「8割動く」ってなんやねん！)。
作業時間の見積もり方
上記の違いは様々な部分に影響を与えますが、作業時間の見積もり方もその一つです。興味深いことに、エンジニアの方々は「作業時間の見積もりは難しく、2倍ほどブレることも十分ありえる」と考える傾向が見られるのに対して、コンサルタントの環境では「作業時間見積もりはブレても0.8-1.2倍だよね」という雰囲気でした。
エンジニアの世界には「ハマる」という言葉があります。書いたコードが意図した通りに動かず、長い長い試行錯誤の果てにやっぱり解決しない状態が延々続くことを言います。
エンジニアは動くモノを作るのが目的であり、動かないなら動くまでトライを続ける必要があります。問題がどんなに細部に由来するものでも、それを解決しない限りは終われません。
プロダクトの規模が大きいほど、そしてロジックが複雑であるほど、予期していない問題に出会う可能性は増えます。ハマらず順調に進んでいても、気づけば長い長いyak shaving(最終的な目標の手前で湧き出てくる小課題群の解決)に巻き込まれていることだってあります。結果として作業時間の見積もりはどんどん難しくなります。だからこそ、予想の3倍は時間をとっておくべきだという「3倍ルール」なんて言葉も耳にします。
しかし3倍などと耳にしたら、前職の会社にいる人たちは驚くと思います。先述の通り、作業時間はかなり高い精度で見積もるのが普通だからです。というより、コンサルタントはあるべき作業時間を定めてその枠内で仕事を完結させることが多いです。
「いやいや、作業が終わらない限り時間は伸びていくじゃないか」と思われる方もいるかもしれません。そこで、分からないことには仮定を設けるという工夫が行われます。
すなわち仮説の検証をする際、その検証で得られる効果に見合う作業時間を使い切ったら、その時点で入手できていない情報や正しいか分からないロジックには一旦仮定を設けて終わらせます。すごく矮小な例ではありますが、どれだけ調べても特定業界の市場予測が見つからないなら、一旦簡潔で妥当な予測線を引いて次にいくといったイメージです。
(もちろん、こういう場合は仮定の内容や仮定で済ませていいのかということの検証に全力が捧がれます)
対してエンジニアは動かない部分を仮定で終わらせられません。「作業時間の見積もり」という言葉を「使うべき最大作業時間の決定」という意味で捉えていた私はハマりを経験して初めて、考え方の違いに気づけました🙂
コミュニケーションと作業のバランス
エンジニアになってからは対人コミュニケーションの時間が減りました。エンジニアのタイプやペアプロ/モブプロをやるのかといった働き方の事情にも依るでしょうが、私の場合は減りました。
ビジネスサイドでは、意思決定のためのコミュニケーションはもちろん、意思決定に必要な情報を入手するためのコミュニケーションも実施されます。ステークホルダーとの会議から専門家やカスタマーへのインタビューまで毎日コミュニケーションだらけです。カレンダーがテトリスのように詰まって色々な人と色々なトピックで話す日々は一旦終わり、いまでは割と作業中心の毎日です。
私は人と話すことが好きなタイプなのでたまに寂しく思いますが、そのような時はtandemやslackのおしゃべりルームに救われています。こういうシステムがあるとやはり嬉しいですね😊
tandemってなに！？という方は、本アドベントカレンダー2,3日目のzakによるtandem紹介記事をぜひ読んでみてください！
知の在り方
これはビジネスサイドがどうとかいうよりもエンジニアの方々が特別なのかもしれませんが、とにかく知を形式知として残すことが尊重されていると感じます。
テックタッチ社内でもそうですし、QiitaやZennをはじめとしたプラットフォームの存在がエンジニア全体の意識の高さを物語っていると思います。もちろんビジネスでもnoteなどがありますが、エンジニアの世界では特段アウトプットの有用性が解かれている印象を受けます。
どんなに些細な話でもいいから自分のために、そして世界のために伝えようとする姿勢がみんなで共有されている状態に感激する日々です。
おわりに
まだエンジニアとして2ヶ月程度しか働いていないのに、色々と生意気なことを書いてしまった感がありますがご容赦ください🙇♂️ もちろん、また何か思いついたら発信したいと思っています！
今回、技術的なテーマもいくつか検討したのですが、直近で感じている仕事の違いをフレッシュな目線で書き残しておくこともユニークな価値の提供になりうると考えてやってみました。
本稿が、ささやかで珍しいクリスマスプレゼントになれば幸いです🎁
