「そんな当てずっぽうで決めていいのですか?」。ある会社のシステム基盤の設計に関する打ち合わせをしている際、メンバーから言われたことがある。全体コンセプトを決めて積み上げたものなので、当てずっぽうなわけではないのだが、ユーザーニーズを聞いていない状態で決めるのは納得できない、というのである。

 ユーザーからニーズを聞けない状況でも、そこにこだわるエンジニアが意外に多いと感じている。エンジニアには二つのタイプがある。一つはユーザーニーズがまずあって、それをどう実現するかという順序で考えるタイプ。もう一つは、新しいアイデアに沿ってシステムを構想し、ユーザーのニーズに後から合わせようとするタイプだ。前者はSI会社、後者はパッケージ会社や研究所の出身者に多い。

 どちらが良いかは場合によるが、筆者の会社のように基幹業務システムの構築に関わる場合、ユーザーニーズを起点にするのが基本だ。ただ、基盤やフレームワークはユーザーが直接関わらないので、エンジニアが仕様決めをリードすべきだと思う。だが冒頭のように、ユーザーにその根拠を求めようとするエンジニアを見かける。

 エンジニアが適切にリードできなかった仕様が、禍根を残すことになった例を一つ挙げておく。SGMLタグの省略機構である。SGMLはHTMLの祖先に当たり、HTMLにもこの機構は引き継がれている。HTMLでは<BODY><P>といったタグと、それぞれの終了タグ</BODY></P>で入れ子構造を作り、階層構造を表現する。終了タグは文脈上で一意に決められるなら省略してもよい、とされる。この省略の仕様は、ユーザー視点での利便性を最優先する発想から生まれたものだ。SGMLは手作業でタグを記述する想定だったので、タグはできるだけ少ない方が見やすいし書きやすい。

 後知恵ではあるが、この省略の仕様はエンジニア視点から「不採用」にすべきものだったと思う。省略を許すために仕様は複雑化し、処理系を作るのが難しくなった。何よりどこで何が省略されたかの解釈に曖昧さが生じた。HTMLを表示するWebブラウザーの解釈が実装ごとに違ってしまい、あるブラウザーでは問題のないWebページが別のブラウザーで表示が崩れてしまう原因の一つになっている。ユーザーを少し楽にする仕様が、後年、HTMLの複数ブラウザー対応を行う多数のエンジニアの苦労を生み出したわけだ。

 HTMLの後に登場したXMLは、やはりSGMLの子孫だがタグの省略を許さない。人が手で記述するだけでなく、システム間連携(XMLドキュメントをやり取りして処理を自動化)での利用を前提にしている。システム間連携では、解釈の曖昧さで生じる問題はブラウザーの表示が崩れるくらいでは済まない。仕様策定当時、システム間連携のニーズは今ほど明らかではなかったが、将来を見越したITの専門家によってタグの省略を許さない仕様になった。現在、システム間連携でXMLが多用されているが、このXMLの普及はエンジニアのリードによる仕様策定の成功事例だと筆者は思っている。

 昨今のシステム開発現場のエンジニアは、「ユーザーから言われた機能を作るだけ」という立場を意図的に選択しているようにも見える。トラブル時の責任追求を避けるために、「すべての仕様についてユーザーが決定したという言質を取れ」という会社の方針があるからかもしれない。

 しかし、ユーザーが判断できるのは目の前の利便性に限られる。ITエンジニアはシステムの将来まで見通した上で設計の方向性を定め、ユーザーをリードする責務がある。「ユーザーが決めたから」は言い訳にはならない。たとえ“当てずっぽう”に見えても、技術上の判断の根拠には、膨大な技術経験に裏打ちされた洞察力や設計思想があるはずだ。またそう言えないようではいけないと筆者は思う。

林 浩一(はやし こういち)
ピースミール・テクノロジー株式会社 代表取締役社長。ウルシステムズ ディレクターを兼務。富士ゼロックス、外資系データベースベンダーを経て現職。オブジェクト指向、XMLデータベース、SOA(Service Oriented Architecture)などに知見を持つITアーキテクトとして、企業への革新的IT導入に取り組む。現在、企業や公共機関のシステム発注側支援コンサルティングに注力