はじめに

アジャイル開発がうまくいかない原因はいろいろ考えられると思いますが、立ち上げ時にその原因が潜んでいる場合も多いのではないかと思います。たとえば、開発前の準備が不十分であったり、詳細があいまいなままプロジェクトがスタートしてしまっていたり、といったケースです。
今回はアジャイル開発の失敗を未然に防ぐため、アジャイル開発の立ち上げ時に、とくに注意すべきポイントを紹介します。

まずはチームを作ろう！

アジャイルを始めるにあたって、一番重要なポイントはやはりチームでしょう。良いチームを作ることが立ち上げの成否を左右するといっても過言ではありません。
では、チームのメンバーをどう選定し、どう意識付ければよいでしょうか。

チームメンバーの選定

まったく何もない状況からアジャイル開発を始めるためには、まずメンバーを集めなければなりません。スクラムマスター（以下SM）やプロダクトオーナー（以下PO）がすでに決まっているとしたら、残りは開発メンバーです。スクラムガイド^注1では、スクラムにおける開発チームの人数は3～9人程度で、チーム全体として職能横断型である^注2ことが推奨されています。
ところで、アジャイル開発にはどんなタイプのメンバーが向いているのでしょうか。「アジャイル宣言の背後にある原則」^注3にヒントがありそうです。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

上記の「意欲に満ちた人々」がメンバーに求められる原則になるでしょう。筆者の経験上、うまくアジャイルに適合しているメンバーは次の特徴を持っていることが多いです。

上記のようなマインドを持っているメンバーを集めることで、アジャイル開発の成功率を上げることができると思います。
ただ、上記に当てはまらないからといって、アジャイル開発にふさわしくないというわけではありません。後述しますが、立ち上げ時の研修などを含めて、未経験者でもアジャイルマインドを獲得することは十分に可能です。逆に、十分なスキル、経験を持ちながらも、従来型開発の経験が長かったりすると、どうしてもアジャイル開発にうまく適応できないこともあります。

インセプションデッキの導入

チームメンバーを集め終わったら、次はチームビルディングです。開発メンバーだけではなく、POやSM、あるいはその他、プロジェクトの関係者、ステークホルダ（利害関係者）も巻き込みましょう。
チームビルディングのための有名な手法として「インセプションデッキ」があります。過去、本連載の第4回「初めての新規サービス開発（実践編）」^注4でも取り扱っていますので、各項目についての説明は省きますが、インセプションデッキは「我々はなぜここにいるのか」「エレベーターピッチ」をはじめとした10の設問と課題から構成されており、これらを実施することで、プロジェクトの「なぜ（Why）」と「どのように（How）」を明確にすることができ、チームとして同じ方向を向くことができるようになります。
メンバー全員で会議室などに集まり、ファシリテーター役がメンバーに対して質問を投げかけ、それに回答していく形で進めていきます。進行のやり方自体もチームで相談して決めるとよいでしょう。特定のメンバーが意見を出して決めていくのではなく、ふせんに書いて出し合うなど、必ずメンバー全員の意見が反映されるよう進めていくことが大事です。
長い開発期間中にチームとして向かうべき方向がわからなくなったときなどに、作成したインセプションデッキにいったん立ち戻ってみるとよいでしょう。

アジャイル研修やコーチングによる教育

アジャイル開発では、その他の開発手法と異なる部分も多く、その手法やプロセスについて、あらかじめ理解しておく必要があります。アジャイル開発が一般的になってきた今では、さまざまな会社からアジャイル研修やスクラム研修のコースが提供されており、複数人で簡単な課題を解決することを通じて、アジャイル開発の進 め方を理解できるようになっています。
アジャイル研修には、開発メンバー向けだけでなく、PO、SMなど、役割別にコースが用意されていますので、できるだけチーム関係者全員に研修を受けてもらうようにしましょう。とくに、POにプロジェクトに積極的に関わってもらえるかどうかは、プロジェクトの成功を左右する大きな要素でもあります。
チーム編成において、チーム内にアジャイル経験が数年あるメンバーがいる場合もあれば、メンバー全員がアジャイルは初めてという場合もあると思います。後者のようなチームの場合、プロジェクトが軌道に乗るまでの間は、コーチングが大きな助けとなります。チーム内部に適当な人材がいない場合は、外部からアジャイルコーチを呼ぶとよいでしょう。

PBLはどのように作成する？

