伝説のパソコン:98FELLOW物語(16)ー開発管理のノウハウ(3)

開発管理のノウハウ(3)

3.外部の力を最大限利用し一気呵成にやる

PC98シリーズは「互換性維持」が金科玉条であり、その互換性評価のために1ヶ月以上の期間を費やし多大な工数を投入していました。
しかしながら、この互換性評価の仕組みは新製品の完成度・信頼度を上げる重要な関所となっており、国民機と言われたPC98シリーズの強みとなっていた組織能力の1つでした。

互換性評価は外部の3rdパーティの主要なソフトハウス(ISV)と拡張ハードベンダー(IHV)の数10社には、量産相当の量産先行機(PP機:PreProduction)を配り、ISV&IHV側にも互換評価を依頼していました。 
当然、社内でもソフト開発部門、SI(システム・インテグレーション)評価部門、および我々の装置開発部門(ハード主体)でも分散して実施していました。

 

ところが、98FELLOWの開発リードタイムは2ヶ月という超短期間であり、互換性評価に1ヶ月も掛けている余裕はありませんでした。

98FELLOWはDOSがメインのOSでしたが、それ以外にも、UNIX-OS(サーバーのOS)での互換性や拡張グラフを搭載したWindowsマシンとして互換性確認も必要でした。

そこでリードタイム短縮のために採った手法は次のようなものでした。考え方は「フロント・フォーカス(後工程の前倒し)」と「3rdパーティも巻き込んだ短期集中」でした。

 

一気呵成、力を結集

 

1.「味見」を早くやる

元来、互換性評価は後工程の量産直前の「量産先行機」でソフト部門、互換評価部門に依頼するルールとなっていましたが、そんなルールに拘っていては出荷日程がキープできません。

量産先行機の前段階のバラック評価機(正式なシャーシではなく手作り板金でバラック的に作った評価機)をソフト部門などにも余分に配り、互換性評価を全項目ではなく、基本項目のみ「味見」評価を先行し、
正式評価も後から実施する「2段構えの互換性評価」とする提案をして何とか受け入れてもらえました。

この結果、早い段階で問題を発見して設計変更にフィードバックすることができました。

 

2.外部を上手く巻き込む

ソフトハウス、ハードベンダーに集中互換評価フロアを提供し外部の互換評価を迅速に終わらせる策をとりました。

 

通常は主要なソフトハウス(ISV)と拡張ハードベンダー(IHV)に量産先行機をこちらから配布して相手先で評価をしてもらい、結果を随時レポートしてもらうやり方でした。

98FELLOWの時は2W程度の短期間で評価結果を出す必要があり、NEC側で互換評価の場所と機材を集中フロアとして用意して先方に出向いてもらい、評価時間の短縮と問題は直ぐに伝達される仕組みとして標準の半分の期間で互換性評価を終わらせることができました。

3.過去の経験を活かしてリスクヘッジを早くやる

過去の互換評価でよく問題を出していたソフトや拡張ハードがありました。
特にDOSのゲームソフトなどはグラフLSIの機能を最大限引き出すためにLSIのコマンドを直接使って職人芸的なソフトを作り上げていたものがあったからです。

新製品でCPUの性能が上がったり、バスクロックのタイミングが少し変わっただけでも動かなくなるゲームソフトもありました。

このような、リスクのあるソフト、拡張ハードをリストアップして、先ほどの味見評価で優先して評価を行うリスクヘッジ策を採りました。

昨今はWINDOWSやOFFICEなどAPも複雑化・大規模化し、個々のユーザーで発生したストールなどの障害はリアルタイムでマイクロソフトに通知され、毎日のようにUpdateがネットを通じて配信される時代になりました。

これは正に、上記の外部(ユーザー)を最大限活用してWINDOWSなどソフト製品の完成度を上げる仕組みで、バージョン・アップの名の元でバグ解決もでき、ユーザー先でのトラブルを未然に防ぐ方法として、また開発リードタイムの大幅短縮や開発費削減の面でも究極の上手いやり方です。

最近は安易に出荷後のUpdateに依存して完成度が低いソフトが出回っていないか逆に心配な面もあります。

ソフトウエアはこのようなUpdateの仕組みが有効ですが、ハードウエアはそうはいきません。場合によってはリコールで全数無償回収・改造などの大きな損失が発生しユーザの信頼感を損なうことにもなります。

従って、短い開発リードタイムで、かつ、量産までに如何に完成度・信頼度を上げられるかのノウハウが各企業の組織能力の差別化として重要となってきます。

 

Column:UNIX(サーバー用OS)のバグ(欠陥)を証明!

余談ですが、この互換性評価を通じてUNIX-OS(サーバー用OS)の非常に稀なケースの障害が発生しました。1週間連続運転してやっと1回発生する程度の間欠障害です。

原因がつかめないまま量産移管の日が迫っておりどうなることかと焦りを覚えました。

そんな折、府中の2OA事業部のH事業部長代理から、私に「大丈夫か?予定どおり量産開始できるだろうね。頑張ってくれ!」と励ましとともにプレッシャーの電話が入りました。私は「大丈夫です!」ととっさに答えましたが、内心は気が気ではありませんでした。

その後、幸いにも当時のNEC新潟の優秀な技術者のM君が、評価台数を倍増し間欠障害の発生確率を増やし、粘り強く障害の発生ポイントを絞込み、遂にはロジックアナライザーで障害発生時のUNIX-OS(サーバー用OS)のポイントを捉えて「これはハードの問題と考えられない、ソフトが原因だと疑い、ついにはUNIX側に割り込み処理の潜在バグ(ソフトの欠陥)がある!」ことを証明して見せたのです。

このように当時の98Fellowの優秀な技術メンバー達の奮闘でギリギリで量産Goにこぎつけました。

後日談として、UNIXの開発元の米国のベル研究所に報告した際、UNIXのベル研究所は驚き、日本のハードの技術者が世界中で標準となっているサーバー用OS:UNIXのバグ(潜在欠陥)を見つけ証明したことに感心し、かつ大いに感謝されたことが記憶に残るエピソードです。

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です