Zenn
😸

開発のボトルネックは人間の脳である

に公開
AI
idea

俺達の戦いはこれからだ

開発に AI を取り入れることで過去に類を見ないスピードでの実装が可能となっている．これからの開発で何がボトルネックとなるのかを考えたときに，「人間自身の脳」という可能性に至ったのでまとめた．

そもそも AI に実装を任せることについて

視点：「コードの危険性」は誰が書いたかよりも，どのように検証・運用されるか

人間が書いたコードでも危ない．人間によって書かれたというだけでは安全性は担保されない．

AI も同様に，未熟な設計や不十分な検証によって危険なコードを出力することがある．しかしこれは，「AI が危険だから」ではなく，「検証プロセスが不十分だから」である．

AI 特有のリスク

ただし，AI にはいくつか人間と異なるリスク要因もある．

  1. ブラックボックス性：

    • AI の出力は，特に大規模言語モデルの場合，どのようにその結論に至ったかが不透明．
    • 意図しない形で，過去に学習した脆弱なパターンを再生することがある．

  2. 信頼の錯覚：

    • 「AI が出したから正しいだろう」と思い込みやすく，コードレビューやテストが甘くなる傾向がある．

  3. 規模とスピード：

    • AI は人間よりはるかに高速にコードを量産できる．チェックが追いつかずに未検証のコードが大量に広まるリスクがある．

したがって，「AI だからこそ起こりやすい事故の構造」があるのも事実なので，本質的な議論に進むには，「誰が書いたか」ではなく，「どう検証され，どう使われるか」に着目する必要がある．

AI に任せられる環境の構築

今後のエンジニアに求められるのは，「誰が書いたか」に左右されず，コードの品質と安全性を担保できる仕組みづくりと運用能力ではないだろうか．

1. 検出と防止の仕組み化（再現可能な安全性）

  • コードレビュー：形式的ではなく，目的を持ったレビュー文化の定着．
  • テストコード：単体・結合・E2E テストを適切に分け，CI で常時実行．
  • 静的解析 / Linter / 型チェック：自動検出で属人性を下げる．
  • セキュリティスキャン：依存ライブラリや脆弱性のチェックも自動化．

2. 開発フロー設計（事故の起こりにくいプロセス）

  • ブランチ戦略と CI/CD：
    • 開発 → ステージング → 本番の流れを明示的に．
    • マージ前にすべてのテストがパスする仕組みを作る．
  • レビュー＋検証のダブルゲート：
    • 人の目と自動チェックの両立．
  • トレーサビリティの確保：
    • 誰が，何を，なぜ変更したかを追跡できるようにする．

3. 人間と AI の協調設計

  • AI が補助する開発では，AI の提案を「盲信せず，検証する文化」が重要．
  • たとえば，AI が生成したテストコードを人がレビューする，逆に人間のコードを AI が静的解析するなど，「お互いを監視する」ような仕組み．

今後のエンジニアは，「手を動かす人」から「品質とプロセスを設計・運用できる人」へとシフトしていく．開発をリードする立場のエンジニアは「チームの中で運用を定着させる・標準化する」役割が求められるだろう．

🔧 「コードを書く力」だけでなく，
🔍 「コードを安全に運用する仕組みを作る力」が問われる時代

1 事業 1 エンジニア時代

上記のような体制を築き AI を有効活用できれば，詳しくない領域も AI で補いつつ一人で高速に開発を進めることも可能だろう．「強いエンジニア＋ AI」による少人数・高速開発」という戦略は，今後ますます有効かつ現実的な選択肢になっていく．

「強いエンジニア＋ AI 開発」の魅力と利点

  1. 情報の劣化・齟齬の最小化

    • チーム間のやりとりが少ない分，「意図が伝わらない」「理解のズレ」などのミスが起きにくい．
    • 一人で一貫して実装〜テスト〜運用まで手がければ，設計思想も通りやすく，品質も担保しやすい．

  2. AI による知識補完で“守備範囲”が広がる

    • 詳しくないフレームワーク・言語・セキュリティ領域なども，AI を活用すれば最低限の品質を保ちながら突破できる．
    • 強いエンジニアであれば，AI の出力の良し悪しも判断できるため，“AI の暴走”も防げる．

  3. ドキュメントやコードへの意識が自然に高まる

    • 人とのやりとりが減る分，文書化や構造化が「自分のため」になる．
    • 「自分が忘れる」ことを前提に設計・記録するスタイルは，結果的に他者にとっても価値がある成果物を生みやすい．

チーム化とのトレードオフ：人が増える＝抽象度が下がる

人数が増えるほど，次のような現象が起きる：

現象 影響
意図の翻訳・再解釈が必要になる 設計の微妙なニュアンスが失われる
足並みを揃えるコストが増える スピードが落ち，調整コストが増える
全員の理解水準が揃わない 「誰かに合わせて妥協する設計」が必要になる

これらはすべて，開発の「純度」と「スピード」の低下につながり得る．AI が開発を行う前提でエンジニアが仕組みや設計を担う必要がある．

つまり今後は，

