21世紀型情報システムを考える-20世紀からの決別ー研究会 レポート 研究会 2011年度 研究会／講演会

【第17回『21世紀型情報システムを考える』研究会　第3フェーズ「情報の海をどう作るか」 】報告

Posted on Author Admin 【第17回『21世紀型情報システムを考える』研究会　第3フェーズ「情報の海をどう作るか」 】報告 はコメントを受け付けていません

ケース紹介：”これが21世紀システムだ！ ～協和発酵キリンの実例”
講　師： 中山嘉之　協和発酵キリン 情報システム部長
日　時： 2011 年3月3日（木）16:00～18:00
場　所： アーク情報システム（市ヶ谷）

これまで21世紀情報システム会は合計16回開催してきた。その16回の内の前半では「情報の海」というキーワードを挙げ、これからの企業には業員 が自由自在にリアルタイムの情報を使って意思決定できる環境が必要であろうということを話し合ってきた。とはいえ、仕組みがあっても、すぐに人が行動でき るわけではない。そこで第二フェーズでは従業員が自発的に行動できるようなフレーム理論（ABCフレーム理論）について語りあった。第1フェーズ、第2 フェーズで語り合った内容は「情報の海構築に向けたABCフレームモデル10カ条」としてまとめられ、BPIAのWebサイトで公開している。第3フェー ズでは、成果が上がるシステムの作り方について話し合う段階へと入った。そこで今回は先端的なビジネスシステム・アーキテクチャを構築した協和発酵キリン 　情報システム部の中山嘉之氏に講演をお願いした。ナビゲータの田口潤氏から中山氏の簡単な紹介の後、講演が始まった。中山氏の講演概要は以下の通り。

■ 「協和発酵キリンにおけるビジネスシステム・アーキテクチャ」

協和発酵キリンは2008年1月1日に協和発酵工業とキリンファーマが合併してできた会社だ。親会社のキリンホールディングスが当社の株式 の50.1％を保有。当社は医療用医薬品の製造・販売を行う事業持ち株会社である。アルコールやエステルなどの化学品を製造していた協和発酵ケミカルが 2011年3月に独立し、現在は医療事業に特化している。

当社の事業ビジョンは、がん、腎、免疫疾患を中心とした領域で、抗体医薬を核にした最先端のバイオテクノロジーを駆使して、画期的な新薬を継続的に創出し、世界の人々の健康と豊かさに貢献する日本初のグローバルスペシャリティファーマになることである。

当社のシステム化の経緯について説明したい。当社のシステム化も70年代のメインフレームから始まった。80年代には分散処理、90年代初 頭にはクライアント/サーバーシステムが登場した。世の中の動きに合わせて当社も新しい技術を導入。90年代半ばにはインターネットが登場し、Webやイ ントラネットを採用。2000年からはJavaを本格採用しだした。2010年からはSaaS、クラウドの活用時代に本格的に入った。当社では周辺システ ムだけではなく、基幹システムもクラウド化に取り組んでいる。私は82年に入社した当時から、社内システムに携わってきた。

■ユーザー企業から見たクラウドコンピューティングの必然性 

クラウドコンピューティングがなぜ必然なのか。当社のようなユーザー企業は業務を実行するのが目的である。したがって情報システム部門に おいて、バージョンアップ、ウィルス対策などのインフラの維持管理は目的ではないからだ。第二に増大するコンピュータ経費の抑制をしたいということ。第三 は業務アプリのサービスインまでの時間を短縮したい。第四はハードが爆発的に進展していること。第五はクラウドビジネスの台頭。これによりアウトソーシン グの可能性をもたらしている。第六はクラウドが当社のシステム全体のアーキテクチャに合致していること。当社は疎結合、非同期で複数のシステム同士をコネ クトしていこうという考え方をしており、クラウドは自社のデータモデルを中心とした地動説にマッチした。周辺の取り替え可能なプロセスの一つがSaaS。 この先、業務自身をアウトソースするBPOも積極的な活用を考えており、昨年から給与計算はBPO（ビジネスプロセスアウトソーシング）を採用している。

当社のシステムアーキテクチャの図を見れば、クラウドコンピューティングを取り入れた必然性がわかると思う。しかしシステム化を始めた 30年前からこの絵を描いていたわけではない。現在の図にまとまったのは、2～3年前である。全てのシステムにまたがるデータを整合性を持って管理し、蓄 積し、交換する仕組みがあれば、極端な話、アプリケーションは自社で持とうが外部にあろうが何ら問題ない。このようなアーキテクチャがクラウドの流れと合 致したのだ。 システムの核となるエンタープライズHub（ハブ）。これを作ったのが97年。これにより、狭義の意味でのアーキテクチャが固まった。このアーキテクチャ は当社独自のビジネスモデルに基づいている。データモデルもプロセスモデルも世界に一つしかない。人事、生産管理、販売物流、営業支援、会計、原価計算な どのローカルモデルとエンタープライモデルの間にはモデル変換（コンバート）が入る。このような仕組みにしておけば、例えば人事のSaaSが気に入らな かったら、その部分を取り換えればいい。そういう仕組みにしている。

■SaaSに向くシステムとその順位

まず、どのシステムをSaaS利用の対象とするか順位づけを行った。まずは汎用性の高さでの順番。一般的に汎用性が高ければSaaS利用は可能である。人事、会計、購買などのシステムは、汎用性が高く独自性が少ない。そういったシステムからSaaSへと切り替えていく。

次はリスクマネジメントの観点。この場合は、ノンコアシステムが優先になる。業務の種類だけではなく、業務のプロセスという観点からも順位 付けをしている。例えば会計でも制度会計は定番の形があるが、管理会計は企業独自のものがある。人事でも給与計算はコアではないが、人材管理は会社独自の 考え方があるのでコアである。調達そのものは汎用的だが、戦略購買は会社独自のカルチャーを持つ。典型的な医薬品のR&Dは会社のコアだが、その 後医薬品申請するレギュレーションは厚生労働省やFDA（米国食品医薬品局）によって決まっているため、ほとんどの医薬品会社は同じパッケージを使ってい る。こうした判断基準でシステムを区分けし、SaaS化できるものからしていく方針だ

計画性がないSaaS化は害をもたらすこともある。A、B、Cというシステムがあり、システムAをSaaS化し、外出しした。使うだけなら 問題はないが、システムAとB、Cのデータインタフェースが分断され、サイロ化してしまう。それを人間がつなぐと、業務効率が悪くなる。これがSaaS利 用の際に気をつけるポイントである。

そこで必要になるのが、トランザクションのハブ。当社では2年前にトランザクションハブという新しい構想を作った。マスタとは別に、1カ所にトランザクションを集中する。これによりシステムのスパゲティ化を防ぐと同時にクラウドの利用が進むというわけだ。

システムAとシステムBというシステムがシンクロナイズさせるために、まずイベント・トランザクション（増加/減少、追加/削除）を共有 することだ。次に種類の異なるトランザクションを汎化すること。これにより更新プロセスや参照プロセスの一部を共有することが可能になり、システムの保守 性が向上する。

具体的にいうと、トランザクションを「5W1H」で捉える。何を、いつ、だれが、どこに、なぜ、どのようにモノを移動したかを表現する、1個のフォーマットに汎化した。汎化した理由は、プロセスの共通性が高くなり、プロセスの再利用性が高まるからだ。

■トランザクションHubとは

先述したようにA、B、Cの各システムはトランザクションHubを経由した接続形態となっている。各システムは必要なデータを、トランザク ションHub上のトランザクションDWH（TR-DWH）を介して蓄積交換する、疎結合インタフェースで結ばれる。TR-DWHはオペレーショナルデータ ストア（ODS）という種類のデータウェアハウス。すべてのイベントの明細を追記型で記述する。訂正はせず、すべて赤黒で書いていく。この仕組みは築地の 魚市場に例えられる。関東のほか、九州などいろいろなところで採った魚が築地に集められ、そこに買いに行くというモデル。トランザクションの制御としては 効率化が図れる。システム間をまたがって利用されるデータの場合に採用されるモデルだ。再利用性のないものはHUBに持ってこない方がよい。
中山氏のレクチャの途中だが、ここで参加者からの質問があった。

Q：この仕組みではリアルタイムでなく、あくまでも間隔をもってデータストアに持ってくるという感じですか。

中山氏：ここはリアルタイムとかそういう観点で話してはいない。書き出しはバッチでやろうがリアルタイム でやってもそれは企業の都合による。ただ疎結合モデルは、データをストアするタイミングと引用するタイミングが同じではない。そこがSAP などERPののビッグバンモデルとは違う点だ。例えば1円の売り上げが上がったとしても、会計のP/L（損益計算書）にすぐ上がってくる必要はないと考え ている。

Q：営業システムから在庫を見に行って、在庫があれば在庫を引き当ててクローズするというようなことも必要ないのか。

中山氏：それは違う。営業支援システムや販売物流システムの内側では密結合モデルだ。生産管理を例に説明 する。日程計画があり、出庫指図が出る。そうすると倉庫システムに対してリアルタイムで「これを出せ」と指図データを出す。これらは使い捨てのトランザク ションで、データの蓄積はない。これは生産管理の中で閉じている話で、それらのシステムの中で閉じている場合、リアルタイムでのやり取りとなり、当然在庫 の引き当てもその中でリアルタイムに行われる。 先ほどから私が説明しているのは、社内における2種類のハブで、システム間をまたがるトランザクションの話だ。この特徴は再利用性の高いトランザクション であり、データウェアハウスが保有しているハブ。これは疎結合となる。レコードも汎化されており、非同期。例えば生産管理から出来高、製品計上のデータを 上げたとする。製品計上のデータは、販売物流では引き当て在庫に使われたりする。月に1回生産管理で受払を計算しそのコストを計算すれば、原価がでる。こ のようにトランザクションにはいくつかのレベルがある。システムの中でクローズできるもの、システムを飛び越えていくもの、さらには企業を飛び越えるもの と3つある。

この後、しばらく中山氏のレクチャが続く。

■トランザクションHubを経由するメリット

トランザクションHubを経由するメリットは4つある。第一に各周辺の業務サービスを容易に取り換えられること。パッケージと心中するリス クを回避できる。第二にトランザクションHubの一点に管理を集中できること。データ変換やファイル送受信ツール、エラー処理などの各種プロセスを共通オ ブジェクト化することで、再利用が可能になる。一点に集中するHubにはパンクしたらシステムがやられてしまうという弱みはあるが、それはFT化し堅牢に すれば問題ない。

第三にトランザクションHubがあらゆるシステムのバッファとして機能すること。トランザクションHubは各業務システムに中立 なコード、フォームで構成される。異なるシステムのコード、フォームをIN→（X）→OUTの2段階で変換。そのコード体系やレコードのフォームなどは ニュートラル=協和発酵キリンオリジナルなものとなる。第四に疎結合ゆえに仕組みがシンプルで運用が楽であること。個別の利用相手を意識せずにDWHに出 力できる。再利用はデータ抽出条件を指定するのみでタイミングは問われない。

今日は本題ではないが、各システムで共通利用するマスタは、あらかじめマスタHub上に製本を集中管理し、これを各システムと同期することでトランザクションの品質を担保するという仕掛けになっている。

トランザクションのところで、システムの中で閉じているものとシステムをまたがるものの2つがあると述べたが、マスタも同じ。シ ステムを超えるものをマスタHubで一点管理している。クラウドに出ていく場合はマスタ更新トランザクションを伝送する。そしてトランザクションHubと マスタHubの双方を合わせてエンタープライズHubと呼んでいる。

トランザクションDWHを介してシステムAとBはつながり、送受信やコード変換、更新、抽出などはすべて同じコンポーネントが使われる。そしてそれらがPower Centerのリポジトリの中にオブジェクトとして格納されている。

　その上位に位置するメタデータセントラルはまさに意味論の世界。従業員コードは何を何ケタでどういうものを表しているかの説明が入っていたりする。これを見ることでデータの意味を把握でき、システムのDNAも受け継いでいくことができる。

■ 人事、治験データ処理、海外現法システムにSaaSを

ここでいくつかのSaaSの適用事例を紹介しよう。まず人事システムから。キリンファーマと協和発酵ではまった く人事制度が異なっていたため、新しい制度を作るのに伴い、システムも新たに構築することとなった。システム開発にかけた期間は1年。そのうちの前半6カ 月を人事のルールに関する議論に費やした。システムの開発に入れたのは、後半6カ月。約6カ月間でシステムを構築できたのはSaaSを採用したからだ。 サービスインは2010年4月1日。

人事給与の部分はBPOを採用している。例外処理があってもBPO会社の人材が処理してくれるので、システムに組み込む必要がない。

人事従業員台帳はクラウド側にあるが、従業員情報はオンプレミスのさまざまなシステムで使われる。先述したようにそれらの各システムの従業員情報はマスタハブから差分を配信する仕組みになっている。

今まだイントラの中に入っている勤怠管理も、近いうちにBPO側に持っていきたいと考えている。BPOできな かった理由はメディカルの工場が3交代制を採用しているため。BPOモデルに3交代制はない。したがって自社のモデルを使い続けている。現在、やり取りを しているのは異動トランザクションだけ。人事異動の差分をもって、従業員マスタを絶えずアップデートする。日何回かのタイミングで行っている。それを会計 システムやネットワークのログオンにも使う個人ITRなどの情報にも使っている。

医薬品特有の臨床試験の分野でも、SaaSを採用している。治験データの収集・管理業務をクラウドサービスに集約している。これも人事給与同様、2010年4月から稼働している。これは特殊な業務なのですごく高価なサービスだが、自社で構築するとさらに高くつく。

第三は海外にある3つの現地法人（子会社）の基幹システムをSaaSで実現した例。これは2011年6月に稼働した。3つの子会社は規模も小さいため、シングルインスタンスでサプライチェーンから会計までSaaSで実現している。

■これからのクラウド化のシナリオ

クラウドのシナリオと難易度について説明したい。レベル1はオフィス系システムのSaaS化。電子メールやスケジューラ、電子稟議書などはすぐに取り組むことができる。インターネット上でのアカウント一括認証が必要になる。

レベル2は業務システムをSaaS、PaaS化にすること。対象アプリは購買、SCM、R&D、SFAなど。パッ ケージの場合は製造元やパートナーへの打診してみるといい。製造元がSaaSサービスに切り替えるということもあるからだ。SaaSかPaaSかはアドオ ン、カスタマイズの度合いで選択する。スクラッチの場合でもコンポーネント型SaaSを利用できれば可能だ。レベル3はBPO。すべての業務を対象にでき るわけではないが、メリットは大きい。それは複雑な例外処理を人間系でこなせることだ。難易度は1、2、3の順で高くなるが、効果は3が一番大きい。

当社では購買をいまPaaS化しようとしている。購買は相手がインターネットの向こうにいるので、イントラではない方がやり やすいからだ。将来的には全部クラウド化する可能性もある。SaaS化もあるかもしれない。会計まで外に出すことも検討しており、実際、今年中に原価計算 を外に出す予定である。その理由はCPUの利用率が非常に低いため。時間単位でCPUを売ってくれるオンデマンドサービスに切り替えようと考えている。 バージョンアップやハードの老朽化を気にする必要もないうえ、コスト面でのメリットも大きいからだ。

SaaS化に対応するには、社内インフラの強化が必要になる。業務サーバがクラウドの向こう側にあるため、エンドユーザーの PCまではインターネット回線を利用するからだ。業務サーバからトランザクションHubまでのバックボーン回線も帯域アップが不可欠になる。またトランザ クションHub、マスタHubが要となるので、FTサーバ化やディザスタリカバリサイトへバックアップするなど、堅牢化も必要になる。

■クラウド化で変化するステム部門の仕事

まずはクラウド化により、業務システムに注力できるようになる。ハード/ソフトインフラの管理は縮小。インフラ維持コストも減少す る。第二によりアウトソーシングの度合いが高まり、サービス調達業務が増大する。例えば人事給与計算サービスは現在でも100ぐらいある。それらの中で選 択していかねばならない。そのような調達担当の専門家が必要になる。第三にシステム間インタフェースの整合性維持が保守の中心となる。業務システム自体の メンテナンスはベンダーに任せることとなる。第五にトランザクションHub、マスタHubがメンテ対象の中核となる。そのためメタデータに関する知識がよ り求められる。従来以上に詳細で正確な業務知識が必要になる。第六はより業務よりに対象レイヤーが上がり、IT部門からIS部門としての色合いが濃くなる わけだ。システム部門はビジネスアーキテクチャ、データアーキテクチャ、一部アプリケーションアーキテクチャにはタッチするが、TAより下は全部ベンダー 任せになる。

■ 例外処理とは、汎化とは、活発な質疑応答

中山氏の講演は終わり、質疑応答へと入った。

 

田口ナビゲータ　今回紹介してくれたシステムは、三菱インフォメーションテクノロジーの草場氏が構築を支援した事例。草場さんに聞くが、ほかの企業でもこのようなシステムを構築した事例はあるのか。

草場氏　良品計画がある。良品計画はすべて手作りで協和発酵キリンとは考え方も異なる。 サプライチェーンと他のサブシステムのインタフェースをすべて先のような仕組みを取り入れている。データを貯めることはやっていないが、一枚の絵できれい に定義されている。

田口ナビゲータ　とすると非常にレアなケースということがわかる。

草場氏　中山氏のところはマスタデータが整備されており、その状態でトランザクション Hubを構築するというもの。そういうケースはまれで、多くの場合、マスタデータの整備から始めなければならない。マスタデータを統一しようという企業も 少ないので、なかなかトランザクションHubまでたどりつけないのではないか。

田口ナビゲータ　ここまではたどり着かず、マスタデータの統一だけで終わってしまうと。Hubという言葉を使っているが、Hubと聞くとネットワークHubを連想してしまう。システム側の人間からすると、データHubはとっつきにくい感じもするが。

中山氏　築地と言うと理解も早くなる。

菊池氏　会計の立場からいうと元帳と補助簿の関係に近いのでは。

田口ナビゲータ　今の言葉を借りると大福帳型システムという言い方がある。それに近いものと考えればよいのか。

中山氏　これはまさに大福帳システムといっていい。

菊池氏　複雑の例外処理とは何か、教えてほしい。

中山氏　例外処理は条件が複雑なもの。例えば得意先によっては50万円を超えると手形にするという取り決めがあったとする。そういうものが例外処理となる。

山田氏　見ている視点が違うように感じた。密結合と疎結合と言う考え方を入れたというのがすごい。密でないといけない部分、疎でやらないといけない部分をきちんと分けて、徐々にレイヤーを上げてつなげていっていることなど、例をみない考え方だと思った。

中山氏　例えばSAP R/3はドイツ人が考えた密結合モデル。彼らはリアルタイムでやらないと気が済まなかったのだと思う。密結合モデルの方が作りやすく、デバッグもやりやす い。しかし、ユーザー企業側からすると、R/3の変更管理は、オーダーエントリをワンセット変更したら会計までテストし直さなければならない。そうするこ とでベンダーが潤うビジネスモデルになっている。

田口ナビゲータ　とはいえそんなR/3を欧米のユーザー企業も買っている。

中山氏　欧米では日本ほど、R/3一色に染まっていないのではないか。

山田氏　データの汎化とはどういうことか。

中山氏　「汎化」とは「Generalize」。ゼネラルとスペシャルの違い。ゼネラルと は意味を汎用的に捉え直すということ。とはいえ標準化とは違う。オーディオを例にとって説明する。オーディオにはラジオやウオークマン、昔型のステレオな ど様々な形がある。それを「オーディオ」と表すのが汎化。つまり汎化とは抽象化すること。反対に特化の方は具象化。今言った、ラジオとウオークマン、ステ レオの違いはそれぞれの違いはあるが、オーディオと捉えたときはスピーカーがありスイッチありなど共通項がある。それら共通項がオーディオの要素だが、で き上がったものは形が異なる。これが差分。オーディオの設計において共通項である部品を先に作ると、再利用できるようになる。汎化をせずに、一からウオー クマンを作ろう、ステレオを作ろうとすると、各部品も違うものになるかもしれない。部品を標準化するという考え方に近いかもしれない。

田口ナビゲータ　受発注の場合であれば、日付、相手先、品名、数量、社員番号などの項目を共通化しておくということか。

中山氏　受注レコードは誰がいつ何時にどんな得意先からどういう品目を何個受注したかと言うことが記載されたものだが、実は発注レコードはこれと裏返しというだけでまったく同じことだからだ。

田口ナビゲータ　データは同じで、買うか売るかをフラグみたいなもので区分するということか。

中山氏　区分コードをみたいなものを持ち出している。

田口ナビゲータ　汎化しておくと別のシステムにつなぐときに変換が簡単になる。

中山氏　その通りで、簡単になる。抽象化、具象化はソフトウェアがなせる業だ。そこに一番 注力することによって、早くできたり標準化できたりする。具象でシステムを全部作ったら大変なことになる。例えば受注と発注で2000年問題のときのよう なことが起こったとする。日付は汎化されていると、そこだけ直せばいい。製品マスタや取引先マスタは同じではないので、汎化していない。

串田氏　優れた取り組みだと思うが、副作用としてアプリケーションや業務をアウトソーシングして年数が経ると中身がわからなくなるのでは。

中山氏　アウトソーシングすることで空洞化する危険性はある。その辺は気を付けている。

串田氏　どうやったらそれを維持できるのか。

