 |
|
なぜあなたのプロジェクトは火を噴くのか？
プロジェクトマネージャ編：チームが思いどおりに動かない！ |
これまで何度もソフトウェア開発の経験を重ねてきた。それなりにスキルも経験もある開発者をアサインした。にもかかわらず、開発プロジェクトは毎回必ず火を噴く。そう、プロジェクトマネージャの努力を嘲笑うかのように、カットオーバが間近になれば部下たちからは悲鳴のような報告が寄せられ、バグやトラブルを収めるために徹夜が続く……そんな経験を持つ方は決して少なくないはずだ。
なぜ開発プロジェクトはいつも火を噴くのだろうか。
| |
［疑問1］ ユーザー要件と開発チームから出てきた成果物が異なる |
| |
ユーザーと設計者の間でシステム要件はフィックスしていたはずだ。しかし、いざできあがってきた成果物を見れば、もともとの要件とは似ても似つかない代物。いったい、どこで誰が何を間違えてしまったのだろう……？ |
| |
［疑問2］ 各チームで作成したモジュールが全体のシステムに組み込めない |
| |
開発の初期段階で、システム全体で使えるアプリケーションフレームワークを作成した。チーム間のミーティングも定期的に綿密に行われていた。だが、全体を組み合わせてみたら、つながらない、組み込めない。あの長時間のミーティングは何だったのか？ |
| |
［疑問3］ カットオーバー直前。原因不明のバグが解消されない |
| |
バグが次のバグを生み、デバッグがまた別のバグを引き起こす。十分な単体テストも行っていたはずなのに、なぜカットオーバー直前でこんなことになってしまうのか。開発者のスキルも決して低くはなかったはずなのに……。 |
このような問題を解決するために、皆さんはどのようなアプローチを取ってきただろうか。
- 人員の更なる強化・育成
- 開発ドキュメントの整備
- チーム間におけるミーティング回数の増加
- 開発者個々人からの報告の徹底
しかし、これらの方策がさほどの効果をあげなかった（あるいは、逆効果だった）ことを、恐らく肌身をもって知っているはずだ。それは、もはや開発レベルにとどまらない――プロジェクト自体を支える「コミュニケーション」レベルでの問題であるといってよい。以下のような点に、思い当たる節はないだろうか？
| |
［ポイント1］ 設計者と現場の伝言ゲーム |
| |
ユーザーと要件を整合する設計者から現場のプログラマまでに、何人も介在する。電子メールやドキュメント、ミーティングなどを何度も介して伝えられた要件の「伝言ゲーム」が、果たしてどこまで正確にチーム全体に伝わっていただろう？ |
| |
［ポイント2］ すべてプライオリティAのアクションアイテム |
| |
カットオーバー直前にトラブル続出。何とか納期に間に合わせるべくアクションアイテムを洗い出してみたら、出てきたプライオリティはすべてAランク。しかし、それは客観的に見て、正しいランク付けだったか？ |
| |
［ポイント3］ 形骸化したドキュメントと断絶したコミュニケーション |
| |
ユーザー要件定義書、機能概要説明書、プロセス定義書、編集仕様書、チェック仕様書……多くのドキュメントは作成した。しかし、それぞれのドキュメントはリアルタイムに更新されていたか？
設計からコーディングの現場までを、ひと連なりのドキュメントが支えていたか？ |
| |
［ポイント3］ 報告とミーティングの嵐が工数を圧迫 |
| |
チーム全体の意識を整合するのが第一の道。日々の定例報告に加え、チームリーダーには日々の整合会議。個々の開発チームにも朝礼・昼礼の実施を徹底させた。しかし、これらのコミュニケーションがメンバーの工数を極端に圧迫はしていなかったか？ |
そう、「火を噴くプロジェクト」が依然解消していないとしたら、それは問題に対する対処法を間違えているからにほかならない。コミュニケーションは、決して実作業、実際のプロジェクト進行と切り離して語れるものではない。しかし、上記問題の根底には、「実作業と断絶したコミュニケーション」「コミュニケーションのための実作業」という問題がなかったか。
ここでわれわれは、プロジェクト進行とコミュニケーションとの融合にいま一度目を向ける必要がある。本稿では、その1つの代表的なソリューションとして、Borland
StarTeam（以下StarTeam）を紹介する。それは単なるツールではなく、ボーランドからソフトウェアマネージャと開発者に向けたプロジェクト改善への提言でもある。
Software Configuration Management（ソフトウェア開発のプロセス管理）というと、ドキュメントやソースコードのバージョン管理という図式だけが先行してしまうきらいがある。事実、これまでのSCM製品の多くが「バージョン管理ツール」に終始してきたのも事実だろう。
しかし、ソフトウェア開発の管理がそのような一面的なものでないことは、前述したとおりだ。SCMとは、要件管理、変更管理、障害追跡、ファイルのバージョン管理、スレッド・ディスカッション、およびプロジェクト・タスク管理など、開発に携わるすべての人間の「コミュニケーション」支援・管理にほかならない。語弊を承知でいうならば、StarTeamとは、ソフトウェア開発に携わるプロジェクトメンバー全員のための「総合グループウェア」製品であるといってもよい。
| |
すべてのリソースをセントラルリポジトリで保管・監視 |
StarTeamはセントラルリポジトリによって、変更要求、タスク管理、要件、ナレッジベースとなるトピックおよびそのほかのユーザー定義オブジェクトなど、重要なプロジェクト資産のすべてを一元的に管理する。つまり、プロジェクトにおける現在のスナップショットを知るために、さまざまなデータストアを検索する必要がない。いつでもどこからでも、管理者を含むチーム全員が同一のプロジェクト資産にアクセスできる。
 |
