はじめに

どのように仕事に取り組めば良いのか、仕事をする上で大切なことは何か、筆者は自問しました。

ある時、ふと、アジャイルマニフェストを読み返してみたところ、アジャイルマニフェストは未だ示唆に富むものであることに気づきました。
さらに言えば、仕事をする上で大切なことがほとんど詰まっているのではないかということに気づいたのです。

この本では「仕事をする上で大切なことはすべてアジャイルマニフェストから学んだ」と題し、アジャイルマニフェストを筆者がどのように解釈し、仕事をする上で大切な何を身につけることができると理解したかを、普遍的な法則や例を踏まえて解説していきます。

この本は最後のアジャイルマニフェスト原文を除き CC BY-SA 4 でライセンスします。

アジャイルマニフェスト原文に関してはアジャイルマニフェストの著作権に従ってください。

筆者紹介

はじめまして。私は株式会社永和システムマネジメントの Agile Studio でプログラマとして働く 東 大樹 (HIGASHI Taiju) と申します。

現在はプログラマとして生計を立てているものの、その過程では紆余曲折がありました。

諸般の事情 (主に自分に起因する事情ですが) により、高校から大学に進学することをしなかったのですが、その後の無計画が災いし、案の定フリーターになってしまいます。

フリーターでは将来設計のしようもなく、お先真っ暗でした。まさに人生＼(^o^)／ｵﾜﾀです。

何かしら現状を打開しなければならないと考え、これまで本を読む習慣もなかったのですが、生きていくためのヒントを求めて、自己啓発書やビジネス書を読み漁るようになりました。
また、当時インターネットが使える環境が整ったため、インターネット上の記事もたくさん読むようになりました。

そんな中、転機となったのは、エリック・レイモンド氏によって書かれ、山形浩生氏によって日本語に翻訳された「ハッカーになろう」という文書との出会いです。

この文書を読んだことで私の中にハッカーへの憧れが生まれました。
また、ハッカーになるための道筋を理解しました。

ただし、当然、この文書を読んでプログラミングをちょっと勉強しただけでプログラマになれるわけではありません。

HTML や CSS を勉強したり、GNU/Linux をコンピュータにインストールして使ってみたり、最初に学ぶべきプログラミング言語として推奨されている Python を勉強したり¹、
また良い物書きでもありたいと思い、ブログ等で情報発信したりを続けながら、パソコンインストラクター、Web 制作会社の企画営業など、少しずつポジションチェンジを試みて、ようやくプログラマになることができました。

そして、プログラマとして何社かの転職経験を経て今に至ります。

もし、将来プログラマになりたいと思っている人で、これを読んでいる人がいれば、「ハッカーになろう」はプログラマになるための指南書として今も有効な文書であることを私が自信を持って保証します。

とは言え、ハッカーへの道のりまだまだ遠く、未だ道半ばではあります。

名実ともにハッカーと他者から認められるような人間になるべく、今も日々奮闘しています。

アジャイルマニフェストとは

アジャイルマニフェスト (アジャイルソフトウェア開発宣言) とはどのようなものなのでしょうか。

Wikipedia は下記で説明しています。(2021年8月現在)

2001年に、アジャイルソフトウェア開発手法 (当時は軽量ソフトウェア開発手法と呼ばれていた) の分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した。 そして、彼らは「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development) という文書にまとめた。 アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている。 アジャイルソフトウェア開発

次に、アジャイルマニフェストの具体的な内容を下記に引用します。(全文は最終チャプターに掲載)

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

非常に短い文書ですね。
実質的には4行の文章です。
これのどこに仕事をする上で大切なことが詰まっているんでしょうか。

憲法と法律

アジャイルマニフェストは言わばアジャイルソフトウェア開発における憲法のようなものです。

その考えに沿うと、アジャイルの手法のひとつであるスクラムは法律で、XP で推奨されているペアプログラミングなどの具体的な手法は、さしずめ条例と言ったところでしょうか。

法律は憲法を土台にして作られるルールです。

