安易に「おなじみ先」に頼まないこと～日本におけるエンタープライズ系企業の DevOps 導入 Step の考察

毎回なのですが、今回のブログポストはマイクロソフトの意見ではなく、私く個人の意見です。ただ、１０年以上アジャイルや DevOps を日本に導入するお手伝いをしてきて、本当に思っていることを基に書きました。少しでも日本に、DevOps が広がるきっかけになって、マイクロソフトも含めた企業が協力やいい競争をして、DevOps の導入を本当に価値あるものになったらいいなと思って書きました。

DevOps のメリットの概要

Puppet Labsのサーベィも示しているが、DevOps は破壊的な改革をソフトウェア開発にもたらす。

これは20年ぐらい前にeXtreme Programming が世間に登場して、ソフトウェアの考え方進め方が大きく変わったのに似ている。今まで６ヵ月に１回しかリリースできなかったサービスが1日に10回もデプロイできるほど効率化されたり、障害復旧からのリードタイムが168倍になるなど、効果は衝撃的なものだ。

しかも、それは特に眉唾の数字ではなく、本当に実践している企業がたくさんある世界で、本当にエッジな人々にとっては「あたりまえ」の世界であり、Microsoftの開発グループを始めとした先端の技術グループでは、さらにその先に進もうとしている。