| 画面1 StarTeam Clientで現行プロジェクトに関係するすべてのアイテムを把握可能（画像をクリックすると拡大表示します） |
| |
ファイルコンポーネントでプロジェクトリソースを横串管理 |
ファイルコンポーネントは、単純に仕様書やソースコードのバージョン管理ができるだけではない。ファイルのチェックインに際して自動的にリンクを生成することで、特定バージョンのリソースとのリンクを実現し、ある特定時点でのスナップショットをプロジェクト横断的に確認できるのだ。この特性は、開発・改定の履歴を管理するにとどまらず、障害発生時の問題特定に際しても極めて有効だ。
 |
| 図1 プロジェクトリソースの横串管理 |
これらのリソースを個々の情報レベルでアクセス制御できるので（マルチビュー）、複数の組織がかかわるプロジェクト案件でも安全なチーム連携が可能である。
| |
トピックコンポーネントで人に依存しない知識ベースの構築を |
トピックコンポーネントは、いわゆるオンライン・ディスカッション機能だ。従来、電子メールなどで単発的にやりとりされていた情報を、リポジトリにナレッジベースとして保存することが可能となる。
これは、議論に参加していなかったメンバーに対しても決定経緯を透明化できるというだけではない。例えば、システムのカットオーバー後に開発当初のメンバーがいなくなったとしても、開発当初の設計思想を見返すことが可能となるのだ。プロジェクトを重ねるごとに、（人ではなく）組織として、これまで仕様書には現れてこなかった暗黙の知を蓄積できるのは、StarTeamならではの機能である。
StarTeamの要求コンポーネントとBorland CaliberRMの統合によって、プロジェクトの要件管理を一元的に実現できる。従来、メンバー（あるいはサブチーム）個々に委ねられていたドキュメント管理が平準化されることで、要件の粒度が均質となる。すなわち、個人のスキルによる要件定義のレベル格差も出にくくなり、要件の伝達に伴うミスリーディングの低減も期待できるだろう。
また、個々の要件をグラフィカルなトレース画面でマッピングできるので、要件の変更に際しても、影響範囲を視覚的に特定できる。変更要求が実行されたか否かの検証および適切な部門への通知も、変更要求コンポーネントがすべて一元的に管理する。
 |
| 画面2 トレースマトリックス・ダイアグラム（画像をクリックすると拡大表示します）
|
| |
既存ツールへの投資を無駄にしない
SCC APIへの対応 |
StarTeamは、SCC（Microsoft Source Code Control）APIに完全準拠することで、開発ツール製品と直接統合できる。さらに、StarTeamはオープンアーキテクチャを採用しているため、ファイル、変更要求、タスク、トピック、要件をさまざまなアプリケーションと連携して利用することが可能だ。つまり、すでにある開発ツールやプロジェクト管理ツールへの投資を無駄にする必要はない。従来のツールを継続利用しつつ、リポジトリの統合だけをStarTeamに委ねることができるのである。
◆
以上、StarTeamによるプロジェクト管理（いや、コミュニケーション管理というべきかもしれない）の改善を見てきた。もちろん、これらの製品がコミュニケーションを不要にするわけではない。コミュニケーションの質を改善し、「従来のコミュニケーションと補完関係を築く」といった方が正しいだろう。
いずれにせよ、これらはプロジェクト全体を見極めたい「プロジェクトマネージャの視点」である。翻って見れば、これらのツールに「束縛される」現場作業者の視点を忘れてはいないか。これまで多くのツールを導入し、失敗してきた。それは、プロジェクトマネージャと現場開発者との意識の乖離であった。そして、現場不在の理想とツールの導入であった。
「プロジェクト・コミュニケーション」を現場開発者の視点からいま一度見直し、現場開発者の視点からコミュニケーションツール導入の是非を検討してみたい。
|
