[WIP] 人生

ここは誰かのフロントエンド

エンジニアにはルールではなくプリンシプルを

「2030年のAIとアジャイル」レポートを読んだ。

github.com

(日本ソフトウェア科学会 機械学習工学研究会 AIとアジャイルWG、今井健男・渡辺知恵美著、2026年4月、v1.2)

このレポートでは、AIがソフトウェア開発の在り方を根本から変えていく未来が描かれている。

読み進めるうちに、一つの問いが生まれた。AI時代のアジャイル開発において、チームの行動指針はどうあるべきか。これからの開発チームに必要なのは、細かいルールメイクではなく、行動の指針となる原則——大げさにいえば、チームにおける「憲法」のようなものではないか。

ルールは状況が変われば陳腐化する。しかし原則は、判断の軸として機能し続ける。AI時代の開発スピードにおいては、都度の合意形成よりも、共有された原則に基づく自律的な行動の方が価値を生む。

そこで、一つの仮説として、現時点で自分が考える「AI時代のエンジニアリング原則」を言語化してみた。

AI時代のエンジニアリング原則

AIによる開発プロセスの高速化に伴う、エンジニアの行動指針

背景

AIの劇的な進化により、コードの実装速度は飛躍的に向上しました。その結果、開発におけるボトルネックは「実装」から、チームやステークホルダーとの「合意形成」へと移行しています。

従来のスクラム開発では、実装コストが高かったために、チケットの着手順番や詳細な分割議論に時間をかける合理性がありました。しかし現在は、その前提が崩れつつあります。

本原則は、従来のスクラムをベースにしつつ、現代のスピード感に合わせて「エンジニアの裁量」と「透明性」を再定義したものです。

これらの原則自体はAI以前から有効なものですが、AIによる実装速度の向上がチームの判断頻度と自律性の要求を一気に引き上げた今、明文化する緊急性が増しています。変化した開発前提のもとで、エンジニアが自律的に動き、価値を最大化するための行動を定義します。

スプリントプランニングの役割

標準的なスクラムにおける「詳細なタスクの見積もりや分割」の時間を削り、プランニングでは以下の合意のみに集中します。

  • チケットの大まかな優先順位の確認
  • 今週、チームとして最も注力すべきテーマの特定

具体的なチケットの着手順、タスクの分割、詳細な進め方は、各エンジニアの裁量に一任します。


1. 憲章(必須ルール)

以下は、チームの規律として例外なく遵守すべき事項です。違反がある場合は即座に正式な是正対象となります。

1-1. ミッション達成を最優先する

チーム、および事業全体の成果を第一に考えます。優先すべき事項は、事業フェーズや市場環境によって刻々と変化します。常に「今、何が最も重要か」の 確認を怠らないでください。

1-2. チケットに記載のないタスクは存在しない

すべての作業はチケットとして可視化します。チケットに記録されていない作業は、チームにとって「存在しないもの」として扱われます。

1-3. 承認フローを遵守する

組織としてのガバナンス維持、内部統制、および品質担保のため、定められた承認フロー(レビューやマージ権限など)の省略は認められません。


2. 行動原則(推奨)

以下は、チームが推奨する行動指針です。状況に応じた判断を尊重しますが、逸脱する場合は論理的な理由を説明できる状態にしてください。

2-1. 自律的にタスクを組み立てる

プランニングで合意した優先順位に基づき、具体的な実行プラン(着手順・分割・手法)はエンジニア自身が最適だと思う形に構築してください。

2-2. 方向性に沿うなら、柔軟にタスクを組み替える

開発過程で生まれた新しいアイデアがチームの方向性と合致するなら、柔軟にタスクの追加や入れ替えを行って構いません。ただし、組み替え時は朝会などで理由を共有し、認識のズレがないか確認してください。影響が大きい場合は、事前の相談を推奨します。

2-3. 透明性は「日次」で担保する

高い裁量を持つ代わりに、日次のスタンドアップ(朝会)で進捗と判断をオープンにします。タスクの組み替え理由などを一言添えることで、余計な報告フローを増やさずに透明性を確保します。

2-4. 迷ったら、早めに相談する

自律性は「孤立」ではありません。判断に迷う場合や、広範囲に影響が及ぶ場合は、迅速に周囲へ相談してください。「相談しすぎ」によるコストよりも、「相談不足」によるリスクの方が遥かに大きいと考えます。

2-5. 同時並行タスクは集中を妨げない範囲に絞る

コンテキストスイッチによる生産性・品質の低下を防ぐため、1人が同時に進行するタスク(WIP)の上限は5個を目安とします。

運用メモ: この数値は運用状況に応じて適宜調整します。

2-6. 「受け手」が理解するまでバックログリファインメントをやりきる

バックログリファインメントは単なる儀式ではなく、開発フローにおける重要な工程です。現時点ではコードレビューに人間の判断が不可欠であり、レビュアーが仕様を理解していなければレビューは停滞します。この前提はAIの進化により変わりうるものの、「受け手が理解できる状態にする」という原則自体は変わりません。

レビューの遅延や手戻りの多くは、担当エンジニアによる周囲への情報共有不足に起因します。他メンバーの理解度に合わせ、自律的に情報を発信してください。円滑なデリバリーを実現することは、チケット担当者の責任です。


裁量拡大と意思決定の一元性

エンジニアの裁量を広げることは、プロダクトの方向性を分散させるリスクと隣り合わせでもある。

「何を作るか」以上に「何を作らないか」の判断こそがプロダクトの価値を決める以上、裁量の拡大は「何を作るか」の最終意思決定者が明確であることを前提としている。

本原則における憲章1-1(ミッション達成の最優先)は、その意思決定者が示す方向に全員が整列するための基盤である。


おわりに

自分は常々、ビジネスとエンジニアは対等でありたいと考えている。対等であるためには、自由と、それに伴う責任が必要だ。

AIによって個人ができることが飛躍的に増えた今、エンジニアはこれまで以上に自律的に動ける。そのメリットを最大化するには、個人の裁量を広げつつ、チームとしての一貫性、透明性をどう保つかがポイントになる。

本稿で示した原則は、その両立を目指したものだ。細かいプロセスで縛るのではなく、共通の原則のもとで各自が最善を判断する。そういうチームの形を、これからも模索していきたい。