包括的なドキュメントよりも動くソフトウェアを

次は「包括的なドキュメントよりも動くソフトウェアを」です。

動くソフトウェアとは何でしょうか？

動くソフトウェアなわけですから、エンドユーザーが UI を通して情報をインプットし、それが処理され、エンドユーザーが UI を通してアウトプットを受け取る一連のプログラムの集合体だと考えられます。

宣言の中に「動くソフトウェア」が謳われている以上、動くソフトウェアが存在しない間は何を開発していたとしてもアジャイルマニフェストに沿っていないわけですから、自ずとこの宣言からは、できる限り早く、動くソフトウェアを獲得しなければならないという動機が生まれます。

それが転じて、アジャイル開発は短いイテレーションを何度も繰り返し、動くソフトウェアを作り続ける開発方法となったと考えます。

短いイテレーション

アジャイルで作る動くソフトウェアは、UI、インプット、処理、アウトプットが伴う一つの完結したプログラムの集合体です。

また、アジャイルのプロジェクトは、設計、実装、テスト、リリース、分析が伴う一つの完結したサイクルの集合体です。

アジャイルでは、そのプログラムを短いイテレーション毎に作成し、そのサイクルを短いイテレーション毎に回します。

これによって、自ずとある法則の恩恵を受けることになります。

量質転化の法則

量質転化の法則という自然界でも観察される普遍的な法則があります。

これも先のチャプターでも紹介したドイツの哲学者であるヘーゲルが定式化した法則で、ある一定限度を超える量が発生すると、限度を超えた時に質に転化する（またはその逆）という法則です。

例えば自然界では水の温度が向上し続けると、100℃を超えた時に気化するという現象があります。

人間社会においても、モノの生産力を上げるために様々な道具や手法が開発・発明されていく中で、あるタイミングで蒸気機関という発明が生まれ、生産力が格段に向上したという現象 (産業革命) がありました。

これは量が質に転化 (生産方法) し、質が量にも転化 (生産能力) した例となります。

何かを新たなことをマスターしたい場合は、それを習得するための勉強や練習に1万時間費やせば良いという1万時間の法則というものがあります。

これは量質転化の法則のある種の言い換えで、量質転化の法則が存在することの証明にもなっていると思います。

私自身も量質転化の法則の恩恵を受けたことがあります。

私は現在かな入力使いなのですが、元々はローマ字入力で、それなりの速度でタイピングできる人でした。

ただ、もっと早く文字入力したい、(英語のスペルをローマ字的に間違えるのが格好悪いから) 英語と日本語を分けて捉えるようにしたいと思い立って、かな入力の習得することにしました。

ただ、かな入力の習得はかな入力を使わなければ当然達成できないものなので、休日だけかな入力するということではかな入力の練習量が足りません。

そこで、仕事を含めたすべてのキーボード作業をかな入力に切り替えるという縛りプレイを断行しました。

かな入力する機会の絶対量が増えた結果、どこかのタイミングで指が自然と動くようになるという質の転化 (手続き記憶化された) が起こり、かな入力が習得できました。¹²

これは脳の仕組みからも証明できることなので、多かれ少なれ、みなさんも何かで経験していることだと思います。

話がかなり脱線しましたが、短いイテレーションで動くソフトウェアを開発し続けるということは、ウォーターフォールでのソフトウェア開発と比較して、完結したプログラムを開発すること、完結したサイクルをこなすことの絶対量が増えることに繋がります。

すると、あるタイミングを境に、手早くプログラムを書き上げることができるようになったり、良い設計を思いつくようになったり、以前読んでも意味や意義が理解できなかったプログラミング手法の原理・原則などが容易に理解できるようになるという現象を引き起こします。

短いイテレーションの中で動くソフトウェアを作り続けることを繰り返すことで、量質転化の法則の恩恵を受けやすくなるのです。

ソフトウェアとの相互作用

動くソフトウェアはある種の物質です。哲学の世界に唯物論という考え方があります。(それと反対の唯心論という考え方もあります。)

唯物論は物事の根源には物質があり、精神的現象はその物質の作用から派生したものであるという考え方で、唯心論は物事の根源には精神があり、物質はその精神の作用から派生したものであるという考え方です。

アジャイルでは動くソフトウェアをソフトウェア開発活動の中心に据えますので、唯物論的な考え方と親和性が高いと考えています。

動くソフトウェアが世に出ると、エンドユーザーがソフトウェアを触れることで、テストでは発見できなかった不具合が見つかったり、不足している機能や有効に使われていない機能がわかったりします。

物質の振る舞いによって、考えに変化が起こり、次の行動が促されることになるため、唯物論的です。

唯物論はまた、科学的な態度や振る舞いを生みます。

動くソフトウェアにおいて、リリース後に発見する不具合や不足、またユーザーから届くクレームや要望などは実際に観察できる経験的事実です。

動くソフトウェアを活動の中心に据えることで、経験的事実に基づいて仮説を立て、実装し、リリースして、定性的または定量的に仮説を検証するといった科学的な行動が生まれます。

その結果、合理的かつ効果的な開発ができるようになります。

経験主義であるとよく言われるスクラムも、このような科学的態度や振る舞いがプロジェクトの運営においても重要なものであると捉えています。

これはある種、動くソフトウェアと個人やチームとの相互作用とも言えます。

したがって、この本では、最初の原則における相互作用は、ソフトウェアとの相互作用をも指すものであると拡大解釈することにしました。

Individuals を、個人だけではなく、ソフトウェアやチームといった概念にも対応できるように「個」と訳して、全体を「個との相互作用」と訳すことにしました。

そして、チームとソフトウェアという関係にも弁証法的発展が生まれる場合があります。

ここでも架空の例を上げてみましょう。

ある企業のトップが製品開発チームに対して、社会的なインパクトのある製品を開発することを命令しました。(テーゼ)

製品開発チームは少数精鋭ではあるものの、社会的にインパクトのある製品を作るには能力が不足していると自覚していました。(アンチテーゼ)

そこで、その企業のトップは、成果にはちゃんと報いていくことを約束し、継続的に良い製品になるよう取り組み続け、最終的に社会的なインパクトのある製品を世に出せれば良いと提案しました。(アウフヘーベン)

製品開発チームは小さな成功を積み重ねていく過程で、給与やボーナスといった形で取り組みに対する報酬を得ることでモチベーションが上がったり、研究開発の予算が確保されたりや優秀な人材をメンバーに迎え入れることができたりするようになって、遂には社会にインパクトを与える製品を世に生み出すことができました。

これがチームとソフトウェアの相互作用によって、チームとソフトウェアが弁証法的発展を遂げる例です。

この原則から学べる仕事をするうえで大切なこと

最後にまとめます。

この原則からは、自分の仕事の質を向上させるためにはまずは量をこなすこと、経験的事実を基に仮説を立て、行動、検証する科学的な態度や振る舞いを学ぶことができます。