伝説のパソコン：９８ＦＥＬＬＯＷ物語（１６）ー開発管理のノウハウ（３）
開発管理のノウハウ（３）
３．外部の力を最大限利用し一気呵成にやる
ＰＣ９８シリーズは「互換性維持」が金科玉条であり、その互換性評価のために１ヶ月以上の期間を費やし多大な工数を投入していました。
しかしながら、この互換性評価の仕組みは新製品の完成度・信頼度を上げる重要な関所となっており、国民機と言われたＰＣ９８シリーズの強みとなっていた組織能力の１つでした。
互換性評価は外部の３ｒｄパーティの主要なソフトハウス（ＩＳＶ）と拡張ハードベンダー（ＩＨＶ）の数１０社には、量産相当の量産先行機（ＰＰ機：PreProduction）を配り、ＩＳＶ＆ＩＨＶ側にも互換評価を依頼していました。
当然、社内でもソフト開発部門、ＳＩ(システム・インテグレーション）評価部門、および我々の装置開発部門（ハード主体）でも分散して実施していました。
ところが、９８ＦＥＬＬＯＷの開発リードタイムは２ヶ月という超短期間であり、互換性評価に１ヶ月も掛けている余裕はありませんでした。
９８ＦＥＬＬＯＷはＤＯＳがメインのＯＳでしたが、それ以外にも、ＵＮＩＸ－ＯＳ（サーバーのＯＳ）での互換性や拡張グラフを搭載したＷｉｎｄｏｗｓマシンとして互換性確認も必要でした。
そこでリードタイム短縮のために採った手法は次のようなものでした。考え方は「フロント・フォーカス（後工程の前倒し）」と「３ｒｄパーティも巻き込んだ短期集中」でした。
１．「味見」を早くやる
元来、互換性評価は後工程の量産直前の「量産先行機」でソフト部門、互換評価部門に依頼するルールとなっていましたが、そんなルールに拘っていては出荷日程がキープできません。
量産先行機の前段階のバラック評価機（正式なシャーシではなく手作り板金でバラック的に作った評価機）をソフト部門などにも余分に配り、互換性評価を全項目ではなく、基本項目のみ「味見」評価を先行し、
正式評価も後から実施する「２段構えの互換性評価」とする提案をして何とか受け入れてもらえました。
この結果、早い段階で問題を発見して設計変更にフィードバックすることができました。
２．外部を上手く巻き込む
ソフトハウス、ハードベンダーに集中互換評価フロアを提供し外部の互換評価を迅速に終わらせる策をとりました。
通常は主要なソフトハウス（ＩＳＶ）と拡張ハードベンダー（ＩＨＶ）に量産先行機をこちらから配布して相手先で評価をしてもらい、結果を随時レポートしてもらうやり方でした。
９８ＦＥＬＬＯWの時は２Ｗ程度の短期間で評価結果を出す必要があり、ＮＥＣ側で互換評価の場所と機材を集中フロアとして用意して先方に出向いてもらい、評価時間の短縮と問題は直ぐに伝達される仕組みとして標準の半分の期間で互換性評価を終わらせることができました。
３．過去の経験を活かしてリスクヘッジを早くやる
過去の互換評価でよく問題を出していたソフトや拡張ハードがありました。
特にＤＯＳのゲームソフトなどはグラフＬＳＩの機能を最大限引き出すためにＬＳＩのコマンドを直接使って職人芸的なソフトを作り上げていたものがあったからです。
新製品でＣＰＵの性能が上がったり、バスクロックのタイミングが少し変わっただけでも動かなくなるゲームソフトもありました。
このような、リスクのあるソフト、拡張ハードをリストアップして、先ほどの味見評価で優先して評価を行うリスクヘッジ策を採りました。
昨今はＷＩＮＤＯＷＳやＯＦＦＩＣＥなどＡＰも複雑化・大規模化し、個々のユーザーで発生したストールなどの障害はリアルタイムでマイクロソフトに通知され、毎日のようにＵｐｄａｔｅがネットを通じて配信される時代になりました。
これは正に、上記の外部（ユーザー）を最大限活用してＷＩＮＤＯＷＳなどソフト製品の完成度を上げる仕組みで、バージョン・アップの名の元でバグ解決もでき、ユーザー先でのトラブルを未然に防ぐ方法として、また開発リードタイムの大幅短縮や開発費削減の面でも究極の上手いやり方です。
最近は安易に出荷後のＵｐｄａｔｅに依存して完成度が低いソフトが出回っていないか逆に心配な面もあります。
ソフトウエアはこのようなＵｐｄａｔｅの仕組みが有効ですが、ハードウエアはそうはいきません。場合によってはリコールで全数無償回収・改造などの大きな損失が発生しユーザの信頼感を損なうことにもなります。
従って、短い開発リードタイムで、かつ、量産までに如何に完成度・信頼度を上げられるかのノウハウが各企業の組織能力の差別化として重要となってきます。
Column：ＵＮＩＸ(サーバー用ＯＳ）のバグ（欠陥）を証明！
余談ですが、この互換性評価を通じてＵＮＩＸ-ＯＳ(サーバー用ＯＳ）の非常に稀なケースの障害が発生しました。1週間連続運転してやっと1回発生する程度の間欠障害です。
原因がつかめないまま量産移管の日が迫っておりどうなることかと焦りを覚えました。
そんな折、府中の２ＯＡ事業部のＨ事業部長代理から、私に「大丈夫か？予定どおり量産開始できるだろうね。頑張ってくれ！」と励ましとともにプレッシャーの電話が入りました。私は「大丈夫です！」ととっさに答えましたが、内心は気が気ではありませんでした。
その後、幸いにも当時のＮＥＣ新潟の優秀な技術者のＭ君が、評価台数を倍増し間欠障害の発生確率を増やし、粘り強く障害の発生ポイントを絞込み、遂にはロジックアナライザーで障害発生時のＵＮＩＸ-ＯＳ(サーバー用ＯＳ）のポイントを捉えて「これはハードの問題と考えられない、ソフトが原因だと疑い、ついにはＵＮＩＸ側に割り込み処理の潜在バグ（ソフトの欠陥）がある！」ことを証明して見せたのです。
このように当時の９８Ｆｅｌｌｏｗの優秀な技術メンバー達の奮闘でギリギリで量産Ｇｏにこぎつけました。
後日談として、ＵＮＩＸの開発元の米国のベル研究所に報告した際、ＵＮＩＸのベル研究所は驚き、日本のハードの技術者が世界中で標準となっているサーバー用ＯＳ：ＵＮＩＸのバグ（潜在欠陥）を見つけ証明したことに感心し、かつ大いに感謝されたことが記憶に残るエピソードです。
Follow me!
“伝説のパソコン：９８ＦＥＬＬＯＷ物語（１６）ー開発管理のノウハウ（３）” に対して1件のコメントがあります。