こんにちは。
セラク・みどりクラウド事業部のエキスパートエンジニア・スクラムマスターの原田です。

みどりクラウド事業部では、毎週月曜の朝30分を使ってミニ勉強会を開催しています。
勉強会を開催する理由や、勉強会テーマであるアジャイル・スクラム勉強会の選定理由については第1回のストーリーで紹介していますので、よろしければこちらも併せて御覧ください。

今週の勉強会では、アジャイルソフトウェア開発宣言についてディスカッション形式で意見交換をする会を行いました。
アジャイル・スクラム勉強会なので、それまでの勉強会でもアジャイルソフトウェア開発宣言の紹介はしていたのですが、より理解を深める必要があると考えたため今回のディスカッションを企画しています。

以降は、アジャイルソフトウェア開発宣言のディスカッションで進めた内容を皆様にもご紹介します。
これを読んでいただいた方にアジャイルソフトウェア開発宣言について知っていただき（既に知っている人には復習として）、みどりクラウドが行っている勉強会にも興味を持って頂けたら幸いです。

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

まず、アジャイルソフトウェア開発宣言そのものを見る前に、なぜそのような宣言が出てきたのかについての背景を知る必要があります。

アジャイルソフトウェア開発宣言には宣言の内容と著者の名前は示されているのですが、いつ・どこで・どのような人が・なぜこのような宣言を出したのかまでは示されていません。
信頼できそうな情報源として、Wikipediaのアジャイルソフトウェア開発には以下のように示されています。

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

いつ示された宣言なのか

2001年に示された宣言です。
今から20年も前になります。アジャイル開発という言葉が日本で流行りだしたのはここ10年くらいな気がするので、それよりもかなり早い段階でアジャイルな開発とはどのようなものなのか示されていたことになりますね。

どこで示された宣言なのか

アメリカ合衆国のスキーリゾートで示された宣言です。
かしこまった会議の場で行った宣言ではなく、リゾートに有識者が集まって意見交換をしてとりまとめた宣言であると言えますね。

宣言にはどのような人が関わったのか

以下の17名が著者として名を連ねています。

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andy Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

個人的に、特に注目をしてほしいのは以下の4名です。

・Kent Beck
エクストリームプラグラミング(XP)の考案者

・Martin Fowler
リファクタリング: プログラムの体質改善テクニックの著者

・Ken Schwaber
・Jeff Sutherland
スクラムガイドの著者

まず、エクストリームプログラミングを提唱したKent Beck(ケント・ベック)の名が出ていますね。
エクストリームプログラミングは、テスト駆動開発・ペアプログラミング・リファクタリング・YAGNIなど、その後のアジャイルな開発やスクラムフレームワークにも大きな影響を与えた考え方です。

また、Martin Fowler(マーティン・ファウラー)が本で纏めたリファクタリングも、アジャイルやスクラムとは切り離せない重要なテーマです。
日本語訳も出版されており、新装版でも5年前の本にはなってしまうのですが、使用する開発言語に関わらずコードを改善するための実践的なテクニックやモチベーションについて紹介されているので、まだ読んだことがないようでしたらぜひ手にとってみることをお勧めします。

そして、Ken Schwaber(ケン・シュエイバー)とJeff Sutherland(ジェフ・サザーランド)。
最初にスクラムを提唱した野中郁次郎先生の論文から着想し、開発プロジェクトで実践した経験からアジャイルソフトウェア開発スクラムというフレームワークに落とし込んだのがこのお二人です。
後に、スクラムガイドとして整理され、今日のスクラムフレームワークの原典となっています。

このように、2001年当時に先進的な開発の取り組みをしていた著名な方々が集って連名で出した宣言と言えます。

なぜこのような宣言を出したのか

ウォーターフォール開発に代表される厳格で重量級な開発の進め方に対して、提唱した17名は限界を感じていたためと予想しています。その当時、ケント・ベックは既にエクストリームプログラミングを提唱していましたが、それらの軽量なソフトウェア開発の根底にある考え方をアジャイルソフトウェア開発宣言として統合・再定義したものである私は考えています。

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

宣言の背景を理解できたら、アジャイルソフトウェア開発宣言の内容を見てみましょう。
と言っても、内容はとってもシンプルかつ簡潔です。

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

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

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

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

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, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。

