「いちばんやさしいアジャイル開発の本」を読んで

どうも！たけです。
アカウントを作るときに、読んだ本の感想もアウトプットしていければと、考えていたので実践してみようということで書いていきます。
今回はタイトルにもある通り、「いちばんやさしいアジャイル開発の本」という本を読んでみました。
こういうアウトプット作業をほとんどしたことがなく、拙い内容になってしまうと思いますが、やっていきます。

概要

アジャイルっていう開発手法がある、というのは知っていたのですが、じゃあ実際にどんな進め方してくのかってのはよくわかっていなかったです。
ざっくりいうと、
開発→リリース→フィードバック→改善(開発)→リリース…
みたいな感じで短い期間でリリースし、フィードバックを受け、改善するというサイクルを繰り返す方法らしいです。

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

よくある誤解

アジャイル開発のよくある誤解として、以下のものが挙げられているようです。

• ドキュメント不要

• 事前計画なしで開発を進める

結論から言うと、ドキュメントも事前計画も必要みたいです。
確かに、開発のスタンス上で最重要視するものではないみたいですが、かといって不要になるわけではないです。

ウォーターフォール型との違い

今の日本IT業界でも主流なのは、古くからある「ウォーターフォール型」という開発手法かと思います。ウォーターフォール型とは、要件定義→外部設計→内部設計→製造→単体テスト→結合テスト→システムテスト→受入テストと、順番に工程を片付けていって進める手法のことを指します。特徴として、「各工程での成果物が完成品。手戻りが発生しないようになっている」ということが挙げられます。
対して、アジャイル開発では「短期間(スプリントと言います)で動くものが作られ、次のスプリントでは要件レベルから見直す」といった感じでウォーターフォール型を超短期間で何周も繰り返していく感じ、と理解しました。(あってるかどうかわからないですが)

思ったこと、考えたこと

読んでる中で出てきた、「完成した機能の6割は使われない」ということにびっくりしました。半分以上も使われることはないというのは、作った側がわかっているとしたらがっかりするだろうなと思いました。
なんでこんなことになるかというと、「顧客が本当に必要だったものを作っていないから」だそうです。「顧客の要求」と「顧客が必要なもの」が必ずしも同一であるとは限らないということです。そのギャップを埋めるために、要件定義段階でヒアリングを行うのだと知って、なるほどと思いました。

おわりに

「顧客が本当に必要だったもの」というのは、ある絵を思い出しました。

顧客が本当に必要だったもの　の図

出典:<https://www.casleyconsulting.co.jp/wordpress/wp-content/uploads/2019/03/project_comedy_l.gif>

この画像でいう、左上と右下のことですね。
どんな開発手法でも顧客とコミュニケーションが必須だなと痛感します。
これまでの業務で要件定義に携わったことはまだないのですが、今後要件定義をやる際は、この至言を忘れないようにします。
今後も読んだ本の感想は投稿していこうと思います。ありがとうございました。