「求められているパフォーマンスが出せていない気がする」と悩んでいる方へ　“期待のズレ”を可視化する、3つの指標へのマッピング

技術的に正しいことがいつも会社・事業にとって正しいわけではない

あらたま：次に少し時を先に進めて、トピックとしては「エンジニアの評価の軸」みたいなところの話をしようと思います。昨今「GPTさんに我々の職が奪われるのではないか」みたいな話もあるので、コーディングだけじゃない、エンジニアの評価軸みたいなところも少しお話ができたらなと思っています。

これは前職の時の話ですが、技術的に正しいことがいつもその会社とかその事業にとって正しいかというと、実はそうでもないみたいなことをいろいろと感じる機会がありました。

例えばテーブル設計をしようとする時に、どこまで正規化をするべきかって、その時々に置かれた自分たちの状況によって絶対に変わるじゃないですか。

なのに「これは第5正規形まで正規化するのが正しいんです！　キリッ」みたいなことを言ってしまって、メンテナンスもアプリケーションコードからの呼び出しも大変なテーブルができあがってしまうようなことは、絶対にあると思うんですよね。そこに対して時間軸も加えたいと思っていて、変わらない市場も存在しないし、変わらない業務フローも存在しない。

市場に合わせて事業、プロダクトのかたちも変わっていくし、そこに付随する、いろいろな人がその事業に参画しているわけなので、その周辺で発生する業務フローも絶対に変わっていくはずなんですよね。

なので「そのスナップショットにおける技術的確からしさというだけで、その後を見越した技術選択がちゃんとできますか」というとできないし、決定打にはなりえないというところを、自分で痛い目を見ながら感じるタイミングがたくさんありました。

技術的な確からしさを知っていることはもちろん大事なんですが、それを使っていれば、振るっていれば大丈夫、「自分は強いエンジニアです」と言えるか、というと言えないなというようなことを多く感じました。

エンジニアとしての1つのあるべき姿

私は前職がロコガイドという会社だったんですが、そこのCTOをやっていて、今はくふうカンパニーというホールディングスのCPOをやっている前田さんという人がいるんですね。

彼が言っていたのは、「システムは現実の写像たれ」と。「（僕は）そう思ってやっているよ」みたいなことを言っていて。最初はちょっと何を言っているのかがよくわからなかったんですけど（笑）。一緒に仕事をしていくうちに「あー、もしかしたらこういうことかもしれないな」みたいなことが少しずつわかるようになってきました。

先ほど「変わらない業務フローも存在しない」みたいな話もしましたが、そもそもエンジニアって、周辺の他の職の人たちの業務フローとか、何を目的に何をやっているかみたいなことって、どのぐらい知っていますか？　

あとは、私たちが価値を届ける先のユーザーさん、toBなりtoCなりいろいろあると思うんですが、ユーザーさんがどういうジャーニーをたどって自分たちのサービスを使ってくれているのかみたいなことを、自信を持って1から10までちゃんと説明できる人ってどのぐらいいますか？　

（本来はそれが分かっていないと）けっこう不安じゃないですか。普通にコードだけを書いていると、仕様を決めてくれる誰かがいて、それをコードに落として、そのままテストなんかを書いちゃったりして。「どうやらみんなが求めているとおりに動いているらしい。よかった」みたいなところが1つのサイクルになってしまって、その外側を観察しにいくのって、自分が能動的にアクションしないと取りに行けない領域だと思っています。

例えば他の職種からエンジニアに転向してきたみたいな方だと、それまでやってきたスキルとかがあるので、そういうスイッチがしやすいかなとは思うんですけど。私もずっとエンジニアでやってきたのでそうなんですが、そうじゃない人もけっこうたくさんいると思っています。

外側に対してちゃんと知りにいくことをやらないと、先ほども話していた「技術的確からしさ」の外側、「事業にとっての確からしさ」みたいなことをしっかり判断するのは難しいなと思っています。

「自分自身がプロダクトマネジメントをやりますか？」というと、それは向き不向きがあるので。私は最近ロールとしてPdMも担っていますが「これは向いていないな」と思いながらやっているんですよね（笑）。

そこに自分のスペシャリティ、ケイパビリティがなかったとしても、何のために何をやるのかというのをしっかり理解した上で、エンジニアはそれをどうやるのかに責任を持つべきだと思うんですよ。

自分自身が、なぜやるのか・何をやるのかを生み出さない。それを他の人と一緒に組んでやることを選んだとしても、それをできるだけ高い解像度で理解して、実現するために何ができるか、何ができ続けるかに責任を持っていくのが、エンジニアとしての1つのあるべき姿かなみたいなことを考えていました。

それをやろうとした時に、周りの業務フローを知らないとか、ユーザーがどうやって使っているかを知らないという状態だと、正しいであろう選択にはきっとたどり着けないんじゃないかと考えるわけなんですね。

必ずしも「事業」と「技術」のどちらかに突出している必要はない

それで軸を……。（スライドの字が）ちょっと小さかったですね。もうちょっと大きくすればよかった。軸を持ってきてみました。