憲法に反した法律は作ることができませんし、仮に憲法が変わるようなことがあっても、法律はそれに合わせて調整されてしかるべきです。

ただし、これは単なる比喩です。

実際にはスクラムを実践しながらアジャイルマニフェストに違反することはできてしまいますし、当然ながら罰則もありません。

ただ、それはやはりアジャイルとは言えないのではないか私は思っています。

原理・原則

アジャイルマニフェストはアジャイルソフトウェア開発における原理・原則でもあります。

私は原理・原則といった類や格言といった類が好きです。

歴史に名を残した偉人、宗教家、詠み人はわからずとも口伝されてきたことわざなど、原理・原則や格言は短い文章で真理を突いている上に、解釈に幅があります。

一見言わんとすることがよくわからない文章であっても、自身の知識や経験に照らし合わせて解釈すると、腑に落ちるということがあります。

その解釈が原理・原則を作った人の意図と異なるものであったとしても、自分なりに自身の知識や経験を照らし合わせて解釈したものなのであれば、それはその当人にとっては正しい解釈であり、自分のものとなります。

他者がどうこう言おうが、あなたにとっての原理・原則はあなたが解釈した内容で正しいのです。

この本は筆者なりにアジャイルマニフェストを解釈した結果、仕事をする上で大切なものがすべて学べたという内容について述べています。

したがって、縮小解釈も拡大解釈もあると思いますし、誤解釈もあると思います。

ただ、読者が何かしら共感できるものに仕上がっているのではないかと私は信じています。

次のチャプターからは、アジャイルマニフェストマニフェストの各宣言を一つずつ取り出し、筆者がその宣言をどのように解釈して、「仕事をする上で大切なこと」としての学びを得たかを一つずつ解説していきます。

プロセスやツールよりも個人と対話を

まず始めは「プロセスやツールよりも個人と対話を」です。

アジャイルソフトウェア開発では、対話によってコトが進んでいきます。

私はこの宣言がアジャイルマニフェストの根幹を担う最も重要な宣言だと思っています。

interaction

日本語版では「個人と対話」と訳されていますが、私はその原文に着目しました。原文を下記に引用します。

Individuals and interactions over processes and tools

特に対話と訳された部分は interactions という英単語が用いられていることが確認できます。

日本語の対話という単語に対しては、dialogue という英単語もあります。

しかし、この宣言文の中では dialogue という単語は用いておらず、interaction という単語を選んでいます。

私はここに作者の何らかの意図があるように感じ取りました。

interaction という英単語は複数の語源で構成された英単語です。

inter- が「間の」で、act が「行う」、-ion が「こと」「もの」といった語源になります。

各語源の意味を組み合わせると、interaction の和訳でよく用いられる「相互作用」という意味が浮かび上がります。

日本語では対話と訳されているものの、対話は相互作用の一つの方法であって、この宣言で言う interaction とは、もう少し幅のある意味を指しているのではないかと私は感じましたので、この本の中では対話ではなく、相互作用と訳し、拡大解釈することにします。¹²

無知の知または不知の自覚

古代ギリシャの哲学者であるソクラテスは、デルポイの神託にて、「アテナイにおける一番のソフィスト（知者）はソクラテスである」という託宣を受けました。

しかし、ソクラテスはその託宣を受けて「知らないことがたくさんある私が一番の知者であるはずがない」と考えました。

ただ、ソクラテスは気づきます。

「知らないことを知っている」ことが知者である条件であると。

同じく東洋でも、論語の伝えるところによれば、これとほとんど同じようなことを、孔子が言及していたようです。

之を知ることを之を知ると為し、知らざることを知らずと為す。是知るなり。

対話をすることによって、不知を自覚できます。

自分の知らないことが相手から学べたり、知らないこと、学ぶべきことを知ることができます。

私は高卒で社会人になり、運良く知識労働者になりましたが、学歴という足かせが、「私が社会で出会うすべての人々は総じて私より優秀である」という前提に立たせてくれました。

それが、不知を自覚させ、プログラミングを始めとして、多くのことを学ぶ動機をもたらしてくれていたことに後になって気付きました。

不知の自覚をしているにも関わらず、他者に教えを乞わないという態度は「聞くは一時の恥、聞かぬは末代の恥」ということわざでも諌められている通り、褒められたものではありません。

自戒の念を込めて言いますが、自分が知らないことについては、相手に教えを乞う姿勢も大切だと思います。

余談になりますが、私が以前携わっていたプロジェクトで、ソクラテスのようなスクラムマスターのいるプロジェクトがありました。

彼は何か問題が発生した時に、その課題を解決するための答えを決して言わない人でした。

「なぜそう思う？」「どうしたら良いと思う？」という問いをひたすら投げかけ、チームメンバーに答えを考えさせました。まさにソクラテスの問答のようなものです。

「あの人は答えを知ってるのに教えてくれないから、時間が無駄になる」といった批判も出たことはあったものの、その当時はいろんな問題についてよく考え、チームで議論し、チームなりの結論を出し、日々脳みそに汗をかきながら仕事に取り組んでいました。

振り返ってみるとあのプロジェクトに携わるメンバーは、皆が生き生きしていたと感じます。

そのプロジェクトを通して、対話をうまく活用するとプロジェクトに息が吹き込まれるということを知りました。

弁証法

次に弁証法という対話の手法について紹介します。

弁証法は哲学の分野で生まれた言葉で、ドイツの哲学者であるヘーゲル (1770年-1831年) によって定式化された手法のことです。

ある命題 (テーゼ) が与えられた時に、そこに含まれる矛盾が、否定の命題 (アンチテーゼ) を生み、両者が抱える矛盾を克服 (アウフヘーベン) した高次な結論 (ジンテーゼ) が導き出されるというものです。

この三者の関係のことを弁証法的関係とも言います。

さらに弁証法におけるこれらの関係は 1 サイクルで完結するものではなく、ジンテーゼが新たなテーゼとなり、新たなアンチテーゼを生む、と言った具合に螺旋的に発展していくものであるとされます。

このことを弁証法的発展と言ったりもします。

具体的な例をあげてみましょう。

最近 PMBOK 第7版が話題になったことが記憶に新しい³ですが、これを弁証法に当てはめてみましょう。

まず、第6版までの PMBOK、つまりウォーターフォール的なプロジェクトマネジメントの方法論をテーゼとします。

そこに、計画通りには物事は進まないというメッセージと共に、アジャイル的なプロジェクトマネジメントが生まれました。

これが PMBOK に対するアンチテーゼです。

この両者の方法論が総合され、高次な結論 (ジンテーゼ) として生まれたものが PMBOK 第7版です。

弁証法的発展で捉えると、アジャイルもまた PMBOK 第7版と相互作用し、さらなる発展の可能性を残している可能性もありますし、両者の矛盾を克服した、まだ発見されていない新たなプロジェクトマネジメント手法が生まれる可能性もあります。

重要なことは、弁証法を使って何かの命題に対して高次な結論を導くためには、アンチテーゼが必要であり、そこで止まることなく、考え抜き、新たな解決策を模索する必要があるということです。

アンチパターン

「私達はスクラムを実践しているので、アジャイルを実践しています。」と言ったり聞いたりすることがあります。

先のチャプターで書いたとおり、アジャイルマニフェストが憲法であるならば、スクラムは法律です。

単にスクラムを実践しているだけではアジャイルとは言い難く、スクラムの各スクラムイベントが、対話を促すイベントになっていなければ憲法違反²とも言えるでしょう。

アジャイルマニフェストを尊重していない形だけのスクラムは「個人と対話よりもプロセスとツールを」になってしまっているのではないでしょうか。

以前携わっていたスクラムを実践しているプロジェクトでこんな話がありました。

ある日、アジャイルコーチとして外部に派遣されることもある先輩社員が、そのプロジェクトのデイリースクラムの様子を遠くから見ていました。

そして近づいてきて一言、「お通夜みたい」とその様子を揶揄しました。

「そんなスクラムならやめてしまえ」ということを言いたかったんだと理解しました。

