組織的なアジャイル導入のトレンドに合ったタイムリな指南書 ―― 『アジャイル開発の本質とスケールアップ』
 | 『アジャイル開発の本質とスケールアップ』 |
タイトルにある「アジャイル開発」とは，1990年代から提唱・実践する人が出始めた，「軽量」プロセスによるソフトウェア開発です．CMM/CMMI（Capability Maturity Model/Capability Maturity Model Integrated）やISOなどの「重い」プロセスに対するアンチテーゼとして広まり，2001年のアジャイル・ソフトウェア開発宣言により，「アジャイル」という言葉が広く認知されるようになりました．
この歴史から分かるように，アジャイル開発は，決してごく最近登場したものではありません．しかし，現在，アジャイル開発手法の「第二の波」が来ている，と言われています．
最初の波は，アジャイル・ソフトウェア開発宣言が出されたころ，主に開発者の草の根的な活動として，XP（エクストリーム・プログラミング）を始めとするアジャイル開発手法が脚光を浴びました．そして，現在，ツール・ベンダの積極的な取り組みもあり，より組織的にアジャイルを導入しようという動きが広がっています．本書は，その意味で非常にタイムリであると言えます．
しかし，アジャイルも決して“銀の弾丸”ではありません．いささかでもそれを期待して本書を読み始めると，まず，クルーシュテン博士の序文にある以下の記述にがっかりされるでしょう．
「この本を読んだ後（この本だけでなく，いくつか他の本も読んだ後），すぐに成功できるレシピとして使えることを期待しないほうがいい．･･･（中略）…ソフトウェア開発の世界では私はこう言うことにしている．『一にコンテキスト（背景），二にコンテキスト，三にコンテキスト』である」
もしあなたが，アジャイルの「継続的改善」という言葉の意図を知らないアジャイル初心者ならば，この本はお勧めしません．もっと手軽な本がたくさんあるので，まずはそれらの書籍を読むことをお勧めします．そして，実際にそこで語られていることを実践してみていただきたいのです．例えばTDD（テスト駆動開発）なら，個人ですぐに試してみることができます．
次に，あなたがすでにアジャイル手法についてご存じだった場合，この書籍の中で，RUP（Rational Unified Process）が取り上げられていることに違和感を覚えるかもしれません．RUPは，アジャイルと同じ反復型開発であっても，成果物として多くのドキュメントを作る「重い」プロセスと見なされることが多いはずです．
しかし，RUPには，アジャイルをスケール・アップするためのヒントが多く含まれていると筆者は考えており，評者もそれに全面的に賛成します．膨大な量のHTMLで構成された製品としてのRUP，多くのドキュメントが必要と思われているRUPの本質を探ると，そこにはアジャイルの本質と同じものがあるのです．RUPは重いプロセスだと思われている方には，こちらの文献をどうぞ．
アジャイル手法のプロセスとしての軽量さに魅力を感じておられる方には，この本で語られている，開発早期でのアーキテクチャへの取り組みやチーム編成の仕方，組織としてのアジャイルへの取り組み方など，スケール・アップのための手法に少々抵抗を感じる方もいるでしょう．しかし，これはアジャイルを大規模化するためにはやむを得ず，必要なことだと思います．
本書の中でも取り上げられていますが，アジャイルをスケール・アップする上で，重要性を再度強調しておきたい点は，「より高い抽象度で顧客のニーズを把握すること」です．規模の大きいシステムでは，アジャイル手法でよく使われるストーリだけで顧客ニーズを把握するのは困難です．フィーチャと呼ばれるより大まかな機能単位，さらに抽象的なニーズ（なぜ顧客はそのシステムを必要としているのか）を，プロジェクト・メンバ全員が理解することが重要です．
そして，プロジェクト・マネージャやリーダと呼ばれる，チームを先導する役割の方は，このような抽象度の高い顧客のニーズや，プロジェクト・その時点のリリース/反復の目標を，チームの隅々まで行き渡らせることに心を砕いてください．これは，ドキュメントを作って，それをプロジェクトの共有フォルダに置いておけばよい，というものではありません．ことあるごとに，口が酸っぱくなるほど，繰り返し繰り返しメンバにそれを伝える，ということです．
どれだけ規模が大きくなっても，地理的に分散したチームであっても，実際に会って話すことが重要です．高価なツールも，立派なドキュメントも，その補助にしかすぎません．自分はリーダの立場ではないし，自分のチームのリーダはそんなことを教えてくれない，とお嘆きのあなたは，自分から考えてみてください．自分が今作っているこの機能は，システム全体の中でどのような役割を果たすものなのか，顧客にどのような価値をもたらすのか．作っているのが最終製品ではない，という方も，最後にはどこかで顧客とつながっているはずです．そうでなければ，給料をもらえませんよね．
常に「なぜ」を自分に問いかけましょう．私は，なぜこのプログラムを書く必要があるのだろう，顧客はなぜこの製品を必要としているのだろう，上司はなぜこの指示を出すのだろう，そして，なぜアジャイル手法を使うのだろう．
それが，最初に取り上げたクルーシュテン博士の序文に対する解にもなるはずです．
なかさと・まきこ
(株)テクノロジックアート
