『変わらない開発現場』シリーズ 情報ポインタ一覧

昨日ですが、ようやく 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 『変わらない開発現場』を変えていくために ~エンプラ系レガシー…

0

拝啓『変わらない開発現場』を嘆く皆様へ ~変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み~

 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。  こうした背景があり、de:code 2017 ではセッションを担当すると同時に、参加者全員に配布するマーケティングのリーフレットを使って、筆者赤間の所属するマイクロソフト エンタープライズサービス(有償サービス部門)での最近のコンサルティングの取り組みをいくつかご紹介するという試みをしてみました。マーケティング部門の費用を使っている関係で、弊社サービス部門の営業色が入った内容にはなってしまっているのですが、その一方で、この情報は(特にエンプラ系 SIer やエンド IT 部門、IT 子会社のマネジメント層の方々にとって)組織やチームをどういった方向に導いていけばよいのかの指針になる、とも考えています。実際、いくつかのお客様でこの取り組みを私からご紹介したのですが、自組織の今後の方向性を整理する上で非常に参考になった、という F/B が多かったです。  個々の皆様の事情はそれぞれ違えど、多少でも参考になる部分があればと思い、blog 化してこちらのサイトにも掲載することにしました(基本的な骨子はリーフレットと同じですが、ページ数の関係で書ききれなかったことを加筆修正しています)。よろしければぜひご覧いただければ幸いです。 ■ エンプラ系 業務システム開発を俯瞰する  クラウドに代表される昨今の技術革新は、業務システム開発の在り方に大きな影響を与えてきました。インフラ、アプリ、運用などの領域に分けてみると、以下のような変化が起きています。  これらの中でも特に重要なのが、「アプリ特性に応じた開発のやり方をする」という考え方です。様々な分類方法が提唱されているのですが、ここではシンプルでわかりやすい、SoE(System of Engagement / お客様との絆を強めるためのシステム)、SoR (System of Record / 事実を記録していくためのシステム)という分類を取り上げてみます。SoE 型システムとは「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステムで、代表例としてはコンシューマ向け Web サイトやゲームアプリ。一方、SoR 型システムとは「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった作成を持つシステムで、代表例としては金融系勘定システムのようなものが挙げられます。  並べてみると明らかなように、これらはシステム開発としての基本的な特性が大きく異なります。例えば SoE 型システムはページ数や業務数は少なめですが、かわりに極めて先進的な技術が投入されます。一方、SoR 型システムは、一つ一つのロジックはさほど難しくないものの膨大な数の業務が存在し、品質の安定性重視のために枯れた技術が好まれる傾向にあります。  また、開発特性が異なれば、求められる開発文化も当然異なります。例えば SoE 型システムでは「素早くリリースして素早く軌道修正していく」という Try &…

3

Part 7. Windows OS の変更ログの入手方法

