実践！ 自己組織化プロジェクト：自己組織化プロジェクトの育て方（3）（2/4 ページ）

[山根圭輔，アクセンチュア]

実はやりたいことは同じこと？ 〜XPやSCRUMなどアジャイル方法論と自己組織化

XP（エクストリーム・プログラミング）と比較してみる

　アジャイルソフトウェア開発プロセスとして、日本で最も有名なのは「XP （eXtreme Programming）」ではないでしょうか？ あらゆるものを「過激（エクストリーム）に」行うことを信条とするこの開発方法論は、基本的に“4つの価値”と、“19のプラクティス”で構成されています。

□ 4つの価値

コミュニケーション
単純さ
フィードバック
勇気

□ XPの19のプラクティス

・ 共同のプラクティス
　　　 反復
　　　 共通の用語
　　　 オープンな作業空間
　　　 回顧

・ 開発のプラクティス
　　　 テスト主導型の開発
　　　 ペア・プログラミング
　　　 リファクタリング
　　　 集団的な所有権
　　　 継続的インテグレーション
　　　 YAGNI（あなたはそれを将来必要としない）

・ 管理者のプラクティス
　　　 責任の受け入れ
　　　 援護
　　　 四半期ごとの見直し
　　　 ミラー
　　　 持続可能なペース

・ 顧客のプラクティス
　　　 ストーリーの作成
　　　 リリース計画
　　　 受け入れテスト
　　　 頻繁なリリース

　まず、“4つの価値”が、非常に「自己組織化」的であることにお気づきになられたでしょうか？

• コミュニケーション →　粒同士の連携（コミュニケーション）が重要
• 単純さ →　粒同士のインターフェイスがシンプルであること
• フィードバック →　「粒」は周りの「粒」との連携により影響（フィードバック）を受ける

　そして、「勇気」とは、上のように「粒」としてさまざまなものの連携をシンプルにしていくためには、相当な勇気が要る、といったところでしょうか。

　もちろん、より詳細なプラクティスレベルでも、「自己組織化」を目指しているといっても良さそうなものが多数あります。

• 反復 →　1つの大きな固まりでなく、作業を「粒」に分けて反復する
• 共通の用語 →　シンプルなインターフェイスのため
• オープンな作業空間 →　コミュニケーションおよびフィードバックが置きやすい状況へ
• テスト主導型の開発 →　インターフェイスをきちんと押さえて、粒同士のコミュニケーションを保証しやすくする
• ペア・プログラミング →　情報という「粒」の共有
• 集団的な所有権 →　情報という「粒」の共有
• 持続可能なペース →　日々の作業という「粒」を持続可能な状態へ
• 頻繁なリリース →　リリースバージョンの「粒」を増やす

ほかのアジャイルソフトウェア開発ではどうか？

　 ほかのアジャイルソフトウェア開発プロセスとして、「SCRUM （スクラム）」や、「適応型ソフトウェア開発（Adaptive Software Development）」などがあります。

　それぞれの詳細はここでは述べませんが、例えばスクラムであれば、「日次スクラム」という名の、スタートアップミーティングを必ず朝行う、といったところから始まり、要件を「プロジェクト・バックログ」として、「粒」の集まりとして扱うこと、「スプリント」と呼ばれる、30日を1期間とした反復作業の「粒」に分けるといった具合です。

　そもそも、この「SCRUM （スクラム）」や「適応型ソフトウェア開発（Adaptive Software Development）」の中で、「自己組織化」や「カオスの縁」という言葉が頻繁に出てきますので、提唱者は確信的に「プロジェクトの自己組織化」を目指しているといっていいでしょう。

　さて、「有名なアジャイル開発方法論の中で自己組織化の概念が含まれているのであれば、何もわざわざ自己組織化なんて言葉を使わずに、どれか1つアジャイル開発方法論を選んでやればいいんじゃないか？」と思われるかもしれません。

　しかし、これらのアジャイル開発全般の根底に流れる目的、提唱者は何を最終的に目指しているのか？ ということを知ることは、非常に価値があることだと思います。なぜなら、この根底に流れる思想を理解することで、盲目的にXPやスクラムを実施することを目指し、現実とのギャップに挫折するのではなく、「自己組織化（あるいは創発ともいう）」という目的を見失うことなく、臨機応変に現実に合わせて微調整・使いやすいところを組み合わせたりすることが可能になるからです。