アジャイルのレイヤ　〜　アジャイルを整理し直して理解する

アジャイル SIer

　【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。

　最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、といった点が曖昧になってきているからでしょう。そこで、アジャイル開発というものを、いくつかのレイヤ（層）に分けることで整理してみようと思います。

　レイヤとは、IT業界でよく使われる言葉で、階層のことです。アジャイルでレイヤと言えば、「価値」「原則」「実践」がすぐに頭に浮かびます。これは最近のアジャイル関連の方法論でよく使われている階層構造です。今回は、そのレイヤとはまた別の切り口で分類しようと考えています。今回の分類は、あくまで倉貫の私見であることを、先に記しておきます。

　さて、アジャイルは、次に示す４つの層に分かれるのではないか、と考えています。

　上位のレイヤの方が導入は容易になりますが、その結果が及ぼす影響範囲は狭くなっていきます。逆に、下位のレイヤの方が導入が難しいだけあって、その効果は大きくなります。それぞれのレイヤについて詳しく見ていきましょう。

テクニカル

　アジャイルにおける「テクニカル」のレイヤを代表するプラクティスとしては、「リファクタリング」や「テスト駆動開発」が真っ先に思い浮かびます。これらのプラクティスは、JavaであればJUnitなどのツールが必要になりますが、それでもプログラマが個人の判断で導入することが可能なものが多いです。アジャイルに興味を持った「個人」がインターネットや書籍で学びさえすれば、自身の作業範囲で導入することができます。

　「テスト駆動開発」で使うテスティングフレームワーク（JUnitなど）は、プラクティスの実践に必須のツールです。しかし、これらのツールだけでも、開発現場で活用することができるため、一部の人たちには、『JUnitを使えばテストファーストである』などといった激しい誤解が産まれたりしています（特に管理者層に）。カバレッジ率などの品質保証のためにJUnitを使うのに違和感を感じるのは私だけでしょうか。

　ツールだけ使ってアジャイルというのはともかく、このレイヤで考えられる内容は、アジャイルの一要素ではありますが、決してアジャイル以外の開発プロセスで使えないかというと、そうではありません。「継続的インテグレーション」などはウォーターフォール（計画駆動）型の大規模開発であっても有効に使えるでしょう。

　「テクニカル」のレイヤは、アジャイルを構成する重要な要素ですが、そのノウハウはアジャイル以外の多くの場面でも有効に活用してもらいたいものです。ただし、それだけでアジャイルを実践していると言ってしまうと誤解が広まるので、注意が必要です。

ファシリテーション

　「ファシリテーション」のレイヤでは、「朝会（スタンダップミーティング）」「ペアプログラミング」「ふりかえり」といったプラクティスがあります。ファシリテーションとは、目的を持ったグループの活動を円滑に進めるための手法として編み出された手法です。特に、参加者をコントロールするのではなく、参加者自身の自主性を高めることで活動を促進します。その役割の人をファシリテータと呼びます。

　ファシリテーションは、よく聞くのが会議の進行であるとか、研修などでも使われますが、他に、集団の活動ということで、会社そのものの活性化のために導入することもあります。日産のゴーンCEOが1000人のファシリテータを育成した話は有名ですね。また、最近のIT業界の話題としては、平鍋氏のプロジェクト・ファシリテーション（http://www.objectclub.jp/community/pf/）を耳にする機会が多いと思います。

　アジャイルの事例の多くが、実はこの「ファシリテーション」のレイヤのプラクティスを実践したものだったりします。近頃の開発プロセス関連のムーブメントは、こういった人的な事項に流れていますし、ともすれば、アジャイル＝ファシリテーションと思われがちな所もあります。しかし、アジャイルの一要素として「ファシリテーション」があると考えるべきでしょう。

　なぜならば、この「ファシリテーション」というレイヤの内容は、アジャイル開発だけでなく、どういった形態のプロジェクトでも使えるものだからです。たとえウォーターフォール型であっても、朝会を実践することは可能ですし、効果もあるでしょう。前述のプロジェクト・ファシリテーションでも、特にプロジェクトの形態は問わないことを言っています。

