転機その3 「ストレングスファインダー」の活用

海老原昂輔氏:おぼろげながら、自分と他者との違いがわかりかけてきた私に訪れた、第3の転機が、このストレングスファインダーです。(スライドを示して)これはさまざまな質問を通じて、自分の強みや癖を可視化することで、自分らしいアプローチで成果を出せるツールです。

このツールで、34ある資質の順位が決まるのですが、このうち1から10位を上位資質と呼びます。この上位資質は、無意識に繰り返される思考、感情、行動の癖で、呼吸をするように自然にできているものです。上位資質は、「≒強み、才能」と思ってもらってけっこうですが、時として裏目に出てしまうことがあります。つまり、弱みになってしまう、短所になってしまうことがあります。

しかし、ストレングスファインダーによって可視化して、ある程度自覚することで、弱みになるほど強く出てしまうのを意識的に制御することを可能にするという役立て方ができます。

ストレングスファインダーは、判定のための設問が非常に多く、「あなたはズバリ○○タイプ」というかたちで出てくるわけではないので、使いこなし方がかなり難しいのですが、そのおかげか自分から見ても、他人から見ても、かなり納得感のある結果が出てくることが多いようで、社内でも非常に盛り上がっています。

「他人と自分はまったく違う人間で、山の登り方がぜんぜん違う」という気づき

私のストレングスファインダーの結果を、持ってきました。(スライドを示して)左側が上位資質で、右に行くほど下位の資質になっています。私の上位資質のうち、多くは緑色の戦略的思考力で、続いて紫色の実行力となっています。他方、青色の人間関係構築力が右に集中しているのがわかると思います。

先ほど私は、上位資質は呼吸をするように自然にできているものだと言いました。裏を返して何を意味するかというと、私は人間関係の構築を呼吸をするように自然にはできないということです。これはまったくそのとおりで、自然にはできていないです。

詳細に分析していくといろいろあるのですが、かいつまんで説明すると、とにかく思考したり掘り下げて考えたり、本質まで突き詰めたり、アイデアマン的な感じで新しいなにかを閃いたりなど、バイタリティがメチャクチャある一方で、無理しがちとなっていて、私は本当にこういう人間です。ある意味わかりやすいかもしれません。

CARTA HOLDINGSの中でストレングスファインダーが流行って、CARTA HOLDINGSはいろいろ共有し合う文化があるので、ストレングスファインダーの結果も共有している人がけっこういます。ということで、私以外のファインダーの結果も持ってきました。

(スライドを示して)私と同じ部署のエンジニアの結果ですが、資質の傾向がまったく異なります。同一部署、同一職種でも異なります。私は戦略的思考力が中心ですが、この方は青の人間関係構築力が中心です。また、違うエンジニアは、緑の戦略的思考力が中心なのは私と変わらないものの、よく見ると資質の内訳は異なっています。対極の戦い方は共通しているけれども、そのアプローチはけっこう異なってくるということです。ほかにも部署内の営業職で、これは違う職種ですが、私と同じ資質傾向が出てきています。

それから人事の2名。これも同一部署の同一職種で異なっています。特に最後の方に注目してもらいたいのですが、人間関係構築力にすごく偏っています。ということは、この方は呼吸をするように人間関係を構築できるというわけで、僕は非常に羨ましいと思います。

要するに他人と自分はまったく違う人間だと、山の登り方がぜんぜん違うのだということに気がついたわけです。ちなみに社内のボルダリング勢に言わせると、壁の登り方も違うようです。狭いフィールドの壁すら違うのですから、いわんや人生や仕事においてもそうだという感じではないですか。同じような成果を出しているように見えても、実際の成果の出し方は異なることが普通にあるよというのが、客観視、可視化されています。