ここまでアプリ・インフラ両側面から Windows 10 WaaS 環境への移行についての注意点などを解説してきましたが、最終的にはインフラ/アプリどちらの観点であっても、FU/SU での変更点を把握して検討することが重要になります。 インフラ観点 : FU で提供される新機能をどのように取り込むか? アプリ観点 : FU/SU で行われた変更でどのようなデグレードが発生しそうか? この Windows OS の変更ログは様々なチャネルを介して提供されており、自分の目的に合ったものを探して利用する必要があります。 [FU/SU 配信の流れと IP/CB/CBB の関係の再整理] まず復習として、FU/SU の配信タイミングと、IP/CB/CBB の関係を整理すると、以下のようになります。 用語の整理 IP : Insider Preview (アーリアダプタ向けに公開される中間ビルド) CB : Current Branch (コンシューマ向けのリリース) CBB : Current Branch for Business (ビジネスユーザ向けのリリース) FU : Feature Upgrade (いわゆる従来のサービスパックに相当) SU : Servicing Update  (いわゆる従来の累積セキュリティパッチに相当)(※ 今後は QU…

0

Part 6. Windows 10 導入時に考え方・やり方を変えるべきポイント – インフラ編

ここまで Windows 10 導入におけるアプリ互換性検証の話題を扱ってきましたが、一方で、IT インフラに関しても管理方法の見直しが重要になります。現在の日本の大企業では IT インフラ管理に関する「人手での作業」が非常に多く行われていますが、昨今のクラウド化の流れや IT 自動化の流れを踏まえると、こうした「人手での作業」は限界を迎えつつあります。このため、Windows 10 導入に併せて『負の遺産』を清算し、IT インフラの近代化を進めることをぜひ検討してみてください。 見直すべきポイントはいろいろあると思いますが、ここでは特に以下の 3 つのトピックについて取り上げてみたいと思います。 [1. セキュリティ] 日本におけるセキュリティ対策の考え方は、どちらかというと「コスト度外視で究極の安全性を追及する」傾向があり、結果的に現場の社員ががんじがらめのやりすぎルールに縛られて苦しんでいるというケースが多いです。ひどいケースになると、セキュリティ関連のルールの抜け道を一生懸命探して仕事を効率化する、なんていうこともありますが、これでは本末転倒です。社員の生産性を高めつつも近代的なセキュリティの脅威に対応していくためには、以下のようなことを考えていく必要があります。 安全性と利便性の両方を取る 安全性を高めようとして制限を増やしすぎると、社員の生産性が低下してしまう 安全性と利便性のバランス(=効用)を考えて、適切な落としどころを考える必要がある 「ルール」を増やさず「技術」を活用する 覚えられない & 守れないルールを作るのではなく、「技術」で安全性を高める 技術的に見た場合には、主に以下の 3 つのカテゴリに分けて考えるとよいと思います。Azure RMS など一部 Windows 10 の新機能ではないものもありますが、既存環境でまだ使われていない場合には、この機会に導入を検討してみてください。 なお、これらのセキュリティ機能はすべてを使うということもないでしょうし、また特定端末に対してのみ使う(例えば AD を操作するマシンはセキュアにする必要があるのでそこだけ特に堅牢にする、など)こともあると思います。ただ気を付けておくべき点として、デバイス, OS(アーキテクチャ), ブートシステムなどの選択に影響が出るセキュリティ機能もあります。例えば Windows Hello は生体認証に対応したカメラなどが必要になりますし、Credential Guard や Device Guard であれば、ハードウェアの対応だけでなく UEFI ブートや x64 OS なども必要になります。このように、Windows 10 導入直後には採用しないものの、いずれ採用したいというセキュリティ機能がある場合には、その制約を確認しておくようにしてください。 [2. マスタイメージ管理]…

0

Part 5-d. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編④

さて、実際の既存業務アプリを考えると、「理想的なアプリ開発」が行われていないことが多く、「理想的なアプリ互換性検証」を行えない場合が少なくありません。短期的な対策としてはやむなしという部分も大きいですが、中長期的を見据えると、今のままのやり方を繰り返していては苦しくなるだけです。ですからここで今一度、「理想的なアプリ互換性検証」や「理想的なアプリ開発」を再考し、次のシステム開発で何に注意すればよいのか、を考えておくべきです。この観点では、マイクロソフトの社内のやり方に、参考になるヒントが多数存在しますので、少しご紹介してみることにします。 [事例:マイクロソフト社内のアプリ互換性検証作業の効率化] 当たり前のことですが、マイクロソフトの社内にも、皆様の会社と同様、多数の業務システムが存在します。マイクロソフト社内では、MSIT と呼ばれる社内 IT 部門が社内業務アプリを管理しており、経費精算アプリ、物品購買システム、マッサージ予約システム、出退勤管理システム、パフォーマンスレビューシステムなどなど、全世界トータルでは約 2,100 個の社内業務アプリが存在しています。こうした社内業務アプリをどのように Windows 10 WaaS に対応させているのかが、かなり詳細な事例情報として Web 上に公開されています。 https://www.microsoft.com/itshowcase/Article/Content/668/Deploying-Windows-10-at-Microsoft-as-an-inplace-upgrade https://www.microsoft.com/itshowcase/Article/Content/519/Microsoft-IT-improves-LOB-application-testing-ensuring-readiness-for-Windows https://www.microsoft.com/itshowcase/Article/Content/520/Microsoft-IT-prepares-LOB-apps-for-Windows マイクロソフト社内の場合、非互換障害が発見された際には必要に応じてアプリ側の修正ではなく Windows OS 側に修正をかける、という点は一般企業と異なりますが、とはいえ非互換検証作業の具体的な効率化手法に関しては、参考になる部分も非常に多いです。なのでぜひ上記の URL をご確認いただきたい……のですが、英文全部を確認するのはさすがに大変だと思いますので、要点を私なりにざっくりと整理すると、以下のようになります。(間違ってたらごめんなさい;、古い情報と新しい情報が混在しており一部情報に食い違いがあったりしているため、完全に 100% 正しくはないかもしれませんが、細かい数字はともかくも要点は間違っていないはずです。) 特に重要なポイント 互換性検証を効率的に進めるため、グローバルで集約テストチームを運営している。 2,100 個の業務アプリから 300 個を選出して集中的にテストしており、さらに段階的な OS 配布を併用することで、致命的な非互換問題の発生を防いでいる。 これらにより、互換性維持の費用を $700k/year (約 7,000 万円/年程度)にキープし続けている。 具体的なテスト効率化の方法 ① テストケースの絞り込み テスト対象システムの絞り込み テストケースの絞り込みの前に、そもそもテスト対象システム(アプリ)自体を絞り込んでいる。 アプリケーションポートフォリオ管理ツールで、社内 LOB システム 約 2,100 個を一元管理。 この中から 約 300 個を Key Test…

0

Part 5-c. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編③

[アプリ互換性検証の効率化の手法② 見逃しリスクへの対応] 前述したように、非互換情報リスト(変更ログ)を使ってテストケースを絞り込むことで、アプリ互換性検証に関わる工数を大きく削減できますが、その一方で、非互換問題の見逃しによる障害リスクをゼロにすることは原理的にできません。このため、非互換障害が発生した場合の被害を最小化する施策も併せて取る必要があります。具体的な方法は主に以下の 2 つです。 A. 一部のアーリアダプタユーザに対する CB(または IP) の先行配信(リング配信) 社員の一部に、先行して CB (または IP)を配布して実業務で使ってもらい、非互換障害が発生した場合には、すみやかに修正を行う。 B. ベンダーとの協業強化による迅速な障害修正対応フローの確立 特にアプリを外注している場合には、速やかな修正ができる体制を整えてくおく。 それぞれについて補足説明すると、以下の通りです。 A. 一部のアーリアダプタユーザに対する CB(または IP) の先行配信 「アーリアダプタ」とは「早期利用ユーザ」のことで、いきなり全社員に一律で FU/SU を配信するのではなく、アーリアダプタから段階的に FU/SU を配信して利用者を増やしていくことにより、非互換問題発生時の問題を極小化しよう、というものになります。この考え方は Windows OS そのものの開発でも使われているもので、リング配信と呼ばれています。(ここでは話を簡単にするため、FU のリング配信についてのみ解説します。これがわかれば、SU についても似たような考え方ができるはずです。) FU の実際のリング配信のやり方については、対象となるアプリの種類によって変わります。 コンシューマ向けサービスや ISV パッケージ製品・サービスの場合 この場合、ユーザ側は FU(November Update や Anniversary Update など)が CB としてリリースされると FU 適用を始めますので、それより先行して利用検証をしなければなりません。 このため、このケースでは Insider Preview を使って先行検証・リスクヘッジをすることになります。 社内業務アプリの場合 この場合、大多数のユーザ(社員)が…

0

Part 5-b. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編②

WaaS におけるアプリ互換性問題を考える上では、Windows 10 → 10 への機能アップグレードにおいて、どの程度、既存レガシー業務アプリに影響を及ぼしうる変更が加えてられているのか、という点が重要になります。もちろん、将来のことはわからない部分もありますが、とはいえ November Update や Anniversary Update の内容を精査してみることは、FU(機能アップグレード)の中身の特性を理解する上で重要になりますので、もう少し細かく見てみることにします。 [Windows 10 FU 間の互換性の実態] 詳細は Part 7 にて解説しますが、Windows 10 の機能アップグレード(FU)で行われた内容については、非公式サイトですが changewindows.org というサイトが(英語ですが)非常によくまとまっており、このサイトを見ると、一覧形式で 8.1 → TH1, TH1 → TH2, TH2 → RS1 で行われた主な機能追加・変更を確認することができます。こちらを確認していただくと、Windows 10 の FU は大まかには以下のような傾向があることがわかります。 Windows 8.1 → Windows 10 TH1 UI まわりが大きく変更されている。(このため、.NET や VB6 アプリもその影響を受ける) その他、OS 全体に比較的大きな機能追加・変更が加えられている Windows 10 TH1 →…

0

Part 5-a. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編①

[大企業におけるレガシー業務アプリ資産について] ここまで解説してきている通り、Windows 10 への移行における大きな障壁のひとつに、アプリ互換性検証の問題があります。特に大企業では、多数のレガシー業務アプリ資産を抱えていることが多く、従来は数年に一回の OS アップグレード、あるいはサービスパック適用時などに大規模な再テストを手作業で実施していたわけですが、WaaS のように頻度が高まると、同じやり方が通用しなくなります。 特に課題になるのは、非近代的なアプローチで開発された、作りっぱなしの既存の業務アプリ資産です。近代的な業務アプリ開発では、テストの自動化や CI/CD、DevOps といった手法を取り込み、リリース後の継続的な保守が容易になるように、常に技術的負債を一定以下に抑え込むような開発・保守スタイルを取ります(詳細は後述)。しかしこうした考え方が一般的ではなかった時に作られたアプリ(いや日本だと今でも、ですけど;)のほとんどは、作った後の保守や互換性検証のことがきちんと考えられておらず、作りっぱなしで後は場当たり的な保守が行われているというのが実態です。こうしたアプリはうっかりすると資産というより負債になっていますが;、既存アプリ負債とか呼ぶと切なすぎるので;、ここではレガシー業務アプリ資産と呼ぶことにしたいと思います。 現在のレガシー業務アプリ資産の大半は、おそらく従来のテクノロジ、すなわち .NET ランタイムや VB6 ランタイムなどで作られていることが多いと思いますので、ランタイム的にも以下のものだけを想定して解説を進めることにしたいと思います。 VB6 フル .NET Framework (CLR2, 4 系)※ .NET 2.0~4.6 のアプリ IE11 ※ 上記のいずれもカーネル互換性のない業務アプリを想定しています 逆に、以下のようなランタイム上で作られているアプリは、今回は対象外として解説します。これらのランタイムはもともと頻繁にバージョンアップを繰り返しており、モダン(近代的)なアプリ開発アプローチを取らないと、そもそも開発・保守ができないためです。 エッジブラウザ向け Web アプリ(HTML5, JavaScript, CSS )※ Microsoft Edge, Google Chrome, Mozzila FireFox など向けの Web アプリ UWP (Universal Windows Platform) ASP.NET Core Xamarin [既存レガシーアプリに対する互換性検証の基本的な考え方] さて、ここから既存レガシーアプリに対する互換性検証の考え方を解説していきますが、細かい話をする前に、まず基本的なポイントとして、OS バージョン間の互換性は昔に比べて高まっている、という実態を抑えておく必要があります。 特にコンピュータ歴の長い方は、ご自宅でのパソコン利用に際して、98…

0

Part 4. Windows 10 導入時の検討の流れ

[導入計画立案の必要性] ここまで述べてきたように、Windows 10 の導入では WaaS を見越した検討を行う必要がありますが、特に大企業の場合、WaaS における頻繁なアプリ互換性検証の実施が課題になりやすい、という特徴があります。インフラ面では従来の Windows OS のバージョンアップとそれほど大きく変わるわけではないものの、とはいえ保守性の向上(保守コストの削減)や、ネットワーク経由での継続的な FU/SU 配信については課題になるケースも多いでしょう。 こうしたことを考えると、Windows 10 導入では、アプリ/インフラ両側面から対応検討を行うことが望ましいのですが、大企業の場合、インフラを管理する IT 部門と、業務システムを管理している事業部門とが分断されているケースがよくあります。このため、IT 部門と各事業部門とがしっかり連携できる状況を作っておくことも重要です。 また Part 5 以降では実際の検討ポイントを解説していきますが、特にレガシーな業務アプリは一朝一夕に改善できないケースが多いため、直近での「とりあえずの」対応と、中長期的な「抜本的な」改善とを分けて考える必要があります。Part 5, 6 を確認していただいたら、下図のような絵を整理していただき、やるべきこと(対応施策)を「インフラ/アプリ」「短期/中長期」に分類していただくことをオススメします。 [特に検討を必要とするポイントについて] 特に、企業内の IT インフラを管理している IT 部門の方からすると、「Windows 10 への移行は、従来の OS バージョンアップと何が違うのか? どこの考え方を特に変える必要があるのか?」という点が気になると思いますので、簡単に下図に整理してみました。 ざっと要点を解説すると、以下の通りです。 インフラ系 クライアント設計やハードウェア選定などの作業は従来と全く変わりがありませんが、今後は「よりセキュアな環境」を「低コストで維持し続ける」ことが今まで以上に重要になってきます。このため、① セキュリティに関する検討と、② 従来手作業で実施していてかなりコストがかかっているポイントの改善、はぜひ実施すべきです。 ②に関しては皆様個々に懸念点が異なると思いますが、多くのお客様で実施されている、パラメータシート管理と手作業でのマスタイメージ作成の 2 点については、この機会にぜひ見直しをオススメしたいです。 また、「継続的に進化し続ける IT 基盤」を実現するために、③ FU/SU の配布方法、を検討することも重要になります。この FU/SU の配信方法はアプリ互換性検証と密接な関係を持っており、最終的な結論としては、FU/SU を段階展開(リング配信)する必要があります。 アプリ系 なんといっても、① WaaS における頻繁なアプリ互換性検証の実施方法、が最大の課題ですが、これをスムーズに行っていくためには、最終的には、②…

0

Part 3. WaaS の正しい理解

さて、ここからいよいよ本題である WaaS の解説に移っていきます。 [WaaS の正しい理解 – Windows 10 における OS 更新モデル] ここまで解説したきたように、「Windows 10 の導入」とは、「継続的にアップグレードされ続ける環境への移行」でもあります。このため、Windows 10 の導入に際しては、『導入後にどのようになるのか?』を理解・検討しておくことが極めて重要です。まずは、Windows 10 移行後の、WaaS による継続的更新(機能追加)の仕組みについて理解しましょう。 [4 つの OS 更新モデル(IP, CB, CBB, LTSB)] ご存じのように、Windows には Home, Enterprise, Pro などの「エディション」という分類が存在しますが、これとは別にもう一つ重要な分類として、「機能追加の受け取りタイミング」という選択肢が存在します。例えばこれまで、Windows 10 は November Update、Anniversary Update という機能追加が実施されているのですが、この機能追加をいつのタイミングで受け取るのかを調整することができるようになっています。具体的には、以下の 4 つの選択肢があります。この 4 つの選択肢については(名称も含めて)暗記してください。 名称 この資料での略称 概要 主な利用者 Insider Preview IP 機能追加の受け取り時期を早める 一部の早期利用ユーザ Current Branch CB 4~8…

3