Pages

2014年8月1日金曜日

納品のない受託開発とリーン生産システム

Be.Cloud通信戌亥です。知人が
『「納品」をなくせばうまく行く ソフトウェア業界の”常識”をかえるビジネスモデル』という本を出版しました。 

「納品しない受託開発」が注目される理由を検証してみたいと思います。

◯ ガッツ・気合い・根性は知識があって始めて生きる
それは今から30年近く前のことになります。私は某メーカ系のソフトウェア会社に勤務しておりました。当時は大手通信会社の仕事をしておりました。いわゆるSIの仕事です。その通信会社の品質基準は日本ではトップレベルのものでした。要件定義、テスト、障害対応等々において様々な基準が決められておりました。

その基準に基づいた開発をしましたが、出来上がったシステムにはたくさんのバグがありました。障害が毎日のようにレポートされました。障害がでると、その原因を追求し、対策とパッチを作成し、何故発生したのかを説明しなければなりませんでした。その資料はいくつ作ったかわからないほどの量になりました。いつ終わるかわからないバグとの戦いは気の遠くなるような作業でした。

もちろん御多分に洩れず徹夜もしました。徹夜をしない時も最終電車で帰ってました。平均4時間ぐらいの睡眠で朝また出かけます。体力仕事です。若い時にしか出来ません。
倉貫さんが本の中で話してた、デスマーチと言えるかどうかわかりませんが、夜中寝ている時に天井にプログラムコードが浮かんだこともあります。

先日、脳の働きを教えてもらいましたが、寝ている時は常識を司る脳が休んでいるそうです。したがって、非常識の脳が働きを取り戻して、突然、「あのソースコードのあの部分が怪しい!」なんてひらめいたりするわけです。そして会社に行ってからそのコードを見てみると、確かにその箇所におかしな点が発見されるわけです。

私が前の会社を辞めて海外に行く直接のきっかけとなったのは、ガッツ・気合い・根性だけで、エンジニアが頑張っても限界があるということを知ったからです。私はバグを作りたいと思っているエンジニアはひとりもいないと信じております。なぜなら、バグを作って一番苦労をするのは、お客様でも、営業でも、マネージャでもなく、エンジニアだからです。そしてもっとスマートなやり方があるんじゃないかと考えたのです。

◯ 基礎学習と経験の両方がエンジニアを成長させる
結論、米国でコンピュータサイエンスという学問を一から勉強しました。今でこそ日本ではコンピュータサイエンスという学部がありますが、当時はあまりありませんでした。私が卒業した日本の某工学系大学にも存在していませんでした。私は電気科というコンピュータから近いように見えて遠い存在の学部を卒業しましたので、コンピュータの基礎なんてまったくなかったのです。

先日、あるセミナーで、次の様なことを話されていた方がいました。
「よく日本の大学を卒業した技術者は即戦力にならないと言われていますが、大学では基礎知識はしっかりと勉強しています。しかし、企業に入ると、先輩たちが相変わらず昔からのやり方に基づいてやっているため、その知識が生きないのです」

その方はユーザ企業のシステム部の方で、大学でも教えている立場の方です。私はその瞬間に大きくうなずいてしまいました。

米国の大学では、基礎理論から実践的な講義までありました。そしてその中で当時大流行りだったのが、オブジェクト指向でした。それは日本でWindows3.0がリリースされるともてはやされていた頃のことでした。

コンピュータソフトの世界はエンジニアリングがあまり発達していませんでした。今もそうだと思います。他業界、例えば自動車業界や建設業界はエンジニアリングの理論はかなり発達していますが、ソフトウェアエンジニアリングというのはあまりにも未熟だったわけですね。当時ソフトウェアもエンジニアリングしなければならないという問題意識がありました。そして、そうすることで、ソフトウェア開発ももっと生産性良く、品質の高い物になると期待していました。

エンジニアリングの理論は必ずしもアカデミックな世界から出て来るわけでは無いとわかったのはその頃でした。

◯ リーン生産方式との出会い
米国留学生活の終わり既に卒業が見えていた頃です。本屋さんに立ち寄ると1つの本が目にはいりました。人間余裕があるときにほどいろんな情報が目に入ってくるものです。22年経った現在でもその本の存在は忘れません。それはLean Production System(リーン生産システム)というタイトルだったと記憶しています。MITの教授が書いた本で、トヨタの生産システムのことを書いた本でした。92年頃ですので、内容はうる覚えですが、以下の様な内容だったと記憶しています。

リーン生産システムは、在庫をなるべく持たずに生産をするという考え方です。当時米国の自動車メーカーと日本の自動車メーカーの生産方式は違っていたのです。MITの教授が何故日本企業は強いのか?そしてそのヒントが生産方式の違いにあるということを徹底分析していたのです。

当時日本のメーカーは既に一つのラインで複数の車種が作れました。一方で米国のメーカーは、別の車種を作る時には、ラインに変更を加えてからでなければ作れませんでした。
これは消費者の購買行動が影響しているということを知りました。米国ではディーラーには新車の在庫があるのです。日本はディーラーには在庫がありませんでした。日本の消費者はディーラーにいって試乗車に乗り、気に入った車があれば色やオプションを決めて注文をします。そして2週間とか1ヶ月後に納車されます。

