AI時代の開発ポリシー：細かいコードにこだわらない

受託開発の現場で25年以上、いろんな「正しさ」を見てきました。
ウォーターフォールが正義だった時代も、アジャイルが救世主に見えた時代も、マイクロサービスが流行って“分割して統治せよ”が合言葉だった時代も。

そして今、IT受託開発はもう一段、はっきりとパラダイムシフトしました。
主役が「人間の手」で書くコードから、「AIが生み出す実装」へ移りつつあります。

EEGでは、この変化を前提に開発ポリシーを更新しました。
結論はシンプルです。

細かいコードにこだわらない。人間は森を見る。実装はAIに任せる。
そして、大規模リファクタリングは“AIがさらに賢くなってから”に寄せる。

今日はその考え方と、現場でどう運用しているかをまとめます。
⸻

こだわる場所が変わっただけ

最初に誤解を防いでおくと、「コード品質なんてどうでもいい」と言いたいわけではありません。
ただ、“こだわりの配分”が変わったという話です。

昔は、優秀なエンジニアほど「細部の美しさ」に価値がありました。
命名、責務分離、抽象化の粒度、例外設計、見通しの良さ。そういう積み上げが、納期と保守性を救ってくれたのも事実です。

でも今は、AIが実装を量産できる。
しかも一定の品質で。しかも速い。

すると何が起きるか。

・人間が“コードの細部”に使う時間の費用対効果が下がる
・代わりに“仕様の曖昧さ”や“目的のズレ”が最大の損失源になる
・コードを美しく磨くより、「何を作るべきか」「どう動けば正解か」を明確にする方が価値が高い

つまり、価値の中心が 木（コード） から 森（プロダクトとシステム） に移りました。
⸻

EEGのAIファースト開発：基本思想

EEGの開発哲学を一言で言うと、こうです。

AIに設計と実装を“委任”し、人間は意思決定に集中する。

ここで大事なのは「丸投げ」ではなく「委任」です。
委任には、任せる側の責任がセットで付いてきます。

人間が握るべきは、主に次の3つです。

1) 目的（Why）

• 何のために作るのか
• 成功の定義は何か（数値でも、状態でも）
• 誰の、どんな痛みを取り除くのか

2) 制約（Constraints）

• 納期、予算、法令、セキュリティ、運用体制
• 使える技術、使ってはいけない技術
• 既存システムやデータ構造との整合

3) 検証（Verification）

• 受け入れ基準（Acceptance Criteria）
• テスト戦略（E2E、統合、ユニットの割合）
• 監視・ログ・アラートの設計（運用で死なないため）

AIが最も苦手なのは、「本当の目的」と「現場の制約」が絡む意思決定です。
ここは人間の領域です。

逆にAIが得意なのは、制約の中での実装、選択肢の提示、繰り返しの作業、リライト、テンプレ化。
ここは遠慮なく任せます。
⸻

「細かいコードにこだわらない」の具体的な意味

EEGで言う「こだわらない」は、怠慢ではなく方針です。具体的にはこういうことです。

こだわらないこと（例）

• 1行1行の“職人芸”みたいな最適化
• 過剰な抽象化（未来の拡張のために現在を複雑にする）
• リファクタリングのためのリファクタリング
• “美しい”クリーンアーキテクチャを完成させること自体が目的化する状態

（余談ですが、インデント論争に人生を吸われた経験がある人は、今こそAIに成仏してもらいましょう。南無。）

こだわること（例）

• 境界（Boundaries）：どこまでが何の責任か
• 契約（Contracts）：API、データ、イベントの仕様
• 受け入れ基準：動けばOKではなく“正しく動く”定義
• 観測性：ログ・メトリクス・トレース
• セキュリティ：認可、入力検証、秘密情報、依存関係
• 運用：障害時に誰がどう復旧するか

コードの美しさより、システムの生存性にこだわる。
これがAI時代の「品質」の中心だと考えています。
⸻

設計も実装もAIに任せるための“人間側の準備”

「AIに任せる」と言うと、魔法の杖みたいに聞こえますが、実際は逆で、人間側が“任せやすい形”を作るほど成果が出ます。