[View:https://docs.com/ushio-tsuyoshi/7001/microsoftscrum7devops:550:0]

だが、日本の一般的なエンタープライズ系の企業がそういった破壊的効果を求めて DevOps ジャーニーを実施したい場合はいったいどうしたらいいだろうか？

日本のエンタープライズ企業への DevOps 導入 Step の考察

　この導入ストーリは、ある程度の規模のある企業様で、現場の実行部隊のリーダーが主導で導入していくケースであり、全社的にではないが、パイロットとして、DevOps の導入を試行することを許可されているというケースを想定している。また導入にあたって、数名のメンバーが導入のコアメンバとして選定されていることも想定している。この時点でのスキルなどは特に想定していない。

ただ、これは私が過去１０年以上アジャイル / DevOps 導入にかかわってきた経験からの想定ケーススタディで実際の企業とは関係ありません。また、基本は構成メンバーや、企業にもよるので、本来はコンテキストによるのですが、記事にするため単純化しています。

1. DevOps コーチを採用する

　DevOps コーチを探すのは容易ではない。DevOps 関連の技術に明るいだけでは組織導入には向かない。DevOps 関連の技術に加えて、アジャイルコーチとしてのアジャイル導入経験が豊富なことが望まれる。だが
残念ながらそういう人はあまり多くない。難しい場合は、アジャイルコーチを導入の中心にして、Infrastructureas Code等の技術を使える DevOps 技術支援をしてくれる人をメンバーに入れるとよい。
　そのケースでは、アジャイルコーチを選ぶ際には、TDD / Continuous Delivery等の技術プラクティスも十分熟知し、実践できるコーチを選ぼう。良いコーチの採用はどうすればいいだろうか？これは「目利き」
が出来ないと難しい問題だ。簡単なのは「目利き」が出来る人に聞くのが一番。目利きを探すためには、このケースだと、DevOps ではなく、アジャイルコミュニティに顔をだしてみて、講演を聞いてこの人と思える
人に聞いてみよう。

　私は DevOps を日本に広めるような役割にある。最初にこの問題が発生すると思うので、日本でも DevOps コーチを育成することにご協力をしていきたい。来月から、「DevOps 道場」というコミュニティを実施する予定だ。
これは、アジャイルコーチや、そうなりたいパッションあふれる人が DevOpsコーチになって活躍できるような場を提供するつもりだ。基本的にオープンなコミュニティで、誰でも参加可能だが、せっかく私はマイクロソフト
なので、技術的にも、オープン / MS技術かかわらず技術面でのサポートも充実させる予定だ。講師陣のボランティアもWelcomeだ。アジャイルコーチにとっては、第二世代アジャイルと言われるDevOpsの、DevOpsなら
ではのプラクティスや、マインドセット、そして、テクノロジープラクティスを学んだり、シェアしたりできる場だ。例え人気がなくても、月１回のペースで開催していきたいと考えている。

　逆にインフラ技術に詳しい人が、アジャイルコーチのマインドセットやプラクティスを学びに来ていただいても結構だ。この回自体が、Dev / Ops / Biz が集まれたら最高だ。是非日本に DevOps を広げていこう！

2. DevOps 導入主導グループ / チームに対する DevOps 教育を実施する

　信頼できる DevOps コーチを採用したら、次はコアメンバーに対するレクチャーだ。広くあまねく先に教育するというよりも、まずコアメンバーに深くアジャイルや、DevOps の考えそして技術面を理解してもらう必要がある。
　これは私のアイデアではなく、尊敬する細川務さんの素晴らしいアイデアだが、彼と仕事をしているときに、彼は合宿を提案した。数日間みっちりコーチ付きで実施する。この数日間だけですべてが身につくわけではないが、
合宿そして、最初の数か月はゆっくりこの時間に費やしてもいい。そうして、技術面だけではなく、マインドセットなども、コーチ陣と「共通認識」の基礎を築くのだ。この場面では、例えばマネージャみたいな立場の人も、
コードを書いてみるとかするほうが良い。それが自分のロールではなくても、各段に「理解」が出来るようになるからだ。内製を目指す企業はなおさらここで、その一歩を踏み出すとよい。

3. 上位マネジメントとのディスカッション

　次に忘れてはいけないのは、上位マネージメントとのディスカッションである。特に DevOps では、複数の部門やステークホルダが絡むので、組織を超えた協力に対して権限もしくは、影響を及ぼすことができる上位マネジメントと
話すのがよい。特に DevOps の導入にパッションを持っている人が最適だ。もしそんなにパッションがなくても、少なくとも、やっていいこと、部門間の協力を得る協力をしてくれることをご約束してもらう。そして、可能なケースで
いいのでビジネスルールや、成果物の定義を変更してもいいことの事前承認を取っておくとよい。
　そのうえで、「なぜこの会社は DevOps を導入するのか？」ということをディスカッションして明文化しておくこと。なぜかというと、組織導入を実施するときは、１００％パッションあふれる人ばかりで構成されることはないからだ。
そういう人でも「納得感」を得てもらうために、「なぜこの会社が DevOps に取り組むのか？、上位のサポートが明確にある」ということに関して共有することで、協力をずっと得やすくなる。

そして、プロジェクトが始まる前から、「最初の１～２か月間は進捗は遅いです」と予言しておこう。DevOps に関わらずアジャイル開発では一般的にそういう傾向になる。実際に言っておかないと、後出しになると、周りの人は心配するので
介入したくなってしまうのは無理がない。だから「予言」をしておくことによって、その間は安心できるのだ。ちゃんと「長期的に成功するために早めに失敗する」という考え方を話しておこう。

4. DevOpsプレゼンテーション + Value Stream Mapping

　次にValue Stream Mapping だ。Value Stream Mapping は、例えば「ソースをコミット」してから、それが本番環境に「デプロイ」されるまでに、どのような工程があり、どの程度の待ち時間と、価値を付加する時間を
持ったプロセスがあるのかを見えるかしていくワークショップだ。これを「Dev / Ops / Biz」の３者を集めて実施する。３者を集めて、可視化するだけでも、今までの工程が見える化され、無駄が浮き彫りになる。そして、その
改善方法を３者で実施すると、かなりの勢いで改善の候補が見つかる。私もValue Stream Mappingを頻繁に実施しているが、効果には毎回驚かされる。私があれこれ指示しなくても、これを実施した人が「ここって、無駄だよね
自動化できるんじゃないか？」とか「ここで承認があるけど、正直形骸化していて意味がないんです」と現場のメンバが言うとトップマネジメントが「そんなの僕は望んでいないから、そんなレビューは無くそう！」とその場できまったり
これは、相当な効果がある。何より、外部のコーチがいうのではなく、「本人ら」が考えて決めていくことに価値がある。
自動化が出来そうか否かは事前に、DevOps のプレゼンテーションをやっておいて、「この技術 / プラクティスが使えそう」とヒントを得ておいていただくのがよいだろう。
　こういった導入で、人を巻き込んで実施していくときに重要なことは「相手を理解する」こと。そして、「私でも出来る！、分かる！、価値がある」と思ってもらうことだ。これはある意味勘違いでもよいが、それがない限り誰も協力してくれないだろう。これはコーチの実力の見せ所だ。
　例えば、私はこのワークショップの時にミラクルクエスチョンというテクニックを使う。最初に改善のアイデアを出してくださいといっても、日本人の場合、意見が出てくるの稀だだから、このように言う。

「なんでも叶えてくれるような、天使がやってきたとします。そして、あなたは、会社のルール含めて、すべてを変更する権利をもっていたとします。もしそうなら、どういうところが改善できそうですか？ほんのちょっとでもかまいませんよ」

といった質問の仕方をする。そうすると、いろいろなアイデアがでてくるのだ。Value Stream Mapping を実施することでプロジェクトごとの改善ポイントが明確になる。そして、デプロイのリードタイムの目標値を、Dev / Ops / Biz の３者で考えていくのもいい。ただし、KPIにはしない。目標値だ。あと、ロジカルに算出できないものにはしないこと。あくまでValue Stream Mapping の結果に基づくものであるべきだ。ただ、現在のリードタイムはしっかり記録しておこう。
何故なら、導入が進んだ後、どの程度成果があったかがわかりやすい。その後の上位マネジメントへのフィードバックやチームで盛り上がるのにも有効だろう。

5. ベンダー選定

　日本のエンプラの場合だと、内製に舵を取る場合であっても、リソース的にパートナーが必要なケースが多いだろう。そのケースだと、ベンダー選定が必要になる。ここで重要なのは、お付き合いがあるからといって、安易に今お付き合いしているベンダーさんにお願いしないことだ。

　なぜなら、長年お付き合いしているベンダーさんが、DevOps やアジャイルの技術や考え方に精通していることはほぼないからだ。彼らとの付き合いをやめる必要はないが、少なくともこのパイロットプロジェクトではやめておこう。
　時には、案件をとりたいがために「弊社はDevOpsもアジャイルもできます！」と受注前はいってくるかもしれない。しかし受注後に「リスクがあるので今回はやめておきましょう」とか言われるのがオチだ。
　しっかり、実際のその技術の実績があるところを集めてチームを作ろう。そうでないと、DevOps を導入するためのパイロットプロジェクトなのに、チームの内部に抵抗勢力ができてしまい、パイロットの意味がなくなってしまう。メンバーはこんな感じの基準で選ぼう

　・開発者：アジャイル開発の経験があり、テスト駆動開発、CI/CDの経験がある。もしくは少なくとも取り組む意思がある。

　　　　　 オブジェクト指向やソフトウェアエンジニアリングプロジェクトで使うアーキテクチャに関しての知見と実践が必要。
　・プロダクトオーナ：Lean Startup やUCDを熟知している、少なくとも取り組む気合がある
　・インフラ / 運用担当者：運用の知識、経験がある。クラウドベースの運用の経験。IaCが出来るメンバーが含まれること。他の人は少なくとも取り組む勇気があること。
　・テスト：テストエンジニアリングに関する知見との実践。可能ならテスト自動化の技法と経験

　運用も、現在のメンバーは検討メンバーに入れながらも、上記のような DevOps 時代の運用経験者をメンバーに加えることをお勧めする。Yahoo! JAPANさんでは、OpsのチームにIaC等の技術を浸透させたいときに、Devチームのエースを運用にコンバートして自動化を進めたという例もある。IaCの心理的壁は皆さんの想像する以上に高い。実際は技術的には超絶に難しいとかではない。むしろインフラ知識があったらできてしまう。ここでも「おれでも出来る！」と安心してもらうことが必要だ。
フルタイムで一緒にやってくれる出来る人が一人でもいると、全然「恐れ」が違うのだ。そうすると、加速度的に新しいことを学ぶのが面白くなってくる。

　このように書くと「上記のようなメンバー等集められないよ」と大抵は言われることが多い。しかし、実際に集めようとすれば意外と集まる。なぜかというと、あなたの会社以外はそういうメンバーを求めないからだ。
　また、優秀なメンツも「いままでお付き合いしているおなじみのベンダーさん」で探そうとするから、難しく感じるだけで、そのわくを取り払うと簡単に見つかる。どうするか？というと、アジャイルや、UCD、DevOps ののコミュニティに出かけるとよい。
　すると、パッションにあふれた優れた技術者がゴロゴロしていることに気づくだろう。あとは名刺交換をするだけだ。本当は目利きのできる人に聞くのがさらに効率が良い。その面でも DevOps コーチの存在は重要なのだ。

何？口座を作るのがめんどくさいって？じゃああなたに尋ねよう。

「君は一生Excel方眼紙を書いて非生産的な作業をしたいのか？それとも、世界を変えるようなサービスを作りたいのか？」

前者を選ぶなら、あなたは導入メンバーに向いていないだろう。誰もやってない道を行くときはある程度の覚悟が必要だ。
しかし、それは大したことの無い楽しい道だ。そしてチャレンジをものにして仕事をやり終えたときの爽快感は最高だ！　

6. 導入プロジェクトキックオフ

　キックオフはたまに「飲み会」と誤解されるケースがあるが、実際は、プロジェクトが始まる前にメンバーが最低限の共通認識を持つための場だ。プロジェクトの目的、意義、方向性、トレードオフなどを共有する。いわゆる「インセプションデッキ」と言われるものやそれに類するものだ。しかし、DevOps の場合「プロジェクト」というのもはばかられる。「プロジェクト」とは始まりがあり、終わりがある一定期間内の活動だ。サービスに「終わり」は無いはずだ。

人を巻き込んで実施するときには、全員がそのプロジェクトに適したスキルを持っているとは限らないので、スキルマップ等を作っておくのも良い。チームが考えて、自ら改善するようにしよう。DevOps の場合は、フィーチャーチームを構成しよう。Dev Ops QA Product Owner / Businesss をワンチームにして、コミュニケーションをとりやすくしておく。別に部門まで最初から移動させることはないが、最初の段階からチームに含んですぐに聞ける体制にしよう。
　そのフィーチャーチームに権限を与え、ユーザのフィードバックを得て、ユーザとコミュニケーションをして、詳細な戦略を変更する権限を与えよう。その文化を育てていくこと。メンバーが増えていったら、DevOps の基本的なプレゼンテーションをして、マインドセットを繰り返しお話しするのも良い。

また、チームメンバーで、Product Ownerだけでなく、Dev / Ops も交えてExperience Map, Jounery Map, User Story Mapping等をみんなで作り上げてもいいだろう。暗黙知含むチームの共通認識をもつこと、そして、Dev Opsの垣根を取り払うことで、いろんなアイデアが交錯し、自分が当事者意識を持てる効果も存在する。見えることは偉大なのだ。

7. プロジェクトコーチング / 教育 / 部門間調整

　DevOps は第二世代アジャイルと言われることもある。アジャイル開発が基本にある。それが、さらにOpsやほかのステークホルダに広まり進化したものと言える。本質はステークホルダが協調した、ソフトウェアライフサイクルの改善活動だ。
実際に座学でごねごねやるより、プロジェクトを始めるときにコーチングをしてしまうほうが手っ取り早い。
　コーチングをするときには、下記の内容をコーチしないといけない。DevOps コーチも一人でカバーできるとは限らないかもしれないが、随時専門家を呼んでカバーすること。

　開発者、QA : アジャイル開発のマインドセット、プラクティス、技術(TDD, BDD, CI, CD）,モデリング力、アーキテクチャ、 アジャイルプロジェクトの進め方
　インフラ運用 ：アジャイルプロジェクトの進め方、ツール、IaC、クラウド、コンテナ、Git等のモダンなチームワークフロー、監視、運用、テレメトリ
　プロダクトオーナー：Jeff Pattonの Product Owner技術、UCD、リーンスタートアップの知識
　　　　　　（尚、Jeff PattonのそれにはUCD、リーンスタートアップの考えも含まれていてお得）
　マネージャ　：アジャイルプロジェクトの進め方、リーンスタートアップなどの考え方、モデリング力

　一人ですべてカバーできる必要はないが、チームでカバーしよう。DevOps というと、Infrastructure as Code や、CI/CDのイメージが強くないだろうか？DevOps は第二世代アジャイルと言われるだけあって、「第一世代アジャイルは当然やってるよね～。」という前提なのだ。だから、それをまだ導入していない時はしっかりアジャイル開発を導入する必要がある。できていればそのままでよい。特に DevOps の場合は、プロダクションファーストマインドセットという考えがあり、本番にデプロイすることで、技術的にも、ビジネス的にも学んでいくというのが第二世代の大きなポイントとなる。そのために、企画やプロダクトオーナー

といった人にも、本番から学びを得て、改善や、方向転換を行うというマインドセットに変えていくことが求められる。
　今まで、じっくり考えて検討に検討を重ねて、本番に半年後に出荷、、、という世界から、デプロイするのは、仮説を検証して、いい方向性を見つけ出すためという「仮説思考バックログ」と言われる考え方にシフトするため、それらが発達したリーンスタートアップの考え方などを学ぶとよいだろう。プロダクションファーストで本番からデータをとって学ぶためには、テレメトリの収集や、重複するアラートをいかに減らすかなどの技術も必要になってくる。こんな広くてはとてもとても一人でカバーできるものではない。だからみんなで協力が必要なのだ。

　プロジェクトはアジャイル開発で回すとよい。Scrumを導入して回していけばよいだろう。教育に関しては基本的には、みんなが困っている部分で実施していくとよい。スクラムマスタや、スクラムプロダクトオーナー系の資格も取れる教育コースもお勧めだ。特にプロダクトオーナーの資格ではDevOps の場合、Jeff PattonのコースがUCDやLean Startupが含まれているので、DevOps に最適だろう。また、Janet氏のアジャイルテスティングの講座も、アジャイルのテストや自動化を考えるのに相当有効だ。

　余談だが、DevOps を実施するときには、チームに一人ぐらい「自動化屋」がいるとよい。テストの自動化や、CI / CDを活用していろいろ自動化する担当の人だ。担当じゃなくてもいいが、そういうテスト技法、自動化技法に強い人はこれからの花形だ。

　リリースマネジメントも最近のモダンなツールやクラウドを使うと、Blue Green Deployment やCanaryingが簡単にできたり、ビルド、負荷テスト、受入テストなどの自動化、QAや本番へのデプロイ、テレメトリの収集、BIによる可視化も本当に簡単にできてしまうようになってきた。もちろんそれでも技術的に最も難しい自動化のアクティビティであることは間違いない。片手間にできる感じではないとは思う。

　スクラムを導入すると枠組みに入っているが、「振り返り」を導入して、「改善活動」をプロセスに入れていくのは大変重要だ。これは、Devだけではなくて、チームで改善すること。このファシリテーションも DevOps の腕次第。しっかり頑張ってほしい。

8. ハックフェスト

　私はマイクロソフトの DevOps エバンジェリストに就任して以来、ハッカソンをずっと開催してきた。正直最初はHackathonが日本の特にエンタープライズの文化になじむかは相当疑問だった。しかし、実際に実施してみると、これは相当効率がいいことがわかってきた。
　例えば座学で、勉強すると、わかった気になる。数日すればすっかり内容は忘れてしまうだろう。ハンズオンはどうだろう？ハンズオンはすごくやった気になる。エラーなくなんとなく動作する。おー、俺出来るわ、、、でも数日後にはやはり再現できないだろう。理解しなくてもできるからだ。
　ハッカソンはどうだろう、実際にやると、動かないとか、引っかかるとかいっぱいある。でも、そういうことを、技術サポート付きでやると、動かなくてちょっとなやんだら、よく知っている人や仲間に聞ける。自分が悩んでるので、がっつり記憶にのこるし、動作するところまで頑張ろうとするので、「理解」をしようとする心が働く。

　実際に座学を受けても、自分で家でかえっていろいろ試さないと、その知識は身につかない。それを考えると、ハッカソンの期間だけとれば、その場で、理解や、実用のイメージについて体感できるなら、こんなに効率が良いことはない。ハンズオンも「理解する」意識をもってやればよいが実際はしっかり時間もかかるし、その１パスしかわからない。やらんと身につかないのだ。ハッカソンは、時間のない我々が短い時間で、できるだけ深く技術的な物事を理解する最短の道でもあると感じる。

　残念ながら、あまねくすべての人にご提供はできないのだが、マイクロソフトにとって、インパクトのあるいい事例になってくれそうなお客様がいて、Azureつかってもいいよー。という方がおられたら私までご連絡してくだされば、このハックフェストをご提供できるかもしれない。
　ハックフェストは、御社に我々のテクニカルエバンジェリストや、DevOps技術、コンテナ、マイクロサービスのプロフェッショナルと一緒に無料で御社向けのハッカソンを実施する企画だ。御社にカスタマイズした内容なので、相当に効率がいいのは保証付きだ。

　もし、御社が難しそうでも、たまに DevOps ハックフェストを実施したり、技術的負債（例えばきっちゃないコードのこと）を返していくためだけに、スプリントを実施するのはいいことだろう。結局、新しいことを学ばないと相対的に効率は落ちていく技術的負債が多ければ多いほど、返済にコストがかかる。つまり大変になってしまうのだ。

9. 評価 / 報告

　最後に評価 / 報告だ。これは意外に忘れられやすい。上位マネージメントには最低クオーターに１回ぐらい成果報告をするように組んでおくのがいいだろう。もっと頻繁なのがお好みなら頻繁に。
　Value Streming Mapで定義した、目指すべき姿に対してどの程度達成したか？御社で実施すべきDevOps / Agileプラクティスのうち何をどの程度達成できているのか？つまりチームの DevOps の成熟度を定期的にモニタして、それをむっちゃわかりやすくして、上位マネジメントやチームと共有するとよい。
そしたら、次はここについて頑張ろう！とかゴールが見えるようになってくる。余談だが、弊社でもDevOps成熟度モデルを測定できるWebサービスがあるので、是非活用していただきたい。
ただし、現在は英語バージョンのみ。もう少ししたら日本語版もできる予定だ。

10. おまけ

　じゃあ、導入するツールはどう決めるかって？基本的にはもちろん「チーム」が決める。以上。しかし、このような初めての導入の時で、プログラミングも初めて、、、みたいな時もある。そういうときは、ノーアイデアでも仕方がない。そういうときは、DevOps コーチや、IaCの技術に強い人が、推薦してあげよう。アジャイル以降のマネージメントスタイルは、ゴールを与えて「チームに考えてもらう」方向性が基本だ。あなたがマネージャなら、なんでも把握するよう頑張らないことだ。今の技術、仕様は既に人が一人でカバーできる分野ではない。それでもある程度の把握をしたい場合は、モデリング技術を覚えることをお勧めする。ただ、それでも技術面では、エキスパートには遠く及ばない。だから、彼らに任せる勇気を持つ。そして彼らをサポートするのだ。あなたの重要な仕事はチームが快適に働けるように障害をとりのぞいてあげること。そして、しっかり、各DevOpsの技術要素を持つ、技術イケメンをゲット
することそれが一番最初の仕事だ。他には、私も記事で書いたTarget社の導入事例や、マイクロソフトの事例も僭越ながら参考になるかもしれない。

是非楽しい DevOps ライフを！