bpia_logo
BPIA公開セミナー
『21世紀型情報システムを考える』研究会
21世紀型情報システムの姿
〜データ一元化を基本にした「情報の海」を目指して

21世紀型情報システムの姿
〜データ一元化を基本にした「情報の海」を目指して

日 時: 2008年10月28日(火)
会 場: 中目黒GTプラザホール
主 催: BPIA
協 力: 株式会社おきぎんエス・ピー・オー
メディアスポンサー: インプレスビジネスメディア、IT記者会
セミナー風景
<Contents>

 BPIA『21世紀型情報システムを考える』研究会は、2008年10月28日に公開セミナーを開催した。セミナー開催にあたり、まず、進行を務める同研究会・ナビゲータであり、インプレスビジネスメディア取締役の田口潤氏から同研究会の概要について簡単な説明がなされた。田口氏による概要は以下の通り。

田口氏

 同研究会がなぜ発足したか。その背景にあるのがネットワークの普及により大きく世界がパラダイムシフトしているにも関わらず、依然としてIT関係者の考え方が20世紀型のまま残っているのではないかということ。例えばビジネスのあり方はドメスティックからグローバルへ、働き方も終身雇用制が崩壊し、さまざまな働き方が認められるようになった。つまり技術のもちろん、社会のあり方や人の働き方、人のマインドの面などさまざまな面がネットワークにより変わりつつある。そんな中で、情報システムがかつてのままでいいのか。これが当研究会で議論をするきっかけとなった問題意識である。

 今回のセミナーは、21世紀型情報システム研究会で過去半年ぐらい議論を進めてきた「データの一元化」をテーマに、4人の方の講演を中心に構成。その講演に入る前に、当研究会のバックボーンとなっている理論について、もう一人のナビゲータであるアールワークス監査役山田博英氏からその理論の概要説明がなされた。その内容は以下のとおり。

当研究会で議論している「情報の海」「フレーム理論」とは

山田博英 21世紀型情報システム研究会・ナビゲータ
山田博英氏

 現在、世の中は目まぐるしく変化している。この変化をもたらしたのはIT技術だといわれているが、変化をもたらした原因をコミュニケーション(情報伝達)と見るのがよい。コミュニケーションという基準で世の中の変化を見ると、今まで見えなかったものが見えてくる。1990年代までのコミュニケーションは紙の配布を基本にそれを電話とかファックスとか会議が補完する形で行われてきた。1990年代になると、コミュニケーションはネットワークを介してリアルタイムで行われるようになり、誰もが何処にいても情報を得られるようになった。それが情報のフラット化といわれている。

 しかしその流れを現状の企業情報システムに当てはめてみると、本当に先のようなフラットなコミュニケーションができるシステムとはなっていない。確かに技術という観点からみれば、受注や出荷などの企業活動を即座に情報としてデジタル化できるようになった。ネットワークの敷設により、誰もがそれらの自由にリアルタイムな情報を取得できる環境も構築できているし、一元的に情報を管理するするためのERPシステムも広く製品化されている。しかし蓄積された情報をリアルタイムに活用して、次の行動の意思決定につなげるまでにはいまだ至っていない。それは次の行動を起こすような情報の蓄積がきちんとできていないからである。当会では誰もがアクセスでき、次の行動の意思決定ができる情報の蓄積庫を「情報の海」と名づけている。

 ではなぜ、情報の海が実現できないのか。たとえERPシステムを導入されていたとしても、今すでに走っている組織をそのシステムにあせることがきわめて難しく、全社的なシステムとして見た場合に蓄積される情報が正確でない可能性があるからだ。例えば在庫1個とコンピュータ上に表示されている商品をこの場で客に売る決断をするには、その数字が本当に正しいかどうか確信をもてなければならない。誰かがすでに売ってしまっているかもしれないのだ。確信がなければあちこちに電話しまくって確かめることになる。情報の海はリアスタイム情報であるが、そこで重要なのはスピードというより、いつでもどこでも判断のための「正しい情報」が見れることなのである。

 では理想の情報の海ができたからといって、人が正しく行動できるかというと、そう簡単なことではない。そこで必要になるのが人が判断するための意識のフレームモデルである。フレームモデルには個人フレーム、その上位にある企業フレーム、さらにその上位にある社会フレームと3段階と考えるのが現実的である。現在の社会は変化が激しい。従来のような考えではうまくいかず、社会そのものがパラダイム転換を迎えている。その中にあって、多くの日本企業は従来の企業フレームから抜け出せていないという現状がある。今後、企業が元気になるためにも、企業フレームを見直し、時流にあったものへと変革していかなければならない。それを当研究会で話し合い、その成果を発信していきたいと考えている。

