これから本格的に Visual Studio Team Services (旧Visual Studio Online) や Team Foundation Server を使い始めるチーム（マネージャ・リーダー・メンバー）向けに、画面操作のデモ含めて約2時間の研修用の資料です。

1. 開発・テスト・リリースで
VSTS/TFSをフル活用する方法
ウォーターフォール・アジャイル・DevOps どんなチームでも
1
アバナード株式会社 シニアコンサルタント（ Microsoft MVP ）古賀 慎一
2016年11月21日（月）
Copyright© 2016 Shin-ichi Koga All Rights Reserved.

2. このセッションのゴール

Work の使い方をイメージする
Test と WorkのBug の使い方を決めることができる
Build と Release の使い方とCodeに必要な条件を理解する
VSTS / TFSをフル活用して、低コストで高品質な開発・運用を！
2
工程管理・進捗管理・開発
シナリオテスト管理 バグ管理
自動ビルド 承認ワークフローによるデプロイ
ウォーターフォール・アジャイル・DevOps それぞれのチームにあった
自動テスト・分岐

3. 自己紹介
3
古賀 慎一
Microsoft MVP for Visual Studio and Development Technologies
アバナード株式会社 シニアコンサルタント
 前職ではクラウドサービス開発で TFS 導入事例
http://tech.surviveplus.net/archives/1114
 某大手 情報サイトのデータ入稿システム のフレームワークを開発
 「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか？
 書籍執筆 日経BP社より発売中

4. アジェンダ
 VSTS/TFSで出来ることはDevOps
 Work による工程管理・進捗管理
 Test によるシナリオテスト管理
 Work の Bug によるバグ管理
 Code によるソースバージョン管理
 Build & Release による継続的デリバリー（自動ビルド・自動テスト・自動デプロイ）
4
このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )

5. VSTS/TFSで出来ることはDevOps
ウォーターフォールとアジャイルに継続的デリバリーをプラスする
5

6. VSTS/TFSで何ができますか？
Visual Studio Team Services のメニューを見るとわかります
 Home ⇒ ダッシュボード・見える化
 Code ⇒ ソースバージョン管理
 Work ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム
 Build & Release ⇒ 自動ビルド・自動テスト・自動デプロイ（継続的デリバリー）
 Test ⇒ シナリオテスト管理・バグトラッキングシステム
6

7. VSTS/TFSで出来ることは DevOps
 アジャイル(≒Dev) ＋ 継続的デリバリー(≒Ops) ＝ DevOps
 開発向けの機能と運用向けの機能を分けずに1つのサービスとして提供
 全ては 開発 と 運用 を繰り返す ためにある（早く安く高品質で）
7
中投資 中投資
時代の変化とニーズに応じて常にアップデート 数年で基礎から見直す

8. DevOps と各機能のバランス
 Home ダッシュボード・見える化 (Dev = Ops)
 Code ソースバージョン管理 (Dev)
 Work タスク管理・工程管理・進捗管理・バグトラッキングシステム (Dev ≧ Ops)
 Build & Release 継続的デリバリー (Ops)
 Test シナリオテスト管理・バグトラッキングシステム ( Dev ≦ Ops ≒ QA )
8
Dev Ops

9. VSTS/TFSはウォーターフォールでは活用できない？
 メニューと用語がアジャイル・DevOps向け
 そのままでは旧来のウォーターフォールでは使い方がわからない
 Codeしか使われていない現場が多い
10年前の Visual SourceSafe と同じ使い方になりがち
9

