メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い

私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。

尚、これは所属会社の見解ではないことは明確にしておきます。

f:id:simplearchitect:20160618213729j:plain

サム・グッケンハイマーの一言

 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。

ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答していた。

 しかし、そんな考えを吹き飛ばすような事件が先日発生した。

 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダーだ。世界的にも著名で、多くの書籍を執筆し、世界最大のアジャイルカンファレンスでキーノートも務めた。そんな彼が de:code 2016で来日した。その時に数社の顧客訪問を実施し、私も数社のアテンドを手伝った。

f:id:simplearchitect:20160618214227j:plain

 私は彼といろいろ話をして大変勉強になったが、彼が帰国後送ってくれた議事録を読んで、ハンマーを頭で殴られたような衝撃的な一言があった。彼はエンタープライズ系の企業の方から「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」という顧客からの質問に対してこう答えたのだ。

「ウォータフォールは一切メリットがないので止めておきなさい」

普段彼はスーツは着ないがその彼が顧客訪問のためにスーツに身を包んでいたのに、こんなことを顧客に言い放ったのだ。その一文を読んだとき私は「ああ、本当は心の中でそう思っていたんだ、だけど、世間の目だとか、角が立つとか、炎上するのでは?とか仕事がなくなるのでは?とかそういうことを気にして自分は大人の態度とやらをとっていただけじゃないか」と気づいたのだ。つまり、本当の意見をいうことから逃げていたのだ。

自分の本当の心の中

 自分の心の中ではとっくに決着がついている。大規模だと、ウォータフォールしかない、基幹系はウォータフォールだとかいろいろ意見はある。では、所属会社のことで恐縮だが、マイクロソフト以上の大企業が日本のどこにあるのだろうか?マイクロソフトは、アジャイル化を終えて、さらに DevOps ジャーニーを進めている。

マイクロソフトじゃなくても、海外の他のTech系の企業のどこにウォータフォール押しの企業があるだろうか?

 海外で出版されている新しい技術系の本を見ても、アジャイル以降のノウハウがどんどんデファクトの考えになっており、それを実践したときに発生する課題について書かれている。 最近のどの本を見ても「この本ウォータフォールが前提だな」というのは見当たらなくなっている。ソーシャルコーディング等、アジャイルからさらに先の新しいパラダイムのプログラミングの習慣、文化の上に新しいノウハウが構築されている。

 統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている。

f:id:simplearchitect:20160529200718j:plain

マイクロソフトの面接での出来事

 私が、マイクロソフトの面接を受けた時にも、自分の現在の2つ上の上司が面接官だった。彼は面接の最初にちょっとびっくりした声で私に聞いた

Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か?

 私は正直に答えた。「そうだよ。特にエンタープライズ系で。スタートアップとか、サービス系だとそうでもないけど」

彼は相当びっくりしていた。別の機会だが、最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの!そんなの誰もやってないよ!」と本当に驚いていた。彼女は特にアジャイルや DevOps の専門家とかではない。

ウォータフォールを紐解いてみる

 ここでWikipediaでウォータフォールの項目を改めて調査してみた。定義のところにこんなことが書いてある。

Waterfall model - Wikipedia, the free encyclopedia

ウォータフォール開発モデルは、製造業や建築業に起源をもっている。高度に構造化された物理的な環境特に、あとで、変更があったときに著しく高価になるもしくは不可能になる環境だ。当時、ソフトウェアのフォーマルな開発手法が存在して居なかった。このハードウェアオリエンテドなモデルが、シンプルにソフトウェアに適用されたのだった(過去形)

という説明になっている。ポジティブで公平な記述をピックアップしてもこんな感じだ。

ウォータフォールモデルが向いているのは、スコープが固定されており、プロジェクトが固定的で、確実であり、技術が 明確に理解されているものである。

 今のソフトウェア開発にはとても向くとは思えない特徴になっている。私は20年以上この業界にいるが、そんなソフトウェア 開発プロジェクトにお目にかかったことがない。

 実際ウォータフォールモデルは、建築とかだと、素晴らしい成果を出しているところもある。私が昔訪問したあるお客さんが 言っていた。「私たちは80年代に作成したWBSをいまだに現役で使うことができている。でも、ソフトウェアだけはそうはいかないんだよな。」と。

ウォータフォールは起源から異なっていた

 さらにお話をすると、ウォータフォールの起源はどのようなものか?というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている。しかし、この論文を見ていただければわかるが、この時点でも、成功するためには、繰り返しや行ったり来たりが必要であり、できれば2回繰り返しなさいといったことが書かれている。現在、日本でイメージするウォータフォールは起源の時点から異なるのだ。英語が苦手な人も上記のリンクを見ていただければ絵で描いているのでご確認いただけると思う。

