そもそもなぜアジャイルなのか？
なぜアジャイルは生まれたのか？
さて、アジャイルってなんでしょう？
ここでは「なに？」ではなく「なぜ？」にフォーカスして書いてみようと思う。
「なぜ？」を知るためには歴史を紐解くのが一番手っ取り早い。
アジャイルという言葉が生まれる前、ソフトウェア開発者は多くの課題に直面していた。
例えば、
最初の見積が不鮮明！ いつ終わるのかわからないけどスケジュールだけは決まり、結局開発期限守れない！
ギリギリまで開発しているからテストする時間ない！ バグだらけ！
仕様変更要望などのフィードバックが開発後半に絶対来る！ 今言うなそれ！
頻繁に減っていく・もしくは入れ替わっていくメンバ！ 生産性激落ち！
など、分かる人なら「わかるわ～」って感じになると思う。これが1990年〜200年代初頭の爆発的にインターネットが普及した時代の頃あたりかな。まぁ今も根強く残ってると思う。
こういう課題解決のアプローチとして、分析や設計・開発・テストという一連の開発プロセスをミニマムにかつ高速に繰り返す反復的な手法、メンバとの密なコミュニケーション、顧客と開発チームの連携、柔軟な計画変更、モチベーションの維持スタイル……などの考え方が生まれ、XPやスクラム、FDD、ASD……といった開発手法として形作られていった。
そしてこれらは従来の例えばウォーターフォール型の開発の考え方とは大きく逸脱したもので、「俺らに何か共通点あるんじゃね？」ということで様々な開発手法を主導的に用いてきた開発者が集まってつくられたのが、アジャイルソフトウェア開発宣言だ。
そう、アジャイルソフトウェア開発宣言は後から作られたものなのだ。これが2001年頃の話。
これもググっていただければ……と思ったが、コピーOKだし、宣言自体は短いものなので、ここにも書いておこう。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
アジャイル開発、という手法は存在しない。
開発手法は多くのソフトウェア開発者が試行錯誤の上で生み出したノウハウだ。そして個々に長年悩み抜いた末に、そういった開発者が集まってたどり着いた本質的な思想だ。見出しにも書いたようにアジャイル開発という手法は存在しない。この考え方に基づいた、様々な開発手法があるわけだ。
アジャイルソフトウェア開発宣言が生み出されて20年。この思想は変わらず重要な考え方として根付き続けていることが本質的であることの証左であるとも言えるんじゃないかな。
なぜアジャイルなのか？
ウォーターフォール的アプローチでは特にインターネットなどのハイスピードで変化する領域では、前述したような課題に直面して上手くいかなかったからだ。
膨大な情報に埋もれ、あっという間に変わっていくこのご時世、柔軟に対応できなければいけない。そのためのかなりプリミティブな考え方がアジャイルソフトウェア開発宣言だ。
悩ましいのは、決して「こういったやり方をすればOK」といった決まったものがあるわけではないところ。変化に対して柔軟に対応するためだから当然といえば当然だが、
作る対象がソフトウェアなのかハードウェアなのか
そもそもITなのかそうではないのか
人数はどのくらいなのか
会社でのチームワークなのか、個人制作なのか
ターゲットは誰・どこなのか
等々、人によって環境は千差万別。根っこの考え方を忘れないように、やり方を試行錯誤していくしかない。
また、自分はスクラムをベースに取り組んでいるのでよく見てるが、スクラムガイドは不定期にアップデートが繰り返されている（最新版は2020年11月）。アジャイルソフトウェア開発宣言ができる前に生まれて、開発手法も変化し続けているわけだ。
なんでもかんでもアジャイルでいいわけではない
逆にいえば、そういう状況でなければアジャイルはハマらないとも言える。
自分は経験がないので確かなことではないけれど、例えば建築物、ビルなどの巨大なものだったりしたとき、設計と実作業と試験を少しずつ並行して進めて変化しつつビルを建てるというイメージは湧かない。内装はともかくとして、ちょっとしたズレやミスが許容されない領域だと思うので、こういったところは入念な準備が必要でウォーターフォール的なプロセスの方が良さそうだろう。昔のドキュメンタリーか何かで見たことがあるが、東京タワーの建築時の話で下の方で数mmズレると上の方でとんでもないズレになるから大変、みたい話だった。こういう変化は後からは許容し辛い。
あと個人制作の場合もマッチしないかもしれない。コミュニケーションやチームワークが前提であったりするので、シナジーが生じにくい。とはいえ、反復的なプロセスという面では個人でも活用できる面はあるので、まったくの無意味にはならないかもしれない。
よくある話
偉い人が「最近はスクラム開発というものを使えば安くて早くて高品質なものができるらしいじゃないか、うちもやってよ」みたいな感じで始まるとかなり危険だ。
とりあえずやってみる、というのは大事だし素晴らしいスタートだけど、根っこの考え方であるアジャイルソフトウェア開発宣言を忘れてはいけない。
とりあえずスクラムでやってみる。スプリント期間決めて、プランニングして開発して、でも、ふりかえりはそれほどやらない。とかよくある話だ。スクラムマスターやそれに類する考え方を持った人がいないとたぶん失敗する。
そうならないように立ち回るのが難しいのだが……そういったところを非エンジニア視点で、今後書いていこうと思う。
今回の参考書籍はこちら
こちらは新版で、旧版持ってたけど、追加分があるということで買ってみたが……すでに旧版読んだことある人や、アジャイルやスクラムやっているよ、という人は無理に読まなくてもいいかもしれない。
この記事が気に入ったらサポートをしてみませんか？