「AI が使う設計や仕様が壊れないように整備する」
＝ 「AI に優しい設計・ルール・文脈の提示」ができるエンジニア

が重要になる．「人間だけでなく AI のオンボーディングも意識した開発」とも言えるだろう．

今後の開発スタイルのイメージ

🧠 人間のエンジニア（設計・意図・仕様の決定者）
   ↓
📄 意図を形式知化（ドキュメント・ルール・プロンプト）
   ↓
🤖 AIエージェント（コード生成，テスト，デバッグなどを分担）
   ↓
🔄 自動フィードバックループ（CI/CD，AIによる品質監視）

このように，AI をチームメンバーとして扱える構造を設計・運用できるエンジニアが，今後の開発の中心となるだろう．

ではチームはいらないのか？ → そうではない

上記の理屈を見るとチームを組むよりも極端な少数精鋭が最適解に感じられるが，筆者はそう考えていない．「チームを持つ意味」や「人を巻き込む動機」 は従来とは変わってくるものの依然として非常に重要である．

従来のチーム編成の目的と，今後の変化

従来のチームの目的 今後の変化
作業の分担（分業） AI により代替・自動化が進む
スキル補完（フロント，インフラなど） 強い個が AI を使って複数スキルを代替できる
スケーラビリティ（人海戦術） AI に適した設計と運用でスケールする

「人とチーム」の意義

  1. 問題発見・戦略・文脈構築は人間に強く依存する

    • AI は「出された問いに対して最善を尽くす」存在．
    • しかし**「何を作るべきか」「本当に問題なのは何か」**を定義するのは人間の役割．
    • 異なる視点・領域の人と議論することで，自分ひとりでは気づけない課題設定や戦略が生まれる．

  2. 人を巻き込むことで成果物の影響力・定着力が増す

    • チームメンバーが参加することで，組織内・顧客側への浸透力が増す（オーナーシップ・共感の醸成）
    • 自分がいなくてもシステムが残る．技術的遺産を共有できるようになる．

  3. 信頼・共創・長期的価値の創出は，人との関係が前提

    • プロダクトは単なるコードではなく，人と人の約束・関係の上に成り立つもの
    • だからこそ，信頼を築ける人間同士での協働は AI では代替できない
動機の変化 従来 これから
労働力として集める タスクを分担したい AI が補うため必要性が低下
視点の多様化 必要なら集める 自分では気づけない視点がほしい
意志決定の質 自分で決める 他者との対話で問題設定・戦略を深めたい
関係性の価値 やや副次的 信頼と共感が成果を左右する主軸になる

今後の開発における最大のボトルネックとは？

「問いを立て，構造を創造する思考の限界」が，今後の開発のボトルネックになる．AI によって「実装速度」は加速したが，「思考速度」や「問いの質」は加速しない．

開発は加速するが人間は加速しない

  • 実装やドキュメント化，テスト，UI 設計，運用…これらは AI が補助・自動化可能．
  • しかし「これはそもそも正しい課題か？」「より良い構造はないか？」といった根源的な問いは，深い背景知識，経験，想像力に基づく．
  • さらに，こうした問いは人が自分で考える以外の方法がない．

この流れで見えてくるのは，今後，人を増やす目的は「手を動かすため」ではなく，「思考を並列化するため」になるということである．

つまり，チームは手を動かす機械の集合ではなく，思考と仮説のパターンを増やす集団として捉えられる．

AI を活かすためには

真の意味で AI を活かすためには実装のスピードアップ=思考するための時間の創出という捉え方が必要である．

AI の力で生まれた余白を，

  • ユーザーや課題への理解
  • 意図の言語化・設計の練り直し
  • 中長期視点の戦略的判断

などに振り向けた人やチームが，最終的に最も大きな価値を生み出すようになる．

AI によって実装スピードが n 倍になったからと言って案件数も n 倍にすれば，エンジニア一人あたりの思考時間は n 分の 1 になってしまう．

結果として言葉通りの粗製乱造となり，エンジニア自身のモチベーションも削られてしまうだろう．スピードが出たからこそ，思考の質を落としてはならない．

まとめ：これからのエンジニアのしごとと開発に必要なもの

今後のエンジニアの仕事は下記のようになるだろう．

  1. 何が本当に重要な課題か？
  2. この課題をどう分解し，どの順で解決すべきか？
  3. 誰にどんな価値を，どんな構造で提供するべきか？
  4. その意図を AI や他者にどう伝えるか？（形式知化・プロンプト・設計）

これらを深く考え続ける負荷こそ（人間自身の脳の限界）が，新たな制約になる．
そしてそれを支えるには，思考のコストを分担するための人間の数が不可欠である．

そしてそれを可能にするのが，

  • 深く思考できる人間の育成
  • 対話を促進する開発文化
  • AI に伝えられる形で思考を表現する力（構造化・形式化）

という「思考と意図」の設計力である．

AI を活用した今後開発の本質は，余白を生み，人間が深く思考する時間を増やすことで提供価値を最大化することであろう．

以上だ( `･ω･)b

GitHubで編集を提案

Discussion