アジャイルマニフェストを読み解く

こんにちは、@TakahiRoyteです。
アジャイル開発に携わる方なら見たことがあるであろうアジャイルマニフェストを順を追って「なぜ？」の部分を読み解いていきます。20年近く前に誕生したアジャイルマニフェストがいまだに参照され続けている理由と、現在において変わらければいけないところは無いかも確認してみましょう。

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

アジャイルマニフェストとは、2001年に当時アジャイルな開発手法で高名であった17名がアメリカ・ユタ州のスノーバードで議論の末、まとめられた、ソフトウェア開発における共通の価値基準です。文は以下の通り：

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

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

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

これを宣言した17名の中にはXPの提唱者であるケント・ベック氏やスクラムの提唱者であるジェフ・サザーランド氏ケン・シュウェイバー氏が居ます、って言うと「スゴ味」がある！この宣言の他に、12の原則があります。

アジャイルマニフェスト本文を読み解く

「私たちは」から始まる最初の文章はソフトウェア開発のプロフェッショナルである17人が議論を経て至った共通の価値であることが分かれば良さそうです。では主文をひとつずつ見ていきましょう。

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

・信頼し合う個人間でのコミュニケーションが最良
・プロセスを守ることが常に正しいとは限らない
・ツールに「使われている」状態を避ける
・ツール越しよりフェイス・トゥ・フェイスのやり取りの方が効率が良い
・ツールは補助的に使うことでコミュニケーションの効果を高められる

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

・本当に顧客（エンドユーザー）に価値を届けるものは何かを意識する
・動くソフトウェアこそが価値デリバリーにおいて一番正確な進捗の尺度
・ドキュメントは必要に応じて作ることが大切、すべて用意するのは大変
・ドキュメント通りのものが求められるとは限らないVUCAの世界

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

・Win-Loseの関係から抜け出しWin-Winを一緒に考える
・契約交渉はWin-Loseの関係を作ってしまいがち
・協調する心なしにチームは心理的安全性を築くことはできない

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

・変化への対応は不確実性が高い世の中に対応するために必要
・計画に従うことでWin-Loseになるならそのやり方を見直すべき
・ものごとは概して計画通りに進まない、正しく計画できない

書き連ねた理由を俯瞰すると、「コミュニケーション」「Win-Win」「価値」「VUCA」などのワードが見えてきました。これらはアジャイルにおけるキーコンセプトに繋がる重要なワードです。

最後の文章は「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」は文字通りの内容でとても大切です。左記のことがらに該当する「プロセスやツール」「包括的なドキュメント」「契約交渉」「計画に従うこと」に価値がないわけがないのです。だからベタですが「アジャイルってドキュメント作らないんでしょ？」に対しては「アジャイルマニフェスト読んでこーい！」でよし。

12の原則を読み解く

アジャイル宣言の背後にある原則は「私たちは以下の原則に従う:」から始まり12の原則が述べられています。

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
ここでいう顧客はユーザー企業のプロジェクト担当者ではなくエンドユーザーだと思ってます。（その人が実際にエンドユーザーでない限りね）。

・顧客中心主義でものごとを進められているか
・使われないもの、使いたくならないものを頑張って作っていないか
・必要なときに必要なものを届けられることが大切

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

・計画に従うことを重視しすぎていないか
・変化の対応の拒絶は競争力の放棄と同じ、競合も変化している
・ファクトをもとに要求の変更が生まれることはとても良いこと！

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

・市場の変化は絶え間ない
・一年前に企画したものが一年後に必要なものとは限らない世界
・一年前に企画したものが一年以内に他者が出さない保証はない世界

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

・ビジネス側と開発者が共創することでイノベーションが起こせる
・分断された状態は良いコミュニケーション状態を生みづらい
・お互いを知ることで信頼し合えるし、好きになれる

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

・チームのモチベーションはすべての成功を左右する
・悪い環境、支援の不足はモチベーションを地の底まで突き落とす
・信頼しないと信頼されない、すてきな関係はすてきな結果を生む

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

・その場にいればその場で聞ける、待ちが一番少ない
・非言語コミュニケーション（表情、声のトーン）も大切
・気軽に聞ける環境も大切

動くソフトウェアこそが進捗の最も重要な尺度です。

・動くソフトウェアこそがエンドユーザーが使うもの
・ウォーターフォールのフェーズゲート管理はPJの成功率に影響しない

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

・イテレーションによるペーシングが、イテレーション単位の改善に繋がる
・持続可能な開発は、チームを無駄に疲弊させることを防ぐ

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

・技術や設計思想などの学習と投資がとても大切
・幅広く知ることで選択肢が増え結果アジリティを高められる

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

・良いアーキテクチャにはシンプルさが宿る
・技術だけではなくチーム運営もシンプルになれば開発に没頭できる

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

・自己組織的なチームは自発的な行動が取れる
・自発的な行動は良きチームワークに繋がり、良い開発体験に繋がる

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

・振り返りがカイゼンのすべて、振り返らないとカイゼンしない
・短く定期的な振り返りはカイゼンのスピードを高める

アジャイルの本質を理解して臨む

こんな感じにアジャイルマニフェストの「なぜ」を理解することで、"Don't just do agile, be agile."に近づくことができると思います。上はあくまでも私の解釈でしかありません。一度、原典であるアジャイルマニフェストを自分の言葉で誰かに説明してみるのもいいかもしれませんね。

それでは良きアジャイルライフを。