とあるコンサルタントのつぶやき https://docs.microsoft.com/archive/blogs/nakama/feed.xml MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 Mon, 05 Nov 2018 05:23:21 GMT ja hourly 1 触って覚える Microsoft Azure https://docs.microsoft.com/archive/blogs/nakama/learn-microsoft-azure Mon, 05 Nov 2018 14:17:49 GMT https://blogs.msdn.microsoft.com/nakama/?p=4695 特に先日リリースされた Microsoft Learn は、ハンズオン形式で実際に Azure を触りながら学習できる素晴らしいものになっているため、この秋にクラウドデビューしたい！ という方はぜひ使ってみてください。
  • 無償で触れる Azure 環境
    • Microsoft Learn
    • Azure 無料アカウント
    • MSDN 利用者特典
  • 無償の学習マテリアル
    • Azure サイトの歩き方
    • AWS ユーザ向けの Azure 解説
    • mstep
    • マイクロソフトのイベント資料
    • docs.microsoft.com
■ 触れる Azure 環境について [Microsoft Lean] Azure をハンズオン形式で触って学べる Web オンライントレーニング環境です。 先月の Ignite でリリースされたシステムで、約 100 件程度のハンズオンラーニングが用意されています（すべて日本語化済み）。 https://docs.microsoft.com/ja-jp/learn/browse/ このサイトのすごいところは、サンドボックス環境が用意されており、無償で Azure を触ってみることが可能なところです（クレジットカード登録も不要）。さらにトレーニングを完了するとポイントが付与され、どの程度学習したかがわかるようになっています。この仕組みにより、ゲーム感覚で楽しく学べると思います。 image 実際にサイトを利用する場合には、Azure ラーニングパスを利用し、テーマに沿って一連のハンズオンを学習するとよいです。 最初にオススメのラーニングパスは以下の 3 つです。まずはここから。
  • Azure の基礎 （Azure の基本機能の理解）
  • Azure でインフラストラクチャ リソースを管理する（IaaS の理解する）
  • Azure App Service を使用して Web サイトを Azure にデプロイする（PaaS の理解）
[Azure 無料アカウント] https://azure.microsoft.com/ja-jp/free/ からサインアップすると、30 日間有効な \22,500 分のクレジットを取得できます。本人確認のためにクレジットカードの登録が必要ですが、従量課金プランに移行しない限り課金はされません。制限事項として、① 30 日間限り、② クレジットカード必要、③ 複数回の利用不可、があるため、Microsoft Learn である程度学習を進めてから、一気に使うのがよいでしょう。 image [MSDN 利用者特典] MSDN（Visual Studio）サブクライバーであれば、こちらのサイトからアクティベーションすると、毎月\6,000～\17,000程度の利用権が与えられます。（保有するサブスクリプションにより、利用できる金額が変わります） https://azure.microsoft.com/ja-jp/pricing/member-offers/credit-for-visual-studio-subscribers/ image ■ Azure 学習マテリアルについて [Azure サイトの歩き方] https://www.microsoft.com/ja-jp/cloud-platform/azure-site-usage テーマ別の日本語資料が欲しい場合に便利なサイトです。Web セミナーやハンズオンラボなどの豊富な学習リソースが提供されています。 サイトの下の方には各種活用資料が集められているため、まずはここを検索してみるとよいでしょう。また、とっかかりとして、ハンズオン資料をやってみるのもオススメです。 image [AWS ユーザ向けの Azure 解説] すでに AWS を使っている、使ったことがある、という場合には、AWS とのアナロジーで Azure を理解すると手っ取り早いです。このために、AWS ユーザ向けの Azure 解説資料が結構たくさん用意されています。AWS を知っている方はこちらをどうぞ。 https://docs.microsoft.com/ja-jp/azure/architecture/aws-professional/ https://docs.microsoft.com/ja-jp/azure/architecture/aws-professional/services https://azure.microsoft.com/ja-jp/blog/cloud-service-map-for-aws-and-azure-available-now/ image [mstep] https://partner.microsoft.com/ja-jp/training/mstep-online マイクロソフトパートナーネットワークに登録されているお客様が無償で受講できるオンラインセミナーです。対象ロール、学習レベルごとにラインアップを用意しており、テキストのダウンロードも可能です。 image mstep に関しては社員登録作業が必要なため、若干面倒です。以下が登録作業手順になりますが、（特に大きな会社だと）厄介なのが「うちの会社ってパートナー登録されてるの？ & 誰が管理者なの？」という点だと思います。不明な場合はマイクロソフトまでお問合せいただければと思います。（が、実は個人事業主でもパートナーネットワークに登録できるらしいのでごにょごにょ．．．．） image [マイクロソフトのイベント資料] マイクロソフトでは多数の技術者向けイベントを実施していますが、フラッグシップイベントでは極めて有益かつディープな Azure の情報が出てきます。ある程度学習が進んで特定技術について深掘りしたくなった場合には、こうしたイベントの資料で最新のディープな情報を学習するのがオススメです。 なお、マイクロソフトのフラッグシップイベントは開発者系／IT Pro 系の 2 系統があり、さらに日本語／英語のイベントがあります（下表のとおり）。ほぼすべてのセッションが、イベント後にオンデマンドで公開されます（資料・動画ともに）ので、キーワードで Web 検索してみてください。 image [docs.microsoft.com] https://docs.microsoft.com/ja-jp/azure/ マイクロソフトの製品ドキュメントが網羅的に存在するサイトです。現在はチュートリアル類も豊富に用意されているため、困った場合にはこのサイトのドキュメントを調べるとかなり技術的な深掘りができます。私自身、特定の技術を深く知りたい場合には、必ずこのサイトの製品ドキュメントを一通り読むようにしているのですが、昔のマイクロソフト製品のドキュメントに比べてかなり実践的で、質が高いです。（なお、一部機械翻訳されているものについては日本語訳がよくないので、英語の原文で読んだ方がよいです。） image また、Azure の各種リファレンスアーキテクチャもこのサイト上に掲載されています。書籍化されていないのが正直もったいないぐらいで、マイクロサービスアーキテクチャなど近代的なアーキテクチャについても多数扱われています。（初学者が読むにはかなりキツいので、まず上の方を一式終わらせてから、ですが。） https://docs.microsoft.com/ja-jp/azure/architecture/ image [まとめ] というわけで、Azure の学習に利用できる代表的な無償リソースをひととおりピックアップさせていただきました。まずはこの辺から Azure を触っていただき、理解を深めていただければと思います。
  • 無償で触れる Azure 環境
    • Microsoft Learn
    • Azure 無料アカウント
    • MSDN 利用者特典
  • 無償の学習マテリアル
    • Azure サイトの歩き方
    • AWS ユーザ向けの Azure 解説
    • mstep
    • マイクロソフトのイベント資料
    • docs.microsoft.com
