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