その後、このプロジェクトではその反省も踏まえ、様々な改善を取り入れて対話が生まれるようになり、皆が自分の意見を言える心理的安全性の高いプロジェクトへと変革しました。

対話のないスクラムというアンチパターンです。

個人との相互作用

話を相互作用に戻します。

相互作用とは相互に作用するわけですから、個人の一方、または両者が受け身では成立しません。

他者の考えや行動があなたに作用するだけでは相互作用とは言えず、あなたの考えや行動を他者に作用させて初めて相互作用と言えます。

相互作用は弁証法的発展を生みだすキッカケになります。

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

スクラムなどでよく言われるように、プロジェクトを成功に導くためには、チームメンバーそれぞれがクロスファンクショナルな人材でなければならないという命題が与えられました。

チームメンバーの A さんは、フロントエンドは得意なものの、バックエンドは全然できなくて、逆に B さんはバックエンドは得意なものの、フロントエンドは全然できません。

これはクロスファンクショナルな人材でなければならないことに対する矛盾であり、アンチテーゼとなります。

この両者の矛盾を解決するための解決策を考えます。

例えば、しばらくの間、A さんと B さんとでペアプログラミングを実施し、お互いの得意分野を互いに教えながら仕事に取り組むという解決策があります。

この解決策がアウフヘーベンとなり、プロジェクトは前に進みつつも、A さんと B さんは互いに不得意な分野をある程度こなせるようになりました。

個人と個人の相互作用によって、個人同士が弁証法的発展を遂げる例です。

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

最後にまとめです。

この原則からは、自分の意見を効果的に相手に伝えることができ、相手の意見に耳を傾けることができる、自律的で他者を尊重できる人間になることを学ぶことができます。

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

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

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

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

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

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

短いイテレーション

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

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

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

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

量質転化の法則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後にまとめます。

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

契約交渉よりも顧客との協調を

次は「契約交渉よりも顧客との協調を」です。

この宣言はアジャイルマニフェストをアジャイルマニフェストたらしめている最もユニークな宣言であると考えています。

顧客は仲間

「アジャイル宣言の背後にある原則」には顧客に関する原則として下記の文章が掲載されています。

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

https://agilemanifesto.org/iso/ja/principles.html

遠回りではあるものの、暗に顧客は仲間であると謳っている点がアジャイルマニフェストのユニークな点です。

顧客の視点

「所変われば品変わる」ということわざがあります。

土地が違っていれば、風俗や習慣が変わってくるという意味のことわざです。

そこから「立場違えば景色も変わる」といった派生した言葉も生まれています。

例え日々一緒に働いていたとしても、顧客を取り巻く環境は、開発者を取り巻く環境とは異なるものです。

ただ、達成するための手段こそ違えど、アジャイルでは動くソフトウェアを通じて同一の目的と目標を共有します。

アジャイルマニフェストで言う価値のあるソフトウェアとは、ビジネスや社会にとって価値のあるソフトウェアのことです。

価値のあるソフトウェアを作るためには開発者の視点に加えて顧客の視点も必要です。

顧客と共に働くことは顧客の視点を獲得するチャンスであり、ビジネスや社会にとって価値のあるソフトウェアとは何かを知るチャンスです。

幸い私はパソコンインストラクター、Web 制作会社の企画営業などの職種も経験していたことがあり、顧客に最も近い立場で仕事をしてきた経験があります。

顧客からのフィードバックを直接受けることができたり、顧客が求めていることを考えたり提案したりすることを経験すると、自分に欠けている視点があることに気付かされます。

ところがプログラマになってみると、そのような環境は当たり前の環境ではないということがわかりました。

顧客と全く関わらない現場が想像以上に多かったのです。

また、私は顧客に寄り添えるプログラマであると自負していたものの、顧客から離れて仕事をし続けると、美しいプログラム、綺麗なアーキテクチャ、最先端の技法など、必ずしもビジネスや社会にとって価値があるとは言い切れない部分に傾倒したり、顧客が理解できない専門用語を多用するようになる傾向が出てきました。

