スクラムマスター文屋宏が思うアジャイル開発【Vol.01】

みなんさん、こんにちは！
スタジオ・アルカナの文屋（ぶんや）です。
今回のテーマは「アジャイル開発」です。

このストーリーをご覧のみなさんは、「アジャイル開発」というワードは日頃からよく耳にされてるでしょうし、実践されている方も多いでしょう。
一方で、なんだかよくわからないけど、なんとなく「アジャイル」って言ってるだけという方もいらっしゃるかもしれませんね。

「Agile」という英単語の意味を調べてみると、「機敏な」とか「素早い」といった意味が出てきます。
つまり「アジャイル開発」とは、「素早い開発」ということになりそうですね。
しかし一体、何が「素早い」のでしょうか。

この答えは、アジャイル開発関連の本やウェブサイトを見ると、割とあっさりとした一文で書かれています。
見かけたことがある方もいらっしゃると思います。
見たことがないという方は、ぜひここで一度、「アジャイル開発とは」とググってみてください。

どうでしょう、意味わかりましたか？

正直なところ、私は最初に「アジャイル開発って何だ？」と思って本やウェブサイトを見ても、いまいちよくわかりませんでした。

そんな自分の体験を思い出し、本ストーリーではググってすぐにわかる内容ではなく、
・一通り勉強したけど、結局あんまりよくわからない
・アジャイル開発チームのメンバーだけど、うまくいかずに困ってる
・「とりあえずアジャイル開発でやれ！」と言われて途方に暮れてる
といった方たちに向けて、できるだけわかりやすく、ときには身近なエピソードや私自身の体験を交えてお伝えしていきたいと思います。

書き始めてみると一度にすべて語り尽くすのは難しかったので、４回に分けてお話しすることになりそうです。

第１回となる本ストーリーでは、従来のウォーターフォール開発と対比しながら、なぜアジャイル開発という手法が考案されたのかといった背景や、アジャイル開発では何を重視しているのかといった、開発の心得のようなものをお話しします。

第２回と第３回では、アジャイル開発の始め方と進め方についてお話しします。
ここでは、未経験の方でも、なんとなくアジャイル開発がどういうものかイメージできる内容にしたいと思います。
おすすめの手法や、教科書通りにはいかない難しい点についてもお伝えしたいと思います。

第４回は、アジャイル的に開発を進めてリリースできたとしても、それでプロジェクトが終わるわけではない、というお話しです。
映画やドラマであればハッピーエンドで終わりですが、現実はその後も続いていきますよね。
そこで現在進行中で私が関わっているチームを例に、リアルな体験を交えてお話ししたいと思います。

では、まずは身近なシーンを例に、アジャイル開発のイメージをお伝えしたいと思います。

ヘンテコな食事会とアジャイル的な食事会

誰かに「今度お食事でも行きましょう。」と誘われて、実際に食事に行ったなんていうことは、みなさんも経験あるでしょう。
ですが、
「何を食べたいですか？」
「場所はどこに行きたいですか？」
「何時から集まりますか？」
「予算はいくらですか？」
「最初に何を頼みたいですか？」
「デザートは何を頼みたいですか？」
など、根掘り葉掘り聞かれた翌日に、「あなたの要望をすべて資料にまとめました。認識に齟齬がないか確認してください。なお、食事会の日程は資料の内容に了承いただいてから１年後を予定しています。」と言われたらどうでしょう？

「その食事会、もういいや…」って思いませんか。

仮に頑張って資料を確認し、辛抱強く１年後まで待ち、やっとの思いでなんとか食事会が開催されたとしましょう。
そうして行ってみたら、「もうちょっと静かなお店が良かった。」とか、「もっと座り心地の良い席が良かった。」と気付くこともあるでしょう。
そのとき、「あなたから１年前に聞いた要望にはすべて応えていますよね？追加の要望があるなら、先に言っていただかないと困ります。」なんて言われたらどうでしょう？
「聞かれた質問にはちゃんと答えたんだけどなぁ…店の雰囲気や座り心地については聞かれなかったからなぁ…」なんて思いますよね。
何より、１年前に「こんなお店に行きたい」と言ったことなんて、今となってはどうでもよくなってますよね。

日常生活ではこんなおかしな体験をすることはないでしょうが、長年IT業界で標準的な開発手法であったウォーターフォール開発では似たようなことが起こり得ます。
それに対して、アジャイル開発的な食事会は、次のようなイメージです。

「今度お食事でも行きましょう。」と誘われたら、翌週には「お好みに合いそうなお店を予約してみました。」と招待されます。
そうしてお店で食事をしながら感想を聞かれたので、「もうちょっと静かで、座り心地の良いお店が良いです。」と言うと、また翌週には静かで座り心地の良いお店に招待されます。
そこでまた感想を聞かれるので、気付いたことを伝えると、そのまた翌週には改善されます。
こういったことを繰り返していくうちに、文句なく満足できる食事会になっていきます。