たったこれだけです。

そして、この中でも特に重要なのは以下のたった6行のメッセージです。

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

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

1つずつ見ていきましょう。

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

意思疎通を図る手段として、プロセスやツールよりも直接対話をした方が効率が良いということです。
チャットやチケット管理システムでやり取りをしていて、直接話したほうが話が早そうだな・説明しやすいなという場面があると思います。それこそ個人と対話をです。

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

かっちりとした設計書をせっせと作り、顧客と設計書の内容をみっちりとレビューしているのに、動作するソフトウェアはまだ1行もできていないという状況は多くの人が経験していると思います。設計書が出来上がっていることは、顧客のビジネスに対して価値を生み出しているのでしょうか？動くソフトウェアがあってこそビジネスに対して価値を生み出していくはずです。

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

これは請負契約によるシステム開発を経験したことのある人には耳の痛い話かもしれませんが、開発の前提となる契約があると、ソフトウェアをどのようにしていくとベストであるかという以前に、契約として決まっていることだからという方向に話が進みやすい傾向があります。成果物を予め定義し、成果物の納品責任と瑕疵担保責任がある請負契約だとなおさらです。
もちろん会社間の契約も大事なのですが、それだけに気を取られていると当初のソフトウェアが実現したかった目的を見失う恐れもあります。契約を尊重しつつも、顧客と協調し価値あるソフトウェアを作っていくことが大事であるという考えです。

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

プロジェクト開始時にきっちりとしたガントチャートやWBSを作り、その後の開発で自ら設定したスケジュールによって自分の首が締まるという体験をした経験はありませんか？経験豊富な人が作成した未来予想でも実際にやってみるとズレることはあり得ますし、それがまだやったことのない・不確定な作業なら計画からズレが発生するのは仕方がないことです。
そのような場面で、変化し続ける現実よりも計画を優先することがビジネス価値を得るために最適な行動でしょうか？それよりも、変化した現実を受け入れて、計画の方を現実に合わせて変化させていく方が良いのではないかと謳っています。

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

見落とされがちですが、ここの一文も忘れてはいけません。
アジャイルソフトウェア開発宣言では個人との対話・動くソフトウェア・顧客との協調・変化への対応を重視していますが、プロセスやツール・ドキュメント・契約交渉・計画に価値が無いとは言っていません。
プロセスやツール・ドキュメント・契約交渉・計画に価値があることを認めながらも、個人との対話・動くソフトウェア・顧客との協調・変化への対応にはより価値があると宣言しているのです。

そのため、アジャイルを標榜する開発を進める中で、「アジャイルだからドキュメントを作らなくてよい」、「アジャイルだから計画は作らない」という意見がもしあったとすれば、それは誤りです。
使われないドキュメントを削減したり、当初計画よりも変化への対応を優先することはあっても、ドキュメントは一切不要・計画も不要ということにはなりません。このあたりはアジャイルという言葉でよく誤解されるポイントなので、アジャイルソフトウェア開発宣言の背景を理解しておくことが重要です。

ディスカッション形式で意見交換

アジャイルソフトウェア開発宣言の背景と内容について参加者の理解度が揃ったところで、ディスカッション形式で意見交換を行いました。

リアル対面で参加者が揃っていれば、ホワイトボードや付箋紙を使って意見を集めたいところですが、コロナ禍でみどりクラウド事業部ではテレワーク体制を敷いているため、オンラインのWeb会議で今回のディスカッションを行っています。

※みどりクラウド事業部のテレワーク体制については以下のストーリーで詳しくご紹介しています

しかし、Web会議だけではなく、ホワイトボードや付箋紙もオンラインで実現したかったので、今回はMiroというオンラインホワイトボードツールを使用しました。オンラインの付箋ツールというとこれまではTrelloが有力だったのですが、Miroの方がより自由度の高いホワイトボード的な使い方ができるツールと言えます。

Freeプランでも3つまでボードを作ることができ、Miroのアカウントを持っている人との同時編集もできますので、興味がある方は試してみてください。

Miroで用意したディスカッションボード

