この記事でわかること
-
未経験からMVPを獲得するまでの「現場視点」を重視した学習戦略
-
特定技術のスペシャリストではなく「ピープルマネジメント」へ舵を切るキャリア戦略
-
心理的安全性を超え「自分たちならできる」と思える「組織効力感」の醸成術
エンジニアとしてのキャリアを歩む中で、多くの人が直面するのが「技術をどこまで深掘りすべきか」という問いです。特に昨今のように生成AIが台頭し、コードを書くこと自体のハードルが下がる中、エンジニアの「真の価値」はどこに宿るのでしょうか。
株式会社うるるの八巻凱斗さんは、文系大学出身・未経験というバックグラウンドからエンジニアの世界に飛び込み、入社後わずか3年で開発チームのリーダーに抜擢。2024年度には「Govtech事業年間MVP」を受賞しました。
彼が選んだのは、特定技術の極致を目指す道ではなく、「技術を広く浅く把握し、ピープルマネジメントに振り切る」という戦略でした。いかにしてベテラン層を巻き込み、レガシーなシステムのアップデートとチームの熱量を両立させたのか。その独自のキャリア論と組織論を詳しく伺いました。
八巻 凱斗
株式会社うるる Govtech事業本部 開発部 体験向上2課 課長補佐
2022年新卒入社。文系大学出身、プログラミング未経験からエンジニアキャリアをスタート。入札情報速報サービス『NJSS』のバックエンド開発に従事。2024年度には入社3年目でチーム長に抜擢され、「Govtech事業年間MVP」を受賞。チームのモメンタムを維持し、ユーザー体験向上のための新機能リリースとレガシーな技術のアップデートを両立させている。
株式会社うるる
「労働力不足を解決し 人と企業を豊かに」をビジョンに掲げ、CGS（Crowd Generated Service）事業を展開。入札情報速報サービス『NJSS』や電話代行サービス『fondesk』など、IT・AIとクラウドワーカーのチカラを活用した独自のビジネスモデルで社会問題の解決を目指している。
【X（旧Twitter）】：http://x.com/Uluru
目次
未経験からのスタートと「現場の痛み」を理解するためのキャッチアップ術
八巻さんは未経験からエンジニアとしてのキャリアをスタートして、圧倒的なスピードで組織を牽引する立場になられました。まずは、そのキャッチアップの秘訣から教えていただけますか。
実のところ、自分では決して「技術力が誰よりも高い」とは思っていません。ただ、未経験だったからこそ、「技術そのものを学ぶこと」と「プロダクトを通じて解決したい課題」を切り離さずに学習を進めたことが良かったのだと思います。
技術を目的化しない、ということでしょうか。具体的にはどのような学習戦略を取られたのですか？
最初は右も左もわからなかったので、とにかく「現場の痛みがわかるようになること」を最優先しました。例えば、バックエンドの開発でLaravelやRuby on Railsなどを使いますが、単に文法を覚えるのではなく、「なぜ今のコードが負債になっているのか」「なぜこの修正に時間がかかるのか」という、現場のメンバーが苦労しているポイントを理解するための知識を必死に集めました。
なるほど。現場で起きている「困りごと」の解像度を上げるために技術を学んだわけですね。その視点は、のちのマネジメント業務にも活きてきそうです。
おっしゃる通りです。技術的な背景やシステムの裏側がわかっていれば、メンバーがどこで詰まっているのか、何にストレスを感じているのかが具体的に想像できるようになります。
最近では生成AIなどのツールも普及していますが、八巻さんは最新技術をどう取り入れていますか？
生成AIなどは積極的に活用しています。未経験スタートだと「知識のムラ」がどうしても出ますが、AIをサポート役として使うことで、そのムラを補いながら実務を進めることができます。ツールの進化によって、技術の基礎さえあればキャッチアップの速度は格段に上がっていると感じますね。
個人のキャッチアップはもちろんですが、うるる社全体としてもAI活用を強力に推進されていると伺いました。
はい、エンジニア一人あたり月額100米ドル規模のAIツール利用が支援されています。会社全体で「AI駆動開発」を推進する土壌があるからこそ、私のような未経験スタートでも最新技術を積極的に試して、成長を加速させやすい環境が整っていると思います。
技術を「広く浅く」把握し、ピープルマネジメントに振り切る決断の理由
八巻さんのキャリアで非常に興味深いのが「技術を広く浅く把握し、ピープルマネジメント（※1）に振り切る」という決断を下されたことです。ミドル層のエンジニアの中には「もっと技術を深めないとマネジメントはできないのではないか」と悩む方が多いですが、そうした不安はありませんでしたか？
※1 ピープルマネジメント：メンバー一人ひとりのモチベーション向上やキャリア構築、目標達成などに寄り添い、個人のパフォーマンスを引き出すことで組織全体の成果を最大化するマネジメント手法のこと。
不安が全くなかったわけではありません。でも、自分の強みがどこにあるかを客観的に見たとき、一人の開発者としてコードを書き続けるよりも、「チーム全員が気持ちよく働ける環境を作り、組織としての出力を最大化する」ことの方が、自分にとっての成果の出し方として合っていると考えたんです。
個人の出力よりも組織の成果にレバレッジをかける道を選ばれたのですね。それは、うるるの開発組織が掲げている価値観とも非常にリンクしているように感じます。
おっしゃる通りです。私たちの開発組織では「一人の天才より結束したチームの力を信じる（チームでコトを成す）」という価値観を大切にしています。
なるほど。とはいえ、現場のエンジニアからすると、実装の詳細まで把握していない課長補佐やリーダーといったマネジメント層に対して、不安を覚えることもあるかと思います。そこはどうクリアされているのでしょうか。
だからこそ「広く浅く」なんです。自分自身で完璧なコードを書けなくても、メンバーと共通言語で話せるレベルの知識は絶対に維持する。その上で、「実装の詳細はプロである皆さんに任せます」と信頼を預けるようにしています。
実装を任せる一方で、技術的な意思決定など、どうしても深い知識が求められる場面に直面することもあるかと思います。そうした際はどう対応されているのでしょうか？
マネージャー業務と並行して、コードレビューや技術的な意思決定の場には今でも積極的に参加するようにしています。もちろん、深く技術を追えていない分、レベルの高い議論になるとわからないこともあります。
でも、そこは「わからなくてもいいから、恥ずかしがらずにとりあえず発言して質問する」という姿勢を徹底しています。そうやって現場のリアルな情報に触れ続けることで、メンバーと同じレベルで会話や認識ができる状態を意識的に維持しています。
すべてを自分で抱え込もうとせず、メンバーをリスペクトして「教えを請う」という姿勢は、若くして組織を率いる上で非常に強力な武器になりそうですね。八巻さんのその「しなやかさ」は、何か大切にされている信念から来ているのでしょうか。
私の座右の銘は「前言撤回」なのですが、これは優柔不断という意味ではなく、「過去の成功体験に固執せず、常に柔軟でいたい」という思いからです。例えば、現場からより良い意見が出て「こっちの方が組織のためになる」と判断すれば、自分の間違いや知識不足を認めてでも即座に軌道修正する。常にその時点でのベストな意思決定を追求するスタンスは、マネジメントで信頼を築く上でも、非常に重要だと考えています 。
心理的安全性の先へ。個人のWillを最大限に活かすチーム作り
八巻さんが組織運営で大切にされている「組織効力感」という言葉。すごく興味深いワードですね。よく耳にする「心理的安全性」とは、具体的にどう違うのでしょうか。
心理的安全性というのは、「何を言っても頭ごなしに否定されない」「失敗を恐れずに弱みを見せ合える」という、いわばチームの土台となる安心感のことです。これはベースとして非常に重要です。
一方で「組織効力感」は、その安心感のさらに先にある、「自分たちのチームならどんな困難でも達成できるよね」という、チームとしての強い自信や前向きな空気感を持っている状態だと定義しています。
「このメンバーならやり遂げられる」という自信ですね。ただ、そうした空気感は属人的になりがちで、意図的に作るのが難しそうに感じます。どうやって再現性を持って作り出しているのですか？
自分が一番意識してやっていることで言うと、「小さな成功の言語化」を徹底しています。これ、実は自分たちでも気づきにくいんですよ。数ヶ月前にできなかったことが今できているって、主観的に見つけるのはすごく難しいんです。組織でも同じことが言えます。
確かに、日々の業務に追われていると、目の前の課題ばかり見てしまって自分たちの成長にはなかなか気づけないですよね。具体的にはどのように言語化しているのでしょうか？
例えば、前回のプロジェクトが不具合など一切なしでリリースまで完遂しきったとき、その完遂しきるまでのプロセスや、今後の財産になるような取り組みを、しっかりテキストに残して伝えるようにしています。「自分たちはこれができるようになったんだ」と気づいてもらうためです。本当に些細なことでも「俺たちならできる」というのは意識して伝えるようにしています。
なるほど。それはどんなタイミングで伝えていますか？
ふとしたタイミングが多いです。気づいたときにすぐチャットツールなどで「これってできるようになってるの、組織としてすごくないですか？」と投稿してみたり、定例の最中にぽろっと伝えてみたり。そうした「確かに」と思えるポイントの積み重ねが、組織効力感の醸成に繋がっていると思っています。
リーダーが自分たちの現在地や成長をこまめに言語化していると、メンバーも前進している実感が湧いて、モチベーションが上がりそうです。
また、1on1では「Will-Can-Must」のフレームワークを用いています。メンバーの「やりたいこと（Will）」をしっかり把握し、「組織の目標（Must）を達成することが、結果として個人のWillの実現にも繋がっている」という状態を作ること。これが合致したとき、推進力は一番高まると感じています。
個人のWillと組織のMustを重ね合わせるマネジメントは、まさに組織効力感を高めるための核心ですね。
私が所属するNJSS事業本部でも、この「個人のWillと組織を重ね合わせたマネジメント」や「組織効力感を高めるチーム文化」は、組織全体の取り組みとして言語化され、大切にされています。個人の属人的なマネジメントではなく、組織の文化として根付いているからこそ、より強い推進力が生まれているのだと思います。
レガシー技術のアップデートを推進し、組織モチベーションに効かせる工夫
開発現場では、新機能の開発と同じくらい「レガシーな技術のアップデート」が重要ですが、どうしても地味な作業になりがちでモチベーションを保ちにくい側面がありますよね。八巻さんがマネジメントに携わる組織では、どのように両立させているのでしょうか？
おっしゃる通り、NJSSのように歴史のあるサービスだと技術的な負債の解消は避けて通れません。そこで大切にしているのが、チーム長時代から私が繰り返し伝えている「磨き、共有し、期待を超えていく」というフレーズです。レガシーな箇所のアップデートを単なる保守作業ではなく、「自分たちのプロダクトを磨き上げる重要なアクション」として位置づけています。
合言葉として明文化することで、負債解消への向き合い方をポジティブに転換しているのですね。
そして、プロジェクトが無事に成功したときや、大きなアップデートが完了したときには、「お疲れ様会」などを通じて感情を共有することをとても大切にしています。
「感情の共有」ですか。効率が重視される開発現場では、意識しないと抜け落ちてしまいがちな部分ですね。
「個人の成果」も大事ですが、それ以上に「組織の連帯感」を優先したいと考えています。システムを作っているのも直しているのも、結局は人間です。一緒に苦労を乗り越えた体験をしっかり喜び合い、ポジティブな感情を全体で共有すること。それが、次へ向かうためのモメンタムを生み出す一番のエネルギーになります。
周囲の力を借りる「巻き込み力」で拓くエンジニアの生存戦略
ミドル層のエンジニアがキャリアを考える上で、技術以外のスキルをどう掛け合わせるかは大きなテーマです。八巻さんはご自身の経験不足をどのように補い、ステークホルダーとの関係を構築されてきたのでしょうか。
私の場合は、若手ならではの「新卒バフ（特権）」を最大限に活かしました。未経験だったこともあり、わからないことは素直に「教えてください」と、部署の垣根を超えて色々な方に聞きに行きました。コミュニケーションの機会を意図的に増やすよう心がけ、周囲との関係性を構築していきました。
自分で抱え込むのではなく、周囲の力を借りる姿勢ですね。ミドル層のエンジニアにとっても、新しい技術領域やビジネス要件に関わる際、こうした「素直に他者を巻き込む力」は非常に重要になりそうです。
若手特有のバフがなくなったとしても、「自分の弱みを自己開示し、周囲を巻き込んでいく力」は、エンジニアのキャリアにおいて強力な武器になります。属人化を解消し、ナレッジ共有の仕組み化を推進できたのも、周囲のメンバーが快く協力してくれたおかげです。
周囲の協力があってこそとおっしゃいますが、その巻き込むスタンスはしっかりと組織に浸透しているようですね。実は一緒に働くメンバーの方からも「小さな成果を言語化してくれるから、前向きに取り組めた」というお声を伺っています。
それは素直に嬉しいです。自分自身、まだまだ手探りな部分も多いですが、一緒に働くメンバーが少しでもそう感じてくれているなら、今の方向性で間違っていなかったんだなとホッとしますね。
そうした人間同士の信頼関係や「人を巻き込む力」は、まさにツールには代替できない強みですよね。冒頭で生成AI活用のお話もありましたが、技術の進化が加速するこれからの時代において、エンジニアの生存戦略について最後にメッセージをお願いします。
ツールがどれほど進化しても、最終的に「どういう組織で、どういう気持ちでプロダクトを作るか」を決めるのは人間です。技術を深掘りする道も素晴らしいですが、もしキャリアに迷っている方がいれば、「技術を広く把握し、周囲を巻き込んで組織の出力を最大化する」というアプローチにも目を向けていただければと思います。組織効力感を高め、みんなで達成感を味わう経験は、エンジニアとしてのキャリアをさらに豊かにしてくれると信じています。
ライター
