チームの詳細
ここで、組織のフォーメーションの話としてメンバーの役割について説明する。最小単位は各チームとなるが、分散したチームはどのようなコミュニケーション手段を使っても生産効率が悪くなってしまう。このため、アーキテクチャとチームの編成、そしてロケーションはできるだけ密にするよう意識している。また、Team Concertでは階層型のチーム構成を採用しており、それぞれの階層にリードを置くことで、チームの力を最大限に引き出せるようにしている。
また、チームにはそれぞれリードがいて、チーム参加の個々のメンバーとデイリーやウイークリーのミーティングを行い、コンポーネントリードに報告する。コンポーネントが大きくなると複数のチームが傘下に入るため、コンポーネントリードはチームリードと密に連絡を取ることになる。このようなコンポーネントが世界中に分散しているため、これらの最上位としてプロジェクト・マネージメント・コミッティ（PMC）が存在する。PMCは、コンポーネント間の調整や、コンポーネントの集合体である商品の最終的な意志決定を行う。
実際にJazz Projectで計画して使用されるものには、障害レポート（Defects）、タスク（Tasks）、機能拡張（Enhancements）、ビルド・ステータス（Build status）、レトロスペクティブ（Retrospectives）、計画項目（Plan Items）、ストーリ（Stories）、RFS itemsがあり、これらを追跡していくことになる。またワークアイテムでは、Plan Item（フィーチャー）、ストーリー（Story）、タスク（Task）の3つが使用される。
プロジェクト管理のポイント
なお、お客様との話の中でよく質問されるのは、もっと上のレベルのものが多い。一つは「全体のプランはどうするのか」というもので、一般にアジャイル開発では業務を短いストーリーに区切って進めていくが、それで本当に必要な機能がもれなく実現できるのか？ という質問だ。ウォーターフォールのプロジェクトでは、初期にがっちりと決めた機能を粛々と開発していくが、議論にブレが生じることは避けられない。全体像を決めずにフィードバックだけで、予算と期間の枠内で、十分な機能を持たせることができるのか、というのである。
Jazz.netではさまざまなフィードバックを受け付けることで、リリース計画のコントロールが必要になる。そこで、プロジェクトが本来達成すべき要求などを確認するために、4つの構造となっている。基軸になるのは「ストーリー」で、ここにシンプルな操作イメージを載せていく。ストーリーに対してもう少し抽象度の高いものが「フィーチャー」である。さらにこの上に「テーマ」があり、ここでは大枠を固めている。
アジャイルの解説では、ストーリーに関連する話が多く、全体感をきちんと説明しているものが意外と少なく、それがもともと達成しなければならないことに対して漏れや抜けがないかという不安感につながっているように思う。アジャイルでは抽象度に応じて内容を切っているので、より上位の部分ではブレを気にしない。なお、テーマで設定する定義はシンプルで「エンタープライズ」「スケーラビリティ」「セキュリティ」それに「他の製品との連携」「セットアップのやり方」「メンテナンスの簡易さ」という程度である。
実際の流れとしては、商品として考慮しなければならないこと、漏れや抜けがあってはならないことはテーマで大枠を固めておき、製品に求められていることをフィーチャーで定義する。これを実際に形にするためにどう動くのかはストーリーで決めて、ストーリーを実現するためにタスクを切っていく。フィードバックについては、それに対してこのような機能を提供しましたということを明確にしたnew ＆ noteworthyというドキュメントを作成する。これによって、全体的な視点でどのような方向に向かっているか、何がどのくらい達成できているのかといった状況を把握できる。
もう一つの質問は、フィードバックにおける「好き勝手」をどうするのかという問題だ。これには、不特定多数の、いろいろな利害関係者がいる中で、いい意味で議論の方向性を誘導していく必要がある。具体的には、フィードバックのポイントを絞り込み、それに対して適切なフィードバックをもらう。また、どのようなフィードバックが欲しいのかをきっちりと定義して、フィードバックの質を上げていく。これはプランニングとnew ＆ noteworhtyで対応していくことになる。
