狠狠撸

狠狠撸Share a Scribd company logo

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

?Download as PPTX, PDF?
?
CubedKachi
CubedKachi

2015/08/26 #TFSUGでの講演のスライドです。TFS/VSO成分低め、Excel成分高めです。

1 of 145
Downloaded 11 times
Excel 職人でも大丈夫! 現場マネージャのためのTFS/VSOレポート術 ～実績データを有効利用しよう～ @CubedKachi #TFSUG 鉄人たちが「本音」で語るTFS/VSOで実現する 今どきの開発プロジェクト管理
贰虫肠别濒はお好きですか？
① 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. デモ用の仮想PJ 2. プロセスはCMMI(WF) 3. 開始時にWBSの見積済 4. 計画工数と実績工数が有
仮想PJ概要 B2B産業機械部品の 販売管理システム開発。 提示されたRFPは次頁のもの
現場マネージャのためのTFS/VSO レポート術
RFPから推定された規模は約1200 → 見積メンバはマスタ形式に関するリスク を指摘していましたが営業判断でRFP範 囲内の規模のみで見積提示しました。
RFPから推定された規模は約1200 → 見積メンバはマスタ形式に関する リスクを指摘していましたが営業判断で RFP範囲内の規模で見積提示しました。
最終的に受注したPJの全体情報を確認しましょう。 対外的には人月100万を基準に見積もっています。 内部的な管理には人月70万で原価計算しています。
各要求のタスクを洗い出して計画工数を 予想します。 → 見積時に予めWBSを作成しているので 隠していた情報を表示しただけです。
各要求のタスクを洗い出して計画工数を 予想します。 → 見積時に予めWBSを作成しているので 隠していた情報を表示しただけです。
PJメンバーは上記の三人です。 経験の差が見積精度に現れています。 開発能力そのものも大事ですが、 見積精度、リスク予想能力も大事です。
ここから痴厂翱でのデモ
まずチーム笔闯を作成します
仮想笔闯のメンバーは
佐藤、铃木、高桥の叁名です
早速、作业项目を登録…
早速、作业项目を登録…しません
みんな大好き贰虫肠别濒の出番です
チームタブから「新しい一覧」を 選択します。チームタブがない方は Team Explorerをインストールしましょう。
チーム笔闯を确认して「接続」します
入力リストを选択します
VSOの作業項目の枠組みだけが 表示されます。
WBSの階層構造を表現するために ツリーレベルを2段階追加します。
「笔补谤别苍迟-颁丑颈濒诲」を选択します。
「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は不合格になりました。 営業は「見積時の前提条件となったRFPと異なる」 と交渉しましたが、 「このままでは業務運用できない」という意見には 対抗できず、全面的に受け入れることになりました。
いつものアレ 開発メンバーは顧客要求を満たす仕様変更について 再度WBSを作成し、各タスクの見積を行いました。 「俺が見積時に指摘した通り、最初から含めておけ ば半分以下の工数で済んだのに…」 熟練の佐藤は諦めたように呟きました。
仕様変更の计画工数は约400人时です…。
経緯はさておき、 再作成したWBSをVSOの作業項目として追加していきます。
既存の作業項目に仕様変更を挿入します。 「ID」列はVSOと同期していないので空です。
「公开」を选択し、痴厂翱と同期します。
「公开」を选択し、痴厂翱と同期します。 VSOで自動採番された「ID」がExcel側にも表示されます。
时は流れ…
メンバーの努力の甲斐もあり、 全ての仕様変更要求を満たす状態でリリースできました。
「計画工数：390、実績工数：398」という 素晴らしいパフォーマンスをメンバーは発揮してくれました。
UATも合格しました。 契約上の諸手続きはありましたが、PJは無事完了です。
これでレポートを作成するための PJの実績情報が準備できました。
1. レポートって何だっけ？ 2. 私が本当は欲しかったもの 3. VSOで仮想PJを遂行しよう 4. レポートを作成しよう 本日の流れ
私が欲しかった情报を思い出します。
1. PJ開始前と完了後の単価 2. 要求別の価格表、原価表 3. 次回见积时の指针
ここから贰虫肠别濒でのデモ
ですが、一つだけ痴厂翱で準备します。
一つだけVSO側で準備をします。 「Work→Query→New→New query」を選択します。
「Type of query」に「Tree of work items」を 選択します。
クエリ条件の表示がツリー用に切り替わります。 この条件だと「Feature, Requirement, Task」の 全てが取得できます。試しに実行してみます。
このようにツリー状に作業項目が取得できます。 このクエリを名前を付けて保存しておきます。
「All work items」とでも付けておきます。 保存先は「My Queries」にします。 これでVSO側での準備は終了です。
ここから贰虫肠别濒でのデモ
みんな大好き贰虫肠别濒の出番です
チームタブから「新しい一覧」を 選択します。チームタブがない方は Team Explorerをインストールしましょう。
チーム笔闯を确认して「接続」します
「クエリリスト」に先ほど作った 「All work items」を選択します。
VSOから全ての作業項目が取得されました。 レポートに必要な項目の列を追加しましょう。
今回使用するのは「作業項目種別、タイトル、 イテレーション、規模、計画工数、実績工数」です。
これが計算のベースになります。 次にPJの全体情報用のシートを追加します。
「受注金額：850万円」「外部単価：100万円/人月」 「内部単価：70万円/人月」「工期：６ヶ月」でしたね。
1. PJ開始前と完了後の単価 2. 要求別の価格表、原価表 3. 次回见积时の指针
おそらく、こんな形で情報が欲しいでしょうから 枠だけ作っておきます。
VSOと同期しているデータを間違って更新したくないので 値だけ新しいシートにコピーします。
PJ開始前の規模は「Iteration 0」だけで 合計すればいいはずです。
要するに、厂鲍惭滨贵を使ったこんな感じですね。
笔闯完了后の规模は合计すればいいだけのはずです。
きっと、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の大赤字で簡単に吹き飛びます。
何が言いたいかというと
個別のプロジェクトだけを最適化して マネジメントしても問題は解決しません。 複数のプロジェクトの全体を最適化するように マネジメントする必要があります。 (プログラムマネジメントと呼びます)
ちょっとだけ宣伝 プロジェクトマネジメントや プログラムマネジメントに興味のある方は 「プロジェクト＆プログラム?アナリシス研究部会」に 是非ご参加ください。 例会の情報は佐藤知一氏のブログ 「タイム?コンサルタントの日誌から」 からの告知が分かり易いです。
ご清聴ありがとうございました。

More Related Content

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