1

Team Foundation Server /Visual Studio Online を利用したチーム開発の実践[ 開発エキスパートに学ぶ！ C# と Visual Studio の今と未来 ] #3

TFSUG ・ Microsoft MVP for Visual Studio ALM 　古賀 慎一

2015 年 10 月 16 日（金）

Copyright© 2015 Shin-ichi Koga All Rights Reserved.

2

このセッションのゴール

TFS / VSO で出来ることの全体的なイメージを持つ

品質・効率を上げるために何をすべきか？ を理解する

自社案件に TFS / VSO を 採用 出来るか？検討出来るようになる

高品質・低コスト・保守性の高い開発を行えるようになろう！

Team Foundation Server / Visual Studio Online

3

自己紹介古賀 慎一

Microsoft MVP for Visual Studio ALM

ソフトバンク・テクノロジー株式会社 Project Management Office (PMO) エキスパートエンジニア

クラウドサービス Online Service Gate® で TFS 導入事例http://tech.surviveplus.net/archives/1114

前職では 某大手 情報サイトのデータ入稿システム のフレームワークを開発

「仕組み」作りで　如何に高品質・低コストで早い開発を実現できるか？

エンタープライズ向けの実践的な C# サンプルを公開

4

アジェンダ

TFS / VSO で品質・効率を上げられるか？

HOME & WORK を使って改善できること

BUILD & TEST を使って改善できること

RELEASE を使って改善できること

Team Room を使って改善できること

まとめ

このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )

5

TFS / VSO で品質・効率を上げられるか？何のためにチームに導入するのか整理しよう

6

TFS / VSO で何が出来ますか？

Visual Studio Online のメニューを見るとわかります

HOME 　⇒　ダッシュボード・見える化

CODE 　⇒　ソースバージョン管理

WORK 　⇒　タスク管理・工程管理・進捗管理・バグトラッキングシステム

BUILD 　⇒　自動ビルド・自動テスト・自動リリース・継続的デリバリー

TEST 　⇒　テストケース管理（バグトラッキングシステム）・他機能はまだプレビュー

さらに RELEASE が追加される予定（リリース管理）

7

ソース管理だけではコスト削減が出来ない

ソースバージョン管理システムの導入は必須、しかし

履歴と比較できるだけでは デグレのコスト削減はできない

分岐で作業を分離できるだけでは リリース事故・コスト肥大化を防げな

い

起きた後の問題解決を早くするだけ　⇒　起きない様にする仕組みが必要

8

チーム開発には TFS / VSO が必要

HOME 　⇒　ダッシュボード・見える化

CODE 　⇒　ソースバージョン管理

WORK 　⇒　タスク管理・工程管理・進捗管理・バグトラッキングシステム

BUILD 　⇒　自動ビルド・自動テスト・自動リリース・継続的デリバリー

TEST 　⇒　テストケース管理（バグトラッキングシステム）

RELEASE 　⇒　リリース管理（自動化・ワークフロー・継続的デリバリー）

ソースバージョン管理システムからもう一歩次に進もう！

9

どれを採用するか？は “クラスタ” の違い？

Visual Studio + TFS （オンプレ）

Visual Studio + VSO （クラウド）

Visual Studio + Subversion ～ Git 、 Trac ～ Redmin 、 hudson ～ jenkins 、 NUnit ... （ OSS ）

どれを採用するのが自分のチームに一番適しているか？

※ TFS/VSO ではソースバージョン管理システムとして Git が使用できます

Team Foundation Server

Visual Studio Online

10

オンプレか？クラウドか？ OSS か？

全てやりたいなら TFS初期投資大＆バージョンアップは大変（ハードウェア要件が上がる）

VSO は 5 名まで無料ですぐに始められて、常に最新

一部従量課金、まだフル機能ではない感じだが、どんどん強化されている

全て無料（あるいは、人件費がとてもかかる） OSS何でも出来る＝全部自分達で解決する必要があり人に依存・トレンドの変化も早い

おすすめは VS + VSO 、機能が不足してきたら VS + TFS を検討

11

チームで採用するには

機能の使い方を覚えるだけではチームには根付かない

必ず「使えない」という感想が返ってくるはず

チームとしての準備が必要

機能の紹介だけではなく、チームとして

「どう実現するか？それで何を守るか？」のマップが必要

何のために TFS / VSO の機能を使うのか？ポイントを押さえよう！

12

HOME & WORK を使って改善できることタスクの進捗と工数の「見える化」によって削減できるコスト

13

失敗プロジェクトのパターン（ WORK/HOME編）

見積もり時に WBS を十分にブレークダウンしていない

ふたを開けてみると全く足りない

必要な工程を省く ⇒ 必ず失敗する　手戻り・不要なコストが増大

チーム全体で必要なタスクの全体量や、リソースの割り当てが適切か？把握できなくなり、ますますタスクの洗い出し・割り当てが甘くなる

期限は変えられない　個人的に努力しても残業で対応するしかなくなる

エンジニアの残業が増えて、プロジェクト全体では赤字になる

次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる

Work Breakdown Structure

14

成功プロジェクトのパターン（ WORK/HOME編）

見積もり時に WBS を十分にブレークダウンしている

必要十分なタスクを割り当て、進捗と結果をより正確に把握できる

必要な工程を適切なリソースで開発できるので、無駄なく完成できる

問題があった場合も、数値的・視覚的にすぐに発見・対応できる

タスクの見積もり・割り当てがさらに改善される

スケジュールどおりに開発するのが当たり前に　良いサイクルが回せる

エンジニアが正当に評価されて、無駄に残業する必要がなくなる

TFS / VSO はこれを「見える化」で支援

15

WORK ・ HOME で見える化

かかる時間を指定して、タスクを割り当てる

タスク進捗の変化をボード＆数値・グラフで確認

PM の見積もりは本当に正しかったのか？

チームは 残り 5 日で、残り 100時間 のタスクを消化できるか？

誰かひとりにタスクが集中しすぎていないか？

必ず「正しいと言え」では改善できない

正しい or 間違いではなく「差」を減らす工夫を

16

必ず TFS / VSO で扱う範囲を決めて導入

最初から「すべてをやろう！」は失敗する

現在の進捗管理との共存・連携を考える

Microsoft Project + TFS / VSO を検討

WBS ・予定 はどこがマスターか？

進捗・実績はどこがマスターか？

顧客への報告資料はどうやって作成するか？

予実を比較可能にして、見積もり精度を上げることで改善していく

17

BUILD & TEST を使って改善できること開発開始から高い品質を維持し続けるという考え方

18

失敗プロジェクトのパターン（ BUILD/TEST編）

「今はそれどころじゃないから」と、十分な設計をしない

設計が不十分なので正しい オブジェクト指向 や MVVM で作れない

正しいオブジェクト指向や MVVM ではないので 単体テスト が作れない

単体テストが作れないので、開発が遅く、途中で品質を把握できない「今はテストしている場合じゃないから」とさらに品質が下がる

最終的には品質をあげる必要があり、残業で対応するしかなくなる

エンジニアの残業が増えて、プロジェクト全体では赤字になる

次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる

19

成功プロジェクトのパターン（ BUILD/TEST編）

設計に十分な時間をかける

特に「どうやって時間をかけずにテストするか？」を考える

設計が十分にされている（ MVVM で作れる）と単体テストが簡単に作れる

単体テストで品質を把握できて、開発・テストが早く完了する

開発プロセスを標準化して再利用できるように見直す時間がとれる

短期間で高品質の開発ができる、よいサイクルが回せる

エンジニアが正当に評価されて、無駄に残業する必要がなくなる

TFS / VSO はこれを「自動ビルド・自動テスト」で支援

20

ビルド・単体テストの結果が TFS / VSO でわかる

手動実行、自動実行（日時・曜日・ソースのチェックイン時に実行）が可能

BUILD で結果をいつでも確認出来る ⇒ HOME にピン留めして「見える化」

21

「ビルド定義」を作成・登録・実行するのが BUILD

どのソースコードをビルドするか？

ビルド後に（どの）単体テストを実行するか？

ビルド後に成果物をコピーするか？

成果物を（どこに）デプロイするか？

これらの「ビルド定義」を、手動・日次・曜日指定 で実行するか？

22

MVVM で設計できれば「単体テスト」を作れる

M : Model 　

DB やクラウドサービスから入手したデータを入れる箱

V: View

画面に表示して、人間がデータの内容を確認出来るようにする

VM : View Model

画面 (V) に表示するために、モデル (M) を複製して、その画面用のモデル (VM) とする

クラスライブラリ、あるいはアプリの一部分の「単体テスト」を作る

23

MVVM : Model – View – View Model の動き

DB やクラウドから取得した Model を、画面用の View Model に格納

画面にデータバインドで表示

双方向バインドなら V でユーザーが値を変える VM も変わる

プログラムで今度は逆に VM から M に格納、それぞれ DB やクラウドに保存する

“A” Model

“C” View Model View “C”

Database “A”

Cloud Service “B”

“B” Model

データバインドData Binding

Web API, WCF

Entity Framework, LINQ to SQL

24

MVVM ならロジックを分離して単体テストできる

MVVM の 色んな部分を差し替えることが可能　 DB にもインターネットに繋がずにテスト出来る

“A” Model

“C” View Model 単体テスト

Database “A”

Cloud Service “B”

“B” Model

View Modelを試験

Web API, WCF

Entity Framework, LINQ to SQL

単体テスト“C” View ModelView Model

を試験

テスト用 Model を作るプログラム

“A” Model“B”

Model

25

MVVM ならテストできない要因を切り離せる

認証、 DB 、ネットワークなどをテスト用のモジュールに差し替え可能

Fakes も活用できる（例： DateTime.Now を変更したテスト）

偽オブジェクト指向、偽MVVM では単体テストが作れない

例： V にロジックが実装されている

　 V を切り離すと、ロジックがなくなるので動作しない　

　 V の単体テストは作れないので、単体テストが作れない

どうやれば MVVM で作れるのか？⇒ 本で詳しく解説しました・サンプルもあります

26

単体テストで進捗・品質を確認できる

毎日ビルド・テストが正常であることを確認

チームの誰も壊していない＝デグレが起きていない

デグレが発生しても、出来るだけ早く発見して解決し、コストを最小に抑える

単体テストが増えていれば、進捗していることも確認できる

カバレッジ 100% までいかなくても、

80% ぐらいを維持できれば品質は劇的にあがる

「完全にはできない」から「全くやらない」ではなく、やる範囲を決めてやる

27

RELEASE を使って改善できることリリース手順も納品物と同様に開発するための仕組み作り

28

失敗プロジェクトのパターン（ RELEASE編）

リリース手順が明確でない、作成した手順書のテスト・レビューが甘い

実際にリリースしようとすると、ちゃんと動かない

リスケする余裕がないので、その場で「人間力」で解決、残業で対応する

記録が不十分になりフィードバックがなく、原因の調査・改善がされない

準備が不十分でもリリース出来るという文化が根付き、準備や原因を特定することは不要・コストがかかる悪だという文化が広がる

エンジニアの残業が増えて、プロジェクト全体では赤字になる

リリースの失敗・コスト増大・残業、プロジェクトの失敗が恒常的に

29

成功プロジェクトのパターン（ RELEASE編）

リリース手順が明確、十分に設計・テストされている

実際にリリースするとちゃんと動く　驚くほどあっけなく

万が一問題がおきても問題が容易に特定できて、すぐに対応できる。

リリース手順も資産として再利用されて、次回よりコストが削減される

リリースは事故無く行われるのが当たり前になり、よいサイクルが回せる

エンジニアが正当に評価されて、無駄に残業する必要がなくなる

TFS / VSO はこれを「リリース管理」で支援

30

リリースに必要なものはすべて TFS / VSO に

CODE に DB 定義（ DataBase プロジェクト）もスクリプトも・・・

VSO BUILD でも簡易的なリリースが可能

自動ビルド・自動テスト後に、 Azure に配置するなどを「ビルド定義」に設定

TFS RELEASE で「リリース定義」を開発するという考え

VSO はまだ RELEASE が使えません、近い将来的に使えるようになる

31

将来 VSO RELEASE でも本格的なデプロイを実現（予 リリース管理では「リリース定義」を作成

いわゆる承認ワークフロー

環境ごとに 担当者の承認とデプロイの実行 を行う

「リリース定義」を実行すると、ワークフロー開始

メール通知あり、 Web で承認・否認ができる

否認するとそこでワークフロー完了

承認するとデプロイが実行されて、次へ進む

全て完了すると、リリース完了

開発環境承認＆デプロイ

QA環境承認＆デプロイ

ステージング環境承認＆デプロイ

運用環境承認＆デプロイ

※この内容はリリース前の公開資料と、 TFS リリース管理の機能から、 VSO に追加される予定の機能を想定して解説しています

32

Team Room を使って改善できること「何でもメール」を廃止して記録と共有のルールを考えよう

33

失敗プロジェクトのパターン（ Team Room編）

共有フォルダに Office ファイルを保存、メールでも情報共有し、ルールがない

ファイルが更新されずに、メールだけで最新の情報が共有されることがある

メールの宛先に含まれる人が限定され、全員に共有されないことがある

メールの宛先に不必要に多数の人が含まれ、メールが氾濫「オオカミ少年」状態

最新の仕様や優先順位が適切に共有されず、チームがバラバラで仕事をしている

作業の無駄や手戻りが恒常的になり、残業で対応するしかなくなる

エンジニアの残業が増えて、プロジェクト全体では赤字になる

次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる

34

成功プロジェクトのパターン（ Team Room編）

指示はタスク（ WORK ）に記録し最新に更新する

仕様はドキュメントに保存し、 CODE でバージョン管理

（あるいは SharePoint に保存し）その URL を、 WORK からリンクする

緊急的な相談や指示の依頼は、メールではなく Team Room で行う

必要に応じて、 WORK や CODE の成果物に反映させることが維持される

常に最新の仕様、指示でタスクが実行される

エンジニアが正当に評価されて、無駄に残業する必要がなくなる

35

何をどこに保存するか？明確にする

「全てメール」は「全て口頭」と同じ

＝ 管理されていない状態

CODE （成果物） に保存するべきもの

WORK （指示）に保存するべきもの

TEST （指標・証拠）に保存するべきもの

Team Room （会話）で短時間保存されて全員に共有されるべきもの

全員が近くの席にいてすぐ会話出来る or 遠隔地でも Team Room で会話できる

36

HOME > Welcome.md ファイル

「ようこそ！」に wiki 形式でドキュメントを作れる（ CODE に保存）

仕様書を全て wiki で書いても良い（ Markdown 記法）

Excel 、 Word でも wiki でも何でも良いので、

必ずドキュメントを書くルールを決める事

※開発者以外も扱えるように、ドキュメントは SharePoint で管理するのがお勧めです

混在（どっちに書くか？メンバーが迷う）やルール無しは失敗する

TFS / VSO 導入前に、チームの文化を決める事が重要

37

まとめVisual Studio + TFS / VSO を使いこなして品質・効率をあげよう！

38

まとめ

TFS / VSO なら特定の人に依存しないで、チームに導入・維持・運用出来る

タスクの進捗と工数の「見える化」で、”オンスケ” を当たり前に

自動ビルドと自動テストで、品質が高い開発を当たり前に

MVVM で作れば単体テストは簡単に作れる

リリース手順も納品物同様に開発し、十分にテストされたものに

情報共有・記録・指示を明確に区別、誰でも最新が何か？わかるように

39

拙著紹介（ CM ）チーム開発の教科書C# によるモダンな開発を実践しよう！

Visual Studio 2010/2012/2013/2015対応

著者：古賀慎一 ( Microsoft MVP for Visual Studio ALM )

単行本： B5 変型判　 288ページ

価格：定価 2916円（本体 2700円＋税）

ISBN： 978-4-8222-9855-5

出版社：日経 BP 社　（目次： http://goo.gl/Q2Z7TZ ）

発売日： 2015 年 10 月 8 日

Amazon.co.jp : http://goo.gl/HfcUSY

今日の内容も詳細に解説！

　

Copyright© 2015 Shin-ichi Koga All Rights Reserved. 40