アジャイルソフトウェア開発宣言、どう解釈している？
アジャイルソフトウェア開発宣言とその原則は紛れもなくアジャイルの原典です。そこで定義されている価値観と原則は、20年経った今もソフトウェア開発をアジャイルにするための金言であることは変わりありません。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
アジャイルソフトウェア開発宣言はこの主文が最も有名ではないでしょうか。アジャイルを実践していく上で守りたい・守るべき4つの価値観ではありますが、実態としてまだまだ浸透していない時や、誤った解釈をしてしまっているのではと気になってしまうこともあります。今回はそんなありそうな誤った解釈を各価値ごとに考えてみて、その上で本来はどう解釈すべきかというのを私なりに考えて書き出してみます。
プロセスやツールよりも個人と対話を
個人？ちゃんと気にかけている。
リーダーが各メンバーの作業を割り当てて、
絶えず手を動かし成長できるようにしているよ。
そこに無駄なんてない。
対話？うちはしているよ。
上長たちとの打合せも毎週あるし、毎月の報告書だって書いている。
その時にプロジェクトの計画や今後についても色々オーダーが来るので、
ちゃんとすべてプロダクトバックログに入れている。アジャイルソフトウェア開発宣言における「個人(Individuals)」に価値をおくとは、個人の自主性自律性を尊重するXY理論でいうY理論にあります（とAlistair Cockburnさんが言ってました）。そういう意味でX理論に基づいた管理をするならそれはアジャイルではありません。自律性を尊重し高めるY理論に基づいた管理を進めるべきであり、それにはリーンアジャイルなリーダーシップやサーヴァントリーダーシップが必要不可欠です。
「対話(Interactions)」を「コミュニケーション(Communication)」、つまり情報の伝達だと勘違いしているケースが多い気がします。原文の英語ではInteractionとあり、これは相互作用を意味します。単なる情報の交換であるコミュニケーションはプロセスの範囲内であり、それ以上の交流を生む相互的な「対話(Interactions)」が本来あってほしいものです。
包括的なドキュメントよりも動くソフトウェアを
動くソフトウェア？ばっちりさ。
何よりもまず動くものを作ることが大事なんだ。
リファクタリングやテスト環境にかけるコストがあったらまずは作ること。
そうじゃないとフィードバックを得られないだろう。テストは後でまとめて作れば良いさ。「動くソフトウェア」から得られるフィードバックがアジャイルにおいて重要であるのは間違いありません。そしてソフトウェアを「動かし続ける」には、「動くソフトウェア」であり続けるには、品質が重要です。これまでのテスト観点であった外部品質以上に、可読性や変更容易性などの内部品質にも目を向け、環境を整備し品質を保っていくプロセスが結果的にはスピードに繋がります。これについては和田卓人さんの質とスピードを読むのがなによりもオススメです。
契約交渉よりも顧客との協調を
顧客との協調？一番大事にしている。
顧客とは良好な関係を築いておきたいからね。
要望を聞きながら、多少の無理難題もこなさなければ。
相手の依頼を着実にこなすことが大切なんだよ。「協調」の意味を調べると「利害の対立した者同士が、おだやかに問題を解決しようとすること。「労資―」。性格・考え方などの異なった者同士が、互いにゆずりあって調和していこうとすること。」とありました(Oxford Language）。私が思う協調は、立場や利害関係を超えて1つの目的に向かって協働することで、その1つの目的を目指す前提の中で「三方良し」をどう実現できるかを考えていくのが重要なんじゃないかなと思っています。協調の原文もCollaborationなので、本当の意味での協力関係を作りたいですね。
計画に従うことよりも変化への対応を
変化への対応？うまくできている。
突発的な問題に対応するため定期的にメンバーは入れ替えているし、
チームは経営陣から毎週のミーティングで来るオーダーにしっかり答えてくれてる。
それを細かい単位での計画にすることでチームは変化への対応を実現している。対応すべき変化は、あらゆる変化であり、その変化はステークホルダーからくる要求に限ったものではありません。そうやって集まった変化へどう対応するかをチームが考え実践していくことでチームが自己管理できるレベルへと成長するのです。その機会を奪ってはもったいない。また、メンバーを頻繁に変更するような変化はチームの安定性を乱し、価値観や技術の共通化のコストが掛かるのであまりおすすめできません。
これを通しての思い
上に書いた誤った解釈とは悪意ある解釈ではなくて、これまでの開発パラダイムにおける価値観が根底にある解釈なんだなと書き終えて感じました。それ自体は別に悪いことではなくて、それも誰かにとっての必要性から生まれたものです。ただ、これまでの開発パラダイムの実践の中で先人たちが「よりよい開発方法」を見つけ出そうとしていく中でたどり着いたものが、アジャイルソフトウェア開発宣言なのです。
アジャイル vs ウォーターフォールのような手法レベルでの対立構造が作られがちですが、そこはあくまでもプロセスとしての話でアジャイルソフトウェア開発宣言での論点ではないんだなと改めて思いました。どんな手法だろうと、どんな開発だろうと重要視すべき共通的普遍的な価値観がアジャイルソフトウェア開発宣言の言いたいところなのだと思います。
そして、それぞれを分けて考えるのではなく、複合的に大切にすることも重要です。顧客と強調し、動くソフトウェアを元に対話しながら、フィードバックを得て変化に対応していくわけです。そしてそれを支える「アジャイルソフトウェアの12の原則」も忘れず、セットで理解することです。誤った解釈の多くは原則を無視していることから生まれているのでは、という気もしています。
翻訳への思いと感謝
これを書くにあたってアジャイルマニフェストと原則の英語の原文をはじめて単語の意味まで読み取ろうと試みて、翻訳ってめっちゃ難しいんだなと改めて思いました。とくにアジャイルソフトウェア開発宣言のような言葉をシンプルに削ぎ落としたものは、本来の意図を伝えるための言葉選びに悩みに悩みそう。スペイン語が少しわかるので見てみましたが、同じ語源からくる単語がある場合が多いので伝わりやすそうですが、日本語は本当に大変なんだろうな……そういえば誰が翻訳してくれたんだろう？と思って少し調べてみました。びっくりしたのはアジャイルソフトウェア開発宣言が日本語に訳されたのがオリジナルの10年後の2010年だということ。
そして翻訳者はアジャイルソフトウェア開発宣言のページにしっかり書いてありました。小さいのと一番下なので気付いてなかった……こういうのも知ろうと思うことがまず大事ということで！
よろしければサポートお願いします！いただいたサポートは書籍やテック・アジャイル関連のイベント参加などに使い、レビューの公開をお約束します。