プロジェクトのゴールって何？

ウォーターフォール開発とアジャイル開発では、なぜ上の食事会のような違いがあるのでしょうか。
もう少し、この２つの開発手法を対比して見ていきましょう。

みなさんの周りで、途中で頓挫したプロジェクトや、いつの間にか自然消滅したプロジェクト、そしてその残骸のようなドキュメントを見かけたことはないでしょうか。
なんだかIT業界のプロジェクトって、ちゃんとゴールまで辿り着いていないことが多そうなイメージがあるのは、私だけでしょうか。
そもそも、プロジェクトのゴールって、何なのでしょうか。

私はまさにこの「ゴールって何？」というところが、２つの開発手法の違いを考える上で重要なポイントだと思います。
プロジェクトに関わるメンバーが、何をゴールだと考えて動いているのか、そこに大きな違いがあると感じています。

ウォーターフォール開発では、プロダクト開発の一連の流れを要件定義、設計、実装、テストといった工程で区切ります。
そして各工程のアウトプットが、次工程のインプットになっていきます。
例えば要件定義工程では、要件定義書がアウトプットとなり、それが次の設計工程のインプットになります。

つまり、要件定義工程のゴールは、要件定義書の完成ということになります。
続いて設計工程のゴールは、設計書の完成です。
このように、ウォーターフォール開発では、工程毎に「これが完成しない限り次の工程には進めない」という明確なゴールがあります。

この「工程毎にゴールがある」というのが、よくも悪くもウォーターフォール開発の特徴です。
そして途中で頓挫したプロジェクトでは、この特徴が悪い方に働いていると思われます。
さらに厄介なことに、工程毎に担当者が変わってしまうこともよくあります。
それにより、自分が担当する工程が無事に完了することがゴールだという意識を持ってしまいがちです。

その結果、ウォーターフォール開発では、次のような状況に陥ってしまうことがあります。
・要件定義は完了しているが、そこから先に進まない
・設計は完了しているが、そこから何も開発されていない
・開発は完了しているが、実は誰も使っていない

要件定義書の完成はあくまでも要件定義工程のゴールでしかなく、設計書の完成は設計工程のゴールでしかありません。
例え工程毎のゴールに達していたとしても、それらはどれもプロジェクト本来のゴールではありません。

発注者である顧客にとっては、開発が完了してリリースして、運用フェーズに入り、ユーザーが定着していき、それによって業務が効率化されたり、収益が得られたり、開発コストを上回る何かしらの効果が得られてはじめて真のゴールに到達したと言えます。

ですがIT業界の常識なのか、要件定義書を納品すればそれだけでお金がもらえてしまうといった契約もあります。
顧客側からすると、要件定義書だけを納品してもらったところで、一体何が嬉しいのでしょうか。

冒頭の食事会の例でいうと、要望を網羅的に書いてもらっただけで、食事に行ってもいないのにお金を支払うようなものです。
例えどんなに素晴らしい計画であっても、実際に食事に行くことなく計画止まりであれば、まったく価値はありませんよね。

ウォーターフォール開発では、開発プロセスと契約を重視し、要件定義書を納品すれば要件定義工程のゴールなのでそこまでで費用が発生します。
しかも納品した要件定義書の内容は変更できません。
そうすると要件定義漏れは許されず、そのため要件定義に膨大な工数を割くことになります。

一方、アジャイル開発では、そもそも要件というものは、どうせ後で変わるだろうと想定しています。
そのため、最初から漏れなく要件を定義しきること、そして要件定義に多くの工数を割くことに意味があるとは考えません。

さらにもう１つ、ウォーターフォール的な考え方では致命的な問題があります。
それは、顧客と開発者の間でドキュメントを通して共通理解をするのは、思いのほか困難だという点です。
そういった意味でも、アジャイル開発では要件定義に多くの工数は割きません。

その代わりに、プロジェクトの立ち上げ時には、顧客と一緒にユーザーストーリーマッピングというイベントをします。
（絶対にユーザーストーリーマッピングをしなければならない、というわけではありませんが、立ち上げ時にやっておくとスムーズに開発に進めます。）

ケーキの注文は簡単ですか？

ユーザーストーリーマッピングについては次回のストーリーで改めて触れますが、この手法の提唱者であるジェフ・パットン氏による素晴らしい著書『ユーザーストーリーマッピング（Jeff Patton (著), 川口 恭伸 (監修), 長尾 高弘 (翻訳), オライリージャパン,2015年）』を紹介させていただきます。

