CodeZine(コードジン)

特集ページ一覧

第2回 ディシプリンド・アジャイル・デリバリーというお作法

“アジャイル”の次へ:IBMの開発プロセス戦略の今(2)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/03/21 14:00

目次

アジャイル・スケーリング・モデルとDAD

 前述のスケーリング・ファクターに対してどう対処すべきかは、これまで広く知られているアジャイルのプラクティスでは十分なガイドにはなっていないのが現実です。小規模なチームでのアジャイル開発に慣れている技術者にとって、スケーリング・ファクターが意味を持つような規模のプロジェクトへ移行するのは大きなジャンプが必要です。そこで、IBMでは、規模の発展に合わせてアジャイル・チームの振る舞いが変わることを表現するために、アジャイル・スケーリング・モデル(ASM)というものを併せて提唱しています(図2)。

図2 アジャイル・スケーリング・モデル(ASM)
図2 アジャイル・スケーリング・モデル(ASM)

 このモデルの中では、従来の少人数でのアジャイル開発スタイルをコア・アジャイル・デベロップメントと呼んでいます。ここで使われるプラクティスは、現在広く知られているアジャイルのプラクティス群そのものです。それに対して、前述のスケーリング・ファクターを考慮しなければならない規模の開発スタイルのことを、Agility@Scaleと呼んでいます。

 従来のアジャイル・プラクティスは「モノを作る」に焦点をあてています。しかし、スケーリング・ファクターを考慮するような規模になった時点で、意思決定に絡む利害関係者の多さ、技術の複雑さ(裏を返せば、技術的なリスク)が増してきます。これらにうまく対処するためには、1回のスプリント期間中のチームの振る舞いだけではなく、プロジェクトの開始から終了まで考慮した時間軸の中での意思決定ポイントやプロジェクトの運営を明確にした枠組みを用意し、利害関係者も含めた全体で合意しておく必要があります。DADは、この枠組みそのものであり、アジャイル・スケーリング・モデル上は、コア@Scaleの中間に位置付けられています。

 注意が必要なのは、DADは「大規模向けに限定されたアジャイルプロセスではない」ということです。その本質は、プロジェクトの運営という観点で見た枠組みなので、少人数のチームや案件であっても、利害関係者が多い場合には、十分有効なものです。これまで日本国内でアジャイルを試行されたお客様の話をお伺いする機会が何度かありましたが、総じて「ユーザー部門の関わり方」に課題が多いように思います。またスプリント内でのバックログの管理に「場当たり的」という不安を持たれる方も多いようです。「プロジェクトの時間軸に沿った運用の枠組み」は、これらの不安にかなり答えることができると思います。

関連リンク

  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 藤井 智弘(フジイ トモヒロ)

    日本アイビーエム株式会社 ソフトウェア開発研究所 Rationalエマージング・ビジネス・サービス。ソフト開発ってホントはもっとおもしろかったはず!という思いのもとで、”管理管理!”でも”開発者の自由!”でもなく、その程よいバランスこそが解と、啓蒙活動...

バックナンバー

連載:“アジャイル”の次へ:IBMの開発プロセス戦略の今
All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5