10. 考え方は「前提として」ちゃんとつながっている
 約40年前 ウォーターフォール （書類で管理、Windowsやパソコンが生まれる前）
 約15年前 アジャイル （.NET 登場、Java が普及し始めた頃）
 7年前 DevOps （ TFS 2010 DevOps対応に生まれ変わる ）
 現在 DevOps 2.0 へ (VSTS、Azure、クロスプラットフォーム、マイクロサービス）
※Microsoft Tech Summitより
作る物の機能・規模・複雑さの増大、スピードも求められる
書類で頑張る方法から、システムの支援を受けて効率化・自動化へ
10

11. 実は日本のウォーターフォールはもはやアジャイル！
 要件、機能、実装、テストの繋がりを保って開発するも（WBS段階的詳細化）
 テスト駆動開発などの開発手法を取り入れて、後工程を出来るだけ前倒し
 最後まで顧客に見せないことはなく、早い段階で細かく動作をデモ
 後工程になって明らかになる顧客の要望もできるだけ取り入れる
 V字ではなく、WOOO... ≒ アジャイル
ならば、より “アジャイルらしいウォーターフォール” で効率よくやろう！
11

12. 文書での管理からTFS画面での管理に変更できる
PMBOKに出てくる文書で、
 日々更新・集計するものは Work / Test に対応する画面がある
簡単入力・リアルタイムで見える化 ⇒ 報告時に書類にエクスポート
 あまり変わらないものは Code に保存する
Markdownはダッシュボードに表示可能 ⇒ Wordに変換可能
ウォータフォール式文書が報告や納品に必要なら
その時エクスポート・変換して作成できる！（普段はTFS画面で見える化）
12

13. 開発手法・用語と人の役割の違い
 アジャイル開発手法をウォーターフォールにも追加可能
 単体テスト、テスト駆動開発、カンバン （必要に応じて効率化可能）
 完全に対応するものは 用語 の違いに慣れるだけ
 人の役割の違い
• WBSの作成・設計・実装・テスト・デプロイを違う人がやる
• 実質同じ人がやる
• チームで適切に分担してやる
 どの管理でも予定と実績の比較が必要（チームメンバーの使い方はほぼ同じ）
13

14. VSTS/TFSをウォーターフォールでも活用できる！
この後、具体的に解説・・・
 アジャイル・DevOps向けのメニューと用語に慣れる
 TFS 簡単入力・リアルタイム見える化、報告時や納品時に文書ファイル化
 人の役割に応じて、WorkとTestの使い方を明確にする
 アジャイル開発手法を取り入れて、Build や Home を活用する
ウォーターフォール ＋ 継続的デリバリー ≒ DevOps だって可能
14

15. どんなチームでも
VSTS/TFSの機能を
フル活用して
DevOps ができる！
15

16. Work による工程管理・進捗管理
ウォーターフォールとアジャイルの違いは、いつ誰がタスクを作るか？
16

17. Workの基本は「その期間に何をするか？」
 誰が Assigned To
 この期間（週）に Iteration
 何を Task
 あとどれくらいの時間で
Remaining Work
 やるか？ やっているか？
To Do / Doing / Done ( Proposed / Active / Resolved / Closed )
開発者は自分のタスクを完了させていく
17

18. イテレーション期間は
 進捗報告・確認 ・カイゼンの最小単位
 ウォーターフォールなら週次報告 etc...
 アジャイル・スクラムならプロダクトをリリースする最小リードタイム
 開発者(チームメンバー)は期間中にタスクを完了させる
 管理者は期間ごとにレポートを取得し、報告と改善を実施できる
 リリース、仕掛の進捗、チームの生産性の実績、EVMの元となる実績値
 バーンダウンチャート 18

19. タスクを誰が作るか？
 開発者にとって「自分のタスクを完了させる」のは同じ
 そのタスクを誰が・いつ・洗い出して・見積もるか？
ウォーターフォールとアジャイル・スクラムでは大きく違う
ここに注意すれば、どちらでもうまくWorkを使いこなせる
19

20. ウォーターフォールのタスクの管理方法（全体）
プロジェクトの開始時
 WBS（日付なし）階層構造で一覧化した作業項目の一覧 +見積もり工数
 スケジュールとリリース （WBSに日付と人を設定）
開発中
 毎日 作業を実施して、実績工数・進捗状況 を入力・集計
 週次など EVM （予実の比較、CPI・SPIなどインデックス値による評価）
 課題の解決・改善（問題の発見が遅れる程、対応は困難）
20

21. ウォーターフォールのタスクの管理方法（開始時１）
WBS（日付なし）階層構造で一覧化した作業項目の一覧 +見積もり工数
 Project でタスクの一覧を作成
 大分類・中分類・小分類・・とタスクを詳細化していく
 親子関係を必ず維持、 WBS番号（1.1.1など）でタスクを識別
 過去の実績から、タスクの見積もり工数（時間・日数）を設定
21

22. ウォーターフォールのタスクの管理方法（開始時２）
スケジュールとリリース （WBSに日付と人を設定）
 タスクにリソース（作業者）をアサインする
 リソースの一日の作業量をみて、
タスクに日付を設定
 マイルストーン、クリティカルパスの確認
 ガントチャート完成
 リソースの単価とタスクの工数から見積もり金額が確定
受託開発の場合、この内容で提案＆契約できれば開発開始
22

23. ウォーターフォールのタスクの管理方法（開発中1）
毎日 作業を実施して、実績工数・進捗状況 を入力・集計
 作業者はガントチャートで「今日やるタスク」を確認
 自分で一日の作業したタスクと作業時間と記録
 作業完了後に Project Server で自分の作業時間を登録
 Project Server が無いときは、Excelなどで収集して、
PMがProjectファイルに全員分の進捗を登録する（これがすごく大変）
23

24. ウォーターフォールのタスクの管理方法（開発中2）
週次など EVM （予実の比較、CPI・SPIなどインデックス値による評価）
 ガントチャートのイナズマ線ではタスクごとの遅れを確認
 EVMでは全体を数値で把握
日付、PV: 完了しているべきタスクの見積もり工数、EV : 完了している工数、
SPI : 予定より遅いか？早いか？、CPI : 予定より工数がかかっているか？かかっていないか？
課題の解決・改善（問題の発見が遅れる程、対応は困難）
 顧客に説明してベースラインの変更（再スケジュール）これは本当にすごく大変
 ウォーターフォールでもできるだけ早く問題に気づいて対応したい 24

25. ウォーターフォールのタスクを
VSTS / TFS を使用して
管理するには・・・
25

26. ウォーターフォールでは Work をこう使う（開始時１）
WBS（日付なし）階層構造で一覧化した作業項目の一覧 +見積もり工数
 これまで通りProjectで作成
 製品、フェーズ、機能、要件、納品物に注目
 WBSを 3階層（タスクなし） or 4階層でTSFにインポート （※違いは後述）
 CMMI テンプレートを使用 Epic / Feature / Requirement(Backlog) / Task に対応
 親子関係を必ず維持してインポート WBS番号（1.1.1など）もタイトルにつける
 4段階の場合 見積もり工数は Task の Remaining Work と Original Estimate に
 3段階の場合 見積もり工数は Backlog の Original Estimate に 26

27. ウォーターフォールでは Work をこう使う（開始時２）
スケジュールとリリース （WBSに日付と人を設定）
 これまで通りProjectで計画
 タスクが、TFSのイテレーション期間のどれにあたるか？
 該当するIteration Pathを設定してTFSにインポート
 タスクがそのイテレーション期間に表示される
 担当者もAssigned Toに設定してインポート
Project ファイルをマスタースケジュールとして保管しておく
27

28. ウォーターフォールでは Work をこう使う（開発中1）
毎日 作業を実施して、実績工数・進捗状況 を入力・集計
 作業者は Workで「この期間でやるタスク」を確認
 Taskを開始・完了させる
 作業したら Completed Workに時間を足して、Remaining Workを減らす
 PMの登録作業は不要
 誰でもカンバンボードで進捗をリアルタイムに確認
開発者もPMもすごく楽！それでいて、より正確な記録！
28

29. ウォーターフォールでは Work をこう使う（開発中2）
3段階でインポートしたときは、Task の作成をチームメンバーに任せる
 作業者はWorkで「この期間で完成させるバックログ」を確認
 バックログを完成させるために必要な全てのタスクを洗い出し、見積もる
 Taskを追加
 見積もり工数をTask の Remaining Work と Original Estimate に入れる
PMはバックログの見積もり工数と、タスクの合計工数を比較してチェック
29

30. ウォーターフォールでは Work をこう使う（開発中3）
TaskをProjectで作成するとちょっとした作業が追加で必要になったときに困る
（Project の最小タスクが TFSの Task）
 ウォーターフォールでタスクを足すのは変更報告が必要な場合が多い
 Projectでタスクを登録しなおして、承認を得て、TFSに再インポート・・・
 必ずやらなくなる・やれなくなる
TFSにタスクを追加しないで作業する癖がつく、実績と乖離、TFSが使われなくなる
Taskをメンバーが追加できる3段階のインポートがお勧め
（Projectの最小タスクは、TFSのBacklog）
 TFSタスクの追加は、Projectのタスク追加ではない（作業用の詳細化） 30

31. ウォーターフォールでは Work をこう使う（開発中4）
週次など EVM （予実の比較、CPI・SPIなどインデックス値による評価）
 4段階では Task の Original Estimate と Completed Work を比較
 3段階では Backlog の Original Estimate と、子 Task のCompleted Workの合計を比較
 もとの Project ファイルの実績値に入力（TFSからエクスポートしてコピペ）
 ExcelにエクスポートしてPower BIで分析もできる
 EVMレポートを作成して進捗会議で報告する
課題の解決・改善（問題の発見が遅れる程、対応は困難）
 PMが集計に苦労しないでチームの状況を把握できるのですぐに手を打てる 31

32. Work をインポート・エクスポートするにはクエリ
 方法をスライドで解説
バックログとタスクをインポート・エクスポート
Team Foundation Server と Excel・Project との連携
http://www.slideshare.net/shinichikoga355/ss-43464369
32

33. VSTS/TFS + Power BI で EVMレポートを作成できる
VSTS/TFS を使いながらウォーターフォールらしい管理・報告が可能 33

34. アジャイル・スクラムでは Work をこう使う（１）
 事前にバックログに要件・作業を登録
 プロダクトオーナーから優先度をつけてやるべきことを挙げておく
 期間の最初に「この期間でやるべきバックログ」を決める
 過去の実績からバックログに見積もり時間を登録すると、TFSが計算
 工数時間ではなく、チーム内で使う相対見積もりの数値
 しばらく同じチームで開発すると、1期間にできる数値が分かってくる（ベロシティ）
 プロダクトオーナーにバックログを宣言して期間開始 34

35. アジャイル・スクラムでは Work をこう使う（２）
 毎日、チームメンバー全員で、
バックログを完成させるために必要な全てのタスクを洗い出し、見積もる
（こちらは工数で良い）
 Taskを追加し、見積もり工数をTask の Remaining Work に入れる
 Taskを 開始・完了させる
 チーム全体でタスク全部を完了できるか？毎日セルフチェックする
 期間内に完成させられる工夫をチームで考える（自立した組織）
 無理なことは無理と宣言する
35

36. 期間内に終わらないときはどうするか？
 ウォーターフォールではそのまま
 以前のIterationの作業であっても、実際に作業したときに Task を完了させる（遅延）
 遅れがEVMレポートとして報告される。最終的にどこかで取り返す。
 アジャイル・スクラムでは、未完成であっても完了
 期間の完了時に、プロダクトオーナーにその期間で完成したものを正確に報告する
 終わらなくて続けたいバックログも、
新しい別のバックログとして次の期間以降に作業する
 次の期間で、他のバックログと優先度を比較する
36

37. タスクが足されて見積もりより遅延するんだけど？
 チームの事実として受け入れよう
 見積もりが甘い
 無理なスケジュールをハラスメントで無理やり終わらせていなかったか？
 スキルが不足しているメンバーをアサインした？
 引継ぎが不足していた？引継ぎのコストをそもそも見積もっていなかった？
 これらが顕在化 ・見える化された と理解しよう
 例えば「人を足せば早くできるわけじゃない」が明確に見える化されてしまう
正しく見積もって出来ることをしよう！そのうえで工数を下げる工夫を！ 37

38. Test によるシナリオテスト管理
テストケースを作成、テストを実施して、結果を記録する
38

39. Test は手動テストを扱う
コードによる単体テストは Test ではなく、Code に保存して Build で扱う（※後述）
 Testでは 手動テストの計画・実行・結果の記録を扱う
 最新結果のチャートをHomeに表示して見える化
 Test にテスト計画を追加するには Test Manager 拡張機能
( Visual Studio Enterprise or Test Professional サブスクリプション※ or 支払い ) が必要
※ユーザーの設定で Basic になっていないか？確認 39

40. テストケースと結果の管理
 タスクが完了させて無くしていく作業
 バックログが完成していく成果物・納品物（実際のファイルはCodeに保存）
 テストはテストケースの一覧 + 結果の一覧
= 「今、製品は正常か？」の一覧表
 必要に応じてテストを実施、再実施して、最新結果の一覧を更新していく
40

41. 要件ベースのテストスイートを作る
 ウォーターフォールV字モデルを思い出してみる
後工程〇〇テストは、前工程□□をテストする・・
 Work に登録されているテスト対象の機能や要件の Backlog に対応する
テストスイート（テストケースの親）を作れる（一括で作成可能）
 テスト計画（テストスイートの親）に
「単体テスト」や「結合テスト」などを作成
 開発・修正でどの範囲をテストする・しなおすか？（トレーサビリティ） 41

42. Grid表示で簡単にテストケースとステップを登録
 Excelの表のように一覧で登録できる
 テストケース
テストステップ
アクション（操作）
期待される結果（そうならなかったら失敗とする条件）
42

43. テスト実行（成功時の流れ）
 Webでも、クライアント(Test Manager)でも
 テストケースを選んで開始
 ステップ（アクションと期待される結果）の一覧画面が表示される
 ステップのアクションに従って順に操作
 期待される結果通りならステップを成功に
 必要に応じてコメントを追加、画像（エビデンス）を添付 （※後述）
 全ステップ成功になるとテストケースが成功になる 43

44. 期待される結果にならなかったら
 ステップの結果を失敗にする その時点でテストケースは失敗になる
 ステップの結果にコメントを追加 どういう結果か？詳細を記載する
 ステップの結果に画像を添付
 エビデンスとしてスクリーンキャプチャを保存
 Windows標準のスニッピングツール、Light Cutter、OneNoteのツールなど
 右クリックメニューからステップの結果に画像を添付できる
 間違ってステップ（計画）に添付してしまう人が多いので注意
44

45. テストが失敗したら
 バグを起票する（※後述）
 開発作業中のテスト実施の場合にはバグを起票しなくてもいい
 バグ起票のルールはチームで決めて、README.mdなどに書いておく
 テストケースのステップの間違い・更新が必要でないか？確認
 要件ベースのテストスイートなら、WorkとCodeのチェンジセット（※後述）を確認
 バックログやタスクを追加して問題を解決する
45

46. テスト結果チャートをダッシュボードに表示
 何パーセントが成功しているか？で、全体として正常かどうか？を判断
 Homeに表示すると毎日見える
 「壊れた窓効果」にならないように、テストの失敗を放置しない
 テスト結果（ケースの結果、ステップの結果とコメント）のTSV形式エクスポートと
添付画像の一括ダウンロードができる Visual Studio 拡張機能あります（納品物の作成に）
※現在作成中でほぼ完成。公開準備が間に合っていないので、すぐに必要ならご連絡ください。
46

47. Work の Bug によるバグ管理
取り扱いを最初にチームで決めておく
47

48. バグの扱い方はプロジェクトでルールを決める
 イテレーション期間に属する・属さない
 表示の仕方を設定で変更できる
 ボードのイテレーション期間に表示するかどうか？
 表示はバックログと同様か？タスクと同様か？
 いつバグを起票するか？（テスト失敗時常に？テストフェーズのみ？）
 そのバグをどう解決するか？（次の期間？その期間？期間に関係なし？）
48

49. Work の Bug と Backlog・Taskの違い
 タスク・バックログは予定のイテレーション期間内に完了させることが目的
 バグは期間内・あるいは期間に関係なく追加して、完了させることが目的
 開発者の使用方法はほぼ同じ
 バグに直接時間を入れて完了させてもいい、
 バグに関連する別のタスクを追加して完了させてもいい
 管理者の集計の仕方が変わるので、チームでどちらかに決めておく必要がある
49

50. バグ チャートをダッシュボードに表示する
 バグがすべて解決されているか？で、全体として正常かどうか？を判断
 Homeに表示すると毎日見える
 「壊れた窓効果」にならないように、テストの失敗を放置しない
 Bug は Work の Backlog や Task 同様、クエリでエクスポートできる
 Bug に時間を入れるときは、EVM でBacklog や Task の集計と同等に扱う
（クエリを準備するときに Bug がないと忘れがち） 50

51. Code によるソースバージョン管理
継続的デリバリーのために、改めてルールを見直しておく
51

52. Work・Testと共にCodeを使用する
 ソースバージョン管理
 チェックインするときに、タスクに関連付ける（強制もできる）
 変更セットとタスクが関連付けられるので、何のための修正なのか？明確
 コメントを強制するだけでは、人の努力に依存してしまう。
 仕組みでミスできなくする。
 Testが失敗したとき、WorkとCodeのチェンジセットから原因をたどれる
52

53. Build & Release と共にCodeを使用する
 ソースを分岐する
 「テストと開発を並行で行う時は分岐必須」が常識だが...
 DevOps2.0 では チェックイン 即 自動テスト&リリース
 これだとメインブランチしか要らない
 そうでなければ開発・メイン・自動リリース用のブランチを用意する
 メインブランチにマージすると自動的に単体テスト（※後述）
 開発とテストが完了して、マージしたら自動的にデプロイ（※後述） 53

54. Build & Release による継続的デリバリー
自動ビルド・自動テスト・自動デプロイを実現する
54

55. DevOpsのためにBuild & Releaseを使う
 Work・Test をうまく扱える（Dev）前提で、継続的デリバリー（Ops）を実現
 ソース管理に保存すると、自動ビルド・自動テストされる状態を保つ
 リリースにかかる時間を限りなく０に近づける
 問題が発見された時に、前のバージョンに戻すことも自動化された状態を保つ
 運用やリリースに関わる課題の解決も全て Work バックログの管理で行う。
 プロダクトを継続的に開発
新機能の開発・リリースを2週間程度で繰り返して、競争力を保つ
55

56. 継続的デリバリーがなければ
早いリリースを
繰り返すことは
不可能 56

57. いや、ウォータフォールでは
そんなに繰り返して
リリースすること
ないし… 57

58. ウォータフォールでの継続的デリバリー
 開発したらすぐに検証用サーバー・Azure にリリースして動作確認
 テストチームにテストを依頼するときに、必ず最新のプログラムにしたい
 週次の定例会議で、ちょっとお客様に動きを見てもらいたい（≒アジャイル）
V時の最後のリリースだけが継続的デリバリーの対象ではない！
58

59. 自動テスト（コードによる単体テスト）が前提
 C#/Visual Basic 全てのメソッドに単体テストを作成
 Codeに保存
 DevOpsでは必須
 プログラムを書き換えて自分でテストを実行すると、壊れていないか？確認できる
 チーム開発で、メインブランチにマージしたときに、壊れていないか？確認できる
 単体テストが無ければ、壊れたまま自動リリースされてしまう可能性
あるいは全シナリオテストをやりおなおし必須に 59

60. 単体テストに求められること
 引数と期待される結果の全バターンを網羅的にテスト
 メソッドを使う機能や画面のシナリオテストで、パターン網羅は現実的でない
 VSTS/TFS で動作する必要がある
 SQL Server、SharePoint サーバーなどに接続可能なテスト
 あるいは接続しないで実行できる設計（依存性の注入）
 Fakes（DateTime.Now を置き換える など）
 実行順に依存しない・どの単体テストも単独で実行できること 60

61. 単体テストが作れる開発の方法
 単体テスト出来るアプリの作り方を
スライド＆サンプルで解説しています
「ちゃんとした C# プログラムを書けるようになる実践的な方法
～ Visual Studio を使った 高品質・低コスト・保守性の高い開発」
http://www.slideshare.net/shinichikoga355/starting-c-sharp
 技術イケメン（経験者）にチームに参加してもらって
一緒に２ヶ月程度開発できるとマスターできるはず！
61

62. ビルドとリリースをこう使う
 ビルド定義で自動ビルド・自動テスト （よりDev側）
 どのソースコードをビルドするか？
 単体テストを実行するか？
 パッケージの作成や検証サーバーなどへのデプロイも可能
 リリース定義でビルド後に承認ワークフロー・デプロイ（よりOps側）
 承認すると検証⇒ステージング⇒本番
62

63. まとめ
 VSTS / TFS で出来るのはDevOps
= ウォータフォール or アジャイル（≒Dev）＋ 継続的デリバリー（≒Ops）
 ウォーターフォールでは Projectをマスターとして Work / Test を使う
 アジャイル・スクラムでは Work / Test をマスターとして使う
 Work / Test / Code と単体テストを使いこなしている前提で、
Build & Releaseを使うと継続的デリバリーが実現できる
63

64. 書籍と勉強会のCM
 チーム開発の教科書
http://amzn.to/2euUzrW
 はじめてのASP.NET SPA開発入門
http://amzn.to/2eQKaUa
 第11回 Plus Programming .net 勉強会
「ASP.NET SPA ビギナー&ステップアップ」2016年12月17日（土）
https://atnd.org/events/82659 64

65. Copyright© 2016 Shin-ichi Koga All Rights Reserved. 65