2024.07.20(土) 14:00から新横浜駅前会議室で
「大放談：エンタープライズシステム導入を成功させるための本当のコツ
（第97回IT勉強宴会@新横浜）」
を開催しました。案内はこちら
参加者は現地集合が28名。懇親会は1人のドタキャンもなく23名でした。主催者としてはドタキャンがあると色々面倒ですので大変うれしいです。これからもよろしくお願いします。
大阪／名古屋から来てくださった方は私が知っている限り7名でした。2次会は16名でした。2次会に5名遠征組がいましたので、21時過ぎに大阪方面の終電を気にして「帰る方は？」と尋ねるとなんと私1人でした。後ろ髪をひかれながら帰りました。
今回は「大放談」という事で、オンライン配信もしませんでした。具体的な企業名もいくつか出ましたのでブログとしては詳細に書きませんのでご了承下さい。
０１ 開会あいさつ
佐野初夫（テラスカイ）
NPO法人IT勉強宴会のご説明と、開発ベンダーとユーザの移り変わりの印象をお話しました。
1995年ごろ、オープン化の波の前後でユーザも開発ベンダーも変わりました。
オープン化の波以降については
ユーザ：コンピュータ導入が目的となることが多い。現場を知らず丸投げ
ベンダー：若手に任せられる清書やコーディングがなくなった。育てられない
０２ 立論１ こんな開発ベンダーはイヤだ
渡辺 幸三氏（副理事長）
（１）基本設計を顧客にやらせるベンダー
ソリューションを創造出来ないので、要件定義の名目で「自分たちが欲しい情報システム」を定義させ、その通り作ろうとする
（２）基本設計を分担したがるベンダー
素質がないメンバーばかりなので分担したがる。「ハモれないので、コーラスグループのメンバーを増やせば何とかなる」と考えるような倒錯
（３）簿記を知らないベンダー
簿記3級を持っていても、簿記のデータモデルが書けないなら本質を理解していないということ。組織の情報管理＝企業活動には簿記が常識。知らないで設計出来ない
０３ 立論２ こんなユーザ企業はイヤだ
中山 嘉之氏（アイ・ティー・イノベーション）
タイトルの表現はキツめですが、実際は、ユーザ企業、ベンダー双方の歴史的な背景による深い問題があります。どうすべきかの私見もお話します。
（１）ターニングポイントは2000年~
それまでユーザ企業の情報システムは内製していました。ユーザ企業がコードも書いてました。システムが大きくなるとプログラムを外注しましたが設計は内製でした
2000年ごろから、ベンダーがユーザと合同でIT子会社を作り、坂を転がるように外注化が進みました。ユーザの経営者はITを軽視し、IT部門もアピール不足でした。
「要件定義」という用語もこの辺りで発生（発明）されたと考えています。それまでのユーザ企業は現場から人を集めてシステムを作っていたので、要件は自明の事でした。
（２）現在の状況
現在では大規模システムのブラックボックス化が進み、意味不明なデータ構造のシステムが増え、DX化が困難になっています。ITベンダーは新たなIT製品やサービスを売り込むことで強引にDX化を推奨しています。
（４）こうなった原因はどこにあるか？
・ユーザ企業はシステムライフサイクル全般を重視＆データ中心指向、
・SIベンダーはプロジェクト成功重視＆プロセス中心指向
→双方はしばしば利益相反関係になっています
（５）ではどうすればよいか（私見）
利益相反を解消する方向で、ユーザ／ベンダーの関係を見直す必要があります。
【ユーザ企業】
- ・ベンダー出身者をキャリア採用し徐々に内製化を進める
- ・業務知識に精通すべくビジネス側ドメインエキスパートを転入する
- ・EA（特にDA）を可視化しIT戦略を明確化する
【ベンダー】
- ・人月提供のSIerから優れたプロダクト・サービスのオファリングへ
- ・データ中心アプローチ手法をユーザ企業にコンサルティング提供
０４ 反論２ 開発ベンダーガンバレ
古関 雄介氏（TALON開発者、HOIPOI社長）
若いころ、1つの画面に多くの機能を詰め込み過ぎたプログラム開発を行いました。なぜこんな仕様になっているのか尋ねても「ユーザが欲しいと言っている」という答えでした。
自分で要件定義を行う中で「こうした方が効率出来です」と伝えても「今の通りにして欲しい」と言われることがあります。紙芝居で資料で説明しても納得してもらえませんでした。
実際に動かさないと理解してもらえないと考えてTALONを作りました。
（１）業務システムのキモはデータモデル
TALONはデータモデルをしっかり作ってこそ効果的なツールです。
単一目的で利用するWebサービス（チャットサービスやTwitter）とは異なり業務システムは、利用者の役割・目的が多くなります。ある人が登録したデータを別の人が追記したり承認したりします。必然的にデータ構造（データモデル）が複雑になるため、データ設計が必須です。
（２）提案型で開発しましょう
既存の仕組みをフロントエンドだけ変えたシステム刷新は辛いことになります。ちゃんとデータモデリングから始めて、なぜ？と思ったら納得できるまで議論しましょう。
「今そうだから」で作ると大変なことになりがちです。
０５ 質疑応答・パネルディスカッション
（１）論理モデルと物理モデルについて
・できれば論理と物理は1つにしたい。異なると設計書のメンテが大変
・昔、上流の設計書はいらないという流れがあった
（２）ローコードツールと言っても色々あります
・面倒なデータモデルせずにシステムが作れるという誤解が広がっている
・データモデルせずにシステムが作れるというローコードツールを使うと大変
→画面ごとに別のテーブルが出来るので受注だけで10テーブル出来たりする
→ベンダーはそれを統合するためにデータ連携ツールを売ったりしている
→さらに連携が面倒なのでRPAを売ることもある
（３）ユーザがベンダーを選定する方法が難しい
・弁護士協会の相談所のような機関が必要なのかも知れません
→商工会議所やITコーディネーターでそういう活動しているのかも？
→よほどの経験と知識がないと出来ないので難しいでしょう
・本来情報システム部やユーザ部門でなく調達部門がコンペして決定すべき
→調達部門にITがわかるメンバを配置する必要がある
・オーディション方式しかないと考えている
＜所感＞
参加者は相当レベルの高い人が多かったため最後のパネルディスカッションも時間ギリギリまで活発な意見交換が出来ました。懇親会、2次会まで同じネタでずっと議論していましたのでIT勉強宴会が発足した当初の雰囲気を思い出しました。
以上