ウォーターフォール脳がほんのりと理解したアジャイル・スクラムの概要
前職は割とお堅いウォーターフォール式の現場がほとんどで、現職ではアジャイルチックな進め方をするようになってきた。
そんな中、実はイマイチアジャイル開発とかスクラムとかが指す意味が分かっていなくて、「この人が言う『アジャイル』と、自分が持っている『アジャイル』の概念がズレてるんじゃないか」と思うことがよくあったので、改めて調べてみた。
目次
「アジャイル開発」は「心構え」
まず、「アジャイル」とよく云われる単語の、一般的な、辞書的な定義を確認する。コレは、エクストリーム・プログラミング (eXtreme Programming) の考案者で知られるケント・ベックってオジさんとかが考えた、アジャイルソフトウェア開発宣言で提唱されている価値観と原則のこと。
提唱されている価値観は以下の4つ。
- プロセスやツールよりも個人と対話
- 包括的なドキュメントよりも動くソフトウェア
- 契約交渉よりも顧客との協調
- 計画に従うことよりも変化への対応
これらについては、
左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
と記されており、決して「ドキュメント要らねえ」「計画しなくていい」って意味ではない。
- 参考 : アジャイルソフトウェア開発宣言
そして、原則として触れられているのは以下の12項目。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
この辺で、僕はちょっと 「精神論っぽいなぁ」と感じてしまった。
- 「価値のあるソフトウェアを速く継続的に提供」「一定のペースを継続的に維持」
- ココで完成、って区切りを作らないでどうやって契約するつもりだろう。客側も成果物を定義しないで何を作らせたいんだか…
- 「日々一緒に働かなければなりません」「フェイス・トゥ・フェイスで話をする」
- 口頭伝達に頼るから「言った」「言わない」になるんじゃん、文書化しろよ
- 「技術的卓越性と優れた設計」「シンプルさ」「自己組織的なチーム」
- 日本の職業エンジニアにそんなスキル持った人間がどれだけ居るかねぇ、基礎スキルがないからどんな開発手法とっても上手くいかないんだよ
このような疑問がモヤモヤっと湧いた。
- 参考 : アジャイル宣言の背後にある原則
いくつかの前提がウォーターフォールとは異なる
そこからもう少し調べてみると、アジャイル開発という手法を選ぶ場合は、そもそも、ウォーターフォールな考え方をする時に前提としている事柄が異なるのである。例えば以下のような事柄は前提にしていない。
- 何をどんな構成で作るか、事前に厳格に決める
- 何が欲しくなるかは日々の情勢によってちょっとずつ変化する
- 大枠として「こんなことを実現したい」はあるものの、システム構成も、実装する内容も、日々の状況に応じて変えることが前提
- 要件 = Scope は事前に決まらないし、日々変更が入るモノとして携わる
- 開発チームは工程に合わせて要員が増減する
- 少数精鋭なチームで、メンバを固定する。これにより、チームがある期間内にかけられる時間は固定化される (5人チームなら、8時間/人 × 5人 × 1週間の営業日5日間、で、200時間、みたいなのが固定と捉える)
- 要件に合わせて開発期間や費用を割り出す
- アジャイルの場合、スプリントと呼ばれる区切りを設けることで、リリースまでの期間を固定する。要員変更もしないので、その期間内でかけられる作業量も上限が決まる
- 固定化された期間と労働力 (コスト) の中で、実現できる要件のうち、重要なモノから順に着手する、という考え方
- ドキュメントに関する細かな成果物責任・納品義務がある
- あんまりない
- そもそも何のためにドキュメントが必要だったかというと、ウォーターフォール式ではチームの要員が増減し、引き継ぎが発生するため、全てを文書化する必要があった
- アジャイルの場合、チームメンバは少数で固定するし、毎日顔を突き合わせて密にコミュニケーションをとるので、ノウハウは各人が持ったまま、うまく摺り合わせて作業していける。だから余計なドキュメントは要らない
- 極端な話、密なコミュニケーションによって、全ての事柄について認識齟齬がないことが確認できていれば、設計書も計画表も、そのチームにとっては必要ない、といえる
- ただ、現実的には人間は忘れるし、誤解も生むので、要件一覧や、スプリント内でのタスク一覧などは、特に認識齟齬がないように文書化する。仕様書も情報共有のために必要な分だけ書く
- お客さん側も、「動くソフトウェアさえあればええねん」という考え方で合意できていれば、納品義務も発生しないというワケ
個人的には、これらの前提が覆される、覆せるという事実に、目からウロコなところもあった。
要件は定まらない
ウォーターフォール式の時だってそうだったはずだ。せっかく要件定義書をガッツリ作っても、長期間の開発中に法改正があったりして、当初の想定どおりに作れなくなったりする。また、工程の終盤になって「やっぱりこの画面が欲しい」とか「この CSV がないと業務が回らない」とか言われて、炎上しながら無理くり実装したりすることもあるだろう。
要件定義書を作っている時は、確かにそれが欲しかったのだろう。でも、時間を経ると様々な状況が変化するし、それによって考慮不足や新たなアイデアが生まれてくるから、その当時決めたとおりのモノでは不足感があり、仕様変更したくなるワケだ。
ウォーターフォール式の要件定義という工程は、「要件を洗い出して決めていた」のではなく、「それ以降の仕様変更を受け付けないための契約書を作っていた」と言った方が、正しいかもしれない。でもそれは結局、お客さんが満足する結果にはなりにくい、ということは、これまで経験してきたはずだ。
だったら、お客さんが満足できることを第一優先して、要件は日々変えて調整していきながら、その瞬間その瞬間で一番重要なモノから実装してリリースしていきましょ、という考え方なのだろう。
余計なドキュメントは要らない
結局のところ、「要件を先に FIX しなきゃ」「納品する成果物の種類を定義しなきゃ」みたいな感覚って、「これまでそうしてきたから」でしかなくて、「今後もそうしないといけない」ワケじゃない。
既にみんな分かってるじゃん。設計書なんて書いてもお客さんは読まないし、開発した自分たちですら、ボリュームが多すぎてコード見た方が早くて正確だ、って。だからもう、最初から「そういうゴミになる資料は作らなくていいっすよね？」とお客さんと合意を取っちゃえばいいのだ。そうすれば、「絶対に作って残さないといけないドキュメント」なんて、かなり少なくなることは明らかだ。
僕が以前書いた「メモとノートの違い」で言うと、開発中はずっとメモの考え方で動き、チームが解体されるようなタイミングで初めて、引き継ぎ等のためにノート的な情報が必要になるワケだ。そのようなやり方で行くことをお客さんと予め合意すれば、別にそれでいいのだ。
「XP」「スクラム」はアジャイルを実現するプラクティスの一つ
前述のとおり、「アジャイル開発」という言葉が示すのは、提唱された「4つの価値観と12の原則」のことしか指さない。これらだけ見ると、やっぱりまだ根性論っぽいというか、具体性に欠けるのだ。そりゃそうだ、提唱しているのは「価値観」までで、方法論ではないからだ。
結局のところ、「アジャイルソフトウェア開発宣言」が言っているのは、「今まで大事だとされてきたことより、コッチの事柄の方が大事だべな。で、それをどうやって実現していくかは、自分で考えてな」ってことなのだ。だからアジャイルという言葉だけ聞いても、あまりしっくりこないのだ。
コレだけだとしっくりこないので、具体的な方法論に落とし込んでいったのが、「エクストリーム・プログラミング (XP)」だとか、「スクラム」だとかいう手法なのである。これらは手法、方法論の一つであり、こうしたやり方ならアジャイル開発の価値観を守っていけると思うよ、というフレームワークなのだ。
最近話題の「スクラム」については、「認定スクラムマスター」という資格も出来上がっているくらい、具体的な手法が定められている。表面的な言葉だけ聞くと根性論っぽさがあるのだが、一応資格の中ではそれぞれの言葉や進め方、価値基準に定義があり、メンバはそれを遵守しないといけない。誰がどのように決めたにせよ、一人の思いつきの根性論ではなく、思考フレームワーク・意思決定フレームワークとして体系的にまとまっていることで、みんな従いやすいって魂胆なんだろう。
実際は「自分の頭で考える」が求められる
大元の価値観は「良いシステムを迅速に・継続的に構築することを目指す」ことに終始している。コレまでの「一回決めたこの仕様どおりのモノを作って」というモノづくりの考え方ではなく、「結果的にこういう価値を生み出したいから、それに合わせた良い感じのやり方を随時生み出してって〜」といった、サービス提供の考え方に近いのだと理解した。
だから、スクラムマスターなどは資格になっているとはいえ、実際チームに取り入れて作業する場合は、人・場所・状況に応じてルールの調整が必要になるだろう。もしかしたら「スクラム」ではない手法に転換することで上手くいく例もあるのかもしれない。いずれにせよ、求められるのは「より良い状態にしようと改善に努めていくこと」なのであって、お客さん側も「これだけのシステムをいつまでに」という考え方ではない、ということなのだ。
そんなワケで、どうしても巷の記事を読んでも、「正解」がない。
- 具体的に作成するドキュメントってなんなの？雛形はないの？
- → その瞬間に必要になったものを作るだけ。雛形はない。関係者が分かればいい。
アジャイル開発を実践したことがない、ウォーターフォール脳だった人間が理解したのは、こんな感じ。