http://image.slidesharecdn.com/holisticproductdevelopment-130312120839-phpapp01/95/holistic-product-development-35-638.jpg?cb=1424666807

 この後国防総省に広まったときに、なぜか「繰り返し」「戻りの線」がカットされて広まったという歴史がある。彼はとても悔しかったそうだが、その意思を受け継いで彼の子供が作ったのが、繰り返し型のRational Unified Process である。  ちなみにWikipeidaのWaterfallの項目を見ると、その後国防総省は、ウォータフォールを嫌い、イテレーティブで、インクりメンタルな方法に変更したとの記述がある。

ウォータフォールを前提とするのが本当に日本のためだろうか?

 ソフトウェアの専門家だったら、こういう歴史を知っている人も多いだろう。ウォータフォールのメリットを語る人も、こういうことを知らずに言っているのではなく、日本がウォータフォール前提にいろんな制度を作っていることや、要員、メンバーの慣れ、エンプラ系のプログラマのレベル、商習慣、日本文化の不確実性の忌避などの性質を考慮して、日本でやるなら、ウォータフォールで実施することも否定できないという考えを持つのもわかる。

 しかし、これらは、ソフトウェア開発の本質だろいうか?オブジェクト指向以降に生まれた技術を使ってソフトウェア開発を0から、何のしがらみもない状態から開発するとしたら、誰がウォータフォールを選択するのだろうか?そこに利点はあるのだろうか?

 今、時代はDevOpsやマイクロサービスの時代に突入している。リードタイムが短縮されて、1日に10回も100回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が15分で当て終わるような時代だ。

 しかし、日本の特にエンタープライズはいまだウォータフォールで、数か月以上のリードタイムになっている。こんなのでどうやって海外のベンダーと対等に戦うのだろうか?  まさに、竹やりで戦闘機と戦っているようなものだ。みんな竹やりの技術を必死に磨いているうちに、海外では、戦闘機でどんどん飛行時間を伸ばして、経験を積んで新たなノウハウを獲得している。

 人や人種の優秀さの問題ではないのだ。今までは内需で、飯を食えたかもしれないけど、本当にそんなのでいいとは思えない。海外の新しい方法、テクノロジーの経験を積んだ企業が乗り込んで来たら国内はむちゃくちゃになってしまう。

 私は人は変えられないと思っている。変えられるのは自分だけ。だから、このチョイスは人次第だと思うし、ウォータフォールを続ける人も特にダメだか、間違っているとは思わない。

方法は二つある。自分たちの「習慣・現状」に新しい考えを合わせるのか、新しい考えに合わせて「習慣・現状」を変えるのか。私は「習慣・現状」を変える方が本質だと思う。敵と戦うときに、余計な重りを背負ってどうやって勝てるのだろう?我々の価値は顧客にバリューを届けることが勝負で、「日本の事情」は誰も考慮してくれないのは当然じゃないだろうか?だから、「重り」を減らす方がよっぽど楽じゃないだろうか?

 だから、自分は、嫌われても、炎上してもいいから、ソフトウェアの専門家として、自分は現在のソフトウェア開発においてはウォータフォールは何のメリットも無いという意見であることを明確にしておきたい。

自分の恥ずかしい体験談 私はインターナショナルでは無価値である

 このように思い至ったのはSamの事件以外にもいくつかの事件があった。マイクロソフトに入る前に、私は外資系、できれば海外に住むことをターゲットに仕事を探していた。その時にある会社さんがいて、私のことを気に入ってくれた英国の企業があった。

私はアジャイルコーチとして、日本でよく遭遇しそうな課題について彼らと話をした。彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか?みたいな話をしてくれた。特に先進的なIT企業ではない。一般的なユーザ企業だ。私はただ、日本のブランチはそうなってないから、そこを助けてほしいみたいな話だった。日本では価値はあるのだが、海外のポジションで働こうと思ったら、私は無価値なのだ。彼らにアドバイスできることなどない。だって、日本の支援ではそのレベルの濃いアジャイル支援の経験できないのだから。

 一方、私は日本では自分で言うのもなんだが、アジャイル導入に関しては無敵といえるほどの適応力を見せていた。2003年にアジャイルをはじめて数年の自分が、ソルトレークのカンファレンスに行ったとき、私が請負契約の中でアジャイルをやるためにどんな工夫をしているか?などの話をすると、参加者の人はものすごく関心を持って聞いてくれた。日本でアジャイルの導入の時にテスト駆動開発が出来ない問題を解消するための、オブジェクトゲームという手法を、2011年にアジャイルカンファレンスで紹介したときは、米国以外の人は関心をもってもらえたが、米国の人からは「子供の教育にとてもいいね」とセッション自体はとてもほめてもらえたが、米国でのニーズのなさを感じた。つまり、私は日本で働いているから価値があるが、米国や英国に行ったら無価値なのだ。これは現時点でも自分の悩みでああるので解決するためにもがいているところだ。