今は顧客側に技術に理解のある人や技術者が増えてきていることもあり、それであまり困ることはなくなってきていることは事実ですが、どのアジャイルの現場でも第一線で活躍しようと思った場合、顧客の立場に立って物事を見たり、プレゼンテーションする能力も失ってはならないと思います。

顧客との距離が遠い期間が長くなると、顧客の気持ちがわからなくなっていく恐ろしさを感じました。

顧客との相互作用

最初の宣言に戻りますが、相互作用の範囲には顧客との相互作用も含まれます。

また、繰り返しになりますが、顧客の御用聞きをするだけでは相互作用とは言えません。

顧客に対して考えの変化や行動の変化を促せるようになって初めて相互作用と言えます。

最近、羽山祥樹さんが書かれた『「顧客の声を聞かない」とはどういうことか』というスライドが話題になりましたが、顧客との相互作用を起こす上でのヒントが詰まっているスライドだと思いますので、ぜひご一読ください。

顧客との相互作用の中心にも動くソフトウェアがあります。

開発者視点だけでは見失われがちではありますが、その前提に立つと、SLO (サービスレベル目標) やビジネス KPI (重要業績評価指標) などの目標や指標を顧客と共に科学的に分析できるようにソフトウェアを設計・実装することも非常に重要な取り組みであることに気づきました。

開発者と顧客にも弁証法的発展が生まれる場合があります。

架空の例を上げましょう。

顧客は製品を成功させるために、すでに成功している例の多いモデルを模倣したソフトウェアを作りたいと主張しました。(テーゼ)

開発者はこれに対し、まだ世に出ていない新しいテクノロジーを基本とした製品が成功する製品であると主張しました。(アンチテーゼ)

両者の矛盾を解決するために、最も重要な機能には新しいテクノロジーを導入し、それ以外はすでに成功しているモデルを模倣することにしました。(アウフヘーベン)

開発者は顧客からビジネスを学び、顧客は開発者からテクノロジーを学ぶことで、開発者と顧客が弁証法的発展を遂げる例です。

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

最後にまとめます。

この原則からは、自分とは異なる立場・文化の人から知識を吸収すること、自分とは異なる立場・文化の視点で物事を観察すること、自分とは異なる立場・文化の人との間で共通の目標を立て共闘することの意義や喜びを学ぶことができます。

計画に従うことよりも変化への対応

最後は「契約交渉よりも変化への対応を」です。

これまで、対話を相互作用と解釈し、作用の対象を個人からソフトウェアやチームと言った個のオブジェクトに広げました。

ここで言及することはあまり多くはありませんが、変化とは何であるかを考えてみたいと思います。

内的要因による変化と外的要因による変化

変化には内的要因による変化と外的要因による変化があります。

ソフトウェア開発の属人化が進んでしまっている問題に対して、プログラマの知識や技術を継承する活動を始めたといった変化は内的要因による変化です。

新型コロナウイルスが流行したことで、開発中のソフトウェアに、音声入力のような非接触インターフェイスで操作できる機能の必要性が生じたといった変化は外的要因による変化です。

変化はチャンス

歴史学者のハラリ氏の書いた「サピエンス全史　文明の構造と人類の幸福」では、今の人類 (ホモ・サピエンス) が繁栄した理由は、虚構を信じ、それを話す能力を獲得したこと (認知革命) だと言います。

それが偶発的に発生したものか、必然的に発生したものかは、未だ解明ができていないそうですが、その変化をチャンスに変え、生存競争を勝ち抜くことができました。

特に外的要因による変化は競合他社にも等しく訪れる変化も含まれます。

変化にいち早く適応し、先行者利益を得るチャンスである場合もあれば、変化の芽を観測し、さらなる大きな変化に備え、競争優位性が獲得できるように研究・開発を進めるチャンスである場合もあるでしょう。

変化はチャンスです。

変化は Fun

変化の乏しい日々はつまらないものでもあります。

マンネリ化した日々に刺激を与えるのもまた変化です。

特にプログラマという人種はテクノロジーの進化などで発生する変化によって知的好奇心をくすぐられます。

