PR

運用フローを整理して属人化を避ける

 2つめの運用フローの整理は属人化を避けて、誰が実行しても変わらない品質で構成管理をできるようにするのが目的だ。

 構成管理の業務は数多く、作業が遅れると開発チームやテストチームなど、プロジェクト全体の進捗に影響をきたす。そのため、場当たり的な修正でその場をしのいでいくことになる現場が多い。その場は乗り切れるが、場当たり対応が積み重なると構成管理担当者に依存した属人的なプロセスができあがる。

 属人化したプロセスは2つの問題を引き起こす。(1)構成管理以外の他チームから構成管理の状況が見えなくなる、(2)業務の引き継ぎが困難になる、といったものだ。

 他チームから構成管理の状況が⾒えなくなると、さまざまな問題が発生する。例えば、開発チームがプログラムをリリースしたくても、構成管理チームに依頼するためのリリース申請書の出し方が分からないという事態が生じたりする。リリース申請書を出せても記載不備でいつまでも構成管理チームとの不毛なやり取りが続き、リリースが予定通り行われないという事態もあり得る。このような状態になると、テストチームがテストスケジュールを立てることが難しくなる。

 業務の引き継ぎが困難になると、決まった担当者しか構成管理業務を実施できなくなる。その人が休むと、構成管理が止まってしまうのだ。各環境へのリリースや成果物管理が実施できなくなるといったトラブルも起こり得る。

 こうした事態にならないよう、プロジェクトに応じた構成管理の運用フローを定める。運用フローは一度定めて終わりではなく、プロジェクトを通じて常に見直しを実施する。見直し結果はプロジェクト全体で共有する。定めた運用フローや意図について、プロジェクトメンバー全員が理解するように文書化したり研修を実施したりしたほうがよい。プロジェクト中の運用フローを変更では、メンバーが意図を理解できるかどうかで浸透の速度が全く違う。

 構成管理の運用フローの例を図に示す。属人的な運用にならないように、このような運用フロー図を作成して、プロジェクトメンバー全員が理解しておくことが重要である。

構成管理の運用フローの例
構成管理の運用フローの例
[画像のクリックで拡大表示]

 この運用フローでは(1)開発者は払い出し申請を行い、構成管理者が本番用Subversion(構成管理SVN)からプログラムを取得して開発者に渡す、(2)開発者は払い出されたプログラムを自チームのSVNにコミットして開発を行う。日次ビルドで開発チーム間のデグレを早期に検出する、(3)開発が終了したら、開発チームの責任者が構成管理チームに受け入れ・リリース申請を行う、(4)構成管理チームが結合テスト環境にリリースする、(5)そのタイミングで構成管理SVNにプログラムをコミットする、(6)構成管理SVNから本番環境にリリースする、という流れで構成管理を行う。

 運用フローは構成管理の担当者が各フェーズ開始前に定める。前述した通り、運用フローは構成管理担当者だけでなく、プロジェクトメンバー全員が把握している必要がある。「次フェーズの構成管理の運用フローが定まっていること」をフェーズの終了条件にしておくとよい。

 運用フローは毎回ゼロから作成するのは手間がかかりすぎる。かといって、ほかのプロジェクトで利用した運用フローを安易に丸ごと流用するのは弊害がある。先人の知恵は大事だが、過去と全く同じプロジェクトは存在しない。そのため、全く同じ構成管理の運用フローも存在しない。プロジェクトごとの利用技術、開発手法、進め方に応じて、過去の運用フローをアレンジして利用する必要がある。

 過去の運用フローを単純に流用すると、そのプロジェクトには不要な意味のないプロセスが含まれていたりする。構成管理の作業工数が膨れあがり、プロジェクト運営のボトルネックになる場合がある。構成管理の実運用が始まってから問題が判明すると、運用と改善を同時に進めることになり苦労する。早い段階で検討する手間を惜しまないようにしよう。