「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(前編)。「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(前編)。2016」が1月19日と20日の2日間、都内で開催されました。そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。DevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介します。マイクロソフトが実践したScrum導入7年間の旅。マイクロソフトのDevOpsエバンジェリストの牛尾と申します。今日は「マイクロソフトが実践したScrum導入7年間の旅。DevOpsへの進化」という話をしようと思います。2014(2014年7月に米オーランドで開催)のキーノートなんですね。いまは2016年ですので、彼に話を聞いて、今日はその内容を完全日本語化しました。マイクロソフトは苦労して時間をかけて、ウォーターフォールからアジャイル開発の世界、そしてDevOpsの世界へと社内の開発を移行させてきました。最初にDevOpsについて話をしますと、DevOpsとはビジネス、Dev、Opsが協力し、ソフトウェアライフサイクルを改善し、ビジネス価値の創出を改善する活動です。アジャイル開発は開発が中心のイメージですが、DevOpsはオペレーションも含んでいて、アジャイル開発の考え方を拡張したものだと思っていただければいいと思います。米国では銀行や生保といった堅いと思われている企業でも、DevOpsで一日に10回以上アプリケーションをデプロイしているところがあります。これはテクノロジーだけでは絶対無理で、マインドセットやビジネスルールを変えていかなければいけない。いうことをしないと達成できないですね。Labsが公開している資料ですが、コードのデプロイが30倍スピードアップし、パフォーマンスの低い環境に比べてリードタイムが200分の1に短縮できると。ほんまかいなと思います。エラーを60分の1に削減できるとか、エラーからの復元を168倍高速にできるとか。したことによって企業の収益性や生産性が高まっていると。普通、アジャイル開発をやっていてもプロダクトをリリースするのは3カ月ごととかじゃないですか。それが1日に10回もできるなんて、DevOpsはすごいじゃないですかと。Services」というサービスをいまマイクロソフトはDevOpsで開発しているのですが、そこで学んだことをみなさんと共有したいと思います。プロジェクト管理のための製品で、プロジェクトを作って、Gitなどでバージョン管理やコードのビルドができて、リリースマネジメントもできてという製品です。Services」という製品で、オンプレミスにインストールするパッケージソフトウェアでした。それをクラウド版として展開を始めたとき、リリースの初日に7時間もサービスがダウンしました。ネットワークのログもちゃんととってなかったので原因究明もうまくいかなかったりと。いうことがきっかけで、マイクロソフトもそろそろDevOpsに取り組まなければならないのかな、となったわけです。2010年から時間をかけて、いろんなひどいめに遇いながらも「SaaSプロバイダとしての学び」を得てきました。これをこのあと説明していきたいと思います。組織の変遷マイクロソフトの体制は、最初はウォーターフォールでした。Agileをやりました。やったときにはこういう体制でした。Mangementがありました。スプリントの後半だけしかQAが忙しくないとか、そういった事情もあり、まずDevとQAを一緒にして、Engineeringチームにしました。今度はEngineeringからOpsに渡してデプロイしてもらうのにも時間がかかるよねと。Mangementも一緒にして、Featureチームにしました。QAもDevもOpsもみんないて、1つのチームとして働いてもらう。このチームに権限も与えて、お客さんとも直接お話をして製品開発をがんばってねと。チームの自己組織化とエンタープライズとしての提携SaaSプロバイダとしての学びの1つ目は「チームの自己組織化とエンタープライズとしての提携」です。開発に携わっているひとは100人以上いて、国も5カ国ぐらいにまたがっているディストリビューテッド(分散した)チームです。Roomはオープンスペースで、すぐ話しかけられるようになっています。マイクロソフトは大きな組織ですが、実は小さなチームの集合体だと思ってください。3週間スプリントでリリースしています。僕はマイクロソフトに昨年の8月に入ったばかりなのですが、マイクロソフトはけっこうメール文化の会社でした。理由が最近なんとなくわかってきたのですが、Outlookで連係させるとめっちゃ便利なんです。スケジューラと連係したり、Skypeと連係させてクリックだけでSkypeで会議ができたり。左側はスプリントが始まったときのスプリントメール。右側はスプリントデモの日のメールで、デモの動画が見られます。いったやり方で、分散したチームでも連係してうまくやっていけると。技術的負債をマネジメントする次は「技術的負債をマネジメントする」。Services」には2つのバージョン、クラウド版とオンプレミス版があります。2つのコードベースは同じ1つのコードで、それぞれリリースブランチを複数持っているということになります。リリースのタイミングは異なっていて、クラウドバージョンは3週間に一回。オンプレミスの方は3カ月に1回です。原則として、テストは可能な限り低レベルで書く。Azureの開発に関わっている日本人に、Azureでシステムテストや受け入れテスト、負荷テストは自動化しているのか聞いたところ、もちろんぜんぶ自動化していると、じゃないとリリースに間に合わないと言っていました。Anywhereという、Javaで聞いたような原則があります。テストは手元のマシンでも、QAでも、本番環境でもどこでも動くように書きましょうと。それからプロダクトはテストが容易な設計にする。しないとテストの自動化ができないので、グローバルにリリースするプロダクトとして致命的になると。テストコードはオマケみたいに見られがちですが、テストもプロダクトコードとして考える。リファクタリングもしていらないコードは捨て、信頼できるコードだけを残す。ひどい目にあっているユーザーを追跡する次は「顧客価値のフロー」ですね。サービスにはSLA(サービスレベル契約)があって、可用性が何パーセントなどと決まっていて、そこを下回らないようにすると。マイクロソフトもいちばん最初はOutside-inのテストとして、外からPingを打ってサービスをチェックしていました。この方法はサービスが増えるとよく分からなくなります。次にやったのはコマンドのヘルス。コマンドとは機能のことで、ビルドとかワークアイテムの作成とか、そういうコマンドを実行してログをとっていた。これも機能が増えるとログに埋もれてわかりにくくなった。そこで最終的に到達したのは、アカウントごとの失敗、つまりユーザーがビルドに失敗しているとか、時間がかかりすぎているとか、そういうことを計測するようにした。すると顧客のインパクトをより身近に感じることができるようになった。いう段階を踏んで改善していきました。99.9%の可用性を達成しても、一方で0.1%に当たってひどい目にあっているユーザーがいて、その人に着目する。ひどい目にあっているユーザーさんを追跡して、コンタクトしてディスカッションして問題を解決する。「Redを抱擁せよ」と言います。いうことは、アジャイル開発だけのときにはやっていなかったことですね。2016「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(前編)。2016「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(後編)。2016厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る(前編)。2016厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る(後編)。「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(後編)。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Studioのロードマップを解説。「質とスピード」(後編)。「質とスピード」(前編)。2.7サポートを発表Google、Lookerの買収完了を発表。Enterprise、BtoBスタートアップ向け支援プログラムで無料提供と発表。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。