PBLはスクラムチームの計画に必要となる、重要なインプットの1つです。最初のスプリントの時点では、開発チームやステークホルダなど、関係者すべてがプロダクトの全体像を理解できるよう、プロダクト全体のビジョンがわるものであるべきです。全体像が見えることで、進捗を見える化することもできます。
すべてのPBLを用意するのは大変だと思うかもしれませんが、最初に作成するPBLは粗い粒度でかまいません。たとえば、ECサイトを作るのであれば、「商品を名称で検索できる」「商品詳細を表示できる」「商品を購入できる」といったPBIで十分です。PBIは開発途中で追加や削除することもできます。
重要なのは、優先順位が高い（≒着手が近い）PBIから順に、開発チームが対応可能なよう、詳細化と添削を行っていくことです。図1の例でいえば、「商品を購入できる」に着手するタイミングが近くなって来たら「購入数が選択できる」「代引き決済ができる」のように詳細化していきます。見積もりについてはのちほど触れますが、1つのPBIが大き過ぎる場合には、PBI自体を分割するとよいでしょう。
スプリントプランニングのタイミングで最終的な優先順位の入れ替えを行い、そのスプリントでの作業を決定します。筆者の経験上、直近の2～3スプリント程度が詳細化されていれば、スムーズにプランニングを実施することができると思います。
PBLを作成するにあたっては、本連載の第3回「初めての新規サービス開発（価値創出編）」^注5、前述の第4回にて方法論などを解説しています。

図1　PBLの詳細化イメージ

PBL 作成時の開発チームの動き

PBLはチーム関係者全員に共有されていることが重要であるため、作成には開発チームにも必ず参加してもらうべきです。そして、PBLの内容について開発チームがしっかりと理解できるよう、POは十分に説明をする必要があります。
スクラムにおける初期見積もりでは全体を詳細に見積もる必要はなく、前述したように最初の2～3スプリントについては詳細に、その後のまだ詳細化されていないスプリントについては、ある程度ざっくりとした見積もりでOKです。

スプリントの長さとプランニング

スプリントの長さはどうやって決めればいいでしょうか？　POにとっては短いスプリントのほうが要望を反映する機会が多くなりますが、一番大きなサイズのPBLを完成させられるだけの長さは確保しないといけません。最終的にはPOと開発チームがバランスを考えて決めるとよいですが、スプリント期間が短いほうが、レトロスペクティブ（振り返り）とフィードバックの回数が増えて軌道修正が容易なため、スクラムに慣れていない状況であれば、1週間や2週間などの短いスプリントとすることをお勧めします（図2）。
スプリントの長さが決まったら、次はいよいよスプリント1のプランニングです。初期スプリントはまだベロシティが安定しないため、開発チームが期間内に完了する工程のイメージができる範囲で、PBIを優先順位順にスプリントバックログ（以下SBL）に入れてみます。スクラム慣れしていないチームでは、やはり短いスプリントのほうが工程をイメージしやすいでしょう。

図2　スプリントの長さと軌道修正の容易さの関係

ルールをあらかじめ決めておこう！

チームでアジャイル開発を実施するにあたっては、ルール作りが非常に重要になってきます。開発チーム内におけるルール、プロジェクトにおけるルールなどさまざまかと思いますが、アジャイル開発においては、どのようなルールをあらかじめ決めておくとよいのでしょうか。

ワーキングアグリーメント

アジャイル開発はチーム全体が同じ方向を向き、一丸となって進めていく開発手法です。メンバー同士でコミュニケーションを取り、協力していく場面が必然的に多くなるため、メンバー個人の納得感が非常に大事になってきます。誰かにタスクを無理やりやらされたり、不満を感じたまま進めていたりする状態では、チームの生産性はなかなか向上しません。
アジャイル開発においては「ワーキングアグリーメント」というプラクティスがよく実施されます。あらかじめチーム内で価値観を共有するため、プロジェクトの立ち上げ時に会議室にみんなで集まり、ホワイトボードに書き出すなどして、チーム内の開発ルールを決めておきます。
たとえば、次のような項目についてあらかじめルール化しておくとよいでしょう。

アジャイルプラクティスから、ツールの使い方、あるいは日常の細かいルールのようなものまで、チームのルールとして必要であると思うものなら、どんな些細なものでもOKです。「担当するチケットに30分ハマったら必ずアラートを上げる」「毎週水曜日は定時退社日とする」など、現場ならではの細かいルールもよく見かけ ます。取り決めたルールについては、開発途中で定期的に見直すとよいでしょう。
開発を進めていく過程において、問題が発生した場合には、これらの内容に立ち戻ることにより、問題が解決することもあります。そのためにも、決定事項については、チーム内で立てたWikiのページに掲載するなどしておきましょう。常に参照できますし、新しいルールの追加や更新も容易です。チームに新規メンバーが参画したときにも、ルールが明文化されていれば、大きな助けとなるでしょう。

完成の定義

スクラム開発では、各スプリントにおいて作成したインクリメント（スプリントの成果物）が、リリース可能な状態になっているかどうかの判定基準を、あらかじめ明確に決めておくことが大事です。この判定基準は、一般的に「完成の定義」と呼ばれ、図3のように、PBI共通に適用される具体的な条件で構成されます。プロジェクトの状況に応じて、完成の定義は順次アップデートしていきます。
各スプリントの成果物は、完成の定義をすべて満たすことにより、初めてリリース可能な状態とみなすことができます。
ここではドキュメントについても、何をどこまで作成するのか、忘れずに定義しておきましょう。アジャイル開発においては、「動作するものを作るのが最優先のため、ドキュメント作成は不要」と誤解されがちですが、けっしてそういうわけではありません。チームメンバーの入れ替えや将来的な保守のためにも、やはり最低限のドキュメントは作成するべきです。
アジャイル開発の場合は、一度作成したドキュメントに変更が加えられる可能性が高いため、メンテナンス性を意識したドキュメント作成を意識しましょう。たとえば、「ガチガチに固定されたフォーマットの使用を避ける」「最初からすべてを詳細に書き過ぎない」などです。

