← まえかわの、あたまのなか。

開発が速い会社は、分業しすぎない

設計、解析、実験を分業せず、専門家が一貫して担当し、同じ部屋で回す。SUBARUの開発の進め方を紹介した動画から、開発が速い組織について考えたことです。

先日、SUBARUの次世代技術を研究施設で体験する動画(LOVECARS!TV!さん)を視聴しました。車そのものの話も面白かったのですが、私もモノ作りをする人間として一番刺さったのは、開発の進め方でした。車の仕様ではなく、そちらの話をまとめておきます。

2年かかる試作を、1年で作る

動画によると、通常は2年かかる試作車の製作を、デジタル開発と「大部屋開発」を組み合わせて、約1年に短縮したそうです。大部屋開発とは、関係する部署の担当者が、同じ部屋に集まって、議論しながら進めるやり方のことです。孫子には、「兵は拙速を聞くも、いまだ巧久を睹ざるなり」という言葉があります。多少まずくても、速く動くほうが、巧みに長引かせるより、ましだ、という意味です。開発のスピードが、競争力に直結する時代だと思います。

デジタルだけに頼らない

印象的だったのは、デジタルのシミュレーションだけに頼らない、という姿勢です。現象を理解して、物理の言葉に落とし込み、性能を達成するシナリオを描き、デジタルで検証して、試作して、また検証する。この一連の流れを、高速で回しているそうです。計算だけで完結させず、現物で確かめるところまでを、素早く往復する。AIが進化して、机の上でできることが増えても、現物で確かめることの価値は、変わらないのだと思います。

分業しないから、速くなる

もう一つ、刺さったのが、分業の考え方です。解析、実験、設計を、担当を分けて回すのではなく、専門のエンジニアが、一貫して担当する。実際の衝突試験の結果と、解析モデルの結果が、高い精度で一致するのは、肝になる部分を理解した本人が、モデルを作っているからだそうです。分業すると、部署の間で、情報の受け渡しが発生します。受け渡しのたびに、待ち時間と、認識のズレが生まれます。一貫して担当することで、チームワークも生まれ、開発全体が速くなる、という話でした。

これは、ソフトウェア開発にも、そのまま当てはまると思います。要件、設計、実装、テストを、別々のチームに渡していく進め方は、人月を積み上げる構造とも相性がいいのですが、速さの面では、不利です。以前書いた「AIが壊すのは、受託開発ではなく人月商売だ」の話とも、つながります。

ちなみに、うちは小さな会社なので、分業したくても、人手が足りません。結果として、全員が一貫して担当しているので、「大部屋開発」の理想形に、世界で最も近い会社かもしれません。

もう一つ白状すると、私はSUBARUの大ファンです。ところが、これまで一度も、SUBARUの車を買ったことがありません。ファンなのに、お客さんではない。このブログを書いている暇があったら、まず買え、という声が聞こえてきます。

← 記事一覧へ戻る