予めMiroで以下のようなボードを用意しておきました。
アジャイルソフトウェア開発宣言が示す以下の4つの価値について、自分たちの仕事に当てはめてみたときのTo be（あるべき姿）とAs is（現在の姿）を参加者がそれぞれ考えて意見を出してもらうためのボードです。

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

To be（あるべき姿）

まず、4つの価値について自分たちの仕事に当てはめてみたときのTo be（あるべき姿）を参加者がそれぞれ考え、付箋に書き出してみます。

以下のような意見がTo be（あるべき姿）として出されました。

プロセスやツールよりも個人と対話を
・チームで気軽に話ができる状態になっている
・テキストによるコミュニケーションよりも会話を重視している
・チーム内で積極的に会話し、チーム内で同じ認識になっている状態
・チーム内で活発に意見交換をしている状態

包括的なドキュメントよりも動くソフトウェアを
・使われる有用な設計書がある
・動いているソフトウェアで説明する
・動くソフトウェアで説明したほうが顧客から意見を得やすい
・動くソフトウェアで認識を合わせる

契約交渉よりも顧客との協調を
・契約の話でお客様vs我々にはならない
・顧客と協調することでアウトプットが更に良くなる
・顧客の要望を我々と双方向でやりとりする
・顧客との協調を実現するために準委任契約のほうがやりやすい

計画に従うことよりも変化への対応を
・完璧なスケジュールを完璧にこなすのは現実的ではない
・スクラムのフレームワークを活用して変化に対応
・可能な限り顧客の要望に答えられるような開発を行う
・計画と変化した現実だったら、現実の方を優先したい

As is（現在の姿）

そして次に、4つの価値について自分たちの仕事に当てはめてみたときのAs is（現在の姿）を参加者がそれぞれ考え、付箋に書き出してみます。

以下のような意見がAs is（現在の姿）として出されました。

プロセスやツールよりも個人と対話を
・チーム内の会話をもっと活発にしたい
・お客様との会話はできていそう。チーム内の会話をもっと盛り上げたい
・週次のふりかえりや、毎朝の朝会で進捗状況は共有できているが、逐一の進捗度合いが把握しくい
・計画会議とふりかえりで以前よりは意見交換をしているが、もっと気軽な会話をできるようにしたい

包括的なドキュメントよりも動くソフトウェアを
・みどりクラウドの設計書は無駄なものを作成していないが、基本設計に関わる設計書を充実させたい
・他の人に設計を伝える手段として、設計書を充実させたい
・ある程度仕様を確立してから動くソフトウェアを作成したい
・もう少し設計書があってもいいかも

契約交渉よりも顧客との協調を
・請負契約のソリューション案件では契約交渉が重視されている
・案件によって顧客との協調ができている場合もあるし、そうではない場合もある
・顧客の要望と開発側の意見の摺合せで、大きな仕様変更が発生しないようにしたい
・請負契約だと協調よりも抑制方向で考えてしまうことが多い

計画に従うことよりも変化への対応を
・まだ変化をできるだけ避けようとしている。変化が無いのが良しとされている感じ
・コロナの影響もあるが、顧客からのフィードバックを得られなかったために変化が少なかった
・開発リソースは限られているので、リソースに関わる柔軟な対応は難しい
・最初に決めた開発スケジュールを後から変更するのはなかなか難しい

このようにして、To be（あるべき姿）とAs is（現在の姿）を対比させることで、何ができていて何が足りないのかがだんだんと見えてきます。

30分のミニ勉強会で開催したのはここまででしたが、このディスカッションを足がかりにしてアジャイルソフトウェア開発宣言の4つの価値について自分たちの仕事にあてはめて理解を深め、さらに開発チームで4つの価値を実践していくことを狙いとしています。
アジャイルソフトウェア開発宣言は一度読んで完全に腹落ちするものでは無いので、今後も繰り返しディスカッションの場を設け、自分たちの仕事と対比することで開発チームの改善を進めたい考えです。

このように、セラク・みどりクラウド事業部では定期的な勉強会やディスカッションの時間を確保し、開発メンバーの知識や技術の底上げと開発現場の改善を行っています。

面白そうだなと興味を持っていただけたら、勉強会では他にどのようなテーマを扱っているのかや、みどりクラウド事業部のアジャイル・スクラムに対する取り組みもご紹介できますので是非お話をしましょう。お待ちしています。