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