DevOps ハッカソンは日本で通用したのか？ 〜ハッカソン運営での学びと中の人〜
私は入社以来、月1回以上のペースで、DevOps ハッカソンという無料イベントを実施しています。
DevOps が学べて、関連技術を自由にハックして楽しめるイベントです。マイクロソフトが、DevOps を広く普及させて将来DevOps の良い事例になってくれるお客様を探すことを目的としています。マイクロソフトというとWindowsみたいなイメージがありますが、このハッカソンはそういった縛りはありません。Azureを使っていただくことと、 Visual Studio Team Services という Git / Kanban / Build(CI) / Release Management / Testingみたいなのが便利にできる SaaSサービスをちょっとだけでいいので使っていただくこと、DevOpsプラクティス (例えばInfrastructure as Code)をどんな技術を使ってもいいので、実装するという条件です。
だから、Linux でも、Docker でも HashiCorp でも技術は好きな物を使って楽しんでもらえればいいイベント になっています。もちろんMSのフルスタックで決めていただいても問題ありません。
実際何回も開催しているとだんだんとコツがわかってくるものです。Microsoftでは、NSATという顧客満足度の指標が あるのですが、この数値もFESTやde:codeの最高レベルぐらいの点数を稼ぐことができています。（もちろん、プレゼン とハッカソンという違いはあるので、一概に比較できませんが）きっと少なくとも、来ていただいた人には体感的にも とても喜んでいただいているようです。
正直に言うと、これは私の努力ではありません。私をサポートしてくれている人が素晴らしいのです。 だから日頃からの感謝を込めて、その内情を正直にお話させていただきます。
DevOps ハッカソン上陸の経緯
私がマイクロソフトに入社したのは、昨年の8月になります。入社した当時最も重要な私の仕事はこの DevOps ハッカソンでした。私は結構チャレンジャー体質かつ、不器用なので「失敗は学ぶチャンス！」と考えています。ですので、「もちろんやるよ〜」と上司に言いました。しかし、正直に言うと、上手くいく確信など何もありませんでした。「最初は失敗して学ぶかな」ぐらいに思っていました。
私の上司はフランスに住んでいるフランス人です。エンタープライズの技術者がメインのターゲットと言っていましたが、少なくとも当時は、日本のエンタープライズの人がハッカソンに参加してくれるイメージがありませんでした。もちろんイベントとしてはスタートアップ系の皆さんも大歓迎です。日本へDevOpsを広める為のイベントという目的がありますので、楽しんでいただければどなたでも大歓迎です。
当時、開催まで３週間ぐらいしかありませんでした。私はマイクロソフトに入りたてで、「Azure とか全然しらんしどうするんよ？そもそも集客大変ちゃうか？」と思っていました。しかし、なんでもやろうと思えばなんとかなるものです。
初回は David という向こうのトップの DevOps エバンジェリストが来てくれることになっていました。本来それは私にやり方を伝えるためなのですが、私たちは、彼がガチハンサムということもあり、「DevOps プリンス」と名前をつけて、「外タレきますよ！」的なノリで宣伝させていただいた。もちろん、個別で自分の知り合いに直接アタックして、DevOps 好きそうな人に声をかけました。
通常のMSのルートじゃない、connpass なども活用して、日英両方でアタックすることで、第一回はかなり盛況で終えることができました。
超絶優秀なマーケティングマネージャが活躍
実は私のポジション（米マイクロソフトのDevOpsエバンジェリスト) は「RG」と内部でよばれているポジションで、マイクロソフトがある技術に力を入れたいときに、３年ぐらい一時的にできるポジションです。過去には Azureのエバとして、尊敬する佐藤(NEO)直生さんや増渕大輔さんが、このポジションにいました。そういう重要なポジションなので、だからきっと凄く優秀な人をアサインしてくれたのだと思います。
今もDevOps のマーケティングは秋山さんという人が担当しています。初回から、今まで変わらず超優秀です。彼女はこのタイミングを逃さず、完璧にプレスの各社にリークをしてしっかり記事にすることをしかけました。
おかげさまで今回話題になっている de:code も彼女が活躍が裏にあります。さらに素晴らしいのが、この初回の成功を一瞬でシンプルで楽しめるレポートにまとめ、本社側のマーケティングやエバンジェリストに共有して、素晴らしい評価を受けたことです。 本社側は、日本市場は相当やりにくい場所と思っていたらしく、とても喜んでもらえたようでした。後に本社から、日本のDevOps ハッカソンはうまくいっているということで、視察が来ることになります。
simplearchitect.hatenablog.com
正直私はエバンジェリストとしては相当「ひよこちゃん」です。人前に出るから目立つけど、「アイコン」みたいなもので、実際の成功のエンジンは彼女なのです。彼女は、その他の細かい手配、アレンジなども完璧です。
視察に来た本社メンバと日本メンバ
ただ、一回目の課題としては、Azure や Visual Sutdio Team Services のセットアップで、混乱し、初日のハックがスムースにいかなかったことがありました。
第二回目からが勝負のタイミング
私は１回目は David がきてくれるのだから、集客さえできればある程度上手くいくのは当然と思っていました。問題は二回目です。 1回目はエッジな人が来てくれました。ですので、ハッカソンという形態も大丈夫でしたが、2回目からはそうとは限りません。
いろいろなレベルの人が来てくれる。そして、Davidはいない。MS入社２ヶ月の私は対応できるだろうか？
私はアジャイルコンサルタントだったので、DevOps のプロセスや考え方、プラクティスに関しては得意分野です。そして、OSSのIaCも大丈夫なところ。問題は、Azure や Visual Studio Team Services だ。さすがにマスターするには時間はありませんでした。
もちろん、自分でデモを作ったり、ランスルーをしてみたりはしているが、ハックを支援できるほどできるだろうか？
ここでも、先の秋山氏がファインプレーを見せました。彼女は、ハッカソンの立案をするだけではなく、他のテクニカルエバンジェリストに適切に助けを求めるだけではなく、ハッカソンごとに、誰が支援するかのアレンジを行って、支援が薄いところは、調整をして、適切なサポートを得られるようにしてくれた。もちろん会場の手配も同じだ。むっちゃ美味しいお弁当や、お菓子もしっかり用意して、みんなが楽しめる雰囲気を巧みに演出してくれました。
無限の守備範囲を持つ神エバンジェリストが支援
私は DevOps といっても、プロセスが最も強く、技術力はスーパー高くない。技術は アジャイル系技術、IaC やコンテナなどの技術は得意な方ですが、ITPro系は経験がありません。（私の所属はITPro - Japanなのだがw) DevOps 系の技術に強いエバといえば高添さんが有名だが、彼はご存知の通り超絶売れっ子です。どうしたものか、、、と考えていたら、秋山さんがまたもやファインプレーをして、エバンジェリストの小塚さんをこのタスクにアサインしてくれました。
吉田パクえさんと小塚さん
彼ははっきり言って超絶優秀。そして無限の守備範囲。VSTSから、Azure、OSのディープなところから、Azure Stack、コンテナ、PowerBI、Office 思いつく限り殆どの分野をカバーする超人なのだ。(ちなみに、たくさんできるが本人は、OSとかのディープな部分が好きらしい。高添さんがやっている分野をやってるのが楽しそう。彼は高添さんのサポートと兼務) 実際、彼は優秀すぎて、いろんなエバンジェリストから引っ張りだこになってしまうので、秋山さんがいろんなエバから要求される彼のアサインをブロックしていた。
彼の才能はそれだけではなく、こういったイベントの運営も完璧なプロフェッショナル。彼はパフォーマンスネックあったときのために、予備のWifiを準備していたり、初回に混乱を招いたVSTS/Azureの導入手順、審査のためのプレゼンテーションのテンプレートから、会場の案内まで完璧にこなした。正直雑な私では到底できないことだ。彼の才能は神がかっている。
DevOps T-シャツ登場
さらに、このイベントを盛り上げるべく、秋山さんが、密かに発注してたのが、DevOps T-シャツだ。背面の毛筆は書道家の友人に書いてもらったらしい。DevとOps が協力して、ソフトウェアのライフサイクルを改善するDevOpsのコンセプトのごとく、DevとOpsのT-シャツを作成した。これはとても喜んでもらえて、海外の同僚もとても羨ましがっている様子だった！参加者はこのDevOps T-シャツがもらえることになっている（現在のところ。在庫切れ後は秋山さんのアイデア次第w）このハッカソンのあと、ハックフェストという別イベントをやったときもわざわざ来てくれて人もいてなかなか嬉しいものだ。
エンタープライズにハッカソンは通用したか？
私が得意のプロセス、プラクティス、アジャイル系技術のデモを行い、秋山さんが私の足りない技術を持ったエバンジェリストを集め、小塚さんが、最高の運営と、高度な技術で参加者の皆さんの問題をガンガンに解決していった。やはり想定した通り特にエンタープライズ系やSI系の方はハッカソンが初めてで、参加に躊躇したとおっしゃっておられる方多くいました。
ハッカソンはすごい技術力が無いと来れないみたいなイメージがあります。
しかし、終わってみると、殆どの方は、「来て良かった」「楽しかった」と言っていただけてほっと一安心です。さすがに、プログラミングが出来る、もしくは、インフラ構築や運用したことがあるとか、そういう基礎的なスキルは必要ですが、エッジでないと楽しめないとかではないので、お気軽に参加されたら楽しんでいただけると思います。
エッジな方はエッジな方で、いろいろな技術をハックできて楽しんでいただけている様子です。大体チームは、毎回マイクロソフト系と、オープンソース系のチームが半々ぐらいになることが多くて、秋山さんのファインプレーもあり、DevとOps を別サイトで募集しているので、Devが8割何てことはこのハッカソンに関しては存在しません。だから、どのチームも、DevとOps が一緒のチームになります。だから、普段体験でき無い、DevとOpsが一緒になって一つのチームでコミュニケーションをとりながら作業をするという体験が得られて喜んでいただけている様子です。 技術に関してもOSSだとDockerやChef、DockerCloud、Jenkins、Slack + Hubot などは人気が高いです。中にはMesosやAzure Container Servicesを実施した人もいます。MS系で固めるチームは、.NET - VSTS - WebApps - SQL serviceの構成で、CI / CD / Release Management を決めて、さらに PowerBI や Application Insight で可視化して、Iacは、 Azure Resource Manager を使ってキメるというパターンが多くありました。
いつもびっくりしますが、たった二日で、CI / CD / Release Management までがっつり自動化したり、ブルーグリーン やロールバックを実装したり、負荷テストを決めたり、監視までうまく回したり、いつもびっくりさせられます。レベルは関係なく 皆さん、みなさんになりに役割分担して、楽しんでいただけているようです。日本でハッカソンなんてできるだろうか？と 思っていましたが、本当にやってみて良かったです。
先日福岡のチームは、このハッカソンで作ったソリューション（Minecraft のサーバーをプロビジョンするサービス）を立ち上げて、GitHub に公開してくれました。そして、このチームは、Dev x Ops だけではなく、デザイナーもいました。もちろん優勝です。
尚、このハッカソンでは、商品のためにハックして欲しくないので、優勝チームは決めますが特に豪華景品はありません。弁当は美味しいですが。
### DevOps ハッカソンの効能
観察してみると、通常のプレゼンテーションやハンズオンと比べて、ハッカソンはどういう効果があるでしょうか？実はマイクロソフト の社内の教育でも、近年では必ずハッカソンのイベントがあります。私も社内イベントがあるのですが、そこでもハッカソンに参加して きました。マイクロソフトでは、スキルレベルを四段階に定義しています。100, 200, 300, 400 のレベルです。100は知ってるレベル 200 は使えるレベル、300 はコードを含む深いレベル 400 がハッカソン主催とかのレベルです。社内のハッカソンに出れば、自動的に その分野で200のレベルを獲得することができます。
Redmond で行われた MS 社内ハッカソンの様子
何かの技術を習得したいときに、プレゼンだけだと、聞いて満足して終わりというパターンが多いでしょう。デモを見てもある意味わかったきになるだけで、実際にできるとは別問題です。その点ハンズオンはいい感じですが、「失敗」がないので理解が浅くてもなんとかなります。
ハッカソンは違います。明確なゴールや目的があり、最初から「応用」を目指して考える必要があります。だから、理解せずできるものではありません。そしていいのは必ず、チームメートがいますし、エバンジェリストやスペシャルゲストがいるので「聞ける」のです。
しかも、懇切丁寧に教えてくれたり、一緒にペアプログラミングまでしてくれたりもします。
何かをマスターするときに、達人の人に聞いて、一緒にやることほど最速で本質がわかる方法はありません。自分で実感していますが、これは最強です。
私も昔は教育コースに出たら分厚い資料をもらってありがたがっていましたが、今から考えると、それを見返すことはどれぐらいあったかな？と思います。自分が「実際できるようになる」ことこそが最高の宝だと思います！そして、何より技術ハックが楽しいものだ！とうまくいってもうまくいかなくても、新しい技術に触れたり試せたり、それをディスカッションするのは最高に楽しいことですね！ ちなみに、主催する側も空き時間が発生するケースがあって、その時はハックを楽しんでいます。もちろん質問があって、参加者の皆さんとハックするのも非常に楽しいですし、勉強にもなっています。本番で対面する「課題」は、決してハンズオンでは体験できません！
それ以外にも、DevOps という要素が大きいです。DevOps という概念は、ソフトウェアライフサイクルの改善を実施するので、範囲が大変広いのです。それとプラクティス、ツール、マインドセットまであるので、これを座学で学ぶのは相当難しいでしょう。しかし、ハッカソンなら概念を理解したのち、本番に程なく近い状態で体験できます。そのため、かなり効率よく理解できると思います。当初は懐疑的でしたが私も、ハッカソンは日本でも、エンタープライズ系でも有効という確信が得られました。
DevOps で使われるツールセット。多すぎっす
後はどうやってみんなに知ってもらうかが課題です。このブログポストもその一つの手段です。無料ですし、マイクロソフトのロックインもないですし、DevOps を広める楽しいものですので、是非広めるのにご協力いただければと思います。
DevOps ハッカソンの改善
実は安定したハッカソンを提供できるためには、いろいろ施策を打っています。秋山さん、小塚さんが完璧に支援してくれていることもありますが、私たちは毎回振り返りをして、改善点と解決策を考えたり、いろいろ手を変え品を変えて、A/Bテストみたいなことをやったりもしています。休日に開催してみたり、平日にしてみたり、品川のマイクロソフトでやってみたり、渋谷の.dots でやってみたり、Java User Groupでやってみたり、ゲストを呼んでみたり。様々です。私のパートも、一人でやったり、小塚さんと分担してみたり、ゲストを加えてみたりと様々なトライをして、その実践から学んで改善をかけています。
大きな傾向としては、平日はよりエンタープライズ色が濃くなる傾向にあるようです。休日の場合の方はオープンソース色、サービス、スタートアップ色が若干濃くなります。ただし、これは、色という程度で、味見程度です。 地方は、大阪、福岡、札幌と実施しましたが、集客に苦労しました。来ていただいた皆さんには楽しんでいただいたようですが、今後も継続して開催するためには、どのように地方で集客するかは大きな課題です。やはり、「ハッカソン」というハードルがまだ高いのかもしれません。
このままでは、地方開催は福岡を除いて厳しい状況になるかもしれません。是非いいアイデアや、ご支援などありましたらコメントいただければと思います。
DevOps ハッカソンの満足度を高めるポイント
さて、様々なテストや試行を繰り返して、現在のところの DevOps ハッカソンの満足度をあげる為の必殺パターンを共有させていただきます。 コンテンツはもちろんあるのですが、「安定した運営」です。DevOps だとネットワークの帯域を消費しますので、しょぼいWifi環境だと相当ストレスになります。ですので、Wifiの帯域はかなり気を使っています。Azure のセットアップや、VSTSのセットアップで、苦労すると、本来のハックが楽しめません。そういう部分をスムースにするのも大変重要です。
次に、オーバービューと、具体的な技術の解説の両方という要素があります。私がするトークやデモはあくまでDevOps の概念やプラクティスを理解するためのオーバービューになっています。それだけにしてしまうと、満足度が落ちることがわかりました。私と小塚さんで２人で担当して同じことをしても、私一人でやる時よりスコアは良い傾向にありました。そこで、１人より２人でやる方がいいことを学びました。
何回か実施して観察してみると特定の回の満足度が高いことがわかりました。それは概要をお話したのち、何か一つのとんがった技術を解説するスペシャルセッションを設けた回が常に非常に高い満足度を得ていることがわかりました。
それをヒントに今は、概要と、詳細の技術を解説したスペシャルセッションを実施する形態にしています。その学びを得た後は毎回満足度が高い状態をキープできています。ちなみにスペシャルゲストがいた回の内訳は次のようになっています。
おそらく、DevOps の場合、概念だけだと、ふわっとしていますし、技術だけだと、腹落ち感がないので、両方をうまくミックスさせて、概念、オーバービューと、詳細な尖った面白い技術 というコンビネーションが良いようです。
- Jug CCC スペシャル: Java エバンジェリスト 寺田が、JenkinsやDocker / Tutum を解説
- Dockerスペシャル : 吉田パクえさんがDocker解説そして、真壁さんと共にサポート
- Chefスペシャル : Chef社から Andrewが来日して通訳付きで、解説とサポート
- Doker / HashiCorpスペシャル: Creationline社の前佛さんが Docker やHashiCorpの解説とサポート
- 地方開催スペシャル : 自動化マスター安納さん、松崎さんのコンビでARM解説とサポート
一般的なプレゼンテーションやハンズオンに比べてスコアが高いのは、秋山さんの努力があり、スペシャルゲスト以外にもテクニカルエバンジェリストが合計４名ほどいる分厚いサポート体制が効いていると思います。そして、何より「ハック」を自分で実施する楽しさが大きいと思います。
自分でハックして、むっちゃ詳しい人に簡単に聞けるのは本当に楽しいことです。それは、チーム内でもあり、サポート陣でもあります。普段交流をあまりしない Dev / Ops そして、他の会社の皆さんと交流するのもいろいろ刺激があって楽しいのかもしれません。
Ruby好きのOSSエンジニアがAzureアーキテクトになった理由 - ZDNet Japanより
スペシャルの回も、吉田パクえさんの回が非常にスコアが高かったため、そこからいろいろ学ばせていただいて、その後の運営に多大な影響を与えてもらっています。
ちなみに、スペシャルの回であっても、それと違う技術でハックしてもまったく問題ないので、MS系技術の人でも、OSS系技術の人でも皆さん楽しんでいただけます。
この DevOps ハッカソンは上記でお話した通り、いろんな皆さんのおかげで非常に高い満足度をいただいています。私はほんま踊ってる程度なのですが、運営の裏でこんなたくさんの人が活躍していただいているのです。
次回以降のアイデアベースのお話。
５月に関しては、DevOps ハッカソンは実施しません。de:code に集中させていただきます。de:code ではDevOps系の 強烈ゲストと、それに対抗するMS技術のDevOpsを楽しんでいただきます。
６月以降のアイデアですが、次のような思いつきがあります。どれをやるか決めていません。是非これ実現してほしい！というのがありましたら、是非ともお気軽にコメントいただければと思います！ では、今後とも、DevOps ハッカソン １ヶ月に１回ペースで実施していきますので、よろしくお願いいたします！ ちなみに、ここで書いていあるのはジャストアイデアであり、本人たちにもまだ開催可能か聞いていませんw ですが、コメントがいろいろつけば、その後押しになるような気がします。
- マイクロサービス監訳 佐藤(NEO) 直生氏をゲストにした「マイクロサービス」スペシャル！
- Xamarin エバンジェリスト兼漫画家 ちょまど氏をゲストにした Xamarin Mobile DevOps スペシャル！
- 高添・小塚ペア Windows コンテナ / Service Fabric スペシャル！
- Docker 日本唯一の公認トレーナー 前佛氏をゲストにした「Docker / HashiCorp」 スペシャル！
- 高添・小塚・安納・前佛さん Ops技術中心！ DevOps スペシャル （OSS、MSの両方のOps技術にフォーカスを当てた回）
- 安納・松崎ペア ARM自動化＆MS技術でDevOps スペシャル！
- Microsoft Bot Framework x Cortana スペシャル! ChatOps の先を行け！
- Microsoft IoT x DevOps スペシャル！
などなど、他にこんなのしてほしいとかありましたら是非ともコメントいただければと思います！
次回の 4/15,16 DevOps ハッカソン
折角なので次回の宣伝をさせてください。次回は 4/15, 16 の金土どいう新たなパターンで実施させていただきます。必勝パターンに則って、今回も「Chefスペシャル」と銘打ってお届けします。Chef を日本にインストールしてきた問いっても過言ではないクリエーションラインさんがその中でも特にスペシャリストである荒井さんがきてお話をしてくれます。しかも、緊急参戦で、Chef社からAlex Vinyar氏が参戦してくれます。彼がサポートした顧客は、IBM, GE, HP, Rakuten, Yahoo, Bloomberg といった超一流どころばかり。これはChef に興味がある人はこんな機会は滅多にないかと思われます。また、Chef x Azure の組み合わせに興味がある人も見逃せない回になりそうですね！
今回も凄いゲストが参戦していただいて、本当に嬉しいです！
Alex Vinyar
I am an Automation Consultant with Chef (Opscode). I help companies get started with the DevOps journey by working with management team to create a roadmap, assessing current state of the organizaton and DevOps readiness, and leading teams in the early stages of implementation. Presently I am in Japan until August to supporting Chef in the APAC region. Some of the companies I've helped: GE Capital,HP,IBM,Microsoft,Rakuten,Yahoo,Walgreens,Bloomberg,etc.
荒井 裕貴
クリエーションライン株式会社のChefエンジニア 前職ではネットワークの運用保守業務をしながら、ネットワークの管理自動化WEBシステムの開発等を行っていた。 クリエーションラインではChefを担当しており、コミュニティーでの講演やChefのトレーニング、COOKBOOK開発等を行っている。 趣味はガンプラと熱帯魚。
「Be Lazy」を極めるためには残業をしてはいけない
「Be Lazy」というのは、日本側の上司にあたる Drew がいつも口にしている言葉だ。その意味合いは、「最小の工数で、最大のインパクトを出す」 という考え方だ。私もアジャイルやリーンを学んできたので、「大量のものを高速に作れること」はむしろ悪であり、いかに「作らなくていいか」を考えてインパクトの出るものにエネルギーをフォーカスするのが重要と思っている。
しかし、正直に言うと、それは、日本人の感覚からいうと最も縁遠い感覚だ。私がなぜ「Be Lazy」を極めたいと思っているか？というと、インターナショナル チームの同僚は仕事で成果をガッツリ出すのも尊敬に値するが、仕事をしている様子も実に楽しそうだ。誰も苦しそうだったり、我慢したりしていない。
仕事は楽しむものと言っていて、「我慢するべきもの」という日本側の空気とは相当違う。私は自分も人生や仕事を楽しみたいし、多くの人がそうなったらいいのにな！と思うので、その謎を解明したいのだ。
私は今もBe Lazy」を身につけるため試行錯誤しているが、気づいた内容をシェアしていきたい。
Be Lazy 思考を感じた出来事
少し前のエントリで、「日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む」というエントリを書いた。ここで、海外の人は、すごく沢山の仕事をこなしているわけではなく、そもそもこなしている物量が少ないという話を書いた。 インターナショナルチームで仕事をするときは、同じ仕事をするにしても、日本と比べて物量が圧倒的に少ない。レポートもそうだし、報告会もそうだそもそも、報告会自体あったっけ？という感じだ。
simplearchitect.hatenablog.com
この前も「Be Lazy」思考の良い事例があった。あるお客様のところで、私の専門外のハンズオンを英語で実施することになった。私はDrewに依頼して、ハンズオンを実施してくれる人を探した。どうやらオーストラリアかどこかにいている人がやってくれるということになった。 彼は私がリクエストをすると、さっとハンズオンの大枠を決めてくれて、ハンズオンの素晴らしいマテリアルを提供するよと行ってきた。その後、彼は「たった半日のために日本に来れない」という話になったので、私はその「素晴らしい」マテリアルをくれ無いか？と言った。私は「さぞかし素晴らしいパワーポイントが送られてくるんだろう」と思ったのだが、実際送られてきたのは、誰でも読める、AzureのWebサイトにあるハンズオンのURLだった。
きっと日本人だったら、ハンズオンのしっかりしたパワーポイントを作って、事前にGitHub にサンプルを作って上げて、、、とかやってしまいそうだが 彼がやったことは、メールを１本書いただけだ。多分ハンズオンも彼が作ったものですらないだろう。
同時に彼のものでは無いが、神と呼ばれる素晴らしい技術力を持った同僚の佐藤さんがより素晴らしいHoLのURLを教えてくれた。それをそのままお客様にお伝えすると、お客様はすごく喜んでいた。「内容も素晴らしいし、これをいただけたら、事前にみんなにシェアできる！」
今回のお客様はかなりインターナショナルなお客様なので、日本人的な感覚が無いからだと思われるが、これこそ、Be Lazy な仕事のやり方だと思う。
丁寧な仕事がさらなる無駄を生成する
もし、私がそのチュートリアルを見ながら解説を加えて、パワーポイントを作り、、、ということをしていたら私の工数が大量にかかっただけではなく、お客様も直前にならないと、パワーポイントを入手できないので事前にみんなにシェア出来なかっただろう。しかも、上記であげたURLは、沢山のハンズオンが載っているので、簡単で退屈ならAdvanceなものも実施できる。パワーポイント化していたら、そこまでは手が回らないだろう。それどころか、Azure がバージョンアップしたら、そのパワポを修正する工数が発生してしまう。これは相当無駄だ。
私を含めた日本人は、どうしても「献上先」の工数を削減しようと頑張って、自分たちが時間をかけて頑張る傾向にある。しかし、それは、本当に「価値」を向上させているアクティビティだろうか？
日本人での Be Lazy 事例
こういうのはお客様が特殊だからできることだろう？と思うかもしれ無いが、私は前々職の大手SIerに所属しているときに完璧にこの思考を持った人がいた。 彼は、本当に優秀なのだが、ガチで１７時に帰って、飲みに行くのだ。残業はよっぽどのことが無い限りしない。しかし、私は彼が仕事は人３倍ぐらいこなしているように感じた。そして、彼がプロジェクトをやって炎上させたのを見たことがない。ウォータフォールなのに。私はアジャイラーだが、彼ならウォータフォールをやっててもなんの文句も言えない。完璧だ。必要が無い。
彼がそうできる理由は「多分むっちゃ優秀なんやろうな」と思っていた。私は最近になってようやく手がかりが見えた気がしてきた。
そんなときふと気がついた。そういえば、Drew もまったく残業しない。もしかして、、、
残業が生産性を破壊している
「Be Lazy を実践したければ残業をしてはいけないのではないだろうか？」という仮説が頭に浮かんだ。私たち日本人だと、「Be Lazy」のコンセプトを素晴らしく感じて、一度は残業はし無いようにしようと思うとする。しかし、１７時の時点になって、自分が思った仕事ができていなければ、「今日のバリューが出ていないので、それが終わるまではやり遂げて帰ろう」と思う人が多いと思う。私は少なくともそうだった。
私は過去にもこういうトライをしてみて、何回も結局残業している。「私は効率が悪いので仕方が無い。」と思っていた。結局ズルズルと、残業、休日での作業をガッツリしてしまうことになって元に戻るというのを繰り返してきた。
これを、もし、定時が１７時なら、１７時に帰ろうとすると、どうなるだろう？と考えると、１７時でバチっと終ざるを得なければ、現状だと多分１７時にはすごく中途半端に仕事が残るだろう。しかし、これで安易に残業するのは良く無い。残業をしてこなせてしまったら、「やっぱり俺は効率悪いなー。」で終了する。つまり、本当の問題を隠してしまうのだ。
強制的に定時に帰ることが生み出す効果
強制的に、１７時に帰るとして、家に帰っても仕事をし無いと決めてみるとどうなるかというと、相当気持ち悪い気分で変えることになる。次の日もまた想定したよりもバリューが出ない。するとどうなるかというと、「工夫」を始めるのだ。
よくよく考えたら、自分は会社に出てから、やろうと思った作業にフォーカスしているか？というとそこまで集中していないし、余分なことも随分やっていることに気づく。時間を固定して今日こそ想定したバリューを時間内に出そう！とガチで考えるようになる。物量ではなく、バリューなら時間内で出来るはず、もしくは、自分のバリューに対する見積もりが甘いことになる。残業や休日の安易な作業は、そういう点を覆い隠してしまって、問題が発覚しない。そしたら、次も安易に残業、休日でカバーする。それでは、いつまでたっても、定時に帰るなど出来るはずがないのだ。
先にすべきは「定時に帰り始める」ことだったのだ。私たちは、どうやったら最小の工数でバリューを最大化出来るのだろうか？
「努力」ではなく「楽にできる仕組みづくり」
そう考えて、「文化の違い」を理解すべく話題の厚切りジェィソン氏の本を読んでみたりした。彼の考えはすごく腹落ちする。違和感が無い。そのいろんな考えの中でも素晴らしいいものがあった。彼が何かを身に付けたい時は、絶対に出来る程度の簡単さにして継続するというテクニックだった。例えば、大抵の人は単語を覚える時に、毎日一時間やりとげようと大きな努力目標を掲げる。ところがそれは続かない。だから、もっと、楽勝でできるレベルに落とし込む。 例えば、５分でいいから毎日単語を覚えるなどだ。こういう0.1%向上させるちょっとした努力を続けていると、1年では、44％スキルアップする。
私を含む日本人は、大抵「努力、頑張る」に持っていく傾向がある。しかし、彼らと付き合っていると、「努力」とか「頑張る」とかいうのがなく「楽しむ」とか「幸せになる」「ロジカル」ということしか頭に無い感がある。よくよく考えると、努力とか、頑張るということは、美しいけど、無理をしていることを意味する。
Be Lazy の具体的実践方法と考え方
もちろん、私は当初想定のバリューが達成できず、すごく居心地が悪い気分になっているが、上記の気づきにある程度の確信があったので、定時帰りを継続していた。 そうした時に、尊敬する同僚の大田さんと、「Be Lazy」に関するディスカッションをした。その時彼が私に教えてくれた本が決定的だった。
「エッセンシャル思考 最小の時間で成果を最大にする」という書籍だ。この本は、まさにどうやって「Be Lazy」を実践するかの答えと意義を教えてくれる素晴らしい名著だった。是非みなさんも手にとっていただきたいのだが、大きなポイントは次の通りだ。
- 大抵のタスクはノイズ。本当に実施すべきものは本当に少ない。
- 自分にとって重要なことを考えて、今、本当にすべき仕事を１つだけ選んで実施する。
- 他人のではなく、自分の人生を生きる。それを明確にして、依頼を断る。
書籍は素晴らしく、是非読んでもらいたいので、これ以上はかかないが、これだけでも相当なバリューが出るようになるはずだ。結局価値の高い仕事は物量をこなすことでは無い。こなすことが少ないから、価値の高い仕事に集中してできるのだ。何故なら大抵のタスクはノイズにすぎないから。
そういえば、私の前々職の上司も、しょっちゅう仕事を断っていた。しかし、受けた仕事は黄金の輝きを放つぐらいにうまくやっていた。しかも、定時帰りで。
Be Lazy の文化を育てる
この本を教えてくれた大田さんと、「Be Lazy」についてディスカッションしたときに、お互いの、もしくは、同僚の素晴らしい「Be Lazy」事例を交換しあって、「すごいな、素晴らしいな！」と感心し合った。
きっとこの会話を聞いたら、眉をしかめる人もいるかもしれない。努力や頑張りの匂いがゼロで楽をしているように感じるからだ。でも楽をすることは本当に素晴らしいことで、それが、生産性を高めて、インパクトあることに注力できることになる。スラック（余裕）が生まれるから変化にも対応できる。
時間ではなく、インパクトについて一生懸命考えるので、だらだらと今のやり方をやるより、ずっと真剣にバリューを考えるようになる… などいいことづくめだ。
この方法は、USの人々の方が、日本よりずっと文化的に導入が楽なのだろう。だから、私のインターナショナルチームの同僚はほぼこういう考え方をしていることに気づく。
日本の価値観と、Be Lazy のコンフリクト
日本だと、このやり方が賞賛される職場はまだ少ない気がする。残業をしている同僚を横目に変えるのも気がひけるだろう。でも負けてはいけない。 もし、できたとしても日本人だったら、 Be Lazy を実施して、少ない工数で、インパクトが出せるようになったら、さらに残業したらもっと成果が出せると思うかもしれない。残念ながらそうではない。無理をするのは、結局「安定しない」し「リスク」が高い。人々が健康で、楽しんで仕事をするのが最も生産性が高いし、持続可能性が高い。
どうも、日本だと、プロジェクトのストーリも「楽」にできたものは賞賛されず、根性とか、超人的な努力で達成したものの方がもてはやされる。 頑張った方がもてはやされるが、実際は、すごいバリューのあることを「楽に」できるような仕組みと工夫を無理なく、一歩一歩重ねる方が、中長期的にみるとよっぽど生産的だと思う。少なくともロジカルだ。
私はどうも昔から気になっていることがある。歴史的に日本は最初は相手を圧倒するのだが、だんだん息切れして、そのうち逆転されてしまう。という展開が昔からすごく多い気がする。本来日本人は優秀な人が多いと思うのだ。ほんまちょっとした考え方で相当損をしている気がする。
おわりに
私はこのやり方をしばらく続けて、Drew に「お前も Be Lazyがうまくなったな！」と言ってもらえるように自分も楽しんでみたい。幸い私の職場はこういうことには理解がある。もし、そうでない環境の方も、私の前々職の上司の例もあるので、トライしてみてはいかがだろうか？あなたが上司ならこういう考えを気に入ってもらえたら広めてみたらどうだろうか？
彼はしょっちゅう仕事を断っていたが、みんなは素晴らしい仕事っぷりに誰も文句をいうどころか尊敬していた。でも、その秘密はきっと「Be Lazy」の思考を彼がマスターしていたからではないか？と思う。多くの物量の仕事をこなしていたら価値の高くインパクトのある仕事はできないのだ。
それよりももっと重要なことは、他人の目よりも、自分の幸せ、そして、自分がお客さんにとっていい仕事をすることが自分にとっては重要だ。だから継続して仮説検証をつづけていきたい。
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。
2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw
Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002
日本はアジャイルの導入がこれからという噂を聞いたけど本当？
これは、私がマイクロソフトの面接の時に、当時の面接官に言われたことだ。何故、彼がこのような質問をしたのか、今の自分にはわかるようになった。私のポジションは、そもそも誕生するかどうかが未定だった。世界で幾つかの国だけオープンするというポジションだったからだ。だから、人を面接して、可能性のある国に DevOps エバンジェリストのインターナショナルポジションをオープンする予定だったらしい。当時は「日本」にDevOps エバンジェリストを配置するか未定だった。私は当時
残念ながらその通り。特にエンタープライズではほんの少しだけ。スタートアップだと導入しているところは多いけど
と正直に答えた。ただし、こういう事も言ってみた。
私はDockerとか、Chef とかMesos とか触っているけど、正直現状での技術力はしょぼいものだ。だけと日本の文化を知っているし、日本、特にエンタープライズマーケットへのアジャイルとか、DevOpsの導入にかけては誰にも負けない。
それが良かったのかどうかわからないが、なんとかこのポジションを獲得する事が出来た。自分は正直しょぼくて何もできない人間だけど、この事とDevOps に関するパッションだけは自信がある。元々ダメ元でのチャレンジだったが、何ヶ月か活動をさせてもらって、上司から直接会った時にいいコメントをいただけるようになった。
彼はこんな事を言ってくれた。正直今思い出しても泣きそうだ。自分が過去にこんなに必要としてもら事は無かったからだ。
私たちは日本のマーケットではいろいろ頑張ってきたけど、本当に、何回も惨めに失敗してきた。実際に現地に行った人間からも、新しい技術の導入が遅すぎるとか、アジャイルすらも導入されてないから無理だよとか。だから諦めようという意見もたくさんあったんだけど、僕は、正しいアプローチをしたらきっといけるって言ってきたんだ。Tsuyoshi が入ってくれて、それが本当だという事を証明してくれた。本当にありがとう。
私は人生であまり褒められた事がないけど、こんなに褒めてもらえたのは多分人生で初めてだと思うので、これだけはちょっとだけ自慢を許して欲しい。いままでの人生はずっと仕事も勉強もできなかった。ずっと「できない奴」「変わった奴」というレッテルで正直あまり社会で必要とされた事も少なかった。自分で１人会社をやってたアジャイルコンサルの時以外は。
世界からは日本はもはやマーケットとして見られていない
このエピソードを書いたのは理由がある。今回 de:code でクリエーションラインさんやマイクロソフトの仲間のおかげで目も眩むほどの著名スピーカーが集まってくれた。でも、残念ながらリソースが不足してお断りされたところもあった。その理由は何かと言うと、「日本のマーケットはビジネスとして価値が高くないから」という事が背景にあるようだった。マーケットの規模は大きいし、ダウンロード数も多いんだけど、「ビジネス」にならないという事のようだ。アジャイルや DevOps などの新しい考え方やクラウドなどのテクノロジーの日本への導入について楽天の川口氏に聞くと「USから３年遅れぐらいで日本にやってくる」感じらしい。
simplearchitect.hatenablog.com
USの状況を見て観察すると、日本の場合、最初に飛びつく層のスピードはUSとそんなに変わらない。その後USでは徐々に本番で使い始めるのに対して、日本はレイトマジョリティぐらいの間までずっとキャズムの谷が続く。世界的に多くの人が使うようになってからやっと企業が導入し始める。リスクがあるとかなんとか言って。これでは世界で勝てるはずがないし、先進テクノロジーの会社が「商売にならない」とそっぽを向いてしまうのも致し方がない。
実際、日本のエンタープライズ系大手企業から出たサービスが世界的に有名になっている例はあるのだろうか？正直にいうと、米国と比べると、日本のソフトウェア産業は足元にも及ばないというのが正直なところだ。
「現場」導入の違い
特にエンタープライズ系の技術導入は本当に悲惨なものがある。１０年ぐらい続いてるイギリスの会社の人と喋った時の事だ。彼らの会社は特に技術に尖った会社ではない。だけど話をすると、アジャイルは当たり前で、受入テスト駆動開発のようなプラクティスももちろん実施済みで、その課題に関しても語っていた。アジャイルの概念も話をした限り、誤解している箇所は一つもなかった。
一方日本のエンタープライズ企業と話をすると、アジャイルもまだ。クラウドもインスタンスを立てるために申請書が必要で３営業日かかる。DevOps に関しても、DevOps を導入しているといいつつバージョン管理しかやってない等、本質を理解していないベンダーに騙されているようなケースも多く見受けられる。 せっかく新しい考えや技術を導入しても、勘違いされて導入される事も非常に多い。昔、「アジャイルを実現するパッケージ」というパッケージのレビューに呼ばれた事があった。プログラマのレベルが低くても、業務をよく知っている人が業務フローさえ書けばアプリができるというものだった。これは、少なくとも「アジャイル」とは真逆の方向性と言ってもいい。他にもドキュメント体系や進め方がウォータフォールのままでアジャイルをやって「使えないよね」と言っている人も多く見かけた。それは当たり前だろう。そして、多くの人は進化型設計と呼ばれるアジャイルの設計方法に関しても理解も試しもしていない様子だった。
当初の日本へのアジャイル導入アプローチ
いろいろ調べてみると、日本と米国は文化も違うし、「SIer 中心」 vs 「内製中心」の違いがある。だから、最初は日本の文化の中で最大限に、アジャイルの良さを引き出せるアプローチを考え続けていた。どうやったら、アジャイルの本質を掴んだまま、日本の請負発注形式や、品質監査などに対応できるだろうか？実際にそのアプローチでやることにより、従来のウォータフォール型よりずっと成果を出すことができた。しかし、請負発注や、正直、アジャイルにおいては意味のないような品質監査に適応することで、本来のアジャイルの実力を引き出せたとは言えなかった。
その時に技術的な気づきがあった。アジャイルをうまく回そうと思ったら技術的にはユニットテストを適切に書けて、進化型設計ができる必要がある。これはアジャイルの本にはあまり書いていないが、「オブジェクト指向プログラミング」が暗黙の前提になっている。SmalltalkやJava なのだから、オブジェクト指向は普通だろうというわけである。しかし、実際、当時の日本の企業で、オブジェクト指向プログラミングが出来ていることは稀だった。だから私は工夫してオブジェクト指向プログラミングの気づきを得るための「オブジェクト脳のつくり方」という本を書いてみたり、「オブジェクトゲーム」という手法を考案して、日本でいままでCOBOLとかでプログラミングをしていた人でも、オブジェクト指向のテスト駆動開発や進化型設計の世界に入れるような工夫を考えて実行していった。実際これは大変うまくいった。アジャイルの本には書いていないけど、暗黙の前提になっている知識を保管することで、技術的には、アジャイルを回せるような、「はしご」を設置することができた。
第二世代アジャイル時代のアプローチ
私はしばらくアジャイルの世界から離れて「要求開発」を学んでいた。アジャイルをやっていて、技術的なサイドをうまく回せる技術がつくと、次の課題は「ストーリがうまく出せない」ということが発生するからだ。また、日本の商習慣的にプログラマは権力をもたせてもらえないので、「超上流」とかに行く方が、よっぽどうまくソフトウェア開発をいい方向に持っていけると考えて、その技術を学び実践した。そうしている間に、第二世代のアジャイルブームがやってきた。Scrum の登場だ。この世代で出てきた素晴らしいエンタープライズ企業の中には「準委任契約」にチャレンジする企業が生まれた。 自分のところでリスクをかぶって、アジャイルが生む本当のビジネス価値を取ろうという素晴らしい企業だ。今も多くないと思うが、そんなエンタープライズ企業が生まれてきた。 そんな企業を支援していると、まだまだ面倒なところはあるにせよ、第一世代の請負時代よりずっとアジャイルの本当のパワーを引き出せるようになってきた。しかも、いつもネックになっていたストーリの部分を要求開発やユーザエクスペリエンス、プロダクトオーナーの技術によって、整理が高速にできるようになった。第一世代とは違って、コーチングに中心が置かれて、アジャイルのより深い考え方が浸透してきたように思う。ただし、これはアジャイル実践者に限る話だ。
残念ながら、そういう先進的な企業以外は、未だにウォータフォールが中心だ。Excelの方眼紙は2016年でも使われているだろう。アジャイルの実践者も、現実の多くの「すべきこと」「よくわからないルール」などに苦労しながらも、いまもアジャイル導入を少しづつ頑張っている。
スタートアップの世界では当たり前だ。何故ならそうでないと世界では勝てないから。先進的な企業じゃない企業に適応したSI企業は、寝技ばかり強くなって、テクノロジーを無くしていった。一部の素晴らしいマインドをもった企業が、「ちゃんとした」テクノロジーや考え方を身につけていった。そんな彼らでも現実の狭間で苦労しており、疲弊した優れた技術者は、スタートアップに流れていったり、大企業でも楽天のような従来型のエンタープライズ企業ではない企業へ転職していった。「まともな技術」をやれることを求めて。
そんな状態でも、日本のマーケットが死ぬことはなかった。日本の内需は大きいから、日本のソフトウェア市場が死ぬことはなかったし、どんなに新しい技術がきても古いやり方で無理くり回してても、ご飯を食べることが出来ていた。
DevOps の到来
そんな時に DevOps の時代がやってきた。私は DevOps エバンジェリストになり、アジャイルの血統を引き継いだ DevOps を日本に広める活動をすることになった。最初に、DevOps ハッカソンというイベントを開始した時、すでに米国から宣伝文が送られてきたのだが、私は基本的に全て書き直した。何故なら「アジャイルが導入されている前提」になっていたからだ。こんなことをしているのは日本だけだ。
トラディショナルなALMに飽き飽きしてきたか？DevOps で新しい世界に踏み出そう！
トラディショナルなALMって、、、日本のエンタープライズではALMどころかアジャイル導入も未だだから、日本市場に適合しないといけない。
ところが、私が2015年のサンフランシスコのDevOps Enterprise というイベントに出たあたりから考えが変わってきた。
「日本や日本の文化に適合したらもしかしたらダメなんじゃないか、、、、」
何故なら米国では、ガッチガチのエンタープライズ企業、しかも銀行とか生保が1日に10回以上本番リリースするような自動化されたリードタイムの短い環境を達成していた。パペットラブスの有名なサーベイを思い出すと DevOps の導入で、リードタイムが200倍短くなり、障害復旧が168倍高速化されるとか、衝撃的なものだ。それは眉唾ではない。リードタイムが半年ぐらいだったところが1日10回デプロイできるリードタイムになったらどうなるだろう。
インターナショナルチームでも、「アジャイルが未だ」とか言ってるのは日本だけなのだ。これは本気でやばい。しかも日本人の多くは英語を苦手としている。グローバルの時代はすぐそこなのに、世界の中で取り残される。実際私はベトナムとかにもよく行っていたが、正直な話、ベトナムのエンジニアの方がよっぽど今の技術を理解していると感じた。少なくとも日本みたいに汚くてもなんでも、できたらいいというノリはなくて、少なくとも「理解」しようとしている。そして、英語も恐れない。
今までのように、日本市場向け、日本の文化を尊重したやり方を続けていたら、あと何年導入にかかるかわからない。その間に日本のソフトウェア産業は死ぬだろう。スタートアップ系は違うが、エンプラはレベルが違いすぎる。例えば、エンプラ系の技術者の人がアメリカに移住して、今の技術で現地で飯が普通に食えるだろうか？
そんな危機感を持っていたので、最近の私は結構スパルタだった。第1期、第2期のアジャイル導入で、本人が「やる気」さえあれば、「自分でもできる」と思ってもらうことができる技術はあるので、なんぼでもなんとかなる。会社の変なルールも、変えようと思ったら変える方法はあるので、それも目の前で証明してみせたりもした。
しかし、私はミスを犯した。前のポストで書いたように、みんなが、ストレスを感じてしまった。技術的に「自分でもできる」と思ってもらうことができても、アジャイルや DevOps を無理なく理解してもらうには何かが足りなかったのだ。
「文化」をインストールすればうまくいく
私が米国マイクロソフトの DevOps エバンジェリストになって、もっとも良かったことの一つに、米国の「文化」が徐々に理解できてきたことがある。これは日本の環境で働いていたら決して得られなかったことだ。中には自分的には目から鱗の気づきがあって、「Be Lazy」 や「物量」、「質問」に対する考え方、「すべきことの量」「自分の幸せが優先」という考え方、、、もっと今後も気づきは継続していくだろう。
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
そんなある時、ふと閃いた。アジャイルや、DevOps は、「米国や欧米の文化が暗黙の前提」の上に構成されるのでは？という仮説だ。もしそうなら、欧米の企業が簡単にアジャイルをインストールできるのも合点が行く。日本では難しいと当時言われていたオブジェクト指向も実は「英語」で学ぶとかんたんなものでしかないので、向こうではオブジェクト指向がわからないとかいう悩みはほぼないのだ。 そういう感覚がインターナショナルポジションになってようやく理解できてきた。アジャイルや DevOps やソフトウェア技術も、英語圏の人が、自身が持っている文化を背景にそれらを理解しようとしたらきっとそんなに理解が難しいものではないのだと思う。 つまり、アジャイルやDevOps の生産性に関わるところだけでもいいので、「欧米の人が、どのような思考回路をしているか？」ということをインストールすれば、日本でもそんな特異なものではなく、簡単なものになる。その時に、日本の文化とか現状を想像するから理解が１０００倍難しくなるのだ。
ちょうど「オブジェクトゲーム」でオブジェクト指向の考え方をインストールした人が、簡単にテスト駆動開発を受け入れられるように。
実際実践してみると、これは大変効果的だった。「Be Lazy」 の話や、「すべき」をなくす話とか、「気軽に聞く」話とかすごく興味を持ってもらえて、早速少しづつ実践してくれた。変な抵抗もなくなった。これは絶対効き目がある。今後もブラッシュアップして、体系化していきたい。自分にとって「オブジェクトゲーム」は当時衝撃的な効果だったが、今回、同等レベルの効果を感じた。自分に足りていなかったピースはこれだ。アジャイルやDevOps を導入する時の日本に置ける暗黙前提条件のライトウィングと、レフトウィングはきっとこれだ。
守破離を意識しよう
実際に、導入に先立って「アメリカの考え方の違い」を アジャイルや DevOps の背景として話するようにすると、いろんなことに違和感がなくなって簡単に進むことがわかった。私はラッキーなことに、オープンソースのコミッタなど、優秀なプログラマに会う機会があるが、優秀なプログラマほど、ロジカルで、シンプルで、少なくともソフトウェアに関する部分は相当「欧米文化の考え方」に近い考えをしている人が多いと感じている。
それはきっと偶然ではないのだろう。向こうの人が特に全員優秀とかではなく、ちょっとした「考え」が違うだけなのだから、その「考え」をまずは学ぶ方が楽だし、タダだ。
それは、日本の文化を捨てて、米国の文化を受け入れることになり、国際競争力を失いそうな気がするかもしれない。昔から日本人は、自分流が大好きだ。
剣の流派もやたらたくさんあるので、昔からそうなのだろう。最初から自分流にしたがる。しかし、本当に何かを学びたかったら、「守破離」で考えることをお勧めする。これは日本の伝統的な考え方だ。まず最初は師匠の言った通りやってみる。その後研究してその型を破る。最後に型から離れて自由になるというモノのマスターの過程だ。
でも、なぜかソフトウェアになると、なぜか基礎をちゃんと理解する前に、いきなり「日本流」「自分流」に従って、魔改造をしてしまい、効果が出ないと元のスタイルに戻っていく。エンタープライズのソフトウェアの世界がこんな無茶苦茶になっているのはこのような過程があるからだと思う。
その「暗黙の前提を理解」して「アジャイルや DevOps」のことをちゃんと理解して実践したら、日本人は凄いことになると思う。心配しなくても、日本人の能力は高いし、思考回路も相当ユニークだ。伝統や文化など、必死にしがみついて守るものではなくて、結果として生まれるものだと思う。 日本人はいろんな考えを受け入れて成長してきたのだから今回もいけるはずだ。
普通に学んで普通に実践すれば、普通に進化する。なんでもそうだと思う。きっとそれを阻害してきたものは、我々が、「欧米の文化」の違いに気づいていなかったり、その因果関係に気づいていなかったのだろう。もちろんこれはまだまだ仮説に過ぎないので、今後も検証していくつもりだ。
私は間違ってるかもしれないが、多くの人が一生懸命日本のソフトウェア産業がよくなるようにいろんな角度から頑張っていれば、そのうち、日本のソフトウェア産業もグローバルの中で生きれるようになると思う。私も自分の出来る範囲で楽しんで探索していきたい。
「すべき事」をなくせばうまくいく。- インターナショナルチームでの学び
私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は日本でプロジェクトの改善活動を実施している時に気づいたことをシェアしたいと思います。
先日、ハックフェストというイベントを実施していました。現在実施している開発チームの作業工程を見える化して、無駄を発見し、マイクロソフトのメンバーが支援して、自動化のハックをして、実際に改善しちゃおう！というイベントです。このようなステップを踏むと、実際に自動化する前に、現在のソフトウェアリリースのリードタイムが８ヶ月だったものが、１週間ぐらいになることがわかったります。
それを実際にハックして実現しちゃおう！というものがハックフェストなのでなんともエキサイティングな仕事です！
ところが、先日ハックフェストを実施したときに、メンバーの人と一緒にペアプログラミングをしていたのですが、その人がとっても辛そうな顔をしていたのです。本来プログラマにとって「ハック」とは楽しいものです。なんで、そんな辛そうなんだろう？ととても気にかかっていました。
インターナショナルチームでは仕事は楽しむもの
そういえば日本では仕事を「楽しい！」といってる人は多くないイメージです。私も実の母からも
好きな事を仕事にできる事はそうそうないのでお前は幸せや。でも世間様はそうやないんやで、みんな我慢してるんや
と良く言われます。しかし、インターナショナルチームや、USに行って仕事をすると、全く逆のイメージで辛そうに仕事をしている人を探す方が難しい感じです。私はマイクロソフトしか経験がないですが、USでマイクロソフト以外でハッカソンのお手伝いをした時も、何かに「悩み」はしても「仕事は辛いがやらなければならない」なんて言っている人に会った事がありません。日本側の私のサポーターのDrewもいつも仕事が楽しそうです。
私の上司のDamienが私にいつも聞いてくるのもこの一言です。
Tsuyoshiエンジョイしてるか？
この違いは一体なんなのでしょうか？ 今回は、なぜ、仕事が辛いものになってしまうのかを考えてみました。
仕事が辛いものになってしまう理由
メンバーの一人は私の友人だったので、「なんでハックしているのに辛そうなのですか？」と個別に聞いてみました。
牛尾さんや、前佛さんに来ていただいているので、嬉しいのですが、結果を出さないといけないのでプレッシャーがあるんです
ここで初めて、インターナショナルチームで、バリューを出す事と、日本式の「結果を出さないといけない」という事のイメージが大きく違う事に気がつきました。
「目標」を立てた後の実行フェーズの違い
インターナショナルチームでも、日本でも、「目標」は立てます。例えば今回でいうと、「従来８ヶ月かかっていたソフトウェアのリリースを１週間に短縮する」になります。それを目標に、５日間のハックフェストを実施するとします。
日本だと、一度目標が決まったら、途中で未知の問題が発覚しても、「プロなのだから、一度決めた納期はしっかり守り通そう」というノリになって、徹夜などをして必死で達成しようとします。そして、その目標が達成できなかった時は「失敗」の烙印を押されて次回は二度とこういうチャンレンジができなくなることもよくあります。
一方インターナショナルチームだと、「目標」は立てます。途中で問題が発生したら、「どうやったら達成できるか？」は常に考えたり、工夫したりしますが、目標設定に無理があると判明した場合は、最も優先順位の高いの最初の１ステップのみを目指すように方向転換します。定時以降の仕事や、休出でカバーしようという流れになることはありません。できないものはできないのです。
上司 Damien の一言
私が今のチームに勤めて最初に衝撃的だった事があります。私はインターナショナルチームですが、普段は日本にいますので、日本チームとも仕事をします。 インターナショナルチームのKPIは定時で無理なく楽に達成できる程度のものになっていますが、日本チームの仕事もお手伝いする事があります。 それに、最初入社した頃は、大量の英文メールにも慣れず、いろんな仕事に手を出してアップアップになっていました。その事を上司に相談しました。
きっと日本だといい上司でもこんな感じじゃないでしょうか？「最初は大変だが、しばらく慣れるまで頑張るしかない。私も出来る限り手伝うから頑張ろう」しかし、Damien が言った事は全く異なりました。
Tsuyoshi 君の一番重要な仕事は何だ？うん DevOps ハッカソンだな。君はいまそれだけをやればいい
彼に限らず、インターナショナルメンバーや、Drew からくるアドバイスで、「ちょっとしんどいけど頑張ろう」「君が本来やるべきだから時間がかかってもやり遂げるべきだ」的なものがあった試しがありません。日本の場合は、やると目標を決めた事を、リソースを追加しても何があってもやりきる方向に倒れますが、インターナショナルチームだと、単純に定時でできる量になるように「作業量」をいまの実力でできる範囲内に調整するのがほとんどです。予定されたアウトプットより少なくなっても気にしません。何故なら、できない事は出来ないからです。
期間内にやりきる対象 vs 実際にやった結果の学びを得る対象
もちろん全ての日本のチームがそうではないと思いますが、多くのチームが日本では目標を決めたらそれが「期間内にやりきるための対象」になり、目測を誤っていても、やりきる対象になるので、相当プレシャーがかかります。失敗は許されないムードのもあります。 インターナショナルチームでは、目標はあくまで目標であり、重要な事は実際やってみて、実際どうだったか？どれぐらいできたか？のフィードバックが重要と考えているようです。最終的に達成した事が計画を超えているか？という観点ではありません。ですので定例会議みたいなものでも、「やってみて実際どうだったか？、改善ポイントやベストプラクティスは？」という事を聞かれます。決して「計画通りかどうか？」とかそんな話は聞かれた試しがありません。
「すべきこと」の量が圧倒的に違う
他の観点で言っても、日本と比べると「すべきこと」が圧倒的に少ないイメージです。インターナショナルチームだと、やるべき対象は KPI の達成だけであり、それも、そんな無理なものが設定されているわけではありません。やりかたは自由で細かく指示はされませんので、自由にやってOKです。
日本だと、そういう評価基準があるのに加えて、日本人として、社会人として「こうあるべきだ」みたいなものが圧倒的にたくさんあります。仕事の結果に対しても「このようにやるべきだ」「これぐらいやるべきだ」「この期間内にやるべきだ」みたいな暗黙の期待が多くあり、それを達成しないと、いまいちな人と思われてしまうケースもあります。本当にそうすべきかはわかりませんが、その期待に全て答えようとするとそれは大変です。
インターナショナルチームは、KPI以外に「やるべき事」ほぼありません。KPIさえ達成していたら、細かく言われる事はありません。やり方も自分で決めるので「やらされること」も、せいぜい月次レポートと、必須教育程度です。
目標設定に関しても、実際やってみて、学んだことをシェアすることが十分バリューであり、目標通り行くことはどうでもいいのです。やるかどうかも自分が決めますし、やらなくても何も言われません。自分がやりたければやるというノリです。だから、みんなその「難しい」チャレンジに対してパズルを解くのと同じノリで楽しめるのです。
自分 vs 他人
向こうの文化で考えると、「自分」が一番大切で、自分の幸せが一番大切です。「自分」が「自分以外のもの」になる事も期待されません。むしろ、「自分」だけでなく「他人」も「幸せ」で、「自分らしくいられること」は重視されます。日本だと、「人の期待と違っている」といろいろ言われますが、インターナショナルチームでは、ダイバーシティを受け入れないと、仲間に入れてもらえません。私が衝撃的だったのは、イギリスに短期留学している時の話です。
ホストファミリーのお母さんが言っていました。「学校にジプシーがいるのよ。その子がむちゃくちゃ暴れるのね。親もいるんだけど、親も一緒にあばれるのよ。だから、その家族のためだけにボディーガードを雇ってるのよ。」それを聞いた私は「なんで、イギリスに来ているのに、ちゃんとイギリスのルールにのっとって振舞わないんだろうね？学校もお金の無駄やん」と言ったのですが、彼女はこう言いました。
Tsuyoshiそれは違うよ。我々から見てむちゃくちゃでも、彼らは彼らの文化があるからそれを尊重しないといけないのよ
これは自分にとって衝撃的な一言でした。
「すべきこと」をなくせば上手くいく
このように、日本には「すべきこと」がたくさんあるため、多くの時間がかかったり、多くの人がいろんな事をやる前から諦めているように見えます。私もバリューストリームマッピングという、ソフトウェア開発作業の見える化を行って無駄を見つけるワークショップを実施しています。すると、たくさんの承認作業や、手作業、有効だと思えないドキュメント書きが明らかになったりします。そして大抵は現場の人もその事を無駄だと思っています。
ところが、「決まっているから変えられない」とか、「変えようとしたら大変だから」という事を言って今の制約の中で仕事をしようとします。
そしてその「すべきこと」は何か問題が発生するたびに、どんどん増えてしまいます。本番へのリリースも、「失敗しないように、慎重にテストをしないといけないから、たくさん仕様書を書いて、マニュアルテストをします。それでないと本番にはリリースできません」と現場では言う事が殆どです。
ところが、実際に社長さんをつれてきて一緒にディスカッションをすると、「この承認無駄だね。カットしよう。」とか、「別に品質にそこまでこだわらなくていいから、早くリリースできるように倒そうよ」「そこは現場で判断していいよ」とか一気に話が進む場面をよく見てきました。
日本でも、「すべき」と思い込んでるだけでそうでないケースは本当はもっと多いのではないでしょうか？
幸せに、バリューを出す仕事をするために
私はその後のハックフェストからは、次のように言うようにしました。
- 「目標」は必ずしも達成しなくてもいいし、自分たちのペースでみんなが楽しんでくれたらいい
- 実際にやってみる事が重要で、どこまで行けたかは終わってからでないとわからないのでどうでもいい
- 終わった後に、無理ないペースでどこまでバリューが出せたかを学んでみよう
私の他のブログエントリにあるような、Be Lazy のような、時間をかけてピカピカなものを目指すより、もっとも楽な手段でバリューを出す方法のお話もしてみました。途中で無理があったら、頑張るのではなく、無理ないように物量を減らす方にシフトすることを推奨しました。
すると、みんな笑顔でハックしてくれるようになって、誰一人として、しんどそうな顔をしなくなり、結果としてかなりの成果が達成できました。
この辺りは、日本の文化なので、「すべきこと」を一気になくす事は出来ないでしょう。でも、まず自分がそういう考えをする事はできるかもしれませんし、自分のチームはそういう考えで運営する事も可能かもしれません。
私は少なくとも、自分が幸せを感じて、楽しい仕事ができる方を選択したいと思っています。ですので、自分と関わる人も、その人がやりたい事をやって、仕事を楽しんでもらいたいなと思います。そして、それが結果としてチームの幸せと、バリューに繋がるんじゃないかなと思っています。
だから、自分も、まず自分が仕事を楽しんで、幸せを感じて、そして、自分以外の人もそう感じてもらえるようまずは「すべき」という事を自分からなくすように小さな一歩を進めてみたいと思います。
P.S. 今回のタイトルは尊敬するソニックガーデンの倉貫さんの著書をオマージュさせていただきました。
倉貫さんの会社の仕事のやり方はこういった「すべき」が見当たらないやり方で昔から凄いなと思っていましたが、今インターナショナルチームになった視点から見ても素晴らしいと改めて思います。
マイクロソフトの de:code の DevOps トラックが奇跡の展開になっている件
私のメインマシンは未だに Mac で現在も docker を中心としたオープンソース系の DevOps 技術が大好きだ。そんな私でも正直、今年の de:code というマイクロソフトのイベントはありえない展開になっていると思う。本当にこうなったのは私の力ではなく、日米のマイクロソフトの仲間と、一緒に仕事をさせてもらっているクリエーションラインさんのおかげで、少なくとも DevOps トラックは奇跡の展開になっていると言っていい。これがマイクロソフトだからという理由で世の中にあまり知られていないのはもったいなすぎる。
OSSを愛する一人として言っておきたい。
はっきり言って、DevOps やマイクロサービスに興味があるならマイクロソフトに全く興味がない人でも参加する価値がある。
その理由を簡単にお話ししたいと思う。この先を読んでいただいたらその理由がわかってもらえると思う。
理由その１. 超豪華 OSS 系ゲストスピーカーの数々！
Mesosphere社 Mesosphere DCOS 開発者 Aaron Williams氏
今年のゲストスピーカーは超豪華だ。そしてそれは、MSのスピーカーに限らない。まず最初に、Mesosphere社の、Developer Aaron Williams氏がやってくる。彼はMesosphere DCOS という基盤を作っている。これはマイクロサービスや DevOps の世界に革命をもたらすかもしれない技術だ。それは「データセンターOS」といって、データセンターをまるで 1台のPCのように扱うことができるようになる技術だ。 例えば "dcos install spark" なんてタイプすると、データセンターのクラスタに Spark が展開されるという恐ろしいものだ。この技術は、Twitter, AirBnB, Apple でも使われている実績ある技術 Apache Mesos がベースになっている。この技術者が来日してトークしてくれる。 私もこの話を Vietnam でしてきて、2nd speaker prize を受賞させてもらった。それぐらい衝撃的なテクノロジーだ。しかも、多くの人は知らないかもしれないが、Microsoft の Azure Container Service というサービスの基盤でもある。そしてマイクロソフトは Windows 版を出すとも言っている。何が起こるんだ？
そんな人が来日なんて、もう既に頭が沸騰しそうや！
Chef社 VP James Casey氏
そしてそれだけに終わらない。Infrastructure as Code の世界で、デファクトスタンダードと呼べる Chef からはまさかの VPが来日。James Casey氏が来日する。大抵の Infrastructure as Code の話は Linux ベースの話が多いが、Chef のいいところは、技術が何年も使われてコードが書きやすい事、アジャイル好きな私として胸熱ポイントは、テスト駆動インフラストラクチャの仕組みが充実していることも特筆だ。また、Linux, Windows の両方のサポートが優れている事も素晴らしい。なんと今回はガチのテスト駆動インフラストラクチャのデモが眼前で繰り広げられるらしい！
大抵の企業は、Windows も Linux も両方存在するだろう。そうなるともちろん片方だけではなく、両方を同じ技術で統一したいところも多いだろう。また、１０台ぐらいのサーバーだとなんでもいいが、それ以上になるとサーバーの構成管理も大変になる。そういう時に chef はサーバーが充実しているので、とても快適になる。個人的にも DevOps系 の技術で最初に衝撃を受けたものなので、そんな皆さんとお仕事ができるなんて、とても感慨深い
CloudBees社 Jenkins 開発者 川口耕介氏
そして、Jenkins の作者の川口耕介さんが普段住んでおられる米国からわざわざ de:code のために来てくれた。Jenkins といえば、CI/CDのデファクトスタンダードだ。OSS系、MS系関係なく使われまくっている。高機能なのに、実行は本当にシンプル！そんな素晴らしいツールの作者が日本人の方だなんて素敵すぎます。そんな川口さんがやってきて、docker を使った継続的デリバリのお話しや、Azure との連携、そしてJenkins 2.0 のお話しもぶちかましてくれる。私も以前スペインでインタビューさせてもらったのだが、その時も相当面白かった。今度はこれをみんなの前でお話ししてくれるのだ。これは Java エバンジェリストのてらだよしおさんのおかげなのだ。
しかし、それだけに留まらない。さらに DevOps テロは続く。
HashiCorp社 Mitchell Hashimoto氏
自分的に超絶アツいのが、HashiCorp の Mitchell Hashimoto 氏だ。あの Vagrant, Packer, Terraform, Consul 等の作者で、HashiCorp のファウンダー。これらのツールはほんまにシンプルで、無駄がなく、かつ気が利いている。この”手になじむ”感は使ったものでしかわからない。これは Unix の思想に影響を受けた、HashiCorp Tao のマインドセットから生まれたものだろうか？昨日もHashiCorpのSerfを使ったクラスタをAzure 上に構築したが、インストールがあり得ないぐらい簡単（バイナリ一つにパス通すだけ）で数コマンドでクラスタが構成できた。 DevOps ファンの方なら、Otto のリリースの当日、タイムラインが otto で埋まったことを覚えているかもしれない。最近出たNomadがむっちゃ簡単に構成できるのに、あっさりマイクロサービスの基盤ができちゃうとか素敵すぎる！ そんなHashiCorpのMitchellがガチ来日。もうありえない。HashCorp の最近のツールは Go で作られているため、意外に聞こえるかもしれないが Windows との相性もいい感じ。今後さらに注目が集まることが予想される！
そして、恐ろしいことに、これらのメンバーが集結してスペシャルセッションと称して、パネルディスカッションを決めるのだ。こんなDevOps 界の東西の横綱が一同に会して同じ壇上に上がるなんてはっきり言って西海岸でもありえない展開だ。それぞれのメンツがそれぞれキーノートになれるぐらいの実力がある。
おお、なんとすごいイベントだ、まるで DevOps やマイクロサービスのオールスターのようだ、、、と思っているかもしれない。 私もそう思っていた。しかし、さらに凄いことが起こったのだ。
理由その２．マイクロソフト最高の DevOps チーム Sam Guckenheimerが講演
マイクロソフト一番の、DevOps 実践チームを率いる Sam Guckenheimer も来日する！そしてガチ事例を話してくれる。マイクロソフトが 内部でどんな開発をして、どうアジャイルや DevOps に取り組んできたか？ということを本人の口から話してもらえる！これは激アツとしか 言いようがない！日本ではあまり有名じゃないかもしれないかもしれないけど、彼は複数の素晴らしいソフトウェア開発に関する書籍を 執筆し、世界最大のアジャイルカンファレンス 2014 のキーノートスピーカーなのだ。私は友人の楽天の川口さんから彼の存在と素晴らしさを教えてもらった。今はマイクロソフトの中の人だからわかるが、マイクロソフトの DevOps の事例の最高のものは彼のチームのものだし、各種のホワイトペーパー、アセスメントの元になっている 7 habits という DevOps の成功のための７つの習慣を考案したのも彼だ。
まさに、１２万人以上いる全世界のマイクロソフトにおいて DevOps の頂点に間違いなく君臨する男が来日するのだ。
こんなすごいイベントが黒船でなくていったい何なのだろうか？間違いなくこの日から日本の DevOps は変わる。本当にそう思う。
理由その３．国内 DevOps 超強力ゲスト＋MS技術の達人によるチョークトークと事例
これだけでも爆発的だが、国内ゲストスピーカーもあり得ない展開だ。元AWS の アジャイル DevOps Cloudコーチの吉羽龍太郎氏、日本で唯一の公認docker トレーナーの資格を持つ男で私も尊敬する前佛雅人氏、マイクロソフト ITPro 界の超人気スピーカーでマイクロソフト技術を知り尽くした男、高添修さん、そして僭越ながらモデレータとして私が入って、DevOps について語りつくすチョークトークなんかも存在する。実際の DevOps 事例として、楽天のKanioさんと川口さんによるガチDevOps 事例 on Azureも非常に楽しみだ。
このように、国内外の DevOps の最新事情がガチで体験できる恐ろしいイベントになっているのだ。もう来年はこのレベルを維持できるかはわからない。でもこれがきっかけになって日本でも DevOps の導入が進むのではないだろうか？
まとめ
中の人になったのでなんだが、今のマイクロソフトは本当にむっちゃくちゃ変わっている。こんなイベントにちょっとでも貢献することができて本当に幸せだ。もし、来れるなら是非来て、その目で、世界最先端を体感してほしい。
今回はゲストスピーカーのお話しばかりしてみたが、OSS の世界の人間である私が、MS に入って知った注目技術を次回は紹介したい と思います。あのマイクロサービス本の監訳者の人が自信をもって紹介するあの基盤とか！ お楽しみに！
de:code (decode) 2016 ｜ 日本マイクロソフトの開発者/アーキテクト/IT Pro 向けイベント - Microsoft Events & Seminars
docker の実行環境を選択する
現在、様々な環境で docker が動作します。先日同僚から、「docker はいろんな環境で動作するが、どの環境で動かせばいいの？」と質問を受けました。
今、初めて docker を始める場合、どこで環境を作ればいいのか迷ってしまうほどたくさんの選択肢があります。この問いに自分なりに答えてみたいと思います。
このポストは現在(2016/3/15)のところの私の個人的な意見を書いておきたいと思います。よりよい選択があれば是非コメントいただきたいと思います。
またこの話は、私より1000倍 docker に詳しい方に共有しておいたので、彼がもっといい記事を書いてくれるかもしれません！
1. 開発環境
開発や、docker を試してみたい目的で docker を動かす環境が欲しい場合、現在はほぼ一択で、「Docker Machine」を使うと良い。Docker Machine は、docker の実行環境を簡単なコマンドで作ってくれる。サーバーは自分で作る必要はない。
docker のページから Docker Toolbox
をダウンロードしてインストールしよう。準備はこれだけ。これは簡単だ。Win / Mac をサポートしている。
上記のコマンドで --driver オプションを指定している。オプションを指定すると、VirtualBox や Hyper-V もしくは、Azure などのクラウド環境にサーバーを作ることができる。開発時には、手元のPCに環境を作るVirtualBox か、Hyper-Vが良いだろう。無駄にお金を使う必要はないし、何も違いがない。そもそも手元の方が早い。クラウド環境だと、ファイアーウォールの設定等実際に運用する時には必要なことを考慮する必要がある。
$ docker-machine create --driver=virtualbox dev
Docker Toolbox をインストールしたあと、これだけで docker を実行する dev という名前のサーバーが起動する。実際には、docker 実行環境がインストールされたバーチャルマシンが起動する。docker は、手元のPCでもサーバーでも全く同じように動作するのが売りなので、大抵のことはDocker Machine で十分だ。この後、docker-machine env devとタイプしたときに一番下に出てくるワンライナーを実行すると、環境設定が終了して、docker が使えるようになる。Windows ユーザへのTips としては、--shell=powershellとか--shell=cmdとかつけてあげると、それぞれの環境用の環境変数設定用ワンライナーを生成してくれる。下記はPowerShellを使った例だ。
PS C:\WINDOWS\system32> docker-machine env dev2 --shell=powershell $Env:DOCKER_TLS_VERIFY = "1" $Env:DOCKER_HOST = "tcp://192.168.99.100:2376" $Env:DOCKER_CERT_PATH = "C:\Users\tsushi\.docker\machine\machines\dev2" $Env:DOCKER_MACHINE_NAME = "dev2" # Run this command to configure your shell: # C:\Program Files\Docker Toolbox\docker-machine.exe env dev2 --shell=powershell | Invoke-Expression PS C:\WINDOWS\system32> docker-machine.exe env dev2 --shell=powershell | Invoke-Expression PS C:\WINDOWS\system32> docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES PS C:\WINDOWS\system32>
これだけで docker が既に使用可能になる。詳しくは docker-machine のコマンドのマニュアルを見て欲しいが、docker-machine ssh dev とタイプすると dockerのサーバーが起動している仮想マシンにログインすることもできる。このツールで大抵のことができる。
開発環境として、Docker Machine を選んでいる理由は、何と言っても手間が少ない、お金がかからないということに尽きる。docker の開発は基本的に
- Dockerfile を作る / テストする
- Docker-Compose のファイルを作る / テストする
- Dockerfile / Compose のファイルをリポジトリに格納する
- DockerHub にイメージをプッシュする
ということを実施することが多いだろう。Docker Compose は、dockerコンテナを組み合わせて環境を作るためのテクノロジだ。例えば、webとdbの組み合わせでシステムを構築したりすることが多いだろう。そういう場合に、Docker Compose 使うと設定ファイルを書くと、いい感じで動作してくれる。
Web-DB 構成を起動する docker-compose.yml の例
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis
redis:
image: redis
大抵はこれらのワークフローが簡単に構築できる環境があればいい。
2. シングルサーバ運用環境
次に、複雑な構成は不要だが、docker で作ったアプリケーションを手軽に公開したい場合のオプションを幾つか紹介する。
2.1. Docker Cloud
最も簡単なのはおそらくDocker Cloud だろう。docker 社が作成している SaaS で、ほぼ何もしなくても、docker が動作するインスタンスを画面 もしくはコマンドラインで起動することができる。実際のインスタンスは Azure などのいくつかのパブリッククラウドで動作する。簡単さでは右に出るものがない感じだ。
現在のところの課題は、Docker Compose が動作しないこと、リージョンによっては動作しなくなることがあるので、試してからにした方がいい。だが、今後、Docker Compose 対応すれば最も注目度の高い環境になると思う。
2.2. docker on Ubuntu
docker の入ったシングルサーバ環境をクラウド環境などに作る方法はたくさんある。
- docker-machine
- docker cloud
- ARM などの IaC のテンプレート
- Vagrant / Terraform の docker プロビジョナーを使う
- CoreOS :
Docker Cloud を別とすると、Docker Machine がもっとも楽な方法だ。docker だけでなく、Docker Compose や、後述する Docker Swarm も使えるのも良い。
ただ、きっとこのオプションを選ぶ人は動作させるサーバーを「自分でコントロールしたい」と思う人だろう。自分でコントロールしつつ、できるだけ楽に docker 環境をデプロイしたい場合は、環境をデプロイする IaC テンプレートを利用するのが良いと思う。環境のデプロイがコード化されているのですぐにデプロイできるし、気にくわないところは、コードを変更して自分のものにしてしまえばいい。
私は、Microsoft の中の人なので、Azure ぐらいしかよく使っていないが、他のプラットフォームでも同様のものはあるだろう。Azure の場合だと、Azure Resource Manager というテンプレートがあり、パラメータを設定してワンボタンでdocker 環境をデプロイできる。コードは JSON で書かれた簡単なものだが、自分のコードにしてカスタマイズすることもできる。Azure Portal からも、docker が動作する環境を複数選ぶことができる。HashiCorp の terraform を使うのも良い手だ。クラウドを選ばず記述できる。
この際、CoreOS や Ubuntu ... 等の選択肢があるが、私が個人的にお勧めするのは現状では Ubuntu になる。世の中の手順や、3rd パーティツールの対応具合を見ても、最もテストされている環境と思われる。その点は CoreOS も悪くないのだが、自分でコントロールしたいという用途の場合は、CoreOS は、当然といえば当然だが、通常の Linux にあるコマンドがなく自分でインストールする必要になるケースが多く、サイズが小さいことを重視したい人にはお勧めだがそうでなければ Ubuntu という選択でよいと思う。例えば CentOS などを選択したい人もいるかもしれないが、3rd Party ツールのサンプル等でも大抵は Ubuntu なので、比較すると圧倒的にペインが少ない可能性が高い。
サーバーを運用するときは、docker だけ使えればいいというケースではない場合も多いように思う。その場合は Ubuntu がお手軽だろう。ただ、今後は、CoreOS のようなサイズが小さいソリューションが重視される傾向にあると思う。昨今の PaaS の動向からすると、CoreOS のようなものは、PaaS の中身として使われることが増えるのではないだろうか？
3. クラスタリング環境
さて、複数サーバーでクラスタリングを構成したい場合もいろいろ有力なオプションがある。それぞれに関してのざっくりした感想を共有したい。クラスタの場合は、決定的なソリューションは存在しない。各ソリューションによって、特色が違うので、その好みによって使い分けるといいだろう。
- Docker Swarm
- docker cloud
- Mesos / Mesosphere DCOS
- Nomad
- Kubernates
最初にお断りしておくが、私はKubernates だけ試していないのでその感想は他の方にお譲りいたします。
3.1. Docker Swarm
Docker Swarm はクラスタリングを構成する環境としては、Docker Compose もサポートされているため操作は快適に感じる。単にクラスタを構成したい場合のオプションとしてはかなりいい感じ。唯一の欠点をお話するとインストールが面倒臭いことにある。 この点は、上記でご紹介した「IaC テンプレートの利用」がら楽だろう。Azure とかの例しかしらないので、恐縮だが、Azure の場合だと、Swarm クラスタをワンボタンでデプロイできる テンプレートが公開されているし、より凝ったものでも、Azure Container Service というサービス化されたテンプレートも公開されている。
3.2. Docker Cloud
Docker Cloud もスケールとかは可能だ。楽さにかけては No.1 ただし、前述したとおり Docker Compose に似た仕組みは動くが、Docker Compose はまだ動作しない。今後楽しみだ。
3.3. Mesos / Mesosphere DCOS
Mesosphere DCOS はクラスタ自体を１台のコンピュータのように扱える「データセンターOS」と呼ばれる仕組みだ。リソースのアロケーションとジョブ / サービスの実行、インストールが大変簡単だ。AirB and B で生まれて、Twitterや Apple でも使われているが、結構ごっついトランザクションをさばく必要のある基盤で使われる。 docker の実行も上記の２つに比べるとリソース割り当てを意識する必要があるので簡単ではないが、負荷の高い環境では要注目！
課題はインストールの面倒くささ。これはSwarm 以上のめんどくささだが、これも同じく「IaC テンプレート」が用意されている。Azure Container Service も内部は Mesosになっているので、そういったものを利用するといいだろう。
3.4. Nomad
最後にご紹介するのが、HashiCorp の Nomad だ。Nomad はよりシンプルで、多機能ではないが Mesosに近いことができる。Nomad の素晴らしいところは、インストールが劇的に簡単で、シンプルなので理解がしやすいところだ。上記のソリューションと同じく、「IaC テンプレート」を使うと良い。私が個人で書いた Nomad と Docker がインストールされた環境を簡単に Azure で使えるようにしたテンプレートが次の通りだ。テンプレートのインストール部分は劇的に簡単だ。尚、HashiCorp は Vagrant で有名な会社だが、他にも良質なソフトウェアを多数作成している。Consul とクラスタ構築の基盤が Nomad でも使われているが、先ほど紹介した Swarm でもこのConsul がクラスタを構築する基盤の一つとして採用されている。
これは私が書いた ARM のテンプレートで、学習目的で Nomad と Docker が入ったインスタンスを５００台までプロビジョンできるコード。GitHub ページの Deploy to Azure ボタンを押すと Azure に仮想サーバーが Deploy されるにようしている。
まとめ
簡単ですが、現在の docker 環境構築のパターンをまとめてみました。少しでもお役に立つと嬉しいなと思います。繰り返しますが、日進月歩の分野でもあるので、コメント や他のいい方法など Welcome です！ 私も勉強したいです！
本番環境の「聖域化」を再考する - DevOps の「リードタイムの短縮」の次に来るもの
DevOps という言葉は2009年のVelocity conference でFlickerが発表した 10 deploys per day という発表が起源になっています。
www.slideshare.net
残念ながらアジャイル開発宣言のような公式の定義がないため、多くの人がその定義をしようと頑張っています。私はその起源や、インターネットでいろんな人が定義している内容を総括して次のように「DevOps のエレベータピッチとは」という問いに答えてきました。
ビジネス・Dev・Ops が協力し、ソフトウェアのライフサイクルと価値の創出を改善する活動
これはこれで特に悪くないとは思うのですが、正直若干「ふわっ」としているのは否めません、また、私が個人的に、Microsoft で一番の DevOps チームと呼ばれる Visual Studio Team Services のチームの事例を研究していく中で、「現在形」の DevOps の形について考えがまとまってきたのでシェアしたいと思います。
リードタイムと10 deploys per day
DevOps の定義を掘り下げる前に、メリットについて考えてみましょう。DevOps のメリットとその本質として最初に言及されるのが、「リードタイムの短縮」です。DevOps の起源のプレゼンテーションにもあったとおり、「１日１０回以上も本番に安全にデプロイできるほどの、自動化と仕組み作りをできるようにする」ということはイメージとしてわかりやすいかもしれません。
注：10 deploys per day に対する私の意見とディスカッションはこちら*1
実際には改善活動なので、いままでアイデアを思いついてから、それを本番にリリースできるまでの時間が「６ヶ月」「３ヶ月」だったのが、冗談抜きで「３時間」とかになったりします。
私も「1日に10回以上デプロイ」は「起源」で使われていますし、大変わかりやすいものなのでDevOpsの「エレベータピッチ」的に使っています。実際は１０回以上リリースできても、「価値」が伴っていないければ意味がないのですが、わかりやすさのためそれをつかうことが多いです。
私にとってこの基準はとてもしっくりきていたのですが、先で述べたVisual Studio Team Services のチームのDevOps 実践の事例を見ていくと、実際には、「リードタイムの改善」に関して言及しており、リリースサイクルの短縮は語られていますが、本当に小さな扱いです。なんでだろうと思っていたのですが、その理由はこのチームは「リードタイムの短縮」の先に進んでいるからそっちの方が素晴らしい成果だからということが言えます。実際に強調されているのは、「本番からのフィードバック」「フィーチャーチーム」そして、「仮説駆動のバックログ」「アラートルーティング」「テレメトリ」などです。
リードタイムの次に来るもの - Gene Kim の 3way
私が考えるまでもなく、既に有名な概念があります。 DevOps の世界で著名な Gene Kim 氏がまとめた「DevOps の 3 ways」です。3 ways は私の別のブログで言及をしていますので、詳細はそちらをごらんください。私は最近はGene Kim 氏の 3 waysで DevOps を考えるのが非常にしっくりきています。
上記の図のようにDevOps の達成するゴールを３つの段階に分けています。
1 way: リードタイムの短縮
2 way: 本番環境やユーザからの学び
3 way: 継続的な実験と検証
それぞれについてご説明したいと思います。
1 way: リードタイムの短縮
これはリードタイムの短縮です。これは 10 deploys per day などのキャッチフレーズの背景にあるリードタイムを自動化や組織変更、フィーチャーチームを構成して、短くしていこうというのが最初のゴールです。これは、アイデアを思いついてから本番にデプロイするまでを高速化することにあります。
これのために使われる DevOps プラクティスの例は次のようなものです。
自動テスト
継続的インテグレーション
継続的デプロイ
Infrastructure as Code
リリースマネジメント
ロードテストと自動スケーリング
フィーチャスイッチ
フィーチャーチーム / Kanban
ChatOps
:
注; DevOpsプラクティスの参考 DevOps Practices | IT Pro Guy & Tesar.info
まずはここを目指すだけでも相当ビジネス的にインパクトがあります。
この辺りは、アジャイルや、Continuous Delivery、アジャイルテスティングの考えを元に、クラウド・インフラ自動化技術、Web Operation あたりのアイデアが元になっていると思われます。
2 way: 本番環境やユーザからの学び
1 way が達成できたら、次の段階に進みましょう。
2つめは本番にデプロイした後に、そこから如何に学んでいくかという、本番から次のバックログへのフィードバックループを指します。本番からの学びを如何に効率良く行っていくかという視点です。
この目的のために使われるプラクティスは
アプリケーションパフォーマンスの監視
可用性監視
自動回復（ロールバックとロールフォワード）
これも、Web Operationやインフラの自動化技術、クラウドの自動化技術の影響を受けていますがこのような技術で本番環境からの学びを高速に反映することができるようになります。
3 way: 継続的な実験と学び
DevOps の最終形態です。 今までは本番環境は「聖域」と考えて、失敗しないように準備や計画をしまくって慎重にデプロイするものでした。ところが今は「本番環境」は聖域ではなく、「仮説を検証する場所」という考え方に変わってきています。結局のところ、デプロイしてみないと、全て卓上の空論です。実際に本番にデプロイして、要求的にもアーキテクチャ的にも学びを得て、早く失敗して、早く方向修正して、資金が尽きる前に自分のビジネス的に「正しい方向性」を見出していく実験をします。 このサイクルを如何に高速に回して、「正しい方向性」を見つけていくか？のゲームです。
ここで使われるプラクティスは
仮説に基づく開発
・運用環境でのテスト
・フォールトインジェクション
・使用状況監視 / ユーザテレメトリ
・仮説駆動のバックログ
：
このあたりは、リーンスタートアップのムーヴメントに非常に影響を受けていると思います。リーン系の考えを学んだことがある人は、この辺りはスッキリ受け入れられるかもしれません。 ただ、今の DevOps ムーヴメントがリーンスタートアップの盛り上がっていた頃と違うことは、エンタープライズ系企業でもこれらの「実験」の考えを採用して、高度な自動化、コラボレーションを実現できるようになってきたことです。
たんにリリースサイクルの短縮だけを考えると見えてこない、DevOps の次の一歩がようやく見えてきました。こういった実践が日本でもガンガンに増えてくるのを少しでもお手伝いしたいなと思っています。
参考
この記事と一緒に、Visual Studio Team Services のDevOps Journey の記事を読まれるとより一層よくわかるかもしれません。
