自ら目的を立てて自律的に行動--アジャイル開発で必要な「自己組織化」の進め方

吉原庄三郎 (ウルシステムズ) 2015年10月05日 07時30分

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

 前回は、アジャイル開発を成功させるためには、開発手法についての正しい理解が欠かせないことを述べた。具体的にはアジャイル開発の目的を把握した上で、それを支える重要な概念である「自己組織化」「タイムボックス」「要件定義の扱い」「振返り(レトロスペクション)」を学ぶ必要がある。今回は「自己組織化」について説明しよう。

 アジャイル開発の本質が「超短期リリース」を繰り返すことはすでに述べた。超短期リリースとは文字通り、数週間程度で動作するソフトウェアをリリースすることを指す。

 アジャイルの超短期リリースを実現するために欠かせないのが「自己組織化」である。自己組織化とは開発チームにマネージャーを置かずに、チームメンバーが自律的にプロジェクトを運営することである。チームメンバーが自ら計画を立て、日々の進捗を共有し、課題を解決する。顧客とのリレーションを維持し、プロジェクトを振り返って改善につなげる。

 多少の言葉の違いはあるものの、どのアジャイル手法も自己組織化を重視している。開発効率を高めるためだ。例えば、何らかの問題が起きた時、マネージャーが報告を受け、関係者を集めてミーティングし、対策を誰かに指示するというのでは時間が掛かる。開発スピードを追及すれば、チームメンバーが自分の頭で考え、行動することが不可欠なのである。

 この「自己組織化」こそが、アジャイル開発が失敗する原因の最たるものだ。基本的にアジャイル開発ではマネージャーを置かない。プラクティスによってはコーチと呼ぶ存在を置くこともあるが、これはあくまでチームメンバーの相談役であって司令塔ではない。チームメンバーは自ら目的を立てて、自律的に進捗を管理することを求めている。

 しかし、言うは易く行うは難し。実際にやってみると、上手く回らないものだ。

 というのも、チームが自律的に振る舞うためには慣れが必要だからだ。多くの開発者はマネージャーの統制の下で規律に従って働くことに慣れている。急に「自律的に振る舞え」と言われても難しいのだ。マネージャーがいなければ、実行可能な計画を作ることもできない。何か課題があっても解決されないまま放置される。非常に効率の悪い進め方が行われることになる。

 こうした状況は、開発チームが成熟するまでは続く。頻繁に問題が発生すると開発チームのモチベーションは下がり、自己組織化からは遠ざかる。悪循環である。これが多くのアジャイル開発プロジェクトが陥る失敗のパターンである。

 では、どうすればよいか。対策は2つある。

 まず、自己組織化されるまでは開発チームにマネージャーを置くこと。マネージャーは開発チームの自己組織化を促進するように運営する。開発チームが成熟して自己組織化されてきたら、役割をマネージャーからコーチに少しずつシフトさせていく。つまり、具体的な指示を出す代わりに助言を与えるのだ。

 場合によっては、アーキテクトもおくべきだろう。有名なアジャイルプラクティスに「YAGNI(You Ain't Gonna Need It)」というものがある。

 YAGNIとは実際に必要になるまで機能を追加しないことを推奨するアジャイルプラクティスである。解釈によってはアーキテクチャ設計のような先行設計は不要であることを意味する。しかし、余程成熟した開発チームでない限りはアーキテクチャ設計があった方がチームメンバーは迷わず開発できるだろう。

 もう1つの対策は、自己組織化するまではリリース期間を長めに取ることだ。具体的には、最初のリリース期間を数カ月程度に設定し、開発チームが成熟してきたところで数週間に縮めるのが良いだろう。自己組織化されていないチームは開発や問題解決の効率が悪い。そうした状態で、数週間のリリースをこなすのは現実的ではない。

アジャイル開発はハイレベルな技術者でないと実践できないか?

 ところで、アジャイル開発はスキルの高いメンバーを揃えないと難しいという指摘がある。これはアジャイル開発が“多能工”を求めるためだろう。

 多能工とは、1人で多くの役割を担う技術者のことだ。仕様の決定から設計、実装、テストまで手掛ける。チームメンバー全員がどんな作業でもこなすことができれば、チームの問題を人任せにすることなく全員で解決しようとする。開発チームを一致団結させて、自己組織化を促すプラクティスである。

 確かに多能工だけで自己組織化された開発チームが編成できれば強力なことには違いない。ただし、現実的にそうしたチームを揃えることは難しいだろう。多能工とは、高いスキルを持ったエース級の技術者にほかならない。

 そうした人材ばかりで10人のチームを組むことができるケースは稀だろう。アジャイル開発を実践する過程で徐々に多能工になっていくというのが現実的。当初から多能工だけで開発チームを編成することにこだわる必要はない。

 なお、技術力と自己組織化は異なる能力であることも強調したい。仮に高いスキルの人員を集めたとしてもチームとして連携するためには成熟が必要である。

 例えば、サッカー日本代表は国内外のエース選手によって構成されているが、それぞれの実力をいかんなく発揮するまでには一定の時間がかかる。チームとしての経験を積んでこそ実力が発揮できる。アジャイル開発におけるチームについても全く同じことが言える。

 アジャイル開発とは知識ではなく、チームの成長である。「Don't just do agile. Be agile.」という言葉がある。アジャイルを行うのではなく、アジャイルになるのである。

 本を読んだからといって明日からアジャイル開発を実践できるわけではない。本に書かれていることを実践するだけでは成功しない。チームを成長させながら「Be agile」に日々近づくのである。成長の過程にあわせて適用するアジャイルプラクティスも選択していかなければならない。

吉原庄三郎(よしはら・しょうざぶろう)
ウルシステムズ 主席コンサルタント、アジャイル推進室
ウルシステムズでITグランドデザイン、プログラムマネジメント、開発運用プロセスデザイン、上流工程のコンサルティングを提供している。
著書に「はじめての設計をやり抜くための本」(翔泳社)がある。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

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

この記事を読んだ方に

関連ホワイトペーパー

連載

CIO
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]