　この「ファシリテーション」のレイヤも、「テクニカル」と同様に、あらゆる開発の場面でそのノウハウを活かしていくことができます。ですので、【アジャイル】という言葉だけで拒否反応を示しているマネージャやエンジニアの方々には、ここまでのレイヤを学んで、現場に活かすことはとても有効なので、ぜひ共に取り組んでもらいたいと思います。

マネジメント

　このレイヤから導入の敷居がぐっと上がってきます。「マネジメント」のレイヤでは「イテレーション開発」や「計画ゲーム」といったプラクティスがあります。このレイヤを実践するためには、チーム全体の動きや、プロジェクトの開発プロセスにまで踏み込む必要が出てくるため、プログラマ個人での導入は難しくなります。「マネジメント」のレイヤを実践するのは、プロジェクトマネージャになります。

　なぜマネージャがアジャイルを実践することが難しいのでしょうか。従来の計画駆動型のプロジェクトの運営では、リスクマネジメントの方針としては、リスクが顕在化しないことが「善」の世界観です。よって、洗い出したリスクをなるべく回避するか防止するようにマネジメントするし、もし発生してもなるべく責任を転嫁できるように事前策をとることが普通でした。

　しかし、アジャイルにおけるリスクマネジメントは、それとは考え方が大きく違っています。アジャイルでは洗い出したリスクを、プロジェクトの中で小出しにして少しずつ受け入れていくという方針をとります。それもなるべくプロジェクトの早い段階から受け入れていくことで、プロジェクト全体のリスクを細分化していきます。あえて想定の範囲内で小さくトラブルを経験していくことによって、失敗ではなく、学習として受け入れていくのです。

　アジャイルでは、短い周期でリリースを繰り返す「ショートリリース」も、顧客をプロジェクト期間中全般にわたって拘束する「顧客同席」も、すべて細分化という考え方で理解することができます。逆に、このことを理解した上でプロジェクトマネジメントすることができれば、プロジェクトにアジャイルを導入することは可能です。

　ただし現実的に考えて、上記のような考え方をもって、かつ、実際にプロジェクトマネジメントできるような人材は、今の日本ではそれほど多くはいないでしょう。そのために、現場のアジャイルを指向するエンジニアたちが、「テクニカル」や「ファシリテーション」のレイヤで導入に苦労し、さまざまな工夫をしているのでしょう。

　逆に、このレイヤでアジャイルを導入できれば、プロジェクトに参加しているメンバは、ほとんどアジャイルということを意識しなくても、アジャイルで求められる内容を実践できるようになります。例えば、イテレーション単位に計画を立てるようにしていれば、自然とふりかえりの機会が生まれてきます。

　この「マネジメント」のレイヤまでが、工夫次第では、顧客との合意がなくても実施できる範囲であると言えます。しかも、多くの「アジャイル」を標榜する記事や書籍などでは、ここまでのレイヤしか取り上げられていませんし、確かに開発プロセスという観点で見るとそれで良いのかもしれません。しかし、アジャイルを実践すると言った場合に本当に重要なのは、次のレイヤなのです。

ビジネス

　先ほどの「マネジメント」のレイヤができていれば、ＰＪメンバへのアジャイルの意識付けは容易であるといいましたが、それでも、難しい局面がでてきます。それが【仕様変更】に対する考え方です。

　従来の考え方の世界では、顧客は、なるべく予算内に多くの機能を詰め込んでもらいたいと考えるし、開発を受注した側は、プロジェクトで受注した金額の中でなるべく製造コストを下げたいと考えます。これがSIのビジネスです。そうした中では、新しい機能の追加や、ユーザの利便性やサービス向上のための積極的な提案や改善をしにくくなってしまいます。なぜならば、提案や改善で発生する【仕様変更】は、予算とコストを揺るがすトラブルの素になるからです。詳しい話は、過去のエントリ*1で書いてます。

