PR

 前回ご紹介した再考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さんが判断したことは,ほとんど軸がぶれなかった。常識なんて無関係です。自分の判断軸を大事にされていました。