前回ご紹介した再考2007年問題の「団塊世代の火事場の馬鹿力」で，私は「我々ユーザー側は，業務の設計とアプリケーション構築を，富士通側はアーキテクチャ（システム全体の構造）やITインフラ（コンピュータの技術基盤）の設計を，それぞれ担当しました。仕事の分担はきちっとできていたわけです」と書きました。これに関して認識が違う，と元富士通のAさんからご指摘がありました。以下はAさんからのメールです。

　長い間，プロジェクトルームで要件の整理から設計までを一緒にやって来ました（あくまで業務中心です）。 私はIT技術，アーキテクチャは大の苦手です。

　SEの役割は，「要件を満たす機能が今検討している内容で本当に良いのか（その機能が本当に必要のものかどうか），その機能を満足する処理ロジックが出来るか，設計する（した）内容に整合性が保たれているかどうか」等のチェックができることだと思います。

　リカバリとかTASEX(OLTPミドルソフト)での必要な機能は，大きな意味で業務要件の一部です（これが達成できないと業務も上手く回りません）。従って，この部分は戸並さん達お客さんにはできないので，我々メーカーSEが作成・修正（機能追加）を行いました。

※この他にも画面ジェネレート用のプログラム，システムがこけた時の画面表示内容，リカバリ完了後の表示内容（最終更新内容），画面操作時のエラーメッセージ内容等色々と提案・検討したことが思い出されます。業務プログラムのデバッグの手伝いも良くやりましたよ。

　また，ファイルの内容がおかしくて，テストですぐこけるので，コピー句からプログラムをジェネレートしてファイル項目の整合性チェックを実行し，おかしいデータを見つけたことも思い出のひとつです。

　Aさんからのメールには，その他の固有名詞もあり，その記憶力はさすが天才！ 私の凡庸な頭脳とは桁違いです。私の認識ともほとんどが一致しています。私の認識とAさんの認識で異なる点は，「ここで書かれていることは業務要件ではなく，業務要件のIT化でしなければならないSEの基本作業である」というところです。

　Aさんのメールで，リカバリ以下に書かれていることについて，ユーザーに問題意識はありません。「うまくやってネ」てな気持です。ですから，ここらの要件は全て富士通にお任せです。Aさん達，富士通のSEはユーザーの運用を考えて仕様を作ってくれています。IT化実現でのデスカッションでもユーザーの視点がありました。そんな観点でいえば，業務運用に着目したソリューションです。

　その意味で，Aさんが「私はIT技術，アーキテクチャは大の苦手」とは，にわかには信じがたい。ですが，同じテクノロジでも，Aさんは業務に相当振っていたんでしょう。メーカーとユーザーの軸足の差です。

　富士通のメインフレーム用DB/DCソフトは，「AIM」ができる前は「SOM（スタンダード・オンライン・モジュール）」だったか？ 物凄く使い難いオンライン・モジュールでアプケーションを組んでいました。

　当時，富士通のSOMオンライン講習が3日間大阪であり，トヨタ系販売会社からYさん，私，プログラマの3人で出かけましたが，Yさんは怒って講習1日目で帰ってしまいました。私とプログラマは，Yさんが怒って帰った理由を「きっとYさんは分からなかったんだ！」と推測しました。私たちは技術好きですから面白かった。

　YさんはSOMについて，「こんなもん使えるか！」と言ったように記憶しています。私は「自分ができないのにムチャクチャ言う」と思っていましたが，結局，富士通は，SOMダイレクトではなく，SOMとアプリの間にOLTPミドルソフトのTASEXをかますことを提案しました。稼働実績がそんなにあるものではないTASEXを利用可能なレベルに引き上げたのは，Aさん達富士通の凄まじいパワーです。SOMダイレクトだったら工数は倍以上だったと思います。そこらの直感と判断は，Yさんの卓見でした。

　その時の私のように，難解（高技術？）という理由で喜ぶ本末転倒なSEも多いのではないでしょうか？その後もYさんが判断したことは，ほとんど軸がぶれなかった。常識なんて無関係です。自分の判断軸を大事にされていました。