「エンジニアは意思決定においてどのような価値を発揮できるのか」を考えることによってキャリアの選択肢を考える
今の会社に入ると決めた辺りから「一旦はキャリアとか中長期の目標とか考えずに目の前の仕事に集中するぞ！」という感じで生きてきたのだが、最近それだけじゃやっぱあかんなと思い始めてきた。
理由としては「組織の最大出力を上げるためには個々人がユニークなスペシャリティを持ち補完し合うのがベスト」であり、そのレベルのスペシャリティを保つには設計された・意図的な努力が必要なんじゃないかと考えるようになったからだ。
そして今自分がなりたい姿としてざっくりと「エンジニアと言うロールに軸足を置きながら事業を成功に導ける人」になりたいと思っている。(ちなみに本題とは逸れてしまうので「なぜエンジニアに軸足を置くのか」と「なぜ事業を成功に導ける人になりたいのか」という問いに対しては今回は触れない。)
それだけだと抽象的すぎるので、もう少し具体的に考えてみたところ意思決定のクオリティーを上げることに貢献することがインパクトでかいのではと言う仮説が自分の中で強くなってきた。
エンジニアは基本的にアイデアを形にするHowのスペシャリストであり、クオリティー高いものを実装することが価値の源泉であることを前提にあると思うが、それだけでなく、Howを実行できるからこそ意思決定に貢献できる部分も多々あると思う。
その貢献できる部分をなるべく言語化することによって「じゃあ自分はどんなことがしたいかなぁと言う考える礎にしよう!」と試みた結果がこの記事だ。
似たような価値観の方には面白いことや良いこと言えているかもしれないので、お読みいただけると幸いである。
仕事とはなにか
いきなり大仰な問いが出てきて面食らったかもしれないが、哲学的な答えを滔々と述べるつもりはなく、そもそも我々が行う組織としての「仕事」とは何かを少し考えてから、じゃあそれを回すための意思決定ってなんだっけ、エンジニアとして力になれそうなのはどこなんだっけ、という順番で考えていきたい。
仕事の定義はここでは次のように定義する。
課題を定義し、それに対する解決策を選択し実行すること
もう少し具体的に深堀ると、課題を提示するためにはまず目標があり、これはビジョンだったり組織の短中期目標のような呼称で言語化される。
それに対して自分たちの取り巻く環境がどうなっているかを捉えて"今"解くべき課題が何かを定義する。
それから課題に対してどんな解決策があるかを洗い出し、選択する。
そしてその解決策を実行し、その結果成功失敗の度合いの違いこそあれ環境に対して変化が起こる。
当たり前の話ではあるが、こういった活動は1回やって終わりではなく、組織の最上位目標であるビジョンを達成するまで、またはそれを持続させるために続いていく。こうやってループしながら続いていく一連の活動が仕事なんじゃないかと思う。
OODAループ
そしてこんな活動を表現するのにぴったりだなぁと思っているループがOODAループで、それは次のような図で表現される。
(出典: https://teamhackers.io/the-essence-of-pdca-and-ooda/)
結構このループ意思決定のフレームとして紹介されることが多いのだが、個人的には仕事のフレームとして表現してもしっくりくるんじゃないかと思っている。こんなこと言ったら作者に怒られそうだけど。(一応大元っぽい本は買ったのだが、要点が掴みづらくて2章くらい読んで諦めた)
さて、図内の要素がそれぞれ先ほど述べた事となんとなく 1:1 で繋がるんじゃないかと思う。このラベル付けが便利なので、これを用いてエンジニア的にはどんなところに価値が出せそうかというのを洗い出していく。
自分が思いつく限りではこの辺りが出てきた。
- Action でアイデアを形にする
- Decide & Orient 選択肢と制約を提示し、状況を整理する
- Observe を技術で支える
- ループ自体を速く回す
Action でアイデアを形にする
もはやエンジニアのアイデンティティとすら呼んでいいのではないかと思うが、シンプルに打ち手となるものをプロダクトとして実装することを指す。
シンプルであるが故に技術力というものが直に関わってくるところであり、ここが強大であると意思決定に直接影響を与えることができる。実行が速ければ取れる選択肢も変わってくるし、より早く環境に影響を与えることができる。
あまり個人の能力頼みで意思決定するのはその人が単一障害点になりがちなのでよろしくはないのだが、やっぱりエンジニアとしてのコアバリューではあると思うので、ここの研鑽は忘れてはいけない。
正直なところ、今自分は他のスキル領域に足を伸ばそうとしている訳だが、このメインのプロダクトを実装するという点だけでも人が足りていない会社が9割9分9厘だと思うので、ここの力を伸ばしまくるだけでも大体の会社で価値を発揮しやすくなるのではと思う。あまり志向が技術に寄りすぎてもアレだけど。
Decide & Orient 選択肢と制約を提示し、状況を整理する
Orientする際に、エンジニアとして重要なことは「選択肢を提示すること」と「制約(と実現可能性)」を提示することだと考えている。なぜならそれはHowを熟知しているものでないと出せないものだからだ。
我々が日々仕事をしている中で全ての課題に対してこんなに真面目に検討する必要はないが、私がかっちりこのOrient -> Decide をやる時は次のように進める。
1. 課題、または課題に対する仮説を言語化する
2. その課題にまつわるファクトを集める
3. 選択肢を洗い出す
4. 課題の解決度合い、時間、コスト、Willなどを比較する
5. 決める
１と２に関しては文字通りなので特に説明することはない。頑張ろう。3に関してはアイデア勝負でいろんな打ち手を考え出す。そして出てきた打ち手たちは異なるトレードオフを抱えていることが常なので4の比較が必要になる。これに関してもう少し詳細に触れる。
課題の解決度合い、時間、コスト、Willなどを比較する
複数の打ち手が出た時に、課題の解決度合い、時間、コスト(いわゆるQCDというやつである)がそれぞれ異なるので、比較してそれっぽい結論を出す必要がある。
QCDに則って考えると、Qualityは機能要求と非機能要求に分かれるが、非機能要求に関しては「譲れないライン」のようになっていることが多いため"制約"と捉えた方が良さそう。機能要求に関しては、その「打ち手によって課題がどれくらい解消されているか」で比較することができる。
時間とコストはそのまんまの意味。
これらに対して制約を示すのがエンジニアの大きい価値かなと思う。例えば時間に対しては見積もりを出しておおよそのかかる時間を出したり、そもそも打ち手が技術的にや時間や組織の状況的に実現可能なのかだ。ここでクオリティの高い根拠を提示することができれば、リスクの高い意思決定を回避させることができる。
Willの影響
上記のようにロジカルな要素だけ話していると抜けがちな観点が人のWillだ。ここで言っているWillとは「これは自分で作って最高の体験作りたい！」とか「この技術が使いたい！」とかそういう話である。
エンジニアも人なので、どれだけ技術選定がロジカルに正しかろうと、クリエイティビティのない仕事(他社の事例の丸々コピーとか)をすることになったり自分のキャリア的には停滞もしくはマイナスな技術選択がなされたらモチベーションも出しづらいし他所にいきたくなるというものだろう。
また、採用にも悪影響がある。古めかしい技術を使っているところはそれだけで足切りされる可能性が高く、逆にエッジな技術を使っているところは会社が無名でもそれだけで「おっ」と興味を持ってもらえることがある。なので採用ブランディングの一要素としても結構なインパクトを持っていたりする。
もちろんこれに気を使い過ぎてオーバーエンジニアリングになるのもよろしくないのだが、アンダーエンジニアリングは割と中長期的に組織を辛くしていくので、時間の要求がアンダーな方を絶対選ばなければいけないほどタイトでなくどっちにするか悩ましいような状況ではとりあえずオーバーな方に倒す方がマシになることが多いのではないかと思う。(それかちゃんとフェーズを踏んで捨てやすくしておく。最初に作るやつは運用の確認のためと割り切ってデータだけは移行しやすくするとか)
Observe を支える技術
Observeする時にそもそも観察対象がないとどうしようもない。それを技術で支えるのも一つ重要な役割だ。
正直経験がなく、テキトーなこと言うと本業の方に怒られるかもしれないので簡潔に述べる。具体的なHowとしてイメージしているものとしては定量的なものとしてはプロダクト上の行動(GAとかで計測するやつ)をログできるようにすることやBI基盤を整える技術などだ。
あまりポピュラーなロール名では無いのだが、いわゆるマーケティングエンジニアと呼ばれる人の職能だと考えている。日本の求人には見たことないけど海外のジョブディスクリプションとしてはちらほらあるっぽい。
たまたま見つけたこの記事に書いてあることが結構イメージと近い。
あとデータから仮説を導くと言う意味ではデータサイエンティストと呼ばれる職種の人もこの辺なのかもしれない、知らんけど。
定性的なものとしてはUX Researcherという昨今注目されているロールの人が当てはまるのではないかと思う。誤解のないように言うとUX Researcherでも定量面は見たり仮説検証の設計をしたりなどロールの守備範囲はもっと広範だと思うが、具体的なHowとしてユーザの行動観察調査やユーザインタビューなどの職能があるため、この辺のHowをスペシャリティを持って実行することをイメージして触れている。(正直エンジニアリングあんま関係ないんだけど、個人的に興味があるから今回言及しました。すまん。)
昨今では短期視点の売り切りのビジネスではなく、ユーザとの長期的な関係を見据えてLTVを重要指標とするものが増えてきているため、今後もこのロールの重要性はどんどん上がるのではないかなと思っている。
ループ自体を早く回す力
最後にこの「意思決定のループ自体を早く回す力」も重要なので触れていきたい。
我々は意思決定するにあたって、既に存在するファクトや状況を観察し仮説を立てることによって次のアクションを実行していくわけだが、常に精度の高い仮説が考えられるほどに情報があることはほとんどない。
実際に市場に出して反応を見るというのも一手段であることは間違いないが、そのファクトが見えないと言う課題そのものに対してアプローチすることも多々ある。それがプロトタイピングだったり、もっと粒度の大きいもので言うとベータテスティングなのかなと思う。もっと定量的なアプローチで言うとABテストなども含まれる(他になんかあるのかな)
こうした仮説検証を設計から実行まで一貫して実行できる技能というのも重宝されると思う。できたらかっこいいよな。
エンジニアとしてどのようなスキルを伸ばしていくか
それでは最後に、これまで考えてきたことがエンジニアのキャリアにどのような影響を与えるかを考えていこうと思う。つまらないことを言うと「組織とプロダクトと個々人の価値観による」のだが、それだけではアレなのでどんなパスがありそうかを述べていく。
ジュニアな内はとにかく技術力伸ばした方がいいのでは
個人的な思想として、エンジニアというロールに軸足をおいて働いていくと決めていて、まだ経験が浅い内はあれこれ浮気せずに "Action" の部分を一人前にこなせるようになるのを目標にした方がいいのではと考えている。
理由としてはOrientの部分で価値を発揮できる前提としてある程度技術力やプロダクトを作った経験が必要だからだ。経験がなさ過ぎると、そもそも選択肢を提示することができなかったり、的外れ過ぎる見積もりを出す可能性がある。
では「1人前ってなんだよ！」と言われると自分でもはっきりとした定義はないので辛いのだが、「課題の定義のすり合わせさえやっておけば後は放っておいても大丈夫と周りの人に信頼されている状態」ぐらいは実現しておきたいものなのかなぁと思う。
Orient & Decideがうまくできるようになるためには
正直自分もよく分かっていないので模索中だ。身も蓋もないこと言うと、場数踏みまくるしかないのではという気もしている。
最近はNoCodeの文脈で「何に対して仮説検証をするか」を細かい粒度で設定でき、取れる選択肢もかなり増えてきている。だからこそ、ここの難易度も上がっており、単純にいろんなサービスを知っていることや、負債を残さず組み合わせるプランニングなど、より抽象度の高いところでの技術力が求められるようになっているのではなかろうか。
ちょっとまとまりがなくなってしまったけど、ちょっとここは場数を踏んでいつか体系的なものを言語化できるようなりたいなぁ、という感じだ。
それとは別に体系的に学べる部分も多々あると思っており
- 見積もり工学
- 起業のフレーム(いい感じの表現が浮かばなかったが、イメージとしてはこのページに載っているようなこと https://resource.foundx.jp/startup-school-2019/)
こういうのは議論の前提として共有できるといいかもしれない。
個別のスペシャリティを磨く
道中上げたもののスペシャリティをそれっぽいロール名つきで再度並べると次のようになる。
- Observe を定量的な観点から支える(マーケティングエンジニア)
- Observe を定性的な観点から支える(UX Researcher)
- ループを早く回す(プロトタイピング)
どの技能がどのくらい求められるかはプロダクトのフェーズや組織にいる人たちのスキルセットにもよるだろうから一概にも言えないが、自分がいる状況と自分自身の「これできるようになりてぇな〜」って気持ちと照らし合わせてベットするところを決めたらいいのではと思う。
おわりに: これから私は何がしたいのか
そもそもの目的がこれに解を出すことなので、最後に自分語りをして締めようと思う。
正直今の仕事状況的には、どこにベットすると良さそうか読みづらい時期なのだが、
- 求められそうなこと: マーケティングエンジニアの職能
- やってみたいこと: プロトタイピング、UX Researcher
という感じだ。
ただ前者は他にやってくれそうな人がいて、自分が手を出そうとしても意味なさそうな感じがある。あとブランディングとか考えると後者も大事になってくると思うけど、いかんせんモノがECなので、プロダクトでどうこうと言うよりはコミニュケーションデザインやコンテンツマーケの方が重要感ある。将来的にはアプリ感のある機能が価値あるみたいな可能性なくはないけど。
なのでなんとなく煮え切らない感じなのだが、どうころんでもマーケ施策のサイクルを早く回せるのが、一番価値あると思うので、一旦自分のなんとなくのWillは飛ばしてこの辺の技術を重点的に学んでいこうと思う。やってみたら楽しいかもしれんし。
ネクストアクションとしてはこんな感じで。
- 「マーケティングとは何か」を自分なりに言語化する
- 今他の人が整えてくれているもののキャッチアップ
- 「自分がリスティング広告を打つにあたって検証までを自力でやれる状態」みたいな放題設定が良さそう
やっていき！
この記事が気に入ったらサポートをしてみませんか？