アジャイルソフトウェア開発についての本が出てから、もう9年ぐらいになります。この間、いろいろな本が出されていてアジャイルソフトウェア開発だとか、アジャイルテスティングだとかアジャイルデータベースとか、言葉は色々出てきています。じゃあ、アジャイルの本質って何なんだろうか？というのを僕なりにまとめてみました。「コミュニケーション中心だ」とか、「人間中心だ」とかいろいろありますが分析するだけではなくて、ソフトウェア以外の他の業界にも役に立つような知識を提供するのがこのエントリーの目的です。アジャイルは他の業界に輸出されるべき、価値のあるモノだと思っています。
僕の考えるアジャイルの本質は「人間の弱点に合わせた仕事をする」言い換えると「無理な管理はしない」ということにつきます。逆に、旧来の(ウォーターフォール)と呼ばれる開発手法の問題の本質は「人間の弱点を管理しようとする」と言えるかな、と思います。後者についてはきちんと考え抜いてませんが。
未来を予測しない
アジャイルソフトウェア開発では、2週間とか、1ヶ月と言ったスパンでの見積もりや設計しかしません。設計はタイミングを見計らって途中でどんどん変えていきます。仕様書はあまり書きません。××設計書みたいなものを書くことは推奨されていません。もちろん学術的に複雑なアルゴリズムなんかは書く必要あると思いますが。
旧来の方法と何が違うかというと、「未来を予測する」ということをムリにしないんですよね。多少はします。ユニットテストを書くのは数分後の未来の予測だし、少なくとも1ヶ月後に向けた設計はします。それに比べて、旧来の方法は年単位で予測をします。旧来の方法では精度が問題になります。そりゃ、期間が長ければズレも大きくなりますからね。仕様を出すユーザ側も大変です。「この機能とこの機能が××年後に実装されたら、作業の効率が××％改善される」なんて遠い未来の予測の上での意志決定が要求されますから。予測に失敗すると、「精度が悪い」と叩かれるわけです。日本の優秀なベンダーは先に予測されることを提案するわけですが、判断が難しいことには代わりありません。
未来を予想するなんてこんな難しいことはありません。恋愛経験がある人は当然ご理解していると思いますが、思い通りになんてなかなか行かないですよね。アジャイル開発は、この難しいことをしなくてもいいようにしているわけです。
失敗を許容する
失敗はあります。ちょっとアルゴリズムを書き間違うとかね。アジャイルソフトウェア開発はテストを先に書くようにすることによって「ちょっとしたミス」はその場で見つけるようにします。設計もあまり先々のことを考えずに、「今できること」のみをやっていきます。今に対して未来が変わってしまったら、リファクタリングということで、そのときに修正します。アジャイルソフトウェア開発では、これは失敗とは言いません。
旧来の方法では未来は予測できている「はず」なので、大きな失敗はないことになっています。それでもテストはします。テストの期間は見積もられているけど、修正の期間は見積もられていません。テスト期間が多めに見積もられていて、その中でこっそり修正します。でも、それでも品質が保てないので、見つかったバグ数を曲線で管理します。収束したら完了らしい。数を数えたって、修正しないと意味ないのに、その場合の修正の工数をどうするかという議論は聞いたことがありません。作業工数に入っていないということは、帰りが遅くなったりするんだと思います。
無駄な管理はしない
上記の二項目が守られるとどうなるか？アジャイルは基本的に管理をしないでも、自発的に進むようになっています。ただし、すべてが「適当でいいや」では崩れてしまいますので、アジャイルソフトウェア開発では「イテレーション」という期限を決めています。この中で「アウトプットを出す」というのが求められています。逆にこの一番シンプルなゴールに向かってがんばるので、自発的でも結果が出ます。試験前には勉強する、ということと一緒ですね。あまり無理なゴールは逆効果ですが、アジャイルではこのゴールを決めるのにも開発チームが関与します当然ここはユーザとのやりとりも発生します。また、仕事の仕方も「振り返り」を行って徐々に自発的に改善していきます。
旧来の方法では、開発作業をするのは下々のモノです。上の人が設計を書きます。その設計に従って作業をします。上下関係があるので、きちんと決まった仕事が行われているか管理が必要になります。チーム体制や仕事の仕方が劇的に変わることはまれです。よっぽど進行に問題があるとかでテコ入れが無い限りは。管理に必要なため、ドキュメントが書かれます。「仕様は勝手に決めてね」では管理できませんからね。この境目のところで他の会社に外注されることもあります(むしろ多い？)。上下が分かれているので、バグとかがあったら長いリストを作成して管理されます。当然、こうなると実装時のフィードバックが上に行くことはまれです。設計だけ書く人は現物から学ぶ機会を喪失していると思います。
まとめ
この文章でアジャイルが「人の弱点にフォーカス」した、というのが理解されたかどうか分かりませんが、僕が考えるアジャイルはこの視点です。この弱点となっている能力にストレスをかけないで、全体の仕事の流れをここに合わせる、というのはきわめてTOC的な発想と言えます。
旧来の方法は弱点を「つぶす」という視点です。弱点を管理すれば底上げされて品質あがるでしょ、という発想です。ただ、ムリに底上げをすると、逆に効率曲線下がってしまうこともあります。もちろん、この手法でなければならないものもたくさんあります。写真を引用しましたが、軍隊はこの例に当てはまります。そのために弾道起動予想、衛星など、あらゆるリスクを考慮してお金を大量にかけて、計画を行います。軍隊が実際に動く場合もトップダウンで動くことが求められます。現実の厳しさが人間の能力を遙かに超えるからです。それだけコストやストレスをかけても損をしないのです。
ザ・ゴールが印象的なため、TOCでは「ボトルネックの改善」というのが本質だろうと思う人が多いのですが、TOCのドラム・バッファ・ロープの手法としては「ボトルネックに全体を合わせる」というのが「ボトルネックの改善」の前に発生します。旧来方法はTOCのステップを一つ無視しているわけです。そのためにひずみが発生するんです。
管理をする、ということから、管理そのものが必要ない世界へ。これが僕がアジャイルに見えるメカニズムです。
補足
あんまり清書とかしてないので、内容はつっこみどころとか多いかもしれません。もちろん、人によって定義とか違うと思うし、この手の定義とか分析とかの話は反論が出ても、相手の意見に耳を貸さないで意見だけが書かれてすれ違ったまま平行線ということも多いので、ウェブ上で議論する気はありません。気になる方は飲み会にでも誘って下さい。
