これから C# 開発を始める方、あるいはチームの開発品質をあげたい リーダー・マネージャ向けに、C# の勉強方法を解説した、約２時間の研修用の資料です。

1. ちゃんとした C# プログラムを
書けるようになる実践的な方法
～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
1
Microsoft MVP - ソフトバンク・テクノロジー株式会社（エキスパートエンジニア）古賀 慎一
2015年4月28日（火）
Copyright© 2015 Shin-ichi Koga All Rights Reserved.

2. このセッションのゴール
※本セッションの対象者は C# 初心者、あるいはチームの開発品質をあげたい リーダー・マネージャ
“ちゃんとしたC#プログラムを書く”こと のイメージを持つ
Visual Studioで何が出来るか？ を理解する
 勉強方法を理解し、明日の開発から 実践 出来るようになる
高品質・低コスト・保守性の高い開発を行えるようになろう！
2

3. 自己紹介
3
古賀 慎一
Microsoft MVP for Visual Studio ALM
ソフトバンク・テクノロジー株式会社 Project Management Office (PMO) エキスパートエンジニア
 クラウドサービス Online Service Gate® で TFS 導入事例
 前職では 某大手 情報サイトのデータ入稿システム のフレームワークを開発
 「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか？
 エンタープライズ向けの実践的な C# サンプルを公開

4. アジェンダ
 “ちゃんとしたプログラムを書ける” とは？
 絶対に身につけるべき事
 C#言語の特徴
 領域別 解説
 勉強の仕方
4

5. “ちゃんとしたプログラムを書ける” とは？
具体的なゴールはなんだろう？
5

6. 経験年数に応じて今後10年～20年で経験すること
 言語を理解し、プログラムを書く ( if, for, List<T>, ()=>)
 ライブラリ・サービスを組み合わせてアプリを組む ( NuGet, Azure, SQL )
 自分で設計を工夫し、オブジェクト指向で実装 ( class, interface )
 デザインパターンを理解し、適切な設計を判断 ( LINQ, MVVM, UML, UX )
 プロジェクト全体を俯瞰して課題を解決 ( PMBOK, Facilitation )
 ビジネス・会社・社会・世界を俯瞰して問題を解決 ( Advocacy, Influencer )
6

7. 役割で異なるゴール
 エンジニア
 リーダー
 マネージャ / アーキテクト
 部長・役員・ステークホルダー（株主・取引先・顧客・NPO ）
全体のベスト ≠ それぞれのベスト
次の役割に移る時に必ず障壁がある（評価は必ず後からついてくる） 7

8. 変化する世界で求められるゴール
 Windows の進化
 言語の進化 ( C++, Visual Basic, Java, .net Framework, C#, Ruby, F# ...)
 サーバークライアント, Web, スマートフォン、クラウド、機械学習、IoT
20年前は一つのコンピュータの中で動作するプログラムが書ければ仕事になった
現代では パブリック/プライベート クラウド とのハイブリッドが必須
※C#の最先端はインターネットに繋がるセンサーの制御と得られたビックデータを活用すること ー Azureを使えば誰でも 8

9. グローバルスタンダードはゴール？
 Microsoft 資格 ( MCSD ) ※最新の資格は基礎向けではないので注意
 国家資格 ( ITパスポート、基本情報処理、応用情報処理・・・）
 PMBOK ( PMP )
資格試験で問われる内容は理想論で、現場では役に立たない？
9

10. PMBOKについて説明したものはどれか？
A) システム開発を行う組織がプロセス改善を行うためのガイドライン
となるものである。
B) 組織全体のプロジェクトマネジメントの能力と品質を向上し，
個々のプロジェクトを支援することを目的に設置される専門部署である。
C) ソフトウェアエンジニアリングに関する理論や方法論，ノウハウ，
そのほかの各種知識を体系化したものである。
D) プロジェクトマネジメントの知識を体系化したものである。
10

