スコットマクネリ

　全国七拠点を専用線のイントラネットでつなぎ、設計チームと試験チーム、計千人規模で五月雨式に、電話の新サービスを開発している。これを取材に来るようになった。開発規模や要員数など、よくある質問をホワイトボードに書いて取材専用にした。パネルは製作費が高い。数値は刻々変わる。手書きのほうがなにかと便利だし、開発現場の泥臭い感じが出る。
　ある取材の翌日、新聞を見て驚いた。ものすごい生産性が見出しになっていた。武蔵野時代のメーカの知り合いからも問い合わせがきた。生産性の大幅改善は事実だったが、その数字は記者の誤解だった。
　Ｓｕｎの社長、スコットマクネリもやってきた。Ｓｕｎワークステーションの大口顧客だったからだ。米国から客人が来るということで、総務がオフィスの整頓状況を事前点検にきた。私は、片付け不要と考えていたのだが、総務が直接指示して片付けた。確かに散らかってはいた。傘もジョギングウェアも干してある。狭い机の間には寝袋、床にカップ麺、まあ少しは片付けるべきか。
　ホワイトボードを英語に書き換え、一通りプレゼンした。だが、私はマクネリが誰だか知らなかった。足を組んで聴いていた大男が手を挙げた。「オブジェクト指向は使わないのか」Ｓｕｎはオブジェクト指向をＰＲしていたが、画像処理関連だ。私は即座に英語で「我々は新技術の挑戦者ではない」と答えた。男はふーんと私を見つめた。「頑固なレガシープログラマめ」と思ったろうか、「現実を知るプロ」と認めたか。どちらでも構いはしない。ここは流行りを追う研究所ではない。開発の現場なのだ。
　エレベーターまで送る途中、お付きらしい男が私の横に寄って来て小声で言った。「オフィスは片付けたろ」否定したが、「いや、絶対片付けたね」にやりとした。元の生活感あふれるオフィスだったら、「Ｓｕｎのパフォーマンスはどうだ」「発熱量が多いね」などと話題も変わっていたかもしれない。
　やったことばかり書いてきたが、実際には「やらない」決断が多かった。オブジェクト指向もその１つだ。研究所の新人のとき、先輩たちにオブジェクト指向をＰＲしたが、稼働している交換プログラムを書き直すまでの価値は見いだせなかった。のちにシリコンバレー支店長になり、ＳｕｎとはＪａｖａのライセンス契約を結び、オブジェクト指向にも取り組むことになる。
　ここからは、「やらない」決断を列挙しよう。当時、成功率七割以上が私の中での採用基準だった。研究なら５割以上だが、現場ではそうはいかない。
　交換機にもＯＳがあった。磁気テープからプログラムを二次記憶にロードしたり、立ち上げ直したりする簡単なプログラムで、「モニター」と呼ばれていた。これをＣＨＩＬＬで書き直し、交換機のＵＮＩＸにしたかった。ＵＮＩＸは多種のコンピュータを共通に操作することをねらった。
　プログラムの構造を変えることで生産性が上がるのではないか、という議論は、改良スタート以来ずっと続いていた。ソフトウェアの専門家が教科書を振りかざしてきた。私も入社したときには、交換プログラムの開発を見て「石器時代」だと落胆したものだ。マルチプロセス、仮想記憶、ハッシュ、オブジェクト指向など、最新技術をなぜ取り入れないと思った。いくつかは開発会議に提案もしたが、すべて却下された。おかげで勉強にはなった。だから、教科書によくある改良に飛びつくことはしなくなった。ゴミ掃除、障害処理、データ定義、巨大モジュールの再分割、割り込みプログラムの見直しなど、地味だが本当に効果が確信できる改良に厳選した。
　プログラムの設計法、ドキュメント記法の提案も多かった。武蔵野時代、あるドキュメント記法を試験導入することになり、新人の私がメーカを指導した。担当モジュールでも実際書いてみた。しかし、効果があるとは思えなかった。複雑な推理小説をフランス語に訳せば分かりやすくなるだろうか。フランス語は論理的らしい。得意ならそれもいいだろう。しかし、千人規模教育するのは大変だ。費用対効果でどうだろう。また、フローチャートのような図はメンテが大変だ。条件分岐が十個を越えると、もうかえって分かりにくくなる。
　詳細設計書は、ソースを日本語で説明しただけだが、やはり欲しいという人が多かった。しかし、バージョンアップ毎のメンテ工数は、開発全体の１割近かった。紙は廃止して、ソースにコメントとして含めた。抵抗はあったが、突破すると、詳細設計書をコピーして電話局に配布する作業がなくなり、喜ばれた。
　問題処理票のデータベースも忘れられない。バグを登録し、管理する、研究所が外注で開発したシステムだったが、使い物にならなかった。その日見つかったバグを、徹夜で入力しても終わらないのだ。（登録ボタンを押してから延々待つ）データベースに出たばかりのオラクルを採用していた。オラクルが悪いのか、Ｓｕｎの性能不足だったのか。外注との打合せに押しかけて文句を言ったが、無駄だった。あきらめて、ＣＳＶ形式のファイルでバグを管理する簡易なシェルスクリプトを自作してしまった。
　研究所は、データベースで高度な分析を売りにしたかったのだろう。しかし、バグ分析は新人のときに凝りている。何を見いだせるか不明の分析のために徹夜で登録しているわけにはいかない。そして、ＣＳＶのバグデータを、のちに後輩が分析してくれた。
　「やりたかった」が「やれなかった」のが、ニュース記事の保管だ。設計も試験もニュースに投稿して共有していた。これらをノウハウとして永久保存したかったが、当時のハードディスクは一本３００ＭＢ。一年分がようやくだった。ＵＮＩＸのニュースは古い記事を自動消去してくれる。通常はディスクの使用率は半分程度に抑えて運用したが、ニュース記事には専用ディスクを割り当て、九割まで消去を我慢した。それでも一杯になり、消去コマンドを打つときは、断腸の思いだった。三十年間の設計書はＮＴＴの貴重なノウハウになったと思うのだが。