カテゴリー: その他

今年は全くと言っていいほど何も活動できませんでした。

“2018年のふりかえり” の続きを読む

今年１年大変お世話になりました。もう少しで今年も終わりですので、ちょっとだけ振り返ってみました。

今年はいきなり出張先（仙台）で年越しをするという、ある意味定常運転状態からのスタートでしたが、コミュニティ関連にはあまり出れなかった感があります。
（というか、ここ数年で出張回数が減った＋日程がギリギリでコミュニティに出るスケジュールが組めない(;´Д｀)）

そんな中で、「Xamarinすげー」ということで、ついにMacBook＋iPhoneを購入してしまうという状態になり、少しは新しい技術に手が付けられたのはよかったと思ってます。

あと、ご縁があり、TFSUGとして書籍「アジャイルでやってみた。ウォーターフォールしか知らなかった僕らSIerのスクラム日記」を出させていただくことができました。
自分の力量不足でいろんな方にご迷惑をお掛けしました。改めてご尽力いただきありがとうございました。<m(__)m>

以前にTFSUGメンバーで「TECHNICAL MASTER はじめてのTeam Foundation Server」を出版させていただきましたが、9/17に「アジャイルでやってみた。 ウォーターフォールしか知らなかった僕らSIerのスクラム日記」を出版させていただけることになりました。

前回は技術メインでしたが、今回はストーリーメインとなっています。
ストーリーとしては、上司にいきなりアジャイルやれと言われ、試行錯誤しながら問題に対処していくという内容で、アジャイルって具体的にどうやるの？／初めてアジャイルをするけどどう始めればいいの？という方でも簡単に進め方がイメージできるような感じになっています。

今までの書籍では「機能説明（技術）」か「ストーリー仕立て（プロセス）」のどちらかに偏っているのが多いかなと思いますが、本書は少しだけ技術面をMixして、VSTSの機能を利用して問題に対処する形になっているので、「具体的にどうツールを適用すればいいか」がわかりやすくなっていると思います。

技術面では、機能の全体概要説明という感じにはなっていますが、
・OSSとVSTSの連携、OSSからの移行(Subversion、Jenkins、Redmine、Android Studioなど)
・Application Insights、Power BIといったクラウドとの連携
・前回と大幅に機能が変わったビルドやリリースマネージメント
といったところまでカバーしています。

出版記念イベントが10/5に東京で開催されます。（第36回 TFSUG東京 「アジャイルでやってみた。」出版記念）
企画者の中村さん（@kaorun55）と、著者筆頭のちぇんわさん（@changeworlds）が執筆時の裏話とかについて話されると思います。

また、大阪で開催されるdotnetConf関西（9/17開催）に、著者メンバーである亀川さん（@kkamegawa）がスピーカーとして参加されるので、そこでもお話があると思います。

最後になりましたが、お誘いいただきました中村さん、レビューに多大な尽力をいただきました横田さん・高橋さん、いろいろなアドバイスや帯のご協力をいただきました武田さん・牛尾さん、原稿が遅くなりご迷惑をお掛けしました秀和システムさん、ありがとうございました。あと、筆者一同の皆様、お疲れさまでした。(^^)/

