アジャイル バウンダリー
アジャイル バウンダリー（アジャイルの境界）をご存知でしょうか？私の監訳書『More Effective Agile』（スティーブ・マコネル 著、日経BP）で紹介されている概念です。
アジャイルになる、実践するにあたって、アジャイルや経験主義ができるところと、そうではないところがあるだろうとの想定のもと、その境界を明示することで、アジャイルの境界内と境界外でのコミュニケーション、コラボレーション、用語の取り扱いなどを工夫しましょうというようなものです。
すべてをアジャイルの考え方（アジャイル マインド）で推進できればもちろんよいのですが、規制産業を中心として、事前の要件定義や取り決め、ドキュメントの整備、組織体制が必要となるものもあるのは事実です。だからといってアジャイルのメリット（複雑な領域での取り組み、変化に適応する）を失っていいわけでもありません。それでは成功につながらないからです。したがって、アジャイル バウンダリーを意識することはある程度は避けて通れません。
アジャイル バウンダリーの鉄則
境界線をどこに引くべきかという指針（鉄則）があります。それは以下のようになります。
- アジャイルチーム内に境界線を引いてはならない
- 境界線は、ステークホルダーに対して引くものである
- 境界線の数は必要最小限にとどめるべきである
- 既存の組織構造、プロセスを一旦忘れて考えるべきである
他の鉄則としては何が思いつきますか？ぜひ現場で話し合ってみてください。
鉄則: アジャイルチーム内に境界線を引いてはならない
アジャイルチームは、「ビジネス価値を提供し続けるチーム」であるとするならば、そのチーム内に境界線があることは望ましくありません。
例えば、スクラムであれば、スクラムチーム内に境界線を引いてはいけません。プロダクトオーナー、開発者、スクラムマスターの間に境界線は不要です。アジャイルチームの中にアジャイルとそうでないものとの境界があるのであれば、それはもはやアジャイルではないでしょう。
QAや、ビジネスアナリスト、UXデザイナーなども境界線の中にいるべきであり、境界線を引くべきではありません。これらはスクラムチームにいるべきです。ビジネス価値を提供するメンバーは、境界の中にいるべきです。
フロントエンドチーム、バックエンドチームなどレイヤーや技術スタックでチームを分けるといった境界も好ましくありません。単独で価値を提供できない構図になりがちだからです。同じく、ディスカバリーチームとデリバリーチームなど境界も好ましくありません。
鉄則: ステークホルダーに対して境界線を引く
境界線は、ステークホルダーに対して引くことになることが大半です。ステークホルダーは非常に広範囲ですので、アジャイルな考え方ができるステークホルダーと、従来の考え方から変えることができない・許されないステークホルダーがでてくることは想定できます。
主なステークホルダーとしては以下が挙げられます。
- エンドユーザー
- 顧客（スポンサー、依頼者）
- 組織のマネージャー（ラインマネージャー、リソースマネージャー）
- 規制の監督者・監査人
これらの中には、アジャイルへの理解度、既存のしがらみなどがありますので、それは十分に考慮（配慮）する必要がでてきます。もちろん、アジャイルへの理解を働きかけることは大切であり、それを諦めるべきではありません。しかしながら、規制産業では特に事前の取り決めなどで避けては通れないこともあります。
したがって、これらのステークホルダーに対して境界線を考えることと、用語やコミュニケーション・コラボレーションの仕方が変わってくることをアジャイルチームは理解しておく必要があるのです。
鉄則: 境界線の数は必要最小限
細かく分析していくと境界線の数が増えていく傾向があります。しかしながら、境界線が増えれば増えるだけコミュニケーションやコラボレーションのコストが増大化していく傾向があることは抑えておくべきです。複雑さが単純に増えていくため、あまりにも多い境界線は作りべきではありません。理想は境界線は一つ、規制産業などで難しい場合でも2つ以内にとどめておきたいところです。
鉄則: 既存の組織構造やプロセスを忘れる
今までアジャイルでない取り組みをしている場合は、アジャイルとそれらの境界線を引こうとすると境界だらけになります。例えば、工程（フェーズ）をわけた開発を行っていた組織があったとして、その前提で境界線を考えると工程（フェーズ）ごとに境界線ができてしまいかねません。境界線は、価値をうむ流れを妨げるべきではないため、既存の組織構造やプロセスは一旦忘れて考えてみるとよいでしょう。
人ではなく、プロセスや、成果物で境界がある場合も
先述では、人や役割での境界線について触れましたが、これはプロセスや成果物での境界線である場合もあります。ここでのプロセスとは価値をうむためのプロセスではなく、関係者が価値を理解する深さや粒度に対する理解のプロセスや成果物を指します。
例えば、事前の要件定義が不可欠な規制産業であった場合は、規制で定められた大枠での定義が義務付けられている場合でも、実装の方法までは事前に定めなくてもよいものもあります。また、実装の詳細について事前に定めなければならない規格準拠もあるけれども、それ以外の柔軟に対応できる部分もあるかもしれません。これらが境界の対象となる場合もあります。
境界線を「完成の定義」でフォローする
境界線に対しては用語の使い方やコミュニケーションとコラボレーションが主で対応していくことになりますが、特に規制産業など取り決めへの準拠が求められる場合は、「完成の定義」に明記し、共通認識を持ち対応するという方法はとれるはずです（その他の方法でももちろん対応することを考えるべきです）。
例えば以下のようなものが完成の定義に入ってくるかもしれません。
- 機能仕様についてのドキュメントを記載したか
- 監査を受けたか
- 実機での実証を行ったか
- トレーサビリティの記録を行ったか
これらは、DoD マトリックスでタスクにしておくと忘れずに実施できるのでおすすめでもあります。
終わりに
アジャイルを実践するにあたり、残念ながら、すべての関係者や成果物がアジャイルに進められない現実もあります。アジャイルへの理解を深めてもらいアジャイルなやり方ができるように努力はしつつも、現実解として、うまく折り合いをつける部分ではそれを行うことも検討する必要があるでしょう。そんなときの考え方の一つをご紹介しました。
エビデンスベースドマネジメント
ただし、「組織内の予算の取り方や意思決定が従来型だからアジャイルが実践できない」という価値に関係のないところでアジャイルの境界ができてしまうことは、できるだけ避けたいところです。この問題は、予算や意思決定も経験主義でなければいけないのに、従来のままであり、それでもアジャイルにやらなければならないという矛盾からうまれてきています。そういった場合は、経験主義に基づいて意思決定や戦略設定である「エビデンスベースドマネジメント」が有効です。
本記事の執筆者:
長沢 智治 - アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
