現場マネージャのためのTFS/VSO レポート術

Excel 職人でも大丈夫 ! 現場マネージャのための TFS/VSOレポート

術～実績データを有効利用しよう～

@CubedKachi

#TFSUG鉄人たちが「本音」で語る TFS/VSOで実現する今どきの開発プロジェクト管理

Excelはお好きですか？

① Excel方眼紙とかクソ、とっとと滅びろよ！② 必要なら使うよ。子供じゃないんだから。

③ むしろ、メールとパワポと Excelしか使ってない。

④ 俺が、 Excelだ！

① Excel方眼紙とかクソ、とっとと滅びろよ！② 必要なら使うよ。子供じゃないんだから。

③ むしろ、メールとパワポと Excelしか使ってない。

④ 俺が、 Excelだ！

① Excel方眼紙とかクソ、とっとと滅びろよ！② 必要なら使うよ。子供じゃないんだから。

③ むしろメールとパワポと Excelしか使ってない。④ 俺が、 Excelだ！

① Excel方眼紙とかクソ、とっとと滅びろよ！② 必要なら使うよ。子供じゃないんだから。

③ むしろメールとパワポと Excelしか使ってない。④ 俺が、 Excelだ！

色んな意見があるとは思いますが今回は Excel中心のお話です。

どちらかというと Excel方眼紙が友達の SEです。PJ管理、設計、開発、テスト、導入、保守まで大体やります。最近、社内システム系の部門に異動しました。←こんな私を泳がせてくれている㈱構造計画研究所に感謝。

自己紹介的な何か

1. レポートって何だっけ？2. 私が本当は欲しかったもの3. VSOで仮想 PJを遂行しよう4. レポートを作成しよう

本日の流れ

1. レポートって何だっけ？2. 私が本当は欲しかったもの3. VSOで仮想 PJを遂行しよう4. レポートを作成しよう

本日の流れ

そもそもの話レポートって何だろう？

誰のために書いてるんだろう？

1. 顧客が要求したから？2. 上司が要求したから？3. 規則で必要だから？

1. 顧客が要求したから？2. 上司が要求したから？3. 規則で必要だから？

1. 顧客が要求したから？2. 上司が要求したから？3. 規則で必要だから？

1. 顧客が要求したから？2. 上司が要求したから？3. 規則で必要だから？

そういう一面もありますが自分のために書きたいですよね？

何のために書いてるんだろう？

過去を振り返るため

PJが完了した時や問題が発生した時に全体を把握するためにレポートを作成する。

詳細は無視して全体で考える必要がある。

過去を振り返るため

PJが完了した時や問題が発生した時に全体を把握するためにレポートを作成する。

詳細は無視して全体で考える必要がある。

総工数は？

PJが完了した時や問題が発生した時に全体を把握するためにレポートを作成する。

詳細は無視して全体で考える必要がある。

過去を振り返るため

総工数は？

バグ密度は？

PJが完了した時や問題が発生した時に全体を把握するためにレポートを作成する。

詳細は無視して全体で考える必要がある。

過去を振り返るため

総工数は？

バグ密度は？

利益率は？

現在を知るためPJの最中にコストや進捗、品質を管理するためにレポートを作成する。

管理可能な粒度で個別詳細の予定と状態を考える必要がある。

PJの最中にコストや進捗、品質を管理するためにレポートを作成する。

管理可能な粒度で個別詳細の予定と状態を考える必要がある。

現在を知るため完了のタスクはどれ？

PJの最中にコストや進捗、品質を管理するためにレポートを作成する。

管理可能な粒度で個別詳細の予定と状態を考える必要がある。

現在を知るため完了のタスクはどれ？

未 Fixのバグは何件？

PJの最中にコストや進捗、品質を管理するためにレポートを作成する。

管理可能な粒度で個別詳細の予定と状態を考える必要がある。

現在を知るため完了のタスクはどれ？

未 Fixのバグは何件？

残業は必要そうかな？

未来を考えるため

