「これが売れないはずはない」が売れない理由　ソフトウェアを作るのは子どもを育てるようなもの

ソフトウェア開発というのは文化

川口耕介氏（以下、川口）：今日はカルフォルニアからお届けしています。僕はなんだかんだ言ってアメリカに20年ぐらい住んでいて、その内15年間ぐらいはずっとソフトウェア開発の生産性について取り組んできました。

さらに直近の10年ぐらいはCloudBeesという会社でJenkinsとか、そういう感じでいろいろソフトウェア開発をしているみなさんを助ける機会に恵まれてきました。その中でいろいろ考えることもあって、Launchableという会社を作ったのですが、みなさんテストを書いているからわかると思いますが、「テスト時間掛かる問題」というのがあるじゃないですか。

ここ1年はそれに取り組んでいます。Launchableでは、日本で技術者のチームを募集しているので、もし興味がある人はメールアドレスとかにご一報いただければと思います。

それで僕の中ではずっと、ソフトウェア開発はどんどん大事になっていって……。ちょうどあれですよね。以前、東京証券取引所のシステムが落ちていましたね。ソフトウェアが回らないとそのうち本当に人死にが出るなと思っていたんですけど、どうやってそのソフトウェアの品質を保つか、みなさん苦労されていると思います。

特に僕の中ではCloudBeesでもLaunchableでも、メインの部分の主戦場はアメリカとヨーロッパですが、日本のソフトウェア開発についても何か手助けしたい・手伝いたいとずっと思っています。特に、故郷に錦を飾りたいなと思って。CloudBeesのときはいろいろやっていたのですが、なかなかうまくいかなくてそれがどうしてなのかな？　といろいろ考えていたんですね。

その中で1つ最近思うようになったのは、ソフトウェア開発というのは文化であるということ。なぜ「文化で」と言っているかというと、文化というのはいろいろお互いにつながりあった習慣から成り立っている1つの巨大なシステムなので、その文化の一部だけを取り出してどこかに移植しようとしてもあまりうまくいかない。そういうことが起こっているなと思ったんですよ。

一部の習慣だけを取り出してもうまくいかない

僕が子どもの頃は日米自動車貿易摩擦というのがあって、アメリカの自動車会社が日本に「どうしたの？　アメリカの車をもっと買え」と、「うちらの車が売れないのはおかしいだろ」みたいな話をしていました。でも、日本に住んでいると、「こんな大きい車はそもそも日本の道路では走らないし、停めるところないからうちじゃ売れないよ」とか思うわけですよ。

これが良い例だなと思います。車だけ見ていると「これが売れないはずないじゃない？」と思うんだけど、それを取り囲む全体の文化がシステムの一部だと思うと、例えば道路事情とか住宅事情とかそういうのをセットで考えたら、これだけ取り出してもうまくいかないよなと、なんとなく納得できると思うんですよ。

そういうことがソフトウェア開発の世界でも起こっているような気がして、僕はこの20年間アメリカのプロダクト開発に関わってきたので、ある種のソフトウェア開発文化みたいなのが存在すると感じています。幸いそれを近くで見ているので、それをお伝えできるんじゃないだろうかと。

逆に僕は日本であまりソフトウェア開発をした経験がないんですけど、それでもやっぱり日本には明らかに違うソフトウェア開発文化が存在しているなというのもわかる。文化が違うので、その一部の習慣だけを取り出して模倣しようとしてもうまくいかないということが現に起こっていると思っています。どちらがいいという話ではありません。

そういうことを言いたいわけではないんですけど、その「違う」ということをわかってもらうのと、アメリカ的なソフトウェア開発文化がどうできあがっているのかというのは、僕がお伝えできることなんじゃないかと思ったわけですね。

先ほど言ったようにその文化はいろいろなものから成り立っているので、どこを最初に説明するかが難しいところなんですけど、僕の中では便利どころをProduct Mindsetと呼ぶんですけど、ソフトウェアは生き物みたいなそういう感じの視点があって、それが一番の根幹なんじゃないかなと思うんですよね。

ソフトウェアを作るというのは子どもを育てるような活動

例えばサービスを作っている会社だと、たぶん生き物感がわりとあって、毎日ちょっとずつお世話をして少しずつ成長していくみたいなのがわかっていくのが感じられると思います。最近はビデオゲームとかもそうだという話を聞きました。リリース初日はむしろ戦いの始まりで、そこからユーザの反応を見てゲームをどんどんいじっていくのが、ゲームのビジネス上の成功の秘訣であるみたいな話を聞いて「そうかそうか」と。

それも生き物ですね。その昔のファミコンとかの時代はカートリッジだったのでリリースしたら終わり。あるいはCDに焼いたら終わりだったんですけど、そういうのじゃないんだなと。オペレーティングシステムだって今は毎日・毎週パッチが上がってくるわけですから、それもいわば生き物みたいなものだし。

そう思うと最近こちらで僕はProduct Mindsetと、ソフトウェアを作るというのは子どもを育てるような感じの活動で、そのために家事をしている。そんなふうに捉えている方が多いかなと思いました。それがたぶん一番大事な根底だと思うんですね。そうするとソフトウェアは1か所に留まることがないし、動かしておくだけだってコストと手間がかかるし、ちょうど人間が毎日ご飯を食べないといけないのと同じようなものです。

