昨今、アジャイル開発やDXの浸透により、ビジネス部門が、社内あるいは外部の開発チームに直接、システム開発を依頼するケースが増えてきました。
しかし、どんなに優れた開発手法を採用しても、ビジネス部門と開発チームの間では認識のズレが起きます。これは双方が「自分たちの目指す成果」としているものが異なっており、そのすり合わせや変換がうまくいかないことが原因です。
それを防ぐためにはビジネス部門側が、事前に「どのようなコミュニケーションをしたいか」を提示した方が効率的です。
そこで、開発手法に関係なく、ビジネス部門と開発チームのコミュニケーションをスムーズにするために整理した「バインドの5原則」を紹介します。
「バインド（bind）」は「結びつける」という意味の英語です。ラグビーでは、スクラムの際に選手同士がしっかりと腕を組み、体を密着させてつながる動作をバインドと呼びます。これによりスクラム全体が安定し、前に力強く押し出すことが可能になります。
同様に、ビジネス部門と開発チームが、一体となって前に進むための取り組みであることから「バインドの5原則」と名づけてみました。
なお、この原則は、以下のような状況を想定しています：
- ビジネス部門が社内外の開発チームへの直接依頼（SIer、子会社、業務委託など含む）
- 開発期間が3〜6ヶ月程度の中規模プロジェクト、もしくは1チーム体制での継続的な開発・保守
- 開発チームはウォーターフォールでもアジャイルでもよい
バインドの5原則
5つの原則は「ビジネス部門がやること」が先にあり、それを受けてに開発チームがやること」が書かれています。
これはビジネス部門が、開発チームに「このように物事を理解したい」という枠組みを提示する必要があるからです。そして、開発チームは、その枠組みを軸に、自分たちの作業を紐つけて管理し、枠組みに従ってビジネス部門とのコミュニケーションを行います。こうすることで双方のコミュニケーションが効率的になり、ズレも発生しにくくなります。
まずは5つの原則の概要を紹介し、それぞれの原則ごとに深掘りしていきます。
① ビジネス視点のマイルストーンを設定する
ビジネス部門は、今後の予定を「ビジネスにとって意味があるタイミング（ユーザーや事業への意味のある変化）」をマイルストーンとして設定する。開発チームは、常にそこを意識しながらスケジュールを管理する
② シナリオベースの課題リストを作る
ビジネス部門は、「何が課題なのか？／それに対して何をしたいのか？」というシナリオベースで課題リストを準備する。開発チームは、好きな方法でタスクを管理するが、このリストに紐つけておき、進捗・状況は、シナリオ単位で報告する。スコープの調整はシナリオ単位ではなく、シナリオの中の厚みで考える
③ 週単位で計画し、判断する
ビジネス部門は、週単位で開発の計画を依頼し、週単位で必要なことを判断する。開発チームは、好きな方法でスケジュールを管理するが、シナリオの完成ステップを週単位で計画し、進捗、状況、今後の見込みを説明し、必要な判断を依頼する。
④ビジネス成果を伝える
ビジネス部門は、週次や重要なマイルストーンごとに、開発チームが作ったものが、どのようにビジネスとしての成果に繋がったのかを開発チームにフィードバックする。また、次に目指すべきビジネス成果を提示する。開発チームは、自分たちが作ったもののビジネス成果を理解し、次のビジネス成果に対して、何をすべきか確認をする
原則①：ビジネス視点のマイルストーンを設定する
ビジネス視点で「いつ、何をしたいのか」を共有する
この原則の目的
ビジネス部門と開発チームが同じゴールに向かって動くためには、開発完了ではなく、ビジネス視点で意味のあるタイミングを起点としたマイルストーンが必要です。
「○月末までに〇〇機能を完成させる」ではなく、「○月○日までに、ユーザーが〇〇できるようになる（＝ビジネス視点の成果）」という成果ベースの節目を設定します。
ビジネス部門がやること
開発チームがやること
- 提示されたマイルストーンに向けて、必要な開発項目を逆算してスケジュールする
- 開発チームだけで対応できないことがあれば、ビジネス部門と一緒に対応を考える
なぜこれが重要か
- 機能ベースのスケジュールで進捗を共有しても、ビジネス視点では、あまり意味がない
- ビジネス視点のマイルストーンを目指すことで、優先順位判断・仕様変更対応・進捗確認がスムーズになる
- 関係者全員が「なぜこれをやっているのか」を忘れずに進められる
原則②：シナリオベースの課題リストを作る
ビジネス視点で「やるべきこと」を共有する
この原則の目的
ビジネス部門と開発チームのコミュニケーションを効率的にするために「やるべきこと」の整理単位が共有されていることが重要です。
単なる機能一覧や要望の箇条書きではなく、「ユーザーが、なぜ困っているか」「どうしたのか」いうシナリオに基づいて課題を整理します。これにより、やるべきことの意図や背景を共有しやすくなります。
ビジネス部門がやること
- ユーザーの「困っていること」「やりたいこと」を、具体的な利用シナリオで記述する
- シナリオは「画面」や「機能」単位ではなく、「ユーザー視点の行動」単位で整理する
- その行動がどうなると「どうなれば成功か（＝期待される状態）」を示す
- シナリオは、できる限り、優先順に並べる
開発チームがやること
なぜこれが重要か
- 仕様やUIの議論が「何のためか」から逸脱しにくくなる
- ビジネス視点を保ったまま、開発や優先順位の判断ができる
- 進捗報告のたびに「その機能、誰のどんな課題に関係あるの？」という問いを省略できる
原則③：週単位で計画し、判断する
ビジネス視点で理解できるまとまりで進捗と調整を共有する
この原則の目的
数ヶ月先の目標に向かって、日単位の細かい進捗を確認しても、「それが何に向かっているのか」「遅れているのか順調なのか」がわかりにくく、そこから何かを判断することは困難です。
そこで、週単位で「この週では何を完成させるか／そのために何をするか」をあらかじめ計画し、それに対する状況・課題・優先順位を毎週共有・判断するようにします。
週という“まとまり”を使って全体像を捉えることで、必要な調整をすぐに行うことができるようになります。週単位の計画は、少なくとも4週分程度は計画し、最大でも12週（3ヶ月）程度の範囲に留めます。これによって、適度な見通しが可能になります
ビジネス部門がやること
- 毎週、決まった曜日・時間に定例を行い、「この1週間に何をしたのか」「次の1週間に何をするのか」「その先は、どういう予定か」を確認する場を設ける
- 計画に対して遅延がある場合は「何が想定外だったのか」について話し合い、今後の予定への影響を確認し、その場で調整を行い、判断を持ち帰らないようにする
- ビジネス側の理由で予定を変更する場合、開発チームに申し入れを行って、次の定例で調整結果を確認する。ただし、次の1週間に予定されていることは、よほどの理由がない限り変更しないようにする
開発チームがやること
なぜこれが重要か
- 数日単位の断片的な進捗ではなく、「意味のあるかたまり」で共有・判断ができる
- 週ごとの計画と判断がサイクルになることで、状況の見通しが立ちやすくなる
- ビジネス部門が、期日とスコープのどちらを優先して判断すべきかが明確になる
原則④：ビジネス成果を伝える
ビジネス視点での成果を共有する
この原則の目的
開発チームは、「この成果が、誰にとって、何の役に立ったのか」を聞く機会が少ないまま、次の作業に進みがちです。
しかし、自分たちの開発成果物がどう使われ、どんなビジネス成果につながったのかを知ることで、モチベーションや判断の質が大きく変わります。
この原則は、開発を「単なる納品」ではなく、「ビジネス成果を届ける行為」に変えるためのものです。
ビジネス部門がやること
開発チームがやること
- 開発成果物の使われ方や反応に関心を持ち、どう貢献できたかを理解しようとする
- 「次に目指すビジネス成果」を理解し、それに沿って開発や改善の方向性を考える
- 必要だと思えば、改善提案やフォローアップのアイデアを提案する
なぜこれが重要か
- 「なぜやるのか」「それは役立ったのか」を意識することで、作業が目的化することを防げる
- 次に向けた判断や提案が、開発チームからも出やすくなる
- お互いが「いい仕事ができた」と感じられる
原則⑤：支援する第三者を設置する
対話の“通訳”として中立の存在を共有する
この原則の目的
ビジネス部門と開発チームの間で、認識のずれや意見の食い違いが生じるのは自然なことです。しかし、そのまま放置し続けると、相互の信頼がなくなり、過剰な説明を求めたり、非効率な作業が増えることでプロジェクト全体が停滞します。
この原則は、両者の間に「対話を促進する中立の存在」を置くことで、建設的な関係を維持するためのものです。
ビジネス部門がやること
まとめ
「バインドの5原則」の目的は、ビジネス部門が開発チームと継続的に良いコミュニケーションを行うことで、ビジネス視点で高い成果を生み出すことにあります。
よって、ビジネス部門が主導して取り組むことが望ましいですが、そうでない場合は、開発チームが求めるべき内容となります。
「こんなことができるビジネス部門なら苦労しないよ」と言われる気もしますが、であればこそ、ちゃんと求める必要があります。「開発のやり方を理解してほしい」と伝えるより、相互の視点を共有するしくみを整える方が、はるかに現実的で前向きです。
相互に努力を重ねることで、信頼関係が生まれ、より良いプロジェクト運営へとつながることを願っています。
補足
この原則は、私自身が、コーチやコンサルタントとしてビジネス部門の支援を行い、開発チームとの橋渡しをしてきた経験から生まれました。
スクラムやPMBOKは素晴らしい仕組みですが、ビジネス部門がオーナーで進める場合、システム開発に不慣れのため、役割と責任が曖昧になりがちです。
そうした場合に、私が、ビジネス部門に「こうするとコミュニケーションが良くなりますよ」とお勧めして、効果があった取り組みを原則として整理してみました。
もちろん、名前の通り、スクラムを参考にしていますが、ビジネス部門から見たコミュニケーションに注目しており、スクラムとの親和性を保ちながらも、ウォーターフォール的に進めている開発チームにも適用できるように整理しています。
