はじめに
『日本企業はアジャイルに向いていない組織体制である。』
こう思われた結果、ビジネスシーンの変化が多い現代にも関わらずアジャイル開発を諦めた現場も多いのではないでしょうか。
確かに、日本の伝統的な組織体制・企業文化とアジャイル開発の理念は、一見すると相容れないように見えます。しかし、グローバル競争の激化とデジタル変革の波の中で、多くの日本企業がこの難題に挑戦しています。
今回紹介する『誰も教えてくれなかったアジャイル開発』では、中央集権型の組織構造を持つ日本企業において、アジャイル開発を成功させるための秘訣と実践的な手法が知るされています。
本記事ではいくつか手法をピックアップして紹介していきます。
アジャイル開発が適している組織文化
- フラットな組織構造：
- 意思決定が速い
- オープンなコミュニケーション：
- 情報共有が活発
- 柔軟性と適応力：
- 急速な変化に対応できる
- 自律的なチーム：
- メンバーが自主的に意思決定できる
- 顧客中心主義：
- 顧客ニーズを最優先する
- 継続的な改善：
- 常にプロセスを見直し最適化する
- 失敗を恐れない文化：
- 試行錯誤を奨励する
アジャイル開発が適している組織事例
- Spotify社が有名
- 「Spotify Model」と呼ばれる独自のアジャイル組織構造を採用している
- 小規模で自律的なチーム（Squad）を基本単位とし、複数のSquadが機能横断的なTribeを形成します
- この構造により、柔軟性と迅速な意思決定を実現している
中央集権型の日本企業におけるアジャイル開発
中央集権型の日本企業でアジャイル開発が難しいとされる主な理由として以下が挙げられます。
- 意思決定の遅さ：階層的な承認プロセスが迅速な対応を妨げる
- リスク回避傾向：失敗を恐れる文化が実験的なアプローチを制限
- 部門間の壁：縦割り組織が横断的な協力を困難にする
- 詳細な計画重視：長期的で詳細な計画立案がアジャイルの柔軟性と矛盾
- 上意下達の文化：現場の自律性やイニシアチブが制限される
ではどのように日本企業のアジャイル開発の利点を取り入れれば良いのでしょうか？
アジャイルでも「計画」を重視して開発を進めること
前提としてプロジェクトの準備段階の最大のイベントは「計画」の立案があるかと思います。
しかしながら、よくある誤解として以下が挙げられます。
- 『アジャイル開発は仕様変更を受け入れるのが前提だから計画は作成しないし、計画をアジャイルで行うことに意味はないのでは？』
確かに、アジャイルでは目的達成のための最適案を都度検討して、実装検証する短いサイクルを繰り返していくことで方向転換が容易であることが特徴として挙げられる。
ただ、それはアジャイル開発で慣れている組織で可能な手法であり、計画なしにプロジェクトを進めるのは日本企業では向いていないとされている
アジャイル開発を理解してもらうことの難しさ
アジャイル開発の経験が少ない中央集権型の企業においては、プロジェクト計画段階でステークホルダーはプロジェクト側に綿密な計画と完成予想図を求める。
そういう組織で『アジャイル開発の進め方』の理解を得るのは難しい
どうやって理解を得るのか
- やはり 『計画』を立てること が中央集権型の組織でアジャイル開発を成功させる鍵となる
『計画』は重要なコミュニケーションの道具
仕様変更を前提としたアジャイル開発においても、以下の3点についてはステークホルダーの理解と合意を得ることが重要となる
- プロジェクトの目的と最終目標
- スケジュール（おおよそのロードマップ）
- 予算（概算）
全てを詳細まで計画する必要はないものの、ウォーターフォール型と同様に計画を立てることで、アジャイル導入のハードルを下げることができる
ただし、詳細な見通しを立てるのは開始から2~3ヶ月分で良いとしている。
上記の計画はプロジェクト関係者全員にとっての重要な「コミュニケーションツール」となる
余計なコストだと感じる反面メリットもある
- スケジュールをプロジェクト関係者で考え共有することで、気づかなかった課題やリスクを発見できる
- 上層部の人物や関連部署のメンバーにとって馴染み深いので、プロジェクトの進捗を説明しやすい
アジャイル開発でスケジュールを立てることはウォーターフォールの予定表以上の効果を期待できる
スクラムではなくともアジャイルできる
プロジェクトを進めやすくするように以下のロールをプロジェクトに立てることも推奨している
- POの代理である代理PO(POO)を立てる
- SM(スクラムマスター)の役割の一部を移譲した開発リーダーを立てることも検討すると良い
成長のための『生産性低下』を許容できるか？
中央集権型の組織でアジャイル開発を進めるに当たって、立ち上げ段階で考慮すべきポイントが
- チームを成長させるために生産性低下を織り込んでおく
こと
アジャイルチームを成熟させるためには 「自律型+多能工」 のメンバーでチームを構成する必要がある。具体的には
- 自ら考え、要件定義から開発・運用まで一貫して担当することができるメンバーでチームを構成すること
しかし上記を達成するためにメンバーの育成に力を入れる場合に、一時的な生産性の低下を許容する必要がある。
それができない場合は、「開発メンバーの専門領域に特化したタスクのみを割り当てることで安定したパフォーマンス」を発揮させる方法をとる。
ユーザーストーリーだけに頼るな
要件定義に使うドキュメントにも注意が必要
アジャイル開発における要件定義表は以下の要素で構成されている
- 役割(誰が)
- 要望(何をしたい)
- 理由(何のために)
この要素が中央集権的な組織においては要件定義で抜け落ちる恐れがある。
理由は以下の通り
- ユーザーストーリーの質そのものの質が低い
- エンドユーザーは欲しい機能が具体的に決まっていたり、既存の機能に目が入ってしまっていてユーザーストーリーの内容を細かく設定しがち
- そこからなぜ要件が抜け落ちるのかというと、エンドユーザーのユーザーストーリーそのものの質が低いのにも関わらず要件が具体的であるため、開発のフェーズにおいて質の悪い具体的なユーザーストーリーをそのまま実装してしまうことがあるから
上記の問題は全て、ステークホルダーであるエンドユーザーの目的や要件がプロジェクト側に伝わっていないことが原因
エンドユーザーの要望がもれなくユーザーストーリーに反映されない限りアジャイル開発は成功しない
エンドユーザーから「十分な情報」を聞き出すためには？
- ユーザーストーリーそのものの品質を向上させる
- ユーザーストーリーを業務プロセスやカスタマージャーニーで並べる「ユーザー・ストーリー・マッピング」を使って抜け漏れを確認する
- 場合によってはウォーターフォール開発で作成する資料を要件定義で作成することも検討する
終わりに
中央集権型の日本企業でアジャイル開発を成功させるには、従来の強みを活かしつつ、新しい方法論を柔軟に取り入れる姿勢が重要です。本記事で紹介した方法は、日本企業の文化に配慮しながらアジャイルの利点を取り入れる実践的なアプローチです。
本記事を読んだエンジニアが紹介した手法を用いて、少しでも日本組織の特性を活かし、段階的にアジャイル開発の導入を進めることで、日本企業ならではのアジャイルスタイルを確立してDXの波を推し進めていけたら幸いです。