Toyota がウォーターフォールを使っている? – InfoQ Japan

Home » 04研究開発・生産・物流 » Toyota がウォーターフォールを使っている? – InfoQ Japan



原文(投稿日:2010/04/04)へのリンク

リーン(Lean)ソフトウェア開発はリーン生産方式にその着想を得ている。中でも Toyota がこの分野で,先駆者として行った活動の影響が大きい。その Toyota のソフトウェア開発部門が旧来型のウォーターフォールを使用していて,リーンソフトウェア開発では初期段階にある,と聞けば驚くだろう。Henrik Kniberg 氏が,リーン視察旅行について書いた 自身のブログでそれを報告している。氏は昨年,グループのメンバと共に Toyota を訪問した。面会したのはソフトウェア開発部門の責任者だ。

私たちはそこで Satoshi Ishii 氏に会うことができました。彼は自動車用の組込ソフトウェアを開発する Embedded Software Division のマネージャです。彼の英語は流暢とは言えないもので,私も詳細な内容を記録していませんでしたので,以降で引用する会話の内容には大意を書き直したものが含まれている点をお断りしておきます。

最初から “私たちよりあなた方の方が,リーンソフトウェア開発については詳しいと思いますよ。” と切り出されたのには驚きました。しかし,その後の話題はさらに興味深いものになったのです。

Henrik の Toyota 訪問は驚きに満ちたものだった。アジャイルソフトウェア開発技術について検討しているか,と彼らに質問したときのことだ。

私たちは Ishii さんに,アジャイルソフトウェア開発の採用を考えているか聞いてみました。彼はアジャイルのアイデアを気に入っていて,そちらの方向へ進んで行きたい,と答えてくれました。しかし彼らはアジャイルそれ自体を目標とは考えず,Toyota 式 – 忍耐と組織 – で実行しようとしているようでした。これにはあまり同意できません。

“私たちは TPS(=西側でリーンと呼んでいるもの) をソフトウェア開発にも適用しようと考えています。” という返答を聞いたときの私たちの表情が想像できるでしょうか。何しろ私たちは,リーンソフトウエア開発の聖地とも思う場所で教えを乞うためにここへ来て,驚きや感動さえ得られるものと期待していたのですから。

Toyota 開発チームの発見したものにはアジャイルの世界に相応しいものが多数あったが,中には正反対のものもあった。

大きな障害のひとつは,彼らが用いているソフトウェアアーキテクチャです。彼は詳細には触れませんでしたが,リーン/アジャイルソフトウェア開発を導入するにはアーキテクチャの大幅な変更が必要である,と説明していました。しかし私は順序が逆だと思います。すなわち,アーキテクチャの変更を反復的,漸進的に実現する手段こそが,リーン/アジャイルソフトウェア開発なのです。


彼はテストと障害の早期対応の重要性を強調していました。製造フェーズで発見された障害は,プロトタイプ段階で発見されたものの 50 倍の費用を必要とします。発見がそれ以降になれば,費用はおよそ 1,000 ~ 10,000 倍にもなるのです! 私は他でも同じような数値を示した研究を見たことがありますが,彼は下のような棒グラフを使って,実際のデータとして見せてくれました。

Israel Gatt 氏も,私たちが Toyota の現在の苦境から学ぶべき教訓を3つ 挙げている。

どのようなアジャイルメソッド – Scrum,リーン,かんばん,Crystal など – を実践するにせよ,上に報告されている Toyota の経験との接点として,次の3つを認識する必要があるでしょう。

  • Toyota 生産システムと同じく,ソフトウェアメソッドも上位の方針決定に支配された “乗り物” に過ぎません。方針が誤っていたら,それを補うことはできないのです。
  • 執拗に成長を追求することで企業が負う品質的/技術的な債務は,成長を通じて達成した利益を容易に超えてしまいます。成長による上昇可能性とその結果としての技術的負債は,表裏一体のものとして捉えるべきです。必要ならば Technical Debt on Your Balance Sheet (バランスシート上の技術的負債) で紹介されたテクニックを用いて,技術的負債を数値化するとよいでしょう。
  • 前項の数値化に加えて,The View From The Executive Suite (重役室からの視点) で紹介されている様々なリスクを評価しておくことも必要です。それがどれほど衝撃的であるか,ということは,Toyota 自身の経験が実感させてくれることでしょう。

Toyota がソフトウェアに関して抱えている現在の問題 について考えたとき,彼らが違う方法でソフトウェア開発を行っていれば,今日のような状況はなかったのではないか,と思わずにはいられない。






コメントを残す