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

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

[後藤章一，豆蔵]

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

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

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

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

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

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

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

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

人手による構成管理

構成管理とは

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

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

ツール試行の結果による課題の認識

　このような状況は幾人ものプロジェクトマネジャーからの報告を通して認識されており、Z社では標準推進部署にA氏をリーダーとするプロジェクトチームを設立し、構成管理活動の改善に着手した。

　プロジェクトマネジャーからの報告によると、何よりもまず「構成管理に要する工数や作業負荷、属人的なエラーが無視できない問題」だという。そのためA氏は、「属人的なエラーを減らすことで構成管理の品質を高め、また管理負荷を下げることで工数をもっと有効に活用できるようにする」ことをまず目標に設定した。

　属人性の排除・管理作業の効率化という面から、最も効果的な解決策として、組織的な構成管理ツールの導入が検討されることになった。

構成管理ツール導入による解決

　A氏は早速、必要な機能についてプロジェクトマネジャーや技術リーダーの意見を収集し、ツールの選定を行った。選定された構成管理ツールのセットアップ方法や使用方法をドキュメント化し、パイロットプロジェクトへ適用した。すると、管理負荷の削減やファイルサーバ管理者のミスによるファイル散逸がなくなるなど、すぐに期待通りの効果が得られた。

　しかし、全社的な展開となると、標準推進部署が集中的にサポートできるパイロットプロジェクトとは事情が異なってくる。以下のような問題が明らかになった。

• リポジトリ（成果物の保存領域）内の構成が統一されていなかった

複数のパイロットプロジェクトでまったく異なるディレクトリ構成が設定されていた。また時系列でディレクトリを切るなど、ファイルサーバのやり方をそのまま踏襲している例もあった。標準推進部署は、リポジトリの構成に対して相談に乗るなどのサポートを行わなければならなかった。

• 管理対象の成果物が統一されていなかった

リポジトリに格納される成果物がプロジェクトによってバラバラであった。また、プロジェクトによっては、ビルドされたすべてのバイナリをリポジトリへ格納したことで、その挙動が重くなってしまうこともあった。標準推進部署は、どのような成果物をどのタイミングから格納すべきか、プロジェクトに対する提案を行わなければならなかった。

• ツールのセットアップや運用に手間が掛かった

リポジトリのセットアップやバックアップ、リカバリの手順を示したマニュアルはあったが、リポジトリのセットアップ上のトラブルやバックアップ手順のミスなどに対して、標準推進部署が個別にハンズオンでサポートしなければならなかった。

• 他部署が提供するツールとのすみ分けが整理されていなかった

Z社には開発標準や技術基盤を共通的に運用する標準推進部署とは別に、品質指標の設定とその実績に基づく品質改善を推進する品質管理部署が存在した。その品質管理部署に対する報告書類を作成する自家製ツールの利用がプロジェクトに義務付けられていたが、このツールの対象領域と、今回標準推進部署が導入を進めた構成管理ツールの対象領域が部分的に重複していた。部署分掌にかかわることもあり、どちらを優先すべきかといった相談が標準推進部署に多く寄せられた。

　これらはツール自体というよりも、その周辺を取り巻くさまざまな事情による課題である。問題が起こるたびに標準推進部署に問い合わせる必要があるのでは、ツール利用のハードルが高くなってしまう。そこでツールの展開に先立ち、A氏はこれら周辺課題への対策に着手することを決めた。

「穴埋め」と「プロモーション」の二面作戦

　冒頭で取り上げたようなツール導入に対する懐疑的なイメージは、Z社でも一部の開発者に持たれていた。この点については標準推進部署でも、パイロットプロジェクト適用以前から課題として認識されていた。そこで、組織のツールに対する理解を醸成し、積極的な活用を推進するため、周辺課題への対処施策のWBS（Work Breakdown Structure）には必ず社内のイントラネットへの掲載や説明会を開催するなどの「プロモーション」を意識したタスクが設定されることになった。

ツールが提供する機能を取り巻く整備事項