図3　完成の定義

スクラム開発に適したツールと技術を選ぼう

スクラム開発の現場においては、大きく分けて2種類のツールを活用していくことになります。1つはコミュニケーションツールやタスクの管理ツール、もう1つはプロダクト開発を効率化し、スクラムにおける反復型開発を支援するCI/CDツールなどです。本節ではスクラム開発が初めての方向けに、筆者の周りでデファクトスタンダードになっているツールを紹介します^注7。また、スクラム開発を始めるにあたって、事前に検討しておいたほうがよいアーキテクチャ要素についても、併せて解説していきます。

コミュニケーションツール

スクラムを運用するには、チケットの管理と、コミュニケーションを支援するツールが最低限必要となるでしょう。
チケットの管理には、一般的にJIRAがよく使われていると思います。 筆者も有償無償問わず多数のツールを利用したことがありますが、JIRAが一番便利でオーソドックスだと考えています。JIRAであれば、PBLからSBLを切り出し、スプリント単位で作業を管理する機能や、バーンダウンチャート^注8、ベロシティグラフ^注9など一般的なスクラムで利用される機能が一通り入っており、操作方法もほかのツールに比べて直感的に利用できるようになっています。
コミュニケーションツールとして、もっともお勧めするツールは、物理的なホワイトボードです。スクラムでは円滑ですばやいコミュニケーションが求められます。そのため、開発チームでホワイトボードを囲み、フリーハンドで絵を描いて議論するのが、速度と正確な認識合わせを行うバランスの取れた方法だと、筆者は考えています。
メンバー間での文字情報のやりとりには、チャットツールが便利です。ただし、現場のセキュリティ制約にも依存しますので、環境に合うものを選ぶとよいでしょう。筆者がよく見かけるチャットツールは、Slack、Mattermost、Microsoft Teamsなどです。また、ナレッジの蓄積のためにはWikiの導入も効果的です。オープンソースのPukiWikiなどがあります。

開発支援ツール

スクラムでは、スプリントごとに反復型開発を行うことになります。複数の開発者が同じソースコードに何度も修正を加えることになるため、バージョン管理を導入したり、回帰テストやビルド／デプロイなど時間がかかるルーチンワークにかかるコストをCI/CDによって削減したりすることで、開発効率を上げることができます。
　現在、ソースコードの管理ツールとしては、GitHubまたはGitLabがデファクトスタンダードになっています。筆者の周りではセキュリティ上の制約により、GitLabをセキュアな環境に構築して利用している現場が多いです。かつてはSVN（Subversion）を利用することもありましたが、近年ではほとんど見かけません。
CI/CDについては、無料で利用できるJenkinsや、有償ですがSaaSとしても利用できるCircleCIなどが有名です。Jenkinsがほぼデファクトスタンダードになっているため、本稿では特別な事情がなければJenkinsを導入することをお勧めします。ほかにもGitHub Actions や、クラウドサービスに内包されているものもありますので、プロジェクトの環境やメンバーの経験なども考慮して選定するとよいでしょう。

プロダクトを動かすアーキテクチャ

アーキテクチャに関しても、ある程度は事前に検討しておいたほうがよいでしょう。そうすることで、将来のベロシティ向上が期待できます。たとえばWeb開発であれば、バックエンド構成（サーバやOS、ミドルウェアなど）を準備しておくと、開発したプロダクトをすぐ動作させられます。また、バックエンド、フロントエンドで利用する開発言語／フレームワークを決定しておくと、チームがすぐに開発に取りかかることができます。
一方で、あらかじめバッチサーバを準備したはいいものの、プロジェクトが進みPBIを詳細化していった結果、バッチサーバは不要だったということも起こり得ます。そのような状況を防ぐために、PBIの詳細化範囲に合わせた最初の2～3スプリントに関する準備に留めておくとよいかもしれません。
検討するときは現場での制約をふまえつつ、開発チームを中心に議論していくことで、チームビルディングの効果も期待できますので、検討作業自体をスクラムチーム全体のタスクとすることをお勧めします。

おわりに

ここまで、アジャイル開発の立ち上げ時に注意するポイントについて見てきました。最後に少し振り返ってみましょう。

チーム

PBL

決まりごと

ツールと技術

◆　◆　◆

立ち上げ時にこれらのポイントを意識することによって、プロジェクトの成功率を上げることができると思います。
立ち上げ時にあらゆることを想定しようとすると、なかなかスプリントが始められませんので、まずは今回の内容に沿ってアジャイル開発の立ち上げ準備を実施することをお勧めします。
本連載は次回で最終回となります。最終回では連載の総まとめを行います。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx