この記事はフロムスクラッチ Advent Calendar 2016の22日目の記事です。

想定読者

このエントリーは、以下のような人を対象にしています。
対象が、前回よりは広がっていて、よいかなと（笑）

ウォーターフォールで、開発をしている人。
アジャイルって、精神論みたいだよねーと思っている人。
アジャイルって、ウォーターフォールと似てるとこもあるよねーと思っている人。

また、「ウォーターフォールとかアジャイルとか聞くけど、エンジニアじゃないから
よくわからんよ」という方にも、読んでいただけたら、理解の助けになるかなと思います。

自己紹介

フロムスクラッチというベンチャーで、エンジニアリング部門のマネージャーを務めております。
自社プロダクトB→Dashにおいて、プロダクトの要件定義、テスティングや開発プロセスの設計、
プラスアルファで採用や広報などを担当しています。前職は、NTTDADAで働いておりました。

はじめに

私とアジャイル

前職は、ウォーターフォールモデルの社内標準が存在しており、非常に活用されていました。
その社内標準は、非常に良く出来たものだったと感じています。つまり、ウォーターフォールモデルを
採用した時にぶつかる壁に対して、徹底的にプロセスやノウハウに落とし込んでいるのです。
例えば、”工程定義”に対する認識のズレが、ウォーターフォールモデル採用時の壁になる例です。

”要件定義”の認識が、お客様と違い、「え、ここまで今決めるんじゃないの？」と言われる。
”詳細設計”と”内部設計”など、同じタイミングだけどニュアンスが異なる言葉で、ベンダ同士に認識が少しずつズレている（横並びのベンダを失敗させるために、定義をあえて合わせないことも、昔はあったらしいですね）
”結合テスト”が、何と何を結合して何を確認するテストなのか、認識がズレることで、すり抜けバグが発生する（「すり抜けだ」VS「すり抜けではない」の論争が勃発）

上記のような認識のズレを解消するために、開発標準は非常に重要なものだと感じます。
さらに、社内標準として統一されていることは、その会社のビジネスに有用であると言えます。

一方で、私の最初の上司は、社内標準にはない手法、”アジャイル”にも興味がある方でした。
当時、入社一年が経ち、やっとウォーターフォールを理解できてきた私に、こんな依頼がありました。

「佐藤くん。次の追加開発は、アジャイルってので出来ないかな？ちょっと調べてくれ。特にオフショア先のと上手いこと実施できると良い。社内の決裁プロセスなどとも、いい感じにできたらなお良いね。」

これが、私とアジャイルの出会いです。

今考えると、当時のプロジェクトは、マルチテナント型のIoTプラットフォームであり、
かつ、追加開発だったので、アジャイルがマッチする可能性は十分にありました。
しかしながら、私の力不足により、アジャイルの採用には至りませんでした。

現在、弊社ではアジャイルスクラムをベースに、ウォーターフォールといいとこ取りな
開発プロセスが実施できている（標準化はまだまだですが）ので、この最初の
上司の先見性には、非常に感謝しています。

本記事では、ウォーターフォールを職務としながら、アジャイルを理解しようとした私が、
アジャイルを理解するポイトとなる基礎事項を整理しようと思います。

基本的な理解の助け

アジャイルは、形容詞である

”アジャイル”は、形容詞であることは、意外と大きな壁です。
Wikipediaで”アジャイル”だけ調べると以下のように説明されます。

Agile usually refers to an entity that possesses agility.

つまり、「敏捷」や「機敏」な様子が、”アジャイル”であり、ソフトウエア開発では、
アジャイルソフトウェア開発（Agile software development）と呼ぶのが適切です。
反対に、”ウォーターフォール”も、ウォーターフォール・モデル（Waterfall model）と呼ぶのが、
正確であり、「ウォーターフォールか、アジャイルか？」という問いは、変な感じがします。

”アジャイル”が形容詞であることが、理解の助けになります。理由は、次節以降で説明します。
※便宜上、アジャイルと読んだほうが短くて楽なので、本記事もそのように記載します。

アジャイルには、複数のメソッドがある

アジャイルには、その手法を提唱したり、体系的に整理した方複数人いらっしゃるので、
複数の手法があります。武芸で言う「～～流」みたいなものですね。
代表的なものには、以下があります。

XP（extreme programming）
スクラム（Scrum）
RUP（Rational Software Corporation）

上記以外にも、ダイナミックシステム開発技法、アダプティブソフトウエア開発技法、
クリスタルメソッド、リーンソフトウェア開発、フィーチャ駆動開発、アジャイル統一
プロセスなどなど、様々な流派が存在します。

アジャイルは、価値観＋プラクティスである

ここが、本記事で重要なポイントの一つです。アジャイルを理解する上で、価値観とプラクティスを
分けて考えると、非常に理解しやすいのではないかと、個人的には考えています。

価値観

アジャイルは、価値観を提唱しています。

つまり、ソフトウェア開発において、何が大切なのか、何が価値なのかを出発点にしています。
その価値観を定義したものが、アジャイルソフトウェア開発宣言に整理されています。

このアジャイルソフトウェア開発宣言の背景には、ウォーターフォールがあるというよりも、
当時のソフトウェア開発ベンダが実施していた契約や仕事の進め方に関係しています。
具体的に、ソフトウェア開発宣言を見てみましょう。

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

前述の”ウォーターフォールモデルを採用した時にぶつかる壁”を思い出してください。
工程定義（内部設計と詳細設計の違いなど）の認識違いが発生する例がありました。
この認識違いを発生させないためには、プロセスを明確に定義したり、ツールによって
仕事の進め方を制限するようなことが楽ではありませんか？

しかし、本質的には、ソフトウェア開発者同士や、ビジネスサイドと対話すること、
コミュニケーションによって得られる知見のほうが、価値が高いよね！そうじゃないかい？
そんな価値観を訴えている文章です。

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

こちらも同様です。工程定義の認識違いを防ぐためには、工程定義を厳格に文書化したり、
工程間の引き継ぎに必要なドキュメントを整備したりすることは非常に有用です。

しかし、本質的には、ドキュメントは手段であって、動くソフトウェアが最終的に
ユーザーに対して価値を発揮するんだよ！そうじゃないかい？
そんな価値観を訴えています。

残りの文章も見てみましょう。

契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

「価値をおく」という部分がポイントです。

つまり、ソフトウェアを利用する人のために、開発者側が何を大切にすべきかという
価値観の部分を提唱しているのが、アジャイルの一側面となっています。
これは、前述のXPやアジャイルというメソッドにも共通していることで、
何を大切にしたいのかを精一杯説くことが、アジャイルの特徴といえます。

プラクティス

価値観と分けて考えるべきは、プラクティスです。
プラクティスとは、具体的に何をどのように進めたら良いのかを提案しています。

具体的なプラクティスの例を挙げると、以下の様なものがあります。

XPにおけるペアプログラミング
スクラムにおけるデイリースクラム
リーンソフトウェア開発におけるカンバン

上記のようなプラクティスは、価値観を達成するための手段です。
アジャイルにおいては、価値観を大切にしているため、必ずしも全てのプラクティスを
実施する必要はなく、それは各組織やチームに合わせて組み合わせるべきと言われます。

アジャイルの理解を始める際、プラクティスから目を向けてしまうことはおすすめしません。
ペアプログラミングという普段は実践しない方法にばかり注目をしたり、
デイリースクラムは”朝会”と一緒じゃないかと蔑んだりすることは、
アジャイルの本質的な理解から離れてしまいます。

是非、アジャイルに関連するワードが出てきた場合は、以下の点を確認してみてください。

そのワードは、価値観の話なのか、プラクティスの話なのか？
プラクティスの話であれば、どんな価値観を体現するための手段なのか？
自分たちの組織、チームが価値観を達成するために、そのプラクティスは有用なのか？

よくある誤解

大規模には向かないのでは？

大規模向けのフレームワークが存在します。例えば、メジャーなのは、SAFe。
マイクロソフトも、アジャイルを採用しているそうです。こちらの記事に詳しいです。

エンタープライズ向けの開発には向かないのでは？

ToC向けプロダクト、ToB向けプロダクトは関係ありません。
世界最大規模のBtoBプロダクト開発しているSalesforceは、
アジャイルスクラムをベースにした独自のフレームワークADM:Agile Development Methodology用意しています。

最後に

アジャイルを理解する上で、価値観とプラクティスを分けて考えることが、重要です。
目的に対する手段、思いの実現に必要な論理、浪漫と算盤、ビジョンに対する事業。
こんな考え方が明確であってほしいですし、私はそっちのほうが好きです。

ちなみに、ウォーターフォールモデルも悪の根源みたいな捉え方をされがちですが、
発案者と言われるウィンストン・ロイスのソフトウェア開発を良くしたいという思いがあったのに、
それが、政治的な思惑や、多くの人の勘違いによって誤解されて伝わってしまっているそうです。
そちらについては、また次の機会にご紹介させていただきます。

おしまい