単に「分かっているつもり」では，他人にきちんと説明できない──。日経ITプロフェッショナル7月号の特集「システム基盤を理解する」を執筆する過程で痛感した，記者の実感である。

　特集では，サーバーやネットワーク，ストレージといった，情報システムを支える「システム基盤」を理解するための基礎知識を解説した。情報システム開発プロジェクトにおいて，ともすればITエンジニアはアプリケーションの実装ばかりに目が行きがちになる。ただし，充実した機能も快適に使えればこそ。性能や可用性，拡張性といった，システムの「品質」を保つには，「システム基盤」に関する知識を身につけることが欠かせない。

　例えばシステムの性能を評価する指標にはどんなものがあるのか，処理量や処理の種類からどのようにサーバーやストレージのスペックを見積もるのか。あなたは，これらを即答できるだろうか。特集ではシステム基盤を理解するための，こうした様々な基礎知識を解説している。その中で取り上げた基礎用語の解説に，文字通り四苦八苦したのである。

様々な定義の存在する「トランザクション」

　苦労した言葉の筆頭は「トランザクション処理」。情報システムでは極めて一般的な処理形態である。記者自身，これまでの記者生活の中で何度となく見聞きしてきた言葉であり，仕組みや内容もそれなりに理解したつもりでいた。

　ところが特集執筆の過程ではデスクとの間で，トランザクションという言葉の意味を巡るやり取りに，延々と時間を費やすハメになった。

デスク：「そもそもトランザクションって何なの？」
記者：「えー，いろんな教科書を見たところ，『データベース・アクセスを伴う，　業務として不可分な一連の処理』ってところでしょうか」
デスク：「業務として不可分・・・，何だか分かったような分からないような説明だなぁ。よく『大量のトランザクションが飛んでくる』って言うだろ。これって，業務として不可分な一連の処理が飛んでくるってこと？」
記者：「・・・」

　実際，トランザクションには様々な定義が存在する。弊社発行の書籍で恐縮だが，「トランザクション処理 ─概念と技法─」（ジム・グレイ，アンドレアス・ロイター　著，喜連川優　監訳）では，次のように3通りの定義を紹介している。

（1）操作を起動した要求や入力メッセージ
（2）操作の実行によるすべての影響
（3）操作を実行するプログラム

　これらのほか，原子性（Atomicity），一貫性（Consistency），独立性（Isolation），持続性（Durability）という特性，つまりACID特性を備えた操作の集まりのこと」とする定義も紹介している。

　同書によれば，トランザクションの定義があいまいなのは「色々な人が様々な視点からトランザクションに接している」からだという。確かに，システムを利用する立場にあるエンドユーザーと，システムを作る側のSEとでは，情報システムに対する視点も関心事も，全く異なる。立場が異なれば，使う言葉の意味も当然変わってくる。

　結局，特集では取材結果や様々な資料，文献の内容を総合して，「ひとまとめにして実行されるべき，複数のデータや処理要求の集まり」と定義した。「ひとまとめ」という言葉には，「一連の処理のうち，どれか1つでも失敗すると処理全体が成立しない」という意味が込められている。例えば商品の出荷に伴い，「在庫の引当て」と「商品の発送」の2つの処理が必要になるとしよう。この2つをひとまとめにしたものをトランザクションとみなすことができる。言うまでもなく，どちらが欠けても，「商品の出荷」業務は成り立たないからだ。

ベテランでも混同しかねない

　情報システムの性能を表す指標の1つ，「ターンアラウンド・タイム」にも手を焼いた。お恥ずかしい話だが，記者は今回の特集を担当するまで，ターンアラウンドタイムとレスポンス・タイムを同じ意味だと思っていた。そもそも違いなど意識したこともなかったのだが。

　念のために説明しておくと，両者ともシステムに処理要求を送ってから結果を得るまでの時間であることに変わりはない。ターンアラウンド・タイムとは，処理要求を送信してから，すべての処理結果を受け取るまでの時間である。つまりクライアント上で処理結果の描画が完全に終わるまでの時間のことになる。

　これに対してレスポンス・タイムとは，クライアントが処理要求を出してから最初の応答を受け取るまでの時間を言う。クライアントから処理要求を送信し終えた瞬間から，処理結果の描画が開始される瞬間までの時間である。

　特集の取材では，大手コンピュータ・メーカーやシステム・インテグレータで，システム基盤設計を手がけるITエンジニアに何人も取材した。その中には，「ターンアラウンド・タイムとレスポンス・タイムは，ほぼ同じ意味です」と答える人もいた。記者の質問の仕方のせいかもしれないが，ベテランでもつい混同してしまいがちな言葉だと言える。

知ってるつもり，分かっているつもりの「怖さ」

　ここで言いたいのは，いろいろな言葉の意味を暗記して完全に覚えようということではない。重要なのは，知っているつもり，分かっているつもりになってしまうことの落とし穴を認識し，言葉の意味をきちんと突き詰めて考えることだ。

　上で挙げたように，同じ情報システム開発プロジェクトのメンバーでも，立場が変われば関心事も変わる。それに伴って，同じ言葉でも込めるニュアンスが違ってくる。言葉の意味をあいまいにしたまま開発を進めることが，トラブルのタネになることは自明だろう。当たり前のことだが，言葉をきちんと理解することはもちろん，利用部門にはにわかに理解しがたい「技術者言葉」を顧客の知っている言葉に置き換えて説明するといった心がけが欠かせない。

　「何を今さら」と感じる読者は多いことだろう。かくいう記者自身，日本語を書くことそのものが仕事であるにもかかわらず，言葉の意味を分かったつもりの「怖さ」を自覚できているかといえば，はなはだ心許ない。特集の取材・執筆を通じて，改めて思い知らされた次第である。

（玉置　亮太＝日経ITプロフェッショナル）