f:id:simplearchitect:20160619084512j:plain

 私のアジャイル歴はおそらく米国の平均的なアジャイルコーチよりずっと長いだろう。では、なぜこんなことになってしまったのだろうか?それは「経験」だ。

最も深刻なことは、「経験」を積めないこと

2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった理由は、日本では「経験」を積めないからだと思う。アジャイルコーチとして、15年ぐらいやっていても、日本ではいつまでたっても「導入」なのだ。深い知識より、日本の商習慣の中で如何にアジャイルの能力を最大限に発揮できるよう「調整」したり足りないところを「埋めたり」する能力が必要だ。アジャイルの知識や、プロダクトオーナー、リーンスタートアップ、そして技術力よりもよっぽど必要とされる。多くの人はこれに気づいていない。私は「そっち」も鍛えているから、国内では活躍できるのだ。逆にせっかくアジャイルコーチとして深い知識をもつことに注力していても、そういう「寝技」的な技術がないため、実力を発揮できない人も多く見てきた。しかし、国際的には彼らの方が「価値」があるのだ。

 現在でも日本はアジャイルコーチングといえば、基本導入部分になってくるので、アジャイルコーチも導入ばかりの経験になってくる。アジャイル(2001)->アジャイルスティング(2009)->継続的デリバリー(2009)-> DevOps(origin 2009)に移っていったチームをずっと面倒見て経験をつめているアジャイルコーチは、一部のインハウスの人だろう。それは、アジャイル実践企業(31%)の中でも10%以下に過ぎない。スタートアップや、サービス系だと、そういう企業もあると思うが、エンタープライズ系だと今からアジャイルというのも非常に多いと思う。 

simplearchitect.hatenablog.com

 アジャイルコーチ以外のロールの人もそうだ。ウォータフォール文化で開発を続けている人は、技術的負債をなくすための、新しいコードの考え方や書き方、新しいチームのコラボレーションやワークスタイルを経験することができない。マネージャの人は、米国では「オールドファッション」と呼ばれるコマンドアンドコントロールと呼ばれるスタイルのマネジメントスタイルしか経験できず、モダンサーバントリーダーシップ型のマネジメントの経験を積むことができない。Opsの人だってとっくに塩漬けになったような技術のお守りをマニュアルベースの手動で運用するのにいっぱいいっぱいで、自働化されたような最先端のモダンな、運用環境や、開発やビジネスとのコラボレーションの経験を積むことができない、企画の人も、本番から頻繁にフィードバックを受けて、企画や、戦略を洗練させていく仕事の経験を積むことができない。これこそが最も深刻な問題だと思う。なぜならこうなると差は開く一方だからだ。経験だけは、お金を払っても解決できない問題なのだ。

日本はソフトウェア開発の後進国

ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた。この差は年々広がっていると思う。経験というのは短縮できない。彼らが戦闘機の経験を積み重ねている間、竹やりの経験を積み重ねても、戦闘機に乗れるわけではない。  あるとき気づいて戦闘機に乗り始めたとしても、その操作になれるのには、やはり同じだけの経験が必要になってくるだろう。

 私はインターナショナルチームに所属する経験から、日本人が彼らに劣ってるとは思わないのだ。それどころかイケてるところがいっぱいある。仕事を一生懸命やるし、イノベーティブだし、世界に勝てる要素はゴロゴロある。もったいなすぎる。

 自分の素直な気持ちに従うと、なぜ明らかにソフトウェア産業後進国となっているのに、先進国のことを学び実践しないのだろうか?

インターナショナルチームにいると、同僚がどんどん先に進んでいるのに、日本で足踏みするのは面白くなさすぎる感覚がある。

自分が目指すビジョン

 私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ。そして、Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい。そのようなスピードで動いている人も既にいる。きっとできるはずだ。みんながみんなそうならないと思うけど、まずはそうなりたいと思っているお客様や仲間と一緒にそのビジョンを実現していきたい。

 これは難しいことじゃない。単に「一歩」そっちの方向に足を踏み出すことだけでいいと思うのだ。数年後振り返るとそれはきっと凄い差になっていると思うから。