日本でアジャイル / 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」のことをちゃんと理解して実践したら、日本人は凄いことになると思う。心配しなくても、日本人の能力は高いし、思考回路も相当ユニークだ。伝統や文化など、必死にしがみついて守るものではなくて、結果として生まれるものだと思う。 日本人はいろんな考えを受け入れて成長してきたのだから今回もいけるはずだ。
普通に学んで普通に実践すれば、普通に進化する。なんでもそうだと思う。きっとそれを阻害してきたものは、我々が、「欧米の文化」の違いに気づいていなかったり、その因果関係に気づいていなかったのだろう。もちろんこれはまだまだ仮説に過ぎないので、今後も検証していくつもりだ。
私は間違ってるかもしれないが、多くの人が一生懸命日本のソフトウェア産業がよくなるようにいろんな角度から頑張っていれば、そのうち、日本のソフトウェア産業もグローバルの中で生きれるようになると思う。私も自分の出来る範囲で楽しんで探索していきたい。
