Technical Notes
テクニカルノーツ
共通フレーム2013をベースに開発プロセスを見直してみた その3
前回のおさらい
「共通フレーム2013」を入手し、開発プロセス再構築についてのディスカッションを繰り返した結果、問題の本質を把握することの重要性に気が付いたのでした。
現場の声
「現場」を「開発部」とした場合、と「経営層」とした場合では、問題の質が大きく異なることがわかります。
■開発部の声
- 当時の担当者がもういないようなシステムの改修依頼が来た際、改修の経緯がわからず、仕様判断に困ることがある。
- プロジェクト用ファイルサーバーはプロジェクトごとに管理方法が異なるので、最終成果物を探すのが難しい。担当者が退職した場合だと、引き継ぎから漏れたプロジェクトの最新ソースを探すのに一苦労した。
- 過去の見積契約内容をたどりたい場合、見積番号を調べにくい。現状では見積書ファイルは顧客名+案件名等で管理されているが、見積番号はファイルを開かないとわからない。
■経営層の声
- プロジェクトを横断的に進捗把握できるツールがないため、個人の主観が混じった進捗報告を個別に聞いている。
- 小規模案件を多数受注している場合、誰があいているのかわかりにくい。対応期限でスケジュールが引かれているケースもあるため、案件引合時に空きリソースを判別しにくい。
開発部からの声は、構成管理にまつわる内容が半数をしめており、引合から保守作業の情報と成果物との紐づきに問題が集中していることが分かりました。
経営層からは、状況把握に関する内容が主であり、プロジェクト状況の共有方法について課題があることがわかりました。
まずは構成管理プロセスの見直し
現状の構成管理は、Subversion、Git、VSS、TFSなどの構成管理システムがプロジェクトごとに構築されている状態です。また、ファイルサーバー上に開発機を仮想マシンごと格納するといった特殊なケースもありました。
構成管理の対象も、ソースファイルだけのプロジェクトもあれば、リリースモジュールを含めているもの。ドキュメントも構成管理システムに格納しているものもあります。
「共通フレーム2013」によると、「ソフトウェア構成管理プロセス」と比較すると、
a) ソフトウェア構成管理戦略が作成されている。
→構成管理手順は個別に作成しているケースもありますが、構成管理の手順がルール等を文書化したものはありません。b)プロセス又はプロジェクトによって生成される品目が識別され、定義され、ベースライン化されている。
→管理対象のベースライン。。。ありません。c)品目の修正及び、リリースが制御されている。
d)品目及び修正の状態が記録され、報告されている。
e)品目の完全さ及び一貫性が確保されている。
f)品目の保管、取扱い及び納入が制御されている。
→リリースの単位ごとにタグ打ちしているプロジェクトもありましたが、多くのプロジェクトでは、コミットをしているだけの状態です。→チケットシステムと構成管理システムが連動していないため、コメントを頼りにトレースすることになります。厳密な管理はできていません。
かいぜん
社内の構成管理サーバーをGITに統合し、ガイドラインを設けることにします。
ソフトウェア構成管理のガイドライン抜粋
- 管理対象物を次の通りとする。
- ソースプログラム
- ソフトウェアビルドに関するコンフィグレーションファイル
- 納品対象のプログラム実行ファイル
- 納品対象のドキュメント
- 納品対象のコンフィグレーションファイル
- 管理対象物は、構成管理サーバー(資産管理番号 XX-XXXXX)で管理する。※GIT利用手順参照
- リビジョン設定のベースラインを次の通りとする。
- リリース・納品時
- 管理対象物を社外へ提供する時
構成管理サーバーに過去資産を移行し、社内に周知しました。
社内周知の抜粋
寄せ集めであるわれわれのGitリポジトリは弱さではなく、力であることを知っている。われわれはSVN教徒、VSS教徒、TFS教、Git教、そして無信仰の人々の開発部である。帯広市内から来たさまざまな開発文化がわれわれを形づくっている。われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋を味わい、暗い歴史を超え強く立ち上がり、団結を強めた。だからこそ、過去の不在担当者への憎しみは乗り越えられると信ぜずにはいられない。開発文化間の隔たりは解消され世界が小さくなるにつれ、共通の人間性が現れると。そして、開発部は新たな構成管理サーバーへのライブラリアンとしての役割を務めねばならない。
ありがとう。バラク・オバマ。
ありがとう。どうしんウェブ。
そして歴史は繰り返す
社内統一の構成管理サーバーを構築し、利用手順やガイドランも設け、自分の仕事は終わった感でいっぱいになった「開発プロセス見直しの担当者」は、高楊枝で過ごしています。しかし、開発部員から「問題が解決していない」との声が聞こえ始めます。
われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋をGitリポジトリに深く刻むことを覚えた。だからこそ、過去の不在担当者への憎しみは乗り越えられる。しかし、深く刻まれたコメントだからこそ、聞こえてくるのは呪いの言葉だけである。
次回は
構成管理サーバーを構築し格納対象を決めたにも関わらず何が足りていないのか。「共通フレーム2013」をベースに現場の声を取り込みます。