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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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