教えてもらったわかりやすい例で言うと、同じ営業職で人脈を広げるのがミッションだったり得意だったりする人たちの間でも、片方は人間関係構築力で自然と広げていくのに対して、片方は戦略的思考力によって完全に打算で広げていきます。しかも、それが自覚的であるというところです。私のような陰キャからしてみれば、人脈を広げているという結果だけを目にして、この人は誰とでも仲良くできる陽キャなんだと勝手に決めつけてしまいそうですが、実際にそういう人と深く付き合ってみると、イメージと違うなということはけっこうあると思います。

結果だけを見ていると、どうしてもそういう細かいプロセスの違いや、やり方に目がいかなくて、誤解をしてしまうところが出てくるという証左だと思います。ともあれ、各々によって成果は異なるのであれば、チームとして外せないポイントさえ守ってもらえれば、やり方はなんでもよくて、それぞれの強みを活かしたアプローチを取ってくれればそれでいいよ、それでパフォーマンス出してくれたほうがいいよという方向に、自分の中で気持ちが変わりました。

これを痛感してようやく、メンバーの特性に合わせてコミュニケーションをするという方向に大きく転換しました。この結果だけを見ても、背中で語ったと言うのはちょっと恥ずかしいというか、背中がしゃべるわけはないので、本当にへそで茶が沸いてしまうような感じだなと思いました。へそで沸くのかって話なのですが、沸いてしまったみたいですね。

自分の考えと行動を「セルフハック」した

ということで、具体的にどういう変化が生じたかですが、これは常駐であるLighthouse Studio CEOからのフィードバックがわかりやすかったので持ってきました。(スライドを示して)全文は恥ずかしいので読みませんが、「第三者的に見て、内面的に良い方向に変化があった」と言ってもらっています。どういうことかというと、この前に見てきたようにストレングスファインダーによって、自分と他人の特性を客観的に見つめ直して、行動のチューニングを行ったということです。

私の結果を見てわかるように、打算や理屈、計算で振る舞いを決めているのですが、その理屈にチューニングをちょっと加える必要があると判明したので、チューニングしたところ、第三者から見てそれが大きな振る舞いの変化として現れたということです。長年見ていたCTOに「急に別人のように良くなったけど、何があったの?」と心配されるぐらい驚かれて、「ストレングスファインダーというものがあってね」と説明しました。

どうチューニングを行ったか。私は笑えてくるぐらい人間関係構築力が低くて、これは薄々気がついていたことが客観的に可視化された感じなのですが、同時に自然にできてしまうタイプの人も存在するというのが明確になりました。

自分は、自然にできてしまう人と同じ振る舞いはできないだろうと気がつき、痛感したので、アプローチをちょっと変えてみました。客観的に示された自分の強みを活かして、弱みをカバーできないだろうかと考えたわけです。そのために他人を知り、分析したのは、戦略的思考力そのままですね。

さらに、唯一の人間関係構築力である「個別化」を活かす、つまり、他人を尊重することを意識的にやりました。これはもともとやっていたことですが、自分とは明確に違う資質傾向が世の中にはたくさんあるんだぞという事実をたくさんインプットしたので、それが自分とは異なる部分をリスペクトする機会の醸成に大きくつながりました。

ストレングスファインダーに出会ったことによって、個別化に拍車がかかったという部分があったかもしれませんし、当然他人の分析にも大きく活用しています。「セルフハック」という言葉がありますが、自分の考えと行動をある指標に基づいてハックしたと言えるのではないかと思います。

海老原流マネジメント道は「マネジメントではなくエンジニアリングをすること」

このようにいろいろな転機がありました。これを経て築かれた「海老原流マネジメント道」とはどんなものかというと、「マネジメントではなくエンジニアリングをする」。ズコッとみんながずっこけている音が聞こえますが、大丈夫です。背中がしゃべっていた頃の海老原はもういないので、大丈夫です。

(スライドを示して)どういうことかをもう少し説明すると、ソフトウェアエンジニアリングから我々が学んできたことは、たくさんあったはずなんです。例えばヤグニや、「Don't guess, measure!」や「DRY」、プログラマーの三大美徳、リーナスの法則、「関心の分離」、「Worse Is Better」。こうしたプラクティスは、ソフトウェアエンジニアの血となり、肉となっているはずです。

