はじめに
まえがき
この文章はアジャイル開発について学んできたことや，読んできた書籍について印象的だった3冊について書きます．
ウォーターフォール型（WF型）との違いと比較をしたり，私なりの解釈を述べたりします．
おすすめの本やサイトがあったら教えて頂けると嬉しいです．
アジャイル開発とは
アジャイル開発は短期間で反復的に開発を行う手法です．
従来型のソフトウェア開発とは異なる手法を実践していたエンジニアによって起草されたソフトウエア開発におけるマインドセットのAgile Manifesto（アジャイルソフトウエア開発宣言）を機に一般化したみたいです[1]．あくまでアジャイル開発はこのマインドセットを実践する為の開発手法の総称で，代表的なものにはAgile manifestoの起草者の一人であるKent Beck氏が提唱したエクストリームプログラミング（XP：Extreme Programming），トヨタ生産方式を参考に考案されたリーン開発，日本において最も普及しているスクラム開発があります．
これらはチームに合わせて，複数の手法を組み合わせたり，テーラリングをしたりしながら開発をします．
読んだ書籍
アジャイルサムライ
アジャイル関連で最も有名なアジャイル開発の書籍の1つです．アジャイル開発における基本的な事が網羅的に書かれています．画像が多く，簡潔な言葉で書かれているのでわかりやすいです．WF型でいうところの上流工程から下流工程の作業の話になっているので「このフェーズはアジャイルではどうやるのだろうか」といった時にも探しやすいです．
本文中にXPとスクラムの用語についての注意がありますが，著者のJonathan Rasmusson氏がXPの用語の方が好みだそうなので，アジャイルサムライでは以下の言葉の使い方になっています．ここの部分を読み飛ばしてしまうと他の本を読んだ時に混乱するんじゃないかという気がします．
- イテレーション：スプリントのこと
- マスターストーリーリスト：プロダクトバックログのこと
- 顧客：プロダクトオーナーのこと
この本を読んで，著者が伝えたかったことの印象はこんな感じです．
アジャイルな開発の為のマインドの紹介 ＞ プラクティス集
アジャイルの失敗例として，「アジャイル開発を実施したけどWF型と変わらなかった」というような話を聞きますが，アジャイル開発の為のマインドの理解不足が原因の様な気がします．**”誰もがこの働き方を気に入るわけじゃない”**とありますが，アジャイル開発のセオリーを知ってそこに賛同できるか，協力できるかはかなり重要なことじゃないかと思います．
アジャイルサムライ――達人開発者への道 Kindle版リンク
http://www.amazon.co.jp/dp/B00J1XKB6K/ref=cm_sw_r_tw_dp_U_x_Tn6eCbG9RM1D9
カイゼンジャーニー
我らがカイゼンジャーニーです．日本企業でのアジャイル開発のストーリーにそってアジャイル開発のプラクティスを学ぶことができます．ある問題に対してカイゼンするにはこれをしてみようという感じなのでプラクティスの具体的な使用イメージがつかめます．
個人的にはドラッカー風エクササイズで期待のズレを正す部分が好きです．同じ組織内であっても価値観の違いや得手不得手があると思います．なんとなくイメージでできると思っていることや，自分ができるから相手もできるだろうと思っていることは誰でもあると思う（常識という言葉で片付けられる事が多いので見過ごされがち）のですが，そこの違いをきちんとすり合わせをするのは大事なんだなというのが具体的なイメージとしてつかめました．
作中に出てくるゴールデンサークルはSimon Sinek氏のTED[2]を見ました．技術を持っている組織や人ほど技術面をアピールしてしまいがちですが，多くのお客さんが知りたいのはそこじゃないんです．洗濯用洗剤を買うお客さんが知りたいのは，どういう酵素が入っていてどれくらいの菌を殺すかではなくて，乾いた時にふかふかでいい匂いがするかなんですよね．
ソフトウェアの要求の特徴として”段階的詳細化”というものがありますが，プロダクトだけでなく，開発チームの意識や方向性でも抽象的で粒度の大きい項目から検討することが大事だということが分かりました．
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで Kindle版リンク
https://www.amazon.co.jp/dp/B078HZKLMB/ref=cm_sw_r_tw_dp_U_x_vy6eCb3QB53AX
アジャイル開発とスクラム
スクラムについての歴史，概要，プラクティスからアジャイル開発の事例を紹介しています．ビジネス書の形で書かれているので，上記2冊とは雰囲気が違います．
スクラムガイド[3]よりも各項目が1段階詳細に書かれているのでソフトウエア開発をスクラムでやる意味が分かりやすい様な気がします．例えばスクラムガイドでは以下の様に書かれています．
スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
スクラムにおける知識は，著者の一人である野中郁次郎氏が提唱した知識創造経営の考え方が元になっています．有名なものに，文中にも取り上げられているSECIモデル（セキモデル）が挙げられますね．これは知識の発生と成長のサイクルを表現したモデルで，知識が現場で生まれて，共有されて個人に取り込まれて，また新しい知識が現場で生まれることを表現しています．それをこの本ではSECIモデルとスクラムのスプリントの相似性として解説しています．
ここでいう，アジャイルソフトウエア開発の”場”は”チーム”のことで，”チーム”でどうやって知識を獲得していくのか考え，実践していくことが重要なんじゃないかと思いました．
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント Kindle版
https://www.amazon.co.jp/dp/B00DIM66P0/ref=cm_sw_r_tw_dp_U_x_AI6eCb8YR0K01
まとめと考察
今回まとめた書籍はアジャイル開発のマインドセットとアジャイル開発を実現する為のプラクティスについてわかりやすくまとめてあります．その為，アジャイルを知る為にまず読む本としてだけではなく，アジャイルに開発するとはどういう事なのかと考える為にも何度も読み返して，自分の中のアジャイル観を作っていくことが大事なのだと思います．
「なんでアジャイル開発なの？」と聞かれる事も多いのですが，私は**「いいものを楽しく作りたいから」**じゃないかと思っています．これを実践する為の方法やいいものを楽しく作る為の考え方が紹介した書籍や，紹介しきれなかった書籍，論文，サイト…etcだと思います．
これはWF型でできないわけではありませんし，実際にプロジェクトマネジメントの国際ガイドラインであるISO 21500やPMIの発行するPMBOKの開発プロセスにも，継続的な見直しと検討についてほとんどの知識エリア，項目に述べられています．しかし，WF型開発は長らくハードウェア（大きなくくりで形があるもの）の開発の為に利用されてきました．これらは完成した1つの工業製品よりもCADデータ等の設計自体が価値を生み出すものです．一方でソフトウェア開発では緻密な計画書があっても動くソフトウェア開発を実装することは必ずしもできないですよね．
たとえば、君のおじいちゃんとおばあちゃんが、お隣さんの息子に小遣い稼ぎの仕事を頼んだとしよう。（中略）その子が仕事を終えたと頼んだ二人が判断するのはどのタイミングだろうか？
- 熊手をかける計画書を提出したとき
- かっこいい熊手の使い方を思いついたとき
- 緻密な落ち葉回収作業完了確認計画を思いついたとき
どれもありえないよね！落ち葉をすべてかき集め、袋に詰めて家の脇に置くまで、彼が小遣いを手にすることはない。
＿＿＿＿アジャイルサムライ
そうであれば緻密な計画書を作るよりも，実際に動くソフトウェアを実装することに時間とお金を使った方が良いものができるということなんですね．
長くなりましたが，これらが今の私のアジャイル開発の解釈です．
参考文献
[1]Kent Beck，Mike Beedle，Arie van Bennekum，Alistair Cockburn，Ward Cunningham，Martin Fowler，James Grenning，Jim Highsmith，Andrew Hunt，Ron Jeffries，Jon Kern，Brian Marick，Robert C. Martin，Steve Mellor，Ken Schwaber，Jeff Sutherland，Dave Thomas（2001）「アジャイルソフトウェア開発宣言」< https://agilemanifesto.org/iso/en/manifesto.html >
[2]Simon Sinek（2009）「How great leaders inspire action」
< https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action >
[3]Ken Schwaber，Jeff Sutherland（2017）「スクラムガイド スクラム公式ガイド ゲームのルール 日本語版」< https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf >