ソフトウェア開発の競争力向上 (黒岩 惠)

MIND-REPORT No.81 ( 2008.4 ) に、 トヨタ生産方式 ( TPS ) の高度情報化に取り組んでこられた 黒岩 惠 氏の文章が載っています。
トヨタ生産方式 / リーン生産方式 と ソフトウェア開発の双方を知っておられる先達の知見は貴重だと思います。

ソフトウェア開発の競争力向上

「あるべき姿を目指し、 改善しつづける人間集団をつくる」 をゴールとする TPS の本質は、 技術や方法論でなく、 人の改善力、 人的能力にある。
  人の知的産物であるソフトウェアの開発プロセスにおける生産性向上、 競争力向上に、 アメリカ流ではなく、 日本のものづくりのマネジメント手法である TQM や TPS、 海外で叫ばれるリーン方式を学ぶことで、 日本のソフト業界の競争力は向上するであろう。
  なお、 TPS のソフト分野への適用について、 日本にはまとまった書籍はない。 筆者が主宰している 「TPS ソフト研究会」 の仲間 （チェンジビジョンの平鍋君など） によるアジャイル / リーンソフトの米翻訳書などから学び、 自社の企業に合う方法論を確立することを期待したい。 変えないことが最も悪いことである。

TPS ( トヨタ生産方式 )、 TQM ( Total Quality Management )、 リーン生産方式といったものが、 大量生産の工場のためだけのものだ、 と思っている人は、 ぜひ全文を読んでください。

もう少し引用しておきます。

ソフトベンダにとっては、 顧客対応のソフトづくりという人月稼業に堕してしまうのも事実である。 ある意味で日本よりレベルの低い米ソフト業界は、 米製造業で普及していた TPS (リーン方式) をソフト開発プロセスに適用した。 リーン / アジャイルソフトとして、 Lean、 XP、 Crystal、 Scram などの開発方法論 (流派) が提唱され、 TPS のソフト開発方法論が日本に逆輸入され、 日本の企業にもリーン / アジャイル方式が試行されつつある。
しかし、日本の ICT 業界の学ぶ相手はアメリカばかりではなく、 今でも世界最強の日本のものづくり、 TQM などのマネジメント、 トヨタの TPS である。

本田技術研究所で 10年近く働いていた私は、 「TPS 最高!」 とは言いませんが… f(^^;
新型車の開発はウォーターフォールではなくアジャイルだというのは、 20年前でもそうでした、 とは言えます。 また、 インクリメンタル&イテレーティブです。

トヨタでは 「見える化」を 強調する。 しかし、 管理者のみを対象とする 「見える化」、 DFD や UML などシステム設計者同士が理解できる 「見える化」 は、トヨタの言う 「見える化」 ではない。

関係者全員が理解できるべきだ、 ということでしょう。
少なくともチーム全員が理解し共有できないようでは、  「改善しつづける人間集団」 を作り上げていくことはできないでしょうね。

19世紀初のフォード方式と同じウォータフォール型 (V字型同じ) で、 細分化された仕事による前時代的ソフト開発プロセスを取っている企業もまだ多い。 しかし、 ソフトウェアの最終顧客に対する付加価値業務は、 品質の良いコーディングだけである。 TPS 流に言えば、 分厚い設計図書は、最終顧客には付加価値はなく、必要なインシデント (付帯) 業務に過ぎない。

アジャイルの方でも、 「設計文書は仕掛在庫」 と言ったりします。 工程間で情報を受け渡すためだけに作る文書は、 顧客にとっては価値が無いですからね。

新車の開発は 500億 ～ 1,000億円の費用で開発期間は 1年前後である。 トヨタでは大部屋、 日産ではクロスファンクショナル組織による関係部門とのコラボレーションでコンカレント開発する。 建築やエンジニアリング業からではなく、 車や電子機器などの商品開発、 ものづくりの PM 手法や TQM などのマネジメント手法を学ぶべきである。

開発の開始と終了をどう定義するかによりますが、 1年というよりは、 まだ 2年のほうが近いはずだと思ってたけど… トヨタはそこまで進んでるのかな? f(^^;

ここで、 大部屋とかクロスファンクショナル組織とか言っているのは、 設計チーム・テストチーム・量産技術チームなど、 そのほか販売やアクセサリー開発や宣伝・広報まで、 連携して動けるような組織のことです。 新車の開発が終わって ( 図面が全部完成して ) から、 工場ラインの準備やアクセサリの開発に取りかかるのではなくて、 コンカレントに ( 並行に ) 仕事を進めていきます。
さらに、 協力会社のエンジニア ( ゲスト・エンジニア ) も一緒に大部屋で、 コンカレントに仕事をします。 部品の仕様が決まってから協力会社に発注が行くのではなく、  部品の仕様を決めるところからゲスト・エンジニアに参加してもらいます。
…と、 私が解説してる部分は、 20年前のホンダ流です。 このへんのやり方は、 少なくとも日本の乗用車メーカーのあいだでは、 みんな似てるようですね。

さて。 「ソフトウェア開発者は製造業のことを知った方がよい」 という話を聞かされたときは、 どこを喩えに使ってくるかに注意しましょう。 黒岩氏のように、 新車の開発が出てきたら、 ソフトウェア開発に応用が利くような話でしょう。 Matz 氏が聞いたのも、 そういう方面の話なんじゃないかな。 そうじゃなくて、 「自動車の製造ラインのように…」 なんてのが出てきたら、 耳を伏せてればいいです。 ( あ、 製造ラインを作ったり改善したりする話だったら、 聞いてあげて。 f(^^; )

良ろしくない方の例として、 製造業・工場・ラインといった言葉に引きずられて、 工場の製造ラインの流れ作業だと思い込んでしまっている記事を挙げておきましょう。

「工業生産の効率的手法」をソフトウェア開発に適用する
～次世代開発基盤技術“Software Factories”～

標準 （マニュアル） 化された作業手順、 別の場所で製造され運び込まれた部品、 組み立てのために必要な治工具 （ツール） 類が整備された工場ラインに似た環境であり、 業務システム （ソフトウェア） の開発現場においても同様のアプローチを取り、 標準化されたものを用いて作業を進めるようにすることで、 リードタイム （納期） と品質を確保することができるという考えである。 このアプローチは、 きわめて工業生産的であり、 生産現場においては日本を筆頭にあらゆる地域で成功をおさめてきた方法である。 Software Factoriesの目指すところは、 この 「ソフトウェア開発の工業化」 にほかならない。

これは、 工業といえばベルトコンベアで流れている生産ラインしか思い浮かばない人が書いたんだと思います。
実際の Software Factories とは、 同じ記事からの引用ですが…

実証されたアーキテクチャを強制することにより、 短期的に高品質なアプリケーションを開発することを目指している。

…というものです。 自動車製造業に喩えるなら、 上手くいった新車をベースに派生車種の開発をするようなものです。 たとえば、 シビックの設計をベースにストリームを開発するようなもの。 ボディの基本構造やエンジンなど、 シビックで実証されたアーキテクチャは基本的に強制されます。 基本構造への影響が少ない外観の変更や、 内装の変更、 そのほか細かいチューニングは可能です。  また、 派生車種であっても、 開発プロセスは ( 短縮されはするけど ) 基本的に同じです。

# この記事、 自家用車のフィーチャとして、 ボディーだのトランスミッションだのを挙げてくれてる。 いや、 ボディーやトランスミッションってのは、 ソフトウェアで言えばパッケージだとかアセンブリだとかといった括りだから。 f(^^;