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

開発者にとってコラボラティブである、ということ。

前回は、今後開発ツールに求められるものを考える際のキーワードとして、“コラボラティブ”を挙げ、ツールに必要な要件を3つ挙げました。

ご存じのように、アジャイルな開発スタイルは、それが提唱された当初から、開発者とユーザーが密にコラボレートすることでよりよりシステムを作ることを指向してきました。また、開発者同士がペア・プログラミング等で共同作業することがより質の高いコードを産む源であるとしてきました。

これらは、「紙とハンコによる（かける手間の割に正確でも同時性もない）情報共有」や「形式主義（で形骸（けいがい）化した）運営」「実態を反映（しない）進ちょく管理」等々へのアンチテーゼとして産まれたものです。

しかし、これらの“形骸化した運営”は、産まれたときから形骸化していたわけではありません。そもそもソフトウエア開発は少人数による開発から始まったものであり、対象とするシステムの複雑化・大規模化に呼応して、プロジェクトの人数も増え、必要に迫られてコミュニケーションのプロセス（“紙とハンコ”）が産まれてきたのです。

いま、問題の原因となっているやり方の多くは、そもそもは、大規模化に直面して発生した問題の“解決策”として産まれてきたのです。

であれば、小規模から始まったアジャイルをより大規模に適用するには、同種の問題に直面するであろうことが予想されます（歴史は繰り返すのです）。

Jazzテクノロジーでは、アジャイルのメリットをより大規模なプロジェクトでも享受するためのポイントとして、次の点に焦点を当てています。

• 実績データに基づくリアルタイム性と透明性
• プロセスのコントロール
• アジャイルスタイルに即したリソースマネジメント

では、ひとつひとつを見ていきましょう。

図1：（動画）ツールによるコラボレーションの例

実績データに基づくリアルタイム性と透明性（1）

形骸化した進ちょく管理

形骸化した運営の代表選手が、進ちょく管理ではないでしょうか？（いきなり、怒られそうですが…）。「ソフトウエア開発とは、本質的に不確定要素が多く 高い精度で予測することが難しい。だから実績ベースの管理に切り替える…」SCRUMで一躍脚光を浴びたタスクベースの管理やバーンダウンチャートによる リリース予測は、その判断の基礎を過去の（どこの誰かもわからぬ人の）経験値ではなく、「いま、そこにあるチームの実績」に基づくという意味で、進ちょく 管理のあり方を根本的に変えてしまいました（進ちょく管理という表現自体が適しているかどうかも疑問ですが）。

しかし、プロジェクト規模が拡大することを考えると、アジャイルでいうタスク管理に加えて次の要因を考慮しなければなりません。

少人数チームであっても、タスクの集合だけでチームの状態を把握しているわけではない。

アジャイルでタスク管理というと、壁一面にポストイットでぺたぺた…、すっかりおなじみのイメージですね。しかし、プロジェクト規模が拡大して、チーム が複数になったり、オフショア等で分散体制になると、途端にタスク状況を共有できなくなってしまいます。「そんなの共有DBで管理すればいいじゃん」…そうでしょうか？

少人数の開発者がひとつの部屋で共同作業するという中で、私たちは多くの情報を暗黙のうちに“直接”やり取りしています。例えば、

「体調がわるそう」

「思った以上に難題が多くて、作業がたまっているね」

「以前の仕事の割り込みが多いね」

特に分散開発をしている場合に各作業者の作業がどのような状態になっているか、作業が集中しすぎていないか、そのリアルな状況を把握するのは難しくなり ます。結果、適切なタイミングで開発者をサポートすることができなくなってしまいます。