米国の消費者はデーラーに並んでいる車の中から気に入った車を選んで買って行きます。余談ですが、数年前にある自動車メーカーのCIOと話をしたときに、日本の販売システムを中国に持っていっても使えないといっていたので、それはどうしてですか?ときいたら、まさに販売の仕方が違うということでした。つまり、中国も米国方式でディーラーに在庫が存在するようです。

オーダメード型の生産からマスプロダクションへ、マスプロダクション型の生産からリーン生産方式へと変わる頃でした。

◯ 市場の要求がイノベーションをもたらす
この日本の顧客の購買行動の違いが、リーン生産方式というイノベーションを産んだのです。MITの先生が書いたこの本では、フォードがT型フォードで始めたマスプロダクションに匹敵するインパクトがあると書かれていました。

売れるかどうかわからない車をたくさん作るのではなく、車が売れてから作る方が効率がいいわけです。リーン生産方式では無駄を無くすことにより、ユーザのニーズにあった車をリーズナブルな価格で提供出来るのです。

「納品しないし受託開発」も同じ原理です。使われるか使われないかわからない機能をいくら作っても無駄になります。その機能が本当に必要かどうかを徹底的に議論をすると倉貫さんの本にも書かれてありました。そして、作った方がいいという議論になると、作ってみて、そして顧客の反応を見る。反応が良ければそれをさらに進めるが、悪ければやり方を変える。こんなことは、通常の業界では出来ませんが、ソフトウェアなら可能です。

私は当時この理論をソフトウェアに利用出来ないか?と考えていました。ソフトウェアは顧客毎に要件が違います。顧客毎に全く違う要件のソフトを作るのは、フォードがマスプロダクションというイノベーションをおこす以前の時代の自動車業界と同じやり方です。お客様の要件を一つ一つ理解しながら作って行くわけです。ソフトウェアでいえばスクラッチの受託開発です。

それに対してソフトウェアパッケージはまさにマスプロダクション型です。確かに生産効率はいいですが、顧客の要件一つ一つに対して答えることができません。機能を使う人にも使わない人にも同じ機能のソフトウェアが提供されます。

リーン生産方式は日本で生まれたイノベーションです。途中まで同じ工程で作り、後行程だけをかえて消費者のニーズの違いをカバーし、在庫と言う無駄をなくし生産をするというやり方です。ソフトウェアは限界原価がほぼゼロである為、在庫という無駄は殆ど存在しませんが、この考え方を使えば、お客様のニーズに答えながら、効率よくソフトウェアを開発することができ、品質も上がるはずです。

◯ クラウドスタイルとリーン生産方式
これまでリーン生産方式は消費者のニーズから生まれてきたということを説明しました。ITの世界では、これまではバックオフィス系のシステムに重きを置いていました。以前からある受託開発から、ERPパッケージへと変わって来たのは、バックオフィス系のシステムは、企業の競争力に直接関わる物ではなく、効率化や生産性向上といった側面の方が強かったからだと思います。

一方で昨今、ITを企業業績に直接貢献する方向に使われ始めています。クラウドシステムの多くは、顧客との直接的な関係をつくったり、eコマースなどの売り上げにダイレクトに結びつく様なITに使われることが多くなっています。「納品のない受託開発」の事例も幾つか出ておりましたが、ほとんどがビジネスに直結するITでした。この場合、ERPパッケージの様な、何処から導入しても同じ様な機能が提供されるよりは、他社に無い、しかしその企業の競争力には絶対に必要な機能が必要です。つまり、二つと同じシステムはないわけです。

そうなると、個々の顧客のニーズに合わせたシステムを格安で提供するには、マスカストマイゼーション型のソフトウェア開発が必要になります。
しかし、それを従来と同じ様なスクラッチ開発としてやっていると、高価な物になり、またスピードを重視すると品質も下がって来ます。そこで必要となるのは、あるシステムに特化したソフトウェア開発となります。

「納品のない受託開発」ではそれを、クラウドのインフラとRubyを使った開発としています。これは車でいうと、同じフレームから違う車種の車を作り出すことと同じです。ある意味、「納品のない受託開発」は一つの生産ラインを作るのと等しい考え方だと思います。もちろんフレームだけ同じであるといっても著しく生産性はあがりませんので、様々な共通部品が必要になるかとは思いますので、本の中には書かれていませんでしたが、その辺りがこの仕組みの本当の意味でのノウハウなんだと勝手に想像しています。

これまでのソフトウェア開発方法では出来なかったこと、つまり多品種少量生産型の考え方に近づける様なアプローチが「納品のない受託開発」であると思います。

最後に、倉貫さんの本の中では、顧客と徹底的に議論をするとありました。この「機能(What)」が欲しいのは、「何故か?(Why)」を確かめてから作るとありました。日本が生んだリーン生産方式というイノベーションは顧客のニーズに答えて生まれたものです。日本の顧客は確かに異常なほどカスタマイズにこだわります。しかし、この顧客のニーズに答える為の方法論(How)を生み出すことが出来れば、日本のソフトウェア業界は変わるでしょう。

0 コメント:

コメントを投稿