この本の０章に、「共有ドキュメントは共通理解ではない。」という例として、非常に面白いエピソードが書かれています。
この写真をご覧ください。

この写真はジェン・イェーツ氏による cakewrecks.com というサイトに掲載されているものです。
面白いケーキがたくさん載っているのですが、これも実際に誰かが注文して出来上がったケーキだそうです。
「in Purple」や「Stars」という文字が書かれていて、なんだかヘンテコなケーキですよね。
注文者は、本当はどんなケーキを作ってほしかったのでしょうか。

「in Purple」と書くのではなく、紫色の文字にしてほしかっただけでは。。。
「Stars」という文字ではなく、星マークを散りばめてほしかったのでは。。。
ジェフ・パットン氏の著書は学びが多いので、ご興味ある方はぜひ読んでみてください。

みなさん、ケーキの注文くらいでしたら思い通りにできそうですか？
ケーキ屋さんとの共通理解であれば、そんなに難しくないかもしれませんね。
でも、仕事の場ではどうでしょうか。
我々の顧客は、ITのことなんてさっぱりわからないという企業も多くあります。
我々IT企業にとっては簡単な話でも、それがどれだけ正確に伝わっているでしょうか。

ウォーターフォール開発では、顧客と認識齟齬が起きないように、入念にヒアリングをします。
「ケーキの直径は何cmで、高さは何cmですか？」
「周りの星は、どういった形状ですか？流れ星にしますか？それとも、星型ですか？何個必要ですか？」
と、思いつく限り漏れなく質問します。
そしてやはり、「一度確定したら変更できません。」という制限付きです。

さて、最初に注文する段階で顧客は、すべての質問に答えられるでしょうか。
仮に答えられたとして、専門外の資料を読み解き、内容に合意し、かなりの時間が経ってから出来上がった成品を見たときに、「ずっと前にお願いした通り、欲しかったものが完璧にできて大満足です！」となるシーンを想像できますか？

要件なんて後で変わることもあるだろうし、漏れなく詳細に文章で書いたところで正確には伝わらないだろう、くらいに考えておいた方が現実的だと思いませんか？

アジャイル開発の心得

ここまで、従来のIT 業界ならではの問題点を挙げ、それを改善するようにアジャイル開発では考えているというお話しをしてきました。
長文になってしまったので、読むのが大変だったという方もいらっしゃるでしょう。

ごめんなさい、実は長文にお付き合いいただかなくとも、簡潔にまとめられたものがあります。
最後に『アジャイルソフトウェア開発宣言』というものをご紹介しておきます。

これは、このページの背景にうっすら映っている人たちを含む、ページ下方に名前が掲載されている有識者たちがこれまでの知見を持ち寄り、「本当に価値のある開発とはどういったものだろう？」と話し合った結果生まれたものです。

このページ内の『アジャイル宣言の背後にある原則』も見ておきましょう。
アジャイル開発とは？の答えを要約すると、つまりこういうことです。
ここに書かれている内容は、顧客に満足してもらうことを最優先にして改善を続けていくと、自然となっていく姿なのだと思います。

「アジャイル開発では先の見通しが立たないから契約できない。」という企業もあるでしょう。
ほんの少し前まで、「クラウドサービスは使ってみないと費用がいくらになるかわからないので、社内稟議が通らない。」という企業も多くありました。
ですが、今では多くの企業がクラウドサービスを導入し、その恩恵を受けています。
開発スタイルも、いつまでも従来のままではなく、環境に合わせて進化していく必要があると思います。

我々スタジオ・アルカナでは、共にアジャイル開発チームを結成してくれる仲間を探しています。
ご興味ありましたら、ぜひ気軽にお問い合わせください。

というわけで、今回はアジャイル開発の精神みたいな話で終わってしまいましたね。
次回はもう少し具体的な、アジャイル開発の始め方と進め方についてお話ししたいと思います。
それでは次回、またお付き合いいただけると嬉しいです！

スタジオ・アルカナでは、
一緒に世の中を楽しくする仲間を募集しています！😃

”あったらうれしい”をすべての人へ。

これはスタジオ・アルカナの想いです。
アルカナのスタッフ、またアルカナに関わる全ての人へむけたメッセージです。
こんなサービスがあったら”うれしいな”
こういうことをしてもらえると”うれしいな”
この人と関われると”うれしいな”
アルカナに関わる人達みんなが”うれしい”といいな
この”うれしい”がどんどん広がっていくともっと”うれしいな”

”うれしい”が広まるって、ワクワクしませんか？
アルカナでは、”うれしい”を広めていく仲間を大募集しています！
一緒にアルカナでお仕事してみませんか？

画像：著作者：tirachardz／出典：Freepik