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

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

安易なプロジェクト化のリスク

この前同僚とプロジェクトって言葉があまり好きじゃないね、みたいな会話をしており、自分的になぜそう思うのか考えてみる。

コンテキストとしては、主に事業会社におけるソフトウェア開発を前提にする。

一般的に事業会社では、ユーザーに価値を届け続けるために、日々多くの機能開発や改善を行っている。その中で、特定の目的を達成するためにチームが組成されることは珍しくない。

しかし、その集まりを安易に「プロジェクト」と呼ぶことには、いくつかの構造的な課題が潜んでいると考えている。


「プロジェクト」という言葉が内包する課題


そもそも「プロジェクト」とは何を指すのであろうか。プロジェクトマネジメントの知識体系であるPMBOKでは、以下のように定義されている。

独自のプロダクト、サービス、または所産を創造するために実施される、有期性の業務

この有期性という性質こそが、最も懸念している点である。期間が定められているからこそ、いくつかの根深い問題を引き起こす傾向がある。


1. 長期的なオーナーシップの欠如

「プロジェクト」という名前がついた活動は、その定義上、始まりと終わりが存在する。メンバーは特定の目的のために期間限定で集められ、目的を達成すれば解散することが前提となる。

この構造は、メンバーの意識を「リリースまで」に限定させてしまうリスクを伴う。もし、ある機能が無事にリリースされ、プロジェクトが役割を終えて解散することが決まっている場合、そのプロダクトの将来的なメンテナンス性や運用負荷、ユーザーからのフィードバックを受けて改善し続けるといった、長期的な視点で物事を考えるインセンティブは働きにくくなる。

結果として、「作ること」自体が目的化し、リリース後のプロダクトの価値を最大化し続けるという、事業会社にとって最も重要な活動への接続が断絶されがちである。プロダクトに対する継続的なオーナーシップが育まれにくい環境は、長期的に見てプロダクトの健全な成長を阻害する要因となり得る。


2. スコープの肥大化とリードタイムの増大

「プロジェクト」として期間や体制を先に定義してしまうと、その期間内におけるメンバーの稼働率を最大化しようという力学が自然と発生する。

「せっかくこの期間、このメンバーを確保したのだから」という思考は、本来の目的達成に必要不可欠ではない機能の追加や、優先度が相対的に低い要件の盛り込み、いわゆるスコープの肥大化を招きやすい。

当初は最小限の価値(Minimum Viable Product)を迅速にユーザーへ届ける計画だったはずが、プロジェクトという枠組みの中で、いつの間にか「すべてを完璧に作り切ること」が目的となり、結果としてリリースまでのリードタイムを不必要に長期化させてしまう。

これは、スコープやビジョン、優先順位が固定化され、市場やユーザーの変化に柔軟に対応しにくいという、ウォーターフォール的な開発モデルの課題にも通じる。


3. 優先順位の形骸化

スコープの肥大化と密接に関連するのが、優先順位付けの先送りである。プロジェクトという大きな枠組みの中では、本来厳密に行われるべき個々の機能に対する優先順位の議論が曖昧なまま、開発が進行してしまうリスクがある。

例えば、AとBという2つの機能を作る計画があったとする。計画当初は、両方とも「優先度:高」と定義されていたかもしれない。しかし、もし開発終盤になって「どちらか一つしかリリースできない」という状況に追い込まれた時、そこで初めて「本当に価値が高いのはどちらか?」という真の優先順位が問われることになる。

これは、「プロジェクト期間内にすべて作る」という前提が、本来向き合うべき価値の議論を覆い隠してしまう典型的なケースである。長期的なスケジュールと確保されたリソースが、真の優先順位を見極める機会を奪い、結果的に価値の低い機能の開発にリソースを割いてしまう事態を招く。


「プロジェクト」が有効なケース

もちろん、「プロジェクト」という進め方を完全に否定しているわけではない。明確なゴールと期限が定められた、リリースそのものが目的となる場合には、非常に有効なアプローチである。

例えば、クライアントから依頼を受けてシステムを開発する受託開発の文脈では、納品することに責任を持つ。納品後の運用責任とは明確に切り離されているため、短期集中でリソースを投下し、計画通りに完遂させる「プロジェクト」型の進行は理にかなっている。


目指すべき姿

では、我々はどうあるべきだろう。

それは、短期的な成果を目的とする「プロジェクト」の集まりではなく、プロダクトや特定のドメインに対して継続的に責任を持つ「チーム」として存在することだと考える。

