👋

シリコンバレーのソフトウェアエンジニアは何が違うのか(2)

2025/01/19に公開

前回のシリコンバレーのソフトウェアエンジニアは何が違うのか(1) では、「なぜ良いコードを書く必要があるのか」ということについて投稿をしました。

1. 高速回転で開発しなければならない

シリコンバレーやベイエリアは世界中の企業の中からトップクラスのテック企業が集まっている地域です。昨今はテキサスなどの他の地域に移動する流れもありますが、依然として高い能力の人材が集まっている地域ではあります。

その理由として挙げられるのが、Google、Apple、Meta(Facebook)、Amazon、Microsoft(通称GAFAM)と呼ばれるような超巨大テック企業があるからです。高収入を得る人達が集中し、住宅や賃貸に対する需要が非常に大きい一方で、シリコンバレーの土地は限られているため、大規模な開発をしづらいです。そのため地価は他の地域に比べて高いです

企業としては良い製品を早く作りたい。そしてそこから利益を生み出したい。これがビジネスの根幹です。

では早く作るためにはどうすればよいか。答えは単純で、能力の高い人物を確保する必要があります。そのためには良い人材が多く住む地域に企業を構えるのが手っ取り早いです。(東京にソフトウェア開発の会社の多くがあるのも同じ理由です)。そうすると地価の高い地域に会社を開きますので、早く開発をしないとお金がショートしてしまいます。

また誰かが新しいアイディアを思いついたとき、世の中では大抵の場合、誰かが似たようなアイディアを思いついています。シリコンバレー周辺に居るスタートアップ企業の殆どは、このアイディア勝負で大きな投資をしてもらっています。なのでアイディアをなるべく早く形にして、お金を稼いで、投資家に返していかないとなりません。(そうしないと次の投資をしてもらえないので、お金がなくなって倒産します)

つまり会社が生き残るためには、お金を稼ぐ必要があり、そのためには早くアイディアを形にして世の中にリリースする必要があり、そのためには高速に開発する必要があるのです。

2. 自社開発の文化

早く開発するためにはどうしたらよいのでしょうか。答えは「自分達で開発する」です。
アメリカ企業の殆どは「内製開発」をしています。日本のように上流工程だけを大企業で行い、オフショアや下請け・孫請け企業で開発を行うというのは、殆どありません。

この違いは何かというと「コミュニケーションコストの高さ」というのを認識しているからです。
(コミュニケーションコストの高さが実感できない方は、こんな方法を試してみましょう。自分の頭の中にある絵を可能な限り、生成AIを使って再現してみてください。非常に難しいと思います。)

幸いにもシステムやソフトウェア開発をする場合には、仕様書を書けばよいです。
しかし規模が大きくなるにつれて、書かなければならない仕様書も増えていきます。そして1から10まで完璧に設計できる人などいません。必ずどこかで不整合が生じて、ウォーターフォールの下流段階で修正作業が発生します。不整合が発生すると、それを修正するために作業の遅れが発生します。
しかもようやく開発をしても、それがビジネス的にヒットするかどうかは世の中に出すまで分かりません。ヒットしなかったら、会社は潰れてしまいます。

そうならないためにも、開発しているプロダクトはなるべく早く世の中にリリースをする必要があります。リリースして、マーケットの反応を見ながら機能を開発していく。これがまさに本来あるべき「アジャイル開発(小さく作って試して改善する)」です。

そのような細かな軌道修正を行うためには、自社で開発するのが一番です。自社で継続的に開発をしていれば書かなければならない仕様書の量は最小限ですみますし、知識も蓄積されていきます。それが自社の強みになっていくわけです。

3. One pagerとDesign Doc

シリコンバレー企業で言われるのは「ドキュメントは短ければ短いほど良い」ということです。
ソフトウェアやシステムを開発していけば、当然ながら新しい機能の追加や機能変更を行います。変化するのに詳細なドキュメントを残しても数年後には使い物にならなくなります。

ここで象徴的なのが、One PagerとDesign Docです。日本の仕様書で該当するのは「要件定義書(外部仕様書)」と「内部仕様書」です。

「なんだ、同じじゃないか」と思うかもしれますが、量が違います。

One Pagerは、Letter用紙1枚です(A4用紙1枚と同等)。
Design Docは少々ボリュームが増えますが、それでも数枚程度です。

One Pagerに書いてあるのは次のことだけです。