中山氏　そのためにリポジトリがある。そこに意味を記述し、全部貯めている。データその もののプリミティブな説明になっている。このリポジトリは1980年代から作ってきた。従業員コードとは、製品コードとは、組織のコードとは何だ、という ことをとうとうと書いている。それがメタデータ。さらに汎化すればメタメタデータになる。汎化するレベルはいろいろある。メタデータセントラルは階層を 持っている。メタデータとメタメタの階層はもちろん、メタデータが使われているレコードとデータの関係、そのレコードがどこに使われているかというファイ ルの関係、さらにはまたレコードが使われているシステム、プロセスとの関係など。もちろんR/3やオラクルなどのERPでも、内部ホワイトペーパーにはこ のようなことはおそらく書かれている。しかしそれらはオープンにされていない。

田口ナビゲータ　メタデータは業種によってはそんなに変わるものか。

中山氏　扱っているデータの種類は業種によって違うかもしれない。例えば金融商品で使われるデータは違うんのではないか。

山田氏　メタデータセントラルはどの会社ももっているものか。

中山氏　メインフレームの時代には持っていた。しかしオープンシステムの時に捨てた企業も多いのではないか。

 

串田氏　BPMはここから始めないと駄目だと感じる。

 

中山氏　例えば情報システムは情報を生産する工場だとしよう。情報の生産工場の中にはプロ グラムが動いている。プログラムを作るための原料は何か。情報を生産する原料はデータで、データをプログラムに掛ければできる。ではプログラムを作り出す 原料は何かというと、メタデータである。メタデータを使って開発環境に掛ければプログラムができ、これを使って今度はデータそのものを原料とし、情報をア ウトプットする。この一連の流れから考えると、メタデータが最も重要な原料となる。メタデータは階層が作れ、最終的にメタは3種類に分かれる。ボリューム とキャラクター（意味のあるデータ）、指示データ（従業員コードのようなモノ）。だがそれだけではシステムは作れない。もう少し分化した階層が必要にな る。受発注コードとするのか、受注コードとするのか。伝票番号も受注用の伝票番号と発注用の伝票番号の体系を同じにする、もしくは別々にするかで違う体形 になるかもしれない。そこを汎化してやらないと効率性が高まらない。

田口ナビゲータ　システムの構築タイミングはずれたりするものだから。

中山氏　まさにその通り。きれいにするならビッグバンでやればいいが、そう簡単に何度もビッグバンができるわけではない。

串田氏　合併したときにメタデータのすりあわせはどのくらいかかったのか。

中山氏　医薬品は業界統一コードがあるため、比較的問題がなく進んだ。ただ食品については、データクレジングの専門集団であるリアライズ社にお願いして一つ一つデータの中身を確認し、何人月もかけてマスタを統合した。何人月もかかった。

串田氏　受発注などに対する考え方については。

中山氏　これも医薬品の場合は同じなので問題はなかった。医薬品は100％、業界VANから受注が来る。ジャパンドラッグネット協議会という卸から、統一マットでオーダーを受けるという仕組みがある。そこでコードもすべて統一されている。

池邊氏　データの鮮度について聞きたい。ハブのデータはどのくらいの期間が持っているのか。

中山氏　ずっと持っているおり削除はしていない。またDWHのトランザクション、ODSは無制限に貯めており、一レコードたりとも消していない。

山田氏　情報システムが変わったことによる経営上の気がついた変化は何かあるか。

中山氏　関係するとしたら、コストダウンへの貢献と、意思決定や判断のための情報を早く届けられるようになったこと、あとは品質の向上だろう。

■ 21世紀に合う情報システム構築のカギとは

田口ナビゲータ　ほかの企業でもこういうシステムを作ろうとしている。しかしうまくいかない。何がカギを握ると思うか。

中山氏　振り返ってみると、1997年にマスタハブに着手した時は、たった２つのマスタか ら始めた。最初の一歩を踏み出すときに、ゴールが見えたとしてもすぐそこに行くのではなく、次の時のことを考えてよりよい仕組みを考える。つまり今回でい えば、再利用ー性を高めるためにトランザクションを貯める仕組みをつくったこと。それもスモールスタートで。そうすれば稟議も通り易く、リスクも少ない。

池邊氏　コストダウンやスピード、ビジネスの継続性に対して、ITのロードマップを持っているから先を見越してこんなものを作っておかないといけないと考えた。そんな感じですね。

中山氏　少しだけ先回りにしておく。それを忘れると汚いバベルの塔になる。そして最初は小さく作ること。

草場氏　そういうことを考える人がいたことも大きかったと思う。

最後に田口ナビゲータは、「中山氏に拍手を」と呼びかけ、会は終了した。

（文・中村仁美）

ご参照（これまでの記録）