自身に立ちはだかった高い壁は、乗り越える楽しみをも与えてくれます。

そう感じない人も多いとは思いますが、変化が激しいアジャイルな現場で仕事をするのであれば、楽しいと捉えた方が幸福度を高く維持できます。

変化を楽しむことができるようになれば、「アジャイル宣言の背後にある原則」にある「変更への歓迎」が自然体となります。

変化は Fun です。

変化とは相互作用が生み出すもの、またはもたらすもの

以上が変化の特性の話になりますが、変化とは相互作用が生み出すもの、またはもたらすものと捉えることもできます。

製品開発チームの中で起こる相互作用が、内的要因による変化を生み出し、社会とソフトウェアとの相互作用が外的要因による変化をもたらします。

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

最後にまとめます。この原則からは、変化に適応する勇気、変化を楽しむ精神が学べます。

まとめ

最後に解釈をまとめていきます。

これまで述べてきたことをひとつの図にまとめると、アジャイルマニフェストが生み出す構造が見えてくることに私は気付きました。

社会との相互作用

まずは、図の左側から説明します。

開発者と顧客は相互作用を通して、互いに影響を与え合い、互いに高みに発展していく関係性があります。

図の中では省略しましたが、開発者と開発者もまた、相互作用を通して互いに影響を与えながら、互いに高みに発展していく関係性があります。

アジャイルでは、開発者と顧客は仲間です。

開発者と顧客を包含する概念は個のチームになります。

図の中央側に移っていくと、チームとソフトウェアが相互作用を通して、互いに影響を与えながら、互いに高みに発展していく関係性があります。

そして、図の右側に移っていくと、ソフトウェアと社会が相互作用を通して、互いに影響を与えながら、互いに高みに発展していく関係性があります。

図の左側のチームとソフトウェアの相互作用からは、内的要因による変化が生まれ、図の右側のソフトウェアと社会の相互作用からは、外的要因による変化が生まれます。

私がこれまで話してきたアジャイルマニフェストの解釈は、この図によって総合されました。

ここで注目したいことは、我々はソフトウェアを通して、社会に影響を与える関係性の中にいるということです。

つまり、アジャイルとは、様々な相互作用を通して、価値のあるソフトウェアを生み出し、社会と相互発展する方法論なのだと解釈できたのです。

さらに言えば、これはソフトウェアに限った話ではなく、プロダクトやサービスに名称を置き換えても通用する方法論だとも思っています。

仕事をする上で大切なことはすべてアジャイルマニフェストから学んだ

筆者はアジャイルマニフェストの個々の宣言から、仕事をする上で大切なことを学ぶことができました。

そしてアジャイルマニフェストの各宣言の関係性を総合することで、ミクロな視点では　近くにいる開発者、近くにいる顧客、作っているソフトウェアとの相互作用を通して、マクロな視点ではソフトウェアとの社会の相互作用を通して、社会に影響を与えることができる可能性を発見することができました。

社会貢献と言うと大げさかもしれませんが、仕事を通して社会に何かを働きかけるその第一歩は、今いるその場所の隣人との相互作用に始まります。

そのことを肝に銘じて、仕事に取り組んで行かなければと身を奮い立たせています。

解釈のすゝめ

この話は筆者がアジャイルマニフェストをこのように解釈したという話です。共感できる人もいれば、共感できない人もいると思います。

最初の方に述べた通り、原理・原則というものは、自分なりに 解釈をして始めて自分のものになるものだと思います。

持っている知識や置かれている環境が違えば、異なる解釈が生まれるはずです。

ぜひ、最後まで読んでいただいた皆さんには、皆さんなりのアジャイルマニフェストの解釈をしてみてください。何でもない文章だったと思っていたものに、大きな発見があるかもしれません。

今後も、そうして生まれた解釈に触れることを楽しみにしていきます。

以上。

アジャイルマニフェスト原文

日本語訳

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

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/ja/manifesto.html

原文

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

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, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
https://agilemanifesto.org/iso/en/manifesto.html