　プロジェクト計画の策定時には、以下の内容を構成管理計画として決定しておく必要がある。

• リポジトリの標準的なディレクトリ構成はどのようなものか
• どこにどのような成果物を格納するべきか
• 構成にベースラインを設定する推奨タイミングはどこなのか
• ベースラインをツールの上でどのように表現するのか
• これらを決定するのはプロジェクト上の誰で、管理を実行するのは誰なのか

　A氏は現場のプロジェクトマネジャーの協力の下、標準推進部署からひな型をあらかじめ提供して、プロジェクト間の差異を小さくした。

　また、Z社の開発者であれば誰がリポジトリを探してもすぐ目的の成果物にアクセスできるルールを策定した。この際、このようなルールを設定する理由を明確に説明するために、理想的な姿を具体的に文書化したことも説明資料として役に立った。例えば、「統一されたリポジトリ構成ルールがあることで、すべてのプロジェクトの基本設計書類一式がどこにあるかについて、わざわざリーダーが説明する時間を設けなくても、Y部長自らがリポジトリにアクセスすることで解決できる」といったものである。

　さらに、ツールのセットアップや運用に関する課題に対しては、ルールを実現するための仕組みをツールに取り入れる以下の施策が実施された。

• 展開するだけで規約に従った状態のリポジトリを使用できるアーカイブを配布する
• バックアップやリストアを簡単に実行できるコマンドセットを事前に用意して提供する

など、スタートアップ・運用負荷削減の仕組みを積極的に提供した。

　これらの仕組みはツール本体と併せて、イントラネットの標準推進部署ページから気軽にダウンロードでき、その情報は社内グループウェアのトップページに掲載されるようになった。

　さらにA氏はツールを提供している他部署との打ち合わせを実施し、相互の提供ツールのすみ分けを明確に設定した。前述の例では、品質管理部署への報告書類を生成するスクリプトを構成管理ツールの提供セットに含めることで合意して、解決に至った。この合意内容は両部署責任者の承認の下で社内全体へ正式に通達され、個々のプロジェクト担当者が心配することはなくなった。

　このようにツールを取り巻く周辺を整備していくことで、パイロットプロジェクト適用時に発覚した課題を1つひとつつぶしていき、プロジェクトがツールを導入する際の障壁を低くしていった。

　また、「ツール周辺の穴」を埋める作業と並行して、ツール自体の利便性を周知し、プロジェクトが自主的にツールを利用していくようなモチベーションを醸成することを目指し、デモンストレーションを定期的に開催する活動も行われた。これらの情報はイントラネット上で随時、告知や報告がなされた。

ツール導入に向けての二面作戦

機能そのもの以外に目を向けることが必要

　今回は、ツールの機能そのものよりもその周辺に労力を割くことで、ツールの導入を成功させた事例を紹介した。以下に重要だと考えられるポイントをまとめる。

作業を踏まえた利用・運用ルールや規約、仕組みを提供する

　標準化推進の一環として、ツールの導入による負荷の低減、属人性の排除は、さまざまな問題の解決策として有効な選択肢の1つである。ただし、ツールの利用を宣言し、プロジェクトへ放り込むだけでは積極的な利用は望めない。

　ツールを利用する方法はもとより、それを取り巻く開発作業を踏まえた利用・運用ルールや規約、その実現の仕組みを併せて整備し、ツールを利用することによる負荷や混乱を極力避ける施策を打たなければならない。Z社では、規約やルールを個々のプロジェクトに意識して守らせるのではなく、あらかじめ規約に沿った構成のリポジトリを用意したり、運用の機能をツールと併せて提供したりすることで、現場の負荷や導入の混乱を低減することができた。

ツールの有効性や活動内容をプロモーションする

　ツールに関する事前の説明や宣伝なども、しっかりと行っておくべきである。実際のところ、現場の開発者たちが提供されたツールを使うに当たり、そのツールの利便性やメリットを事前に認識している例が非常に少ない。メリットがなければ、当然ながら積極的にツールを使ってはもらえない。ツールを利用することによって解決される問題やメリットについて、まず開発者に理解してもらうのだという認識を持つことが重要である。Z社では、ツールの展開に合わせて、継続的に説明会やイントラネット上でその目的を説明したり効果をデモンストレーションしたりすることで、開発者の理解を得ることができた。

　また今回の事例では、標準推進部署から「今、どのような課題に取り組んでいるのか」「どういう解決策が取られたか」という情報がリアルタイムに公開されたことによって、参加者意識が社内に醸成されたことも、ツールの展開に効果的であったと考えられる。これは展開活動中に標準推進部署へツールの問い合わせがあったことからもうかがえる効果である。

ツールの利用範囲と責任範囲を明確化する

　今回は構成管理の事例を紹介したが、ツールがさまざまな領域で利用されるためには、複数のツールの適用領域とその使用義務を明確に説明できるようにしておかなければならない。特に大企業においては、同じ領域をサポートする複数のツールが使用義務付きで提供され、現場ではどちらを使ったらよいのか判断できないケースも起こり得る。共通的な支援部署が複数あるような企業では、展開前に既存ツールがカバーする領域と、今回導入するツールがカバーする領域が重複していないか、重複した場合はどのようにすみ分けるのかといった調整を、社内組織が事前に行っておくべきである。

　いちいちプロジェクトごとに配慮しているようでは、実効性のあるツール利用が求められるはずもない。Z社では、パイロットプロジェクトでの試行段階でその問題を把握できたため、全社への展開前に調整を行いその結果を公開することで、現場での混乱を未然に防ぐことができた。

標準推進部署への積極的な協力を

　ツール導入などの標準推進はトップダウンで行われることが多いが、それだけに開発現場のメンバーのモチベーションを高める努力を惜しんではならない。逆に、モチベーションを低下させる要素を試行適用から特定し、それを展開する前に丁寧につぶしていくことを心掛けるべきである。

　今回の事例では、ツールの選定からパイロットプロジェクトでの試行と課題の特定、その解決などについて、現場のプロジェクトマネジャーに多くの協力を得ている。現場のモチベーションを低下させる要素や問題点については、現場の人間が一番よく分かることもあり、プロジェクトマネジャーの成功への貢献は極めて大きかったと考えられる。

　プロジェクトの運営に多忙を極めているプロジェクトマネジャーにとって、標準化推進に協力することは大きな負担となってしまうかもしれない。しかし、個々のプロジェクト運営上の課題には、その組織自体に根本的な原因があることも多い。

　今回の事例のように、現場を熟知したプロジェクトマネジャーが組織的な標準化活動に関与し、現場で起きている具体的な問題や状況の報告、対策の協議、改善効果のフィードバックなどを積極的に行うことで、より組織の実態に沿った実効的な標準化活動が実現できる。それにより組織全体としての能力を高め、結局は個々のプロジェクトの問題を減らし、より楽にプロジェクト運営できることにつながるだろう。

　また、個々のプロジェクトがうまく回れば、組織全体としての競争力や収益力を高め、さらなる業務改善へ割く予算や余力も生まれる。組織的な標準化活動の大きな目的の1つは、この好循環の輪を作り上げることでもある。

　もし今後、ツール導入に限らず組織的な標準化活動への協力要請があれば、積極的な参加を検討していただきたい。なぜなら、プロジェクトマネジャーが参加することで、自分のプロジェクトのみならず、組織に大きく貢献することにつながるからだ。

＜筆者紹介＞

後藤章一氏

株式会社豆蔵 BS事業部　エンタープライズチーム　コンサルタント

専門分野：開発プロセス策定、標準化推進

ユーザー企業での社内SEから、システムインテグレーター数社でのシステム開発、技術調査、教育などの業務に携わり、2006年より株式会社豆蔵に在籍。開発プロセスや開発標準の策定・適用支援、オフショア開発推進支援などに従事している。

関連ホワイトペーパー

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