チームは、リリースをゴールではなく、ユーザーに価値を届けるためのスタートラインと捉える。自らが開発した機能のパフォーマンスを監視し、ユーザーの声に耳を傾け、得られた学びをもとに次の改善サイクルを回していく。この継続的なプロセスこそが、プロダクトを真に成長させると考える。

このようなチームは、期間で区切られるのではなく、プロダクトのライフサイクルと共に存在し続ける。それにより、メンバー一人ひとりがプロダクトの成功に長期的なオーナーシップを持ち、自律的に価値創造に取り組む文化が育まれていく。

また上述したスコープの肥大化&長期化に関して、常に注意する必要がある。プロジェクトと銘打つことで、多くのスコープ、期間の長期化、優先順位の形骸化が許容されてしまう構造に注目し、安易にプロジェクト化させない工夫が必要である。

そのためには、スプリントプランニングをはじめとした様々なフレームワークを取り入れるのも良いだろう。


さいごに

「プロジェクト」という言葉には、ビジネス上、関係者に計画を説明しやすく、進捗を評価しやすいというメリットがあることも事実である。第三者から見ても、機能がリリースされたかどうかは明確に判断できる客観的な指標である。
しかし、その「分かりやすさ」の裏で、プロダクトの本質的な価値向上を妨げる構造が生まれていないか、常に自問する必要がある。


単発の花火を打ち上げる「プロジェクト」ではなく、プロダクトと共に成長し続ける息の長い「チーム」でありたいものですね

湘.なんかで人生初の社外LTをしてきた

タイトルそのままなんですが、先日開催された湘.なんか#2でLTをしてきました。

 

shonanpm.connpass.com

 

資料はここに上げました。

 

speakerdeck.com

 

内容は会社のブログに書いたことのサマリーで取り立てて新しいトピックでは無いのですが、内容は同じでも、5分の枠の中でどう話すとよいか?を考えたり、ブログとはまた違った伝え方の練習が必要だなと感じました。

 

zenn.dev

 

エンジニアコミュニティやイベントはこれまでは聴く側で参加していたのですが、やっぱり何か自分の考えていることとか、伝えたいことを話す、それによって何か議論したり、話すきっかけが生まれたりするのは楽しいなと思いました。

 

感想

今回自分の目標は、自分のやってみたいという気持ちから逃げないだったので参加してきちんと発表出来ただけで、満足です(我ながらハードルが低い)

 

初めての登壇にもおすすめの場所なので、皆さんも参加してみてはいかがでしょうか!

 

shonanpm.connpass.com

 

「さくらのドメイン」で取得したドメインを、はてなブログの独自ドメインに設定する

思い立って、ブログを再開してみる。

最初は独自ドメインの設定の記事から。とは言ってもヘルプページに書かれていたことそのままである。

help.hatenablog.com

手順は3つのみ。

  1. ドメインを取得する
  2. Aレコードの設定
  3. はてなブログに設定する

1. ドメインを取得する

何はともあれ、ドメインを取得する。今回は初めて「さくらのドメイン」でドメインを取得してみる。

domain.sakura.ad.jp

本論と関係ないけど、最近さくらインターネットさんは採用を頑張っていて、勢いがあるイメージがある。ガバメントクラウド とか頑張ってほしい。

findy-code.io

今回はこのブログで利用する sh0g0.com を取得した。

2. Aレコードの設定

最初に取得した段階だと、ドメインの ゾーン設定(各種レコード情報などの設定)ができていない。ので、ドメインコントロールパネルから、ゾーン設定をする。

help.sakura.ad.jp

いろんな設定方式があるが、自分はどんな設定になっているか気になったので以下の詳細設定を選択。

help.sakura.ad.jp

最初の設定だと、NSレコードのみ設定されていたので、ここにAレコードを追加する必要がある。

追加する値ははてなブログのヘルプページに書いてあった。

help.hatenablog.com

自分はサブドメイン方式ではなくネイキッドドメイン(wwwなどのホスト名がつかないドメイン)が好きなので、そちらの方を参照した。

ドメインコントロールパネルで以下のように設定すればOK

ちなみに、一応サブドメイン方式も試してみて、以下のように設定するとたしかに正しく表示できた。簡単すぎてびっくりである

3. はてなブログに設定する

最後に、はてなブログ側に上記のドメインを設定しておしまいだ。

最初はドメインの設定チェックでエラーになったが、約1時間くらいで正常に疎通できるようになった。

おわりに

何気にブログサービスに独自ドメイン設定をするのは初めてだったので、楽しかった。各種レコード設定とかなんとなくの理解だったので、もっとちゃんと調べよう