CLOSE

アメリカ式ソフトウェア開発方式はどこへ向かっているのか(全3記事)

「カルフォルニアロールもお寿司なんだ」ぐらいの気持ちが大切 アメリカ式ソフトウェア開発方式はどこへ向かっているのか

Agile Tech EXPOは、アジャイル開発者やアジャイルに興味がある方向けのカンファレンスです。「Jenkins」の生みの親として知られる川口耕介がソフトウェアの開発文化について、日本とアメリカの違いやこれからの向かうべき方向について講演しました。最後は日本におけるソフトウェア開発について。前回の記事はこちら。

Hiringの武器

川口耕介氏(以下、川口):さっきちょっとDeveloper Productivity Engineeringの話をしましたが、僕はその人たちとやり取りする機会が多いのでその話をします。だいたいビルドスクリプトとかを書きたい人はある種一部の奇特な人たちなので、そういうのがうまく回り出すとやってくれる人たちがいるのは、なんかありがたいと思えるようになる。

だから飴的な側面もあるし、でも下手すると現場の人は自分たちが一番プロダクトのことをわかっているから一番いいものを使いたいとなるので、中央のやり方に従うことによるメリットと、独自の道を行くことのメリットとの間で常にちょっと緊張関係があるわけですよね。

中央のやり方に従うことのメリットがある程度大きくならないといつまで経っても村文化のままで、最初の分水嶺というか、臨界質量を超えてDeveloper Productivity Engineeringチームが作ったやつがある程度よくならないとうまくいかないんですよ。

多くの人たちは臨界質量を超えられないで苦しんでいますが、これは1回超え出すとものすごい勢いで進みます。例えば有名なのはGoogleとかで、Googleは社内でゴリゴリに独自のソースコード管理システムからビルドから全部自分たちで作っていて、それが圧倒的な生産的資産を今までに育んできています。

そうすると開発者の人があまりにも居心地がよくなっちゃって、なんでGoogleを辞めないかというと、この「うちのインフラ以外で仕事する姿が想像できないから」ということなんです。その中でも珍しくGoogleを辞めたエンジニアが外に行って真っ先に何をするかというとGoogleの社内にあったものを再実装するんです。そうやって発明されたものがいろいろゴロゴロしているじゃないですか。

そのぐらい社内に開発者の生産性を上げる資産が積み上がっていたら、それはなかなか他の企業はちょっとやそっとでは追いつかないということになりますよね。そうするとこれがHiringの武器になって、この差をどうやって埋めるのか、すごい心配になる。その勝者と敗者みたいなのがどんどんできあがっていくんじゃないか。そこが僕が今気になるところですね。

日本のビジネスの発想はProject Mindset

製造業とかも今はもうきっとスケールメリットがないと勝負できないので、例えば小さな会社がこれから自動車作るかというとたぶんならないですよね。ソフトウェアもこんな大きな生産性資産を社内で積み上げた数少ない会社だけがソフトウェア開発を牛耳って、他の人たちは何をやっても追いつけないという、そういう二極化が進んでいるような気がしなくないですか? 僕はそういう気がするんですよね。

そういう世の中がいいのかなと僕はちょっと不思議な気もするんですけど、現実に向かっている気がするんです。圧倒的ソフトウェア開発力を蓄えつつある会社が世界にいくつかあって、それらの会社にどうやって立ち向かうんだろうと。他の会社はどうやるの? となったところで日本の話に戻ってくるんですけど。

こういう文化は、日本のビジネスシーンでのソフトウェア開発文化とは違うんじゃないかと思います。むしろ僕はみなさんにおうかがいしたいんですけど、たぶん日本のビジネスの発想ではProduct Mindsetではなくて、便宜上ここではProject Mindsetというんですけど、たぶんソフトウェアというのは家を建てるようなものだと思われているんじゃないかなと思うんですね。

必要になるし、これがないと生きられないから会社にとって必要なんだけど、でもあまりにそれが難しすぎるから、プロの仕事だから誰か呼んで来ないといけない。だからそのプロを呼んで設計してもらって実装してもらったらそれを検収して「よし完成! これをしばらく使うぞ!」と。

しばらくしたらいろいろいじりたいことが出てくるので、そしたら時々は改装していくんだけど、それはまた別口の話でそのときに何やるか決めるみたいな、そういうことですよね?

日本的なやり方を極めていったら何かが生まれるかも