ここに挙げた以外にも、Azure を深く学習していくための資料をこの blog にアップしていきたいと思いますので、ぜひ本 blog も引き続きチェックしていただければと思います。
※ なお、エンプラ系のお客様の場合、別途、個別支援をご提案できる場合がございます。弊社の営業担当がいる場合には、ぜひお気軽にご相談いただければと思います。]]> Docker for Windows & Web Apps for Containers 実践活用技法 https://docs.microsoft.com/archive/blogs/nakama/dockerandazure Thu, 27 Sep 2018 09:31:00 GMT https://blogs.msdn.microsoft.com/nakama/?p=4475 この資料はタイトルの通り、アプリ開発の実践的な視点から Docker for Windows と動作環境である Web Apps for Containers を使ってみよう、というもので、Docker の基本的なところから解説しています。あくまで実践！ ということで、一般的な Docker の本で書かれている内部的な話とかレイヤーの話とかはガン無視してます。まずこの資料などで Docker for Windows の使い方を理解してから、その筋の専門書を読んでいただくと理解が早いんじゃないかと思います。 この資料で解説している内容は、大きく 2 つあります。 ① Docker for Windows を使って、Windows OS 上で Linux アプリを作る方法 image Docker for Windows のよいところは、「開発は Windows OS の使い慣れたエディタで、実行・動作確認は Linux OS 上で」という構成が、Windows マシン 1 台で簡単に構成できるところです。意外にこの仕組みがきちんと説明されている資料がネット上でほとんど見当たらないこともあり、なかなか Docker for Windows が活用されていないのでは、という気がしています。資料では Java アプリを Windows 上で開発・デバッグし、最後に Linux OS 上で動作確認を取る、という流れで解説をしています。 ② Docker コンテナを VSTS (Azure DevOps) 上で作成し、Web Apps for Containers で動作させる image Docker コンテナを動かすクラウドサービスは、CaaS (Container as a Service) などと呼ばれますが、CaaS は IaaS と PaaS の中間に位置するようなソリューションです。すなわち、PaaS であれば OS・ミドルへのパッチ当ては全自動ですが、IaaS だと手動になってしまう。これを回避するには、上図のような CI/CD（自動ビルドと自動リリース）の仕組みを作成しておき、最新のパッチが当たった Docker イメージの作成・展開がワンクリックでできるようにしておくことが重要になります。このような仕組みは VSTS (Azure DevOps) と Azure Web Apps for Containers を使うと超簡単にできるのですが、意外にそのやり方が知られていません。このやり方について、資料後半で解説しています。 ＃ 上記で利用している Java のサンプルコードについてはこちらにアップしておきました。実際に手を動かして学習したい方は演習用に利用してみてください。 ＃ 環境構築方法などもろもろ基本的な部分については割愛しちゃってますので、その辺の前後作業についてはこの資料をベースに、Step-by-Step 化してくださる方が出てくることを祈っています（他力本願；）。 なお、本資料では解説していませんが、Java の Web アプリを動かすだけなら、純粋な PaaS 環境である Web Apps for Windows か Web Apps for Linux の方がオススメです。今回は、Linux Docker 上で動かすサンプルとして Java アプリしか持っていなかったので Java を例に取って解説しているのですが、シンプルな Java の Web アプリならコンテナのような大掛かりな仕掛けを作る必要もなく、単純に PaaS Web Apps で手軽に動かせるんですよね；。その辺の話についてはまた別の機会に書きたいと思います。 ではでは、なにはともあれ Docker for Windows と Azure を使って、素敵なコンテナライフを！ ＃ ご意見・ご感想はこちらのコメントでも、あるいははてブでも大丈夫です（ブクマしておきました）。]]> Agile も DevOps も銀の弾丸なんかじゃない https://docs.microsoft.com/archive/blogs/nakama/agiledevopsisnotsilverbullet Tue, 28 Aug 2018 10:11:33 GMT https://blogs.msdn.microsoft.com/nakama/?p=4425
  • アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ？ → そんなわけないでしょ；。
  • これからの開発は当然アジャイルとか DevOps でしょ！ → そんなわけないでしょ；。
    • みたいな話；。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～」というエントリを書いたのですが、その補足的な意味合いも兼ねて、少しまとめてみようと思います。正直、当たり前すぎる話なので、その道のプロな方は「ふ～ん」と読み流してください；。 ［アジャイルや DevOps を活用することによる ROI 最大化の注意点］ のっけから結論を書いてしまうのですが、アジャイルや DevOps をエンプラ系プロジェクトに適用してメリットを得たい場合には、以下 2 つの点に特に注意する必要があります。 image 簡単に言えば、十把一絡げにアジャイルや DevOps を適用してもうまく行くわけがなく、これらの手法は決して銀の弾丸ではありません。しかし、なぜこれらが銀の弾丸ではないのか、またどんな条件があればアジャイルや DevOps のメリットが最大化されるのかは、意外に端的に語られていないため、軽く説明してみたいと思います。 ［アジャイル開発 vs ウォータフォール型開発］ モノづくりの観点から考えると、ウォータフォールとアジャイルは、計画型／適応型のトレードオフの関係で捉えることができます。このため、それぞれ請負向き／内製向きという特性があることは、以前のエントリでも解説しました。日本の開発現場では、両者は二者択一の文面で語られることが多いのですが、日本のエンプラ系開発現場においてより良い開発を目指すためには、両者をミックスした開発プロセスのテーラリングが必要になります。 image しかし、このような説明だとなかなかしっくりこないと思いますので、ぶっちぎりの適応型アジャイル（ここでは仮に「フルアジャイル」と呼ぶことにしましょう）がどのようなものなのかを考えてみたいと思います。 ［完璧（？）なアジャイル開発について］ ご存じのように、アジャイル開発の背後には、「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」がベースラインの考え方として存在します。原典そのまま引用すると、こんな感じです。 image しかし見ていただければわかる通り、これらは具体的に何かの（技術的）手法を定義しているわけではなく、ある意味、ソフトウェア開発の『理想像』や『思想』を語ったものに近いです。実際、アジャイルを実践する開発現場では、日々、自律的な模索と改善が続けられ、よりよい開発技法を目指して進化を続ける……これこそがアジャイルの真価ではないかと思います。 ……が、ぶっちゃけこれだと煙に巻かれた気がするなんだかよくわからないのも実際のところです；。以下は完全に私の私見なのですが、実際にこれらを目指して優れたアジャイル開発を実現している現場では、特に以下の 4 つをきっちり実践しているように思います。（この辺は皆様のご意見をいただきたいところですが、私の感覚として。） image ちょっとだけ補足をすると、以下の通りです。（MVP アプローチは極めて重要なので後述）
    • 内製開発
      • 一般的に請負型ウォータフォール開発では、受発注関係による利害関係が生じるため、請負契約の後は、発注側は「いかに変更・修正を突っ込むか」、受注側は「いかにそれを突っぱねるか」という不毛な争いが生じます。
      • （特に大規模開発においては）請負契約は、確実に成果物責任を以て遂行させるという観点において極めて重要なものですが、一方で、関係者全員が同じ方向を向いてゴールを共有することが時として難しくなる元凶にもなり得ます。
      • 内製開発であれば関係者全員が同じ方向を向いてゴールを共有することが容易ですが、その一方で、全員がプロフェッショナルであり、オープンかつ自律的な活動・改善ができる（言い換えれば全員が大人である）ことが求められます。（大規模開発だとそれだけの数のプロフェッショナルの頭数を揃えることが困難なケースが多いです。）
    • データ駆動型開発（運用環境第一主義、Production First Mindset）
      • 例えば仕様案として A, B の 2 つがある場合、実際の開発現場では、どちらを採用すべきかは一番偉い人の鶴の一声で決まることが多いです。しかしこのような主観的な物事の決め方では不適切な決定が行われることも多く、「客観性を以て」、すなわち「データを元に」開発上の様々な判断を下すことが求められます。このような考え方を「データ駆動型開発」と呼びます。
      • データ駆動型開発を実現するために重要になるのが、「運用環境からユーザーの実際の使い方の情報を吸い上げる」ことです。このようなデータをテレメトリデータと呼び、運用環境での実際の情報を元に開発判断を下すことが望ましいです。このようなアプローチを「運用環境第一主義」と呼びます。
    • DevOps インフラ
      • データ駆動型開発や運用環境第一主義を実現するためには、A/B 両案を素早く作って素早く運用環境に配置し、運用環境からテレメトリデータを吸い上げ、それに基づいて決断を下して運用環境に反映させていく、という素早いサイクルが必要です。このために DevOps インフラが利用されます。
    ……とまあこの辺はよく語られるのですが、アジャイル開発の本質をよく言い当てているのが MVP アプローチです。これについて解説します。 ［MVP アプローチ（Minimum Viable Product）について］ MVP アプローチとは、最終的な完成物を想定して段階的に作り上げていくのではなく、「価値」を検証できる成果物をまず小さく作り、それを元に F/B を集め、軌道修正しながら最終成果物を目指すものです。これに関しては、Henrik Kniberg 氏のこちらの blog の下図が、極めて的確に本質を言い当てているので引用します。 mvp イラストを見れば一目瞭然だと思うのですが、アジャイルのアプローチは、上図ではなく下図のようなものです。つまり、「どこかに行くときに素早く行ける乗り物が欲しい」というお客さんに対して、
    • 上図のアプローチは、「きっと車が欲しいに違いない」と考え、最終成果物を先に想定してしまい、これを段階的（Incremental）に開発していく方法。
    • 下図のアプローチは、「本当にお客さんが欲しいものはわからない」と考えて、とりあえずキックボードを作ってみて反応を伺い、そのあと自転車を作ってみて反応を伺い、最後にはスーパーカーを作って満足させる、という方法。
    です。このケースにおいては当然下図のアプローチの方がよいわけですが、その理由は、
    • 上図のアプローチは、価値検証が最後までできないため、開発のリスクが高い。（成果物の ROI が最大化されない）
    • 下図のアプローチは、価値検証しながら進むため、成果物の ROI が最大化される。
    というものですが、その一方で、下図のアプローチの場合は頻繁な作り直しが必要になるため、開発作業量は大きくなるという問題を抱えています（プログラミングの観点で言うのなら、無理な作り替えにより生じた技術的負債の適宜返済が必要になる）。最終成果物が最初からきっちり確定できているのであれば、上図のアプローチの方が最短経路でゴールにたどり着けます。 ＃ 最終成果物が最初からきっちり確定できていることなんてない、と言われる方もいると思いますが、 ＃ 例えば、サポートの切れた製品上で開発されたシステムをどうしても .NET などで再構築しなければ ＃ ならないような SoR 系のシステム場合には、最終成果物が概ね見えていることが多いです。 ＃ このような案件では、上図のようなインクリメンタルなアプローチで開発した方がよいでしょう。 このことから、なぜアジャイル開発で ROI が最大化されるのか、そしてどのような開発にアジャイル開発が適しているのかに関して、以下のように整理できます。 image 現在の多くのエンプラ系のシステム開発案件は、既存資産まみれの中で開発することが多く、スクラッチでゼロから綺麗なシステムを構築するのではないケースがほとんどです。こうした条件下では、必ずしも MVP アプローチに代表されるようなアジャイル開発が最適とは限りません。そしてなにより、一定以上の規模の開発においては、頻繁な方針転換・作り直しをテキパキとこなせるだけの優れた高スキルなデベロッパーの頭数を揃えることが難しく、結果として、MVP アプローチをやろうとしてもできない場合が少なくありません。 ＃ ぶっちゃけですが、優れた開発者を頭数揃えられれば、どんな方法だってまあまあうまくいくはず；。 ＃ 大規模開発で戦わなければならないのは、メンバーのスキルセットの平準化と底上げなんですよ；。 もちろん、アジャイルが無理だからといってウォーターフォールでやる、というのは短絡的です。以前のエントリにも書いたように、重要なのは、ウォーターフォール型開発をベースラインに置きながらも、アジャイルの手法をうまく取り入れることによって開発生産性の改善を目指す、すなわち開発プロセスを適切にテーラリングすることです。具体的な様々なテクニックについては拙著「業務システム開発 モダナイゼーションガイド」にいろいろ書いたのですが、ここでは「ウォータフォールとアジャイルのいいとこどり」という観点で、3 つほど具体的な方法を取り上げてみたいと思います。 ［アジャイル開発技法の適用対象・活用手法］ 本来のアジャイル開発（Scrum 開発など）をそのまま適用できないプロジェクトでも、アジャイル開発のプラクティス（技法）を部分的に活用した生産性改善は可能です。現場でよく利用される代表的なテクニックは以下の 3 つです。
    • ① UX デザインフェーズにアジャイル開発技法を適用（アジャイルウォータフォール）
    • ② CI/CD による下流工程の作業生産性の改善（頻繁なリリース（≠ 早期のリリース））
    • ③ ボトムアップ型タスク管理を用いた予実管理と作業完了の推定（ミニアジャイル）
    ＃ 勝手に名前つけましたが、すでに業界的に標準名が決まっていたら教えてください；。 image それぞれについて説明します。
    ① UX デザインフェーズにアジャイル開発技法を適用（アジャイルウォータフォール） 大規模開発を安定的に進めるためには、どこかのタイミングでいったん仕様を確定させる必要があります（＝仕様のベースラインを決めて、そこからの修正については「仕様変更」として管理する）。UI/UX は試行錯誤による改善が求められるため、外部設計終了のタイミングで仕様を確定させる方法が一般的で、ここでアジャイル／ウォータフォールのアプローチを切り替える方法がよく取られます。すなわち、要件定義～外部設計までは（モックを高速に開発・提示して F/B を受けて修正する）アジャイル型で進め、外部仕様が確定した時点からはウォータフォール的に開発を進める、というものです。この方法はエンプラ系システム開発でも極めて取り組みやすく、実際の現場でも頻繁に使われていると思います。 ② CI/CD による下流工程の作業生産性の改善（頻繁なリリース（≠ 早期のリリース）） 下流工程での作業効率を高めるために、以下の CI/CD の仕組みを導入することは極めて有効です。ちなみに VSTS だとぜんぶ簡単にできるよ！ と宣伝w。
    • ソースコード管理
    • 自動ビルド
    • （カナリアサーバやテストサーバへの）自動リリース
    • （部分的な）テストの自動化
    • 手動テストの効率化
    ＃ これらについては拙著「業務システム開発 モダナイゼーションガイド」にいろいろ書いたので、ここでは割愛。 ③ ボトムアップ型タスク管理を用いた予実管理と作業完了の推定（ミニアジャイル） 下流工程の一連の作業がきちんと予定工期中に終わるかどうかを確認するために、ボトムアップ型タスク管理を用いた予実管理を行うのも非常に有効性があります。こちらも以前のエントリにおいて「Scrum のスプリントプラクティス」にて解説していますので、興味がある方はご確認ください。 これら 3 つの技法のポイントは、基本路線としてはウォータフォール型開発を維持しつつ、アジャイル開発のプラクティスをうまく取り込んでいくものだという点です。特にエンプラ系の大規模開発（数億円を超えるようなプロジェクト）では、ベースラインをウォータフォール型に置いた方がよいケースが多く、いきなりフルアジャイル型でやろうとすると、特にお客様が（慣れていないために）対応できないことがほとんどです。最終的にフルアジャイル型を目指すにしても、段階を追って切り替えていく・成長していくことは重要です。フルアジャイルを実践している開発現場だって、いきなり現在の開発スタイルになったわけではないのですから。 ［実際の作業ワークフローの設計例］ 以上のような考え方に基づき、実際の開発では、開発作業のワークフローを下図のようなコンセプト図として整理することをオススメしたいです。ちなみに下図は、モバイルアプリ開発にエンプラ系企業が手を出そうとする際に、割とスムーズに受け入れられやすそうな形でワークフローを整理したものです。 image 上図の場合、作業ワークフローの設計上、以下のような点がポイントになっています。
    • ユーザエクスペリエンスチームとサーバ／クライアント開発チームを分断している モバイルアプリ企業の場合、ユーザエクスペリエンスチームとクライアント開発チームとが合体している場合も多いと思います。しかし、エンプラ系企業が開発するモバイルアプリの場合、UI/UX の裏側に実装するロジックもそれなりのボリュームになる場合が多く、外部仕様を固めてからアプリの開発に進まないと、開発の制御がしにくくなることがよくあります。このため、外部設計段階で仕様をいったん fix できるように、開発チームを分断しています。
    • サーバ／クライアント開発チームを分断している エンプラ系企業がモバイルアプリ開発に取り組む場合、バックエンドのサーバロジックはすでに基幹系として存在しており、API のみ追加開発するような場合も多いでしょう。一方、クライアント側のモバイルアプリ開発に関しては、言語からして Swift など異なるモノを使う場合も多く、スキルセットが異なります。さらに、開発のサイクルも、サーバ／クライアントで速度感が異なると考えられるため、これらのチームを分断するようなワークフローとして設計しています。
    • 複数の開発・テスト環境を用意し、段階的リリース（リング配信）ができるようにする 現在開発中のアプリがすぐにみられるカナリア環境、ある程度開発が進んだアプリについて構成テストを行えるようにするテスト環境、さらにβチャネルを介して先行ユーザ配信を可能とする運用環境など、目的に応じた多段階配信ができるようにリリースシステムを設計します。
    再三の繰り返しになりますが、このような設計がよいかどうかはもちろんケースバイケースです。チームやプロジェクトの実態に合わせて、開発プロセスをテーラリングすることがなにより重要です。 ［アジャイルと言いながら偽装請負にならないために］ ここまではウォータフォール型にアジャイルを組み込む流れで説明しましたが、本当のアジャイル型で開発をやりたい場合に関して、一点だけ書かせてください。実際の開発現場でよく見かける光景なのですが、アジャイル開発は請負型ではダメ、ということでベンダーさんと準委任契約を取り交わしているにもかかわらず、お客様がアジャイルのチームに入ってこない、というケースがあります。例えばスクラムのチーム体制に基づいてイラストを書くと、下図のようになっている場合があります。 image アジャイル開発で新しいシステム開発スタイルに変えていきたい、という前向きなお客様は結構いらっしゃいますが、このパターンに陥ると失敗する確率がかなり上がります。理由は簡単で、本来、プロダクトオーナーは業務要件を整理し、それらに対して適切な優先順位付けとスコーピングを行うことがゴールなのですが、お客様がチームの外にいると、なんでもかんでも押し込もうとしてしまうためです。お客様からの要件詰め込みの圧力に対抗するためには、実際にお客様がプロダクトオーナーの立場としてプロジェクトに参画しなければならず、この体制を最初に作れるかどうかが極めて重要です。 多くの場合、お客様側はアジャイル開発やスクラムに十分な知見を持っていないため、お客様からアジャイルやりたい、と言われた場合には、このようなリスクについて十分に事前に説明すること、そしてプロジェクトの立ち上げ時点できっちり体制を組むことを、特に気を付けていただけるとよいかと思います。 ［まとめ］ というわけでここまでいろいろ書いてきましたが、要点をまとめると以下の通りです。
    • アジャイルや DevOps のメリットを享受するためには、① 適用対象プロジェクトの見極めと、② プロセステーラリングの 2 つが重要。
    • フルアジャイルの特性は、① MVP アプローチ、② 内製開発、③ データ駆動型開発、④ DevOps インフラの 4 つに代表されるが、これらを完全に適用できることは、エンプラ系開発だと稀。
    • MVP アプローチが、アジャイルアプローチの本質を言い当てている。頻繁な軌道修正と作り直しが必要とされるため、万能な開発技法というわけではなく、プロジェクトに以下のような特性・要件が必要。
      • SoE 型アプリ
      • 初期段階で最終要件が確定できず、試行錯誤が必要になるもの
      • 進化させ続けることが必要な戦略領域のアプリ
      • スクラッチ型開発が必要そうなもの
    • エンプラ系の大規模開発で、ウォータフォール型開発にアジャイル型開発のプラクティスを取り込む場合、以下の 3 つが代表的なテクニック。
      • ① UX デザインフェーズにアジャイル開発技法を適用（アジャイルウォータフォール）
      • ② CI/CD による下流工程の作業生産性の改善（頻繁なリリース（≠ 早期のリリース））
      • ③ ボトムアップ型タスク管理を用いた予実管理と作業完了の推定（ミニアジャイル）
    • 実際にアジャイル開発を行いたい場合、お客様側から開発チーム側に PO （プロダクトオーナー）を出してもらうことが極めて重要。ここを外すと偽装請負的な開発になってしまう。
    アジャイル開発に関しては様々な考え方があると思いますし、このエントリが必ずしも正しいというわけではないと思います。が、このエントリが、皆様が開発現場でより良い開発手法を模索するための一助になれば幸いです。 ＃ ご意見やアドバイスは、コメントやはてブ、Twitter などでいただければ嬉しいです^^。 ＃ 皆様の知見に基づくご意見やアドバイスをぜひ共有してください～。]]>         .NET Framework における時差情報（サマータイム）の取り扱い https://docs.microsoft.com/archive/blogs/nakama/timezone Sat, 11 Aug 2018 04:55:43 GMT https://blogs.msdn.microsoft.com/nakama/?p=4235
  • 「サマータイム導入はコンピュータシステム的に難あり」は本当か
  • サマータイム実施は不可能である
    • 2020 年のオリンピックに向けて、限定的（または恒久的）にサマータイムを導入する、というもの。話を聞いたときに耳を疑ったのですが、いやもう絶対に不可能だろう、と私も思いました；。上記に取り上げた立命館大学の上原さんのスライドは非常によくまとまっていて、ホントこれ、と思いましたが、一方で Windows をはじめとするコンピュータシステムでそもそもサマータイムがどのような取り扱いになるのかを知らない人は多いのでは？、と思います。 実はずいぶん昔に国際化対応アプリケーションの開発方法を調べたことがあり、そのときにタイムゾーン（時差情報）をどのように取り扱うのか、をまとめたことがあります。おそらく皆様の参考になるのでは、と思いますので、若干手直しして情報共有してみます。10 年以上前の資料なので、画面のスナップショットがまさかの XP や Vista（！）だったりするのはご容赦、なのですが、考え方は特に変わっていないので、今でも普通に通用する内容かなと思います。（もし何か変わっているところがあったら教えていただけると嬉しいです；。）
     
    ちょっと長いスライドなので、夏時間（サマータイム）という観点から要点を抜き出すと、以下の 2 つがポイントです。 ① Windows OS 上では、夏時間はタイムゾーンの変更として取り扱われる (p.10) 夏時間に入る＝別の国のタイムゾーンに移動したのと同じようなこととして扱われます。イメージとしては、日本国内にいながら、時差のある国へ海外旅行に行ったのと同じような取り扱いになる、と考えるとわかりやすいかと思います。（なお、夏時間などのタイムゾーン情報はレジストリ情報として管理されており、Windows Update によりメンテナンスされています。なので本資料ではカバーしていませんが、 .NET Core で作ったアプリを Linux 上で動作させたりする場合にはまた別の注意が必要になってきます。） ② DateTime 型の加減算処理を行う際は、必ず UTC を介して行う (p.35, 36) .NET Framework 上で日付をプログラミングする際、DateTime 型でプログラミングされている方が多いと思いますが、DateTime 型はオフセット値（UTC からの時差）を持つことができません。DateTime 型は、「見た目の数値」をそのまま加減算処理してしまうため、夏時間前後でのオフセット値の変化に対応できません。このため、DateTime 型で加減算処理を行う場合には、必ず UTC を介して計算する必要があります。（ちなみにこの問題に対応するために導入されたのが DateTimeOffset 型です。） アメリカでは国内に主に 4 つのタイムゾーンがある上に夏時間まであるため、プログラミングを行う際にタイムゾーンを考慮したプログラミングを行うのは当然なのですが、日本国内の場合、長らく単一のタイムゾーンしかなかったため、タイムゾーンを考慮した形で設計・実装・テストされているシステムは非常に少ないでしょう。正直なところ、今の状況で夏時間が導入された場合のことを考えると、日本の開発の実情を知る自分としてはかなりぞっとします。（「うちのシステムは夏時間が導入されても大丈夫です！」と言える国内開発者はどれだけいるのだろうかと．．．．；） ＃ ネットを見ていると、システムの時刻変えればいい、みたいに単純化されている人もいるのですが、スタンドアロンで動く時計みたいなものと、システム間で連携することが前提になっているシステムとでは全く違うんですよね；。 ＃ 例えば DB に書かれた時刻や電文に乗っかってくる時刻が JST なのかサマータイムなのかは大問題で、自分のシステムがちゃんとサマータイム対応していたとしても、相手先のシステムから 1 or 2 時間ずれた時刻が送られてきた瞬間に業務矛盾を起こすケースとか、そういうぞっとするケースが考えられまくるんですよね。 ＃ 本来はこういう問題を避けるために、すべて UTC ベースで処理するのが基本なんですが、ひと昔前のシステムだと UTC で時刻を扱っているケースなんてほとんどないのではないかと思うのですが；（もしかしたら今でもそういうシステムが多数なのかも；）。 2020 年に併せた夏時間の導入はあまりにも無茶すぎる、とエンジニア的な観点からは思いますが、とはいえこれからの IT エンジニアにとって、タイムゾーンや夏時間（サマータイム）を理解し、国際化対応アプリケーションを作る（海外でも動作するアプリを書く）ことは必須かと思います。この資料が、IT エンジニアのみなさんにとって、タイムゾーンや夏時間（サマータイム）を理解する一助になれば幸いです。]]>         VSTS/TFS Test Manager による手動テスト（打鍵テスト）の効率化 https://docs.microsoft.com/archive/blogs/nakama/testmanager Wed, 20 Jun 2018 10:33:36 GMT https://blogs.msdn.microsoft.com/nakama/?p=4225 image ［打鍵テストの効率化に対する考え方］ 手動での UI 打鍵テストの効率化については、すぐさま「自動化して効率化しよう」という話が出がちですが、自動化による効率化がうまく機能する（高いコストメリットが出る）ためにはテストの繰り返し回数が多いことが必要です。代表的には以下の 2 つのようなケースに当てはまると、自動化が極めて有効に機能します。
    • かなりの構成テストが必要（構成テスト＝異なる OS やデバイス、ブラウザなどで同じテストケースを何度も繰り返すこと。最近だとスマホアプリのような場合が代表的。）
    • 同一の UI や機能に対して長期保守が必要（例えば Windows OS のように一度リリースするとそのバージョンを同じ機能のまま最大 10 年間保守し続けなければならないような場合）
    しかしエンプラ系の業務システムでは、上記のような条件が満たされていないことも多く、また自動化するにしてもテストケースがあまりにも多いために全部を自動化するのが現実的ではないこともよくあります。こうした背景から、エンプラ系業務システムではかなりのテストケース（特に結合テスト以降のテスト）が手作業で行われており、この傾向は今後もあまり変わらないでしょう。 ［ツールによる効率化の必要性］ とはいえ、だからといって Excel を使いまくったテストは非効率的です。一般に打鍵テストは以下の手順で進みますが、特に後半の作業はツールによる効率化を図るべきところです。
    • 網羅的かつ効率的なテストケースを組み立てる
    • 組み立てたテストケースを元に、打鍵でテストを実施する
    • テスト結果を保存するために、手作業でスナップショットを取り、Excel にぺたぺた貼り付ける
    • テスト結果を集計するために、手作業で Excel に実施結果を書き込んでいく
    • バグを報告するために、手作業で Excel を使ってバグ報告を行う
    実はマイクロソフトでは、手動打鍵テストを効率化するためのツール Test Manager を提供しています。それも 2010 年から。リリースから 8 年も経過するのにまるで現場に浸透していないという不遇のツールです。ネットでググってみると、驚くほどヒットしません。日本の開発現場では驚くほど活用できるのに（涙）。 image あるお客様から聞いたところによると、実際、Excel で実施していたテストをこの Test Manager （リッチクライアント版の MTM）に置き換えたところ、テスト工数が従来の約 1/3 で済んだ、という劇的な効果が出たそうです。1/3 は極端にしても、おそらく 1/2 ぐらいにはなると思いますので、このツールを活用しない手はないでしょう。 このツールでどんなことができるのかについては、実際に動いているところを見るのが手っ取り早いです。先日の de:code 2018 ではまさにこのデモを原田さんに実施していただきました。こちらの動画の 14:25 からを見てみていただけるとよいと思います。（25 分間ぐらいのデモですが、見れば一発でわかります） が、どうしてもビデオ見てる暇がない！ というか電車の中とかなので見れない！ という方のために、要点をざっくり整理すると共に、いくつか補足情報を記載しておきます。 ［Test Manager のツール概要］ Test Manager は、テストケースやテスト結果データを保存するためのサーバと、打鍵テスト中に各種のデータを収集するためのクライアントから構成されます。
    • サーバ側 VSTS （クラウドサービス）または TFS （オンプレミス）を利用します。インターネット接続などに制約がなければ VSTS を利用するのが手軽（サーバのセットアップや維持管理が不要なため）です。なお、この手動テスト支援機能はオプション機能であるため、マーケットプレイスからアドオンをインストールする必要があります。
    • クライアント側 ブラウザプラグイン版である Test & Feedback Client と、リッチクライアント版である MTM (Microsoft Test Manager) の 2 種類があります。モダンブラウザ（Chrome や Firefox）で Web アプリをテストする場合には前者を、WinForms や WPF、IE11 でのテストを行う場合は後者を利用してください。ブラウザプラグインはこちらから入手できます。
    今回のデモでは、VSTS + Test & Feedback Client （ブラウザプラグイン）の組み合わせを使って、Java で作られた Web アプリに対する打鍵テストを行っています。デモや下記の説明を見ていただくとわかりますが、このツールは Web アプリが .NET で作られていなくても利用できます。 また、TFS や VSTS はソースコード管理やビルド・リリース管理などを行うツールですが、Test Manager は単体で利用することができます。つまり、TFS/VSTS でソースコード管理などを行っていなくても Test Manager による打鍵テスト効率化を行うことができます。 ［Test Manager でできること］ Test Manager でできることは主に以下の通りです。
    • テストケース一覧の管理（Excel からの貼り付けもできます）
    • 構成パターンの管理（Chrome, Firefox などで別々にテストする際、テスト結果を分けて取り扱えます）
    • テスト中のログ保存（ビデオによる録画や打鍵ログが取得できます）
    • バグ報告との連動（取得したログを添付する形でバグ報告を簡単に出せます）
    • テスト結果やバグの集計（テストの実施結果をグラフで集計するダッシュボードを簡単に作れます）
    以下にそれぞれの概要を解説します。 ［テストケース一覧の管理］ 良いテストを行うには、網羅的かつ効率的なテストケースを組み立てることがまず必要ですが、この部分はツールでどうこうできるものではなく、やはり従来通り、頭を使って考える必要があります（具体的なテクニックは拙著で解説）。テストケースの組み立てはかなりの試行錯誤が必要になるため、通常は Excel を使って行います。ここは今まで通りで OK。 image しかしどんなに Excel 大好きでも、Excel を使うのはここまでにしましょう。このテストケース一覧は、Test Manager に貼り付けて（＝Test Manager に取り込んで）使います。 image image この作業に関していくつか Tips です（概要だけ知りたい方は読み飛ばして OK です）。
    • 一般的に業務システム開発でのテストでは、テストケース数が膨大になるため、各テストケースについての打鍵手順（操作手順や確認手順）を細かく書かないことが多いです。しかし、細かい作業手順書がある場合には、これも Test Manager に取り込むことが可能です（これをテスト手順（Test Steps）と呼びます）。詳細はビデオで解説されていますので、そちらをご覧ください。
    • テストケースを取り込む際には、① テスト計画と、② テストスイート（フォルダ）の 2 つを作る必要があります。通常、テスト計画はリリース単位（v1 リリース用とか v2 リリース用とか）、テストスイートは業務単位や要件単位に作ります。なお、後でのデータ集計を見やすくするため、テストスイートの階層数を揃えておき、番号をつけておくのがオススメです。
    • テストケースの取り込みは UI 上からコピペする方法以外に、WIT に Excel から VSTS/TFS につないでインポートする方法もあります。後者の方法を使うと、優先度やエリア情報などもまとめてインポートできるので、慣れてきたらこちらがオススメです。
    ［構成パターンの管理］ もし同じテストを Windows 7, 10、あるいは Chrome と FireFox など複数の構成パターンで実施する場合には、テストケースを重複登録するのではなく、構成パターンを定義してください。構成パターンを定義した上で、各テストケースに対してどの構成パターンで実施するのかを指定すると、一つのテストケースが複数のテストに分かれます。 vlcsnap-2018-06-20-10h12m21s673 vlcsnap-2018-06-20-10h12m36s120 この作業に関していくつか Tips です（概要だけ知りたい方は読み飛ばして OK です）。
    • 構成パターンを割り当てるとひとつのテストケースが複数に分裂しますが、Test Manager ではこの分裂したひとつひとつのことを “Test Point” （または単純に “Test”）と呼んでいます。テストケース×構成パターン＝テストポイント（テスト実施点）、と理解するとよいでしょう。このことからわかるように、Test Manager の UI 上に表示されているのは、テストケースではなくテストポイントです。
    • 各テストを実施する人（打鍵する人＝Tester）が決まっている場合には、”Assign Tester” により割り当てておくとよいです。ただし、実際には割り当てられていない人がそのテストをやっちゃうことも可能です。なので、このテスター割り当て機能は「誰がやるのかをわかりやすくしておく」だけのための機能です。
    • Test Manager では、各テストポイントを打鍵する “Tester” と、各テストケースを作成・管理する “担当者” とが別々に管理されます。Test Manager の UI 上に表示されるテストポイント一覧に表示されているのは前者、テストケースを開いたときに出てくる担当者は後者であることに注意してください。（テストケースを作った人が打鍵作業をするとは限りません）
    ［テスト中のログ保存］ テストの準備が整ったら、実施したいテストを選択して実行ボタンを押します。すると、ブラウザがプラグインによりテスト実行モードに切り替わります。テスト実行モードでは、各種のログを取得しながらテストの打鍵作業を行うことができます。 vlcsnap-2018-06-20-10h14m33s829 取得できる代表的なログは以下の 2 つです。
    • ① ビデオ録画 画面全体の録画を保存できます。記録としては最強ですが、データ量が多くなることと、後から確認するのが大変なのがデメリットです。
    • ② アクションログ（打鍵ログ） 実施した打鍵内容が一覧の形で保存されます。多くの場合、従来 Excel にぺたぺたとスナップショットを貼り付け保存していた内容はこのログで代替できます。（下の画面で文字化けを起こしているのはエンコード設定の影響です；）
    vlcsnap-2018-06-20-10h16m16s425 これ以外にも、手作業でスクリーンショットを保存したり、コメントを残したりすることができます。これらはテストの実施結果として、VSTS/TFS に保存されていきます。 vlcsnap-2018-06-20-10h15m31s259 この作業に関していくつか Tips です（概要だけ知りたい方は読み飛ばして OK です）。
    • アクションログに関しては、ブラウザプラグイン版とデスクトップ版で取得内容が異なります。後者の場合は画像付きではなく、完全なテキストログとしての保存になります。（が、多くの場合はこのテキストログだけでも十分で、これとビデオログの二つがあれば画像付きアクションログがなくても事足りるでしょう。）
    • アクションログの取得に関しては、クライアント側のツールとアプリの開発技術によって取れる／取れないが変化します。例えば MTM を使う場合、WinForms はアクションログが取れますが、Java Swing アプリはアクションログが（技術的な理由により）取れません。詳細はこちらを確認してください。
    ［バグ報告との連動］ テスト実施中にバグと思わしき内容が見つかった場合には、バグ報告を上げることができます。このバグ報告には前述のログを添付できるため、バグピンポンを防止することができます。 vlcsnap-2018-06-20-10h18m11s055 この作業に関していくつか Tips です（概要だけ知りたい方は読み飛ばして OK です）。
    • （参考）バグピンポンとは… テストチームから報告されたバグが、開発チーム側でうまく再現せず、テストチームと開発チームとの間で押し問答が起こる（バグ票が行ったり来たりする）こと。バグが再現せず（No Repro 問題と呼ばれます）、バグピンポンが発生する大きな原因の一つに、「テストチームがバグを見つけるまでの手順や発生状況が正しく記録されていない」（バグ報告書に書かれている再現手順が正しくない）ことがあります。この問題は、ビデオログやアクションログを活用すると激減させることができます。
    • バグ報告の作成には 2 通りあり、テスト実施中にすぐさまバグ報告を上げる方法と、テストの打鍵を一通り終えた後にバグ報告を作成する方法があります（上のスナップショットは後者の方法）。一般的に現場では前者の方法が（ラクなので）好まれることも多いのですが、本来は後者のやり方が正しいです。（バグ報告が重複していることもありますし、バグの再現手順をきちんと確立してからバグ報告を行うのが正しいため）
    ［テスト結果やバグの集計］ テスト結果やバグについては、簡単に集計グラフを作成したり、それらを元にしたダッシュボードを作成することができます（この作り方はビデオ見た方が早いです、33:30 あたりから）。下記のようなダッシュボードであれば、5～10 分ぐらいでさくっと作れます。 vlcsnap-2018-06-20-10h20m36s982 vlcsnap-2018-06-20-10h22m23s690 この作業に関していくつか Tips です（概要だけ知りたい方は読み飛ばして OK です）。
    • ダッシュボードに追加する Widget で似たようなものがいろいろありますが、テスト結果の集計には “Chart for Test Plans” を利用します。このウィジェットには二つの機能があり、テスト計画（テストケース）を集計する機能と、テスト結果を集計する機能があります。前者はわざわざ集計しなくてもよいことが多いでしょうから、後者をメインで利用します。
    • バグの集計に関しては、”Chart for Test Plans” ではなく “Query Results”, “Query Title”, “Chart for Work Items” などを利用します。これは、バグ情報が内部的には作業項目管理（WIT, Work Item Tracking）と呼ばれる仕組みで管理されている（テスト結果とは別に管理されている）ためです。
    • ダッシュボードなどの UI ではなく、生データを引き抜いて Excel や Power BI などで独自レポートを作ることは結構大変です。詳細レポートを PDF レポートとして引き抜くことはできるようになっているため、まずはこれを活用していただくことをお薦めします。ちなみに生データを使ったレポート作成が大変な理由は、そもそも TFS/VSTS 内でのテスト結果データの構造がかなり複雑（テストケース／テストポイント／テスト実施などのデータ構造を正しく理解しないといけない）なことが最大の理由です。データ引き抜き自体は API 経由でできますので、どうしても、という方は頑張ってみてください。:-)
    • 各テストのテスト結果は、Test Manager の UI 上から簡単に変更ができます（ボタンを押すだけで簡単に結果が変更できてしまう）が、この変更機能は主にリグレッションテストなどのためにテスト結果をリセットしたい場合に利用するものです。担当者が勝手に変更したかどうかは、前述の詳細レポートを出力してみて、テストに要した時間を確認してみるとわかります。（テストに要した時間が 00:00 だった場合には、UI 上からテスト結果を変更している）
    ［Test Manager 活用に関して知っておくとよいこと］ Test Manager の活用に関して、いくつか重要な点を補足します。 ① テストそのものの効率化について Excel まみれのテストを行っている場合、Test Manager を導入するだけでもかなりの改善効果が期待できますが、さらに抜本的な改善をするためには、テストのやり方そのものの見直し・改善が必要です。特に日本のエンプラ系 SI 開発現場では、以下のような問題がよく見受けられます。
    • SIer と協力会社とで、やっているテストの内容に重複がある
    • 協力会社からテストケース一覧を出してもらうものの、SIer の方で適切にレビューができない（＝テストケース漏れでバグがすり抜ける）
    • そもそも単体テストの内容が不十分で、SIer に協力会社から納品されるアプリにかなりのバグが残っている
    これらの問題は Test Manager などのツールの導入で解決できるものではなく、テストの考え方ややり方に対する抜本的な見直しが必要です。本エントリの範疇を超えるためここでは深掘りしませんが、本内容については拙著の第 3 章にて、テストケースの設計テクニックやツール活用方法まで含めて詳細に解説しています。こちらの情報をぜひ読んでみてください。 ② ツールの費用について Test Manager は無償ツールではなく、一人ひと月あたり $52 （日本円で \6000 弱程度）の費用がかかります（VS Ent や Test Pro のライセンスを持っている場合には無償）。また、VSTS を利用する場合、5 ユーザまでは無償ですがそれ以上になると一人ひと月あたり \500～\1000 程度の費用がかかります。この価格に関して高い！ という方がいらっしゃるのですが；、個人的には、Excel で手作業でスナップショットを貼り付ける作業のために人件費をどれだけ垂れ流しているのかと考えたら激安なんじゃないかと思うのですが……どうでしょうか。っつーかテスト工数が 1/3 になった、なんていう事例もあるぐらいなので、どう考えてもツール費用なんて激安だと思うんですが；。 確かに、大人の事情で人件費は聖域だけどツール費用は一文たりとも払えないんです、というケースもあると思います。そのような場合にはせめてステップ記録ツールを使ってください。このツールは Windows OS の標準ツール（7 以降で搭載）で、アクションログのようなログデータを簡単に作れます。残念ながら集計作業やバグ報告との連携はありませんが、少なくとも Excel にスナップショットぺたぺた貼り付けるよりは圧倒的によいと思います。 なお誤解されやすいのですが、Test Manager で利用するブラウザプラグイン（Test & Feedback プラグイン）そのものは無償です。しかしこのプラグインだけだとテストケースとの連動ができないため、実態として使い物になりません。このため、Test Manager との組み合わせが必須となります。 ③ 実際に試用してみたい方へ とりあえず使ってみたい！ という方は、30 日 Trial を使ってみることをオススメします。ざっくりした試用開始の手順は以下の通りです。
    • www.visualstudio.com へ行き、VSTS のアカウントを新規作成する。
    • 新規にチームプロジェクトを作成する。（一つの VSTS アカウント内に複数の開発プロジェクトを作れます。開発方法論はなんでも OK ですが、特にこだわりがなければ Agile か Scrum を指定。）
    • マーケットプレイスから Test Manager を取得する。（先に作成した VSTS アカウントへインストールする形になります。30 日間は無償。）
    • ブラウザに Test & Feedback プラグインをインストールする。（Chrome または Firefox を利用してください。）
    あとは、前掲の de:code のビデオを見ながら試してみてください。 ［まとめ］ de:code 2018 では、打鍵テストを取り上げてツールを使った効率化についてお話をさせていただきました。TFS/VSTS の Test Manager 機能を使っていただくと以下のようなことが可能になり、Excel ベースの打鍵テスト作業を大幅に効率化・近代化できるはずです。
      • テストケース一覧の管理（Excel からの貼り付けもできます）
      • 構成パターンの管理（Chrome, FireFox などで別々にテストする際、テスト結果を分けて取り扱えます）
      • テスト中のログ保存（ビデオによる録画や打鍵ログが取得できます）
      • バグ報告との連動（取得したログを添付する形でバグ報告を簡単に出せます）
      • テスト結果やバグの集計（テストの実施結果をグラフで集計するダッシュボードを簡単に作れます）
    Test Manager に限らず、VSTS/TFS には様々な便利な機能が搭載されています。ぜひこちらの blog などを参考にして、VSTS/TFS を活用していただければと思います。]]>         業務システム開発 モダナイゼーションガイド https://docs.microsoft.com/archive/blogs/nakama/si-modernization Thu, 15 Feb 2018 12:43:00 GMT https://blogs.msdn.microsoft.com/nakama/?p=3916 image 正式タイトルは「業務システム開発 モダナイゼーションガイド～非効率な日本のSIを変革する実践的ベストプラクティス～」。今回の書籍のテーマは、日本の SIer の旧態依然とした Excel まみれの業務システム開発の手法を近代化（モダナイゼーション）して生産性を高めようというもので、以前、弊社のイベント de:code で大変反響のあった「拝啓『変わらない開発現場』を嘆く皆様へ」のフルセット版のようなものになります。タイトルだけでは書籍の内容がさっぱりわからん！ という方が多いのではないかということもあり、こちらに本書のまえがき全文を掲載したいと思います。ご興味のある方は、ぜひ本屋でお手に取っていただければ嬉しいです。（日経 BP さんのサイトでの紹介はこちらです。社内エンジニアの育成テキストなどとしてもご活用いただけると思いますので、もしバルク購入したいというご要望がありましたら、こちらのお問い合わせフォームから日経 BP さんにご連絡ください。） ＃ ちなみにどうでもいいつぶやきですが、個人での印税受け取りは放棄しているため、「儲けた印税で飲みに連れていってください！」的なリクエストはなしで ＆ ワリカンでお願いします；。 本書の執筆にあたっては、日経 BP さんをはじめ、社内外のたくさんの皆様からご協力をいただきました。改めてこの場を借りてお礼申し上げます。ありがとうございましたm(_ _)m。また、イイネ！ ダメダネ！ とか、この本いいよ！ ここ間違ってるよ！ ここはもっといいやり方あるよ！ とかありましたら、Facebook/Twitter/この記事のコメント/はてブなどで反応いただけるとめちゃめちゃ嬉しい ＆ 励みになります。 私の SI 業界での 20 年間の経験の集大成として執筆しました。情報密度がかなり高い本になっていますので、社内勉強会でみんなで検討しながら読むなど、ぜひ周りの方とも情報共有しながら現場でご活用いただければと思います。この書籍が、皆さまの開発現場を少しでも改善するきっかけになること、そしてこの本を踏み台にして、よりよいシステム開発方法論が建設的に議論されていくことを心から願っています。では、以下、まえがきです。
    業務システム開発 モダナイゼーションガイド～非効率な日本のSIを変革する実践的ベストプラクティス～ まえがきより
    ■ はじめに ～『変わらない開発現場』を嘆く皆様へ～ 「日本の SI ビジネスは崩壊前夜」 「日本の SI はガラパゴス」 「日本の SIer の余命はあと5年」 「ウォータフォールには何のメリットもない」 「日本のエンジニアはイノベーティブじゃない」 ネットや雑誌で毎日のように揶揄される日本のエンプラ系 SI（システムインテグレーション）業界。古くは「現代の 3K（キツい・帰れない・給料が安い）」「デジタル土方」、そして最近では「SI オワコン」「SI 終末論」など、次々と生み出される悲惨なキーワード。これらを見るたびに、心を打ち砕かれている現場エンジニアはかなり多いのではないだろうか。 実際、日本の SI 開発現場は確かにひどい。下図は、数年前にある情報システム子会社の幹部に対して、その会社の実際の現場で発生している問題点を整理・説明するために筆者が作ったものである。ところがこのイラストを他のお客様（SIer や情シス子会社）や弊社内の同僚のコンサルに見せてみると、自社あるいは自分が担当するお客様でも似たような、あるいは全く同様の問題が起こっているという。 image 筆者が SI 業界に身を置くようになって約 20 年になるが、実際、コンサルとして日本の様々な開発現場に行ってみると、判を押したかのように似たような問題にぶち当たる。一定の年次になったというだけで十分な知識もないのに「上級 SE」にさせられたプロパー（正社員）が、コストと時間に追われて場当たり的な作業指示を出し、協力会社だけでなく、指示を出した自分自身も作業効率の悪さに苦しむ。そして前述したような心無い罵倒に打ちひしがれながらも、なまじ当たっている面があるだけに言い返せずますます悶々とする。こんなやり方を続けていたら、確かに日本の SI が崩壊するのも時間の問題である。 無論、SIer や情シス子会社のプロパーや日本の SI に関わるエンジニアとて、明らかに沈むとわかっている沈没船に身を委ねたいわけではない。少しでも現場を改善したい、少しでもプロジェクトがうまくいくようにしたいと、日々もがき苦しみながら努力を続けている人たちの方が圧倒的多数だろう。だがしかし、実際には日々の業務をなんとかこなすのが精いっぱいで、抜本的な業務改善までには手が回らない。ニアショアやオフショアを使うだけではもはやインパクトのあるコストメリットが出せなくなりつつある上に、際限のないコストカットの波により現場の労働力が枯渇していく。そんな過酷な現実の中で、どうやって高い生産性と俊敏性を実現させていくかについて悩んでいる現場エンジニアやマネジメントは非常に多いはずである。 こうした SIer や情シス子会社の日々の悩みに対して、果たしてアジャイルや DevOps といった、欧米流のソリューション（プラクティス）が「そのまま」解決策になるのだろうか？　筆者は、この答えは明らかにノーであると考える。少数精鋭で新しいビジネスを模索し続ける、内製前提の SoE 型システム開発の現場から生まれたソリューション（プラクティス）は、システム化対象となる業務量・業務数の多さから少数精鋭での開発が困難となる、請負前提の SoR 型システム開発の現場に必ずしもそのまま適用できるものではない。 そもそも多くの SIer や情シス子会社が悩んでいるのは、様々な事情や制約によって高スキルのエンジニアだけを揃えられるわけではないという状況下において、いかに互いのスキル（専門性）を補完し、チーム全体・プロジェクト全体のアウトプットを最大化していくかという命題である。契約形態（内製型と請負型）、開発規模、揃えられる人員とスキルセットといった、数々の前提条件が異なる欧米型ソリューションをそのまま持ってきて、SIer や情シス子会社の悩めるプロパーたちに対してマウントポジションで殴り掛かるのは筋違いというものであろう。だが、まるで欧米礼賛とも言えるこうした言説は未だ後を絶たず、特にネット上では噛み合わない議論から、不毛なけなし合いへと発展・炎上する例がしばしば見受けられる。こんな状況がいつまで続けばよいのだろうか。 ■ SI 技術（システムインテグレーション技術）の重要性 本来、技術進化の恩恵は、IT 技術を駆使するシステム業界に属するエンジニアが最も享受できるはずである。にもかかわらず、その恩恵をほとんど受けられていないのは何故か。それは、日本のエンプラ系開発現場では、なんとなく非効率的と感じながらも、数十年前と本質的には大きく変わらないやり方を繰り返し続けているからではないだろうか。 image そしてこの状況を生み出している最大の原因は、日本のエンプラ系 SI の商慣習（多重請負構造）における『上流』の仕事のやり方が、ほとんど進化していないことにあると筆者は考えている。 image Visual Studio や Azure といった開発技術（実装技術、モノ作りの技術）を最終的に触るのは、末端にいる協力会社のエンジニアである。しかし、多重請負構造におけるエンドユーザー企業や IT 部門、SI 関連会社、SIer がこうした開発技術の活用を『妨げる』ようなことをしていては、いつまでたっても開発技術の進化の恩恵を受けることはできない。 当たり前のことだが、モノ作りのやり方が変われば、設計手法やプロマネ手法（いわゆる『SI 技術（システムインテグレーション技術）』）もそれに合わせた見直しが必要になる。近代的な開発技術の進化を理解し、SI技術を進化させ（＝近代化し）、エンドユーザー企業に対してそのメリットを提案していくのは、IT 部門や SI 関連会社、SIer の責務である。IT 部門や SIer が技術のことを知り、正しくプロジェクトを立て付けなければ、いつまでたっても現場は非効率的な Excel 設計書と Excel テストから脱却できないのである。 しかし考えてみると、.NET や Javaなど製品技術を解説する本や、プロマネを対象とした専門書は多数あるが、「SI （システムインテグレーション）」に関する技術的なセオリー全般をバランスよく扱っている書籍が意外に少ない。これには以下のような理由が考えられる。 ① 日本の商慣習を前提としたシステム開発手法が生み出されていない ② そうしたノウハウは（あったとしても）SIer の門外不出となっており情報が流通していない ③ ベンダーから提供される情報は実装技術に特化しすぎている ④ プロマネ向けに書かれた書籍は設計・実装・テスト技術に触れていないものが多い 実際、筆者が実際の開発現場に行くと、「なぜこんな基本中の基本が見落とされているのか？」と思うようなことが少なくないが、逆に「そうしたことを短時間で学べる書籍はないか？」と問われると、なかなかおすすめできる書籍がない。これではいつまでたっても日本のシステム開発の現場はなかなか変わらないだろう。こうした現状を打破していくため、筆者が 20 年間かけて、コンサルティングの現場で培ってきたノウハウとベストプラクティスを、可能な限りお伝えしたいと考えて本書を執筆することにした。 ■ 本書の内容とゴールについて 本書は、日本の SI 業界における多重請負構造を前提条件とした上で、SI（システムインテグレーション）に必要となる基礎知識やノウハウ（SI 技術）を幅広く提供する。これにより、多重請負構造の上流の立場にある IT 部門や SIer のプロパーが、システム開発を正しい方向に導き、開発現場を近代化できるようになることを目指すものである。 ■ 本書の構成について 本書では、以下の 4 つの章を通して、SI 技術に関するノウハウを幅広く提供する。全て通して読んでいただくことが望ましいが、悩んでいるところや興味があるところだけをかいつまんで読んでいただいても構わない。 第 1 章 開発プロセスと V 字型モデル ネットの世界では、「イケてない開発 vs イケてる開発」という文脈で、しばしば「ウォータフォール vs アジャイル」の対立構図が取り上げられる。しかしこうした近視眼的な見方では、システム開発の本質を見失う。そこで第1章では、ウォータフォールとアジャイルの特性の違いを解説すると共に、改めて、システム開発の基本とも言える V 字モデルの重要性について振り返る。そして V 字型モデルの段階的詳細化の最大の問題・課題とも言える「後工程の予測・推定の必要性」について述べ、手戻りを軽減・防止するための基本的な対策方針を説明する。 また、開発プロセスのテーラリングにおいては、SoR 型システム開発と SoE 型システム開発とを正しく分けて考えることが最初の起点となる。これらのシステム開発の特性の違いを解説すると共に、日本の SI がガラパゴスなのではなく、むしろ欧米の SI こそがガラパゴスであることを述べる。これを通して、現在の日本のエンプラ系 SI 業界が行うべきことが、「SoE 型システム開発で生まれた様々なベストプラクティスのエッセンスを、SoR 型システム開発へ還元すること」であることを説明する。 第 2 章 フェーズとロールモデル プロジェクトの成否は、最初の建付け（チーム編成とタスク検討）により大きく左右されるが、実際の開発現場を見ると、チーム編成にしてもタスク検討にしても、基本的なセオリーが守られていないことが少なからずある。よくある問題としては、「専門性（ロール）」を意識しないアサインや、非機能要件に基づく設計プロセスである「方式設計」の漏れ、そして技術力の軽視から来るアーキテクトの不在問題などがある。 そこで第 2 章では、業務システム開発の骨格となる、2つのタスクの流れ（機能要件に基づく流れと非機能要件に基づく流れ）と、5 つのロール（業務 SE、アーキテクト、デベロッパー、テスター、プロマネ）について解説する。そして、チーム編成で特によく見られるいくつかの問題を取り上げ、正しくチーム編成とタスクを建て付けるための基本を説明する。 第 3 章 各タスクの実施の要点 開発生産性の改善には、（当たり前だが）作業の手戻り防止と、ムダな作業の排除が欠かせない。にもかかわらず実際の現場では、Excel での画面設計書をひたすら手でこねくり回して時間を無駄にしたり、実施証跡を取るためにテスト結果のスクリーンショットを Excel にひたすら貼り付けたり、保守されることもなく腐っていく内部設計書を粗製乱造しまくるといったデタラメが横行しているのが実態である。こうしたムリ・ムダ・ムラが改善されない大きな理由のひとつは、「そのタスクがなぜ必要なのか（Why）」「そのタスクでは少なくとも何を検討して何を作る必要があるのか（What）」が十分に議論・理解されていないことである。手戻り防止とムダな作業の排除には、チーム内での根拠のある議論が必要になるが、そのための基礎知識が足りていない場合が非常に多いと考えられる。 そこで第 3 章では、要件定義、外部設計、方式設計、内部設計、実装・単体機能テスト、結合機能テスト、システムテストのそれぞれについて、各タスクの実施の要点を解説する。これにより、「根拠のある作業」「根拠のある SI」を実現できるようにする。この章では、SoE 型開発現場で生まれたベストプラクティスを、SoR 型開発現場に取り込むための多数のTipsを織り込んでいる。この章に書かれた内容をきちんと実践するだけでも、QCD（品質・コスト・期間）はかなり改善できるはずである。 また第 3 章の最後では、近代的なインフラや運用管理の基礎概念についても解説する。優れたシステム開発のための基礎となる「運用環境第一主義（Production First Mindset）」の考え方について触れ、その実現に必要となる近代的なインフラや運用管理の要点を解説する。これらが正しく理解できると、クラウドや DevOps の必要性も、必然的に理解できるはずである。 第 4 章 システム開発現場の近代化に向けて 実際の現場では、「今のやり方を変える必要などない」という、論理的とは言えない部課長の鶴の一声で、現場改善の芽はもちろんのこと、若手社員のやる気まで潰してしまうケースも少なくない。しかし、現場を変えていけるのは現場のエンジニアでしかなく、また彼らを勇気づけ、ルールや仕組みを変えていけるのはマネジメントでしかない。本来、両者は二人三脚が必要であり、そのためには根拠のある議論に基づいた歩み寄りが必要となる。 そこで本書の締めくくりとなる第 4 章では、会社や組織、そして個人が何を意識し、どこを目指していけばよいのかの指針について、筆者の見解を述べる。具体的には、SoR 型システム開発では中堅層のプロマネや業務 SE の再教育、社内アーキテクトの育成、初級エンジニアの設計・実装スキルの底上げ、成果物の品質確保プロセスの作り込みなどが必要であること、また SoE 型システム開発では最新テクノロジの要点の理解、デザイン思考の利用などによるビジネスニーズの深掘り、プロトタイピングによる概念実証を行うための社内 PoC チームなどが必要であることを解説していく。そしてエンジニアやマネジメント個々人がどのような考え方を持って何に取り組むべきかを説明する。 第 4 章は第 1 章から第 3 章を踏まえて読んだ方がより納得感があると思われるが、忙しいマネジメントや上席の方は、この章だけをピックアップして読んでいただいてもよいだろう。 ■ 本書の解説について 筆者はここまで .NET 関連の書籍を 9 冊執筆してきているが、10 冊目となる本書では、.NET や Azure といった実装技術そのものに関する説明はほとんど行わない。“How” ではなく “Why”、すなわちなぜその作業をしなければならないのか？　にフォーカスした解説を行う。理由は以下の通りである。 ・ 具体的なやり方は、その気になって調べればいくらでも情報が見つかる。 ・ なぜそれをする必要があるのか？ を理解すると、自信を持ってシステム開発に取り組める。 SI（システム開発）のそれぞれの作業（タスク）には、意味と根拠が必ずある。一つ一つの作業の「理由」「意味」を正しく理解して、作業のムリ・ムダ・ムラを排除すること、そして「あるべき論」を正しく理解した上で、現実の「制約条件」と組み合わせ、落としどころを探ることで、『根拠のある作業』『根拠のある SI』を実現することができる。 ■ 本書で想定している読者と前提知識について 本書は主に IT 部門や SIer のプロパー（業務 SE、プロマネ、アーキテクトなど）をターゲットとして執筆している。前述したように、発注元になる IT 部門や SIer のプロパーが正しいアプローチを知らないと、システム開発の現場を適切な方向に導くことができず、新しい開発技術の恩恵を受けることができなくなるためである。 また、現場経験年数としては5年以上の方を想定して執筆している。ある程度の現場経験があると、肌感覚として理解できる部分、納得できる部分がたくさん出てくるのではないかと思う。完全な新卒エンジニアでも読めないことはないと思われるが、その場合には、数年後にまた本書を読み返してみていただけると、違った発見があるかもしれない。 逆に、業務 SE、アーキテクト、プロマネなどそれぞれの道の「プロ」からすると、自分の専門領域に関する情報としては物足りない部分があるはずである。本書は特定のロールの「プロ」向けに書いた書籍（例えばプロマネのプロ向けに書いた書籍）ではなく、どのようなロールの人であっても必ず知っておいていただきたい「SI 技術の基礎」をまとめた書籍である。現場経験年数が長い方は、ご自身の専門ロール以外の部分を読んでいただけると幸いである。 ■ 本書の免責事項について 日本人は書籍に対してバイブル的な存在を求める傾向があると感じているが、残念ながらそうした情報は全世界どこを見回してみてもなかなか存在しないのが実情である。そうした中で、筆者の独自研究と現場経験に基づいて、筆者自身が「こうした情報があればよいのに」という希望を形にしたのが本書（およびこの書籍を書くための元ネタとなっている、マイクロソフトのコンサルティングサービスが提供する Visual Studio Workshop）である。 このため、本書には筆者個人の考えや解釈などが多く含まれているが、これはあくまで筆者の個人的見解であり、必ずしもマイクロソフトおよびコンサルティングサービスとしての公式見解というわけではない。この点に関しては、ご容赦いただければと思う。 なお、書籍をいきなり読むのが少しつらい、という方には、以下のサイトにまとめてある各種イベントビデオもご活用いただければと思う。扱っているトピックは限定的だが、本書でどのような話を取り扱っているのかの一端を短時間でご確認いただくことができると思う。 ・ 『変わらない開発現場』シリーズ 情報ポインタ一覧 https://blogs.msdn.microsoft.com/nakama/2017/06/17/sier-modernization/ ■ 本書で利用しているツールや画面スナップショットについて 先に、.NET や Azure といった実装技術そのものに関する説明はほとんど行わないと書いたが、ある程度具体的なツールや手法を示した方が理解しやすいものについては、マイクロソフトの製品やサービスを例にとって説明を行っている。筆者は基本的にマイクロソフト以外の技術に明るくないため、解説はマイクロソフト製品をベースに行っているが、同様のことは（おそらく手間は増えるだろうが）OSS 系ツールや他社製テクノロジであっても実現できるだろう。 また広範な領域の情報を限られた時間で執筆している関係で、すでに紹介しているツールや画面スナップショットが古くなっているものもある。また、Azure や Visual Studio、Visual Studio Team Services（VSTS）はどんどん進化を続けるため、読者の皆様が本書を読むころにはすでに古くなってしまっている可能性が高い。しかし、本書で解説している「SIの基本」はさほど変わらないはずである。実際に現場で「SI の基本」を実践する際には、その時点での最新のツールを調査した上で利用していただきたい。 ■ 本書に関するご意見・ご感想などについて 限られた時間での執筆であることに加え、筆者の経験不足・知識不足により、書き足らずのところや、さらに良い手法が存在するところもあると思う。こうした部分については、ぜひ本書を素材または踏み台として、ネット上や社内勉強会、各種コミュニティなどでオープンに議論していただければと考えている。 本書に関するご意見やご感想などは、以下のメールアドレス宛にお寄せ頂ければ幸いである。今後の執筆内容などに可能な限り反映させ、より分かりやすい、より良いコンテンツを提供していきたいと考えている。 ・ 日経BP社 nsp@nikkeibp.co.jp ■ 最後に 特に、開発方法論に関するネット上での議論は空中戦や宗教論争になりやすく、なかなか地に足の着いた議論になりにくい。本書はその領域に対する「言語化」を試みたものでもある。日本の労働人口の減少と生産性改善の必要性が叫ばれる中で、日本人同士がいがみ合い、けなし合うのはあまりにも不毛だと筆者は考える。開発現場のエンジニアが「SI 技術の基本」について共通認識と共通言語を持ち、「根拠のある議論」に基づいてお互いが学ぶべきところを学び合い、「根拠のある SI」を各自が自信を持って実践できるようになることを心から願っている。そして本書の知見が、皆様の開発現場の改善と近代化に少しでも貢献できたのであれば、望外の幸せである。

    2018年1月 赤間　信幸 日本マイクロソフト株式会社　エンタープライズサービス事業本部 プリンシパルコンサルタント

    ]]>         『変わらない開発現場』シリーズ 情報ポインタ一覧 https://docs.microsoft.com/archive/blogs/nakama/sier-modernization Sat, 17 Jun 2017 02:07:19 GMT https://blogs.msdn.microsoft.com/nakama/?p=3835 昨日ですが、ようやく de:code 2017 で実施したセッション ppt, ビデオが公開されました。先日アップした blog エントリと併せて、昨年の de:code 2016 から始まった『変わらない開発現場』シリーズは一通りこれでやり尽くした形になりますが、ここで改めて、関連する情報ポインタ一覧を整理しておきたいと思います。 現場の方が初めて見る場合には ① de:code 2016 CLT-016 から、マネジメントや上司の方にオススメする場合には ② de:code 2017 DO-08 あるいは ③ からまずご覧いただき、興味に応じて他の情報を見ていただくとよいと思います。社内勉強会などにぜひご活用ください。これらの情報が、皆様の開発現場の改善に少しでもご活用いただけることを願っております。 ※ ご意見・ご感想・F/B・拡散など大歓迎です。Twitter @nakama00、はてブ、あるいはこの blog などでぜひお気軽にコメントなどをお寄せください。
    ① de:code 2016 CLT-016 拝啓『変わらない開発現場』を嘆く皆様へ ～エンプラ系 SI 開発現場の「今」を変えていくために～ ［ビデオ］ https://channel9.msdn.com/Events/de-code/2016/CLT-016 ［ppt］ https://docs.com/decode2016/9106 ［はてブ］ http://b.hatena.ne.jp/entry/s/channel9.msdn.com/Events/de-code/2016/CLT-016 ［主な対象者］ SIer 現場担当者、SIer マネジメント層 ［内容］ 設計・テストに関する実践的な改善方法 このエントリーをはてなブックマークに追加
    ② de:code 2017 DO-08 『変わらない開発現場』を変えていくために ～エンプラ系レガシー SIer のための DevOps 再入門～ ［ビデオ］ https://channel9.msdn.com/Events/de-code/2017/DO08 ［ppt］ https://www.slideshare.net/decode2017/do08-sier-devops ［はてブ］http://b.hatena.ne.jp/entry/s/channel9.msdn.com/Events/de-code/2017/DO08 ［主な対象者］ SIer マネジメント層、SIer 現場担当者 ［内容］ SIer の技術力空洞化問題と近代的プロマネ技術 このエントリーをはてなブックマークに追加
    ③ 拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ ［blog］ https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/ ［はてブ］ http://b.hatena.ne.jp/entry/s/blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/ ［主な対象者］ SIer マネジメント層 ［内容］ SIer のマネジメント層が考えるべき今後に向けた取り組み方 image このエントリーをはてなブックマークに追加
    ④ 続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ ［blog］ https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/ ［はてブ］ http://b.hatena.ne.jp/entry/s/blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/ ［対象者］ SIer マネジメント層、SIer 現場担当者 ［内容］ ウォータフォールとアジャイルの特性の違い、 受発注型 SI ビジネスの中での現実的な Agile・Scrum の活用技術の提言 このエントリーをはてなブックマークに追加
    ⑤ 『変わらない開発現場』を変えていくために。 ［blog］https://blogs.msdn.microsoft.com/nakama/2016/07/03/nextstep/ ［はてブ］ http://b.hatena.ne.jp/entry/s/blogs.msdn.microsoft.com/nakama/2016/07/03/nextstep/ ［対象者］ SIer 現場担当者 ［内容］ 上司の説得方法、現場エンジニアとマネジメントの思考の違い このエントリーをはてなブックマークに追加
    ⑥ TechSummit 2016 DEP-010 進化し続ける OS インフラへの挑戦 ～WaaS 時代のアプリ互換の考え方～ ［ビデオ］ https://www.youtube.com/watch?v=8GAJTT_BJQk ［ppt］ https://docs.com/mstechsummit16/2357 ［内容］ 開発近代化の必要性、 CI/CD、カナリアサーバなどの DevOps プラクティスの実践的デモ
    ⑦ 開発系エンジニアのスキルロードマップ ［blog］ https://blogs.msdn.microsoft.com/nakama/2011/11/24/part-1/ ［はてブ］ http://b.hatena.ne.jp/entry/blogs.msdn.com/b/nakama/archive/2011/11/25/skill-roadmap-part-1.aspx ［対象者］ SIer 現場担当者、SIer マネジメント層 ［内容］ SIer で求められる主なスキルセットと学習ロードマップ image このエントリーをはてなブックマークに追加]]>         拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ https://docs.microsoft.com/archive/blogs/nakama/devmodernization Thu, 25 May 2017 07:33:00 GMT https://blogs.msdn.microsoft.com/nakama/?p=3765 image 　昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。 　こうした背景があり、de:code 2017 ではセッションを担当すると同時に、参加者全員に配布するマーケティングのリーフレットを使って、筆者赤間の所属するマイクロソフト エンタープライズサービス（有償サービス部門）での最近のコンサルティングの取り組みをいくつかご紹介するという試みをしてみました。マーケティング部門の費用を使っている関係で、弊社サービス部門の営業色が入った内容にはなってしまっているのですが、その一方で、この情報は（特にエンプラ系 SIer やエンド IT 部門、IT 子会社のマネジメント層の方々にとって）組織やチームをどういった方向に導いていけばよいのかの指針になる、とも考えています。実際、いくつかのお客様でこの取り組みを私からご紹介したのですが、自組織の今後の方向性を整理する上で非常に参考になった、という F/B が多かったです。 　個々の皆様の事情はそれぞれ違えど、多少でも参考になる部分があればと思い、blog 化してこちらのサイトにも掲載することにしました（基本的な骨子はリーフレットと同じですが、ページ数の関係で書ききれなかったことを加筆修正しています）。よろしければぜひご覧いただければ幸いです。
    ■ エンプラ系 業務システム開発を俯瞰する 　クラウドに代表される昨今の技術革新は、業務システム開発の在り方に大きな影響を与えてきました。インフラ、アプリ、運用などの領域に分けてみると、以下のような変化が起きています。 image 　これらの中でも特に重要なのが、「アプリ特性に応じた開発のやり方をする」という考え方です。様々な分類方法が提唱されているのですが、ここではシンプルでわかりやすい、SoE（System of Engagement / お客様との絆を強めるためのシステム）、SoR （System of Record / 事実を記録していくためのシステム）という分類を取り上げてみます。SoE 型システムとは「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステムで、代表例としてはコンシューマ向け Web サイトやゲームアプリ。一方、SoR 型システムとは「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった作成を持つシステムで、代表例としては金融系勘定システムのようなものが挙げられます。 image 　並べてみると明らかなように、これらはシステム開発としての基本的な特性が大きく異なります。例えば SoE 型システムはページ数や業務数は少なめですが、かわりに極めて先進的な技術が投入されます。一方、SoR 型システムは、一つ一つのロジックはさほど難しくないものの膨大な数の業務が存在し、品質の安定性重視のために枯れた技術が好まれる傾向にあります。 　また、開発特性が異なれば、求められる開発文化も当然異なります。例えば SoE 型システムでは「素早くリリースして素早く軌道修正していく」という Try & Error の文化が重視されますし、SoR 型システムでは「大規模システムを早く・安く・上手く作るためにいかにプロジェクトやメンバーを制御するのか」といった点が重視されます。 　もちろん実際の個々のシステムはここまで両極端ではないでしょうが、この分類に従って考えてみると、いろいろ考えやすくなるのも事実です。例えば日本のシステム開発市場に関して考えてみると、
    • いわゆるエンプラ系 SIer での業務システム開発は SoR 型システムが圧倒的多数。（この傾向は今後もおそらく変わらない）
    • アジャイルやDevOps プラクティスは SoE 型システム開発界隈から生まれてきた手法であり、エンプラ系 SIer の SoR 型システム開発には単純適用できないことが多い。
    • 最近ではお客様が新規性の高いビジネスを模索していることも多く、エンプラ系 SIer といえど SoE 型システムの開発に取り組まねばならないことが多くなってきている。
    といった実情があるのですが、こうした状況が整理されないまま、DevOps やアジャイルは日本に定着するのか？ 的な議論が数多くなされています。こうしたことが、日本の開発現場の改善に向けた建設的な議論が進みにくいことの一因ではないかと私は考えています。 　また加えて言うのであれば、私は日本と欧米とでは随分と状況が異なると考えています。
    • 例えば、「欧米では Scrum が基本で DevOps が当たり前」と言われるが、そもそも欧米で 2000 年代にオフショア化が非常に進んだことを考えると、欧米の国内に残った「高付加価値 SI」は、必然的に内製でも成立するような（内製でないと成立しないような） SoE 型のような先進性を求めたものになる。よって、そこでアジャイルや DevOps などのプラクティスが進化・発展するのはある意味当たり前。
    • その一方、日本は世界中でも言語障壁が特に高い国であり、欧米のように大規模 SoR 型システム開発をうまくオフショアできていないのが実態。結果として、国内には Web サービス系企業やゲーム業界のように積極的に DevOps プラクティスを活用する企業と、確実性をなにより重視し、膨大なドキュメントに基づく大規模な SoR 型システム開発を実施するエンプラ系 SIer 企業とがごった煮で共存している形となっている。
    　よく、「システム開発に関して日本はガラパゴスだ」と言われるのですが、むしろこれは逆で、実際には欧米（特にアメリカ）のシステム開発の方がある意味よっぽどガラパゴスなのではないかと思うのです。というのも、アメリカにおけるオフショア先であるインドや中国などにおいて大規模開発が行われる場合は当然受託開発であり、そこではやはりウォーターフォール的な開発文化が強いらしく（私の見聞きしている範囲なのでバイアスはあるかもしれませんが）、その部分に関しては、日本の SIer とあまり状況は変わらないように見えるのです。……と考えると、おそらく日本のシステム開発の市場というのは、簡単に言えば「世界の縮図」ではないかと思うのです。 　しかしここで勘違いして欲しくないのは、仮に欧米のシステム開発がガラパゴス化していたとしても、そこからエンプラ系 SIer の SoR 型システム開発が学ぶべきこと・学べることはたくさんある、という点です。「ガラパゴス化」というのはあまりいい意味で使われない言葉ですが、最先端を突っ走ることによって多数の様々なプラクティス（実践的手法）が生み出されていることも事実であり、こうした内容は開発文化の違いを意識ししつつ（＝きちんと取捨選択しながら）積極的に取り入れていく必要があります。 image 　こうした背景を元にすると、私を含めた、エンプラ系 SI 界隈に携わる人々が取り組まなければならない課題は主に以下の 2 つであると考えています。
    • ① SoR 型システム開発における、更なる開発生産性の改善
    • ② 先進的ビジネスのための SoE 型システム開発への取り組み
    　以降では、これらに関する私の考えと、マイクロソフト エンタープライズサービスによるコンサルティングの取り組みや事例をご紹介していきます。
    ■ ① SoR 型システム開発における開発生産性の改善 ～開発近代化コンサルティングサービス～ 　開発技術の進化があれば、その恩恵により開発生産性は改善されるはずです。……にもかかわらず、実際のエンプラ系システム開発現場ではその進化の恩恵を受けられていないことが多いのではないでしょうか？　これには様々な理由があると思いますが、中でも大きな理由のひとつとして、日本の SI 商慣習（多重請負構造）における『上流』の仕事のやり方が、10 年以上も変化していない（ような現場が多い）ことが挙げられると私は考えています。 image 　当たり前のことですが、モノづくりのやり方が変われば、設計手法やプロマネ手法もそれに合わせた見直しが必要になります。この点は、私が昨年・今年と de:code で一貫して取り上げてきたテーマで、実践論として具体的なレベルまで踏み込んで解説しています（仔細は以下の ppt やビデオをご覧ください）。
    • de:code 2016 CLT-016 拝啓『変わらない開発現場』を嘆く皆様へ ～エンプラ系 SI 開発現場の「今」を変えていくために～ https://channel9.msdn.com/Events/de-code/2016/CLT-016 https://docs.com/decode2016/9106
    • de:code 2017 DO-08 『変わらない開発現場』を変えていくために ～エンプラ系レガシー SIer のための DevOps 再入門～ （ppt, ビデオは後日公開予定）
    　しかし上記のセッションで説明されているような「ベストプラクティス」がすでに存在するにもかかわらず、 Excel 設計書に代表されるように、日本の開発現場は昔ながらのやり方を淡々と続けていることが少なくありません。実際の開発現場を数多く訪問している私の肌感覚ですが、その最大の理由は、IT 部門や SI 関連会社、あるいは SIer のプロパーが、最新の開発技術やモノづくりのやり方を単に「知らない」、そしてその結果、それに併せた最適な SI のやり方を考えられなかったり、改善の打ち手を考えられなかったりすることが多いためだと考えています。 　これは、SIer のプロパーが怠けている、ということではありません。いやむしろ、SIer のプロパーさんほど身を粉にして働いている方々はいないでしょう。にもかかわらずなぜこのような状況が発生するのか？　その原因の一つに、私は IT 部門や SIer における過度な外注やアウトソーシングがあると考えています。 image 　上図に示したのはシステム開発の業務遂行に必要な「5 つの専門性」です（仔細はこちらのエントリを参照）。こうした役割を、SIer のプロパーさんと、協力会社の方々によって分担していくわけですが、このアウトソースの仕方に問題がある場合が少なくありません。通常、SIer のコアコンピタンス は「プロマネ」「業務」「技術」の 3 つですが、 行き過ぎたアウトソースや協力会社への依存により、 社内にアーキテクトがいなくなっているケースが非常に多いです。その結果、現場あるあるとして以下のようなことが起こります。……というよりホントにこんな現場ばっかです；（涙）。
    • プロマネや業務 SE に対して 技術的視点から下支えする人材がおらず、技術的に正しい開発方針を取れていない。
    • ベンダーや協力会社に対して不適切な指示を出してしまう。
    • 技術がわからないので協力会社の成果物を全くレビューできない。
    • 意味のない・効果の薄いドキュメントや報告書を大量に作らせてしまったりしている。
    　このアーキテクト不在問題は SoR 型システム開発の改善を考えていく上で極めて根深い問題です。これについては、de:code 2017 DO-08 セッションにて詳細に取り扱っているのでご確認いただければと思うのですが、こうした状況を改善していくための基本的な手立ては以下の 2 つです。
    • 現在のプロマネや業務 SE の使っている、10 年前から進化していない SI 方法論を、近代的なものにリニューアルしていく。
    • 社内に技術がわかるアーキテクトを育てて保有していく。
    　これらに関するマイクロソフト エンタープライズサービスの取り組みを私は「開発近代化サービス」と銘打っているのですが、具体的には以下のようなコンサルティングをお客様向けに実施しています。
    • A. 中堅層のプロマネ・業務 SE の再教育プログラム
    • B. アーキテクト育成プログラム
    　以下に順に解説します。 ［A. 中堅層のプロマネ・業務 SE の再教育プログラム］ 　前述したように、モノづくりのやり方が変われば、設計手法やプロマネ手法もそれに合わせた見直しが必要になります。だからこそ、手持ちの仕事で忙殺されている業務 SE やプロマネの方々を、アーキテクトが技術面から下支えし、近代的な SI を実践していくことが必要なのですが、現状を踏まえると、以下の 2 つの問題があります。
    • そもそもアーキテクトが SIer の中にいない（or 不足している）
    • そもそも SoR 型システム開発における、「近代的な SI 手法」が（世の中的に）十分に整備されていない
    　これらのうち、後者は非常に大きな問題です。先に述べたように、欧米は内製ベースの SoE 型システム開発を前提として、アジャイルや DevOps といった手法・プラクティス群を開発・整備し続けてきました。しかしその一方で、受発注ベースの SoR 型システム開発に関する「近代的な SI 手法」の改善に関しては手つかずで放置されており、全体としてはほとんど進化していません。私見ですが、おそらくこの問題は日本固有の問題ではなくグローバル共通の課題であり、これに対するソリューションは誰かが先陣を切って新しく作っていかなければならない状況である、と思います。そしてその先陣を切れるのは、SoE/SoR 型システム開発が共存する国である日本をおいて他にないだろう、とも考えています。 　なぜかというと、先に述べたように、SoR 型システム開発手法を進化させていく際には、SoE 型システム開発向けとして開発された各種の DevOps 系プラクティス群が参考になります。右から左に導入することはできませんが、本質論を踏まえて取捨選択しながら取り込んだり融合させていくことは十分にできるわけで（具体的な手法は de:code イベントセッションを参照）、こうした「SoR 型システム開発向けの近代的な SI 手法」を、自社の状況に併せて作り上げていくことが、SIer や IT 子会社の多くに求められている、と考えています。そしてこうした「他国／他社のいいところを参考にして、自分たちのやり方を上手に進化させていく」ことは、もともと日本のお家芸、だったのではないでしょうか？ 　幸い、私はマイクロソフトというグローバル企業に所属しており本社の R&D 部門の手法の話やDevOps 系プラクティスについて聞く機会が多いこと、また日本のいわゆるエンプラ系システム開発現場に向けたコンサルティングサービスを 15 年以上手掛けていること、そしてこの領域をなんとかしたいという思いがあり、日本独自のソリューションとして開発近代化サービスを開発し、展開しています。具体的には、主に現場経験 10 年程度のプロマネ・業務 SE を対象として、V 字型モデル開発の基本を、現在の開発技術やトレンドに沿った実践的手法と共に学び直す、という再教育プログラムを開発・デリバリしています（実は de:code の昨年・今年の私のセッションは、この再教育プログラムからごく一部を切り出したものです）。 image 　内容としては、開発プロセス、チーム編成、外部設計、内部設計、ソフトウェアテストなどについて、日本の現状や欧米でのベストプラクティス、また日本の様々な現場に見られる課題の解決のヒントなどをひたすら紹介していく、というものになっています。実装方法を解説するものではないので、コードはほとんど出てこず、それ故に特にマイクロソフト技術に縛られる内容にもなっていません。実際の開発現場において「なぜそれをしなければならないのか」というところに踏み込むことで、プロマネ・業務 SE として外してはならない要点、SI において『幹』となる考え方やタスクをきちんと理解・習得していただくことを目的としています。 　また、こちらは単発トレーニングとして実施することも多いのですが、より踏み込んだお客様では、この内容を元に実際のお客様プロジェクトにおける設計・テストドキュメントの改善レビューを行い、より一層深い理解・改善をしていただいていることもあります。 ［B. アーキテクト育成プログラム］ 　もう 1 つは、そもそもの問題の根幹であるアーキテクト不足を解消するために、社内アーキテクトを育成していくプログラムです。アーキテクト育成のための設計・実装技術のスキルトランスファーといった昔ながらのサービスも手掛けていますが、アーキテクトとしての重要スキルの一つであるコンサルテーションスキルについても OJT での育成サービスを行っています。 　もう少し具体的に書くと、SIer や IT 子会社におけるアーキテクトは非常に貴重な人材であるため、共通部門（CoE, Center of Excellence）に集約され、下図のような様々なミッションを担っていることがよくあります。こうした人材はアーキテクトとしての活動を通して、究極的には現場向けの社内コンサルタントになっていくことが望ましいのですが、一朝一夕にコンサルタントとしての立ち振る舞いができるようになるわけでもありません。そこで弊社コンサルタントが『お手本』となって、ガイドラインの作成支援や実際の現場プロジェクト支援などに参画し、メンバーを育てていくといったこともしています。 image
    ■ ② 先進的ビジネスのための SoE 型開発への取り組み ～PoC ラボによるアイディアの早期具現化～ 　さてここまで述べてきたように、SoR 型システム開発の改善は、従来のやり方の延長線で考えていくことが可能です。しかし SoE 型システム開発への取り組みに関しては、全く異なる発想とアプローチが必要になります。これについて、ビジネス的な背景も含めて少し掘り下げます。 　ご存じのように、昨今の IT（デジタル）は人々の生活（アナログ）をあらゆる面で支え、よりよいものにしています。このような変化は「デジタル変革」（デジタルトランスフォーメーション）と呼ばれていますが、このデジタル変革は極めて急激に進むという特徴を持っています。具体的に言うと、ひと昔前であれば Facebook や Google、そして最近であれば Uber や Airbnb などといった、いわゆるスタートアップと呼ばれる企業は、恐るべき速度でサービスを拡大してきました。そして既存企業がその速度についていけず、あっという間に既存ビジネスが破壊されるということが現実のものとなっています。 　この既存ビジネスの破壊において重要なポイントの一つは、そこで使われている技術は必ずしも新しいものではない、という点です。よく語られることですが、例えば 2007 年に発売された iPhone は、当時の既存技術を組み合わせて作られており、iPhone のために何か全く新しい技術が発明されたというわけではありません。この例からわかるように、現代は、すでに多数の「発明」（AI や VR などの革新的技術）が存在しており、それが「ユースケース」（使い方・ニーズ）の発見を待っている、そしてそれを最初に見つけてビジネス化できた人がイノベーションを起こす、という形になっているわけです。 image 　こうした「ニーズ」の発見には Try & Error による試行錯誤が欠かせませんが、昨今はクラウドの登場、デバイスのコモディティ化などによって IT 技術の利用コストが大幅に低減しており、挑戦のためのハードルが昔に比べて圧倒的に下がっています。その結果、数多のスタートアップ企業がリスクをどんどん取って、イノベーションへの挑戦（簡単に言えば「一発当てる」ための挑戦）を繰り返している、という状況が生まれています。米国におけるスタートアップブームの背景にはこうした IT 環境の変化があるわけです（このあたりは馬田さんの良著「逆説のスタートアップ思考」にて詳細に解説されていますので、興味がある方はご一読いただくとよいと思います）。 　上記のような状況を元に考えると、先進的テクノロジを使った新しいビジネスの取り組みに必要なポイントは以下の 3 つであり、マイクロソフト エンタープライズサービスではこれらに対応するサービスをそれぞれ展開しています。 image 　以下に順に解説します。 ［A. 最新テクノロジの理解（インベンションの理解）］ 　革新的なサービスを考える際、シーズ（種）となる最新技術を知ることは極めて重要です。特に事業部門のお客様に近ければ近いほど、ビジネスに深い造詣がある一方、最新技術を知らないことが多くなるため、こうした最前線の方々の業務知識と、最新技術とを突き合わせてみることがより重要になってきます。 　とはいえ数多の技術をすべて把握することは非現実的でもあります。こうしたことから、弊社では定着期に入りつつある技術を効率的に把握するための最新技術セミナーを用意しています。このセミナーによって、ビジネスアイディアとマッチングできる最新技術を探っていくわけです。 image ［B. ビジネスニーズの深掘り（ユースケースの模索）］ 　2000 年以降に成人になった若者の方々をミレニアル世代と呼びますが、消費世代に差し掛かってきたミレニアル世代の人々の考え方は、旧世代の人たちとは大きく異なることが知られています。よく言われることとして、デジタルネイティブである、所有欲がない（シェア・利用）、出世よりワークライフバランス、自分が納得したものを消費する、ソーシャルで緩く繋がる、といったことが挙げられますが、こうした価値観の変化にうまく追随できていない既存企業が増えつつあります。 　実はこの問題はミレニアル世代に限った話ではなく、リーマンショック以降の生活様式の変化や人々の価値観の変化といったものに追随できないことで、新しい企業にお客様を奪われていくことがしばしば発生します。その大きな理由の一つとして、「従来型のビジネスを熟知していること」、すなわち過去の成功体験が発想・思考の妨げになることが挙げられます。こうした課題を解決していくためには、なによりお客様を深く理解すること、そしてそこから隠れたビジネスニーズを深掘り・発見していくことが必要になりますが、そのための手法として最近着目されているのが、デザイン思考（Design Thinking）と呼ばれる手法です。 　本論から逸れるため、ここではデザイン思考の詳細に立ち入ることは避けますが、もともとデザイン思考は優秀なデザイナさんによる物事の「思考方法」「考え方」を真似るところからスタートしており、下図に示すような発展の経緯を辿ってビジネスの世界へと入ってきています。このことからもわかるように、デザイン思考そのものは必ずしも IT に限定されるものではないのですが、近年では、こうした「優秀なデザイナさんによる物事の思考方法」を、各業界に特化した形で進化・発展させ、より使いやすい手法（プロセス）としたものが各社から提唱・提供されているようになってきました。 image 　マイクロソフトでもこうした流れを受け、デジタルエンビジョニングワークショップ（DEWS）という手法を開発し、サービスを提供しています。これはお客様への深い洞察を元に、新たなイノベーションを IT 技術との組み合わせにより生み出していくビジネスデザイン手法を体系化したもので、デジタルトランスフォーメーションへの足掛かりとして、現在マイクロソフト エンタープライズサービスよりサービスを提供しています。 image ［C. プロトタイプによる PoC 検証（Try & Error による模索）］ 　さて、最新技術とユーザニーズの掛け合わせから生まれたアイディアは、PoC （Proof of Concept、プロトタイピングによる概念検証）により素早く具現化・検証していくことが必要です。前述したように、今日では IT 実現コストの低減により「まずは試してみる」ことが昔に比べて圧倒的に容易化しています。アイディアを素早く形にして試しいみることで、お客様からの F/B を早期に得ることができ、より優れたアイディアやビジネスに昇華させていくことができるわけです。 　こうしたアイディアの素早い具現化のためには、以下の 2 つが必要不可欠です。
    • 社内 PoC ラボセンターの設置 アイディアの具現化は素早く社内で行うことが必要であり、いちいち請負型でベンダーに発注することは非現実的です。このため、PoC アプリ開発チームは社内に持つ必要があります。（社内アーキテクトは SoR 型システム開発におけるアーキテクトロールだけでなく、こうした取り組みでも活躍してもらう（＝アーキテクトの人たちが先端技術を使って直接プロトタイプを実装していってもらう）ことになります。）
    • 高速開発基盤の整備 Azure などのクラウドをフル活用した開発基盤を整備し、PoC アプリ開発チームが作成したプロトタイプをすぐさま配置してテストできる環境を整えておく必要があります。
    　なおこれらの取り組みは、SoE 型システム開発における PoC 検証はもとより、従来の SoR 型システム開発においても有効性が高いです。なぜなら PoC によるプロトタイピングで十分に UI などの要件を煮詰めたうえでベンダーに発注することにより、見積もりブレや手戻りなどのプロジェクトリスクを極小化することができるためです。 image 　弊社マイクロソフト エンタープライズサービスでは、上に示したような取り組みをしやすくするため、以下のようなサービスを展開しています。
    • PoC ラボセンターの提供 弊社コンサルタントチームが（場合によってはお客様先に常駐して）実際に PoC を回し、高速にお客様アイディアを具現化していく。
    • Azure PaaS 開発基盤の整備 Azure を利用する場合のリファレンスアーキテクチャガイドの整備などを実施する。
    ■ マネジメント層に求められる役割 　さて、ここまでマイクロソフト エンタープライズサービスが手掛けてきているエンプラ系 SIer 向けの取り組みをご紹介してきましたが、こうした取り組みを実際に進める際には、マネジメント層にも重要な役割を担っていただく必要が出てきます。それは、SoR 型システム開発と SoE 型システム開発とを分離し、そこに適切な経営レベルの判断を入れる、という点なのですが、このポイントは非常に重要なため、最後に解説して締めくくっていきたいと思います。 　前述した SoR 型システム開発への取り組みは漸進的アプローチ、すなわち従来の取り組みを改善していくアプローチである、ということができます。一方で、SoE 型システム開発への取り組みは革新的アプローチであり、リスクを取って進めていくべき性格が強いものです。このため、適用対象となるプロジェクトも違えば、個々の社員の向き不向きも異なってきます。もちろんノウハウを交換しあうことは重要ですが、全社一律のルールで管理しようとすると、様々なところに無理が生じます。故に、会社の中で、SoR 型システム開発への取り組みと、SoE 型システム開発への取り組みとをきちんと分けてそれぞれ考えることがまず重要になるわけです。 　また、特に SoE 型システム開発でイノベーションへ取り組む場合には、マネジメント層の『投資判断』が必要になることもしばしば発生します。イノベーションに必要なユースケースの発見には、相当な Try & Error が求められるのですが、実際のスタートアップ企業の打率はかなり低く（例えば 100 社に投資しても 1 社成功するかどうか、しかしその成功する 1 社は 1 万倍のリターンがある、といった具合）、ハイリスク・ハイリターンの博打的な側面があります。こうしたところに企業としての合理的な判断（例えば ROI や短期的なリターンなど）を求めると、イノベーションへの取り組みは必然的に失敗します（これをイノベーションのジレンマと呼びます）。 　こうした問題から最近着目されているのが「バーベル戦略」という考え方です。これは大半のリソースは従来通り安全牌にかけておき、一定のリソースをハイリスク・ハイリターンに賭けてイノベーションを目指す、というものです。先に述べたように、スタートアップ的な領域への投資では一発の大当たりが他のすべての失敗を帳消しにするものの、実際には「全部失敗することもありうる」わけで、余剰体力が残っているうちに、余剰体力で新しいビジネスの芽を見つけるために頑張るわけです。 image 　マネジメントは何かと現場に ROI を求める傾向がありますが、ROI が算出できるのであれば、マネジメントの判断など不要です。原理的に白黒が付けられない投資（リソース投入など）に対して、自らの裁量、そして KKD （勘と経験と度胸）で判断をすることこそがマネジメントの仕事である、私はそう考えています。（← KKD はそういうところで使うべきものだと私は思います） 　本 blog で解説したような取り組みでは、必ず投資モードで行う作業が発生すると思います……が、そうした取り組みをいつ、どの程度、どのような形でやるのか。それを判断しサポートするのはマネジメント層の役割であり、経営判断がどうしても必要な領域になります。マネジメント層の方々には、ぜひ現場メンバーの積極的な姿勢や取り組みをサポートし、会社やチームの活性化につなげていただければと思います。
    ■ まとめ 　本 blog では、私が所属するエンタープライズサービス統括本部のコンサルティングの取り組みのご紹介を通して、『変わらない開発現場』に苦しむ IT 子会社さんや SIer さんの改善の取り組みのヒントになる情報を執筆してみました。要点をまとめると、以下の通りとなります。
    • システム開発の改善を考える場合には、SoE 型システム開発と SoR 型システム開発とに分けて考える。
      • SoE 型システム = 「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステム、コンシューマ向け Web サイトやゲームアプリなど
      • SoR 型システム = 「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった特性を持つシステム、金融系勘定システムなど
      • これら 2 つは開発特性が全く異なるため、分けて考える必要がある
    • 欧米の手法を右から左に導入するのではなく、システム開発特性を意識した上で導入する。
      • アジャイルや DevOps などの手法は、SoE 型システム開発の文化の中で進化・発展してきたもの。
      • 日本国内には SoE 型システム開発と SoR 型システム開発の両方が共存している。このため、SoR 型システム開発へ欧米の手法を導入する際には、各種プラクティスを取捨選択しながら段階的に導入し、現場改善につなげていく必要がある。
    • SoR 型システム開発の改善は、以下の 2 軸で考えていくとよい。
      • 現在のプロマネや業務 SE の使っている、10 年前から変わらない SI 方法論を、近代的な SI 方法論にリニューアルしていく。
      • 社内に技術がわかるアーキテクトを育てて保有していく。
    • SoE 型システム開発の改善は、以下の 3 軸で考えていくとよい。
      • 最新テクノロジの理解（インベンションの理解）
      • ビジネスニーズの深掘り（ユースケースの模索）
      • プロトタイプによる PoC 検証（Try & Error による模索）
    　システム開発現場の悩みは、SIer ごと、開発現場ごとにそれぞれ異なると思います。本エントリの解説を参考にしていただいて、現場改善のための具体的な戦略立案、そして実行へとつなげていただければ幸いです。]]>         Part 7. Windows OS の変更ログの入手方法 https://docs.microsoft.com/archive/blogs/nakama/win10waas-part7 Thu, 18 Aug 2016 00:11:00 GMT https://blogs.msdn.microsoft.com/nakama/?p=3275 ここまでアプリ・インフラ両側面から Windows 10 WaaS 環境への移行についての注意点などを解説してきましたが、最終的にはインフラ／アプリどちらの観点であっても、FU/SU での変更点を把握して検討することが重要になります。
    • インフラ観点 : FU で提供される新機能をどのように取り込むか？
    • アプリ観点 : FU/SU で行われた変更でどのようなデグレードが発生しそうか？
    この Windows OS の変更ログは様々なチャネルを介して提供されており、自分の目的に合ったものを探して利用する必要があります。 ［FU/SU 配信の流れと IP/CB/CBB の関係の再整理］ まず復習として、FU/SU の配信タイミングと、IP/CB/CBB の関係を整理すると、以下のようになります。 image
    • 用語の整理
      • IP : Insider Preview (アーリアダプタ向けに公開される中間ビルド)
      • CB : Current Branch (コンシューマ向けのリリース)
      • CBB : Current Branch for Business (ビジネスユーザ向けのリリース)
      • FU : Feature Upgrade (いわゆる従来のサービスパックに相当)
      • SU : Servicing Update  (いわゆる従来の累積セキュリティパッチに相当)（※ 今後は QU : Quality Update に名称変更の予定）
    • 基本的な流れは、以下のように整理することができます。
      • ① IP リリースごとに、機能追加・変更と、修正（脆弱性・バグ）が行われる
      • ② ①がある程度貯まると、CB として FU がリリースされる
      • ③ FU リリース後は、サポート終了まで修正（脆弱性・バグ）が SU として配信される
    この一連の流れにおいて、我々は以下を整理しておく必要があります。
    • 公式／非公式サイトから、どのタイミングでどのような情報が提供されているのか？
    • 自社での検討のために、どのタイミングでどのような情報が欲しいのか？
    重要なので Part 5-b で解説したことを繰り返しますが、変更情報には、「機能追加・変更」に関する情報と、「修正」に関する情報があり、どのレベルで非互換情報を確認するのかを意識することが非常に大切です。 image 簡単に言えば、以下のようになります。
    • ミッションクリティカルが高い場合には…
      • 機能追加・変更だけでなく、修正情報（パッチ情報）についても確認することになるが…
      • この場合、パッチリリースごとの確認が必要 → 自動化されたテストの繰り返しが必要です。
    • ミッションクリティカル度が中程度の場合には..
      • この場合には、機能追加・変更を中心に確認することになります。
      • よって、FU のリリースのつど（＝CB がリリースされるつど）、機能追加・変更を確認することになります。
    ではおさらいはこの程度にして、実際にどのような場所から機能追加・変更・修正に関する情報を入手できるのかを整理します。 ［代表的な変更ログ情報の提供サイトについて］ 公式／非公式含め、代表的な変更ログ情報サイトには以下のようなものがあります。
    サイト名 スコープ 提供頻度 情報粒度 公式／非公式 言語 注意事項
    Windows 10 ロードマップ OS 全体 FU 概要レベル 公式 日本語あり 全体像を掴むのに便利
    Windows Insider blog OS 全体 IP 機能追加・変更・修正 公式 英語のみ 情報が細かいため整理が必要
    Microsoft Edge Changelog Edge のみ IP/FU 機能追加・変更・修正 公式 英語のみ Edge に特化
    What's new in Windows for developers 主に UWP FU 機能追加・変更 公式 英語のみ ほぼ UWP に特化
    Windows blog for Japan OS 全体 主に FU 機能追加・変更 公式 日本語のみ 重要なトピックに絞って解説
    ChangeWindows.org OS 全体 IP/FU 機能追加・変更 非公式 英語のみ 非公式だが極めて便利
    ASKVG OS 全体 IP/FU 機能追加・変更 非公式 英語のみ  
    Windows 10 リリース情報 OS 全体 SU 修正 公式 日本語あり いわゆる KB 情報
    Windows and Windows Server compatibility cookbook OS 全体 － 機能追加・変更 公式 英語のみ Windows 7～8.1 までの情報
    多分に私見が入りまくりますが；、それぞれのサイトを紹介すると、以下のようになります。 Windows 10 ロードマップ
    • https://www.microsoft.com/ja-jp/WindowsForBusiness/windows-roadmap
    • よいところ
      • 概要レベルで、機能追加・変更の全体像を掴むことができる
      • ユーザの用途（大企業向け／中小企業向けなど）によって情報が整理されている
      • 今後のロードマップも（ある程度）知ることができる
    • 残念なところ
      • 細かい内容はほとんどわからないため、他の資料を確認する必要がある
    • image
    Windows Insider blog
    • https://blogs.windows.com/windowsexperience/tag/windows-10-insider-preview/
    • よいところ
      • マイクロソフトから公式情報として公開されている、機能追加・変更・修正情報
      • 機能追加・変更をほぼ網羅しており、修正情報は代表的なものが取り上げられている
    • 残念なところ
      • プレビュービルド毎に情報公開しているが、機能アップグレード毎に整理されていない
      • このため、アプリ互換性検証で利用しようとすると、FU 間でのすべての IP の情報を自力でまとめ上げなければならない
    • image
    Microsoft Edge Changelog
    • https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/
    • よいところ
      • Edge 開発チームから公式情報として公開されている機能追加・変更・修正情報
      • 機能追加・変更を網羅しており、修正情報は代表的なものが取り上げられている
      • Web 上で、任意のプレビュービルド間や CB 間での差分情報をまとめて表示することが可能（← この機能がよくできています）
    • 残念なところ
      • （当たり前ですが）ブラウザ関連の情報しかないこと
    • image
    What's new in Windows for developers
    • https://msdn.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-1607
    • よいところ
      • マイクロソフトから公開されている開発者向けの機能追加・変更の情報
      • 主に UWP 開発における FU 間でのアプリ開発者向けの機能追加・変更点が整理されている
    • 残念なところ
      • UWP 関連（アプリ開発ランタイム）の情報しか含まれていないこと
      • OS 側の変更点についてはほとんど含まれていないこと
    • image
    Windows blog for Japan
    • https://blogs.windows.com/japan/
    • よいところ
      • 日本固有の情報について提供している公式の Web サイト
      • 日本語で重要な情報が提供される
    • 残念なところ
      • 重要な変更情報の提供にとどまっており、OS の変更情報が網羅されているわけではないこと
    • image
    ChangeWindows.org
    • http://changewindows.org/
    • よいところ
      • 公式サイトなどの情報を元に作られた、非公式の機能追加・変更情報サイト
      • Insider Preview 単位の情報提供に加え、機能アップグレードごとに集約情報を提供
      • PC, Mobile, Xbox, Server, IoT すべての情報をわかりやすく一覧化して情報提供
    • 残念なところ
      • 公式サイトではないこと（というかこれが非公式サイトというのが未だ信じられないのですが；；）
    ASKVG
    • http://www.askvg.com/category/windows-10/
    • よいところ
      • 公式サイトなどの情報を元に作られた、非公式の機能追加・変更情報サイト
      • Insider Preview 単位の情報提供に加え、機能アップグレードごとに集約情報を提供
    • 残念なところ
      • ChangeWindows.org に比べて説明は細かいが、一覧性には劣る
    Windows 10 リリース情報
    • https://technet.microsoft.com/en-us/windows/release-info.aspx
    • よいところ
      • サービスアップデート（累積パッチ）の内容を解説した内容
      • CB リリース後の脆弱性・信頼性・バグ修正に関する情報を提供するもの
      • 日本語での情報提供もある
    • 残念なところ
      • サービスアップデートの情報しかない＝機能アップグレードの情報がない
      • このため、実態としては使いどころがほとんどない
    • image
    また、Windows 10 WaaS とは少し異なるのですが、こちらの情報についても紹介しておきます。 Windows and Windows Server compatibility cookbook
    • https://msdn.microsoft.com/en-us/library/windows/desktop/hh848074.aspx （日本語版はこちら、ただし Windows 10 部分のみ） 
    • よいところ
      • Windows 7→8, 8→8.1 における主な機能追加・変更に関する情報が取りまとめられている
      • 非互換項目についてはワークアラウンド（回避策）が掲載されているものもある
      • 下図にあるように、実際の Windows 10 への移行においては、① 初回の Windows 10 への移行と、② 移行した後の WaaS による継続的な更新とがある。②に関してはここまでに取り上げてきた情報が役立つが、①の部分に関してはこの Cookbook の情報が役立つ。
      • image
      • ただし、7/8/8.1 からの移行の場合、UI コントロールの見た目の変更に伴い、比較的大規模なアプリ互換性検証を行う場合が多いと考えられるため、この情報を使う必要があるかどうかに関してはケースバイケース
    • 残念なところ
      • 機能追加・変更がきちんとまとまっているのは 8.1 までで、10 以降に関しては情報がほとんどない
      • 英語の情報しかない
    ［Premier WaaS 非互換情報提供サービスについて］ ここまで代表的な情報提供サイトをご紹介してきたのですが、中程度のミッションクリティカル度を持つアプリ互換性検証を想定した場合、実際にほしいのは以下のような情報です。
    • FU ごとに、機能追加・変更に関する情報が一覧として整理されている情報がベンダーから欲しい。
    • 突合せ確認が簡単にできるように、表形式などでわかりやすく一覧化されていると使いやすい。できれば日本語で。
    この要件を考えた場合、上記の書いたサイトはどれも一長一短で、どうしてもある程度自分でのとりまとめが必要になります。
    • Windows 10 ロードマップ情報 : アプリ互換性検証の目的で使うには情報が粗すぎる。
    • Windows Insider blog : 情報としてはよいが、Insider Preview 単位に情報が細かく分割されてしまっているため、整理する手間がかかる。
    • Edge Changelog : 情報をまとめて一括表示できるのは便利だが、ブラウザの情報しかない。
    • What's new in Windows for developers : FU 間の差分情報が一覧で整理されているのは便利だが、UWP 系ランタイムの情報しかない。
    • Windows blog for Japan : 情報の網羅性がない。
    • ChangeWindows.org : 内容・まとめ方ともにほぼベストだが、英語かつ非公式。
    • ASKVG : 一覧形式にまとまっていないため、見るのが大変。
    • Windows 10 リリース情報 : そもそも SU の修正情報しか掲載されていない。
    • Windows and Windows Server compatibility cookbook : Windows 10 以降については情報がほとんど含まれていない。
    私が一通り使ってみた感触では、ChangeWindows.org の情報が一番使い勝手がよく、次点がその情報ソースである Windows Insider blog かな、という印象があるのですが、いずれも上記に述べた課題があります。正直なところ、実用上は ChangeWindows.org + Windows blog for Japan の 2 つの情報でいけると思うのですが、大企業の方（特に IT 部門の方）だとなかなかこれでは納得できない ＆ 各業務部門の開発現場を納得させられない、ということがあるかもしれません。 こうした事情から、私の方で Premier サポートの方々と相談し、（有償サポートではあるのですが）日本の Premier サポートサービスの提供サービスメニューの一つとして、「WaaS 非互換情報提供サービス」「Windows 7 → 10 非互換情報提供サービス」という名称で、機能追加・変更の一覧情報を FU リリースのつど提供できるように調整しました。 image 以下のような項目を一覧化して取りまとめています。ざーっと機能追加・変更を眺めて、各自の業務アプリに影響しそうな項目を抽出するのに役立てることができると思います。弊社プレミアサポート契約をお持ちであれば、有償ですがそこから入手が可能ですので、どうしても非公式情報や英語の情報では……といったことがあれば、弊社プレミアサポートまでお問合せください。
    • カテゴリ
    • 変更内容
    • 変更が加えられたバージョン／ビルド番号
    • 変更種別（機能追加・変更・削除）
    • 参考 URL（情報ソースとなっているより詳しい URL）
    • 要注意事項（レガシー業務アプリに非互換問題を引き起こしやすそうな項目）
    • 備考
    またここでは特に取り上げていませんが、私が所属しているコンサルティングサービスでは、（大企業様向けに特化していますが）Windows 10 導入支援や、開発近代化支援などのカスタムコンサルティングサービスを提供しています。Windows 10 WaaS 環境への移行や、システム開発を近代化して WaaS 対応はもとよりさらなる高開発生産性を目指したい、といったニーズに関しては、コンサルティングサービスにご相談ください。 ［Windows OS の変更ログの利用上の注意点について］ 最後に、Part 5-b. で触れたことの繰り返しになりますが、どのような非互換情報リストを利用しても、絞り込んだテストだけで非互換問題を事前に100% 洗い出すことは原理的にできない、という点についてはくれぐれも注意してください。マイクロソフトに限らず、ベンダーから提供される非互換情報そのものは、すべての変更点を網羅したリストにはそもそもなっておらず（＝すべての変更点を網羅したリストを提供していない）、また同時に、「何を機能追加・変更・修正とみなすのか？」に関しては、ある程度、人間の恣意的な判断が入ることが原理的に避けられません。 image ですから、以下の 2 点については必ず意識するようにしてください。
    • どのような変更ログを利用するとしても、絞り込み再テストを行う方法では原理的に見逃しリスクをゼロにすることはできない。
    • 故にリスクヘッジのためには FU/SU のリング配信と迅速な障害対応を組み合わせることが必須である。
    ［まとめ～エンタープライズ企業における Windows 10 導入と WaaS 適用の要点］ というわけでかなりの大ボリュームでお送りした一連の blog エントリですが、締め括りとして要点をまとめておきます。
    • エンタープライズ企業における Windows 10 の導入では、その後の WaaS 適用を見越した対応を行うことが重要である
      • Windows 10 の導入 ＝ 継続的にアップグレードされ続ける環境への移行である。
      • このため、WaaS での継続的な機能アップグレードの仕組みを理解するとともに、過去のやり方を見直し、効率的な保守・運用ができる仕組みを整えることが重要になる。
    • 代表的な Windows 10 導入の目的
      • 1. セキュリティ強化、2. モバイルワークスタイル、3. 多彩なデバイス活用、などを検討してみる
    • WaaS の正しい理解
      • IP/CB/CBB/LTSB の使い分けが重要、特に LTSB は一般の OA 端末で利用するものではないことに注意する
      • Windows 10 の更新には、FU、SU、ストアアプリの更新がある
      • FU は 1 バージョンスキップするものではなく、順次アップグレードしていくべきものであることに注意する
    • Windows 10 導入時の検討の流れ
      • Windows 10 の導入時にやるべきことは、アプリ／インフラ、すぐに対応できること／できないことに分けて考える
    • Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編
      • ミッションクリティカル度に応じて、互換性検証のレベルを変える
      • アプリ互換性検証の効率化の基本指針は、① テストケースの絞り込みと、② FU/SU のリング配信によるリスクヘッジ。
      • さらに効率化を進めたい場合、全体最適化が必要なこともある。その際は、中長期的な計画として、システム開発の近代化に取り組んでいく。
    • Windows 10 導入時に考え方・やり方を変えるべきポイント – インフラ編
      • 特に、セキュリティ、マスタイメージ管理、FU/SU 配信方式について検討するとよい。
    • Windows OS の変更ログの入手方法
      • いつどのような目的でどんな非互換情報（変更ログ）が必要になるのかを考え、それに合わせた情報入手方法を決定する。
      • 公式／非公式の様々な Web サイトがあるため、自分の目的にあった情報入手方法を検討しておく。
    Windows 10 の導入は、新しい近代的な IT 環境への移行である、と考え、本 blog エントリを参考に、ぜひ IT 環境やシステム開発の近代化を進めていただければと思います。長文にもかかわらず、最後までお付き合いいただいてありがとうございました。]]>         Part 6. Windows 10 導入時に考え方・やり方を変えるべきポイント – インフラ編 https://docs.microsoft.com/archive/blogs/nakama/win10waas-part6 Thu, 18 Aug 2016 00:10:00 GMT https://blogs.msdn.microsoft.com/nakama/?p=3085 ここまで Windows 10 導入におけるアプリ互換性検証の話題を扱ってきましたが、一方で、IT インフラに関しても管理方法の見直しが重要になります。現在の日本の大企業では IT インフラ管理に関する「人手での作業」が非常に多く行われていますが、昨今のクラウド化の流れや IT 自動化の流れを踏まえると、こうした「人手での作業」は限界を迎えつつあります。このため、Windows 10 導入に併せて『負の遺産』を清算し、IT インフラの近代化を進めることをぜひ検討してみてください。 見直すべきポイントはいろいろあると思いますが、ここでは特に以下の 3 つのトピックについて取り上げてみたいと思います。 image ［1. セキュリティ］ 日本におけるセキュリティ対策の考え方は、どちらかというと「コスト度外視で究極の安全性を追及する」傾向があり、結果的に現場の社員ががんじがらめのやりすぎルールに縛られて苦しんでいるというケースが多いです。ひどいケースになると、セキュリティ関連のルールの抜け道を一生懸命探して仕事を効率化する、なんていうこともありますが、これでは本末転倒です。社員の生産性を高めつつも近代的なセキュリティの脅威に対応していくためには、以下のようなことを考えていく必要があります。
    • 安全性と利便性の両方を取る
      • 安全性を高めようとして制限を増やしすぎると、社員の生産性が低下してしまう
      • 安全性と利便性のバランス（＝効用）を考えて、適切な落としどころを考える必要がある
    • 「ルール」を増やさず「技術」を活用する
      • 覚えられない ＆ 守れないルールを作るのではなく、「技術」で安全性を高める
    技術的に見た場合には、主に以下の 3 つのカテゴリに分けて考えるとよいと思います。Azure RMS など一部 Windows 10 の新機能ではないものもありますが、既存環境でまだ使われていない場合には、この機会に導入を検討してみてください。 image なお、これらのセキュリティ機能はすべてを使うということもないでしょうし、また特定端末に対してのみ使う（例えば AD を操作するマシンはセキュアにする必要があるのでそこだけ特に堅牢にする、など）こともあると思います。ただ気を付けておくべき点として、デバイス, OS（アーキテクチャ）, ブートシステムなどの選択に影響が出るセキュリティ機能もあります。例えば Windows Hello は生体認証に対応したカメラなどが必要になりますし、Credential Guard や Device Guard であれば、ハードウェアの対応だけでなく UEFI ブートや x64 OS なども必要になります。このように、Windows 10 導入直後には採用しないものの、いずれ採用したいというセキュリティ機能がある場合には、その制約を確認しておくようにしてください。 ［2. マスタイメージ管理］ 日本の大企業では、Excel による設定パラメータ値の管理と、Word による各種の作業手順書の作成が、今でもかなり行われています。もちろんこれらのやり方は、特に IT スキルのないお客様にぱっと見せて理解してもらう、といった観点で一定の有効性はありますが、その一方で、こうしたシートや手順書の管理が IT 保守コストの増大を招いている側面もあります。できれば以下のような見直しを行って、保守コストの低減を目指した方がよいです。（ちなみにパラメータシートによる管理は日本特有の文化らしいです。まあわかる気がする……；）
    • ① パラメータシートによる設定値の一覧管理
      • 増え続けるパラメータを管理し続けること自体に無理がある
      • 「実態」を実物管理し、そこに機能差分を調べて「追加していく」アプローチを採用する
    • ② 手作業でのクライアント端末マスタイメージの作成・保守作業
      • 端末種類が増えるとイメージ管理作業が膨大になるため、タスクシーケンスを作成する
      • さらに SCCM を使えば、キッティング作業も大幅に簡素化される
    image ［3. FU/SU 配信制御］ Windows 10 の導入とは、最新化され続ける IT インフラへの移行であり、そのためには FU/SU をオンラインで配布し続けられる環境を整えることが重要です。しかし、ネットワークを使って OS を更新する、という仕組みはまだまだ日本の大企業では馴染みが薄い（現在は端末入れ替えに併せて OS を更新するのが一般的）ため、FU/SU の配信制御方式について検討しておく必要があります。中でも特に重要なのは以下の 2 点です。
    • ① リング配信制御
      • アプリ非互換の見逃しリスク低減のため、FU/SU の段階展開が必要になる
      • 拠点のような単位ではなく、部門内・拠点内での端末単位の段階展開が必要であることに注意する
    • ② 分散拠点への FU/SU 配信
      • FU は 3～4GB（半年ごと）程度、SU は（累積パッチであるため）最大 1GB 程度（月次）
      • このため、細い WAN 回線を利用している分散拠点については、配信方法の検討が必要
    image ①については特に注意が必要なので気をつけてほしいのですが、FU/SU を先行配信するのはアーリアダプタユーザ、すなわち『特定のユーザ』に対してです。例えば②の図において、各拠点単位に順次 FU/SU を配信していくのではなく、各拠点の中の特定端末から順次配信していく、という形が求められます。また逆に、デバイスドライバの不具合などでアップグレードを抑止しなければならないようなケースでは、特定のハードウェアを使っているユーザに対しては配信を一時的に差し止める、という動きをさせなければなりません。 FU/SU の代表的な配信方法は主に以下の 3 通り（＋メディア配布）です。
    配信方法 リング制御 分散配布 P2P オプション 備考
    SCCM ◎ 柔軟に可能 ◎ 配布ポイント ◎ BranchCache •SCCM のバージョンアップが必要 •SCCM は端末管理やマスタ管理にも活用可能
    WSUS △ 可能だが面倒 ◎ 子サーバ ◎ BranchCache ◎ DO (RS1 以降) •差分配布（高速インストールファイル）をサポート •O365 ProPlus の配信ができない
    WU × 細かい制御は困難 × なし ◎ DO (WUDO) －
    メディア （手作業での配布） （手作業での配布） （手作業での配布） －
    ※ 略称は以下の通りです。製品などの概要は Web サイトに情報が多々ありますので、検索してみてください。
    • SCCM : System Center Configuration Manager
    • WSUS : Windows Server Update Services
    • DO : Delivery Optimization
    • WU : Windows Update
    • WUDO : Windows Update Delivery Optimization
    お客様の環境に応じたケースバイケースの検討が必要なため、一概にどれを選べばよいとは言えないのですが、まずは以下のような指針で考え始めてみるとよいと思います。
    • ① リング配信制御
      • 『特定のユーザ』や『特定の端末』への段階展開が必要だが、この制御は SCCM が最も柔軟にできる
      • SCCM はマスタイメージの作成や端末管理などでも活用できるため、SCCM が導入されている場合には、これが第一選択となる
      • SCCM が導入されておらず、かつ導入予定がなければ、WSUS, WU のどちらかを選ぶ（が、制限があったりリング配信制御が大変だったりするので要注意）
    • ② 分散拠点への FU/SU 配信
      • WAN 帯域が細い場合、分散拠点側に配布ポイントや子サーバを配置する方法が考えられるが、分散拠点側でこうしたサーバマシンを運用できないケースもある
      • このような場合には、P2P オプションを使う
      • WAN 帯域が極端に細い場合には、最後はメディア配布でカバーする
    実際のところ、どの配信方式が最適なのかは机上検討だけでは決めきれない部分があります（特に帯域については机上検討だけでは困難）。このため、ある程度は「やってみて考える」という部分が出てくるかと思います。また、回線コストも下がっている傾向はありますので、中長期的には WAN 回線の増強なども視野に入れて検討を進めていただければと思います。 ［継続的な情報入手について］ さて、Windows 10 の WaaS では、機能追加は例えばスタートメニューや設定画面、Cortana などの OS そのものに入ってきます。ということは、IT インフラ管理者は、Windows 10 WaaS で提供される新しい機能をどのように活用するのかを積極的に考えていく必要がある、ということになります。この検討に関しては、レガシー業務アプリの互換性検証に利用する変更点一覧情報のような細かいリストを元に考えるよりも、まず「セキュリティ」や「管理機能」などの大きな粒度で確認していった方がやりやすいと思います。この目的のためには、Windows for Business サイトを活用すると便利です。 image この 2 つのマイクロソフト公式サイトは、「大きな粒度での」機能追加・変更を把握するのに便利です。まずはこちらで概要を把握し、その後、新機能を詳細検討し、グループポリシーやマスタイメージへの組み込みなどを進めていくとよいでしょう。 ]]>