　しかし、アジャイル開発では、変化を受け入れることを前提とし、かつ、顧客のビジネスの成功のために変化に対応していくことを「善」と考えています。だからこそ、SIビジネスの中では、アジャイル開発を実践することが難しくなってくるのです。世界観が違っているのです。よって、アジャイル開発を本当に実践したいというのであれば、SIビジネスとは別のビジネスを実現させる必要があります。それが、アジャイルの「ビジネス」のレイヤになります。

　アジャイルを実践するためには、このレイヤを握ることはとても重要な事項です。しかし、多くのアジャイルのエバンジェリストたちは、このビジネスの問題を避けて通っているようにも見えるし、現場のエンジニアのレベルでは普段対処できるレベルではないため、多くのアジャイルを語る場面で抜け落ちているのも事実です。XPJUGでもこのレイヤが話題にのぼることは殆どありません。

　また、「ビジネス」のレイヤになってくると、テクニカルやファシリテーションとは違い、市場の商習慣が大きく影響してきます。米国におけるこのレイヤの問題と、日本における問題は違っているために、多くの場面で話題にあがりにくいのかもしれません。

　「ビジネス」のレイヤで、アジャイルをうまく実践できるケースとして考えられるのが、プロダクトやサービスの開発です。JUDEなどを開発しているチェンジビジョンでは、アジャイルを実践しているという話を聞きましたが、それはビジネスのオーナーが自社だからこと可能なのでしょう。はてなのようなWebサービスの会社でも、アジャイルとは明言していませんが、近しいやり方が実践できているようです。それ以外のケースとして今後注目なのは最近流行りのレベニューシェアという形態でしょう。レベニューシェアとは、システム構築してその対価で稼ぐビジネスではなく、サイトからの収益をシェアする形のビジネスモデルです。これであれば、前向きな仕様変更ができそうです。

　アジャイルの今後を考えていくためには、「テクニカル」や「ファシリテーション」といったレイヤでの工夫などを考えていくことも重要ですが、この「ビジネス」のレイヤをもっともっとディスカッションしていくべきだと考えていますし、このレイヤで工夫し実践した事例を共有していきたいですね。

レイヤに直交するアジャイル・マインド

　アジャイルを４つのレイヤに分解してきましたが、実は、このレイヤに直交する概念が残されています。それが、アジャイル・マインドと呼ばれるものです。立場上の問題から、必ずしも理想的な環境でアジャイルに取り組むことができない現場は沢山あります。それでもなお、アジャイルを指向し、そのための工夫をしていく人たちはいるものです。そうした人たちに共通する仕事に対する「姿勢」がアジャイル・マインドです。

　アジャイル・マインドを持った人たちの行動にはいくつもの共通点があるようです。愚痴を語る前にできることから改善していく人たちであり、自らの「行動」で周りの世界を変えようとする人たちであり、仲間とその家族を大切にする人たちであり、お互いに尊重し合い成長の機会にしていく人たちであり、自らの仕事に誇りを持って取り組む人たち。そんな人たちに出会えたことが、私自身XPJUGをやっていて一番の収穫だったと思います。

　人との繋がりを大切にし、変化を恐れず、自ら変えていこうとすることがアジャイル・マインドなのかもしれません。それがしっかりしていれば、どのレイヤだろうと実践はできるし、取り組み方も変わってくるのでしょう。そういう人たちが取り組んでいる開発を、「アジャイル開発」と呼んでも良いのかもしれませんね。

　「ビジネス」のレイヤでアジャイルを考えて実践していく人が増えると同時に、アジャイル・マインドを持った人たちが現場に増えることで、この“キツい・キツい・キツい”の３Kといわれる私たちの業界を変えていけるような気がしています。

*1:ディフェンシブな開発 〜 SIビジネスの致命的欠陥 http://d.hatena.ne.jp/kuranuki/20060116/p1