プログラムのモジュール化

　「プログラムの構造化」「モジュール化」が流行語だった時代がある。米軍が採用したプログラム言語Ａｄａも、電電公社が交換機に採用していたＣＨＩＬＬも、モジュール化が売りだった。
　プログラミング言語の「モジュール」をどう活用してシステムを作るか、哲学論争になってしまうことが多い。主観的な「分かりやすい」とか「美しい」は、絵画や映画なら何度も創作でき、美を究めていくことができる。しかし、プログラムのモジュール設計は、人生で何度も実践できない。大きなシステムの初期開発に立ち会える機会は少ない。かつ、そのシステムが長寿でなければ効果を検証できない。担当者が世代変わりするくらい経って、本当のメリット・デメリットが見えてくる。
　新人の私が携わった交換プログラムは、その数年前に開発された交換機をベースにしていた。メーカのチーフたちは前作に従事し、モジュールを設計した張本人たちであったから、背景や経緯を熟知していた。私が気づいたのはずっとあとになってからだ。初期開発から十年に渡り、モジュールの功罪を体験できた。
　メーカに頼らなくても社員で問題を究明し、解決できる技術力をつけるよう、研究者も開発に参画せよと、総裁から檄があって八年、デジタル交換機をリリースしてから六年が経っていた。当初開発に参画した奴にトラブルを起こした交換プログラムを改良させろ、ということで久しぶりにソースを覗いて驚いた。七年前の「失敗トレーサ」が手つかずで残っていたのだ。調べていくと、他にも使われていないコードが多数見つかった。あるモジュールでは残骸が三割もあった。
　自分のモジュールだけ見ていればよい、というモジュール化のメリットは、「他が見えないため自分の中の残骸もわからない」問題となっていた。開発費の支払方法にも問題があった。追加変更した行数に支払うから、残骸を削除しても一銭にもならない。メーカは絶対に削除しなかった。
　モジュールを次々メーカから引き取り、内製していくと、十年前のモジュール設計の背景が見えてきた。交換機の開発は、日本メーカの育成も兼ねていた。当時、四社は自社でも交換機を開発しており、海外に輸出していた。電電公社向けは四社が均等に分担して共同開発だ。
　均等というのは規模の話で、機能はなかなか均等というわけにはいかない。発注はモジュール単位、モジュールは機能単位だから、どうしても機能を分担することになる。
　初期開発では均等に分担したとしても、その後の開発でどのモジュールにどれだけの開発があるか、分からない。毎年、担当モジュールをシャッフルすれば均等にできるが、現実にはそうもいかない。メーカは各社、重要なモジュールの内実をドキュメント化していない。ソースコードを日本語に訳しただけの「詳細設計書」は納品する。しかし、なぜそう実装したのか、ノウハウには一切触れていない。モジュール分担はひとたび決まると、その交換機の寿命三十年間、基本変えられない。
　維持管理になって、どのモジュールでどれだけの開発があるか、それは機能追加の内容によって大きく変わる。電話サービスの追加と保守コマンドの追加では、改造するモジュールが異なる。だから、モジュール分担は、メーカにとって三十年に一度のドラフト会議のようなものだ。
　毎年安定して受注できるためには、各社は異なるモジュールに分散投資をした。今年、このモジュールが外れても、別のモジュールに改造があるよう分散する。担当する機能も分散することになり、担当技術者のスキルも分散する。育成という狙いにもかなう。
　四社に主要機能を満遍なく分担させると、設計時から四社で密に議論が必要になる。たとえば、障害に対応する機能も四社に分けたので、どう対応するか、四社で検討しなければならない。開発会議で膨大な資料を交換していた理由である。
　新人の私が開発会議の議事録を書いていた頃、あるメーカが、あるモジュールをやらせてほしいと懇願してきたらしく、コーディング直前になって分担を替えた。これ以外に分担を変えた例を知らないから、某社はよほどやらせてほしかったのだろう。しかし、それが問題だったとのちに気づく。
　そのモジュールは、もう一つのモジュールと密に結合していた。元々は一社で両方を担当していたが、開発規模が大きいので、某社が泣きついたのだ。内製するためメーカから引き取ったが、元の担当メーカの分担に合わせて、別々の支店に担当してもらった。しかし、これらのモジュールは一社で両方をやるべきだった。もっと言えば、モジュール分割すべきではなかった。一つの支店で担当するように変えたら、俄然スムースになった。（生産性が二倍以上になった）
　モジュールはコンパイルの単位でもある。しかし、実際にはモジュールは相互に依存していて、単体ではコンパイルできない。そこで、まず他モジュールに見せる部分だけ作る。これを「スタブ」と呼んでいた。
　全モジュールがスタブを公開して初めてコンパイルできる。スタブを作っている段階はコンパイルができないから、公開されたスタブは、コンパイルチェック未である。全スタブが揃い、コンパイルしてみると、問題がぼろぼろ出て来る。一つを直すと連鎖で問題が見つかる。こうして、全スタブのチェックが終わるまで何度もコンパイルが必要で、一週間も二週間もかかっていた。
　研究所では、こういう現場のゴタゴタはメーカ任せだった。幹事メーカに発破をかけるだけで本質を見ようとはしていなかった。内製してみて、ゴタゴタ解消に乗り出す。それは、モジュール分割の反対、ある特殊なモジュールに全モジュールのスタブの一部を集約したのだ。
　集約したのはデータ定義である。データは他のデータを参照して定義されているが、全ての定義がモジュール内にあるから、そのモジュールだけコンパイルすればチェックができる。スタブ完成を大幅に短縮できた。
　スタブを自動化したことで、モジュール分割が容易になった。モジュールは、ある大きさを越えるとコンパイルできなくなる。機能追加中に突然コンパイル不能になるので、従来は大慌てだったが、容易に分割できるようになったので、「ＸＸＸ２」「ＸＸＸ３」と機械的に分割した。
　のちにカナダの交換機メーカのプログラムを見る機会があり、全く異なるモジュール化に驚いた。当然一社で開発している。モジュール分割の狙いは、分担の均等化でもスキルアップでもない。それは、電話局の条件、契約の内容に合わせて必要な機能を組み込むためだった。例えば、ジャパンというモジュールがあるのだ。電話局の規模も役割も大きく違う。ベースの機能に、その国、その電話局特有の機能を追加していくモジュール化だった。オブジェクト指向でのクラス継承に近い。
　新総裁はモジュール化に期待していた。造船でモジュールを標準化し、大幅なコスト削減と工期短縮を実現した経験からだ。しかし、交換プログラムの開発は造船と本質的に違う。三十年間の維持管理は増築である。
　研究所がモジュール化でねらったのは、ハード構成が異なる交換機に対して、プログラムを効率的に維持管理することだった。しかし、それも実現できなかった。導入する客先（事業部）が異なれば、客に合わせて開発することになり、モジュールの再利用は二の次になる。同じ客でハードの差が小さいなら、ハード構成を同一にしてしまうほうがトータルの維持管理は安くなる。