そういう考え方からスタートしたら自然とこの種の技能は常時必要な技能ではないということになりますし、社内に雇っておくにはコストが高すぎてもったいないから、必要なときに口利きのゼネコンみたいな人に依頼すると、あちこちから優れたスペシャリストを呼んできてくれます。そのスペシャリストが左官屋さんとか板金屋とかいろいろあるじゃないですか。

その人たちが必要なときだけワーッと必要な人数が一度に集まって、寄ってたかって作って、その時だけコストがかかるけど終わったらいなくなるからコストがかからない。それはそれで必ずしも悪いことじゃないと思うんですよ。

その仕組みだからできることもあるはずなので、高い並列度とか社員によって難しいし、現に今我々の会社でも同じような問題に直面していて、今すぐこれを作りたいと思ったときに人を雇うところから始めないといけないとなったら3ヶ月や6ヶ月後みたいな話ですよね。だから電話をかけたら呼んでくれる左官屋さんがいるのはすごいことだと思う。

それを活かす方法も何かあるんじゃないかと思うし、スペシャリストを必要な時に呼べるというのも商社みたいなスキルなわけで、そこに中間マージンが発生するのは当然だと思うし、だから僕は必ずしも多重請負みたいなのがおかしいかというとそうは思わないんですよね。

こういう仕組みになったら社員は会社を移動する必要がなくなるじゃないですか。どんどん個人に知識が蓄積されていくし、そうなったらすごい職人たちが生まれる気もするし、会社を動かないことによるコストが下がる部分は絶対にあると思うんですよね。

だからそういうのを活用していったら日本的なやり方に、これを極めていったらアメリカ式のやり方とは違う何かが生まれるんじゃないかという期待が僕としてはちょっとするわけです。

我々はどこへ向かっていくのか

でも一方で、この考え方の時にこれはどうするのかな? と思います。先ほど「組織の中に生産性の資産が」という話をしたんですけど、この方式だと組織の中に、ユーザ企業の中には生産性資産は積み上がらないわけなので、ソフトウェア開発の効率性がどれだけ上げられるかというものの上限のキャップが変わる気がするんですよね。

「職人の中にどれだけ技能が溜まるか」対「組織の中にどれだけ生産性資産が溜まるか」という。日本の大手SIerさんとかに行くとお客さんの現場の環境があまりにもいろいろ違うので、こっちの現場で知識を蓄えた、例えば左官屋さんが次のビルに行ってそのスキルを活用してパッとできるかというと、なんかそうなっていないような気がするんですよね。そうだとしたらヤバイ気がする。

そういう会社の中に生産性資産、子どもの周りに生産性資産を積み上げていかないという方式だと、アジャイルとかCI/CDとかの本質なところで齟齬がある気がします。そうだとしたらニーズだけ取り入れても働き方の分業の仕方が変わっていなかったらそれはうまくいかないですよね。だからこの辺どうするの? と。このままやったらよくないんじゃないの?

だから、じゃあそういう違いがあるんだということを話してわかった上で、じゃあここから我々はどこへ向かって行くのかというところが気になりますよね。冒頭にも言ったんですけど、別に「アメリカのやり方を日本に輸入しろ!」みたいな、そういうことを言いたいわけじゃないんですよ。

例えばクリスマスみたいに概念は日本に輸入されたんだけど、こっちでは家族で団らんするイベントなのに日本では恋人たちのイベントでみたいな、名前は同じだけどぜんぜん違うものになっています。それが日本の文化に取り込まれて活用されている例ですよね。

あるいはお寿司みたいに、日本から輸出されてアメリカに来たらカルフォルニアロールというぜんぜん別の食べ物になっていて、海苔とご飯の順序もひっくり返っているし魚じゃないじゃないですか。そういう「これお寿司なの?」という。そうしてその文化のバウンダリを超えたときにその換骨奪胎されて独自の進化をたどって、名前は残っているんだけど違うものになっているという例もいろいろあるじゃないですか。

何を換骨奪胎するか、もっと意図的に考える

でもそれとは逆にその昔、例えばヨーロッパの小さな国では軍隊は傭兵でみんなお金を払って必要な時だけ集めていたんですけど、どこかのタイミングで国民軍といって自分の国民の平民を兵隊にするということが起こるわけですね。

そうすると軍隊に対するインセンティブとか戦場を守らないといけないインセンティブとかが違うので、それで戦争に革命的な変化が起こって国民軍のほうがが傭兵軍より圧倒的に強いということがわかっちゃったので、傭兵軍を使っていた国がみんな滅ぼされた結果、今は国民軍しか残っていないみたいな。そういうこともありえますよね。