11. PMBOKについて説明したものはどれか？（答え）
A) システム開発を行う組織がプロセス改善を行うためのガイドライン
となるものである。
B) 組織全体のプロジェクトマネジメントの能力と品質を向上し，
個々のプロジェクトを支援することを目的に設置される専門部署である。
C) ソフトウェアエンジニアリングに関する理論や方法論，ノウハウ，
そのほかの各種知識を体系化したものである。
D)プロジェクトマネジメントの知識を体系化したものである。
※ ITパスポート 平成27年春期 問41 - ITパスポート試験ドットコム ( http://www.itpassportsiken.com/ ) より引用 11

12. グローバルスタンダードはゴールではなく武器
 Microsoft 資格 ( MCSD ) ※最新の資格は基礎向けではないので注意
 国家資格 ( ITパスポート、基本情報処理、応用情報処理・・・）
 PMBOK ( PMP ) ⇒ Visual Studio もこれがわかっている前提で構成
誤：資格試験で問われる内容は理想論で、現場では役に立たない
正：資格試験で問われる共通言語で話せない人は、現場では役に立たない
資格試験は時代に合わせて進化していて、最新のものは実践的で現実的な問題が多い 12

13. あなたに求められるゴールは
時代の変化に応じて最適な手法で
品質・生産性・保守性
を担保できること
13

14. Visual Studio を使って
C#でどうやって
実現するか？
14

15. 絶対に身につけるべき事
Visual Studio で C# を使って開発する基本的・具体的な方法
15

16. 絶対に身につけるべき事
1. 常に綺麗なコードを書く方法
2. 格安で必要な範囲を的確にテスト出来る方法
3. 格安で何度でも容易に安全にデプロイ（配置）出来る方法
4. 複数人のチームで開発する方法
将来 Visual Studio のバージョンが変わっても、これを忘れないこと
※ Visual Studio では設計も扱えますが、このセッションでは解説しません 16

17. 絶対に身につけるべき事
1. 常に綺麗なコードを書く方法
2. 格安で必要な範囲を的確にテスト出来る方法
3. 格安で何度でも容易に安全にデプロイ（配置）出来る方法
4. 複数人のチームで開発する方法
17

18. 1. 常に綺麗なコードを書く方法
 静的コード分析を有効にする
 MVVM を理解する（データバインドを使える）
未経験者にとって覚えることは沢山ありますが、まずこの２つを目標に
※当然 C# の文法などは教科書で勉強する必要がありますが（後で教科書を紹介します）
始める前に知っておいて欲しい！
18

19. 静的コード分析を有効にする
常に綺麗なコードを書く方法①
19

20. 静的コード分析はペアプログラミングの代わり
 Visual Studio プロジェクトに設定（プロジェクト単位でコード分析を有効にする）
 ビルドするたびに、問題を探して警告に表示
 標準の警告より、バグや問題になりやすい問題を詳細に指摘してくれる
優秀なエンジニアとペアプロしている気分
＝（ちょっとウザい時もあるけれど）的確に指摘してくれる
20

21. コードを書く・ビルドする・エラーの説明を読む
 エラーは修正しないとプログラムがうごかないので誰でも直す
 多くの人は警告を無視・放置する
 じゃぁ、警告は何のために出ているのか？＝もしかしてバグなんじゃね？
 10年前に「静的コード分析」が誕生＝もっとバグっぽいのあるんじゃね？
確かに警告のヘルプは何言ってるか？わかんないこと多いけど
10歳以上年の離れた先輩の言っていることも、わからないことが多いから同じような（以下略） 21
この癖を

22. どんなことを教えてくれるのか？（１）
 IDisposable の Dispose 忘れ（using, try-finally で必ず解放）
メモリーリークしていませんか？
GCが動いて突然遅くなることないですか？
 使われていない変数の宣言
宣言しただけで使われていない変数がある
別の変数や仮の定数をいれておいて、変更するのを忘れてないですか？
動かすまでもなくバグっぽいよね 22
最重要！

23. どんなことを教えてくれるのか？（２）
 英語のスペルミス
恥ずかしい（一生残ります）
同じ単語の正しいスペルとスペルミスの2つが存在する場合、バグになる可能性が
 省略形の禁止
昔は長い変数名が使えなかったので省略が普通でした、が、バグも多かった
ml は メーリングリスト の略？機械学習の略？（時代と人によってイメージが違う）
ちょっと口うるさいケド、人間同士で宗教的な論争になるよりマシ 23

24. どんなことを教えてくれるのか？（３）
 この例がダメな理由がわかりますか？
public string CreateTransactionId ( FileInfo userFile ){
return “TR” + userFile.FullName.GetHashCode() ;
}
実際に同様の問題でバグになるケースが沢山あります
静的コード分析を有効にしていれば、「警告」で気付くことが出来ます
 宿題：この静的コード分析の説明とスローされる例外を確認 24

25. 静的コード分析 導入を阻む者達
 新規作成した空のプロジェクトが警告になる ので嫌になる
CLSCompliant (true or false) を追加する
Key.snk ファイルで署名する ー 昔は署名の意味が .net 2.0 の MCP 試験に出題されました
定番の警告は「お決まりのやるべき事」と覚える（そんなに数はありません）
 Visual Studio 2013, 2015 日本語版はバグで、正常に動作しない分析がある
Microsoft にフィードバックしました
今は 英語版を使う or 完全ではなくても日本語版で使える範囲で 25

26. リーダー・マネージャーが肝に銘じること
 開発メンバーが「静的コード分析は難しくて納期に間に合いません」と
言ってきたら
 「納期までに完成させられますが、瑕疵として修正する必要があるバグが
どれだけあるか？私にはわかりません」と言っている と思うべき
 上級者向けではなく、新人教育・コードレビューで指摘する内容
 歴史的経緯・お金の都合でデフォルト有効じゃないだけ
（※ 以前は上位エディションでしか使えなかった。Microsoft の上位機能は手軽さをお金で買うイメージが近い）
26

27. 実際の案件で使えなくても
 C#を勉強するときには必ず「静的コード分析」有効にする
 どんな教科書・サンプルを使った勉強でもこれを実践するだけで、
どんどんちゃんとしたプログラムが書けるようになる！
 自分が担当するときだけ有効にするという手も
 既存資産（会社のプログラムコード、特に2005年より前のもの）には適用出来ない場合もあるが、
適用して何が問題か？確認するのも勉強になります
27

28. MVVM を理解する（データバインドを使える）
常に綺麗なコードを書く方法②
28

29. MVVMはどんなアプリを作るときも標準の考え方
 M : Model
 DBやクラウドサービスから入手したデータを入れる箱
 V: View
 画面に表示して、人間がデータの内容を確認出来るようにする
 VM : View Model
 画面(V) に表示するために、モデル(M) を複製して、その画面用のモデル(VM) とする
※ 2005年頃 Microsoft で提案され、.net Framework 3.0 から採用。JavaScript や Android にも普及
29

30. MVVM : Model – View – View Model の動き
 DBやクラウドから取得した Model を、画面用の View Model に格納
 画面にデータバインドで表示
 双方向バインドなら V でユーザーが値を変える VM も変わる
 プログラムで今度は逆に VM から M に格納、それぞれDBやクラウドに保存する
30
“A” Model
“C” View Model View “C”
Database “A”
Cloud Service “B” “B” Model
データバインド
Data Binding
Web API, WCF
Entity Framework, LINQ to SQL

31. MVVMは変更に強い（保守性が高い）
 新サービスが増えても、DBを変えても低コストで対応可能
31
“A2” Model
“C” View Model
View “C”
part 1
part 2
Database “A2”
Cloud Service “B” “B” Model
データバインド
Data Binding
Web API, WCF
Entity Framework, LINQ to SQL
“D” Model “C2” View ModelNew Service “D”

32. イベントでプロパティを代入するのは古典的
 Console アプリでは前から順に値を出力すればいい
 昔の Windows / Web はその考え方の延長「イベントでプロパティ代入」で実装されていた
 Windows / Web / App 画面を伴うアプリは全てユーザーの入力がある
 現代のアプリは DB や複数のクラウドサービスから値を取得・保存する
 非同期で（リアルタイムに）画面が更新される
 イベントとプロパティ代入では対応出来ない ＝ データバインドが必要
32

33. 昔よく見られた失敗 ＝ 偽３層アーキテクチャ
 画面・ロジック・データアクセスを分離する考えは以前からあった
 分離する強力な「仕組み」が無かったため、意図を守れない実装も多数
 DLL（Visual Studio プロジェクト）は分かれているのに、実際には
プレゼンテーション層に全てのロジックが実装されている場合も・・・
33
Data Tier?
Method “A”
Method “B”
Method “C”
Business
Logic Tier?
Method “A”
Method “B”
Method “C”
Presentation Tier?
事実上、全ロジックが
実装されている
Call Method “A”
Call Method “B”
Call Method “C”
Database
SQL Query Call A, B, C Call A, B, C
MVVMで解決

34. 境界を越えるときは必ずテスト済みであること
 責任の所在が明確
 DB から M を正しく取得することがテスト済み
 M から VM を正しく作れることがテスト済み バグがなく正常に動くはず
 VM を V にバインド出来ることがテスト済み
34
“A” Model
“C” View Model View “C”
Database “A”
Cloud Service “B” “B” Model
データバインド
Data Binding
Web API, WCF
Entity Framework, LINQ to SQL
簡単に
品質を保てる

35. 無理に MVVM にこだわる必要は無いが
 MVVM の考え方が出来ることは必須
 後で説明する「単体テスト」もこの考え方を理解していると簡単に使いこなせる
 HTML5 + JavaScript など他の言語・文化圏でも MVVM が浸透
 今後、Azure のサービスが増えるにつれてますます重要度が上がる
MVVM を意識して C# を勉強してください
35

36. 絶対に身につけるべき事
1. 常に綺麗なコードを書く方法
2. 格安で必要な範囲を的確にテスト出来る方法
3. 格安で何度でも容易に安全にデプロイ（配置）出来る方法
4. 複数人のチームで開発する方法
36

37. 2. 格安で必要な範囲を的確にテスト出来る方法
 F5 デバッグ（ローカルデバッグ・リモートデバッグ・エミュレータ）
 単体テスト
 コード化されたUIテスト
 ロードテスト
自分で書いたコードは必ず自分でテストする 最初の責任をどう果たすか？
※設計や上流工程での問題はここで紹介するテストではなく、「テストスイート」「テストケース」を使って確認します。
ここでは取り扱いません。必要に応じて ウォーターフォールV字モデル や、Test Manager を勉強してください。
37

38. F5 デバッグ（ローカルデバッグ・リモートデバッグ・エミュレータ）
格安で必要な範囲を的確にテスト出来る方法①
38

39. Visual Studio = F5 デバッグ
 プロジェクトを作成して、[ F5 キー ] を押すとアプリが起動する
 多くのアプリがそのままデバッグできる
Windows 上で直接起動
Windows Desktop、Windows Store Apps、ASP.net (Web site)
アプリが起動（アプリ・拡張機能がインストールされた状態で起動）
Visual Studio Extensions、 Office Apps、Office Extensions (Outlook, Word, Excel, PowerPoint )
エミュレータが起動
Windows Store Apps 、Windows Phone Apps、Xamarin.iOS、Xamarin.Android 39

40. F5デバッグ出来る = 最高速で何度も試せる
 何度も試せると、手動での動作確認が数多く出来る
 F5デバッグ出来ないと、その分テストが億劫になる
• 「ちゃんと書けたはずだから確認しなくても、大丈夫だろう」
• 「コードは変えたけど、さっき動いたから全部は確認しなくても、大丈夫だろう」
• 「自分は確認しなくても、誰か他のところで確認されるだろうから、大丈夫だろう」
 自動車の「だろう運転」と同じ ⇒「（バグがある）かもしれない」
40
簡単に
品質を保てる

41. F5デバッグ出来ない＝十分にテストされない
 「Windows Server にインストールしないと動作確認出来ない」は
 リリースされるまで一度もテストされない＝まともに動かない と等しい
 インストールしないと動作確認出来ないアプリの品質を保つのが難しい
Windows Service、Azure Worker Role、SharePoint Page/Workflow、Exchange Transport Agent ...
どんなに責任感が強い人でも こなせる回数が少ない と品質が低くなる
※エミュレータも起動するまで時間がかかると、デスクトップアプリより品質が低くなりやすい
41

42. 何としても F5 デバッグ出来るようにしたい！
 前職で 某大手 情報サイトのデータ入稿システム のフレームワークを開発
 最もこだわったのは F5デバッグ出来ること
1. ローカルで開発しそのまま F5 デバッグ出来る（開発）
2. サーバーにインストールして動作させる別のモードがある（本番）
 「Windows アプリ」として起動する開発モードを用意した
 2ヶ月かかる開発が、2週間でバグ無しで開発出来るようになった
ローカルで十分にテストしてリリースすれば、本番で問題にならない 42

43. クラスライブラリを参照すれば F5 デバッグ出来る
 インストールしないと動作しないものを開発する場合
 （MVVMの考え方と同様）インストールするそのものと、ロジックを分離
 ロジックだけを入れたクラスライブラリを作成
 そのクラスライブラリを参照した Windows アプリを作る 43
クラスライブラリ
(DLL)
インストールが必要なもの
(例：Windows Service）
開発用 Windows アプリ
(WPF)
参照参照
起動するまで 約10秒起動するまで 約10分

44. 画面の部品のみの F5 デバッグ も出来る
 Visual Studio 拡張機能を作る時、ツールウィンドウだけでデバッグ（起動速度が全然違う）
Editor Plus
https://visualstudiogallery.msdn.microsoft.com/af8f350c-b992-464f-b9f3-580b51545f67
44
起動するまで 約3秒起動するまで 約1分

45. UI部品・ロジックを分離してもテストできるか？１
 MVVM を理解していれば可能 ⇒ テスト用に部分的に差し替えても正常に動作する
※ Expression Blend を使うと、WPF アプリの「デザイン用サンプルデータ」を作成可能。起動しなくてもUIを確認出来る。
45
“A” Model
“C” View Model View “C”
Database “A”
Cloud Service “B” “B” Model
データバインド
Data Binding
Web API, WCF
Entity Framework, LINQ to SQL
View “C”“C” View Model
Data Binding
テスト用 View Model
を作るプログラム

46. UI部品・ロジックを分離してもテストできるか？２
 MVVMの 色んな部分を差し替えることが可能 DBにもインターネットに繋がずにテスト出来る
※他社との連携システムを作成するときは、両者で共通して使える スタブ・ドライバの作成が必須
46
“A” Model
“C” View Model
テスト用
View
Database “A”
Cloud Service “B” “B” Model
データバインド
Data Binding
Web API, WCF
Entity Framework, LINQ to SQL
View “C”“C” View Model
Data Binding
テスト用 Model
を作るプログラム
“A” Model
“B” Model

47. インストールしなくてもテスト出来るように！
 低コストで品質を保つためには、如何にF5デバッグ出来るようにするか？
 テストを前提にクラスライブラリ（ロジック・UI部品）を分離する
 MVVM を理解して部品を差し替え可能に
 差し替え用の部品も（ソースバージョン管理に含めて）納品物と同じように扱う
ここで作ったものを「個人のツールとし、人に引き継がない」は絶対にダメ！
47

48. ここまで工夫すれば
F5デバッグだけで
十分に戦える！
48

49. いや、毎回テスト用 View 作るのしんどいし・・・
ロジックを直接
テストしてくれる
画面無いの？ 49

50. 単体テスト
格安で必要な範囲を的確にテスト出来る方法②
50

51. Visual Studio でメソッドを直接テスト
 Visual Studio 単体テスト は C# コードで、C# コードをテストする
メソッド public string CreateTransactionId ( FileInfo userFile ) をテストする時
userFile を様々に変えてテストする、テスト用のメソッドを作成
 Visual Studio がテスト用のメソッドを実行
 一度作ったテストは何度でも使える
※ Java の JUnit と同様。以前は NUnit 。Visual Studio 2005 から標準機能になった。 51

52. テストの実行と結果画面が標準で提供される
 F5デバッグ感覚でテストを実行、成功・失敗がひと目でわかる
 テストケースの分だけテストメソッドを追加
52

53. すぐに試せるサンプルを用意しました
 TFS・VSO・ローカルで動作するデータ
ベースを使った単体テストの作り方・
量産方法
 https://code.msdn.microsoft.com/TFSV
SO-dc7b8c9d
 C# サンプルをダウンロードできます
53

54. F5デバッグより回数をこなせる単体テスト
 プログラムを改修したら、単体テストを開始して休憩に
 休憩から変えるとテスト結果が出ている
 その間に 100～ 200～ 何万テストケースでも自動で実行してくれる
 （他の関係ないと思っていたところを）壊すとすぐに気付く
 完成すると嬉しい
 MVVM でロジックだけを直接テストできるのは、単体テストのみ
54

55. 単体テストで自動でメソッドをテストできるなら
画面操作を
自動でテストする
機能は無いの？ 55

56. コード化されたUIテスト
格安で必要な範囲を的確にテスト出来る方法③
56

57. Visual Studio が人の代わりに画面を操作してテスト
 コード化されたUIテスト は C#コードで、画面をテストする
 Web アプリ / Windows デスクトップアプリをテストする時
 画面を開く、ボタンを押す、テキストを入力する・・・ を C# で記述
 手で操作して「録画」する機能が使える
 Visual Studio がテストを実行（人の操作を代行）
 一度作ったテストは何度でも使える
※MS-Windows 3.1 には、レコーダという人の操作を記録・再生する機能が標準であった 57

58. すぐに試せるサンプルを用意しました
 WPF アプリケーションの「コード化さ
れたUIテスト (Coded UI Test) 」の作り
方 ～ UIのテスト駆動開発とUIMapの保
守
 https://code.msdn.microsoft.com/WPF-
UI-Coded-UI-Test-9ab5581d
 C# サンプルをダウンロードできます
58

59. テストの回数を増やすことが品質に繋がる・・なら
１機能を開発する時に、テスト出来る回数とかかる時間の比率：
※経験に基づくイメージです。テストする範囲が異なるので単純に比較できませんが、これぐらい差が出ると思います。
59
 インストールしないとテスト出来ない 1（手動） 1,000
 F5デバッグが出来る 10～100（手動） 100
 コード化されたUIテストが出来る 10～1,000（自動） 10
 単体テストが出来る 100～10,000（自動） 1

60. ロードテスト
格安で必要な範囲を的確にテスト出来る方法④
60

61. すぐに試せるサンプルは用意できていません
 簡単に言うと Visual Studio で Web サイトに負荷をかける機能です
 F5デバッグで起動した ASP.net Webサイトに自分で負荷をかけます
ローカルWebにも、サーバーにも負荷を変えることが出来ます
 ローカルで早く動かない Web サイトが、サーバーで（以下略
※現在は Visual Studio Ultimate が必要ですが、近い将来 Premium と Ultimate は Enterprise に統合されます
http://blogs.msdn.com/b/visualstudio_jpn/archive/2015/03/31/announcing-the-visual-studio-2015-product-line.aspx
61

62. 絶対に身につけるべき事
1. 常に綺麗なコードを書く方法
2. 格安で必要な範囲を的確にテスト出来る方法
3. 格安で何度でも容易に安全にデプロイ（配置）出来る方法
4. 複数人のチームで開発する方法
62

63. 格安で何度でも容易に安全にデプロイ出来る方法
 発行
 セットアップの作成
Visual Studio Installer Extension を使用
 リリース管理
ただし、今のバージョンは難易度が高い
将来使うことを意識（考え方を身に着けておく）
63

64. 絶対に身につけるべき事
1. 常に綺麗なコードを書く方法
2. 格安で必要な範囲を的確にテスト出来る方法
3. 格安で何度でも容易に安全にデプロイ（配置）出来る方法
4. 複数人のチームで開発する方法
64

65. 複数人のチームで開発する方法
 ソースバージョン管理
 タスク管理
 自動ビルド・自動テスト
全て Visual Studio + Team Foundation Server / Visual Studio Online を使う
65

66. TFS の使い方は他のスライドを参考に
 スクラム開発を始めよう！
TFS を使った日常コミュケーションとチームワーク
http://www.slideshare.net/shinichikoga355/102-ver4
 開発キックオフ時にマネージャが行うべき１１のこと
～Visual Studio Online & TFS 使い始めと HOME 画面の構成
http://www.slideshare.net/shinichikoga355/starting-tfs
 TFS スクラム開発とリリース管理を使えば Rapid Release を行える!
～ Online Service Gate® クラウド サービスの開発事例
http://channel9.msdn.com/Events/Architect-Jump-Start-
Seminar/20141117/Session2 66

67. 自動ビルド・自動テストはサンプルを用意しました
 TFS・VSO・ローカルで動作するデータ
ベースを使った単体テストの作り方・
量産方法
 https://code.msdn.microsoft.com/TFSV
SO-dc7b8c9d
 C# サンプルをダウンロードできます
（※前述のサンプルです。解説を読んでください）
67

68. C#言語の特徴
他の言語との違いを「ふんわり」理解しておく
68

69. C# は JavaScript, VBよりも堅く Java よりも柔らかに
 Visual Basic (VB) と C# はほぼ同じ物
 違いはコンパイラの「思想」だけで、どちらも .net Framework で動作
 VB は厳密にも曖昧にも使える柔軟な言語（1位※）
 Java は厳密に定義する言語（2位※ ）
 JavaScript は非常に曖昧なことを許容する言語（3位※ ）
 C# は VB より厳密に、Java よりは曖昧に調整された言語（4位※ ）
※利用者数：@IT 「Windows 10／Visual Studio 2015への期待と課題」より
http://www.atmarkit.co.jp/ait/articles/1504/24/news018.html
69

70. C# は他の言語の機能と融合してきた
 たぶん C++ + VB + Java + Delphi = C# として誕生
 C# 3.0 から 型推論・ラムダ式・匿名クラス（ 関数型プログラム ）
 ASP.net MVC は Ruby on Rails, Cake PHP に近い（ ”設定より規約” ）
 多くのプラットフォームで動作
 最新版 ASP.net は Linux で動作する
 Xamarin, Unity では iPhone, Android アプリが開発できる
70

71. 領域別 解説
全体像を把握して（古い技術ではなく）新しい技術を身につけよう
71

72. 共通言語仕様
 if, for, while ... 基本的な C# の構文 （ .net 1.0 以降）
 ジェネリック IDictionary<string, int> （ .net 2.0 以降）
 型推論 var, 匿名型, LINQ, ラムダ式 ()=>{}; （.net 3, 3.5 以降）
 dynamic, 非同期 async/await（.net 4, 4.5 以降）
 nameof, null条件演算子 ?. （次バージョン以降）
新しいほど低コストで使いやすく推奨される機能
※ .net のバージョンが同じでも Visual Studio のバージョンで機能が追加される場合が多くあります
※ 新しさと習得の難易度は関係がありません
72

73. データアクセス（データベースの利用）
 SqlCommand で SQL を直接実行
旧式、最高速だが高リスク高コスト
 DataSet, 型付きDataSet
旧式、中～高コスト（進化の途中で扱いにくい）
 LINQ to SQL + Entity Framework
最新、若干低速だが低リスク低コスト
73

74. 作成するもの別
 デスクトップ（ WPF, Windows Forms, Windows Service , Console )
 Web ( ASP.net SPA, Web API, ASP.net MVC, ASP.net )
 スマートデバイス アプリ（ Windows Store, Windows Phone, Xamarin.iOS )
 Office （ Office ストアアプリ, デスクトップ Office 拡張機能, Exchange, SharePoint ）
 通信のみ（ WCF, .net Remoting ）
 Visual Studio（ 拡張機能, 言語, プロジェクト ）
※ SDK の追加インストールや製品の購入が必要なものも含みます。ゲームは Unity や Direct X の知識が必要。
※ 他に IoT (Internet of Things)、機械学習などが今後のトレンドです。
74

75. チーム開発
 ソースバージョン管理
 タスク管理
 テストケース・バグトラッキングシステム
 スクラム開発 / ウォーターフォール開発
75

76. テスト
 F5デバッグ（ローカル, リモート, エミュレータ）
 単体テスト（ローカル, 自動ビルド・自動テスト）
 コード化されたUIテスト
 ロードテスト（Visual Studio Ultimate, Visual Studio Online シンプル）
 テストケース・バグトラッキングシステム
 ラボ管理
76

77. 配置（デプロイ）
 Windows Installer セットアップの作成（Visual Studio Installer）
 発行（Web, ClickOnce, FTP, ファイルコピー）
 Azure 発行
 ストアに登録（Windows Store, Windows Phone, Office Apps )
 Release Management
 Windows Azure への継続的な配信（Visual Studio Online）