ただ、そもそもなのですが、これはソフトエンジニアリングのためだけのものだっけ? と思うわけです。実はそうしたものの大半は、エンジニアリング共通のプラクティスとして一般化できるのではないかと考えました。私たちは図らずも、そのことを事業をエンジニアリングすることで体現してきています。私たちが遂行する事業は、ソフトウェアエンジニアリングから学んできたメソドロジーが多かれ少なかれ反映されています。「リーン」の考え方は、多分に科学的で、多分にソフトウェアエンジニアリング的だと思います。

ということは、people領域においてもひょっとしたらエンジニアリング対象にできるのではと考え、その1つの指標として、ストレングスファインダーを導入したらどうなのかと、試行錯誤したわけです。それ以外の領域も活用できるかもしれないと言うと、ちょっと誤解があるかもしれません。要するに「人間とソフトウェアを同一視しているのか」と、お怒りの声が聞こえてくるような気がするので、もう少し具体的に説明をさせてください。

(スライドを示して)エンジニアリング対象領域を拡大するとはどういうことか。要はエンジニアリング対象領域を拡大して、個々人の特性に左右されにくいプラクティスを見出して、再現性の向上や属人性の排除につなげていけないかと考えています。つまり、プラクティスを応用分野であるソフトウェアエンジニアリングから、基礎分野であるエンジニアリングに一般化していくわけです。他の領域のエンジニアリングでも同じように一般化できる要素がたくさんあると思います。

そうして一般化していった成果を各応用分野に反映し、広めていくことで、エンジニアリングの力で誰でも再現性を持ってその領域の問題を解いていくのを可能にするということを目指しています。あくまでその1つとして、people領域があると捉えています。

こうして行き着くのがこれだと思っているわけです。(スライドを示して)これが私が思い描く理想的な状態です。CTOもVPoEもプロダクトマネージャーもエンジニアリングマネージャーもテックリードもいないと言うと、また誤解があるかもしれないので、もう少し正確に言うと、みんながCTOをやり、みんながVPoEをやり、みんながプロダクトマネージャーもやり、みんながエンジニアリングマネージャーをやり、みんながテックリードをやる。こういうのが理想だなと思っています。

結局、マネジメントによって何がしたいのか

すごく荒唐無稽な話に聞こえるかもしれませんが、CARTA HOLDINGSのエンジニアとしては、実はちょっと納得感があります。私たちは、Netflix社が提唱する「フルサイクルエンジニア」を地で行っているところがあります。「フルサイクルエンジニア」を簡単に言うと、ソフトウェアライフサイクル全体に対する責任を全員が持つことによって、サイロ化をなくしていくスタイルです。

ライフサイクルのすべての領域に対して知識があり、活動できます。それを個人の力量に依存せず実現していくために、みんなで共用可能なツール、ナレッジを育てていきましょうという考え方です。

ソフトウェアエンジニリング以外の事業やピープルに対して応用して、そのためにみんなで共用可能なツールやナレッジを育てていったら、みんながマネジメントできるようになる。そうしたらマネジメントにおける属人性は剥がれて、スケールするのではないかというのが、先ほどのお話です。このモデルをソフトウェアの領域に対して実践している私としては、違和感がありません。

結局のところ、マネジメントは何がしたいのか。事業をエンジニアリングする上で、当然経営的観点は無視できません。そうなると、CXOだけがスケールを判断するのはリスキーだし、スケールしないですよね。プロダクトを作っていく立場としても、戦略や設計なしにエンジニアリングしていくのは不可能に近いです。そうであれば、プロダクトマネージャーだけにそれを委ねるのは、やはりリスキーです。

ピープルに関して言えば、各々の距離が近い現場内のほうが解像度が高いはずです。解像度が高いがゆえのギクシャクや、バイアスもありますが、そうであっても解像度が低いよりは、より正鵠を射たアプローチができる可能性が高いです。見えているがゆえの苦悩やバイアスは、技術や知識でカバーできる領域なので、見えていないよりはマシかなと思います。

