シリコンバレー的ものづくり – その2

昨日の続きです。

まずシリコンバレーのものづくりを見ていく前に、ちょっと1歩下がって「シリコンバレーは変化が激しい」と、よくみなさんがよく耳にすることについて最初に触れておきたい。一体どんな変化なのか詳しく語られた媒体をあまり見たことがないので、実体験をもとにあげてみる。

1. 朝令暮改(良い意味で)
ある日あるときのプロダクトマネジメントチームのミーティングで「Aという機能をいれよう」と決める。そして3週間後には「現在のディールの状況や競合の動きを見て、Bのほうがいいとわかったから、Aはやめよう」と決定されてしまう。その結果、開発してるエンジニアやQAの人々もそれに対応しないといけない。(対応できない人は2軍落ちか退場)

こういう針路変更・組織変更が四半期 or 半年に一度グローバルレベルで、US HQ内ではもっと頻繁にあったりする。

2. 早い新陳代謝
不要となったエンジニアはすぐさま別のプロジェクトへの移動か、他部署への転籍、もしくは転職を余儀なくされる。覚えにくい、発音しにくいインド人の名前をようやく覚えられたと思ったら、その翌週にはその人がいなくなっていたなんてことは普通。(また覚えなおしかよ)
一方で腕の立つエンジニアはしっかりお金をかけて探しており、 何人もの面接を抜けて月に何人か新しい人が常に入ってくる。うちのVPも、常々「ボトム10%は速やかに入れ替えたほうが良い」と公言する性質の人です。

3. Show me the money economy
以前の投稿でもちょっと触れたが、シリコンバレーの会社(上場・非上場にかかわらず)は、継続的に利益を出すことが至上命題。さもないと、投資家、市場からの厳しい矢面に立たされるわけです。 なので儲からない・うまくいかないとわかればそのプロジェクト自体からサーッと手を引きます。(その責任者のクビと共に・・)そこに何の未練も執着もなし。

さて、こういう組織的な性格があるおかげでウォーターフォール型の開発をしていたら遅くてたまらないし、機動力もない。では今主流はというと、「高速プロトタイプ型」とでもいう方向になっている。それを象徴するのが、いまやシリコンバレーの「当たり前」、”MVP手法”だ。これはMinimum Viable Productの略で製品として成り立つための必要最小限の機能を乗せた物、といえる。とにかくマーケット攻略の要件がそろったらそれをさっさと形にしたプロトタイプを作るのを猛然と行う。それを一旦マーケットに投げてみて、もらったフィードバックをもとに次のプロトタイプへ・・と、あまたあるWeb2.0系のサービスはほぼこの系統。

もっともWeb2.0系のようにユーザーが個人ならまだしも、顧客が法人になるような場合、さすがに100%高速プロトタイプ型でいくわけいかない。うちも含め大抵のシリコンバレーメーカーは現在Hybrid方式をとっている。つまり製品開発のプロセスで、ウォーターフォールと高速プロトタイプの使い分けを行っているのだ。

このMVPの姿勢はこの地に生きる企業の暗黙の了解なのです。無論全社すみずみまでそれが行き渡ってるところもあれば、一部のBUが先端的に取り入れたりと、具体的なImplementationについては各社の文化によります。

さてプロジェクトマネジメントの観点から見た場合、こうした高速プロトタイプが社内でボコボコと立ち上がっていると、個別のPMもさることながら、それがちゃんと会社全体の戦略と予算に適合しているか把握が難しい時がある。そこで登場するのがProgram Managerなる存在だ。

これも会社によって異なるが、当該タイトルを持った人がいる場合もあるし、BUのトップが兼任という場合もある。面白いのがProject management (以下PJM) とProgram management(PGM)の力関係。PJMはどちらかといえば決まったプロセスに利害関係者をカッチリのせるのがスタンスなのに対し、PGMはその方向性が戦略に合致しているならば別のPathもトライせよ、必要なら他のプロジェクトからリソース回したるというスタンス。そう、全く逆なんです。

でもこうした相反する力学がぶつかることで、議論が活発になるし論点の見落としが少なくなるのは事実。ただ、たまに議論が収集つかなくなります。(だからこそBUのトップが兼任して、最後は彼の鶴の一声で決めちゃったりする。)

ということで、ざっくりシリコンバレー的ものづくりについて概観を凝縮して書いてみたが、当然全ての観点について書ききれないので、それはまた別の機会に。

広告

シリコンバレー的ものづくり – その1

メンチカツ by パパ&次女

今日はメンチカツを娘と一緒に作ってみた。自分がゴハンを作るときにたいてい娘は「見た~い」、「お手伝いした~い」といってくる。これはこれでうれしいのだが、いかんせん3歳なので、できることが限られる。そんなとき、いかに料理のどの部分を任せるのか、一緒にやるのか、見るだけにさせるか考える必要がある。ポイントはDelegation(委任)の度合いに応じてTradeOffが発生すること。全部委任すればその工程は娘次第になり、一緒にやれば自分は他のことができなくなる。見させるだけにすれば「何やらせてくれる~?まだ~?」と娘は盛んにInterruptをかけ、ついには娘は飽きてしまう。夕飯までのタイムリミットはおよそ1時間。この間に1汁3菜の材料の下ごしらえから調理、盛り付け、食事開始というプロセスがある。フライパンで炒めるだけ系であればともかく、本日のお題はメンチカツ。一手間、二手間かかる代物だ。

気づいた人もいると思うが、料理は実はプロジェクトマネジメントに相通じるエッセンスを含んでいる。限られた時間とリソースでいかに成果をあげるか。目的の達成のために何に集中して、何に目をつむるか。どんなツールを選び、どこに適用するか。もちろんプロジェクトにも料理にも「段取り」というものがあるが、この投稿ではPMP(Project Management Professional) とかPMBOK (Project Management Body of Knowledgeで語られてるような教科書の内容を焼きなおしするつもりはない。

なぜか。それは旧来型のプロジェクトマネジメントによる「ものづくり」が、もはやシリコンバレーでは通用しなくなってきているからだ。特にウォーターフォールと呼ばれている典型的なソフトウェア開発手法では、シリコンバレーで展開される変化についていけなくなってきてるから。(日本でもそうかな?)

話を料理に戻すと、プロジェクトの完遂の観点から言えば、いかに「並列処理」をするかにかかってくる。なぜなら、時間が限られてるのでひとつひとつ順番にやっていたら絶対に終わらない。鍋に火をかけている時間、電子レンジで温める時間、次女に任せている時間、こうした時間に自分は他のことができる。要はいかに1品1品を「さっさと作る」ところに焦点を置けるか。もちろんここで味を犠牲にしてはいけないので、味付け、計量に関しては少々時間がかかってもやむなしと考える。でも玉ねぎを炒めるのに電子レンジを使えば十分で、わざわざフライパンでやる必要はないし、炊飯も一番最初に仕掛けとけば終了時には炊けている。(我が家は活力鍋でご飯を炊いています。電気炊飯器じゃありません。)

まーそんな感じで作っていくとちゃんと時間通りにできるのだ。完成したメンチカツもジューシーでうまかった~

さて、明日は今日の話をベースにシリコンバレーのプロジェクトマネジメントと「ものづくり」について書いていく。