“コラボラティブである”ために（1/2）

“時差”は、なかなか埋まらず…

先日、弊社の製品開発チームのメンバーと一緒に、とある団体のインタビューを受ける機会がありました。印象的だったのは、「IBMソフトウエアの開発部門では、『特に理由がなければ、アジャイルでやる』のがワールドワイドの基本方針と、なった」という彼の発言。

問題意識の高いお客さまのリーダークラスが、アジャイルを採用、あるいは試行するために、社内向けの理由付けに四苦八苦している姿を多く見ている身としては、（身内のことで恐縮ですが） 海の向こうとの“時差”を感じた出来事でした。

IBMは自らの製品開発の経験を通して、アジャイルな開発スタイルの有効性を実感するとともに、より大規模なシステムへの適用に関しても手応えを感じています。前回名前だけ挙げたJazzテクノロジーのプロジェクトチームは、100人以上の分散体制でアジャイルな開発スタイルをここ数年続けています。

これまでの開発スタイルに比べて、納期遅延が少なく製品品質も高くなっているという実績データもでており、アジャイル採用プロジェクト数は急速に増えてきていました（が、まさか基本方針とは）。

Jazzプロジェクトの取り組みについては、昨年の4月に当Think IT上で4回に亘って連載の機会をいただきました（「分散開発とアジャイルは水と油か？」）。

下の図は、より大規模なプロジェクトにアジャイルを適用する場合に考慮しなければならないさまざまな要素についてリストアップしたものです。詳細はそちらの連載を併せてご覧いただくとして、この図を頭の隅に置きつつ、本記事ではツールの話に絞っていきましょう。

コラボレーションをより“具体的”に

前回の話を簡単にまとめると、開発ツールの焦点は次のような変遷をたどってきています。

1. 「個人の作業を効率化する」
2. 「他人の経験値（共有知）を導入することで、個人の生産物の質を高める」

もちろん、この2つは排他的ではなく、本来足し算であるべきです。また、管理面ばかりが強調される傾向のあるALM（アプリケーションライフサイクル管理）の領域でさえ、「個人の作業が、まとはずれな結果を生まないための情報基盤」という意味で、個々の開発者にとって重要であることも忘れてはなりません。

そしていま、大規模アジャイルへの本格展開をにらんで焦点を当てているのは、「いかにコラボレーションをサポートするか」です。しかし、このコラボレーションという言葉、あまりに一般用語すぎて、“モデリング”とか“テスト自動化”という言葉に比べて、今ひとつ具体性に欠けていると思うのは筆者だけではないでしょう。そこで、次ページからは、次に挙げる3つの具体的な状況を取り上げて、コラボレーションという一般用語に開発者にとっての具体性を付加することにしましょう。そうすればツールとして何が必要なのか、おのずと見えてくるというモノです。

1. 要件をだす側と開発側とのコラボレーション
2. 開発者同士のコラボレーション
3. マネジメントとのコラボレーション