関連資料 PDF yamada081028.pdf(62KB)
contents ↑

 上記山田氏の発言を田口氏は多少の補足がなされた後、情報の海的なものがきちんとつくられた企業による、講演が行われた。トップバッターは大三紙業である。大三紙業の松井孝悦社長による講演は以下のとおり。

講演1:「情報の海がもたらす自律神経組織」

松井孝悦 大三紙業株式会社 代表取締役
松井孝悦氏

 大三紙業(http://www.daisan.com/)は愛知県豊橋市に本社を構える食品や電子工業、繊維製品などの軟包装資材メーカーである。中でも主力である食品包装材業務では、顧客のニーズに合わせて仕様を決めるのはもちろん、同じような工程でも中味によって加工の仕方が異なるなど、システム化しにくい要素が多かった。

 そんな課題を抱えながらも、大三紙業では1980年代後半からいち早くオフコンを導入、90年代にはさらにそれを強化する一方で日報システムを導入するなど、積極的にシステム化に取り組んできた。

 受注から発注までのすべての業務がスムーズに回るシステム

 J90年代後半、受注から加工の段取り、出荷まで特別な確認や指示をしなくても必要な情報が行き届き業務がスムーズに進むインフラ作りをしようと、基幹業務系システムの刷新に着手した。つまり基幹情報システムを自律神経のようにしたいと考えたのである。2000年に新システムが稼動。現在は会社の自律神経として、受注から発注までのすべての業務が、特別な指示をすることなくスムーズに回っている。
効果はそれだけではない。生産リードタイムの短縮や在庫の縮小、納期遅れの減少などの効果も出ている。また今回のシステムではクライアントにウェブトップとJavaを採用、端末メンテナンスやプログラム保守、サーバー保守の工数がほとんどかからなくなるなど、情報システム管理者にとっても大きなメリットが得られた。もちろん社員にもいい影響を与えており、効率化やスピード化、顧客への情報サービスの点で認識の変化が見られている。必要な情報がタイムリーに提供されることで、業務に対する意欲も向上しているようだ。

 運用のレベルアップが不可欠

 システムを刷新しただけで、先のような効果が出たわけではない。新システムを稼動する際には、情報システム運用のレベルアップに取り組んだ。従来のシステムではバッチ処理を行っていたため、データエントリーに関してもそれほど厳密ではなかった。しかし新システムはリアルタイムシステムであるため、業務が発生した時点で入力しないと動かない設計となっている。そこで従来の習慣からの脱却に取り組んだ。またデータエントリー系、業務系、参照系の使い分けなど、特定の画面はその業務担当者が見るものであるという社内の習慣も覆す必要があった。
また信じられないような運用の抜け道を見つけ出す社員もいるため、正しい運用を守らせることへの注意は欠かせない。社内で正しくシステムを使うためにも、運用管理者は運用のマネジメント力をつけていくことが大きな課題である。

 情報システムを導入する上での注意点を3つ挙げる。
第一にシステムは購入すればいいというものではないことを認識したい。社内業務をすべて洗い出し、改善する覚悟が必要である。第二にシステムとは社員全員の英知の結果である。要件をまとめるためにも、社内にいる相当数の社員をかなりの時間を拘束することが必要になる。第三に本気で使う気にならなければ動かないということ。カットオーバー後、全社一丸となって新しいシステムを使っていこうという気力が必要である。
当社では近い将来、フルリプレースを予定しており、業務プロセスを設計・実装できる開発アプローチの登場に期待している。

関連資料 PDF matsui081028.pdf(395KB)
contents ↑

 松井氏の講演の後、簡単な質疑応答が行われた。「お客様からも在庫の状況などが見られるシステムであるということだが、リスクはないのか」という問いに対し、松井氏は「そういうシステムになったのは4〜5年たってから。特定顧客と長く付き合っていくためのサービスとして位置づけている。不特定多数の顧客に提供しているサービスではないので、リスクはないと感じている。「このシステムの鍵を握っているのは運用である。企業であれば人が変わったりすることもある。そのようなとき、どのようにして運用レベルを維持していくのか。その秘訣があれば教えて欲しい」という問いに対して松井氏は、「それはいたちごっこでしかないが、とにかく社員全員に運用レベルを維持するんだという意識を啓蒙していくことしかないと考えている」と回答した。

講演2「マスタの一元化によるデータ基盤構築と基幹システムによる経営の見える化──インプレスの成功事例」

山崎敦史 株式会社インプレスホールディングス CIO執行役員
山崎敦史氏

 インプレスは1992年の創業以来、分社化やM&Aによって現在は20社を超えるメディア企業グループに成長した。グループでは各社の独立性を担保する狙いもあって、それぞれ別々のシステムを構築していた。持株会社のインプレスホールディングスは上場企業であり、2000年代前半に経営の見える化、内部統制への対応などを図るべく、マスタの一元化を伴う基幹系システムの刷新を実践することにした。しかし出版という特殊な業態を内包すること、グループ企業の多さなどから、過去2回にわたって基幹システムの構築は不成功に終わっている。3度目の今回、成功裏に刷新を完了した裏には「何としても、成功させる」という経営者の強い意志とスタッフの思い、それを支える方法論があった。

 「基幹システムとは何か」から定義

 他の多くの企業と同様、インプレスでは新事業を始めるたびに新しいシステムを構築してきた。そのため事業ごと、グループ企業ごとに商品マスターや顧客マスタが存在していた。当然、財務会計情報や管理会計情報をまとめるために工数がかかってしまう、コスト低減を図ることも難しい。事業単体での採算性も最終集計をしないと分からないなど、さまざまな問題点を抱えていた。

 そこで何としてもグループ共通の基幹システムを、となったわけだが、3度目ゆえに十分な予算を投入しにくいという課題があった。刷新プロジェクトの担当チームはこの課題に対し、まず業務改革プロジェクトを実施、年間2億円近い経費削減を達成した。IT投資の原資を生み出したわけである。同時にプロジェクトを通じて、グループ全体の現状の業務プロセスを経営トップにも分かる形で図式化し、社内の意識改革につなげた。次に経営戦略から展開したIT戦略を策定し、基幹システム検討委員会を立ち上げた。その上で基幹システムはどうあるべきか、それに何を期待するのかなど、委員会メンバーによる検討を繰り返した。

 まず既存のシステムから必要なデータを抽出して共有データベースを構築し、単純に商品マスタや顧客マスタを統合しようとしたが、それではすぐに役に立たなくなるという結論に達し、取りやめた。インプレスでは中期経営計画の一つとして、店頭などのリアルチャネルとインターネットなどのオンラインチャネルの双方のビジネスを展開する仕組みを実現する戦略を立てていた。たとえば単純な書籍販売ではなく、電子書籍の章売りやページ売りを可能にする。その場合、元の書籍の原価を電子書籍にも賦課する必要がある。

 一方、ローテーション型およびスペース型などデジタル広告の種別ごとの売り上げ把握を可能にしたい、組織体制に変更があっても製品別・部門別売り上げやその原価を過去にさかのぼって集計したいなどのニーズもあった。こうした検討の結果、現状の要件だけを吸い上げるのではなく、将来にわたるビジネスに対応できるマスタの定義と構造作りに取り組むことを決めた。例えば、各社の経営管理の柔軟性を保つために勘定科目マスタはグループ共通とするが、勘定補助項目を設けて各社ごと自由に設定できるようにするなど、マスタ運用におけるオーナーシップと責任も明確にする作業を行った。
「スピードアップ」「正確性向上」を目指して、2004年10月、データ基盤と基幹アプリケーションからなる新しいグループ基幹システム「P-1」の構築を開始した。

 目標を上回る効果を確認

 P-1構築に際して、開発したユースケースは650、業務項目は4,300。開発工数は内部工数も含め600人月で約2年半の期間をかけた。カットオーバーは2006年10月から3度に分けて、既存システムからP-1への切り替えを行った。現在はグループ会社20社がシステムを利用しており、2008年4月このプロジェクトの結果検証を行い、当初目標を十分に上回る効果を上げている。具体的には、システム構築の目標だった業務のスピードアップや正確性の向上などを実現。連結財務諸表の作成が2日早くなり、異常値の原因を容易に追究でき、ミスが起きる可能性を減らした。日本版SOX法対応、つまり内部統制も容易になり、拡張性が高まるなどの効果も認められた。

 今回の基幹システム刷新プロジェクトを通じて改めて確認した、プロジェクト成功のポイントは6つある。1.経営レベルで新システム導入の目的を明確にし、責任を持つこと。2.新業務プロセス、システムの仕様を決定する責任部署を設置すること。3.社内業務と対象システムの知識を持つメンバーが参画すること。4.外部ソフトウエア会社と社内プロジェクトメンバーの間での用語統一、言葉の定義を行うこと。5.十分な開発経験をもつ外部ソフトウエア委託会社と技術部が協業すること。6.成功体験におごることなく実態を冷静に捉えることである。

contents ↑

 講演に引き続き、質疑応答が行われた。「基幹システムの構築では、業務分析がカギを握ると思う。経営者や一般社員にも分かる業務分析図に工夫した点があれば」という質問に対しては、「業務分析図は、開発を委託したアトリスのものを使った。モデル化や抽象化も同社の技術者に任せたが、出来上がった業務分析図は確かに理解しやすいものだった」と答えた。一方、「エクセルをつかって財務諸表を作成する企業も多い。それでは日本版SOX法へ対応するのは難しいということか」という質問には、山崎氏は「エクセルで財務諸表を作成し、内部統制の有効性を確保するのは無理だと考える。変更していない証拠を用意するためにエンドユーザーコンピューティングの規約を設けるなど、さまざまな縛りが必要になるからだ。それでは業務が回らなくなる」と回答した。

講演3:基幹系再統合へ向けた私論と事例

青山周平 三井情報株式会社 総合研究所シニアコンサルタント
青山周平氏

 多くのシステム部門が抱えている重要課題の一つが、増えすぎた情報システムの統合である。背景にあるのが、サブシステムとサーバーが多すぎること。肥大化しすぎた結果、どこから手をつければいいのか分からないと感じているのが現状だろう。状況を打開する万能薬はなく、何がどうなっているのかを地道に調べるしかない。そこで私のようなコンサルタントが呼ばれるのだが、As-Is分析をDFD(データフローダイアグラム)や業務フローなど従来型の図式化手法で行うと情報量爆発が起き、次に何をしたらよいか分からなくなり、時間と金銭、意欲が消えていってしまう。

 肥大化したシステムにおいて、分析マヒに陥るのを防ぐ手法がPEXA

そのような分析マヒ状態に陥るのを防ぐ手法の一つがPEXAである。PEXAは ①伝票処理を中心とした定型業務システムに特化して業務を可視化するする分析・設計手法、および ②その方法論から導き出された成果物に基づいてJavaアプリケーソンを自動生成する実行環境、の2要素からなる。筆者が2006年に話を初めて聞いたときにはあまりのよさに信じられなかったが、詳しくヒアリングするなど調べていくうちに使えそうだということがわかり、2007年に三井物産グループのあるプロジェクトに適用した。

 PEXAによる上流分析は、「顧客の持っている定式化されていない情報から、定量的かつ検証可能な表現形式であるSVOステートメントに実現すべき機能を変換する」という定義に基づいて行われる。PEXAでは、すべての定型業務は以下の6つのパターンに当てはまるという仮定――といっても多くの適用例により実証済み――の下、ユーザー側担当者へのヒアリングや資料調査を通じて、個々の業務をパターンに当てはめて定義していく。

PEXAのビジネス概念モデル。

  1. Order-Result(指示・実績)パターン
  2. Request-Task-ToDo-Remainder-Alert(ワークフロー)パターン
  3. Account-Entry-Transaction(トランザクション)パターン
  4. Contract-Service-Use Charge(契約)パターン
  5. Target Scenario-Evaluate(評価)パターン
  6. Item-Portfolio(ポートフォリオ)パターン

 なお、こういった業務分析を手がけた経験がある方なら分かるはずだが、定型業務主体の基幹系では3つ目のAETが主で、Item-Portfolioが付随し、Order-Resultが混じることが多い。

 分析作業は、最初にミッションステートメント(プロジェクトの目的)を確定し、次にAs-Is分析、さらにTo-Be分析を行い、最後に個別課題の整理と全体のまとめ、という流れで行われる。

 説明の難しさ、理解にしにくさがPEXAの課題

 PEXAの優れた点は、定型業務に的を絞ったこと、SVOステートメントという表現形式やビジネス概念モデル、それに当てはめて業務分析し詳細化する各種のツールとドキュメントなどにある。上記の説明だけでも、なんとなく業務をシステム化可能な形で分析できるのでは、という感触を持っていただけるのではないだろうか。

 半面、より詳細な説明、あるいは上記のパターンの詳細などにもう一歩踏み込むと、急に難しくなる。これがPEXAの現状の課題だ。例えばSVOステートメントは英語のそれとは当然異なり、PEXAでは「ロール(S)は、組織・人から実行権限を分離したものであり、組織・人はロールの属性(参加者)として記述する」となっている。組織や人から実行権限を分離すると何が残るのか、残ったもの分離してきた実行権限を指すのか、この意味はよく分からない。また「Vはイニシアチブ」と定義されており、「O(イニシアチブ・ターゲット)に対する行動」である。Oは「操作対象であり論理的な伝票の単位に相当する」とされている。

 一方、「SVOステートメントは量子化された最小単位で、これより小さい単位(プロセス)では業務が完了せず、これより大きい単位では基準が明確ではなくなるもの」と定義されている。量子化という、一般にもIT分野でも使われない言葉が出てくる。これらのよく分からない表現を解消しないと、使う側にとって敷居が高い。

 私なりの理解を紹介する。As-IsでのSVOステートメントとは、業務機能をSVO形式で記述したものであり、英文法と同様にS(Subject)は「誰が」、V(Verb)は「どうする」、O(Object)は「何を」を表したもの。量子化された最小単位という表現は特に気にする必要はなく、粒度は具体的なイメージが想起できるかどうかで判断すればいい。想起できない場合は、より詳細な情報を聞き出し記述することを心がけた。To-BeのSVOステートメント記述に関しては、PEXAによる定義を正しく適用することが求められる。まずは従来手法同様、システムのサポート範囲を決めて、その対象を細かく再検証することが大事だ。

 次に気をつけなければならないのが、As-Isでは別々に記述するものも、システムとして同時に処理すべきものであれば一つとして扱うこと。商品の受注と在庫引き当てなどの業務はその例である。また述語はPEXAで定義済みの述語に置き換えるなど、適確性が求められる。このPEXAの動詞体系に合わせていく過程で、粒度は自ずから修正される。管理的SVOは業種に特化したコンサルタントが補うことも必要である。

 ロール分析はイニシアチブ・パターンを元に、役割(S)が何(O)に対してどのような権限を持っているかをパターン化する作業である。各ロール間でどのようなオペレーションに基づき、どのような操作対象を操作して業務を行っているかを記述していくのである。

 PEXAの欠点をAET図で補う

 最後にDFDや業務フロー図などの旧来手法とPEXAの最大の違いは、PEXAの場合、業務とシステムの両方の視点で記載ができることを強調したい。ビジネスルールは記載しないため、分岐やループが出てこないことや、情報密度が最大であることなどもPEXAの特徴だ。しかし、SVOステートメントだけでは限界もある。第一の欠点は業務の流れを追うのが難しいこと。第二に関係のないSVOステートメントも前後の脈略なく記載されるため、業務担当者にとって分かりにくいことである。

 その欠点を補足するのに活用したいのがAET図である。AET図とはAccount(勘定)間をTransaction(システムへの入力)によってEntry(明細行)が移動する業務フロー図の一種である。これを作成することによって、SVOステートメントに過不足がないかどうか、容易に検証できるようになる。
実際、PEXAで上流分析を実施すると、従来手法に比べ少ない工数で終えることができた。ルールを無視するという割り切りがある、到達点が明快に規定されていることが、その理由である。

関連資料 PDF aoyama081028.pdf(38KB)
contents ↑

講演4.業務システム構築の科学的開発手法にふれて

山口光士 株式会社おきぎんエス・ピー・オー
山口光士氏

 おきぎんエス・ピー・オーは沖縄県に拠点を置く、沖縄銀行のSI子会社。売り上げの4〜6割が沖縄銀行関連となっている。しかしながら地銀システム共同化の流れや昨今の金融業界の不安定な状況などにより、銀行依存のビジネス構造から脱却する必要性に迫られている。またそれを実現するためには、システム部が抱えている問題を改善する必要性もあった。

 属人的なプロセスを排除し、標準プロセス策定に取り組む

 システム部が抱える最大の課題は科学的な標準プロセスがなかったこと。仕事はいきあたりばったりでリスクだらけ。プロジェクトの状況も見えず、計画や成果物の妥当性が検証できないなど、属人的な要素で占められていた。そのため、QCD(品質、コスト、納期)が達成できない、担当者でなければ保守ができない、プロジェクトのナレッジが共有されないなど、バッドスパイラルに陥っていたのである。そこで昨年、科学的な標準プロセスを策定と研究チームを立ち上げ、本格的に取り組むことになった。

 また幸いなことに同時期に内閣府の「オフショア開発センター整備モデル実証事業」を受託、この実証で得た成果も自社の標準プロセスに取り込むことができた。

 標準プロセス策定への取り組みをしていく中で課題も浮かび上がった。まずは業務分析・設計手法の問題。実績と比較するためには定量的な粒度で機能を分解する手法が必要である。最初はユースケースを試みたが、それでは粒度を揃えることが難しい上に、仕様書を言葉で記述するためにあいまいになってしまう。第二に習得コストの問題。図解言語や概念の習得には多大なコストがかかる。第三は業務パターン蓄積の問題。当社は小規模ながら多種多様な顧客を持っている。そのため一度でも携わった業務パターンを標準的手法でパターン化して、また次の顧客に生かすような仕組みを作りたいと考えたのである。

 PEXAで課題を解決

 そんな壁にぶつかっているときに出会ったのが、PEXAである。PEXAはこれらの課題を解決する手法だった。第一の特徴は対象業務を定量的に分解する分析手法「SVOステートメント」を持っていること。第二に機能をプロセス、ルール、データ(業務項目)に分類する設計手法「ActivitySheet」があること。第三に抽象度の高いモデル構造が実現できる6つのビジネスパターンを持っていること。このビジネスパターンを組み合わせるだけでシステムが表せるのである。その他にもPEXAはテンプレートやパターンを持っていて、顧客から提供される素材をこれらのテンプレートやパターンに当てはめていくのである。モデリングの知識は多少必要だが、従来のモデリング手法よりは習得するのに断然敷居が低くてすむ。開発は言語知識すら不要であるため、習得コストもそれほどかからない。また業務知識蓄積の問題もビジネスパターンとSVOステートメントで解決できる。

 もちろん、PEXA自身、改良しなければならない余地はあるとはいえ、これを活用することで新たな可能性が見えてきた。これまで標準プロセスがないことで諦めていた外部リソースの活用の可能性がでてきたこと。また業種ごとに抽象化されたシステムの構造は、同じ業種内の横展開の可能にする。さらにはSaaSとして提供することも可能だ。その他ユーザーとのコミュニケーション基盤として使えるのはもちろん、CMMIのレベル3〜4を目指すことも可能になるかもしれない。

contents ↑

 講演の後簡単な質疑応答が行われた。「どのくらいの研修期間で習得できたのか」という質問に対して、山口氏は「私自身はアトリスで学んだのは2カ月間。またもう一人の上流分析を担当するITコーディネータは1カ月間滞在して、SVOステートメントをつくる知識を得た。すでに案件でも適応し、それなりの分析作業ができたという報告を得ている」と回答した。

 こうして3時間半に及ぶ公開セミナーは盛況のうちに終了した。

交流会でのピアノ演奏