友人の話によれば、ERPなどの中には、数千万ステップもの規模のものがあるとのこと。汎用機のOSの設計をしてきましたが、JRの座席予約や都銀向けなど数千端末ものシステムを動かす超大型機向けのOSでも、300万ステップ程度だったことを考えると、どう考えても多すぎると思いました。どうしてこんなに大きいのか？そういえば、WindowsＮＴがもてはやされた頃、技術者向けの専門誌にNTのステップ数は1500万と書いてあったことを思い出しました。
私はWindowNTを自作PCに入れて使っていましたが、Windowsよりは安定している感がありました。しかし、1500万ステップ･･･超大型汎用機向けのOSが300万ステップ･･･何だか合点がいかなかったことを覚えています。どうしてこんなに増えてしまうのでしょう。少し調べたことがあります。今日はそれを紹介します。
汎用機全盛時代のシェアは富士通、日立で二分されていましたが、後者にいた私の記憶では、設計ドキュメントは徹底して作成、保守、更新され、どこをどう修正した／その理由は何／処理内容／と共にその該当ヵ所（ソースコード）は完全に管理・把握され、ドキュメントとソースコードとは完全に同期（一致）していました。多分富士通でもそうだったことでしょうが、そうしなければ、全てのアプリケーションのインフラとなるOSの信頼性が保てないことから当たり前のこととして理解していました。もちろん、無駄なソースコードは皆無です。それはオーバヘッドの原因にもなるし、バグの温床になりかねないからです。
それが1000万ステップを超え、数千万ステップになるようなアプリケーションが出て来るようになった･･･あの複雑な処理するOSを何倍も何十倍も上回るアプリケーションはどうして生まれるのか、そもそも管理し切れるのか、全体を把握できている人はいるのでしょうか。吉川英治の大作三国志があります。
残念ながら頁数や文字数が分かりませんが、シナリオが頭に入っているので何とか読了できますが、数千万ステップの文字の羅列で表されるロジックを一人で追うことは不可能です。何百人も投入して機能毎に細分化して作業しているのでしょうが、それぞれの担当機能が相互に影響し合っている部分の修正、エンハンス（機能強化）の際の調整はどうしているのでしょう？他が見えない状態で勝手に修正、エンハンスはできません。それを支援するためのツールがあるとは思いますが、削ってミスすることを避けるために重複処理が、多数発生することが予想されます。ITmediaによれば、実際に多数の重複処理（図の○で囲まれた部分）があるようです。
どうしてそうなるのでしょう。
・設計ドキュメントとソースコードの同期がとられていない
・全体像をソースコードレベルで把握している人がいない
・入出力だけ分かっていて処理内容がブラックボックス化している
早い話が、インドの寓話にある、群盲象を撫でる状態になっていると思われます。
群盲象を撫でるとは、部分部分を見ても、寄せ集めても全体像が分からないという、インドの寓話（群盲象を撫でる）があります。大勢の目の不自由な人が、てんでに大きな象を触って何者かの感想を言うものの、目が不自由なために全体が見えず、鼻、牙、足、耳、尻尾、皮膚など、それぞれ触った部分の感想を言うだけになり、それらの感想を集めても象であることは分かりません。巨大ステップのアプリケーションが正に象の状態で、撫でているのがアプリケーション開発技術者という図式です。
その結果、どうなるでしょう。元のソースコードを触ると理解していないかもしれない部分があり、その処理を含むモジュールを触ると、バグを誘発する可能性があるので、そのモジュールを残したまま、そっくりそのままコピーしそれをエンハンスするということになります。ステップ数が増えるのは自明です。処理内容のドキュメントとソースコードが同期を取って更新されていれば、ドキュメントを見て修正ヵ所、エンハンスするヵ所を見つけ、対応するソースコードをみて処理内容を確認すれば、この様な重複が発生することはありません。
ドキュメントを重視せず、ソースコード優先で作業する仕事の仕方を続けた結果、象どころか恐竜になってしまい、全体を把握しきれないばかりか、個別の機能もソースコードレベルで理解せず（怖くて触れず）、屋上屋を重ねてきた結果が、巨大ステップのアプリケーションが生まれてしまった原因です。そういった意味では、石橋を叩いて亘る開発習慣をつけてもらった昔の会社、当時の風潮、OS開発という職種に感謝しています。
※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、本ブログの無断転載、流用を禁じます。