EEGで効くのはこのあたりです。

1) 仕様は“文章”ではなく“判定可能な条件”で書く

• NG：「ユーザーが使いやすいようにする」
• OK：「3ステップ以内で登録完了」「フォームエラーは項目ごとに表示」「1秒以内に次画面へ遷移」など

AIは、曖昧さの中で暴れるときもあります。
なので最初から、正否判定できる仕様に変換して渡します。

2) インターフェースを先に固定する

• APIスキーマ
• DBスキーマ（またはイベントスキーマ）
• エラーハンドリング方針
• 権限モデル

内部実装が多少荒くても、外の契約が安定していればシステムは崩れません。
受託開発は特に、「相手がいる」のでここが生命線です。

3) テストを“成果物の中心”に置く

AIがコードを書き、AIがコードを直し、AIがコードを磨く。
このループを成立させるのは、結局 テスト（と観測性） です。

EEGでは極端に言うと、こういう順番を推奨します。\

1. 受け入れ基準を書く（人間）\
2. テスト方針を決める（人間）\
3. テスト雛形をAIが作る\
4. 実装をAIが作る\
5. 人間は“期待通りか”だけを見る（レビューも設計寄り）
   ⸻

リファクタリングは「しない」のではなく「後ろに寄せる」

これも誤解されやすいので、はっきり言います。

EEGはリファクタリングを否定していません。
ただし、“やる時期”を変えます。

なぜ後ろに寄せるのか？
• AIの性能は上がり続けている（＝将来の改修コストは下がりやすい）
• 現在のリファクタは、未来の仕様変更で無駄になる可能性が高い
• 受託の現場で最も高いコストは「作り直し」より「方向転換」
• “今”磨くより、"動くものを早く出して学ぶ"方が顧客価値が高い

もちろん例外もあります。後ろに寄せると言っても、最低限の整備はやります。

“今すぐやる”リファクタの基準

• セキュリティ事故につながる
• バグが頻発して学習（改善）が進まない
• 変更が怖くて手が止まる（開発速度が落ちる）
• 監視や障害対応ができず運用が破綻する

要するに、事業と運用を守るためのリファクタは前倒し。
美観や理想のためのリファクタは後ろ倒し。

この線引きが、AI時代には効きます。
⸻

「森を見る」って、具体的に何をするのか

人間が集中すべき仕事を、EEGではこんなふうに整理しています。

森を見る仕事（人間の主戦場）

• 課題定義：問題は何で、何を解くのか
• 優先順位：何を削り、何を残すか（これが一番難しい）
• 全体設計：境界・データ・権限・運用
• リスク設計：障害、炎上、法令、セキュリティ、契約
• コミュニケーション：顧客と合意形成、期待値調整
• 価値検証：出したものが正しいか、数字と現場で確認

AIが賢くなるほど、ここがボトルネックになります。
つまり、ここに時間を投資するほど、会社として強くなる。
⸻

受託開発会社がこの波で勝つ方法

AIによって、「実装力」そのものは民主化されます。
だからこそ受託開発会社の価値は、次に移ります。
• 期待値を壊さずに合意形成できる力
• 不確実な状況で仕様を固める力
• 運用と保守まで含めて失敗しない設計力
• トラブル時に守り切る力（体制・判断・責任）

これらは、道具が進化しても簡単にはコピーされません。
むしろAIが普及するほど、差が出ます。
⸻

まとめ：コードより、意思決定に集中する

AI時代の開発ポリシーは、こう言い換えられます。
• AIに作らせる（設計も実装も）
• 人間は決める（目的・制約・検証）
• 磨くのは後でいい（ただし運用と安全を壊すものは今直す）

細部に宿る神様には申し訳ないけれど、今は少しお休みいただいて、
まずは“動く価値”を世の中に出す。
その上で、AIがさらに賢くなった未来に、リファクタリングはもっと安く、もっと速く、もっと安全にできるようになります。

EEGはこの前提で、受託開発のやり方そのものをアップデートし続けます。
森を見て、最短で価値に到達するために。