エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
こんにちは、株式会社エウレカでCTOをしている kaneshin です。
この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。
はじめに
株式会社エウレカは、恋活・婚活マッチングアプリ「Pairs」の運用とオンライン結婚相談所「Pairsエンゲージ」の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。（Pairsは以下「ペアーズ」と表記します）
入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世の中に出すことができるところまでマッチング市場は成長してきています。
自己紹介：経歴とスキル
エウレカに入社する前は、組込み系企業の株式会社ACCESSに新卒として入社しています。ソフトウェアエンジニアとして入社しましたが、新卒一年目は品質保証を経験させるという会社の方針でQuality Assuranceをやらせてもらいましたが、この知識と経験は今でも活きていると感じます。
退職後は数学の最適化理論の研究の手伝いをしていて、C言語によるLimited-BFGSをベースにした改良アルゴリズムの実装を行っていました。併せて、バンクーバーに語学留学もしていたりと、エウレカに入社するまではWeb系とはほど遠いい経験です。
2012年から2014年までエウレカは受託事業もしていたので、入社してからはペアーズの開発・運用しつつ、受託案件が忙しくなった場合は受託案件のサポートもしていました。
そんな当時のエウレカで得られたスキルを列挙するとなると、かなり多くのものをCTO就任までに経験させてもらったと思います。勝手に手を広げていたといっても過言ではない気もします。
- 2012~2013: PHP & JavaScript & QA
ペアーズの立ち上げ期だったためバックエンドはもちろんのこと、ペアーズのスマートフォン向けのWebも構築していました。委託した案件ではテストケースを作って渡すといった、前職のスキルを活かしていたこともあります。 - 2013~2014: iOS & Android & PHP & Infra (on AWS)
自社事業（ペアーズと他含む）のアプリを作るということでiOSアプリをメインにネイティブアプリの開発をしていましたが、その傍らでは受託案件の対応もしていたので、そのときは領域を限定せずにバックエンド含めて全般をやっていました。 - 2015~2016: Go & AWS
ペアーズのサーバーアプリケーションはPHPで書かれていたのですが、今後を見据えてGoでリプレイスするプロジェクトが開始することになりました。当時はネイティブアプリのマネージャーでしたが、ここからバックエンドメインに戻ってきました。
こう見るとバックエンドエンジニアがキャリアとして長い気もしますが、フロントエンド全般となるWeb, iOS, Androidの開発をしているときが一番楽しいですし、2015年以前の私を知っている人からするとネイティブアプリエンジニア色の方が濃い気がします。
さて、私の経歴とスキルの話しで長くなってしまいましたが、エウレカに入社してからは「自社事業と職種に関わらず広い領域で仕事をしていた」というのが私のキャリアの背景にあります。
キャリアとは？その考え方と背景について
少し前置きが長くなりました。さて、キャリアについて考えていきましょう。まずは言葉の定義から入りますが、そもそも「キャリア」とはなんでしょうか。前置きでもキャリアという用語を使用していますが、日本語では意味が広義的なため、使うのが躊躇われる苦手な言葉です。
英語としての “Career” は日本語に訳すと「経歴」です。しかし、経歴だけでこれからの時代で生きていけるのでしょうか？私と社内や社外にて1on1や面談・面接をしたことがある人は聞いたことがあるかもしれませんが「このご時世キャリアなんてあってないようなもの」とよく言っています。かっこいい経歴なんて役に立ちません。どのような肩書きも自分で起業して名乗ってしまえばそれだけで履歴書に書くことができます。
それでは、私自身がどのようなものをキャリアとして位置付けた軸として考えているかと言うと、「どのような状況下においても生きていけるスキル」をキャリア戦略として考えています。
時代の移り変わりでも使えるまで知識を深掘り続ける
なぜこの考えに行き着いたかというと大学時代に就職活動していたときに遡ります。とある企業の新卒説明会で「産業における輸送の変遷によって技術は進歩し、その変遷によって活躍するスキルも変遷する。それに依存しないスキルを新卒から身に着けるべき」という話を聞いたことが頭に残っています。
ここからさらに考えたこととして、私が専攻していた数学は定理や公式をただ覚えるのではなく、その根底にある定理の考え方や公理の在り方の方が重要であり、それらを知ることで数学の別の分野を勉強してもゼロから勉強することなく、今までの考え方を応用することができます。
このようなスキルの礎となる部分にリソースをかけてキャリア開発を行っていくことが、これからエンジニアが自分自身の専門性に自信を持てる一つの指針になると思っています。
スキルの礎となる知識がないとどうなるのか
多くの方に多いのは「自分の考察がない」場合が多いです。悪い意味で「雰囲気でコードを書いている」や「○○が流行っているから選択した」といった状態です。
また、このような知識がないと技術的な知識の深みと幅によって生み出されるアイディアの量と質に影響が出てきます。例えば、ミドルウェアやクラウドサービスの知識がないと、アプリケーションコードだけで対処してしまうことが発生したり、また、「技術的負債」に対して「なぜ負債なのか」をブレイクダウンしていく言語化や幅の広がりもなくなってしまいます。
このような礎の知識を体系的に学べるのが高専や大学・大学院でのコンピューターサイエンスであり、それらを卒業した方たちは当たり前のようにこの知識を持っていると思います。そして、これらは事業で成果を出す業務の中ではなかなか必要とされないと考えている人をたまに見かけますが、そんなことは全くありません。コンピューターサイエンスの知識を蔑ろにする人は何もわかっていません。
ちなみに、面接などでは「何故、○○（例：Clean ArchitectureやGo）を導入したのですか？」と聞くことで、どこまで考察しているのかを深掘りすることができるのでスキルの深みをヒアリングすることができます。これは面接官だけでなく、面接を受ける側も企業側への問いとしてもっておくことで、その面接官がどれだけスキルを持っているかがわかるはずです。
礎となる技術的な幅と深さ
ここから少し技術よりの話にフォーカスしていきます。さきほど「どのような状況下においても生きていけるスキル」のキャリア戦略をお伝えしましたが、それを考察するにあたってピラミッドモデルに当てはめて考えています。
DIKWピラミッドをベースとしてスキルの幅を考察する
技術の幅を拡げる考えのベースとしてDIKWピラミッドという考えにある、Wisdomレイヤー、Knowledgeレイヤー、Informationレイヤーとして考えて技術スキルの伸長の変遷を考えています。
DIKWピラミッドでのKnowledge Managementでは階層化された領域に分けることができます。
- Wisdom：知恵
- Understanding：理解
- Knowledge：知識
- Information：情報
- Data：データ
認識に至るまで、どのように情報を人が考えているかをピラミッドで図示しています。InformationレイヤーのからKnowledgeレイヤーへ情報を連結させていくことと、KnowledgeレイヤーからWisdomへ連結された情報を判断に利用することができることになります。これらを一般化して、スキル習得のために置き換えたものは去年書いた記事にある「学習進化の５段階モデル」になるのでぜひご参照ください。
学習進化の５段階モデル
- 第１段階「無意識的無能」：何も知らない
- 第２段階「意識的無能」：意識してもできない
- 第３段階「意識的有能」：意識すればできる
- 第４段階「無意識的有能」：意識しなくてもできる
- 第５段階「無意識的有能に対して意識的有能」：他人に秘訣を教えることができる
ここの話しはCMMI (Capability Maturity Model Integration) とあわせて考察すると、考えが深くなると思います。
技術的な幅と技術的な深さを考察する
スキルの身に付け方の余談が入ってしまいましたが、キャリア戦略として具体的なイメージをつけるためにTechnical Breadth（以下、技術的な幅）とTechnical Depth（以下、技術的な深さ）というのをピラミッドで表現します。
さきほどのDIKWピラミッドをエンジニアとして必要となるプロセスと領域として言い換えつつ、簡易的にした図示したものです。
このピラミッドでは技術的な幅の領域を拡大させていくことや技術的な深さ技術的な深さを追求することをベースに考えることができるものです。図にある英文の意味を軽く日本語で説明すると下記になります。
- Stuff you know：知っていること
「知っているし、できること」で、日常のエンジニアリング業務において必要となる技術やフレームワーク、プログラミング言語の知識についてです。 - Stuff you know you don’t know：知っているようで知らないこと
「知っているけど、できないこと」で、聞いたことはあるが、それについての専門的な知識を持ち合わせていない場合です。例えば、AWSについてはよく聞くと思いますが、それらを使いこなすことができない状態を指します。 - Stuff you don’t know you don’t know：知らないことは知らない
「知らないし、できないこと」で、ほぼ知らないことを指します。例えば、RTOS (Real-time OS) は組込み系では耳にしますが、Web系では知らない人が多くいると思います。
技術的な幅と技術的な深さについて、どのようにアプローチして伸長させていくかがエンジニアとしてのキャリアを考えていく軸になると思っているので、それを身につけたほうが良いと思うスキルの順にご説明します。
1. 技術的な深さを追求して、専門性を向上させる
エンジニアはまず最初にピラミッドの最上部にある “Stuff you know” の領域にフォーカスして拡げていくべきで、ほとんどの場合が業務と直結しているためです。ここは当たり前ですが、最も重要で忘れてはならないことです。
ここで伝えたいことは一つ、結局は「ここの専門性をどこまで深めていくのかが重要」というのをいつまでも忘れないで欲しいのと、自分自身の専門性をどこに据えるのか、というのを将来的に考えることになるはずです。
そして、専門性はiOSやWebといった絞り過ぎたプラットフォームに依存しない考えを持って欲しいです。ここを絞り過ぎるとキャリア迷子になってしまうことが多いように感じます。しかし、この依存しない考えは技術的な幅を拡げるときまでは忘れてしまっても構いません。
この「絞り過ぎている」と思うタイミングは必ずきます。それは専門スキルに自信を持ってから数ヶ月後に訪れる「やっぱり技術わからない」と思ったときだと考えています。
これは、いわゆるダニング＝クルーガー効果をもとにしています。
「ダニング＝クルーガー効果」
優越の錯覚を生み出す認知バイアスは、能力の高い人物の場合は外部（＝他人）に対する過小評価に起因している。一方で、能力の低い人物の場合は内部（＝自身）に対する過大評価に起因している。
これを図示化したものが下記のグラフになります。
ダニング＝クルーガー効果の最初に自信がついたところから下降して自信をなくすときは今まで見えていなかったことが見えてきたときなため、このときから技術的な幅を拡げていくフェーズに入ると考えています。
今まで見えていなかったことが見えるというのは、視野の広さと視座の高さが変わっているときです。
2018年に記事を書いているのでこちらもぜひ読んでみてください。
2. 深さを追求したら技術的な幅を拡げて視野を拡げる
専門性の深さを追求して、自分自身に足りないところが見えてきたら今度は技術的な幅を拡げるフェーズです。
ここからキャリア開発の仕方に悩んでいる社外の人が多いなと話しをしていると感じます。技術的な幅の拡げ方を知る機会がないので、単純に幅広く知識を身につけようと考えている方が多いです。幅広く知識を身に着けるときに、いままでご自身でやられていた専門性と全く関係のない領域に手を伸ばす人もいますが、それは正しいこともあるし、間違っていることもあると思っています。
拡げ方は、前の方に書いた「スキルの礎」に対して、学んだことがどのように還元されるのかを軸に専門性を深める相乗効果を生むべきです。この考え方を持っていると、スキルの身に付け方の視点が変わると思います。
研究なども、新しいことをやるときに全くのゼロから開始することは少ないです。今までの知識や経験を活かしながら横展開させて研究をし、そして、その新しい研究が今までの研究に活かされて、新しい発見となることがあります。
料理も、和食の作り方を軸に勉強をしていれば、新しい発見をするために違った領域の料理の研究もしています。そのようにして、自分の専門性を深めるために知識を横に拡げていくことを常に念頭においておくべきです。
間違えても「別のプラットフォームもできるようになりたいからやる」というような考えて手を出してはいけないと考えています。根底となる「スキルの礎」を今以上に深化させるために新しいことに手を伸ばすべきです。
エウレカではこの考えを最初に持ってもらってからチーム異動などをしています。むしろ、この考えと専門スキルの深さがある程度あれば誰でも異動しても大丈夫だと考えています。
ここまではスタンスとして昔に書いた記事も一読してもらえると幸いです。
3. 技術的な深さを追求するか、技術的な幅を強化するか
ここからは今回のメインのトピックではないのですが、1と2を長期で経験されてきたあと、どのように今までのスキルを超えた状態になるのか、という場面です。深さを探求するエキスパートとなるか、幅を強化したアーキテクトやエンジニアリングマネジメントなるか。
ここについては各々の考えもあると思いますが、ひとつだけ言いたいこととしては、エキスパート、アーキテクト、エンジニアリングマネジメント、これらをどれか注力したときにも他の分野に応用が効くことを忘れてはならないし、応用が効く領域です。
どれか一つのキャリアパスを選んだとしても、他の領域を経験したければ変えればいいだけです。それができるスキルは既に1と2で身についているはずです。逆に、その自信が無いなら、まだここのフェーズではないということです。
事業成長≠スキル成長
事業の成長がスキルの成長に関連しているかというと、間接的は影響はしているが直接的には関係ないと考えています。この考えは「どのような状況下においても生きていけるスキル」の上で非常に重要だと考えています。
そもそも事業成長＝スキル成長の場合、売れている事業を持っていると見えやすい結果を出している人がスキル成長したと見られて、給与があがったりします。
その人は本当にエンジニアとしてのスキルが成長しているのか？社内で裏側を支えている人の方が本当はスキルとして上なのではないか？
そのような矛盾は組織として、その人のキャリアを殺す可能性が高いので、事業成長はマネージャー以上の責務であり、事業成長はスキル成長をさせるための良い機会として認識して、最適なアサイン計画を行うことがマネージャー以上の仕事だと考えています。
「給料をあげたい」もいいモチベーションだと思います。その機会をどのように作っていくのかが、マネジメントの仕事です。
そして、事業が成長していないときに給料があがらない（＝ここでいうスキルが成長していない）もエンジニアとしては正しいのか？とよく考えます。幸いなことに、現在のエウレカは事業成長をし続けているので、マネジメントに注力してからこの課題に実際に直面することはありません。
しかし、とある企業では事業が成長していないが、個人としてはしっかりと成長する機会があり技術的な幅や深さが拡がっている人も多くいます。そのような人を企業はしっかりと評価をすべきですし、本当に逃してはいけない人材です。どのような状況でも自己成長できる人は稀です。
企業としてのキャリア戦略の軸を定める
いろいろと記事中に書いてきましたが、一番重要なのは企業としてブレない軸を定めておくことは、これからキャリア開発することと採用をするにあたって重要な要素となるはずです。
特に、海外企業ではこのような取り組みは昔から行われています。キャリアに対する考え方がそもそも日本は特殊で、いままでの終身雇用という制度によって未熟なところが多いです。
海外企業を参考にしていくと、キャリア開発のCareer Ladderを外部向けに発信しているところもあります。
キャリアに責任をもって、人を採用すべき
このご時世、本当にフリーランスでも活躍することができるし、人によっては社会人をしているよりかも自由度の高い仕事をしつつ、高い収入を得ている人もいます。
そのように手に職を持っている人は選べる立場にいることを踏まえて「なぜ、このご時世に企業に属するのか」を永遠のテーマとして真摯に考えていくことがマネジメントレイヤーとして考え続けることだと思います。
技術の切り売りをする環境ではなく、技術を身に付けられる機会が提供される企業に属すことがキャリア戦略として大事だと個人的には考えています。
このようなスタンスをもって、採用する人に対するキャリアに責任が持てないなら、それはその人に対して不誠実なので採用をすべきでないとも考えます。自分たち、マネジメントレイヤーのために採用をすることだけでなく、相手の人の人生まで考えたキャリア戦略を考えて採用をするのがこのご時世で必要だと常々考えます。
いうても、スタートアップは生きるか死ぬか
ここまで読まれたスタートアップ在籍の方もいると思いますが、スタートアップではキャリアのことを考える前に、目の前にある事業が生きるか死ぬか、そもそも会社にあるキャッシュが簡単に底を突くこともあります。
そんな中でこのようなキャリアについて語る前に、目の前の事業に向かった方がよいです。そういう世界を選んだのなら、キャリアを捨ててでも向かわなければならない事実です。
そのため、スタートアップにいくなら、最低限の技術的な深さはそもそもあることが前提だと思っています。無いまま幅を拡げることになりかねない状況になります。これはまた事説あるので、どこかの機会で書くかもしれないし、書かないかもしれないです。
おわりに
エンジニアのキャリアについて、私の経歴や背景から持っている考えと、これからエンジニアとして生き残っていくために必要なキャリア開発としてのスキルの身に付け方についてお話しました。
これは自分自身が意識して行動するのもそうですが、そのようなキャリア設計がされているエンジニア組織に在籍することも重要だと考えます。
エンジニア組織はそれこそ企業によってそれぞれ特色があると思いますが、どのエンジニア組織も人の成長を踏まえた組織設計をしていると思います。そのため、この記事は別に答えではなく、ひとつの考え方だと認識してもらいたいです。
人間が絡んでくるマネジメントについて、自分たちの価値観をおしつけることはあってはならないです。どのように作用するのかを考えて、おしつける形ではなく、相乗効果の生まれる組織が良いと思っています。
早く行きたいなら一人で行け、遠くへ行きたいならみんなで行け
アフリカのことわざですが、この言葉は組織設計の上で重要にしています。エウレカにも Peer Power という「多様な個々の力を掛け合わせ、ビジョンを手繰りよせる。」と意味を持ったバリューがあり、それぞれの価値観を認識しあって目的に向かっていくことを掲げています。Diversity & Inclusion ですね。
さいごに、この記事を読んでもっと突っ込んでお話しを聞いてみたい場合、カジュアルなリモート1on1も最近していますので、ぜひ気軽にお声がけください。（※お知り合いの方のコンタクトはDMで一報もらえると助かります）
