アジャイル開発をうまく進めるために

この記事は夏のリレー連載2024 6日目の記事です。

こんにちは、庄司です。

この記事では Four Keys にあるデプロイの頻度を中心にアジャイル開発がどうすればうまく進められるかを検討します。

アジャイル開発がうまく進んでいるかを知る指標に、デプロイの頻度、変更のリードタイム、変更失敗率、デプロイ失敗時の復元までの時間を使用する「Four Keys」がよく知られています。

「LeanとDevOpsの科学」にあるように、2009年頃までは、開発側 (Dev) と運用側 (Ops) とで責任が完全に分離され「混乱の壁」があったと言われています。DevOps ムーブメントが2009年頃に始まったのは、アジャイル開発が主流になるにつれ、デプロイ頻度を増やす圧力の高まりで Dev と Ops の摩擦が高まったことが背景です。

アジャイル開発で中心となるチームは「チームトポロジー」で紹介されるところでは「ストリームアラインドチーム (Stream aligned team)」と呼ばれます。このチームがフィードバックや変更の要求に迅速に対処して、Four Keys を高いレベルに維持することが求められます。

開発プロセスとしてのアジャイル開発は、今でも計画駆動開発とよく比較されて議論となります。しかし筆者の目からすると、計画駆動開発が前提としている職能上の枠に縛られたハンドオフに問題があるのであって、そこにいる各職能をもつ人々が、同じストリームアラインドチームの中で一体となってフィードバックや変更の要求に迅速に対処できるよう、ハンドオフを無くせば、このような議論は不要だという認識です。

「知っておきたいプラットフォームエンジニアリングのホットなトピック」に近年の認知負荷の高まりを表すグラフが掲載されています。

2009年頃に始まった DevOps ムーブメントで開発と運用が同じストリームアラインドチームとなり Four Keys の向上に寄与してきましたが、時間の経過ともに、フロントエンドやバックエンド技術の進化、コンテナ技術の進化、クラウドの台頭、さらに急速な進化をみせる生成 AI 等に伴う認知負荷の高まりから、ストリームアラインドチームのキャパシティを超えてしまい、新しい職能の枠が誕生し、新しい形態の分業が起こっているように感じています。

アジャイル開発の主役はこれからも「ストリームアラインドチーム」であるでしょう。とすれば、ストリームアラインドチームは継続的に学ぶ組織であるとともに、キャパシティを超えて増大する認知負荷への対処を「チームトポロジー」を参考に他のチームとのコミュニケーションパスを活用しながら、ハンドオフによるオーバーヘッドの無いまたは最小化を目指し、とりわけ新しい職能の枠の誕生には注意を払うようにマネジメントしながら組織設計を継続的に行うことが、アジャイル開発をうまく進めることにつながると筆者は考えています。