なぜあなたのプロジェクトは火を噴くのか？ 　 現場開発者編：マネージャは現場が分かっていない！

　プロジェクトマネージャ編では、プロジェクト開発におけるコミュニケーションの重要性と改善への提言、そして、そのインフラストラクチャとしてのBorland StarTeam（以下StarTeam）について概説した。

　しかし、いま一度考えてみてほしい。

　これまでも多くのプロジェクト管理、コミュニケーション支援ツールを導入してきた。プロジェクトマネージャの視点から見る限り、これらツールは決して「できの悪いもの」ではなかった。それなりの検討もしたし、理想的な活用プロセスも想定したうえで導入したはずだ。しかし、その多く（あるいはすべて）が途中でとん挫してしまった、使われなくなってしまったのはなぜだろう。

　そこには、現場との明らかな乖離がある。

　プロジェクトマネージャは「プロジェクトを把握し、全体にプライオリティ付けと適切な人員のアサインを行う」のが仕事だ。しかし、現場開発者にとっての仕事とは、「自らに与えられた仕事をいかに効率的に、正確にこなすか」である。現場開発者にとっては、変更要件が適切に自分に伝えられるのはマネージャの仕事であるし、いわれたとおりに作業してプロジェクトがうまくいかないとしたら、それは「マネージャへの不満」となる。だからといって、メンバー全員の意識を整合し、全体を把握するために「現場開発者自身の仕事が増える」としたら――多くの場合、その余剰分の作業は徹底されない。なぜなら、それは現場開発者の「一義的な仕事ではない」からだ。

　つまり、現場開発者にとって、プロジェクト管理は自らの作業プロセスに「自然に」組み込まれているものでなければならない。作業とコミュニケーションとがひと連なりのフローとなっていなければ、そのコミュニケーションは成り立たないし、継続も定着もあり得ない。

　そこで本稿では、現場開発者のツールとしてのStarTeamに立ち返ってみる必要があるだろう。

　StarTeamとは、ソフトウェア開発メンバーにとっての「グループウェア」のようなものである。単なる「プロジェクト管理ツール」でも「ソフトウェア開発支援ツール」でもない。あえていうならば、ソフトウェア開発にかかわる――ということは、すべての作業プロセスを一気通貫する「コミュニケーション」管理のためのツールなのだ。

　「コミュニケーション」プラットフォームとしての観点からStarTeamを概観したとき、StarTeamがその機能性以上に、ユーザビリティに重点を置いた設計がなされていることを理解いただけるはずである。

　以下は、StarTeamと周辺を取り巻く関係コンポーネントをまとめたアーキテクチャ図である。

図1　StarTeamのアーキテクチャ

　図1を見れば分かるとおり、StarTeamには専用のStarTeam Win32クライアントが標準で用意されているが、それはStarBaseサーバにアクセスするための「一手段」にすぎない。StarGateを介することで、StarBaseサーバはアクセスするクライアントを選ばない。Borland JBuilderをはじめ、Microsoft Visual StudioやEclipse、Togetherなど、主要なクライアントと容易に連携できる。

　つまり、StarTeamを導入したからといって、ユーザー（現場開発者）の操作は何ら変わることはない。いつもどおりのインターフェイス、いつもどおりの手順で作業を進めていけば、ナレッジベースが自然とセントラルリポジトリに蓄積される――それこそがStarTeamアーキテクチャの魅力である。

　StarTeam SDK（Software Development Kit）は、Java、COM（Component Object Model）、.NET Frameworkに対応したAPIだ。StarTeam SDKを利用すれば、必要に応じてカスタムクライアント／ソリューションの開発が可能となる。もちろん、カスタム機能開発に際してはJBuilderやVisual Studio .NETなど、使い慣れた開発環境を利用することができる。

画面1　カスタムソリューションによって構築されたモジュールの例（画像をクリックすると拡大表示します）

　プロジェクトマネージャ編で述べた各種コンポーネントは、開発者にとってもコミュニケーションを効率化する有用なツールだ。

　例えば、トピックコンポーネントを利用すれば、これまで設計の決定経緯からは遠ざけられがちであった現場開発者も含めて状況認識の共有が可能となるから、より手戻りの少ない開発が望めるだろう。

　タスクコンポーネントは、Microsoft Projectとの統合によって、チームメンバーに対するタスクの割り当てとリアルタイムな実績管理を実現する。これによって、プロジェクトマネージャは個人の負荷状況を適確に判定し、一個人への負荷集中を未然に防ぐことができる。

画面2　タスクコンポーネントの管理画面（画像をクリックすると拡大表示します）

◆

　いかがだろうか？

　プロジェクトマネージャ編でも述べたように、StarTeamを導入したからといってコミュニケーションが不要になるわけではない。StarTeamは、無駄なコミュニケーションを省き、コミュニケーションの質を改善する土台である。

　ということは、これをきっかけに開発者自身も変わらねばならないということである。現場開発者にもプロジェクトの全体像が見えるようになったということは、開発者自身にもプロジェクトの全体像を把握したうえでの仕事が求められるということでもある。変わっていくべきは、プロジェクトマネージャだけではない。

　StarTeamをきっかけに生まれたコミュニケーションの改善は、プロジェクトマネージャと現場開発者と、プロジェクトにかかわるすべての人間を巻き込んだ、新たな開発プロセスの可能性でもあるのだ。

プロジェクトマネージャ編へ

チーム開発レベルを底上げする方法 トップページへ