スクラムマスターの資格を取得した いとけん です。
所属部門であるディベロップメントテクノロジーセンターでは、昨年度から『アジャイル技術コミュニティ』を作り普及・啓蒙活動をしています。昨年度のコミュニティ活動ではアジャイル開発の経験者を集めて、工夫して上手く行った点・行かなかった点を経験者間で共有し、スクラムイベント毎に事例集(工夫したポイントのTips集)としてまとめ、社内公開しました。
本記事では、そのなかでも事例集を作るときに議論になった「アーキテクチャ設計は、どうやって進めるのか？」について纏めました。
「そりゃ、初めにやるでしょ。Sprint.0とかSprint.1で。。。」という話なのですが、実際の開発ではなかなかそうもいきません。開発途中でのシステム要求(≠ビジネス要求)の追加・変更(≒ピボット)を行うのが前提のアジャイル開発では、初めに全てを決めきることは難しく、開発を進めながらユーザーストーリーをシステムアーキテクチャ・方式設計に落とていかなければなりません。
このための時間を、どのように確保・計画していったらよいか、そのあたりを整理してみました。
私の所属していたプロジェクトは、ある規格に則った IoT 向けのクラウドシステムで、IoT デバイス側も同時開発だったので、デバイスアプリ開発チーム、クラウドアプリ開発チーム、規格の認証基盤開発チーム、クラウドインフラ構築チームの4チーム構成でした。
いわゆる「大規模アジャイル」に当たるのかもしれません。
ただ、「アジャイルやるぞー！」といった感じではなく「アジャイルのいいとこ取り入れてみよう」ぐらいの感じです。アジャイルと言えばスクラムの普及率が高いので、私たちもスクラムのプラクティスを取り入れてプロジェクトを進めていました。
このプロジェクトでは、ユーザーストーリー(以下、ストーリー)が1Sprintに入らないという問題を抱えていました。スクラムの研修を受けると「1Sprint内に入るぐらいにストーリーを小さくして毎Sprintデプロイすることで、小まめに実ユーザーからフィードバックをもらいましょう」と聞くかと思います。しかしどんなに小さくしても、複数チームという事情もあり1つのストーリーを実現するにはチーム間の調整をする必要があり、1Sprintに収まらず、、、
具体的には、以下のような作業がしばしば発生していました。
- 機能を実現するためのアーキテクチャ(以下、アーキ)設計案を複数出し、メリットデメリットを出す
※ここで指すアーキ設計は、ストーリーをどう実装に落とし込むのか(利用する技術の選択やシーケンス)の設計です - 技術的に実現可能かの調査(有益なライブラリがあるかの調査など)
- 各チームで開発するアプリ間の具体的なインタフェースの定義
- 結合テストを行う日程調整
これらの作業を終えると、やっと 5.詳細設計 6.実装 7.テスト 8.デプロイ ができる感じです。
チーム間の調整となると回答待ちの時間が発生したりしますし、1Sprint(2週間) に収まらないのがイメージできるかと思います。
しかも、1～4の作業は試行錯誤があるので、5～8の作業と同等か、それ以上の期間・コストがかかっていました。
一体この1～4の作業は、スクラム開発的には何の作業に入るのでしょう。
- アーキ設計やインタフェース設計(以下、IF設計)を行っているから、Sprint内のタスク？
→ でも見積り前じゃん。 - 日程調整(どのSprintに入れるか?)をやってるから、Sprint計画でやるべき？
→ やることが明らかになってないとSprint計画終わらないよね。 - 工数見積もりをやってるからプロダクトバックログリファインメント？
→ え、Sprintの半分ぐらいの時間を使って？ - 技術的に実現可能かの調査って、何に入るんだ？
→ むむむー！
私の頭のなかでぐるぐる回りだしてしまいました。
こんな時に立ち返るのは、スクラムガイドです。
スクラムガイド2020を見てみると、プロダクトバックログの節にこんなのとが書いてあります。
1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプ
ランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの
活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく
詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの
詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選
択できるように、プロダクトオーナーが開発者を支援することもできる。
「リファインメントの活動を通じて、選択に必要な透明性を獲得する」とあるので、1～3はRefinemetに入りそうな気がします。しかし、Sprint内でプロダクトバックログリファインメントにかける工数が50%近いというのは明らかに異常です。
でも、この中にヒントがありました。
プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。
分割。
なにも、小さなストーリーになるように、、、とは書かれていないではないか！
スクラムでは、スクラムチームが自発的に改善案を出して問題に対処していかなければなりません。
私たちは、一旦いわゆるスクラム研修で云われる手法とは異なるものの、ストーリーを図のように「分割」して対処することにしました。
上がスクラム研修で学ぶ分割のしかた、下が私たちの解としての分割のしかたです。
もちろん、この方法には以下のような欠点もありますが、私の所属していたプロジェクトでは、それが問題とならないため採用することが出来ました。
- ストーリーがデプロイされるまでに時間がかかる
- 従って、毎Sprintはデプロイできない
この方法を取るようになってから、芋づる式に調査・検討課題が出てくることが予見される場合を除いては、各バックログアイテムの作業工数の見積りが可能になり、Sprint計画で出来るできないで揉める(というか自信がない状態)も減りました。
従って、あらかじめ、いつ頃になったら他チームと結合を開始できるかを明確に答えることも出来るようになりました。そして、1～2カ月ぐらい先までの見通しが立つようになったので、他チームの状況を見ながらのタスクの入替えも容易になりました。
図にすると、こんな感じです。
実際は、アーキ案1か案2かで後続の進め方が違ったり、課題とアーキの順が入れ替わったり(場合によって不要だったり)しますが、それらが可視化されたことが大きかったです。
クレスコには『アジャイル技術コミュニティ』があるとお話ししました。
そのコミュニティでは、スクラムコーチのように活動しているメンバーや、外部のスクラムコーチに相談したりできる機会が有ります。
その場で、どういう手段が取りうるかを相談してみました。
やっぱり、ストーリーを複数の小さなストーリーに分割するのが良いみたいです。
ただ、以下のような考え方も取り入れるのも有りかも。とのことでしした。
- 他のチームに関与する部分と、関与しない部分に分ける。
- タスクかんばんに Uncontrol(waiting) というレーンを作って管理する。いつ進捗確認するのかを管理する。
- プロダクトオーナーとリファインメントの時間を多く持つ。
また、以下のようなことに注意すると良いのでは。とのアドバイスも貰いました。
- プロダクトオーナーと受け入れ条件を変えてみる
- Sprintレビューの定義を変えてみる
- 例えば「DEMOが出来ないといけない」から「紙芝居をSprintのゴールにする」など
これなら、いろいろと対策のしかたは有りそうです。
私たちの解も、あながち間違いではなかったようです。
こちらも先生たちに教わったのですが、先に必要な情報収集をすることを「スパイク」と言い、私たちの実践していた「アーキ設計」「課題調査」「IF設計」はスパイクに当たるんだよ。とのことです。
そして、知見のあるメンバーと議論すると新しいアイデアがどんどん出てくるなと実感しました。
また、少しぐらいスクラムの原則から外れていてもトライしてみて良いんだと感じました。（早くトライすれば、失敗しても、すぐ是正できるしね）
プロジェクトの特性によって取るべき施策も異なるので、この記事の内容が万人に当たるとは思いませんが考えるキッカケになればと思います。
スクラムマスターの資格を取得したからと言って、とつぜんスキルが身に着くなんてことはないので、これからも、コミュニティで相談しながら、悩み悩みアジャイル開発を推進していきたいと思います。
