怠けることから始めるDevOps：Agile Japan 2016 レポート(4)

スピーカーの牛尾氏、野澤氏

コンサートを思わせる「DevOps！」コールから始まったこのセッションでは、DevOpsに関して

• 日本は世界から遅れすぎ
• がんばって追いつこうとしても、そもそも日本人的な働き方では到底無理

という、つらい事実がわかりました。
そして追いつくには、今までのやり方を変えるのではなく、日本人的な考え方を否定する必要があると感じました。

DevOpsは文化

DevOpsと聞いて、Infrastructure as CodeやContinuous Deliveryなどに始まる自動化が思い浮かぶ方が多いかと思います。
そうではなく、DevOpsは文化。ビジネス価値を早く届けるための人・プロセス・プロダクトの集合体であると牛尾さんは言います。重要なのは、どういったツールを使うかだけでなく、根底にあるマインドセットです。

そして、DevOpsはアジャイルを基盤としています。
よく言われる「10 deploy/day」は、それ自体に意味はありません。すばやく価値を提供し、フィードバックを得ることにあります。このプロセスを早く回すことで、ビジネス価値をすばやく提供し改善していくサイクルを回していくことに意味があるのです。
このプロセスは、反復的な開発を行うアジャイル開発として見ることができます。つまり、DevOpsを導入する前に、アジャイルのマインドセットを導入する必要があるのです。

日本文化はアジャイルに向いていない

残念なことに日本はアジャイルに向いていません。

調査によれば、海外のソフトウェア開発企業のうち95％がアジャイルを導入していると回答しているのに対し、日本では31％と大差がついています。
この数字は日本の遅れをどのくらい示しているのでしょうか。Chef社のAlex Vinyar氏は8年、マイクロソフトのDevOpsソートリーダーであるSam Guckenhimer氏は5年と言っています。彼らが見ている範囲が日本全体ではないので、もっと遅れていると捉えてよいのではないでしょうか。

Be Lazy —生産性に最も影響する考え方

さらに大変残念なことに、アリスター・コーバーン氏のサーベイによると、アジャイルの導入難度は日本が堂々の1位です。アジャイルが生まれたのは西洋文化であり、西洋文化と日本文化がかけ離れているためであると牛尾さんは分析しています。

なので、西洋文化にしましょう。今までのやり方をすべて捨てる必要はありません。抵抗を感じるかもしれませんが、日本的な考え方のうちアジャイルの導入を阻害するものを改善できればいいのです。

講演中の牛尾氏

ところで、ある調査によれば、米国の生産性を100としたとき、日本は半分近くの62という数字になるそうです。
これは、米国人が日本人の倍の活動をしているわけではありません。牛尾さんがインターナショナルなチームで気づいたことは、物量が違うことです。たくさんやるのではなく、なにが本当に価値があるのかを徹底的に考え、それだけに集中してこなす考え方です。

これが「Be Lazy」です。

Be Lazyは、日本人的な考え方とは正反対です。

• きっと全部やらないと意味がない
• 一生懸命努力すれば価値が出る
• みんなまだがんばっているから、自分もがんばらなければいけない

のようなことを、暗黙のルールとして受け入れることが日本では多いように感じます。
これらを受け入れることは、本当によいことなのでしょうか？本当に大切にしなければならないことを確認せず、これまでのやり方を受け入れたままで進めていいのでしょうか？
特に1つ目の「全部やらないと意味がない」という考えを捨てない限りは、アジャイルになれないと思います。

では、どのようにすればBe Lazyになれるのでしょうか。それがカラダメディカの事例として紹介されました。

カラダメディカのDevOps導入事例 —Be Lazyで打ち破る日本文化

カラダメディカは、医師や薬剤師などの医療従事者に24時間、医療に関する質問をできるサービスを提供しており、2015年に株式会社エムティーアイから独立しました。そのためか、ゼロスタートのスタートアップとは少し異なり、開発スタイルなどは旧来のやり方を踏襲、トップダウンな雰囲気がある現場だったそうです。その中で、非効率な作業をしているのではないか漠然とした不安があったと野澤さんは語りました。

効率化の支援を依頼された牛尾さんと野澤さんがまず行ったのは、バリューストリームマッピングです。
これは、仕事の始まりから終わりまで、開発の場合はプロジェクトの起案からリリースされユーザーの手に届くまでのフローとリードタイムを書き出す作業です。この活動は、一部の人たちで行うのではなく、フローに関わる全ての人で行うのが特徴です。こうすることで、思い込みがなくなり正しい現状を見える化できます。

バリューストリームマップから、リスクを抑えるための判定会議などのフローが多いことを見つけました。リードタイムを短くして効率化したいが、それでは品質やリスクを担保できなくなるというトレードオフになっていたのです。

そこで野澤さんは、納期と品質どちらが大切なのかを社長に直接確認しました。日本人の感覚だと、価値観をあらためて聞くことがはばかられ、聞いたとしても「どちらも大事」と言われると思うのではないでしょうか。しかし意外にも納期が大事だという回答を得ます。
この経験から、もっと早く聞いておけばよかったと後悔し、以降はいたるところに社長を巻き込んでいるそうです。

ここからは、バリューストリームマッピングで見つけた課題の地道な改善活動です。課題の一つ一つはさまざまな現場で陥りそうなものばかりです。バリューストリームマップをつくる際、関係者間で課題は共有できており、しかも優先事項を社長に確認したことで方向性が定まったのだと思います。そういった状況なので、無駄な摩擦が生じずに改善の意欲を高く継続できたのではないでしょうか。

がんばって怠けましょう

昨今話題のDevOpsは、技術だけではなく、開発者と運用者の閉じた範囲のことでもない、プロセス全体の問題を関係者全員で解決していく取り組みです。
カラダメディカの成果は、これまでのやり方を見直し、暗黙のルールを見直し、周りとの関わりかたを見直したからこそ、本当にやるべきことに絞り込めたのでしょう。

DevOpsやアジャイル開発に関するツールやプラクティスを導入したが、うまくいかなかったことはないでしょうか。もしかしたら使い方や利用する場面ではなく、チームの文化や考え方に問題があるのかもしれません。
本当にやらなければいけないことはなんなのか、やらなくていいことはなんなのかを見出すBe Lazyな活動こそが効率化なのだと思います。

文化を変える、これまでのやり方を変えるというのは精神的苦痛を伴う印象があります。つらいよりも、むず痒さを感じそうです。ですが、Be Lazyの考え方は比較的簡単に取り入れられると思いました。特別なツールは必要ありません。これまでのやり方を見直すところから始めればいいのです。
私は家庭の事情から定時で帰宅せざるをえなくなり、当初は、業務時間が短いために仕事を断ったり、残っている人がいる中で早く帰ることから、後ろめたい気持ちがありました。仕事の整理などでバタバタしていましたが、実際にはなんの問題もありませんでした。後ろめたく思う必要はなかったのです。

皆さんも、普段の仕事の中で満たさなければいけないこと、より簡単なやり方を探すことから始められるのではないでしょうか。その中で、物事の本質を考える癖をつけることが大切なのだと思います。

それでは皆さん、がんばって怠けましょう。

参考文献

• 「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」（牛尾剛、野澤英歩、2016年）

Agile Japanとは

• Agile Japanとは
• 公式サイト：Agile Japan
• Twitter：@agilejapan
• Facebookページ：Agile Japan

レポートコーナー

• Agile Japan 2016 レポート
• Agile Japan 2015 レポート
• Agile Japan 2014 レポート
• Agile Japan 2013 レポート
• Agile Japan 2012 レポート
• Agile Japan 2011 レポート