尾関雅則氏は我が国の情報化を牽引したリーダーの一人である。国鉄時代には本格的なプロジェクトチームを作り、大型コンピューターを使って、みどりの窓口の座席予約オンラインシステムを開発、1973年1月に完成させた。日立製作所の常務に転じてから、パソコンなどオフィス製品事業の責任者となり、87年には国鉄の民営化によって作られた鉄道総合技術研究所の初代理事長に就任した。2007年現在も、IT関連の勉強会などに顔を出し、発言や質問をされている。
その尾関氏は10年前、73歳の時に「オゼのホームページ」を開設、情報化やプロジェクトに関するエッセイを執筆した。今回、本サイト上に、オゼのホームページを復刻する。10年前の論考であっても経営とITに関わる本質的な意見が綴られている。
ネーミング
ソフトウェアを制作中にプログラマー達は、ファイルやサブルーチン等に色々な名前をつけるチャンスを持ちます。これは辛気臭いプログラミング作業の中での、彼らの密かな楽しみになっているようです。
バッチ処理のように、一人一人のソフトが、独立している場合はともかく、オンラインのように一つのソフトを大勢で分担して造る場合は、ネーミングを勝手にやらせたら、大変な混乱のもとになります。このような時にはネーミングを厳しく統制しなければなりません。
しかし、これは、今まで許されていた、ささやかな楽しみさえも奪われてしまうという、 言い知れぬ寂しさと不満をもたらすことになります。しかも、そのような統制がきちんと守られているかどうかは外から見ては絶対に分らないものです。デバッグの段階になって、大騒ぎになることがよくあります。
プログラマー全員が、上からの押さえつけでなく、理解をベースにして自主的に造ったルールでなければ、中々、守られないのです。この世界ではあくまでも、本音でデモクラシー的に運営することが必要なのです。
異常処理
システム設計に於いては、異常処理の方式が極めて重要です。往々にして、内部矛盾が発生して処理を中断する場合、警報を出して人間に知らせるだけで、よしとしていることが多いのです。そこからさきはオペレーターさんよろしくね・・・というわけです。
しかし、それから人間はどうするのか？どうしなければならないのか？ 更に、そのような時に、きちんと対処できる人を、如何にして確保し、教育してゆくか等が、重大な問題であって、システム設計とは本来そのあたりまで考えて置かなければならないものであるという認識が極めて重要です。
更に、異常状態から復旧処理のフィロソフィーは、大変重要であります。一般にシステム異常が発生した場合、処理中のトランザクション が必ず存在するもので、これらのグレーゾーンにあるものを復旧 するのにあたって、どのように取り扱うかが、この問題の中核です。
たとえば、疑わしい時は、既にファイルを更新したこととするか、未更新と考えて再度、更新処理を行なわせるのか・・・というようことです。または、送信中のトランザクションなら再送信するか、中止して捨ててしまうかなどの選択を、しなければならない訳で、それぞれの、アプリケーション毎に、適切な処理を選ばないといけないのです。
（オリジナルは1998年9月29日公開）