■ OnePager

  • 目的
  • 開発の背景
  • 機能の概要
  • ゴール
  • 今回の開発ではやらないこと

自社で継続的に開発をしているので、これだけで十分なのです。不明瞭な点はミーティングをして決めるか、書いた人に聞けば良いわけです。

日本のように外注をしていたら当然これでは成り立ちません。1から10まで完璧に指示書を書かなければ作業が滞ります。これは似たようなものを作り続ける場合には有効かもしれません。「完璧な指示書」があれば「数の論理」で並列作業をすることができ、大きなシステムを短期間で作れます。

ですが「完璧な指示書」を書くのは非常に困難です。ましてやマーケットニーズが刻一刻と変化するような環境で機敏に開発の方向修正をしていく必要がある中では不向きです。

ならばドキュメントとして書く量は最小限にして、さっさと物を作ってしまおう、というわけです。そこで失敗しても小さい失敗なら軌道修正も簡単です。ウォーターフォールで「完璧な指示書」に従って「完璧な製品」を作っても、マーケットニーズがなければ失敗してお金を稼ぐことができません。そしたら会社は倒産してしまうわけです。

なので、なるべく早く開発をして早くリリースをする必要があり、そのためには仕様書なんてものは極限まで簡素化する、というのがシリコンバレー流です。

(でもこれを”いわゆる日本企業・組織”に「納品物」として提出すると、「あいつらは仕様書の書き方も知らない」と言われますので、日本でこの文化を取り入れるならば、会社内用と納品物用と分ける必要があるかもしれません)

4. 多生多死の文化

Googleには何万人というソフトウェアエンジニア、Alphabet全体ではさらに多くのソフトウェアエンジニアがいます。公式に何人という数字は発表されていませんが、とりあえずたくさんいます(元Google社員の方によると、Alphabet全体で多く見積もって5-6万人くらいだろう、とのこと)。一般的には難しいと言われる試験を乗り越えてきた世界中の優秀なソフトウェアエンジニア達が集まった集団です。

そんな彼らはお金をもらっている以上、何かアウトプットを出す必要があります。アウトプットの形は様々ですが、やはり開発で一番楽しいのは、自分達が考えたアイディアを作り、世の中にリリースしていくときです。

Google社内での1チームの平均人数は7人、多くても10人程度と言われています。その各チームがそれぞれアイディアを考えて開発をしたらどうでしょうか。とてつもない数の製品が生まれてきます。でもGoogleからそんなにたくさんの製品やサービスがリリースされているか、というと、そんなことはありませんね。それはGoogleから世の中に製品をリリースするためには、まず社内での競争を勝ち抜く必要があるからです。

優秀な人達が、たくさんの製品を作り、社内での熾烈な競争を勝ち抜き、ようやく外の世界にベータ版としてリリースできるようになります。そしてその状態で数年勝ち抜いて、勝ち残った製品だけがようやく「正式版」のサービスになることができるのです。
勝ち抜くためには多くのユーザーを獲得する必要があります。多くのユーザーを獲得するためには、常に進化をしていく必要があります。(進化が止まると途中でサービス終了になります)

Googleが生み出しては消してきたプロダクトにはGoogle+やGoogle URL Shortnerなど、枚挙にいとまがありません。これはGoogleだけでなく、他のビックテック企業でも同様のことが起こっています。

■終了したGoogleサービスとアプリがわかる「Killed by Google」
https://killedbygoogle.com/

競争を獲得するためにはどうするか。早く開発やバグ修正を行い、製品を安定させ、新しい機能を追加や改善していき、マーケットにリリースをして、ユーザーを獲得していく。
そのためには無駄な努力を徹底的に省く必要があるわけです。

Greek Alphabet Software Academyでは何を教えているのか

今回の投稿では、主に「ビジネスの側面から、開発サイクルを高速に回す必要性」に焦点を当てました。ソフトウェアエンジニア個人やチーム文化などがどう違うかについては、次の投稿で触れていきたいと思います。

Greek Alphabet Software Academyでは、主に元Googleエンジニア達を講師陣に、シリコンバレー流のプロダクト開発というのを中心に教えています。アイディアの出し方、ドキュメントの書き方、高速で開発する方法、運用する方法、など、その内容は多岐に渡ります。

この記事を読んで興味を持っていただいた方は、ぜひご連絡ください

Greek Alphabet Software Academy

Discussion