あとは評価もあります。ただ、評価に関しては、私たちはすでに技術力評価会という武器を持っていて、評価の専門性や属人性からは解放されています。なので、マネジメントだけに期待するのは、危ういのではないかと考えているわけです。

エンジニアリングマネージャーは“自分の仕事がない状態”を目指してほしい

ということで、ここで突然ですが告知があります。私たちLighthouse Studioでは、エンジニアリングマネージャーとシニアエンジニアを募集しています。「さっきエンジニアリングマネージャーはいないのが理想だと言ったじゃん」と思われるかもしれませんが、ちょっと説明させてください。

(スライドを示して)エンジニアリングマネージャーの方には、Lighthouse Studioのエンジニアリング組織の拡大にとって、効率的なピープルマネジメントを行ってもらいたいなと思います。もともとの我々の強みを活かして、それをよりスケールさせるための戦略を立てて、実行してもらいたいと思っています。

ここまでは普通で、ここからちょっとおかしなことになってきます。その専門性をCARTA HOLDINGSのエンジニアに展開して、布教して、普遍化して、エンジニアリングマネージャーとしての仕事がなくなるほどに浸透させてもらいたいです。これは先ほど見てきたフルサイクルエンジニアの考え方とまったく同じで、サイロ化を防ぐものです。

より強力にスケールさせていくためには、どうしてもこういうことが必要だよということで、我々は日常的にシステム化することによって、エンジニアとしての自分の仕事を次々となくしていっているので、それと同じことをしてくださいというだけです。要するに自分の食い扶持をなくすというミッションを掲げてやってもらえる方を募集しています。仕事がどんどん増えていく一方で、なんだかんだ食い扶持がなくなることはないので、たぶん大丈夫かなと思います。

ということで、気を取り直して、再告知です。Lighthouse Studioでは、エンジニアリングマネージャーとシニアエンジニアを募集しています。エンジニアリングマネージャーは、ピープルマネジメントを軸にLighthouse Studioの組織拡大に寄与してもらうとともに、ご自身の専門領域を一般化して、エンジニアリングマネージャーの仕事を奪ってもらいます。

シニアエンジニアは、私がこうした目的でピープルマネジメント領域のエンジニアリングの応用をやっていくので、私からソフトウェアエンジニアの仕事を奪ってもらいます。どちらも募集しているので、もし興味がある方がいれば、ぜひ採用ページに立ち寄って、いろいろ見てもらえればと思います。カジュアル面談からでも大歓迎です。議論もしたいですね。

マネジメントをいったん捨てて、エンジニアリングを一般化して応用するというアプローチ

ということで、まとめです。(スライドを示して)本発表では、私、海老原 昂輔のこれまでの経験を踏まえて、自分の強みを活かして、自分らしいマネジメント手法を模索していったという話をしました。この、マネジメントではなくエンジニアリングするという、ちょっとふざけた感じの本気のマネジメント手法は、みなさんもそのまま使えるとは限りませんが、ここにたどり着いた経緯や道筋から、なにかを得てもらえれば、至上の喜びです。

ついでに言うと、私みたいな癖を持つ方は、他の本では「人と仲良くしましょう」と集約されるケースが多いですが、それができたら苦労しないじゃないですか。そうした方においては、試しにマネジメントをいったんかなぐり捨ててもらって、エンジニアリングを一般化する、得意とする領域を一般化するというアプローチを一度試してもらえればなと思います。なかなか光明になり得るのではないかなと思うので、そこで得たフィードバックも見られると楽しいです。

私の目標は、本質的にマネジメント職を必要としない組織を作り上げることです。これは荒唐無稽に聞こえるかもしれませんが、手応えを非常に感じつつあるので、ぜひ共感し、手を貸してもらえる方はお声掛けをお待ちしています。ということで、ご清聴ありがとうございました。