だからガラパゴス化するというか独自の道をたどるというのは多様性という意味ではすごくいいし、僕はそういうのも好きなんですけど、結局経済的活動なので何かの激しい競争にさらされるとそこで攻め滅ぼされちゃう可能性もないわけではありません。そういう例も実際にある。だからどっちにするの?と。

独自の道を行くのであればそれもすごくいいと思うし、このやり方はアメリカでやっているソフトウェア開発方式だから必ずしも良いとは思わないです。

だけど、でもそしたらその西洋的な技術の発展の潮流のうち、どこの部分をどう取り入れて、あるいは何を換骨奪胎してというのはもっと意図的に考えないといけないと思います。それを「アメリカでアジャイルはこういうことだから、日本でもこういうふうにアジャイルをやらないといけないんだ」と言ったら、それは原理主義でうまくいかなくなっちゃうじゃないですか。

だから「カルフォルニアロールもお寿司なんだ」ぐらいの大らかな気持ちでやっていかないといけないはずなんですよね。もしくはその日本的な技術の発展というのが日本的な良さを活かした、文化を活かした独自の技術の発展方向みたいなのがそこにあるはずで、この分業体制に沿った技術は何なの? というのをもっと追求していってもいい気がするし、誰かがそれをやっていくべきじゃないですか。

そういうのをやっているのは誰なの? というのがすごい興味あるので、「俺らのところでは日本式は恥だと思ってなくていろいろな取り組みをしている」という人がいたら、僕はぜひ聞きたいなと思っている。

あるいはこれがいわゆるガラパゴス化してこのままいくと滅びちゃうとなるんだったら、日本でも昔ありましたけど、どこかに出島みたいなのを作ってそこは上から下まで全部アメリカ式の開発方式を、あるいは西洋式の開発方式をやるみたいな、そういう取り組みが必要ということになりますよね。

出島を作っている人がいたら教えてほしい

その文化というのは結局体験しないとわからないんですよ。その部分だけ習って見様見真似でやっても、しみじみ感がそこでは得られないので、そうすると出島を作ってオランダから宣教師とかを呼んで、西洋式のソフトウェア開発をして、そこで学んだ人たちがそのソフトウェア開発のやり方を日本中に広めていくという。

福沢諭吉がアメリカ行って帰ってきたあとに真っ先に作ったのが慶應義塾大学という、そういうのと近い話があると思います。そういうこともやらないといけないはずだし、だとしたらそのためには出島を作るにはそれなりのいろいろな手助けが必要で、今ここでは雇用形態とかの話をしているのでこれは1つの企業の手に負える話ではないかもしれない。

ということになったら誰のちからがそこに必要で、どういうことを動かしていかないといけないのかというのを考えないといけません。幸い世の中は広いので誰かがどちらかに決めないといけないという話ではなくて、いろいろな人がいろいろなことをやればいいんですよ。

というので「この出島を作ったのは誰なの?」と。「俺のところでは出島を作っている」という人がいたらぜひ教えてほしい。

そういうことを考えている人もぜひ知りたいと思います。あとは個人にとってはこういうのをやっていくということの他に、船がこれから沈むと。沈むんだったらそこで踏ん張って努力することは社会にとっても個人にとっても損失なので「この船はもうダメだな」と思っている人がいたら僕はぜひアメリカにさっさと来てほしいと思うんです。

Sun Microsystems のエンジニアたちが広めたもの

星が死んで最後に超新星爆発が起こると、それで重金属とかがそこでできてバーンとそれが宇宙に広がっていくというのがあります。アメリカで働いていたSun Microsystemsという会社が10年ぐらい前にオラクルに買収されたんですけど、実質潰れたようなものでした。

そのときに中にいたエンジニアがいろいろなところに行って、その過程で今までの知見とか文化とかを持ち出していくんですよね。そうしていろいろな種が、今の時代だとウイルスが広がるみたいな感じで、もっとポジティブな意味で言っているんですけど、いろいろなものがあちこちに伝染して感染していくんですね。

そういうのはすごくいいなと思います。いろいろな考えるべきことがあると思うので、みなさんがきっといろいろなところでいろいろな取り組みをされていると思うので、ぜひそういう取り組みのお話を僕に教えていただきたいと思っています。

というぐらいの話で僕の時間がいっぱいになりつつあるので、今日これで終わりです。ありがとうございました。

司会者:すばらしいお話をありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!