将来の PJの見積や要件定義、チームの編成に備えてレポートを作成する。

複数の PJを横断的に比較する必要がある。

未来を考えるため

将来の PJの見積や要件定義、チームの編成に備えてレポートを作成する。

複数の PJを横断的に比較する必要がある。

非機能要件 Aの価格を○○万円にしたら機能要件 Bの値引きをカバーできるか？

将来の PJの見積や要件定義、チームの編成に備えてレポートを作成する。

複数の PJを横断的に比較する必要がある。

未来を考えるため非機能要件 Aの価格を○○万円にしたら機能要件 Bの値引きをカバーできるか？

RFPには記載されていないが、UAT後に△△の要望が出てくるはず…

どれが大事なの？

全部

1. レポートって何だっけ？2. 私が本当は欲しかったもの3. VSOで仮想 PJを遂行しよう4. レポートを作成しよう

本日の流れ

PL、 PMをやっているとどうしても利益が気になります。

ところが

TFSレポート機能やWebポータルのチャート機能は色んな場所で紹介されていますがTFS/VSOで実施した PJの利益計算の情報は見かけません。

何故でしょう？

TFS/VSOに受注金額や賃率等の生々しい値を入力する場所が存在しないからでは？

TFS/VSOはどちらかというとTech系のプロダクトなので、お金の話は受けないからでは？

無いなら自分で作ろう

なので、今回は VSOからエクスポートした作業項目を使って、自分の欲しいと思っている三つの情報をレポートしてみます。

1. PJ開始前と完了後の単価2. 要求別の価格表、原価表3. 次回見積時の指針

1. レポートって何だっけ？2. 私が本当は欲しかったもの3. VSOで仮想 PJを遂行しよう4. レポートを作成しよう

本日の流れ

私が欲しいレポートを作成するためにPJの実績データを用意する必要があります。まずは VSOのインポート機能を使って仮想 PJを完了させるところまでデモします。

前提条件

1. デモ用の仮想 PJ2. プロセスは CMMI(WF)3. 開始時にWBSの見積済4. 計画工数と実績工数が有

仮想 PJ概要B2B産業機械部品の販売管理システム開発。提示された RFPは次頁のもの

RFPから推定された規模は約 1200→見積メンバはマスタ形式に関するリスクを指摘していましたが営業判断で RFP範囲内の規模のみで見積提示しました。

RFPから推定された規模は約 1200→見積メンバはマスタ形式に関するリスクを指摘していましたが営業判断でRFP範囲内の規模で見積提示しました。

最終的に受注した PJの全体情報を確認しましょう。

対外的には人月 100万を基準に見積もっています。内部的な管理には人月 70万で原価計算しています。

各要求のタスクを洗い出して計画工数を予想します。→見積時に予めWBSを作成しているので隠していた情報を表示しただけです。

各要求のタスクを洗い出して計画工数を予想します。→見積時に予めWBSを作成しているので隠していた情報を表示しただけです。

PJメンバーは上記の三人です。経験の差が見積精度に現れています。

開発能力そのものも大事ですが、見積精度、リスク予想能力も大事です。

ここから VSOでのデモ

まずチーム PJを作成します

仮想 PJのメンバーは

佐藤、鈴木、高橋の三名です

早速、作業項目を登録…

早速、作業項目を登録…しません

みんな大好き Excelの出番です

チームタブから「新しい一覧」を選択します。チームタブがない方はTeam Explorerをインストールしましょう。

チーム PJを確認して「接続」します

入力リストを選択します

VSOの作業項目の枠組みだけが表示されます。

WBSの階層構造を表現するためにツリーレベルを 2段階追加します。

「 Parent-Child」を選択します。

「 Title1」「 Title2」の列に変化します。「 Title1」を入力せず「 Title2」だけを入力すると「 Title1」の子供となります。「 Feature」「 Requirement」「 Task」を表現するためにもう 1階層追加しましょう。

「 Title1」「 Title2」の列に変化します。「 Title1」を入力せず「 Title2」だけを入力すると「 Title1」の子供となります。「 Feature」「 Requirement」「 Task」を表現するためにもう 1階層追加しましょう。

