SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

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

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

 前回は、「RUPはどこに消えたのか?」という(少々あざとい^^;)タイトルのもと、RUPをめぐるここ数年の動きを概観してきました。「あれ? アジャイルがないじゃん?」と思った方もいらっしゃることでしょう。なにせ連載タイトルにはアジャイルってありますからね……ということで、今回はアジャイルのお話です。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 ここ数年、IBM Rationalチームは、グローバルで"Agility@Scale("アジリティー・アット・スケール"と読みます)"というメッセージの下、アジャイル・ソリューションをアピールしてきました。その動きの中で昨年から、ディシプリンド・アジャイル・デリバリー(以降、DAD)という名のアジャイル・プロセスを構築しました。DADについては、「DAD入門」というホワイトペーパーを配布していますが(※配布終了しました)、この稿では日本でのアジャイル事情も加味して、DADの位置づけとその意味をご紹介したいと思います。

そもそも大規模に適用するとはどういうことか?
――アジャイル・スケーリング・ファクターという考え方

 「アジャイルと大規模」をテーマにした論考、セミナー、パネルディスカッションが一時期よくみられました(ちなみに、うちもやりましたが(・_;))。これらをみてみると、論者の立ち位置には以下の3つのパターンがあるように思います。

  • 立ち位置1:大企業に少人数のアジャイルチームをたくさん増やす

    →これを「大規模に展開する」と呼ぶ流派

  • 立ち位置2:大規模(=大人数)プロジェクトに小規模チームで培われたプラクティスが適用できるか

    →大人数で実施できるか? あるいは大人数で実施するためにどうするか? を論じる流派

  • 立ち位置3:大規模(=大人数)プロジェクトを、少人数のアジャイルチームの集合体として編成して運営できるか?

    →多くのチームをどうまとめるか? 多くの利害関係者とどうコラボレーションするか? を論じる流派

 これらが整理されずに、会話が微妙にかみ合っていないパネルディスカッションを見たことも少なくありません。

 さて、これら3パターンに共通するのは、いずれも「作る技術としてのアジャイル・プラクティス」と「規模」との関係性に注目している点です。これに対して、IBMでは「プロジェクトとして成立させるためのファクター」に着目します。それらのファクターを具体的に表したモノが、図1です(これらをアジャイル・スケーリング・ファクターと呼んでいます)。いくつか例を挙げてみましょう。

図1 アジャイル・スケーリング・ファクター
図1 アジャイル・スケーリング・ファクター
  • 大人数で開発する際には、オフショアに代表される地理的に分散した体制が一般的になっている。国によって労働条件に対する法的規定、文化的慣習が異なり、プロジェクトとして成立するにはこれらの違いを考慮した体制構築が必要となる。
  • 構築対象となるシステムが、業界団体あるいは監督官庁によって定められた規定・法令の制約を受けることがある。これらを遵守するため、プロジェクトでの情報管理のあり方が影響を受ける場合がある(俗に言うコンプライアンス・ケース)。

等々。

 あえて開発技術以外の項目を選んでみましたが、これらは開発の効率化その手段としてのアジャイル・プラクティス云々とは別次元の話です。しかし、開発プロジェクトをプロジェクトとして成立させるためには必須の条件です。もちろん、あらゆるケースで図1で提示されているスケーリング・ファクターすべてが関係してくるわけではありません。しかし、なにを考慮すべきか否かを見極めることは必要です。

 これまで少人数のアジャイル開発に慣れている開発者も、いきなり上で挙げたようなファクターを考慮してプロジェクトを編成する立場になったら、戸惑うのではないでしょうか? 「それは、アジャイルチームの仕事ではなく、プロジェクトマネージャの仕事でしょ?」という声が聞こえてきそうです。もしそういう声が多いようなら、それは「アジャイル・プラクティスと規模」の話だけでは、大規模アジャイルをプロジェクトとして運営することができないということなのでしょう。

関連リンク

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

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
“アジャイル”の次へ:IBMの開発プロセス戦略の今連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6474 2013/04/10 18:07

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング