[ 開発エキスパートに学ぶ！C#とVisual Studio の今と未来 ] #3

1. Team Foundation Server /
Visual Studio Online
を利用したチーム開発の実践
[ 開発エキスパートに学ぶ！C#とVisual Studio の今と未来 ] #3
1
TFSUG・Microsoft MVP for Visual Studio ALM 古賀 慎一
2015年10月16日（金）
Copyright© 2015 Shin-ichi Koga All Rights Reserved.

2. このセッションのゴール
TFS / VSOで出来ることの全体的なイメージを持つ
品質・効率を上げるために何をすべきか？ を理解する
自社案件に TFS / VSO を 採用 出来るか？検討出来るようになる
高品質・低コスト・保守性の高い開発を行えるようになろう！
2
Team Foundation Server / Visual Studio Online

3. 自己紹介
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 を使って改善できること
 まとめ
4
このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )

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

6. TFS / VSOで何が出来ますか？
 Visual Studio Online のメニューを見るとわかります
 HOME ⇒ ダッシュボード・見える化
 CODE ⇒ ソースバージョン管理
 WORK ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム
 BUILD ⇒ 自動ビルド・自動テスト・自動リリース・継続的デリバリー
 TEST ⇒ テストケース管理（バグトラッキングシステム）・他機能はまだプレビュー
6 さらに RELEASE が追加される予定（リリース管理）

7. ソース管理だけではコスト削減が出来ない
ソースバージョン管理システムの導入は必須、しかし
 履歴と比較できるだけでは デグレのコスト削減はできない
 分岐で作業を分離できるだけでは リリース事故・コスト肥大化を防げない
起きた後の問題解決を早くするだけ ⇒ 起きない様にする仕組みが必要
7

8. チーム開発には TFS / VSO が必要
 HOME ⇒ ダッシュボード・見える化
 CODE ⇒ ソースバージョン管理
 WORK ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム
 BUILD ⇒ 自動ビルド・自動テスト・自動リリース・継続的デリバリー
 TEST ⇒ テストケース管理（バグトラッキングシステム）
 RELEASE ⇒ リリース管理（自動化・ワークフロー・継続的デリバリー）
ソースバージョン管理システムからもう一歩次に進もう！
8

9. どれを採用するか？は “クラスタ” の違い？
 Visual Studio + TFS（オンプレ）
 Visual Studio + VSO（クラウド）
 Visual Studio
+ Subversion～Git、Trac～Redmin、hudson～jenkins、NUnit ...（OSS）
どれを採用するのが自分のチームに一番適しているか？
※ TFS/VSO ではソースバージョン管理システムとして Git が使用できます 9
Team Foundation Server
Visual Studio Online

10. オンプレか？クラウドか？OSSか？
 全てやりたいなら TFS
 初期投資大＆バージョンアップは大変（ハードウェア要件が上がる）
 VSO は 5名まで無料ですぐに始められて、常に最新
 一部従量課金、まだフル機能ではない感じだが、どんどん強化されている
 全て無料（あるいは、人件費がとてもかかる） OSS
 何でも出来る＝全部自分達で解決する必要があり人に依存・トレンドの変化も早い
おすすめは VS + VSO、機能が不足してきたら VS + TFS を検討 10

11. チームで採用するには
 機能の使い方を覚えるだけではチームには根付かない
必ず「使えない」という感想が返ってくるはず
 チームとしての準備が必要
 機能の紹介だけではなく、チームとして
「どう実現するか？それで何を守るか？」のマップが必要
何のために TFS / VSO の機能を使うのか？ポイントを押さえよう！ 11

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

13. 失敗プロジェクトのパターン（WORK/HOME編）
 見積もり時に WBS を十分にブレークダウンしていない
 ふたを開けてみると全く足りない
 必要な工程を省く ⇒ 必ず失敗する 手戻り・不要なコストが増大
 チーム全体で必要なタスクの全体量や、リソースの割り当てが適切か？
把握できなくなり、ますますタスクの洗い出し・割り当てが甘くなる
 期限は変えられない 個人的に努力しても残業で対応するしかなくなる
 エンジニアの残業が増えて、プロジェクト全体では赤字になる
 次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる 13
Work Breakdown Structure

14. 成功プロジェクトのパターン（WORK/HOME編）
 見積もり時に WBS を十分にブレークダウンしている
 必要十分なタスクを割り当て、進捗と結果をより正確に把握できる
 必要な工程を適切なリソースで開発できるので、無駄なく完成できる
 問題があった場合も、数値的・視覚的にすぐに発見・対応できる
 タスクの見積もり・割り当てがさらに改善される
 スケジュールどおりに開発するのが当たり前に 良いサイクルが回せる
 エンジニアが正当に評価されて、無駄に残業する必要がなくなる
TFS / VSO はこれを「見える化」で支援 14

15. WORK・HOMEで見える化
 かかる時間を指定して、タスクを割り当てる
 タスク進捗の変化をボード＆数値・グラフで確認
 PMの見積もりは本当に正しかったのか？
 チームは 残り 5日で、残り 100時間 のタスクを消化できるか？
 誰かひとりにタスクが集中しすぎていないか？
 必ず「正しいと言え」では改善できない
正しい or 間違いではなく「差」を減らす工夫を
15

16. 必ず TFS / VSO で扱う範囲を決めて導入
 最初から「すべてをやろう！」は失敗する
 現在の進捗管理との共存・連携を考える
 Microsoft Project + TFS / VSO を検討
 WBS・予定 はどこがマスターか？
 進捗・実績はどこがマスターか？
 顧客への報告資料はどうやって作成するか？
予実を比較可能にして、見積もり精度を上げることで改善していく
16

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

18. 失敗プロジェクトのパターン（BUILD/TEST編）
 「今はそれどころじゃないから」と、十分な設計をしない
 設計が不十分なので正しい オブジェクト指向 や MVVM で作れない
 正しいオブジェクト指向や MVVM ではないので 単体テスト が作れない
 単体テストが作れないので、開発が遅く、途中で品質を把握できない
「今はテストしている場合じゃないから」とさらに品質が下がる
 最終的には品質をあげる必要があり、残業で対応するしかなくなる
 エンジニアの残業が増えて、プロジェクト全体では赤字になる
 次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる 18

19. 成功プロジェクトのパターン（BUILD/TEST編）
 設計に十分な時間をかける
 特に「どうやって時間をかけずにテストするか？」を考える
 設計が十分にされている（MVVMで作れる）と単体テストが簡単に作れる
 単体テストで品質を把握できて、開発・テストが早く完了する
 開発プロセスを標準化して再利用できるように見直す時間がとれる
 短期間で高品質の開発ができる、よいサイクルが回せる
 エンジニアが正当に評価されて、無駄に残業する必要がなくなる
TFS / VSO はこれを「自動ビルド・自動テスト」で支援
19

20. ビルド・単体テストの結果が TFS / VSO でわかる
 手動実行、自動実行（日時・曜日・ソースのチェックイン時に実行）が可能
 BUILD で結果をいつでも確認出来る ⇒ HOME にピン留めして「見える化」 20

21. 「ビルド定義」を作成・登録・実行するのが BUILD
 どのソースコードをビルドするか？
 ビルド後に（どの）単体テストを実行するか？
 ビルド後に成果物をコピーするか？
 成果物を（どこに）デプロイするか？
 これらの「ビルド定義」を、手動・日次・曜日指定 で実行するか？
21

22. MVVMで設計できれば「単体テスト」を作れる
 M : Model
 DBやクラウドサービスから入手したデータを入れる箱
 V: View
 画面に表示して、人間がデータの内容を確認出来るようにする
 VM : View Model
 画面(V) に表示するために、モデル(M) を複製して、その画面用のモデル(VM) とする
クラスライブラリ、あるいはアプリの一部分の「単体テスト」を作る
22

23. MVVM : Model – View – View Model の動き
 DBやクラウドから取得した Model を、画面用の View Model に格納
 画面にデータバインドで表示
 双方向バインドなら V でユーザーが値を変える VM も変わる
 プログラムで今度は逆に VM から M に格納、それぞれDBやクラウドに保存する
23
“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にもインターネットに繋がずにテスト出来る 24
“A” Model
“C” View Model 単体テスト
Database “A”
Cloud Service “B” “B” Model
View Model
を試験
Web API, WCF
Entity Framework, LINQ to SQL
単体テスト“C” View Model
View Model
を試験
テスト用 Model
を作るプログラム
“A” Model
“B” Model

25. MVVM ならテストできない要因を切り離せる
 認証、DB、ネットワークなどをテスト用のモジュールに差し替え可能
 Fakes も活用できる（例：DateTime.Now を変更したテスト）
偽オブジェクト指向、偽MVVMでは単体テストが作れない
例：V にロジックが実装されている
V を切り離すと、ロジックがなくなるので動作しない
Vの単体テストは作れないので、単体テストが作れない
どうやれば MVVM で作れるのか？⇒ 本で詳しく解説しました・サンプルもあります 25

26. 単体テストで進捗・品質を確認できる
 毎日ビルド・テストが正常であることを確認
 チームの誰も壊していない＝デグレが起きていない
 デグレが発生しても、出来るだけ早く発見して解決し、コストを最小に抑える
 単体テストが増えていれば、進捗していることも確認できる
 カバレッジ100%までいかなくても、
80%ぐらいを維持できれば品質は劇的にあがる
「完全にはできない」から「全くやらない」ではなく、やる範囲を決めてやる 26

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

28. 失敗プロジェクトのパターン（RELEASE編）
 リリース手順が明確でない、作成した手順書のテスト・レビューが甘い
 実際にリリースしようとすると、ちゃんと動かない
 リスケする余裕がないので、その場で「人間力」で解決、残業で対応する
 記録が不十分になりフィードバックがなく、原因の調査・改善がされない
 準備が不十分でもリリース出来るという文化が根付き、準備や
原因を特定することは不要・コストがかかる悪だという文化が広がる
 エンジニアの残業が増えて、プロジェクト全体では赤字になる
 リリースの失敗・コスト増大・残業、プロジェクトの失敗が恒常的に 28

29. 成功プロジェクトのパターン（RELEASE編）
 リリース手順が明確、十分に設計・テストされている
 実際にリリースするとちゃんと動く 驚くほどあっけなく
 万が一問題がおきても問題が容易に特定できて、すぐに対応できる。
 リリース手順も資産として再利用されて、次回よりコストが削減される
 リリースは事故無く行われるのが当たり前になり、よいサイクルが回せる
 エンジニアが正当に評価されて、無駄に残業する必要がなくなる
TFS / VSO はこれを「リリース管理」で支援
29

30. リリースに必要なものはすべて TFS / VSO に
 CODE に DB定義（DataBaseプロジェクト）もスクリプトも・・・
 VSO BUILDでも簡易的なリリースが可能
 自動ビルド・自動テスト後に、Azure に配置するなどを「ビルド定義」に設定
 TFS RELEASEで「リリース定義」を開発するという考え
VSO はまだ RELEASE が使えません、近い将来的に使えるようになる
30

31. 将来 VSO RELEASE でも本格的なデプロイを実現（予
 リリース管理では「リリース定義」を作成
 いわゆる承認ワークフロー
 環境ごとに 担当者の承認とデプロイの実行 を行う
 「リリース定義」を実行すると、ワークフロー開始
 メール通知あり、Webで承認・否認ができる
 否認するとそこでワークフロー完了
 承認するとデプロイが実行されて、次へ進む
 全て完了すると、リリース完了
31
開発環境
承認＆デプロイ
QA環境
承認＆デプロイ
ステージング環境
承認＆デプロイ
運用環境
承認＆デプロイ
※この内容はリリース前の公開資料と、TFSリリース管理の機能から、VSOに追加される予定の機能を想定して解説しています

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

33. 失敗プロジェクトのパターン（Team Room編）
 共有フォルダにOfficeファイルを保存、メールでも情報共有し、ルールがない
 ファイルが更新されずに、メールだけで最新の情報が共有されることがある
 メールの宛先に含まれる人が限定され、全員に共有されないことがある
 メールの宛先に不必要に多数の人が含まれ、メールが氾濫「オオカミ少年」状態
 最新の仕様や優先順位が適切に共有されず、チームがバラバラで仕事をしている
 作業の無駄や手戻りが恒常的になり、残業で対応するしかなくなる
 エンジニアの残業が増えて、プロジェクト全体では赤字になる
 次はもっと残業をするようになり、プロジェクトの失敗が恒常的になる 33

34. 成功プロジェクトのパターン（Team Room編）
 指示はタスク（WORK）に記録し最新に更新する
 仕様はドキュメントに保存し、CODEでバージョン管理
（あるいは SharePoint に保存し）そのURLを、WORKからリンクする
 緊急的な相談や指示の依頼は、メールではなく Team Room で行う
必要に応じて、WORKやCODEの成果物に反映させることが維持される
 常に最新の仕様、指示でタスクが実行される
 エンジニアが正当に評価されて、無駄に残業する必要がなくなる
34

35. 何をどこに保存するか？明確にする
 「全てメール」は「全て口頭」と同じ
＝ 管理されていない状態
 CODE（成果物） に保存するべきもの
 WORK（指示）に保存するべきもの
 TEST（指標・証拠）に保存するべきもの
 Team Room（会話）で短時間保存されて全員に共有されるべきもの
全員が近くの席にいてすぐ会話出来る or 遠隔地でも Team Room で会話できる 35

36. HOME > Welcome.md ファイル
 「ようこそ！」に wiki 形式でドキュメントを作れる（CODEに保存）
 仕様書を全て wiki で書いても良い（Markdown 記法）
 Excel、Word でも wiki でも何でも良いので、
必ずドキュメントを書くルールを決める事
※開発者以外も扱えるように、ドキュメントは SharePoint で管理するのがお勧めです
 混在（どっちに書くか？メンバーが迷う）やルール無しは失敗する
TFS / VSO 導入前に、チームの文化を決める事が重要 36

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

38. まとめ
 TFS / VSO なら特定の人に依存しないで、チームに導入・維持・運用出来る
 タスクの進捗と工数の「見える化」で、”オンスケ” を当たり前に
 自動ビルドと自動テストで、品質が高い開発を当たり前に
 MVVMで作れば単体テストは簡単に作れる
 リリース手順も納品物同様に開発し、十分にテストされたものに
 情報共有・記録・指示を明確に区別、誰でも最新が何か？わかるように
38

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
39
今日の内容も
詳細に解説！

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