現場の抵抗勢力も納得する「ツール導入術」：プロジェクトマネジャーに贈るプロセス改善事例 第3回

プロジェクトでツール導入やその検討をした経験があるだろう。その有用性は理解できるが、業務の妨げになると疎まれることもある。今回はツールを効果的に導入し、構成管理上の問題を解決した事例を紹介する。

[後藤章一，豆蔵]

「ツール導入」は標準化推進の鬼門？

　開発ツールはさまざまな機能と利便性を提供してくれるものだが、組織内における開発業務の標準化を推進する上では、その導入は鬼門だと思われることが多い。特に、使いづらいツールや実効性に乏しいツールをトップダウンで展開した経験を持つ組織では、「ツールの導入による効率化」などという文言を見ただけで、「結局は無駄な労力になるだろう」と拒否反応を示される場合もある。読者の中にも同様の認識を持っている方がいるのではないだろうか。しかし、ある課題に対してツールの導入による解決を図ることは、本来有効な選択肢となるはずである。

　今回は、社内の標準推進部署と現場が協力し、構成管理の問題に対してツールをうまく導入して解決を図ったZ社の事例を紹介する。プロジェクトマネジャーのみならず、自社内の標準化推進業務を担当している方にも、開発現場との連携に役立つ事例としてぜひ読んでいただきたい。

膨らむ管理工数、属人的な品質管理

　数千人規模のシステムインテグレーターであるZ社では、入社数年の若手エンジニアに対して、プロジェクトの成果物を格納するファイルサーバ管理者の役割を割り当てていた。プロジェクト用ディレクトリには、あらゆる計画書や設計書、ソースコードなどが格納されている。そこからファイルを出し入れする際には管理者に申請する必要があり、管理者は取り出しや格納オペレーションを行った上で、それらの記録をExcelの一覧表で管理していた。

　開発が佳境に入ると、管理者はファイルのやりとりに忙殺されて作業が雑になり、サーバ上のファイル構成が崩れ、「最新の設計書がどれなのか分からない」「ある設計書と別の設計書で更新内容に矛盾が生じる」「デグレードが頻発する」などの問題が起こりがちだった。

　また、別のプロジェクトでは、チーム間での共有とチーム内での管理のために、ファイルサーバと構成管理ツール（バージョン管理ツール）を混在させて成果物管理を行っていた。事前の取り決めがなかったこともあり、「どちらに格納されている設計書が正本なのか」「どのソースコードがリリース対象なのか」などがすぐには判断できず、リリースのたびにチーム内外への確認作業が必要となり、進ちょくに影響することがあった。

　このようにZ社では、部署やプロジェクトごとに成果物の管理方法が異なっており、要員が新しくプロジェクトへ割り当てられるたびに、書類の格納場所の確認や更新ルールの統一などを行う手間が生じ、プロジェクトのスタートアップを遅らせる一因ともなっていた。

人手による構成管理

構成管理とは

　構成管理とは、プロジェクト実行中に作成されるあらゆる成果物を一元管理し、それら全体の一貫性と整合性を維持する活動である。構成管理下に置かれている成果物は、その変更の軌跡をいつでもたどることができ、あるタイミングでリリースされた成果物のセットを、いつでも容易に取り出せなければならない。

　プロセス改善モデルのスタンダードともいえる「CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）」の段階表現において、構成管理は最初に取り掛かるべき成熟度レベル2のプロセス領域の1つとして定義されている。このことからも、その重要性が強く認識されていることが分かる。

関連ホワイトペーパー

プロジェクトマネジメント | 品質管理 | グループウェア | バージョン管理