コーディングを手放して、意思決定にフォーカスする—AIと歩む、これからのエンジニアキャリア論

導入

こんにちは、スタメンの名古屋本社でエンジニアリングマネージャー（EM）をしているあさしん(@asashin227)です。今回は、会社のアドカレ的な企画で記事を書いています。

2025年に入り、LLMがより一層身近なものになり、生活に溶け込んでくるようになってきました。私も、個人的にClaudeやGeminiの有償プランを使ってさまざまなタスクの効率化を行なっています。

さて、皆さんはどのようにAIを使っているでしょうか。検索サービスの代わりに調べ物をしてもらったり、面白画像を作ったり。エンジニアであれば、普段の開発業務やコードレビューで使うことが多いでしょう。

私は、1人のチームメンバーと同じような感覚でAIと接しています。

EMだからそのような感覚なのかというと、そういうわけではありません。emconfの広木大地さんのKeynoteでも言及されているように、すべてのエンジニアが、AIを管理するマネージャーになっていくべきだと考えています。

この記事では、AIにできるコーディングはAIに任せて、人間はAIでは解決できない部分にフォーカスするという働き方について、私の実体験を交えてお話ししたいと思います。

AIを「部下」として使うということ

私はAIを1人のメンバーと同じように接しています。

例えば、何かしらの機能開発を行う場合、人間のメンバーにタスクを依頼するのと同じようにAIに対してもタスクをアサインします。特に、具体的に解決方法がわかっている不具合や、実装方法が明確な小さなコンポーネント作成など、AIが得意としています。

実感として、ほとんどの定型的な開発作業はAIができるようになりました。 テストコードの生成、既存パターンに沿った実装、ドキュメント作成など、「正解がある程度見えている作業」はAIに任せられます。

一方で、人間が自分で手を動かす場面も残っています。それは、AIでは解決できない実装——例えば、情報が少ない新しいツールの検証、複雑な仕様の設計判断、チーム固有のコンテキストが必要な部分などです。

時には、とある機能の実現可能性を評価するため、プロトタイピングをAIに作成してもらうこともあります。細かく仕様が決まっていない段階なので、ふわっとした指示を行い、いきなり実装から入るのではなくて、実装方針をIssueに記述させてディスカッションベースで、プロトタイプの実装方針を固めていきます。

また、アイデア出しなどでは抽象度が高い状態から具体的な状態に持っていくための壁打ち相手をしてもらっています。

意思決定の具体例：CircleCIからXcode Cloudへの移行

「意思決定にフォーカスする」とはどういうことか、具体例でお話しさせてください。

当時、私たちの開発ラインは「CircleCI × Fastlane × Firebase AppDistribution」という、iOS開発における一種の『黄金構成』で安定稼働していました。高度な設定が可能で、ベータ配信のフローも確立されていて、特に大きな不満はありませんでした。

そこに登場したのが、「Xcode Cloud」でした。

もしここで、AIに「移行すべきか？」と聞いていたら、おそらく答えは「NO」だったと思います。

• 情報不足: Beta版のためドキュメントが圧倒的に少ない
• 機能退行のリスク: FirebaseからTestFlightへの強制移行により、QAフローが変わる
• コストの不透明さ: 時間単価は安いが、実運用コストが見えない

AIは既存の情報やパターンをもとに判断するので、データが少ないXcode Cloudへの移行は「リスクが高い」と判断されがちです。

スクリプトを書けることはわかっていましたが、どこまで出来るのかの検証ができていませんでした。実際、Xcode Cloudを使う場合、Firebase AppDistributionを使ったベータ配信はほぼ不可能でした。

でも、私は 「移行する前提での検証」を決断しました。なぜかというと、Appleのエコシステムに乗ることで長期的なメンテナンスコストが下がり、開発体験も統一できる——目先の混乱を上回るリターンがあると「直感」したからです。この直感は、過去の経験から来るもので、AIには持てない強みかもしれません。

もちろん、無謀な賭けはしたくないので、「並行稼働（Parallel Run）」という方法を取りました。無料期間を活用して、既存のCircleCIを動かしながら、裏でXcode Cloudを実運用水準で回し続けたんです。結果として不確実性が解消され、「これならいける」という確信に変わりました。

AIは「AとB、どちらが安全か」は教えてくれます。でも、「安全なAを捨てて、リスクあるBを検証してみよう」という意思決定は、責任を持つ人間の役割なんですよね。

この泥臭い検証プロセスと決断が、今の私の仕事だと思っています。

コーディングをAIに任せる—私の実践方法

では、実際にどうやってコーディングをAIに任せているのか、具体的にお話しします。

普段のEM業務を行っていると、じっくりキーボードを叩く時間がなかなか取れないというのが正直なところです。だからこそ、AIの力を思いっきり借りています。

私の開発パートナーは、Devin と Cursor です。