「 Title3」が追加されました。これで 3レベルのWBSを表現できます。次に担当者や計画工数なども入力できるように項目を追加しましょう。

「 Title3」が追加されました。これで 3レベルのWBSを表現できます。次に担当者や計画工数なども入力できるように項目を追加しましょう。

3種類の作業項目が混在しているので「作業項目の種類」は「すべての作業項目の種類」を選択します。

「使用可能な列」から必要な項目を「選択された列」に追加します。

管理しやすい表示順に並べ替えます。

作業項目種別タイトルイテレーション状態理由担当者規模計画工数で並べました。

項目の種類と並び順が適用されました。

作成していたWBSをコピー&ペーストします。こういう時は Excelの方が便利ですね。

「公開」を選択すると入力したデータが VSOと同期されます。今回は VSO側にないデータなので追加されます。

同期されたので VSOで自動採番された「 ID」がExcel側にも表示されました。

時は流れ…

メンバーの努力の甲斐もあり、全ての要求仕様を満たす状態でリリースできました。

「計画工数： 1163、実績工数： 1217」という素晴らしいパフォーマンスをメンバーは発揮してくれました。

後はUATの結果を待つだけです。

UATには魔物が住んでいる…

いつものアレ

見積メンバが危惧していた通り、「過去データは承認された時点の値で見えていなければならない」とUATは不合格になりました。営業は「見積時の前提条件となった RFPと異なる」と交渉しましたが、「このままでは業務運用できない」という意見には対抗できず、全面的に受け入れることになりました。

いつものアレ

開発メンバーは顧客要求を満たす仕様変更について再度WBSを作成し、各タスクの見積を行いました。「俺が見積時に指摘した通り、最初から含めておけば半分以下の工数で済んだのに…」熟練の佐藤は諦めたように呟きました。

仕様変更の計画工数は約 400人時です…。

経緯はさておき、再作成したWBSを VSOの作業項目として追加していきます。

既存の作業項目に仕様変更を挿入します。「 ID」列は VSOと同期していないので空です。

「公開」を選択し、 VSOと同期します。

「公開」を選択し、 VSOと同期します。VSOで自動採番された「 ID」が Excel側にも表示されます。

時は流れ…

メンバーの努力の甲斐もあり、全ての仕様変更要求を満たす状態でリリースできました。

「計画工数： 390、実績工数： 398」という素晴らしいパフォーマンスをメンバーは発揮してくれました。

UATも合格しました。契約上の諸手続きはありましたが、 PJは無事完了です。

これでレポートを作成するためのPJの実績情報が準備できました。

1. レポートって何だっけ？2. 私が本当は欲しかったもの3. VSOで仮想 PJを遂行しよう4. レポートを作成しよう

本日の流れ

私が欲しかった情報を思い出します。

1. PJ開始前と完了後の単価2. 要求別の価格表、原価表3. 次回見積時の指針

ここから Excelでのデモ

ですが、一つだけ VSOで準備します。

一つだけ VSO側で準備をします。「Work→Query→New→New query」を選択します。

「 Type of query」に「 Tree of work items」を選択します。

クエリ条件の表示がツリー用に切り替わります。この条件だと「 Feature, Requirement, Task」の全てが取得できます。試しに実行してみます。

このようにツリー状に作業項目が取得できます。このクエリを名前を付けて保存しておきます。

「 All work items」とでも付けておきます。保存先は「My Queries」にします。これで VSO側での準備は終了です。

ここから Excelでのデモ

みんな大好き Excelの出番です

チームタブから「新しい一覧」を選択します。チームタブがない方はTeam Explorerをインストールしましょう。

チーム PJを確認して「接続」します

「クエリリスト」に先ほど作った「 All work items」を選択します。

VSOから全ての作業項目が取得されました。レポートに必要な項目の列を追加しましょう。

今回使用するのは「作業項目種別、タイトル、イテレーション、規模、計画工数、実績工数」です。