77

78. 勉強の仕方
良いサンプルを参考にしてください
78

79. バージョンに注意
 新機能によって、過去の書き方は推奨されなくなる場合が多々ある
 最新のバージョンの教科書で勉強すること
 同じ処理を違う書き方が出来るときは、必ず、最新の書き方を使う事
誤：古い物が初心者向け、新しい物は上級者向け
正：新しい物を使うのが推奨、優しいか難しいか？は場合による
79

80. ネットの「サンプルのための記述」に注意
 サンプルは「説明したい目的の機能」の使い方が
わかりやすくなるように構成
 その他のエンタープライズ開発の要素は考慮されていない場合が多い
プロジェクトの構成、名前の付け方、デバッグしやすい設計、エラー処理・・・
 これをそのまま標準だと誤解して実装したコードが、
社内にも増えている可能性がある（参考にしてよいか？注意が必要）
80

81. 実務の実践だけではスキルアップできない？
 マネージャは（個人のスキルアップではなく）結果を期待
 役員は、個人のスキルアップは現場の上長の責任と認識
 ステークホルダーはスキルを持っているエンジニアが担当することを期待
「これを試しにやってみたい」は、成果が上げられるときに認められる
⇒ 既にレベルアップしていることが条件
81

82. お奨めの教科書
 独習 C# ( http://goo.gl/92a4Pq )
 ASP.NET MVC5実践プログラミング ( http://goo.gl/ii0D15 )
 プログラミングMicrosoft ASP.NET MVC 第3版ASP.NET MVC 5 対応版
(マイクロソフト公式解説書) ( http://goo.gl/HBKvHQ )
まず、C# の言語仕様を理解。ラムダ式とLINQは必ず使いこなせるようになってください。
次に MVVM の経験として ASP.net MVC が教科書が多くてお奨めです。
82

83. 推薦図書
 IT Architects’ Archive―ソフトウェア開発の課題
パターンによるソフトウェア構成管理 ( http://goo.gl/2yF1N1 )
 独習 UML ( http://goo.gl/VYg1ZC )
 PMBOKガイド・マニュアル―第5版対応 ( http://goo.gl/G4oDks )
ソースバージョン管理で「何となく分岐・マージする」のではく、理解して使いこなせる様に。
自分で設計をしたり、チームで会話をするには UML 図を読めるようになりましょう。
プロジェクト全体の流れを理解するために PMBOK を勉強しておくこともお奨めです。
83

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