DevinWiki：全体把握に使う

まず、コードベース全体の把握には DevinWiki を使っています。以前は、新機能開発や不具合調査の前に「コードを読んで仕様を把握する」時間が必要でした。今は違います。Devinに「この画面名のクラスを探して」と投げるだけで、関連コードから設計仕様までが数秒でドキュメント化されます。

「事前の全体把握にかかる時間」は、大幅に削減できました。

Cursor：実装プランを練る段階で使う

そして、方針を立てて細かい実装プランを練る段階では Cursor を使っています。

先日とあるプロジェクトで、約2000行のテストコードをわずか10分で書きました。

……といっても、私がタイピングの達人なわけではありません（笑）。AIに生成してもらったんです。もちろん、一発で完璧なコードができるわけではなく、テストケースとして不完全な部分もありました。でも、大事なのはそこではなくて、

「人間なら半日かかる試行錯誤を、10分で終えられた」 ということなんです。
もちろん、その後の動作確認や修正には人の目が必要ですが、ゼロベースから必要な観点を含んだテストケースを大量に作ることができるインパクトは絶大です。

AIの提案に対して、私は `Tab` キーを押して承認するか、修正指示を出すだけ。正解が明確なタスク（明確な不具合修正など）は、自律型エージェントの Devin に並行して任せることもあります。

こうして私は、コードの「ライター（書き手）」から、「エディター（編集者）」や「レビュアー」へと役割が変わってきました。

もちろん、すべてをAIに任せられるわけではありません。AIが生成したコードのレビューや、AIでは判断が難しい設計上の決断、チーム固有の事情を踏まえた調整など、人間でないと解決できない部分は残っています。

ただ、そういった「人間にしかできない実装」に集中できるようになったのは大きな変化です。AIにできることはAIに任せ、空いた時間を「次に何をやるか」という意思決定や、AIでは解決できない実装に使えるようになったんです。

意思決定にフォーカスするために必要なこと：「Why」を持つ

ここで一つ、大事なことをお伝えしたいと思います。

コーディングを手放せば自動的にうまくいく……というわけではないんです。

AIの本質は「遂行」と「補強」にあります。人間がある意思決定（Direction）を行ったとき、それを素早く遂行したり、その意思決定に必要な根拠（Rationale）を補足したりするのは得意です。でも、「そもそも何のために、何をするのか（Why）」という起点は、AIには作れません。

• How（手段）: AIに聞けば、最適な実装パターンをいくつも提示してくれます
• Why（目的）: でも、「なぜ今、それをやるのか？」「どの課題を最優先で解くべきか？」という問いには、AIは答えを持っていません

つまり、コーディングを手放した分、「何をやるか」「なぜやるか」という意思決定の質を上げる必要があるということです。高性能な車を手に入れても、行き先が決まっていなければどこにも行けないのと同じですよね。

これからのエンジニアのキャリアにおいて大切なのは、「How」ではなく「Why」を考える力だと思っています。「この機能をどう作るか」だけでなく、「どの課題を解決すれば事業が伸びるか」というWhyを見つけ出し、仮説を立て、決断する。

AIにコーディングを任せることで生まれた時間を、この「Why」を考えることに使う——それが、私が目指しているキャリアの形です。

まとめ

ここまで、AIとの協業について私の実体験をお話ししてきました。

私自身、最初は「コーディングを手放したらエンジニアとしての価値がなくなるのでは？」という不安もありました。でも今は、「AIにできる部分はAIに任せて、もっと面白い意思決定やAIでは解決できない実装に集中できる」という期待の方が大きいです。

私たちがいるスタメンという場所は、そんな変化を前向きに捉えたい人にとって、良い環境だと思っています。「RxSwiftをリプレイスする」といった技術的負債の解消も、「AIに2000行のコードを書いてもらう」といったツールの活用も、すべては「事業のプレゼンスを高める」という目的のための手段です。

スタメンでは、AIにできるコーディングはAIに任せて、人間なら3日かかる仕事を30分で終わらせる。そして空いた時間で、次の「大事な意思決定」や「AIでは解決できない実装」に向き合う——そんな働き方を大切にしています。

エンジニアのキャリアの形は、少しずつ変わってきていると感じます。これからの時代は、コードの書き手（Writer）だけでなく、技術とAIをうまく組み合わせて、ビジネスで成果を出すための絵を描く、設計者（Architect）であり、決断者（Decision Maker）でもあることが求められるのかもしれません。

AIにできることはAIに任せ、人間はAIでは解決できない部分にフォーカスする——この考え方に共感してくれる方と、スタメンで一緒に働けたら嬉しいです。

スタメンでは、新卒・中途問わず、スタメンを一緒に盛り上げてくれる方を募集中です🔥

もし興味を持っていただけたらぜひカジュアル面談からお話しましょう！！