シェア
はてブ
みなさん、こんにちは！あらたま（@ar_tama）です。 ソフトウェアエンジニアとしてキャリアをスタートさせ、事業会社のテックリードや、レイターステージのベンチャー企業でのCTOを経て、現在は株式会社LayerXのバクラク事業部でEM（エンジニアリングマネージャー）をしています。
自分の軸足はソフトウェアエンジニアリングにあると思っていますが、エンジニアリングスキルをいったん脇に置き、事業そのものの価値を押し上げる目的で、違う領域に注力していた時期も少なからずあります。裏を返せば「エンジニアリングで突き抜けることを選ばなかった」ことの負い目と独り相撲的に戦ってきました。何なら今もその葛藤の只中にいる自覚があります。
葛藤は一般にはさらけ出すのも躊躇するような感情ではありますが、いかに研鑽を積もうともそういった感情はなくならず、隣の芝はずっと青くあり続けるのではないでしょうか。ならば葛藤によって足を止めるのではなく、いっそのことまるっと受け入れて原動力としよう。私も長年燻らせてきましたが、ようやく最近そう思えるようになりました。
我々の仕事がAIに奪われる未来が現実めいてきた変化の激しい今だからこそ、様態に固執せず変化の波をしなやかに乗りこなす力が大事だと思います。本稿では、私が葛藤を受け入れて、波を乗りこなすべくトライしてきたことや、その結果得られたものを、キャリアのいちサンプルとして取り上げてみたいと思います。
巻頭写真：丹野雄二 撮影
発揮できるスキルは自分のWillだけでなく環境に依存する
前提として、ソフトウェアエンジニアとして発揮できるスキルの形はさまざまであり、誤解を恐れずに言えば、全員が全員「スーパーハッカー」になる必要はないと私は考えます。なぜなら我々は雇用の形態を問わず「特定の目的のもとにソフトウェアを形にすること、形にし続けること」にコミットしているわけで、そこでどのようなスキルを見つけて伸ばしていくかは、エンジニア自身の「こうありたい」と思う方向性（以降、Willとします）と同等かそれ以上に、その環境（チームやプロダクト）に依存するはずです。
例えば、戦略としてRailsとGoに技術を統一している環境に身を置くエンジニアが「Scalaを導入したい」と考えたとき、Scalaを書ける・キャッチアップできる人がいない、あるいはJVMアプリケーション運用の知見がないといった理由で、導入を諦めざるを得ないことはあります。しかし時が流れて、Scala経験者が環境に増え、SREの層も厚くなってきた状況であれば、また結果は変わるかもしれません。
このように自らが所属する環境において、自身と環境の向いている方向が揃っているかどうかを定期的に確認することが大事だと私は考えています。この「定期的に」がキモで、なぜなら人も環境も変化するものであり、ソフトウェア産業では変化の量とスピードが顕著だからです。
特にエンジニアであれば、多様で底の深いエンジニアリングスキル（ハードスキル）に加えて、チームでこなす役割（ソフトスキル）の深掘りも必要です。さらに事業会社の内製エンジニアならば、事業への理解やコミットが求められることもあるでしょう。時間がいくらあっても足りません。
周囲からの期待＝環境と自身の認知は揃っているか
私は2023年3月にYAPC::Kyotoへの登壇で、周囲からの期待＝環境と自身の認知が揃っているかどうかをレーダーチャートを用いてマッピングすることで、視覚的に捉える取り組みに言及しました（詳細は下記の発表資料やアーカイブ動画を参照してください）。
▲ あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで - Speaker Deck
自らのキャリアを振り返ると、今思えばではありますが、新卒時代は自分の役割認識が周囲からの期待や要請とズレていることが多かったように思います。当時の私はバックエンドエンジニアとしてだけでなく、プロジェクトマネージャーやチームリーダーといった役割を兼務することもありました。
しかし、自分や周囲がきちんと見えていなかったからこそ「この環境で、技術でもって突き抜けることを期待されているんだ」という思い込みから脱却できず、マイナス面ばかり気になってしまい、自分で上げた成果さえも客観的に受け止められませんでした。自分の状況を客観的に観察することは、このように意識的に取り組んでさえもなお難しいものなのです。
インポスター症候群から脱するには
お気づきの方もいらっしゃるかもしれませんが、前述の新卒時代での出来事は、いわゆる「インポスター症候群」の典型例でもあります。周りが強い（強そうに見える）ばかりに、自分の実力をうまく客観視できていない状態です。こうした状況を脱するには、次の3つが必要だと私は考えます。
- 自身を客観視するスキル
- 定量化できる成功体験
- 周囲からの承認
今思えば、私自身には2も3も十分過ぎるほどあったのに、1が未発達なために脱せない状況が長く続いてしまったと反省しきりです……。この状態は自分が苦しいだけでなく、自分ができたことを「当たり前」と捉えてしまうため、周囲に要求するラインが不当に高くなってしまうこともあります。そのためなるべく早く脱するに越したことはありません。
現職ではマネージャーとして、同じように苦しむ仲間が生まれないような・脱せるような仕組みづくりにチャレンジしています。
変化の激しい環境でこそ実践したい「キャリアの棚卸し」
環境からの期待と自身の認知を理解するには、ざっと挙げられるだけでも以下のステップがあります。
- 自分は人生においてどうなりたい・どうありたいか？（Will）
- 会社はチーム・プロダクトをどう成長させたくて、自分には何を（どんな役割を）期待しているか？
- 自分はチームの中でどうありたい（またはチーム・プロダクトをどうしたい）か？
- これらにどう折り合いをつけるか？ ギャップがあるならどう埋めるか？
見るからに大変ですね……。とはいえ1に関しては、必ずしもきちんと明確に理解できている必要はありません。言ってしまえば私もまだまだ曖昧なところがあります。 そのため2から4を繰り返すうちに1が炙り出されてくるのを待つ、というアプローチによって軌道を適宜修正するようにしています。
この一連の振り返りプロセスを私は「キャリアの棚卸し」と呼んでいます。 自分自身を理解することは、実は誰かを理解する以上に大変なものです。そのため定期的に「棚卸し」をして、自身が楽しいと感じるポイント、モヤモヤを感じているポイントをまずは認知することから始めましょう。
仕事の目標設定にあわせてキャリアを継続的に棚卸しする
ソフトウェア開発は変化の量もスピードも激しい業界ですし、市場もこちらのことなんてお構いなしにどんどん変わっていきます。特にベンチャー企業では顕著に現れます。気が付いたら入社時の目論見とは大きくズレた遠いところまで流されてきてしまった……と感じている方も少なくないでしょう。
棚卸しを何度か繰り返せば、「あんなにワクワクしていたプロジェクトも、最近はあんまり面白くないかも？」というように差分が見えてくるはずです。 この差分に目を向け、原因を深掘りしていくことで次に取るべきアクションが明確になり、早く軌道修正できるようになります。 始めは大変かもしれませんが、繰り返すと徐々に楽になります。私自身、漫然としたモヤモヤを抱える頻度も減ったように感じます。
ただ、これが息をするようにできるようになるかというとそうでもなく、「やるぞ〜」という気持ちが必要なこともしばしば。 そのため私は、会社において一般に半年や1年の単位である「目標設定・評価」のサイクルと合わせることで、繰り返しやすくしています。具体的な仕事と一緒に、気持ちやキャリア観といったものも棚卸ししましょう。
期待の掛け違い・すれ違いを防ぐ自己評価プロセス
話は少し横道にそれますが、評価における期待の掛け違いによるすれ違い、つまり被評価者は「こんなに頑張ったのに全然評価してくれない」と感じ、評価者は「頑張ったことは伝わっているけど、期待はもっと高かったから評価は据え置き」と判断する状況がしばしば発生します。
これは評価者のマネジメント能力不足も一因となり得ますが、実は被評価者が「頑張る方向は期待と沿ったものだったか？」「頑張った結果どのような価値につながったか？」という自己評価プロセスをおろそかにしていたというケースもあり得ます。「アピールしなくても評価してくるはず」という言外の期待を持つのではなく、自己評価による振り返り結果をもとに、丁寧にかつ頻度高くコミュニケーションを取ることにより、すれ違いを防ぐことができます。
また、会社において絶対評価は存在せず、相対評価のみであることを前提として受け入れることも重要なように思います。会社に限らず社会は役割分担によって回っています。 例えばピッチャーが粒ぞろいの環境にピッチャー志望のビギナーが入ってきても、レギュラー獲得までの難易度は一般的には他の環境よりも高いでしょう。 さらに「お手本がたくさんいるから早く成長できる環境」と捉えるか「自分が全然活躍できない環境」と捉えるかも、自分が何を求めているかで変わってくるはずです。
自己評価を通じて環境の捉え方をアップデートする
このように置かれた環境の捉え方は、持っている視点によってさまざまです。複数の視点を持つことで初めて世界を立体的に捉えることができます。 自己評価の過程で「社長には今のエンジニアチームがどう見えているだろうか？」「みんなから見たチームの健康状態はどうだろうか？」といった想像をめぐらし、ときには実際に聞いてみたりもして、自分の認知とのギャップを修正していきます。
このギャップが埋まらない状態が長く続くと、人はコミュニケーションを取ることすら諦めてしまいかねません。私も過去に「この人には何を言っても無駄だから……」「どうせ何をやっても状況は変わらないから……」と諦めてしまったことがあり、たいへん悔しい思いをしました。
しかし、これは対応が後手に回ってしまったがゆえの状況とも言えます。対話を諦めない姿勢と、ギャップにいかに早く気付けるか、それをリカバリできるか、そのための仕組みを作ることが肝要です。 そして自己評価の過程で視野が広がり解像度が上がった結果、より最適な技術選択・実装・コミュニケーションができるようになっていくはずです。
▲ 前述したYAPC::Kyoto 2023で登壇する筆者（写真提供：Japan Perl Association）
最適なキャリアパスをOODAループで模索する
私はこれまでのキャリアで、ど真ん中のエンジニアリングだけでなく、プロジェクトマネジメント、クライアントワークの上流工程、事業開発、組織開発、ピープルマネジメント（エンジニアだけでなくデザイナー・PdMを含む）、プロダクトマネジメントといった隣接領域を、時には自ら志願して、時には巻き込まれながら経験してきました。そもそも出身が音楽大学であるため、キャリアのスタートラインからズレていた感はあるのですが……。
とはいえ短期的には「寄り道」かもしれない経験が、後から意外なところで役に立つこともしばしばあります。振り返ってみるとそういった経験が、冒頭で触れた葛藤の一因になっていることも否めませんが、前述した「複数の視点を持つ」ことにつながり「視野が広がり解像度が上がった結果、より最適な技術選択・実装・コミュニケーションができるように」なった理由でもあると思っています。
実際、ソフトウェアエンジニアとして大きく成長できたと感じる一番の出来事は、ど真ん中のエンジニアリングではないプロジェクトにありました。
以前、事業会社でエンジニアとして働いていた折に、現行のビジネスモデルを顧客視点に立ち戻って捉え直しアップデートするプロジェクトに、多様なバックグラウンドを持つメンバーの1人としてアサインされたことがあります。それまでも「ユーザーに価値を正しく素早く届けること」にコミットしてきたつもりでしたが、この活動を通じて「ユーザーへの価値」への解像度がそもそも粗く、さらに「その価値を企業活動としてどのように循環させるか」という視点が抜け落ちていることに気づいて愕然としたのです。
企業という生き物が成長していくには、届けた価値がロスなく対価へと転換され、それが循環・拡大している状態を作ることが不可欠です。一見当たり前のことではありますが、マーケティングを始めとするビジネス的な観点を取り込んでこそ、ソフトウェアで価値を生む・生み続けることの本当の意味を理解し、実践できるようになりました。
寄り道を焦らずに楽しめるように
こうした例を踏まえると、ソフトウェアエンジニアにとって最適なキャリアパスが存在するかどうかすら怪しくなってきます。当事者の1人としても、現職のマネージャーの立場としても、自分や周囲の未来に選択肢を増やすことならできるでしょうが、そこに最適なパスが含まれていると断言はできません。
となれば、キャリアにもOODAループ※を適用し、細かく軌道修正をかけていくスタイルが時代に即しているのではないかと私は考えます。
例えば「思い切りエンジニアリングに没頭できる環境で働きたい！」といったWillがあったとして、そんな理想の環境を維持するため、あるいは探すために、時には意に反したタスクをこなす必要もあります。今自分がやっていることは何のためか？ 何につながっているか？ それを「自分」と「環境」の視点から観察し、行動する。その繰り返しによって、焦らず「寄り道」を楽しめるようになるのかもしれません。
私の場合、こういった「寄り道」はまさに葛藤の発露であり、中には恥ずかしながら「正攻法でやっても突き抜けられないなら、いっそのこと逆張りしてみるか」といった気持ちで始めたものもありました。ただし、やるからには全力で取り組み、その過程で自分のキャリアにおける柱が見つかることを期待していました。今でも、やることを絞りきらず「必要かも」とか「面白そう」などと感じたことに柔軟に取り組めるよう心がけています。
逆説的ではありますが、自分の現状が最良だと思わず、もっとよくできると考えること。価値観や柱は経験によってこそアップデートされるものなので、無理に方向を規定せず、越境しながら取り組むつもりでいること。これは曽根壮大さんが以前に触れられていた「計画的偶発性理論」にも通じますが、自身のユニークなスタンスになっていると感じています。
※ OODAループ＝Observe（観察）、Orient（状況判断、方向づけ）、Decide（意思決定）、Act（行動）を繰り返す意思決定のフレームワーク。アメリカ空軍のジョン・ボイド大佐により提唱された。
弱みは強み
また、マネジメントにおける過去の自身の失敗として、「弱み」を「克服すべきもの」と捉えた表層的なコミュニケーションをしてしまっていたことがあります。実際には弱みと強みは表裏一体であり、その人を形作る大事な特性の1つです。軽々しく否定してよいものではないことも往々にしてあります。
たいていの場合、私たちはチームプレイをしているので、できないことを無理してできるようになるより、補完できるようなチーミングこそがやるべきことです。また、弱みを見せあえる、補完し高めあえるチームであればこそ、こうした葛藤も足を止める要因ではなく、チームが生み出す価値を最大化する原動力へと昇華できると確信しています。
まとめ ─ 変化に対応し続けるために
業務フローに変化が起きれば、システムも適切にリファクタリングする必要があります。変化に対応し続けられないシステムは歪みを生じ、やがては技術的負債となってしまいます。同様に、私たち自身も変化に対して硬直化しないよう、柔軟に対応し続ける必要があるように思います。
とはいえ一概に変わることがよいというわけではなく、「変えたくないな、この部分は大事にしたいな」と感じたら、思い切って環境を変えることもよい選択肢となるかもしれません。私自身も、状況の変化に全力で食らいついてみたことで身についた視座もありましたし、また変化に対する周囲とのスタンスの違いが転職理由の1つとなったこともありました。
変化に対応し続けるために大事なのは、現状に甘んじずアンラーンし続ける意志を持つことなのではないかと私は思います。ゴールを見失わず、振り返りを繰り返すことで自分や環境の変化に敏感になれれば、浮かんだ「なぜ？」を深掘りする過程で次の一手の精度を上げられるはずです。
一見遠回りに思えますが、結局のところこうした地道な一歩の積み重ねでしか自分の道を作ることはできず、それゆえに積み重ねによってどんなところへも歩いていけるという希望にもなるとも言えるのではないでしょうか。
本稿が皆さんのモヤモヤを晴らす一助になれたら、こんなに嬉しいことはありません。いきいきと働く私たちが作る素敵な未来を夢見て、筆を擱きたいと思います。
▲ 現職の株式会社LayerXのスタッフと（右から2人目が筆者）
編集・制作：はてな編集部
【アーカイブ動画】Findy Engineer Lab アフタートークイベント
あらたまさんに聞く 意思決定の決め手 ~自分を客観視したキャリアの棚卸し~
・開催日時：2023/12/5（火）12:00~13:00
・アーカイブ視聴方法：こちらから
※視聴にはFindyへのログインが必要です。ご登録いただくと、Findy上でその他の人気イベントのアーカイブ視聴も可能となります。
新多 真琴（あらた・まこと）
国立音楽大学卒業後、DeNAでソフトウェアエンジニアとしてキャリアをスタート。その後はセオ商事、ロコガイドを経て、Cake.jpにて執行役員CTOを務める。現在はLayerXにてバクラク事業部のEM（エンジニアリングマネージャー）を担当。趣味は全国津々浦々のサウナ探訪。「日本もちもち協会（@mochimochi_org）」代表。
blog: たまめも(tech)、ar_tama｜note