感想ですが、
・DevOps関連としては最強（過去のMSイベント／OSS系イベントと比較して）
　これだけ有名な方々が勢ぞろいしてセッションを行ってくれるのは記憶にありません。
　人数制限で入れなかったのですが、25日の最終セッションで「DevOps 第一人者のガチトークバトル」もあり、
　そちらには日本トップのスクラムコーチである@ryuzeeこと吉羽さんやMS高添さんなども交えたセッションもありました。
・DevOpsとは
　よく「1日10回デプロイすればDevOps」「テストやデプロイを自動化すればDevOps」とか聞きますが、今回のイベントでは「文化」「継続」「計測可能」というキーワードがよく出てました。
　「スピードを出すための自動化」ではなく、「やったことを（ビジネス価値として）計測して、それに基づいて改善するプロセスを継続して実施する文化」ができないとDevOpsではないということかと。
・最近のMSはいい方向に進んでる（気がする）
　自分ごときが言える立場ではないですが、スタンスが昔の「MSテクノロジーだけで」から「いいものは他社のものでも使って。でもMSもいいものあるでしょ」に変わってます。
　MSのテクノロジーもOSS化されているものも多々あるので、本当の意味でオープンになってきているなと感じます。
　DevとOpsの両方をサポートできるMSなので、プラットフォーム／開発の両方を高い融合レベルで使えるメリットは高いと思います。
・セッション大杉
　たくさんセッションがありすぎて、同一時間帯で聞きたいセッションが被ることがありました。
　首都圏の会社なら複数人で手分けして聞けるのでしょうが、地方からではその手は使えないので。
・会場（動線）悪すぎ
　昨年からも言われてますが、会場独特の通路（コの字）とキャパシティの小ささが相まって、セッション間の移動がカオスです。
　中々大箱がないのと、大箱は年単位で予約されているのでなんともし難いのも分かるのですが・・・。

まぁ、生存確認できた方もいらっしゃいましたし、全体的には楽しいイベントでした。
イベント関係者の方々お疲れ様でした。

さて、２日目についてのメモです。

☆楽天でのDevOps実践事例とAzureベストプラクティス
前半はEnterprise AgileやDevOpsをどうやって全社に広めるか、後半はAzureでの実装実例でした。
　今日の定義：アジャイル開発手法をチームを超えて適用する取り組みの総称
　各チームに部分的にアジャイルを適用→組織全体をアジャイルに
　変化に強い
　課題：チーム運営／チーム外との調整／組織全体
　チーム解散→ノウハウ／暗黙知が失われる「記憶喪失」
　SmallTeamの維持／勉強会・コミュニティ／自動化・リポジトリ
　チームの熟成不足：ビルディングに時間がかかる／計画制度が悪くなる→研修／スキル分析／定期的な計画と振り返り
　・スキルとプロセス合意の不足：
　　自動テストが書けないなど
　　研修／テストコーディングの研修／勉強会
　・チーム外
　　・職能別組織：開発チームとの協働のために時間がかかる
　　　事業別組織：情報共有が起こりにくい→調査などの予算や教育が部門ごとに分かれているので
　　　　明確なPO／関係者への成果物のデモとFB
　　・承認プロセス
　　　事前チェックで速度が落ちる
　　　POをチームの中に置く／マネージメントからの支援／関係者への成果物のデモとFB
　・What’s Devps?
　　Faster Feedback for Business
　・Why DevOps
　　どうやって勝つか？
　　　引継ぎをやめる、SmallTeam、Automation
　　　Cross Functional Cover All Skillsets
　・Team Tools Services Data Analysis Process
　・Delevlopers QA Devps Product Manager Project Manager
　・Real time Reporting
　・4拠点に分散
　・コードレビューも自動化
　・SonarQube StyleCop PatchCOnfig
　・TeamCity
　・Blue/Green -> Rollback
　・Performance Test
　・Application Insightsで監視→エラーがあれば一旦エラーテーブルに格納して対応／対応が終わったらエラー情報のクリーニング
　・自動実行部分はAzure Functionを使用
　・AWSのログによく似ている←エラーテーブル
　・これらの確認が完了したサイトをAutoSwapでリリース
　・Traffic ManagerでStagingとProductの割り振りを制御
　・EFを使っていないものもある
　・DBSchemaを変えると他の処理でエラーになる→Microservice
　・週1回エラー内容のレビューを行い、問題と思われるものについては改善を行う