事業にもメチャクチャ明るくて、技術にもメチャクチャ明るい人って、スーパーマンじゃないですか。我々はスーパーマンにはちょっと（なれない）……。もちろん、いろいろなハードルを軽々と飛び越えてなれる人たちもたくさんいるんですが、少なくとも私自身の自分の認知は凡人なので、「この極を同時に振り切ることは無理だな」みたいなことを思うわけなんですよ。

なんですが、たいていの会社はどっちにも振れている人が欲しいという人はそんなにいなくて。これは語弊があるかもしれないですが、事業をやっているたいていの会社さんは、そこまで尖った技術を必要としないことも多いと思うんですよ。もちろん例外はありますよ？　サービスインした当初からメチャクチャ高いトラフィックを扱わないといけないみたいなことだったら、パフォーマンスへの知識がある人に来てもらったほうがいいと思います。「100パーセントそうである」ということを言いたいわけではありません。

なので、必ずしもどっちかに突出している必要はない。そういう中で「じゃあ自分のマッピングをどうしていこうかな」というところを考えるというか、理解して、自分のwillを重ね合わせるみたいなことができるといいんじゃないかなと思うわけです。

それで全員が全員、何かの領域に尖っているようなチームメンバーって……。2011年のhidekさんのチームがまさにそうだったと思いますが、本来の目的のためにアライメントするような役割。つなぎ合わせたりバランスさせたりする役割というのが必要になるはずなんですよね。

一概にどっちがいいというのは言えませんが、一人ひとりがそのバランサーの役割を持てるような布陣で臨めるんだったら、そういうチームのかたちもありじゃないですか。

なので、その時その環境で自分がどういうバランスで動くといい感じにプロダクトがうまくいきそうかとか、自分がどういう役割を担いたいかとか、そういったことを理解しておくことが大事なんだなと思うわけですね。

1＋1の力を3に、10に、100にするために「組織」がある

（スライドを示して）ここにもう1個の軸を足そうと思います。組織です。今チームの話もしたと思いますが、3つ目の軸として組織がある。エンジニアリングマネージャーの仕事とか、ちいとぽ（チームトポロジー）とか（の話）がここ2年ぐらい話題を席巻するようになって、よりこのあたりの機運が高まっている感じはします。

個人でやるのではなくて、組織として会社に属してなにかをやっていく時って、「お給料が定額毎月振り込まれるという安定した環境ってすばらしいよね」みたいな話ももちろんあります。（でも）それだけではなく、1＋1の力を2じゃなくて3とか、10とか、100とかに昇華させていくというか。そういったことをするために集まるものだと思っています。

じゃあこの10や100にするために自分でできることって何だろうとか、みんなが意識して動けるとどんなことができるだろうとかを考えたり実践したりすることを求められる環境。あとは、そういうことを考えたり動いたりするのが得意な人も一定いると思うんですよね。

どういうかたちのマネジメントでもいいですが、マネージャーになって初めてこの課題と相対する方も多くいるのかなと思います。

個人的にはメンバーレイヤーの頃からこれを意識して動けるとすごくいいなと思っていて。例えば、「マネージャーにマネージしてもらうために自分のことをよりよく知ってもらう、より良く評価してもらうために自分はどんなことができるだろう」とか。あとは「自分が気持ちよく、みんなも気持ちよく働けるために自分には何ができるだろう」「周りにどんなことをしてもらうといいだろう」みたいなことを考える機会も（大事です）。

私自身それを実践することによっていろいろな視点を得ることができたし、一周回って技術力にも深みが出せたなと振り返ると思うわけですね。なので、この3つ目の軸の「組織」というのも大事なんじゃないかなと。

求められる三角形にどう自分のwillやcanをマッピングしていくか

先ほど2軸の時にお話ししたのと同じ感じですが、求められる三角形にどうマッピングするのか・マッピングしていきたいのかみたいなところって、個人の志向にもよるし、環境によっても大きく変わってくるなと思っています。

（スライドを示して）「軸の最大値も評価指標も相対的」と書いたんですが、例えば先ほどの話の高トラフィックなアプリケーションをサーブしているような環境では、技術の1目盛りを上がるのに「パフォーマンスに関するちゃんとした知識がある」ことが最初のハードルになるかもしれません。

「3マス行ったからどの環境でも技術的に強い」みたいな話ではなくて。この「最大値」も何を持ってステップを上がるかも環境によって大きく変わってくるところかなと思っています。

（スライドを示して）ちょっと見づらいかな？　大丈夫ですか？　あとでスライドを公開するので、よかったらその時に追いかけてみてもらえればと思います。

この青いところ……。一番左が重なっていて見づらいですね（笑）。あの青いところが、私が当時理解していた自分への期待。それに対して、黄色いのが自分のwillやcan。その時やりたいと思っていたこととか、その自分ができると思っていたこととかをマッピングしていってみています。誰にも言われていないのに、2015年当時の自分は、技術的にメチャクチャ尖っていることを期待されていると思っていた。

