ソフト開発業務とTPS

1. Howを追求する業界とWhatを追求する業界

what::なにを作るか、How::いかに作るか、についての考察です。

欧米とくにアメリカは、whatを重視して新しいモノゴトを創りだそうという気風にあふれていると思います。

しかし、生産に関しては、日本の企業ほどHowを重視しているとは、思われません

これに対して、日本は、近年こそwhatを重視してはいますが、全く新しいモノゴトを創り出すことでは、欧米とくに

アメリカには、まだ遅れをとっていると思われます。

しかし、日本では、Howを重視する業界が多いようです。

とくに自動車・家電など耐久消費製品を作る業界では、品質・開発期間などで競争が激しく、Howを重視せざるを得ません。

食品・農業でもHowを重視する風土がもともとあります。

これらの業種では、Howにこだわった企業がよい業績を上げているように思われます。　

　 その一方、受注生産の業種は、受注契約時の競争が激しく、受注金額・納期を提案する段階でHowを重視していると思います。

ただ契約後の、実装時のHowを重視することが、利益を生み出す元となります。当然Howにこだわる企業がよい業績を上げることになります。

ここでIT業界ですが、IT業界は、変化が激しいこともあって、総じて、次に何を作るかを優先し、Howは2の次にしているように思われます。

ただIT業界と一口にいっても、取り扱っている分野は、多岐にわたっていますので、ここではソフトウェア開発・保守業務に限定したいと思います。

日本のソフトウェア産業全体の諸課題・諸問題は、多く論ぜられており、ここで改めて取り上げることはしません。

ただ、改めて認識してもらいたいことは、日本のソフトウェア産業は、Howを重視していないということです。

しかし、日本のソフトウェア産業が、世界に伍していくための必要条件は、「Howを重視する」ということであります。

2. ソフトウェア開発・保守業務へのTPSの適用の考え方

トヨタ生産方式(Toyota Production System、略称TPS、またはリーン生産方式）は、トヨタ自動車で発案された自動車生産の運用方式であり、他の業種にも拡がりをみせています。

IT業界でもソフトウェア開発にTPSを導入しようとする試みが幾度となくなされてきたが、なかなか上手く行ってないようです。

上手く行かないというのは当然と言えるのです。元々TPSは、機械を使って、作業を標準化し、繰り返し生産を行う工場から生まれた生産方式であり、コンピュータという機械こそ使っていますがライン化されていない個人中心のその都度異なる知的創造作業を行うソフトウェア開発業務には相容れないものだと思います。

しかしながら、Howを重視するといえば、TPSはその最右翼に来るものです。ソフトウェア開発にTPSをそのまま導入するのではなく、TPSの種々の形式・手法の元の考え方をソフトウェア開発業務に合わせた形に置き換えて適用することだと思います。

ソフトウェア開発に具体的に取り入れるTPSの基本考え方の項目とは下記のようなものである。(詳細は別途)

①見える化

②自動化

③ジャストインタイム

④無駄の排除

⑤平準化

⑥一個流し

⑦スケジュール管理

⑧知の共有化

⑧については、TPSではとくに取り上げられていないが、知的作業における「知の共有化」を図って

日本の得意なチーム開発を取り入れることが大事である。

3. TPS適用の不得意な分野

下記画像にあるように設計分野、IT分野、その他知的創造分野は「TPS適用の不得意な分野」であります。

その理由は、「目に見えない」「繰り返し反復作業ではない」「作業プロセスを機械化、自動化できない」

「工程内で品質を確保できない」などなどTPSでは手を出しかねる領域なのです。

さらに設計作業とprogramming に焦点を絞って考えてみます。

4. 設計とProgramming_標準化・機械化の難しい知的作業 

設計者とProgrammerは似ている所があります。両者とも高学歴で技術レベルが高く、知的創造活動をする誇り高い技術者です。

社長命令で業務改革を指示しても、その中身が伴っていない改革案では、面従腹背で直ぐに元に戻ってしまいます。

中身が伴っていない改革案とは何かというと、仕組みやルールを基幹とした改革です。設計者やProgrammerは、手数が増えることや面倒なことを嫌います。彼らはの手数をできるだけかけず、純粋に知的創造活動を追求したいのです。

設計者やProgrammerの手数を減らし、楽にさせることを内包した改革案であれば、設計者とProgrammerも乗ってきてくれます。

手数を減らし、楽にさせることが出来たものは、設計者にはCAD、ProgrammerにはPRAやスケジュール管理ソフトでした。

これで改革は定着し、非可逆的な改革となりました。

ホワイトカラーの業務改革は、IT改革から始めるとうまくいきます。

5. 目に見えない設計作業とprogramming

設計者がCADを使い始めて、プロセス改革は軌道に乗り始めましたが、問題が出ました。

CAD化以前は設計者が直接手書きで図面を書いていましたので、その図面を見れば、進捗度や問題点を発見できました。

ところがCAD化されると、設計マネジャーから苦情がでました。それは設計者が何をやっているかわからないということです。

Programmerが現在VisualStudioなどを使ってprogammingしているところを、projectマネジャーが見ても何をやっているかわからないという状態と同じでした。

そこでプロッターで随時図面出力したり、DigitalMockupやVirtualRealityに発展して、見える化が実現でき、設計プロセスの大変革が実現しました。

これに相当するprogrammingにおける見える化は、やはり上記のPRAやスケジュール管理ソフトでその役割を果たしました。

もちろんProgrammingを支援するためのIT改善は、継続的に発展させていく必要があります。