☆赤間さん：拝啓「変わらない開発現場」を嘆く皆様へ
キャッチーなタイトルです。社内でも議論になったようです。
聴講対象は「Excel設計書・打鍵フルパステストに親近感がある方」だそうですww
・いろいろなデバイスに対するUXの追及
・MSのアナウンスに響くのは技術者（協力会社）まで。アーキテクト以上のプロパーには響きにくい
○SI開発手法の変化←10年間で大きく進化した
　・Agility→軽量化
　・課題が多くあるにも関わらず、やり方そのものの改善が進んでいない
　・開発文化が違う→良いところを取り入れる。全部を輸入するのは難しい
　・決定的に異なるポイント：無駄なことを徹底的にそぎ落とす
　　日本の「良き文化」「美徳」が悪い方法に作用している可能性がある
　　→設計作業の最適化／テストの最適化／開発状況の見える化／近代的なプロマネ技術の会得
　・無駄な設計書を書かない／手戻りを減らす
　　当たり前のことを書かない：ex.キャンセルボタンを押すと処理がキャンセルされる
　　コードで自明なことは書かない
　　内部設計作業の先取りをしない：コントロール名・イベントハンドラのつづりの一覧
　　　→現在の開発技術は開発生産性が高い→設計書でワンクッションを置く必要がない
　　・外部設計書：誰が。いつどんなときに、何のために使うのか
　　・Excelで最初から描くのは「手戻り」を考えていない→100%の設計書を1回で作成するのは無理
　　・後工程を完全に想像するのはできない→プロトタイプを作成する／設計の意図を共有する
　　　→タブレット／スマホアプリでは、すべての操作を描き切れない
　　・プロパー～協力会社間で「きれいな境界線」
　　　協力会社のリーダーに「意図の共有」「実装可否の確認」「プロトタイピング」
　　・技術が進化→プロセスも改善しないと対応できない
　　・テストの効率化<>テストの自動化
　　・テストの自動化はコストメリットが出にくい：5～15倍程度
　　　ソフトウェアベンダーがテストの自動化を行っている理由：構成テストの必要性／長期サポートの必要性
　　・テスト設計の効率化
　　　テストケース設計の良しあしで大きく左右される
　　・UT:モジュール単位、IT:業務シナリオベースの機能テスト
　　　ST:非機能要件の品質特性に対するテスト　※日本ではシステム間の連動テストを指すことがある
　　・STは後付けで実施するものではない
　　　設計段階からの実施が必要
　　・UT/ITに非効率なテスト重複が多い
　　　協力会社から納品されたアプリをどこまで再検査すればよいか？
　　・プログラム構造を考える(MVVMなど）で、テストパターンを減らす／一部を自動テストに回す
　　　「ユーザがやりそうなこと」をITで確認
　　・UT:入力パターン網羅／IT:UT完了を前提としたシナリオ網羅
　　・MSでITである一定のUT不良が発生したら差し戻し
　　・DevとTesterを分けない←効率が良い
　　　昔に戻るんじゃ？→UT/iTの作りこみを最適化するには変更が必要
　　・濃淡をつけずにテストを実施→効率が悪い
　　　「バグの抽出」が目標→バグのありそうな場所を重点的にテスト
　　・テストケースの排除の判断は、過去の経験からしか推測できない
　　　→テストインフラを使用して、データの管理と蓄積、分析が重量
　　　　→Excelでは分析が難しくなる
　　・テストの実施効率化は、結果的にWaaS(Windows as a Service)になる
　○まとめ
　　・作れなくてもよいが勘所は知らないといけない
　　・設計やテストにも技術が存在する
　　・基礎理論をおろそかにしない
　　・ツールや手法の背後に存在する「意図」を理解する
　　・最初からパッチ当てを考えない→最終的にどこを目指すか
　　・「根拠のある作業」「根拠のあるSI」
　　・木こりのジレンマ
　　　「刃を研ぐ時間なんてないよ」
　　　時間は有限→自分たちを改善（斧→チェーンソー）
　　・日々の作業を見直し「やり方」を改善
　　・最新技術の背後にある「意図」をくみ、現場に取り込む
　　・魔法の杖はない

☆Jenkins 川口さん：Dockerコンテナによる継続的デリバリのおすすめと新機能の紹介
ちょうとJenkins2.0が出たばかりだったので聞いてみました。
前説がなんとJavaエバの寺田さんでした。寺田さんのリクエストに快諾してくれたとのこと。
　○Jenkinsがミッションクリティカルか？→2015年度は92%
　○ビルドの自動化→テストの自動化→デプロイスクリプトの共有→継続的デリバリ
　○継続的デリバリ　素直で単純な反復可能なプロセスが欠かせない
　○デプロイの現実：手順書、深夜作業、２週間に１回　←　嫌ですよねw
　○継続的デリバリへの道のり：自動化、エラーに耐えるアーキテクチャ、エラーを検知するパイプライン・エラーを許容するインフラ
　　全体の底上げが必要
　○フィーチャーフラグ・ダークラウンチ・マイクロサービス
　○エラー検知パイプライン：ブランチごとで検知　Dev→QA→Production
　○コードレビューの自動検査、信頼できるテスト・ブランチの活用・複数の検問（例：ブランチ毎にテスト実施）
　○テストのサイズ、内容が適切なところで実施されているか
　○インフラ：Bule/Green Deploy、カナリアリリース、不死鳥サーバ(0から構築しなおし)、Immutableインフラ → クラウドだと簡単にできる
　○共通する目標を設定することが重要
　○現状、３割はどこかで手動が入るデプロイ、１割は完全自動デプロイ
　○Jenkinsをコンテナ上で→アップデート、将来の引っ越しが簡単
　○Azure Slaveプラグイン：負荷に応じて自動伸縮、いつも新築、Win/Linuxの両方
　○Labelを使ってビルド環境の対応付け、Init Scriptで初期設定を実施←時間がかからない程度であれば
　　Init Scriptで時間がかかるのなら、イメージから展開
　○30～60分のRetention Timeを設定する
　○Dockerプラグイン(with Docker swarm)
　　利点：ビルド環境の作成・管理・利用が簡単、いつも新築
　　欠点：ワークスペースの再利用なし、AutoScaleNG、Docker in Docker
　○Pipeline as Code：Jenkinsfileに記述、ソースリポジトリに保存できる、パイプライン実行中にJenkinsを再起動できる、とか
　○Jenkinsfileを拡張してDRYにできる
　○Organization Follder：プロセステンプレートの事前登録、自動適用？
　　・利点：設定は１度だけ、Jenkinsfileをコミットするだけ、ブランチ別のビルド履歴、プルリクの自動ビルドと履歴
　　・使うツールの依存関係までは自動解決しない（Jenkinsufile内で「～がなければインストール」と記述。
　　　そのツールの前提となるソフトも全て記述）
　○Jenkins管理者に個々のツールまで管理させたくない
　○チームから全社へ／一家に一台Jenkins→中央集権化
　○運用の効率化、ベストプラクティスの開発と普及、計算機資源のプール
　○Private SaaS Edition(PSE)で、開発者にサービスとしてJenkinsに必要なものを提供
　　チームごとに「Jenkinsが欲しい」と言われたらサービスとして提供。器（ハード）はさっきの中央集権で集約
　　自動的なフェイルオーバー、マルチテナント、個々のマスター配置に悩まない

☆マグナムさん：Azure Resource Managerを利用したIaC
ちょうとAzure上に確認環境が欲しくて、テンプレートから生成するところまでやってみたいと思ってたところでした。
　○３００個を超えるARMテンプレートがあるので、自分で１から作成する必要はない
　○ポータルサイトで自分が作成したリソースのテンプレート出力が可能
　○azuredeploy.json内のparametersの設定内容はazuredeploy.parameters.jsonのparametersから取得する
　○variableは同一テンプレート内で利用する変数を定義
　○Windows以外だとAzure CLIでデプロイ可能
　○最低限覚えておいた方がいいもの
　　文字列連結:concat
　　リソースID取得;resourceId→dependsOnとの併用で多用
　　ロケーション指定:resourceGroup().location()
　　ループ関連（複数のVMを作成するときとか）:copy, copyindex()
　○AzureRmResourceGroupDeployment でテンプレートチェックができる、-Debugで結果を出力してくれる
　○定義ファイルを編集したときは、キャッシュがきいてるので、編集した直後は反映されないときがある
　○管理ポータルの監査ログでもエラー内容を確認できる

☆Chef社James Casey氏：Powering High Verocity Development for your Infrastructure
ここの前説は牛尾さんでした。（DevOps系セッションは前説デフォルト？）
ここでも「Chef!」コール発動w
内容は自社(Chef社)での事例、設計思想っぽいものとかでした。
　○7割はリモートで作業
　○インフラとアプリを同等に扱う
　○「安全に」スピードを持って→Cloud, Automation, Culture
　○早くインフラが使用可能になると、いろんな実験ができるようになる
　○手作業では無理（時間がかかる）→自動化。今までのやり方を巻き込む（バージョン管理、CI/CDとか）
　○ミスが起こっても前に進む。
　○ミスの分析→より早く動ける
　○広めるために：事実と数字。美地熱的な数字につながってる
　○ツールとしてのChef, ワークフローとしてのChef Delivery、DevのためのChef DevelopmentKit、コンプライアンスのためのChef Compliance(テスト)
　○MS Ecosystemとの統合:ハイブリッド（クラウドとオンプレミス）への対応
　○ChefはAzureポータルから導入可能、PowerShellにも対応
　○LinuxもWindowsもフルサポート
ここからはChef社が他社にコンサル／サポートした事例
　○買収などで複数企業のシステムを稼働させる→サイロ化→DevOpsでの最適化
　○いくつかの企業で使ってたChefのベストプラクティスを他の企業にも展開
　○opensshのパッチ適用対応：1person・15minと156persons・9day
ここからはDevOpsの進め方とか
　○データの可視化が重要
　○インフラ構築でもTDDを採用する
　○TDDでスピードと品質に対応する
　○Rubocop：Static Code Analyzer
　○FoodCritic：CookBookのスタイルチェック
　　スタイルチェックは「わかりやすさ」優先
　○ChefSpec:ローカルでのテスト
　○Test Kitchen:テスト環境を設定し、実際にテストを実行
　○たくさんのCookBookが公開されてるので、それを使うこと
　○Chef Complianceから作成した環境のテストを実施、結果をComplianceで確認
　○PowerShellをCookBookの中に入れることが出来る

長くなったので、全体的な感想は次に書きますw

今年もde:codeに行くことができました。
早速ですが、自分が聞けたものについて残したメモを簡単にまとめたいと思います。

☆Keynode
なんかいろいろあった気がしますw
非常にOpenになった、and今年はかつらさんのお話しにもありましたがグローバルレベルでのスピーカー陣だなと思います。
（ナデラのスピーチを筆頭に。まぁ、壇上で踊ったり「DevOps」Jenkins」「HashiCorp」「Chef」「Mesosphere」とかのCall&Responce求めたりする方もいらっしゃいましたが）
とりあえず、（アンチMSであっても）今のMSが提供する技術・情報を拒絶する必要は全くないなと感じました。
個人的には非常にワクワクするものばかりです。
（また、自分がTFSでJavaやってるのもありますが）

☆世界DevOpsトップ企業×MSによるトークセッション
スピーカーが強力すぎます!!これほどのスピーカーがそろうことはOSS系のイベントでも中々ないのでは？
　MS:Sam Guckenheimer, 牛尾さん
　HashiCorp:Michell Hashimoto
　Chef:James Casey
　Mesosphere:Aaron Williams
　クリエーションライン:鈴木逸平氏
英語だったので綺麗には聞けてないのですが、概要／出てくる単語はこんな感じです。
○DevOpsのキーワード:Cloud、Automation、Culture
○Agileの導入しずらさ　ワースト１は日本w
　https://t.co/18jZhbOAFs ← 牛尾さんのTweetで、「文化の違いによるAgile導入難度」のスライド
○黒船とか鎖国とかちょんまげ（ウォーターフォールと形が似てる）とか・・・w
○ScrumのDone：出荷可能
　DevOpsのDone：出荷可能ではないが展開可能＋測定可能←評価可能
○継続的にデリバリー可能＋計測可能　継続的なフィードバック
○ソフトウェア駆動型企業に代わるための活動
○組織変革
○どこにどのような問題点があるのか／本当に変わろうとする意識があるのか
○経験を大事に
○DemoDays
　カイゼンの進捗を見せれば、他の人も変わりたいと思う
　CI, 見える化, Release Automation
　許可を求めるな、後で謝れw
　Value Stream Mapping
　利害関係者を巻き込め
○この製品が面白いと思ってもらって、サポートや拡張機能が欲しいと思ってもらうことが重要

☆安納さん:ハイブリッドなAD設計 Windows Server 2016版
安定の安納さんです。立ち見でした。
○認証は「生産性向上」のため。安全性を確保する条件。→できないことはさせない
○利用者／デバイス／アプリに対する認証
○IdPは統一しないといびつな作りになり、セキュリティホールを生む元にもなる
○パスワード：サーバに渡す（ネットワークを流れる）
　PIN：ネットワークに流れない、PC内にある
　スマートカード証明書：展開が面倒
　PINの代わりとしてWindows Helloが使える
○.NET PASSPORTはユーザとデバイスの組み合わせが正しいことを証明
　※デバイスに秘密鍵
○PASSPORTのリモートアンロック　※Preview
　PCとスマホをBlueToothで接続し認証。PCにプロファイルを残さない？
○PASSPORT for Work
○AADに組織アカウントを登録することでAAD用PRTを取得（Windows 10でAD用PRTと併存可）
○Azure AD Connect
○Windows Server 2012 R2だとKerberosを使えばAAD連携可能

☆高添さん＆小塚さん：Windows系インフラエンジニアのためのDevOps
どうも、Dev系と仲が悪いそうですw（パフォーマンスですよw
○Containerの分離レベル ← Docker
　Windows Container:Registty/Files/Apps
　Hyper-V Container:Windows Container+Process
　※一旦停止する必要があるが、相互に切り替え可能
○特権アクセス管理
　・特定の時間帯のみ特定の処理を実現
○通常SSDとNVMe SSDも認識して記憶域の管理を行える
　CPUボトルネックが出始めている
○25Gbpsネットワーク市販開始

☆SysinternalsやOS標準ツールの徹底活用術
ちょっとしたおすすめツールの紹介です。目指せ脱初心者！
○イベントファイル形式と、その他の形式の２種類でイベントログは取得する
　evtx形式は、メッセージ内容をDLLから取得している
○パフォーマンスモニタで複数のマシンをまとめて監視
○ベースライン取得のためなら、取得間隔は10～15分、取得対象：Processor, Memory, Disk, Network
○ProcessExplorer:SpaceとF5でプロセスの増減を簡単に確認できる（色がつく）
○NotMyFault←自分の好きな色に設定できる
○Symbolファイルも入れておく（オフライン用にDL可能）
○WinDBGで、「! Analyze -v」で簡易解析

セッションの後に参加者パーティがあったのですが、人が多すぎて途中で帰りましたw
セッション間も入室待ちや移動で人が集中するので大変でした。

一日目はこんな感じで。

またもや更新が滞っております( ;∀;)

早速ですが、5/26～27で開催されたde:code 2015に参加してきました。
今回、Galaxy Note 3＋OneNodeの構成で手書きでメモを残してみましたが、以外にバッテリーが持ってくれたのと、
手書きの適当さがイイ感じでした。
仕事の都合で聞けなかったセッションもありますが、簡単にまとめてみます。
※あくまで個人的なメモですので、情報が欠如／一部異なるところもあるかもしれませんがご容赦願います。
　また、記載した内容は2015／05／27時点のものですので、変更される可能性が大いにあります。
　
○基調講演
メッセージとしては、「今までの「クラウド、モバイル」に加えて「IoT」が追加され、あらゆるものが繋がる。
その全てに対してMicrosoftは価値を提供してく」といったところでしょうか。
事例として面白かったのは、TOYOTAの「T-Connect」で車の情報をAzure上に集め、Map上にどれぐらいの速度でどこを走っているのかをマッピングするというものでした。Mapの移動／縮小・拡大に対する反応も即時だったので、「これがクラウドの力か・・・
」という感じですが。
（実は、友山専務のJZA80スープラの写真が一番興味深かったですがｗ）

○アジャイルなビジネスに貢献するIT アーキテクトの役割
　・（主に）Webサービスのレガシー化に対する「MSA(Micro Service Architecture)」は現実解
　・SOAとMSAの違いは文化面。
　　SOAはトップダウン／理想の世界
　　MSAはボトムアップ
　・ドメインは分割、プラットフォームは共通化する方向で検討する
　・要件定義に「ビジネスの価値」を取り込む
　・予算主導→価値の検証／人材の育成ができなくなる

○クラウドプラットフォーム　次期 Windows Server 概要
　・Storage ReEplica
　　SMB3.0、ハード非依存、構築前にレポート作成可能（クラスタと同様）
　　Destination側はレプリカディスクの内容は見れない
　・VM Resiliency（一時的な障害[ちょっとネットワークが見れなくなったとか]）への対応として、
　　-Vの仮想マシンのStateが追加
　　ストレージ：Pause→Stop（30分）
　　ハード間（Quorumが見れないとか）：Isolate, UnMonitor
　・Host Guardian Service（仮想VMのセキュリティ強化）
　　vTPMを使用／保護されたVM（Shield VM）のみ起動
　　→Gen2, Win8以降, LinuxもOK
　・必要な時に必要な特権→Identity Manager
　　新たなADを追加。既存のADは変更不要
　・Hyper-V
　　・構成バージョン：5.0→6.0、構成ファイルがバイナリ化
　　・チェックポイント
　　　今までと同じもの：Standard Checkpoint
　　　VSSベース：Production Checkpoint
　・Nano Server
　　GUIが全くない
　　とにかくリソースが少ない
　・Docker
　　Serverコンテナ／Hyper-Vコンテナの２種類

○MS版Docker 誕生!Windows Server Containers とは?
　・GUI系の操作が必要な場合は「Container Connect」で表示
　　→リモートデスクトップのようなもの
　・テンプレートを集約（セントラルリポジトリ）

○Windows 10 “Windows as a Service”
　・Cortanaで社内データのBI連携（イベントの参加人数を確認／どこから来たのかをMapping）
　・機能改善／新機能の追加を無料サービス化（Windows Update経由）
　・Windows 10への(無償)アップデートはリリースから1年間
　・機能更新は2～3回／年の予定
　・Windows Update for Business(WSB)
　　更新タイミングの調整（早く／遅めに）
　・P2PキャッシュでWU経由でなくても更新ファイルが取得可能
　・リリースまでの工程が大幅変更
　　・開発ビルド
　　・MS社内ベータ
　　・Insider Preview Branch
　　・Current Branch
　　　一般向け、４ヶ月程度を想定、全エディションが対象
　　・Current Branch for Business
　　　ビジネスユーザ向け、４～８ヶ月程度を想定、Professional／Enterprise／Educationが対象
　　・Long Time Servecing Branch
　　　最大10年は機能を固定化（メインストリーム5年、拡張サポート5年）、要SA
　　　WSUS経由のみ対応予定、Enterprise／Educationのみ対象

○Xamarin.Forms と Web API による実践的クロスデバイス業務アプリケーション開発
　・Xamarin.Formからはサービス参照できない→WCF／Webサービスが使えない
　　→WebAPIを使用
　・IIS Expressが使えない　→　Azure Webサイトを使用

○Windows 開発における Visual Studio Online を用いたプロジェクト管理
　・IMEチームでの実例
　・月単位でのサイクル
　・VSOはカスタマイズしたものを使用
　・必ずランク付けを行う
　・各種情報がハイパーリンクで参照できるので、透明性が高くなった
　・パーミッションを変更
　　今まで：部門ごと（アプリ／ＯＳなど）、現在：アクセスフリー
　・マイルストーンごとの成果→月ごとの成果
　・ミーティング：週次→日次
　・担当を固定化→状況により柔軟に割り当て
　　→結果として開発者のカバー範囲が広がる（人材育成）
　・「綿密なリリース」から「試して修正」
　・（チーム？）組織変更
　　・今まで
　　　Developer：内部設計、コード
　　　Tester　 ：テスト
　　　PM　　　 ：外部仕様
　　・現在
　　　Developer：内部設計、コード、テスト
　　　Quality　：ユーザシナリオ検証（基準設定と測定）
　　　PM　　　 ：外部仕様、シナリオ作成
　・顧客体験と機能に対する成功基準を定義、測定

○これが噂の Nano Server ～期待に応えるために小さくなった次期サーバー OS～
　・MSが考えている「データセンターアーキテクチャ」がすごいらしい
　・不要なものは削除
　　・「役割と機能の追加」で持っているインストールモジュール
　　・WOW64
　　・一部サーバコンポーネント
　　・MSIが使えない
　　・GUIスタック
　　　ローカルログオンすらＮＧ
　　・操作はPowerShell
　　・Azure Stack重要
　　・Setup & BootEvent Collectionでセットアップ時や起動時のイベント情報を集約
　　・使える役割は、Hyper-V, クラスタ, File Server, Containerだけ
　　・TechNetにTP2でのNano Serverの作り方が掲載されている
　　　→「Getting Started with Nano Server」
　　　　https://msdn.microsoft.com/en-us/library/mt126167.aspx
　　　　
自分が参加したセッションはインフラ寄りでしたが、印象として次期Windows Server(Windows Server 2016)が
凄そうということと、いままでサーバ系がメインだった高添さんがクライアント（Windows 10）やDevOps関係の
内容を入れてきているところ、IMEチームのVSO使用実例など、今までとは少し違うところがあり、「ナデラに
なってからMSがまた変わってきているかな」ということを実感しました。

あと、参加者パーティの抽選で、ラズパイ頂きました。
最近やっとXamarin触り始めたばかりなのですぐにはIoTまで手が回りませんが、何か使ってみたいと思います。

参加された皆様、イベントを作られたMS社員および関係者の方々、お疲れ様でした。

今年もあとわずかになりました。少し早い気もしますが、ちょっと仕事が立て込んでいるので今年を振り返ってみます。

ちょっと周りで流行ってるっぽいので、今年のアクセス数TOP10を上げてみました。

1 Windows 7 & Server 2008 R2 SP1の正しい適用
2 TFSでの分岐について：基本的な考え方
3 TFS2012ライセンスメモ
4 TFSの分岐について：ワークスペースの作成
5 ユーザコントロールとカスタムコントロールの違い？
6 Hyper-Vで「開始中」のままになったら
7 TFSの分岐について：マージ
8 TFSの分岐について：MAINブランチをどうするか
9 TFSの分岐について：マージで競合が発生したとき
10 コードカバレッジ分析の色分けがちゃんと表示されないとき

SP1の適用が1位なのはちょっと不本意ですが、それ以外にも分岐に関するものが大半を占めていたのも予想外でした。明確な正解がないので、皆さんいろいろ検索されているということでしょうか。

去年の振り返りで、「仕事でもTFSを使おうかと画策している」と書きましたが、ようやく仕事でもTFSを使い始めました。（とは言っても、Javaなんですが(^-^;　）
これで最初の一歩は踏み出せました。

しかし、去年に引き続き仕事が重なったままだったので、勉強会などで登壇させていただく機会は少なかった（なぜか、12月の同日に2回w）のですが、いろいろ大きな機会をいただくことができました。

まずは共著で書籍を発行させていただくことになりました。
TECHNICAL MASTER はじめてのTeam Foundation Server [Kindle版]

発行当初も4店舗限定での発売となり、今となっては電子書籍のみの状態で少し寂しい状態ですが、こういった機会に巡り合えたことに感謝です。

また、初めてMicrosoft MVP Awardを受賞させていただくことができました。

本当にこの２つは大きな機会でした。ありがとうございました。

残念だったのは、これも去年の振り返りで書いてたのですが、TFSのハンズオンができませんでした。来年にはVisual Studio／Team Foundation Serverも次のバージョンが出るでしょうから、新しいバージョンでのハンスオンもやってみたいです。

今年もいろいろな方々にお世話になりました。来年もよろしくお願いいたします。<(_ _)>