第1回：システムの構築プロセス（開発と運用）を定義する#1

・導入事例から学んだプロセス標準化

提案書を書くにあたって、まず調査を行いました。

Microsoft MVP for Visual Studio ALMの方たち^※1のブログなどを読み漁り、OnlineとOn premiseはそれぞれ使いどころがあることを知り、TFSは一元管理に適したソース管理ツールであり、Gitは分散管理に適したソース管理ツールであることを知りました。また、ソース管理はApplication Lifecycle Management（以降「ALM」）の一部にすぎないことなどを知ることになります。通常提案書などを書く場合は、100ページ程度のものを1週間ぐらいで書きますが、私にとっての最初の洗礼は「ALMの提案は1週間程度で策定できるレベルのものではない」ということでした。

私はProject Management（以降「PM」）を経験済みであり、Project Management Body of Knowledge（以降「PMBOK」）の知識もあったので救われた部分もありますが、5年でほぼ全面更改するようなシステムばかりを経験してきたので、ひとつのシステムのライフサイクルを管理するスキルを持ち合わせているわけではなく、要件や要求からさまざまなシステムを統合・連携していくスキルしか持ち合わせていませんでした。

そこで、まず提案先のシステムのライフサイクルの全体像の外観図を描くことから始めました。提案先は業務システムを成長させていくタイプの企業であったため、ソース管理については分散管理ではなく一元管理が向いていると考え、TFSを中心にシステム文書の更新やソースの分岐・マージ、アプリケーション・データの変更と顧客別カスタマイズや国際化の関係などの要素を登場させた図を描くことから始めました。この際、OnlineとOn premiseのどちらかを限定で使うことや組み合わせて使うことを後から考えるようにして、さまざまな導入事例のパターンを参照しました。^※2

※1：Microsoft MVPのサイトで[Find MVP]から[MVPs in my country or region]を選択し、[Technical expertise]で[Visual Studio ALM]を選択して[Search]で表示される各MVPの方たちに進むとブログや著作などを参照できます。
http://mvp.microsoft.com/en-us/search-mvp.aspx?ex=Visual+Studio+ALM&lo=Japan&sc=s

※2：日本郵政スタッフ株式会社（http://www.microsoft.com/ja-jp/casestudies/jp-staff.aspx）など

ライフサイクル外観図

この図では、プロダクト・リリースの前後に関係なく、リポジトリへの格納の順とブランチ／マージの規範を定義しました。参考にした導入事例では、プロセスの標準化が重要であることを訴求していたためです。TFSの操作やOnlineとOn premiseなどの環境の構築と運用の基礎となるALMについて標準化された開発・運用プロセスが必要で、私はブランチとマージについてその改修をカテゴライズすることから始めました。

「設計が必要な改修」、「定義のみ必要な改修」、「プライオリティの高い改修」の3つに分類し、それらのブランチ／マージが交差するのは構わないが、同じカテゴリーの改修については並行してブランチさせないことを規範としました。
一般的な開発では、ある改修が他の改修に影響することは多々あります。そのような改修は仕様変更のように設計から見直すこと（または追加設計）が必要であり、試験についても影響を受ける側、与える側の両方に必要なので各種設計書の改訂が必要になります。また、バグ改修などのプライオリティの高い改修では、設計文書が後回しになることもあると思います。

そのような運用を考慮した結果、最低限の規範として、改修のカテゴリー分けと同カテゴリーの並行したブランチを禁止しました。ブランチとマージに長けた分散管理システムでは、このようなことを気にする必要がないかもしれませんが、今回の提案では一元管理を推奨べきと考え、かつ提案先の企業では、レイヤード・アプリケーション^※3を構築しており、複数の協力会社が役割を明確に分担できない構成になっていたため、複数の協力会社間で最低限の規範を策定する必要がありました。ブランチ、マージ作業を行うのは提案先の企業ですが、そのブランチ内で作業を行う協力会社のメンバーは、並行しているブランチとマージが保証されているブランチを意識する必要があると考えたためです。

※3：新しい機能を追加する場合、データストアから必要な情報を再現する部分を含め、データサービスまでを開発フレームワークが担当し、データアクセスレイヤーからデータモデルにおける業務設計を上級SEが担当します。各プログラマーは、データモデルからビューモデルを作成し、画面を構築するといった構成を行っています。