触って覚える Microsoft Azure

今日から TechSummit 2018 が開幕していますが、私の方はというと、手持ちの仕事があまりにも忙しすぎて品川オフィスの居残り組(涙)。まあそんなこともあるよと思うのですが、季節はやっぱり勉強の秋!(ぇ? ということで、Azure デビューしてみたい、という方向けの無償学習リソースについて、ざっと整理しておきたいと思います。特に先日リリースされた 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 を触ってみることが可能なところです(クレジットカード登録も不要)。さらにトレーニングを完了するとポイントが付与され、どの程度学習したかがわかるようになっています。この仕組みにより、ゲーム感覚で楽しく学べると思います。 実際にサイトを利用する場合には、Azure ラーニングパスを利用し、テーマに沿って一連のハンズオンを学習するとよいです。 最初にオススメのラーニングパスは以下の 3 つです。まずはここから。 Azure…

0

Docker for Windows & Web Apps for Containers 実践活用技法

先日、しれっと営業部門のクラウドソリューションアーキテクトに異動した話を書いたのですが、このロールは Azure の拡販に向けたプリセールスのミッションを担ってます。で、このロールでお仕事をしていると、やっぱり技術情報提供がまだまだ足りていないなと感じるところもあります。 その一つが Docker 関連の実践的な活用技法に関するもの。世の中を見ていると、Docker の情報は Linux OS 上で扱うものが多く(たぶんみなさん Mac 上で開発されてるんでしょう;)、Docker for Windows の情報が非常に少ない。あるいは Web アプリの Docker コンテナは Azure の Web Apps for Containers で簡単に動かせるにもかかわらず世の中からはガン無視されてたり(涙)。これはさすがにまずかろう、ということで、先日作った資料をまるごと一つ、ごそっと公開してみようかと思います。 Docker for Windows & Web Apps for Containers 実践活用技法 from Microsoft Corporation この資料はタイトルの通り、アプリ開発の実践的な視点から Docker for Windows と動作環境である Web Apps for Containers を使ってみよう、というもので、Docker の基本的なところから解説しています。あくまで実践! ということで、一般的な Docker の本で書かれている内部的な話とかレイヤーの話とかはガン無視してます。まずこの資料などで Docker for Windows…

0

Agile も DevOps も銀の弾丸なんかじゃない

……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが;、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ;」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話だったのかというと、 アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ? → そんなわけないでしょ;。 これからの開発は当然アジャイルとか DevOps でしょ! → そんなわけないでしょ;。 みたいな話;。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~」というエントリを書いたのですが、その補足的な意味合いも兼ねて、少しまとめてみようと思います。正直、当たり前すぎる話なので、その道のプロな方は「ふ~ん」と読み流してください;。 [アジャイルや DevOps を活用することによる ROI 最大化の注意点] のっけから結論を書いてしまうのですが、アジャイルや DevOps をエンプラ系プロジェクトに適用してメリットを得たい場合には、以下 2 つの点に特に注意する必要があります。 簡単に言えば、十把一絡げにアジャイルや DevOps を適用してもうまく行くわけがなく、これらの手法は決して銀の弾丸ではありません。しかし、なぜこれらが銀の弾丸ではないのか、またどんな条件があればアジャイルや DevOps のメリットが最大化されるのかは、意外に端的に語られていないため、軽く説明してみたいと思います。 [アジャイル開発 vs ウォータフォール型開発] モノづくりの観点から考えると、ウォータフォールとアジャイルは、計画型/適応型のトレードオフの関係で捉えることができます。このため、それぞれ請負向き/内製向きという特性があることは、以前のエントリでも解説しました。日本の開発現場では、両者は二者択一の文面で語られることが多いのですが、日本のエンプラ系開発現場においてより良い開発を目指すためには、両者をミックスした開発プロセスのテーラリングが必要になります。 しかし、このような説明だとなかなかしっくりこないと思いますので、ぶっちぎりの適応型アジャイル(ここでは仮に「フルアジャイル」と呼ぶことにしましょう)がどのようなものなのかを考えてみたいと思います。 [完璧(?)なアジャイル開発について] ご存じのように、アジャイル開発の背後には、「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」がベースラインの考え方として存在します。原典そのまま引用すると、こんな感じです。 しかし見ていただければわかる通り、これらは具体的に何かの(技術的)手法を定義しているわけではなく、ある意味、ソフトウェア開発の『理想像』や『思想』を語ったものに近いです。実際、アジャイルを実践する開発現場では、日々、自律的な模索と改善が続けられ、よりよい開発技法を目指して進化を続ける……これこそがアジャイルの真価ではないかと思います。 ……が、ぶっちゃけこれだと煙に巻かれた気がするなんだかよくわからないのも実際のところです;。以下は完全に私の私見なのですが、実際にこれらを目指して優れたアジャイル開発を実現している現場では、特に以下の 4 つをきっちり実践しているように思います。(この辺は皆様のご意見をいただきたいところですが、私の感覚として。) ちょっとだけ補足をすると、以下の通りです。(MVP アプローチは極めて重要なので後述) 内製開発 一般的に請負型ウォータフォール開発では、受発注関係による利害関係が生じるため、請負契約の後は、発注側は「いかに変更・修正を突っ込むか」、受注側は「いかにそれを突っぱねるか」という不毛な争いが生じます。 (特に大規模開発においては)請負契約は、確実に成果物責任を以て遂行させるという観点において極めて重要なものですが、一方で、関係者全員が同じ方向を向いてゴールを共有することが時として難しくなる元凶にもなり得ます。 内製開発であれば関係者全員が同じ方向を向いてゴールを共有することが容易ですが、その一方で、全員がプロフェッショナルであり、オープンかつ自律的な活動・改善ができる(言い換えれば全員が大人である)ことが求められます。(大規模開発だとそれだけの数のプロフェッショナルの頭数を揃えることが困難なケースが多いです。) データ駆動型開発(運用環境第一主義、Production First Mindset) 例えば仕様案として A, B…

0

.NET Framework における時差情報(サマータイム)の取り扱い

実は先日、8/1 に社内で異動しまして、18 年間続けてきたコンサルタントからクラウドソリューションアーキテクトにロールチェンジしました。さてこの blog もタイトルを変えるべきかどうなのか……とかまったり考えていたら、ここ数日、びっくりするような話題が飛び込んできました。 「サマータイム導入はコンピュータシステム的に難あり」は本当か サマータイム実施は不可能である 2020 年のオリンピックに向けて、限定的(または恒久的)にサマータイムを導入する、というもの。話を聞いたときに耳を疑ったのですが、いやもう絶対に不可能だろう、と私も思いました;。上記に取り上げた立命館大学の上原さんのスライドは非常によくまとまっていて、ホントこれ、と思いましたが、一方で Windows をはじめとするコンピュータシステムでそもそもサマータイムがどのような取り扱いになるのかを知らない人は多いのでは?、と思います。 実はずいぶん昔に国際化対応アプリケーションの開発方法を調べたことがあり、そのときにタイムゾーン(時差情報)をどのように取り扱うのか、をまとめたことがあります。おそらく皆様の参考になるのでは、と思いますので、若干手直しして情報共有してみます。10 年以上前の資料なので、画面のスナップショットがまさかの XP や Vista(!)だったりするのはご容赦、なのですが、考え方は特に変わっていないので、今でも普通に通用する内容かなと思います。(もし何か変わっているところがあったら教えていただけると嬉しいです;。) .NET Framework におけるタイムゾーンの取り扱い   ちょっと長いスライドなので、夏時間(サマータイム)という観点から要点を抜き出すと、以下の 2 つがポイントです。 ① Windows OS 上では、夏時間はタイムゾーンの変更として取り扱われる (p.10) 夏時間に入る=別の国のタイムゾーンに移動したのと同じようなこととして扱われます。イメージとしては、日本国内にいながら、時差のある国へ海外旅行に行ったのと同じような取り扱いになる、と考えるとわかりやすいかと思います。(なお、夏時間などのタイムゾーン情報はレジストリ情報として管理されており、Windows Update によりメンテナンスされています。なので本資料ではカバーしていませんが、 .NET Core で作ったアプリを Linux 上で動作させたりする場合にはまた別の注意が必要になってきます。) ② DateTime 型の加減算処理を行う際は、必ず UTC を介して行う (p.35, 36) .NET Framework 上で日付をプログラミングする際、DateTime 型でプログラミングされている方が多いと思いますが、DateTime 型はオフセット値(UTC からの時差)を持つことができません。DateTime 型は、「見た目の数値」をそのまま加減算処理してしまうため、夏時間前後でのオフセット値の変化に対応できません。このため、DateTime 型で加減算処理を行う場合には、必ず UTC を介して計算する必要があります。(ちなみにこの問題に対応するために導入されたのが DateTimeOffset 型です。)…

1

VSTS/TFS Test Manager による手動テスト(打鍵テスト)の効率化

先日の話ですが、5 月下旬に開催された de:code 2018 に、若手エースコンサルタントの原田さんと一緒に登壇させていただきました。私事の関係で突発で穴を開けるリスクがあり、今回は登壇を見送ろうかと思っていたのですが、原田さんに協力いただけるとのことになったので、初めて共同登壇という形にさせていただきました。二人で登壇するといろいろ気付きもあり、私自身、非常によい経験になりました。(改めて原田さん、無茶ぶりに協力していただいてありがとうございました。m(_ _)m) さて de:code 2018 では IT Modernization の重要性について説明し、そこから手動テスト(打鍵テスト)の効率化について取り上げて解説を行いました。日本の多くの SIer では未だ Excel を使った打鍵テストが行われまくっていますが、この部分は VSTS/TFS の Test Manager を利用することにより大幅な効率改善ができます。このエントリでは、セッション内容について簡単に整理しておきたいと思います。 [打鍵テストの効率化に対する考え方] 手動での UI 打鍵テストの効率化については、すぐさま「自動化して効率化しよう」という話が出がちですが、自動化による効率化がうまく機能する(高いコストメリットが出る)ためにはテストの繰り返し回数が多いことが必要です。代表的には以下の 2 つのようなケースに当てはまると、自動化が極めて有効に機能します。 かなりの構成テストが必要(構成テスト=異なる OS やデバイス、ブラウザなどで同じテストケースを何度も繰り返すこと。最近だとスマホアプリのような場合が代表的。) 同一の UI や機能に対して長期保守が必要(例えば Windows OS のように一度リリースするとそのバージョンを同じ機能のまま最大 10 年間保守し続けなければならないような場合) しかしエンプラ系の業務システムでは、上記のような条件が満たされていないことも多く、また自動化するにしてもテストケースがあまりにも多いために全部を自動化するのが現実的ではないこともよくあります。こうした背景から、エンプラ系業務システムではかなりのテストケース(特に結合テスト以降のテスト)が手作業で行われており、この傾向は今後もあまり変わらないでしょう。 [ツールによる効率化の必要性] とはいえ、だからといって Excel を使いまくったテストは非効率的です。一般に打鍵テストは以下の手順で進みますが、特に後半の作業はツールによる効率化を図るべきところです。 網羅的かつ効率的なテストケースを組み立てる 組み立てたテストケースを元に、打鍵でテストを実施する テスト結果を保存するために、手作業でスナップショットを取り、Excel にぺたぺた貼り付ける テスト結果を集計するために、手作業で Excel に実施結果を書き込んでいく バグを報告するために、手作業で Excel を使ってバグ報告を行う 実はマイクロソフトでは、手動打鍵テストを効率化するためのツール…

0

業務システム開発 モダナイゼーションガイド

あいかわらず稀にしか更新しない blog で大変恐縮なのですが、自身 10 冊目(!)となる書籍が発刊されました!(前回の Azure 本から実に 7 年ぶりという遅筆ぶりなのですが;。) 正式タイトルは「業務システム開発 モダナイゼーションガイド~非効率な日本のSIを変革する実践的ベストプラクティス~」。今回の書籍のテーマは、日本の SIer の旧態依然とした Excel まみれの業務システム開発の手法を近代化(モダナイゼーション)して生産性を高めようというもので、以前、弊社のイベント de:code で大変反響のあった「拝啓『変わらない開発現場』を嘆く皆様へ」のフルセット版のようなものになります。タイトルだけでは書籍の内容がさっぱりわからん! という方が多いのではないかということもあり、こちらに本書のまえがき全文を掲載したいと思います。ご興味のある方は、ぜひ本屋でお手に取っていただければ嬉しいです。(日経 BP さんのサイトでの紹介はこちらです。社内エンジニアの育成テキストなどとしてもご活用いただけると思いますので、もしバルク購入したいというご要望がありましたら、こちらのお問い合わせフォームから日経 BP さんにご連絡ください。) # ちなみにどうでもいいつぶやきですが、個人での印税受け取りは放棄しているため、「儲けた印税で飲みに連れていってください!」的なリクエストはなしで & ワリカンでお願いします;。 本書の執筆にあたっては、日経 BP さんをはじめ、社内外のたくさんの皆様からご協力をいただきました。改めてこの場を借りてお礼申し上げます。ありがとうございましたm(_ _)m。また、イイネ! ダメダネ! とか、この本いいよ! ここ間違ってるよ! ここはもっといいやり方あるよ! とかありましたら、Facebook/Twitter/この記事のコメント/はてブなどで反応いただけるとめちゃめちゃ嬉しい & 励みになります。 私の SI 業界での 20 年間の経験の集大成として執筆しました。情報密度がかなり高い本になっていますので、社内勉強会でみんなで検討しながら読むなど、ぜひ周りの方とも情報共有しながら現場でご活用いただければと思います。この書籍が、皆さまの開発現場を少しでも改善するきっかけになること、そしてこの本を踏み台にして、よりよいシステム開発方法論が建設的に議論されていくことを心から願っています。では、以下、まえがきです。 業務システム開発 モダナイゼーションガイド~非効率な日本のSIを変革する実践的ベストプラクティス~ まえがきより ■ はじめに ~『変わらない開発現場』を嘆く皆様へ~ 「日本の SI ビジネスは崩壊前夜」 「日本の SI はガラパゴス」 「日本の…

0

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

昨日ですが、ようやく 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