常に変化し続けるということになるので、そうするとその変化こそが本質だという話になるじゃないですか。ここのみなさんに僕はアジャイルなんて偉そうに語れることは何もないわけなんですけど、その辺がたぶんアジャイル的な考え方の根幹につながってくるんだと思うんです。できるだけ小さい、できるだけ小さなループの反復でソフトウェア開発を捉えるという、そういう考え方ですね。

そうしたほうがソフトウェア開発におけるリスクが小さくなるという知見があって、あまりに広く共有されているので、もはや僕はこれは「ソフトウェアの行為」と呼んでいいんじゃないかと思うんですけど、こういう考え方に自然と育児と結びついていくと思うんですよ。

その次の一歩をどうするかということに集中していて、それによる目先の変化はなんなのかと考えるというのがProduct Mindsetから生まれる自然な発想ということになると思うんですね。

このProduct Mindsetを体現する育児の総責任者みたいな人の職種があって、プロダクトマネージャーというんですけど、これも僕の印象ではずっとアクティブなソフトウェア開発における中核的な役割を担うようになったのは、ここ10年ぐらいの話なんじゃないかなと思うんです。

明日の宿題も大事だけど5年後のことも大事

だから一方で明日のご飯も食べないといけないし今日の宿題もやらないといけないしという短期的なゴールと、その一方で5年後はどこかの高校に受かっているとか、どこかのいい大学に入っているとか長期的な視点もあるじゃないですか。

それをどうやったら両方ともバランスしていくのかということを考えていかないといけなくて、明日の宿題も大事だけど5年後のことも大事。そのトレードオフをするみたいな。そういうことをやる仕事だと僕は思っているんですね。あとはお客さんへのインパクトを先に考えて、そのためにどういう順番で何を作っていったらどれだけビジネス上の大きなインパクトを出せるか、そういうことを考える必要があるじゃないですか。

それから、子育てというのは子どもも育つんですけど親が育つというのもあるじゃないですか。要するに子どもの5分先を行っているような感じで、昔は「大人って立派だな」と思っていたんですけど、実はそんなことなくて本当にちょっと先を行くだけなんですよ。

ソフトウェアプロダクトもそれぞれのプロダクトがぜんぜん違うし個性があるし、挙動とかもぜんぜん違いますよね。だからその子どもが、ソフトウェアが育つ周りで親が育っていくというのがとても大事で、だからその子どもに特有の、ソフトウェアに特有の知識の蓄積みたいなのが進まないといけない。その蓄積された知識に非常に価値がある。その知見があるから次のソフトウェアの改善ができていくということがあるんですよね。

それはやっぱり技術についても育児と同じようなことが言えると思っていて、だからそう考えているのでプロダクトマネージャーとか技術者とか、社員で雇用しようと基本的にはずっとやってもらうための役割みたいになっていて、だから教育とかそういう投資の対象にもなるし。

なぜ日本ではエンジニアの多重下請構造とかになるのかなとずっと気になっていて、いまだに僕はそれに興味を持っていてその答えを探し求めています。よく解雇規制がという話をする人も多くて、それもそうなのかもしれないですけど、じゃあこっちでそんな簡単にエンジニアの首をバサバサと切れるかと言ったら、まあそんなことはないですよ。

チームとしては長生きするが、個人個人は出入りが激しい

だから本当にそれだけなのかなというのが、僕としては今ひとつ納得しきれていないです。でもその契約形態とか雇用形態とか育児の関わり方みたいなのが違うというのが大きな違いかもと僕は思っている。それからあとは社員や働く人のインセンティブが何かというと、親のインセンティブが何かというと、必ずしも働く時間ではないんじゃないかなと僕は思っている。

むしろその結果へのインパクトだから、育った子どもがどれだけ大きなインパクトを社会に起こしてくれるかとか、あるいはビジネスに起こしてくれるかに興味があります。プロダクトの成功が次の社内の商品につながっていくというのが、時間で表れるとか成果物に対してお金を払うみたいなものとはちょっと違う文化を生む1つの理由になっているのではないかなと思うんですね。

なので「子どもが」「子育てが」という話をずっとしているんですけど、ソフトウェアプロジェクトというのはうまくいけば成功してけっこう長生きするじゃないですか。この辺でも10年、20年続いているプロダクトがいろいろあるわけですけど。でも親のエンジニアたちやプロダクトマネージャーたちはフルタイムの従業員で、そんなに長くは同じ会社にはいないですよね。

だから親のチームとしては長生きするんだけど、それを構成する個人個人はけっこう出入りが激しい。でもチームとしての一貫性というか一体性というか、それが一続きに続いていかないといけないという現実があるので、自然と属人性というか、その人にしかできない何かを排除していかないといけないなということになりますよね。

だからそういう論理のつながりで、知識あるいは知見を「集団的知性」と書いたんですけど、学んだこととかを個人の頭の中に留めるんじゃなくて、チームの中にどんどん還元して共有化していく必要がやむを得ず生まれるということなんじゃないかなと思うんですよね。

（次回につづく）