「うちはアジャイルなので仕様書は作りません」と言われて、返答に困ったことがあります。
その現場では実際に仕様書が無く、決めたことがどこにも残っていませんでした。半年後に「なぜこの作りにしたのか」を誰も答えられない状態になっていました。あれをアジャイルと呼んでいたわけです。
原文には、そんなことは書かれていません。
とはいえ、アジャイルにしてほしいと言いたくなる気持ちも分かります。私も逆側に立ったことがあって、遅いし出てきたものが想像と違うという状況では、進め方を変えたくなる。だからこの記事は、言う側と言われる側の両方に向けて書きます。
宣言は「捨てる」と言っていない
アジャイルの出発点は2001年に出た短い文書です。日本語版が公開されています。
対比が4つ並んでいます。原文の言い回しをそのまま写すのは控えますが、扱っている観点はこの4つです。手順や道具よりも人と人のやりとりを見る。文書を作ることよりも動くソフトウェアが出ていることを見る。契約の交渉よりも顧客と協力できているかを見る。計画を守ることよりも変化に対応できるかを見る。
そのうえで大事なのが末尾の一文です。原文は「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」と書いています。
つまりドキュメントに価値が無いとは書いていない。動くソフトウェアのほうを優先する、と書いてある。優先順位の話であって、廃止の話ではありません。
冒頭の現場は、この一文を落として読んでいたのだと思います。私も当時は指摘できませんでした。原文を読んでいなかったからです。
宣言には12の原則も付いています。こちらも短いので、通しで読めます。
スクラムは枠組みで、手順書ではない
実務でアジャイルと言うとき、多くはスクラムのことを指しています。定義は公式のガイドにまとまっていて、いまの版は2020年11月のものです。
読んでみると分かるのが、分量が少ないことです。何をどう作るかの手順ではなく、枠だけが決まっている。決まっているのは、誰が何に責任を持つか、決まった時期に必ずやる会議(公式には「イベント」と呼びます)、そして作るもの。中身は自分たちで埋める前提になっています。
用語をひとつ補っておくと、2020年版は「役割」という言い方をやめて「責任」という言葉を使っています。肩書きを配るのではなく、誰が何を引き受けるかという建て方です。
だから「スクラムを導入したのにうまくいかない」という相談は、枠だけ入れて中身を埋めていない状態だったりします。毎日の短い会議とスプリント(1〜2週間などの区切りのこと)は入れたけれど、何を作るかの優先順位を決める人がいない。枠は形だけ動きます。
この優先順位を決める役を、スクラムではプロダクトオーナーと呼びます。会議でこの言葉が出てきたら、決める人を立ててくれという話だと思ってください。
私が見た中でいちばん効いていたのは、スプリントの終わりに実際に動くものを見せていたチームでした。動くものが出てくると、見た人が「これじゃない」と言えます。言われた側は嫌ですが、半年後に言われるより安い。
ウォーターフォールとの実務上の違い
対比としてよく出るウォーターフォールは、工程を順に一度ずつ通す進め方です。要件定義から始めて、設計、実装、テストと降りていく。
違いは「反復するかどうか」だと説明されますが、実務でいちばん効いてくる違いは別のところにあると感じています。間違いに気づけるタイミングです。
ウォーターフォールは、要件が正しいという前提で動きます。前提が正しければ効率的です。順番に進めるだけなので無駄がない。ただし要件が間違っていた場合、途中の設計レビューで拾えなかった分は、動くものを見て気づくことになるのでテスト以降まで残ります。そこまでに作ったものが全部影響を受けます。
反復型は、2週間ごとに動くものを見せるので、間違いが2週間以内に見つかります。代わりに、毎回の区切りで作る手間と見せる手間がかかる。効率は落ちます。
つまり要件がどれくらい確かかで選ぶものです。既存業務をそのままシステムにするなら要件は確かなので、順に進めたほうが早い。何を作るべきか自体が分かっていないなら、反復して確かめたほうが安い。
工程の並び自体はどちらでも同じものが出てきます。呼び方については別記事にまとめました。
反復の中でも対応関係は必要
反復型にすると設計を書かなくていいと解釈されることがあります。ここは分けて考えたほうがいい部分です。
決めたことと確認することが向き合っているかという話は、期間の長さとは関係なく成り立ちます。2週間のスプリントの中でも、何を作るか決めていなければ、できたものが正しいかを判断できません。規模が小さいので傷が浅いだけです。
この対応関係についてはV字モデルの記事で書きました。
AIが入ると反復の回数が変わる
いま実務で起きている変化を書きます。
反復型のコストは、毎回動くものを作る手間でした。2週間に1回しか見せられなかったのは、それだけ時間がかかっていたからです。
実装をAIに任せると、ここが縮みます。私は自分用に作った小さな社内ツールで、朝に方針を決めて夕方に動くものを見る形を何度かやりました。1日で1周しています。以前の感覚だと1週間かかっていた粒度です。
ただし回せる回数が増えると、別の問題が出ます。見る側が追いつきません。 私は自分ひとりで作っていたので問題になりませんでしたが、業務側の人に毎日確認してもらうのは無理です。
ここは実際に詰まりました。1日1周で回して4日分ためてから見せたら、どの変更がどれなのか説明できなくなっていた。作る速度が上がっても、合意する速度は上がらないという当たり前のことに気づくのに、4日かかっています。
いまは作る回転と見せる回転を分けています。手元では毎日回して、見せるのは週1回。回せることと回すべきことは別だと思うようになりました。
導入を聞かれたときに確認すること
研修先で「アジャイルにしたい」と言われたとき、私は2つ聞いています。
優先順位を決める人が決まっているか。 ここが空席のままスクラムの形だけ入れると、毎回の区切りで何を作るか揉めます。決める人がいないなら、先にそこを決めるほうが効きます。
動くものを見て判断する人が時間を出せるか。 反復の価値は早く間違いに気づけることなので、見る人がいないと反復した意味が消えます。月に1回しか時間が取れないなら、2週間のスプリントは意味を持ちません。
どちらも手法の話ではなく人の話です。私が見てきた範囲では、詰まる原因はほぼこの2つでした。