これが計算のベースになります。次に PJの全体情報用のシートを追加します。

「受注金額： 850万円」「外部単価： 100万円 /人月」「内部単価： 70万円 /人月」「工期：６ヶ月」でしたね。

1. PJ開始前と完了後の単価2. 要求別の価格表、原価表3. 次回見積時の指針

おそらく、こんな形で情報が欲しいでしょうから枠だけ作っておきます。

VSOと同期しているデータを間違って更新したくないので値だけ新しいシートにコピーします。

PJ開始前の規模は「 \Iteration 0」だけで合計すればいいはずです。

要するに、 SUMIFを使ったこんな感じですね。

PJ完了後の規模は合計すればいいだけのはずです。

きっと、 SUMを使ったこんな感じですね。単価は受注金額を規模で割るだけですから

きっと、 SUMを使ったこんな感じですね。単価は受注金額を規模で割るだけですから

こんな感じですね。これが高いか安いかの評価はさておき仕様変更対応は 2割以上の値引きと同じ効果がありました。

1. PJ開始前と完了後の単価2. 要求別の価格表、原価表3. 次回見積時の指針

VSOからエクスポートしたままのデータでは親が位置関係でしか分からないので列を追加します。

作業項目種別を比較して、タスクの親 IDを入れています。これで要求ごとに工数を集計出来るはずです。

まずは要求ごとの計画工数から。親 IDが自分の IDと一致する計画工数を SUMIFで求めます。

同様に要求ごとの実績工数。親 IDが自分の IDと一致する実績工数を SUMIFで求めます。

工数から金額への換算のために単価を人時単位にします。この会社では「 7.5時間 *20営業日=1人月」です。

要求ごとの計画原価は計画工数に内部単価を乗じたものです。そろそろ、見にくくなってきたので表示を整理します。

要求ごとの実績原価は実績工数に内部単価を乗じたものです。見積からの乖離の少ないチームですので面白味に欠けますね。

PJ開始前の要求の売価は規模に単価を乗じたものと考えます。単価には先ほど集計した実質的な値を使います。

PJ完了後の要求の売価は規模に単価を乗じたものと考えます。単価には先ほど集計した実質的な値を使います。

「利益率=(売価 -原価 )/売価」を見ると一目瞭然ですね。要求によっては赤が出ているモノもあります。

1. PJ開始前と完了後の単価2. 要求別の価格表、原価表3. 次回見積時の指針

当初の予定では品質 (バグ数 )と利益の関係や見積精度 (計画と実績の乖離率 )に起因する利益率の低下について話そうかと考えていました。

ですが、私の短い経験だけを振り返ってみても(自社開発等 )真っ当な技術者を揃えている時には品質問題や見積精度に起因する利益低下などリスクに織り込まれている以上には起きていません。

今回の仮想 PJで起こったのは見積時に想定しておきながらも入札に勝つためや受注時利益率を高めるためにわざと除外してしまったリスクに関する問題です。

身に覚えのある方もいるのでは？

「顧客が悪い」とか「営業が悪い」とか「WFが悪い」とかそういう話ではないです。

もっと、営業陣や経営陣と合意を取り付けて予測したリスクを含めた形で受注していれば計画からの乖離はここまで大きくなかったはずです。(熟練の佐藤さんの呟きのように )

開発や運用だけ協力しても恒常的利益は出ません。どこか別の PJの大赤字で簡単に吹き飛びます。

何が言いたいかというと

個別のプロジェクトだけを最適化してマネジメントしても問題は解決しません。複数のプロジェクトの全体を最適化するようにマネジメントする必要があります。(プログラムマネジメントと呼びます )

ちょっとだけ宣伝

プロジェクトマネジメントやプログラムマネジメントに興味のある方は「プロジェクト＆プログラム・アナリシス研究部会」に是非ご参加ください。

例会の情報は佐藤知一氏のブログ「タイム・コンサルタントの日誌から」からの告知が分かり易いです。

ご清聴ありがとうございました。