3つの三角形は全部軸の最大値も指標も違うので、押し並べるのもちょっと違うんですけど。とにかく技術的に尖っていることが強いと思い込んでいて。でも自分はプロダクトへの理解とか、チームでうまくやるとか、そういったところにも興味が向いていた（ところもあった）なと思うので、そういう感じで少しズレがあったかなと。

（スライドの）真ん中のところが前職ですね。2020年です。これはだいたい（期待と実感が）合っていたなと思うんですよね。

一時期「ビジネスモデルを転換するために何ができるか考えてみましょう」というタスクフォースにぶち込まれたことがあって。「僕はエンジニアなのにそんなのぜんぜんわからないよ」というところから、マーケティングの本とかをメチャクチャ読んだりしてキャッチアップをけっこうした結果、いろいろ見えてきた世界もありました。

なので、これは自分にとってはすごく良い経験になったんですが、そういったことがあって。当時期待されていたであろうことから、もう一歩事業に対して見る目線が得られたかなと思ったりしています。

（スライドの）一番右が最近のやつです。代表とよく話すんですが、話している感じでは、技術的に尖っていたりすることはこの環境ではぜんぜん求められていないなと最近感じています（笑）。

それよりも、なぜ・何を作るべきかというところで「しっかりみんなのことをリードしていってほしい」と言われていて。「なるほど。そうしたら新しい力を付けていかねばならぬな」みたいなところが今起きている、という感じですね。

なので、一番左の三角形を見て思うのは、「求められているパフォーマンスがきっちり出せていないような気がするな」みたいなことで悩んだり、苦しんだりしている方がもしいるのであれば、自分に期待されている役割の認知が、実は期待している側と少し相違がある可能性があるよという、その可能性を覚えておいてほしいなと思うわけですね。

Cake.jpにおけるテックリードとスペシャリストとエンジニアリングマネージャーの定義

次から2枚ぐらい参考（情報）みたいなスライド、Cake.jpにおけるテックリードとスペシャリストとエンジニアリングマネージャーの定義を持ってきました。テックリードを「技術力でもって事業に対してコミットし続けられる人」と指していて、それをやるためにはそのタイミングで正しいとされる技術選択がちゃんとできるということ。

あとは、そこに対してメンバーに一緒についてきてもらう、走ってきてもらうための、その一定のリーダーシップも必要とされるなと思っています。なので、技術特化というよりは事業だったり、組織だったりも一定振れている状態。弊社のメンバーにスペシャリストの枠でキャリアラダーを登ってくれている人は今はいないんですが、技術に尖っていること、特定の技術に深く精通していることを求めつつも、それをどう事業に転化していくのかというのと、それを今いるメンバーにどう敷衍していってもらうのかという視点で、事業や組織への理解も一定求めていきたいなと思っています。

「エンジニアリングマネージャーはちょっと面積が広くて大変だ」みたいな感じがするんですけど（笑）。それをどのチームで成していくのかって、今後の事業の成長戦略みたいなところも理解する必要があるし、やはりメンバーときっちりお話をするためにはある程度の技術力も必要だというわけで。（スライドを示して）こういうマッピングをしているなという感じです。

CTOに求められる事業フェーズ別のバランス

もう1個（スライドを）持ってきました。これは一口に「スタートアップとかでCTOをやります」と言ったとしても、求められる領域はその会社のフェーズだったり、周りのケイパビリティ、経営がどういうことが得意で、どういうところが不得意かに大きく左右されるなと思っています。

創業期って、まずPMF（Product Market Fit）をしましょうという話だと思うので、そのPMFをするためにとにかく手を速くたくさん（動かせる）、試行錯誤できるための実現力を持った人が一般的には歓迎されるのかな、みたいな。

あとは成長期、「上場に向けて少しずつ拡大していきましょう」とか「PMFをしてきたからそこをさらに伸ばしていきましょう」とか。そういったタイミングでCTOがいてVPoEがいて、PdMがいてみたいな布陣が取れるといいんですが、いろいろな事情から取れないこともあると思うんですよね。

そうすると、器用貧乏という（言い方をする）とよくないですが、CTOがある程度の何でも屋さんになって、技術のこともちゃんと見るし、事業に対してもちゃんと介入するし、組織もちゃんと作っていく。

（組織を）立ち上げて盤石にしていくことが求められるのかな。これって大変ですよね。たぶん私も今ここ（の立場）にいるんですけど、「すごい大変だな」と思っていて（笑）。

そこからさらに「円熟期」と言いましたが……。これもIPO前後のところはこういう体制が取れている人が多いんじゃないかなと思いますが、PdMがいて、その人が事業にしっかり責任を持ちます。それで技術に尖った人がいて、例えばその人がCTOをやります。組織に尖った人がいて、その人がVPoEをやるというような、チームでこの三角形を補完していくみたいな選択肢もどんどん取れるようになっていくのかなと思っています。この場合は、チームでどの領域を担うかみたいな話ができるといいと思います。

ずいぶん話が流れてきたので、ちょっとここらで休憩を入れようかなと思っているんですが、概ねオンスケで進行しています。よかったです！

（次回に続く）