なぜこの本を読むことにしたか
なぜわたしはこの本を読むために時間を使うのか。
①世界の見方を根底からひっくり返す書物、
②世界の見方の解像度をあげる書物、
③好きだから読む書物
この本は②。最近よく見かけるようになった「アジャイル開発」という用語について学ぶために、初心者向けのこの本を読んだ。
本書の位置付け
アジャイル開発初心者や、ソフトウェア開発にかかわらない人たちを想定した入門書。アジャイル開発とはなにか、なぜこの手法が必要とされるのか、メリットやデメリットはなにかなど、全体像をつかむのに最適。
本書で述べていること
21世紀に入り、ソフトウェアビジネスは「完成品を販売して終わり」ではなく「販売後もアップデートをリリースしつづける＝継続的に価値を向上させつづける」ことをあたりまえに要求されるようになった。
アジャイル開発はこのような時代要請にぴったりあてはまる。すなわち【短期間でフィードバックを受けてすばやく改善することを前提に】（ここが従来と根本的にちがうところ）、まずメインサービス部分ができたところで製品をリリースして、消費者に使用してもらいながら不具合や要望をその都度調整する【短いサイクルで開発とリリースを繰り返すソフトウェア開発手法】である。ちなみに、価値を提供できる実用的で最小限の範囲のプロダクトをMVP（Minimum Viable Product）という。
著者は従来手法とアジャイル開発のちがいを【フェーズで区切る開発と、反復をつなぎ続ける開発】と表現する。いずれの反復後でも、アウトプットとして「動くソフトウェア」ができなければならない。
ウォーターフォールでは各工程での成果物を完成品とみなしており、後工程での手戻りが発生しないようになっています。それに対し、アジャイル開発では一定の期間（スプリント）ごとに動くソフトウェアが作られ、次のスプリントではそのソフトウェアから得られた気づきをもとに要件レベルから見直しが行われます。
アジャイル開発は「インクリメンタル（少しずつ）かつイテレーティブ（反復的に）に作り進める」ものです。
アジャイル開発は技術ではなく方法論。だから、これまでのやり方を変えたくないチームメンバーが「気になるけど時間がない」「いま別に困ってない」「うちの現場に合うの？」など、なんだかんだ理由をつけて、アジャイル開発手法導入を反対する可能性を常に考えなければならない。
なぜアジャイル開発なのか、これまでのやり方のどこを変え、どこを変えないのか、どんな価値を生み出すことが期待できるのか、しっかり説明したうえで、具体的施策に入らなければならないと本書は強調する。
後半は実践編として、アジャイル開発がプロダクト及びチームにどのような変化をもたらすか（もたらさずにはいられないか）を説明し、具体的な取組方法を数多く紹介していく。たとえばチームの成長段階は「タックマンモデル」というフレームワークで「形成期」「混乱期」「統一期」「機能期」と名付けられている、チームメンバーの情報共有のために毎日短い朝会を取り入れる、など、あるべき姿の説明に入る。
感想いろいろ
読んでいてよく納得。
OSやアプリやオンラインゲームなどがしょっちゅうバージョンアップしたり大型実装したりするのに慣れきっている私たちは、不具合があれば開発側にコメントしてなおしてほしいと要望することをあたりまえだととらえるようになったが、一昔前、ソフトウェアがCD-ROMで売られていた時代からは考えられないことであろう。アジャイル開発手法でなければ、このような時代的要請にこたえることはむずかしい。
アジャイル開発はようするにマインドセットにすぎないのだけれど、古いやり方のここが時代遅れだから変えていきましょうと宣言した点で、革新的だ。
そもそもユーザーが自分のほしいものをはっきり言語化できているかというと、そんなことはない。有名な逸話があるではないか。「もし自動車が発明されるまえに顧客にほしいものを聞いていたら、『もっと速い馬がほしい』という回答を得ていただろう」と。著者にいわせるとこうなる。
ソフトウェア開発では、開発した機能のうち6割が使われないという事実があります。これは開発している側が利用者のニーズを把握できていないことや、そもそも利用者自身も自分が本当に必要なものを理解していないことから起こります。
DXには、①ITによりビジネスや生活を変革させていくこと（DX: Digital Transformation (*1) ）と、②ソフトウェア開発者体験の充実（DX：Developer eXperience）の、ふたつの意味があるというけれど、どちらも21世紀になってから生まれた言葉でありながら、いまや知らない人はいないほどとなった。どれほど世の中の動きがはやいのかよくわかる。このような動きについていくスピード重視のやり方こそがアジャイル開発手法だ。
とはいえ後半はいささか理想論にすぎると思う。チームメンバーが自学自習で足りないスキルをみずから身につけるのが望ましいというけれど、それができる人間ばかりを集めることができればどれほど楽か。すくなくとも私はそんなチーム見たことない。やる気のないチームをどのようにしてアジャイル開発に向かわせるかが、いちばんの課題だと思う。
その意味で、第６章が一番読みごたえがある。うまくいかなかったときに試すことができるさまざまな打開策が紹介されているが、「リリース前の問題発覚やトラブルを避けたい」「テストの無駄を解消する」など、ソフトウェア開発現場あるあるの具体的問題を解決することが前提にあるから、とてもイメージしやすく読みやすく、忙しいメンバーにも必要性を納得してもらいやすく、IT以外の業界にも応用出来そうなものがそろっている。
(*1) もともと人間がしていたことをITに置き換えるだけではなく、ITを前提とした新しいプロセスやビジネスをデザインするという考え方。具体例としては、いわゆる「従来業界を破壊するイノベーション」であるNetflixやUber、Airbnb、近年ではブロックチェーン技術を利用した仮想通貨など。たとえば遠隔操作前提の工場を建設することもあてはまるであろう。
