Solutions Architecture, Design, Programming, Operation and Continuous Integration.
Articles of IT skills

・プロセスを社内のワークフローに落とし込む ユニファイド・プロセスをベースに策定した試験的なプロセスを社内のワークフローに落とし込む作業には、要求～基本設計までの上流設計フェーズ、詳細設計～試験までの構築フェーズと運用フェーズに分割して提案しました。社内のワークフローをAgileに適用する際、イテレーションが同じロールで繰り返されることが習熟度につながっていき、プロセスの確立につながると考えたからです。また、このロールにキャリアを連動させることは、社員教育にもつながるという提案をしました。提案先の企業の社内ワークフローのロールとして、社員による上流設計フェーズと協力会社による構築フェーズおよび運用フェーズが定着していたためです。 つまりここでいう社員教育とは、システム調達（プロキュアメント）のキャリアラダー・プランを策定することです。社員によるTFSの管理委託ができるようになることではなく、ALMを社内に定着させ、システムの品質を管理し、ベンダーを選定する能力とコントロールする能力を開発することです。上流設計フェーズでは自らが設計に参加できる能力を持ち合わせ、構築および運用フェーズでは管理する能力を持ち合わせる必要があったため、フェーズによってTFSを使う目的が異なることを訴求することは重要でした。多くの企業において、社員のキャリア開発プランは社内のさまざまなワークフローと深く結びついてます。その企業のキャリア開発に則ったプロセスでなければALMは社内に定着しません。 上流設計に参加できる能力は、ALMの視点でのみ考えれば、Agile Unified Processにおけるイテレーションとその成果物の構成を理解することでタスクのステートを推移させていくことが可能です。上流設計フェーズのイテレーションとその成果物の構成を定義する作業については、製品戦略などと深くかかわるためPLM側の責務とし、ALMの提案書では、構築、運用フェーズにおけるイテレーションとその成果物の構成を定義する作業を提案しました。 TFSには7種類（以降に「」で括ってあります）のチケット（TFSでの呼称は「ワークアイテム」）があります。これらの種類は組織やプロジェクトに応じてすべて使っても良いし、いくつかの種類にまとめてもかまいません。提案した方法は、いくつかの「タスク」と「バグ」、「テスト」で構成された「機能」があり、その「機能」のいくつかと複数の「テスト」で構成された「ユーザーストーリー」があり、そのいくつかの「ユーザーストーリー」と複数の「テスト」および複数の「懸案事項」があるイテレーションを構成するように提案しました。TFSの7種類のワークアイテムにはすべて「状況」（ステート）があるため、このステートを管理することができます。イテレーションを通して、ワークアイテムの種類を統合していくなり、それぞれのステートを変更していくなりといった規律の確立こそが構築、運用フェーズにおけるプロセスの管理であることを訴求しました。 前述のコミットのワークフロー内でのステートの変化を以下のように提案しました。 ワークフロー内のステートの変化

・ユニファイド・プロセスとPLM、ALM 前回作成したブランチとマージの仕組みはProduct Lifecycle Management（以降「PLM」）とALMに登場する成果物の管理の枠組みに過ぎません。この枠組みに則って成果物のバージョンを管理していく必要があり、たとえば文書管理であれば、ALMやPLMの役割は下図のようになることを提案しました。 文書定義の役割分担 文書管理においてPLMとALMの管理を完全に切り離し、ALMの管理のみをTFSで行うことでソースと文書のバージョン管理を同期させることを計画しました。ALMの管理機能は、バージョン管理、進捗や人員リソースの管理、品質管理、ビルドやリリース管理、変更管理や追跡などがあり、これらすべての運用を定義する必要があります。まずバージョン管理については、メジャー、マイナー、リビジョン、ビルドのそれぞれのインクリメント・ルールとして、新機能（メジャー）、機能拡張（マイナー）、バグ修正（リビジョン）、ビルド（リファクタリング）という標準的なバージョニングを採用しました。この際、シェルブとチェックインをロールごとに使い分けるように計画しました。 コミットのワークフロー チケット（TFSでの呼称は「ワークアイテム」）のステータス管理やロールについては、次項「プロセスを社内のワークフローに落とし込む」に詳細を解説しますが、ワークフローの最後のロールである「ビルド管理者」（おそらくは開発責任者）が、すべてのチケットのステータスを管理する点が重要です。このロールこそがアプリケーションのバージョンをコントロールするロールと言えます。 このロールに必要な知識として、プロセス定義の手法があります。バージョンのインクリメントに対する管理プロセスを策定するうえではCMMI（定義済みプロセスの定着を目的とした能力成熟度統合手法）、Scrum（少人数におけるコミュニケーションを中心としたスプリント推進によるプロセス確立手法）、Agile（ウォーターフォールを細分化したイテレーションによる柔軟なプロセス確立手法）がありますが、今回の提案ではAgileでTFSのインストールを行うことを提案しました。提案先の企業では、明確な開発プロセス、管理プロセスが確立されていなかったため、試験的なプロセスを策定し、それを繰り返しによって微調整しつつ確立する必要があったからです。 この試験的なプロセスを充足、改修することを目的とした微調整であることはチーム全員に周知する必要があります。開発者にとってもより良いプロセスを確立するために試験的なプロセスを行っているのであり、開発者のフィードバックが次のイテレーションの試験的なプロセスになるので、同じプロセスを繰り返すのであれば、確立されたプロセスに対するCMMI方式に移行する必要があると考えたからです。 試験的なプロセスは、ユニファイド・プロセスに則って策定しました。業務用ソフトウェアの開発ではユニファイド・プロセスに則ってAgileのイテレーションを計画すべきと考えたからです※：コラム「Agile Unified Process」参照。 ユニファイド・プロセスは、オブジェクト指向開発誕生以前からソフトウェア開発手法として確立されていたいくつかの手法をオブジェクト指向開発に適した形に統合した反復型開発手法です。これにはUMLなどオブジェクト指向から生まれた図での表現なども含まれますが、それらは組織やプロジェクト、ソフトウェアに適した形でカスタマイズされること（この場合変形ではなく、ユニファイド・プロセスの各要素の取捨選択）を期待されており、ユニファイド・プロセスという明確に定義されたプロセスがあるわけではありません。もっとも有名な実体化されたユニファイド・プロセスはラショナル・ユニファイド・プロセスです。

・導入事例から学んだプロセス標準化 提案書を書くにあたって、まず調査を行いました。 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 […]

ある会社にApplication Lifecycle Management（以降「ALM」）を提案することになりました。 私はVisual Studioで開発を行ってきましたし、Team Faundation Server（以降「TFS」）でのソース管理も利用してきました。かなりの規模の案件です。 ただし、Team Faundation Serverの設定をやったこともなく、GitやSubversionも大規模案件に使ったことはありませんでした。そして、提案書を作成しながら、ALMがいかに開発者や運用者の良心やスキルに依存していたかを痛感しました。 ここでは、管理ツールの導入とその運用手順を明示した提案書で、そのような良心や運用に頼らない仕組みを実現できることを訴求した内容について、以下の5回に分けて報告していきたいと思います。 第1回：システムの構築プロセス（開発と運用）を定義する 第2回：システムリソースの一元管理と分散管理 第3回：Visual Studio Onlineを提案してみた […]