「個人の開発者から生成AIを束ねるリーダーに」──その変化が引き起こす問題
熊谷氏は現在、エンジニア兼PMとして顧客の課題解決に奔走している。そこに至るまでの道のりは、平坦ではなかった。新卒でメーカーに入社し、飛び込み営業や商品企画を担当。その後Webコンサルタントとして転職したが、実態はクレーム対応係のようなもので、「強面の方に厳しく叱責されたり、部屋に長時間引き留められたりしたこともありました」と振り返る。そんな経験も、今ではいい思い出だという。
エンジニアとしてのキャリアをスタートさせたのは20代後半。同年代と比べて開発経験が短く、熊谷氏にとってコンプレックスだった。加えて完璧主義な性格も災いし、できない自分と周囲を比較しては自信を失う日々が続いた。
過去のクレーム対応で培った対人スキルが逆効果を招くこともあった。自分では手を動かしたいと思っていても、話が上手なのでリーダーを任される。「経験を積みたいのに、口ばかりで仕事する状態が続いてしまう」と熊谷氏は当時の悩みを語った。
そして生成AIが登場する。自然言語の理解力や回答を生成するスピードに驚き、「知識や経験の不足をカバーしてくれるかもしれない」と期待した。しかし現実は甘くなかった。
「指示を出すのはあくまでも人間で、AIが出してきたアウトプットを評価するのも人間です」と熊谷氏は指摘する。AIにうまく指示を出せなければ意図しないコードが生成され、AIが書いたコードをレビューできなければ品質も担保できない。こうした生成AIを扱う上での課題は、実力不足から生じる。「自分がやろうとしていることが、自分の力量を超えている」状態だ。そして、「AIを使っても、自分の実力以上の成果は出ない」という結論に至った。
熊谷氏はここで、過去の自分と現在のエンジニアの状況が重なることに気づいた。「生成AIを使った開発が当たり前になり、皆さんは個人の開発者ではなく、生成AIを束ねるリーダーになっています」。コードに向き合っていた人が、「コードを書いてください」と指示する立場に変わったのだ。
実装力が伴っていないと感じても、判断して指示を出さなければならない。それは、スキルアップの途上でリーダーを任された熊谷氏自身の経験と同じ構造だった。
「物事は進んでいくのに自分だけ取り残された」という焦燥感。それを埋めようと目先の技術力にフォーカスし、小手先の戦術に頼ってしまう。しかしAI駆動開発を用いたプロジェクトのリーダーになった今、手を動かす機会は確実に減っている。「コーディングの機会が少ない中で、実力をつけていくために何ができるのか」──これが熊谷氏の問題提起だった。
エンジニアリングの本質を見直す──カギは「エンジニアとしての原体験」
コーディングの機会が減る中でどう実力をつけるか。熊谷氏が提示したのは「原体験に戻る」ことだった。
「皆さん、初めて書いたコードや初めて作った仕組みのことをどれくらい覚えていますか」
熊谷氏が初めて作ったプログラムは、リスティング広告運用を自動化するスクリプトだ。毎日2時間を費やしていたキーワード入札単価の調整作業に限界を感じ、非エンジニアながら100行程度のコードを3日かけて完成させた。
「成果物が欲しかったわけではなく、無駄な仕事から解放されたかった」
初めてコードを書いたときは可読性など考えず、「その先にある価値が欲しかった」と話す。それがエンジニアとしての原体験だ。
しかし仕事では納期に追われ、本質から遠ざかることがある。熊谷氏は価値創造のため、Why、Whatに目を向ける4つの問いを示した。「誰のため？」「何を解決したいの？」「それは本当に困っていることなの？」「そもそもそれってシステム化する必要があるの？」特に重要なのが、後半の2つだ。課題が本当に存在しているのか、ピントがずれていないかを問うことで本質が見えてくる。
具体例として、ワークフロー機能の開発時に受けたフィードバックを挙げた。申請者が所属組織を手入力しているため選択式にしたいという要望だ。しかしよく話を聞くと、申請者だけではなく承認者も困っていた。表記は正しいが古い組織名が入力されるケースがあり、承認者のチェックが大変だったのだ。その結果、選択式だけでなく組織のリビジョン管理機能も追加し、古い申請を検知できるようにした。
「私たちがここにいる意味は、コードを書くことじゃない。成果物を納品することでも、デプロイすることでもない。そこから価値を生み出すのが、私たちのいる意味なんだ」と熊谷氏は強調した。
実践する機会としての「個人開発」、フレームワークによる学習の効率化
価値創造に向き合うためには実践の機会が必要だが、AIの普及で減りつつある。そこで熊谷氏は個人のプロジェクトを強く推奨した。「個人開発は公開しなくてもいい」。自分で使うためだけのプログラムで十分だし、誰にも見られないのでかっこ悪くても失敗しても怖くないという。
ただし一般公開するアプリを作るメリットも大きい。誰の何を解決したいのか、Why・Whatの部分としっかり向き合うことになり、上流から設計する経験が積める。さらに自分のサーバー代が月数万円飛んでいくとなれば、コスト最適化にも本気で取り組むようになる。そして利用者から「すごくいい仕組みだね」と言われることが励みになる。
作るネタがないという人には、「姓名判断プログラムで娘の名前候補を一気に判定した」「羽田空港の駐車場満空情報を1週間収集して、何時に行けば止められるか分析した」といった自身の開発例を挙げ、自分の生活を便利にするためのアプリ開発を勧めた。
また、学習効率化の手法として、アクティブリコールと分散学習も紹介した。
アクティブリコールは、勉強した内容についてテキストを見ずに思い出して書き出す方法だ。「おととい食べた晩御飯を思い出すときのように、脳に負荷をかけながら自発的に思い出そうとすることで、脳が重要な情報だと認識します」。受動的に読むだけより、記憶の定着が促される。
分散学習は、同じ内容を連続で学ぶより間隔を空けて繰り返す手法だ。2時間ぶっ通しで勉強するより、1時間ずつ日を分ける。間隔は3日後、7日後、10日後と徐々に広げていく。
熊谷氏はこの2つを組み合わせている。例えばAWS資格の勉強では、参考書を1章読んだら、Claudeのチャットに学習内容を思い出して書き出す。AIに添削してもらい、テキストや公式ドキュメントで答え合わせをする。これを3回繰り返し、数日後に同じチャットを開いて再度思い出して書き出す。「同じところがわかっていないな、というのが浮き彫りになり、苦手箇所がわかりやすくなります」
「価値創造のために課題を設定して解決策を実装する」改めて考えるエンジニアの役割とは
熊谷氏が最後に提示したのは、「人との関わり」を増やすことだ。リモートワークや生成AIの活用が当たり前になり、個人で解決できることが増え、人との関わりは確実に減った。
しかし熊谷氏は、そんな時代だからこそ人との関わり方を意識する必要があると語る。
「人との出会いは機会を生み出してくれる」
勉強会で得られる知見、「この社内ドキュメントが参考になる」という発見、コードレビューから得られるノウハウ。熊谷氏自身も、2024年のDevelopers Boostに先輩が登壇したことから、今回の登壇機会を得た。
社内イベントでの偶然の出会いも、仕事の突破口になった。熊谷氏が顧客のプロジェクト支援の際、開発体制そのものに問題があることに気づいていた。しかし与えられた役割は開発支援に限られており、組織や体制の課題には踏み込みにくい状況だった。
そんなとき、社内イベントでたまたま話した相手がアジャイルの担当者だった。開発体制を診断するサービスがあることを教えてもらい、それが顧客への提案の糸口になった。「武器をもらえた」と熊谷氏は振り返る。一人では解決できなかった課題が、人とのつながりによって道が開けた瞬間だった。
エンジニアだけでなく、営業やマーケティング担当との関わりも重要だ。熊谷氏は新卒のメーカー時代に社長から言われた言葉を紹介した。
「お客様は私たち作り手が想定していないような使い方や、発想を持っています。その発想を聞いているのは、社内では営業やマーケティングの人間です」
つまり、何を作るべきかという開発の源泉は営業・マーケティングにある。だからこそ、そのつながりを大切にしなさいと教えられたのだ。
営業・マーケティングの人と関わるとき、熊谷氏が強く推奨するのが自己開示による「同期コミュニケーション」だ。SlackやTeamsで質問を受けたとき、「ちょっと喋っていいですか」と言ってコールしてみる。お互いにオフィスに出社しているなら実際に会いに行くのもいい。
「迷惑がられるのでは」と思うかもしれないが、熊谷氏は会いに行って嫌がられたことは一度もないという。「むしろ『エンジニアの人が会いに来てくれた』とすごくチヤホヤしてもらえます。ちょっと嬉しいと思いますよ」
人によっては勇気がいる話ではあるが、ぜひ同期コミュニケーションを取り入れてほしいと語った。
最後に熊谷氏は改めてエンジニアの本質を語った。「私たちエンジニアは価値創造に向かって課題設定して解決策を実装する人間である。そこにエンジニアの価値があるということは、これまでもこれからも変わらない」
そこに向かうための武器は、これまで出会ってきた人たちや、やってきた仕事に詰まっている。「皆さんの人生がこの課題解決、価値創造のための武器になっていきます。その一瞬一瞬を大切に生きてもらって、皆さんのエンジニアリングが利用者の方や、皆さん自身の人生を豊かにしてくれることを願っております」と述べ、講演を締めくくった。
