第14回 『21世紀型情報システムを考える』研究会
─20世紀型アプローチからいかに決別するか──
─20世紀型アプローチからいかに決別するか──
ケース紹介：構造変革が激しいメディア産業における基幹システム構築事例
| 講 師： | 山手 章弘
株式会社インプレスホールディングス 取締役/執行役員CFO
|
|---|---|
| 日 時： | 2010 年7月6日（火）16:00〜18:00 |
| 場 所： | (株)アーク情報システム AK大会議室 |
21世紀型情報システム研究会が発足して約2年半が過ぎた。会の冒頭で田口潤ナビゲータはこれまでの研究会で議論してきたことを紹介した。
最初の約1年（第1フェーズ）は、山田博英ナビゲータが提唱する「情報の海」の必要性について議論してきた。「情報の海」とは人や組織が自律的にアクションを起こせるよう、活用可能な形で情報を蓄積するための仕組みである。どうすれば活用可能な形になるのかなど、その基準について議論した。その結果は10カ条にまとめてBPIAのホームページに掲載している。
第2フェーズでは、情報の海の対になる「ABCフレーム」を議論した。情報の海を活用して、自律的に活動する組織に欠かせないのが、ある種の判断基準＝ABCフレームである。具体的には、人が意思決定し行動するには、大きく3つの背景が影響している。個人はそれぞれの行動規範を持つ。しかし会社に勤務する個人の行動は、その会社の理念や戦略などに影響を受ける。そして会社は社会の規範に影響を受ける。このように個人の行動や思考は、社会（C）、企業や組織（B）、そして自分自身（A）に影響を受ける。
一方で21世紀の現在でも、ABCのフレームは20世紀のまま留まっている。これでは、情報の海を実現するシステムがあっても、その真価を発揮できない。では20世紀のABCフレームはどんなもので問題は何か、21世紀のABCフレームとはどんなものであるべきか――それを議論してきた。その結果についても、10カ条にまとめ、BPIAのウェブページで公開している。
2009年末からは、情報の海を提供するための情報システムのあり方、つくり方について議論する段階へと入った（第3フェーズ）。20世紀型のシステム構築の方法論やアプローチでは、個別システムは構築できても情報の海を提供できるようなシステムは構築困難。では情報の海を装備した21世紀型の情報システムを構築するには何が必要か、そのための手法や方法論はどんなものなのか。これを先進事例などを題材にしながら探っていくのが、第3フェーズの目的である。
このフェーズの第1回の議論では、メンバーである草場氏、大西氏のレクチャーにより、知名度のある大企業でさえ、情報の海とはほど遠いシステムしか有していない実態を明らかにした。今回は、先進事例として、インプレスホールディングスを取り上げる。同社の基幹システム開発について紹介するのは、開発に携わり、現在インプレスホールディングス取締役/執行役員CFO（最高財務責任者）の山手章弘尚氏。同社システムを実際に構築したのは、当研究会のメンバーである安光正則氏（アトリス代表取締役社長）である。
山手氏の講演概要は以下の通り。
インプレスグループは専門コンテンツを展開するメディアグループである。IT以外にも音楽関連やデザイン関連、医療関連、山岳・自然関連、さらにはモバイルサービス関連などさまざまな分野のコンテンツを提供している。売上は170億円、スタッフ数800人と、出版社の中では中堅規模。特徴は分野ごとに専門性を生かすため分社経営していることである。私が所属するインプレスホールディングスは純粋持ち株会社。グループ会社の基幹システムやネットワークインフラ、資金などの一括調達・運用をしているため、各社は事業運営に専念している。2000年10月に東京証券取引所に上場している。
基幹システムを刷新する背景には、当社が抱えるいくつかの課題があった。まず出版業界は委託販売（書店は売れ残った書籍を一定期間であれば返品できる）や再販制度（定価販売が義務付けられている）など特殊な商習慣があること。しかも最近では、iPadなどの登場により電子書籍も普及してきた。新しい売り方などこれまでとは異なるビジネスモデルが確立されていくはずである。また「IT Leaders」のように購読料は無料で、広告費のみで売り上げるコンテンツや出版物も登場している。これも従来までの書店売りの出版物とは異なるビジネスモデルである。このように異なる収益・販売モデルが出てきていることから明らかなようにメディア産業は急激に変革しており、その新たな収益機会を獲得していくことが求められていた。新たなビジネスモデルを確立するために、販売管理や管理・財務会計の仕組みの刷新が必須となった。
先述したように、グループ各社で規模の大きい会社以外は事業運営に専念するために経理、総務などの管理部門をもっていないため、管理業務は当社で集中管理している。
また2000年10月に東証に上場したことも、基幹システムを刷新するきっかけとなった。正確かつ早期の連結決算開示が必要になったからである。その後、制度の改正により四半期開示や内部統制報告制度（J-SOX）、国際財務報告基準（IFRS）への対応も検討する必要が生じている。
当社では96年より基幹システムの開発にチャレンジしてきた。最初は自社開発だったが失敗。2度目はERPパッケージにカスタマイズを加えるという方法を採用した。これも上手くいかず、上場後もレガシーシステムをベースに手作業で対応することが続いた。
従来、当社が導入していた会計システムは、富士総合研究所（現みずほ総合研究所）のパッケージをカスタマイズしたものである。生産管理システム、販売管理システムなどすべてバラバラに導入されており、中でも販売管理システムは販売チャネル毎に6種類もの異なったシステムが存在していた。
マスタやデータがバラバラという状態は、2002年まで続いた。
「さすがにこのままではまずい」──そう考え、2003年より約2年間、業務プロセスの把握と経費削減を目的に業務改革プロジェクトに取り組んだ。業務プロセス洗い出しの過程では、地球シミュレーションと呼ぶ各社各部門の業務プロセス図、いわゆるユースケース図を作成した。その後、主に物流インフラの業務プロセスを見直したことで、年間2億円程度の経費削減を実現した。
クリックすると拡大します。
こうして整備した業務プロセスを一つの基本として、2004年4月に基幹システム構築プロジェクトが発足。同年10月まで検討を行い、2006年3月までに詳細仕様を決定。仕様検討を1年半ぐらいかけて綿密に行った。
刷新した基幹システムの概要を紹介する。利用会社は現在17社。連結子会社は合弁会社と在外子会社を除く、すべてのグループ会社に原則利用を義務付けている。開発したドメインは会計、販売管理、生産管理、情報の4業務。会計ドメインのサブドメインである財務会計は、一から開発するのは難しいという理由から、SCAWというパッケージを利用した。その他の管理会計、支払管理、ワークフロー（マスタ登録、支払申請）などは、今回、新規開発している。
販売管理ドメインはすべての販売チャネルの売上データについて一元化している。先述したように出版販売は非常に特殊な商習慣なので、受注、請求、在庫数管理についてはレガシーシステムを利用している。
生産管理ドメインについては、すべてのプロダクトのマスタ管理をしている。情報ドメインについては、ユーザーによるデータ抽出、加工ができるよう、DrSumというエクセルベースで加工が出来るツールを導入した。
そのほか、直販受注システムや印税計算システム、連結会計システムについては、複雑な仕組みをもつ、もしくは将来のビジネス構造が予測できないため、現時点では基幹システムと連動して運用する方法を採用している。連結会計については今のところ、基幹システムとの同期は考えていない。
基幹システム開発にあたり、課題も複数あった。第一にマスタやトランザクションデータが複数存在、散在していたこと。これらすべてのシステムについて把握できる人はいなかった。第二に手作業や重複作業による無駄が多く、データの整合性を維持できていなかったこと。ミスの発生率も高かった。第三に経営情報を適時かつ正確に取得できなかったこと。集計は各システムから取得して手作業で行っていた。データの定義が標準化されておらず、情報自体の信憑性がなかった。第四に常に変化する経営環境、事業領域に対応できていないこと。当社の子会社の数はつねに増減している。このように新しいビジネスモデルが立ち上がるたびに新しいシステムが稼働するため、刷新のタイミングを図るのが難しかった。
以上の課題を解決するために「グループデータ基盤」と「グループ基幹アプリケーション」の活用により、効率化・スピードアップ、正確性のアップを図り、グループの利益増に貢献させることを新システムの開発目標と定めた。
そのために具体的に取り組んだのが
などである。
過去の失敗を教訓にしたこと以外にも、さまざまな成功の要因があった。
第一に基幹システム開発の目的、獲得目標を経営レベルで共有したことである。プロジェクトの目的を経営レベルで定め、役割や責任を明確にしたのである。仕様決定はドメインオーナーが行い、システムオーナーが最終決定をした。当社は以前よりドメインごとにシステムを共通運用していたので、各ドメインオーナーが各社の意見も多少取りいれ、あるべき姿に纏め上げることができた。ちなみに会計ドメインのオーナーは私である。販売ドメインは、販売管理業務を担当している会社の人など、各業務のプロがドメインオーナーを務めたことも成功のポイントとなった。
第二に業務プロセスの定義を十分行ったこと。これ以前にも何度か基幹システムの構築に関わったことがあるが、ユーザーとシステム会社の認識が食い違うこともたびたびであった。それが積み重なり、失敗を招いたように思う。今回は最初から、ユーザーと開発側の誰もが理解できる表記方法（ユースケース）で仕様を決め、まったく同じ認識で出来るようにした。しかも認識のぶれをなくして完全に一致させるため、ユースケースはできる限り細分化した。最終的に確定したユースケース数は650、業務項目数は4400だったが、当初はユースケース数が1800ぐらいあった。余分な部分を切り捨てたり、プロセスを見直て絞り込み、この数値となった。
第三にデータの定義・用語の整備が十分にできたこと。ビジネスパターン（To-Be）をかなりの時間をかけ検討したうえで設定し、マスタ体系を整備。各ドメインでデータ項目の抽出を行い、粒度、項目名の刷りあわせを徹底して行った。
第四はこれら3つの意味を現場レベルで十分共有できたこと。基幹システムを構築する前に、業務改革プロジェクトにおいて、現場の業務プロセスをヒアリングし、検討委員会で各社の経営レベルも含めて、ディスカッションをじっくり行ったことが成功の要因として大きかったと考える。
基幹システムとはいえ、当グループの利益を増やしていくのが目的である。今後は、事業よりのシステムを構築し、基幹システムに取り込んでいくことを考えている。例えばPOSデータ（書店）と配本実績の基幹システムへの取り込みにより、製造・販売計画への活用はその一例である。これにより、売れる確率の高いところに配本を調整し、返品率の低減を実現したい。
またEC（直販）事業の新たなビジネスモデルへの対応も検討したい。自社製品型（出版物）から仕入れ商品型への対応や、会員・読者への付加サービス、メディア連動型ECなど、より競争力のある新しいビジネスモデルへの対応、より利益が増やせるシステムの開発に注力していく予定だ。
田口ナビゲータ： ありがとうございました。私も同システムのユーザーの一人。その立場で見たとき、データモデルやプロセスが突出して複雑というわけではない。しかし過去2回は失敗してきた。今回成功した要因はプロセスの整理、要件の明確化、マスター辞書の作成など、当たり前のことばかりのような気もするが、実際にはまだこのあたりからできていないということなのか。
安光氏： プロセスや表面上のモノや金の動きから取り組むと、うまくいかない。一番大事なことは、商品（事業）の概念モデル化と、それをどうやって作るか、どうやって売るかがの定義がきちんとできていること。それがないとマスタさえつくれない。インプレスの成功の要因は、商品の概念モデルがきちんと作られていたことだ。例えば病院の場合、クリニカルパス（ある病気の治療や検査に対する医療工程）が商品とすると、糖尿病だけで3000項目にも上ってしまった。それが病名の数だけある。こういうパスを整理するだけでは、システムに乗らないということがわかった。
Q： サービス産業の方が商品概念の定義づけは難しい？
安光氏： サービス産業はモノづくり産業に比べ、商品という概念が明確ではないので難しいと思う。インテグレータではこの企業の商品は何かということはわからない。だからプロセスから入って、失敗する。
Q： 勘定科目の設定のあり方などは、従来からそれほど変わっていないと思うのだが。
安光氏： 例えば病院の場合、細かい勘定科目は何かなどわからない。
山手氏： 財務会計でもっている粒度とデータを集計しているデータの粒度は異なる。
Q： 料金一つ一つが勘定科目になるのでは。
安光氏： 予実管理をするには原価がわからない。原価はなかなか出てこない。定義がつくれない。サービス業の原価ははっきりしない。どんぶりになるという構図だ。商品の概念モデルが必要な理由がそこにある。
山手氏： 例えば当社の場合、間接費は原価に振り分けてはいない。コンテンツがどういう収益を上げているかで考えている。部門ごとに利益管理ができていればよい。
Q： IFRSなどには対応する予定は？
山手氏： 返品が契約上に存在する出版業界の特性上、IFRSへの対応で収益認識に関しては、いくつかの方法論を検討する必要がある。
Q： システムの話とは関係ないかも知れないが、グループに入るメリットを聞きたい。関接費削減以外にも。
山手氏： グループの個々の会社は小さく、大きいところでも100人規模だ。最大のメリットは、様々な事業インフラを利用できること。100人規模では決して借りられない巨大なデータセンターも借りられる。
田口ナビゲータ： グループの1社にいる身で言えば、人材採用の面でもメリットがある。
Q： グループ企業同士の人事交流もある？
山手氏： ある。また同じようなビジネスを展開しているため、それに関するノウハウも共有できるメリットが大きい。
田口ナビゲータ： 話をシステム構築に戻すと、山手さんのレクチャでは、業務改革とプロセスを見える化したという話があった。どちらから先に手をつけたのか。
山手氏： 並行してやっていたと記憶しているが、まず目標として利益を増やすにはどうするかを考えることから始めた。プロセスというよりは、グループが持っているものの何が強みなのかを先に考えた。それがないと何もできないと思った。
山田ナビゲータ： 強みがどこにあるかは、現場の人が体感している感覚をマクロのモデルの中で位置づけるトップダウンとの融合の中で行う必要がありますね。
田口ナビゲータ： ビジネスの粒度をどこにおくのかで異なってくるように思う。
山手氏： ホールディングスの仕事は、各事業会社の強みはどこにあるのかを考えること。私たちも常日頃から考えていたと思う。
安光氏： 現場の事業会社サイドにそれほど知識があるとは思えない。
佐久間氏： 山手さんのお話を聞いていて、コンサルタントが不要になったのは、彼らがプロセス指向になったことも要因の一つではないかと思った。コンサルティング会社のコンサルタントの仕事は、As-Isを書いて整理することとなっている。しかしシステム構築の現場ではプロセス指向の人ではなく、どういうビジネスなのかきちんと定義でき、システムを考える人が求められているということがわかった。
田岡氏： プロセスもデータモデルも双方、整理しないとうまくいかないという話だと理解したが……。
鶴保氏： 今、IT業界はプロダクトアウトから抜け切れない。ソリューションを顧客は求めている。だから必死になってソリューションに行こうという流れになっている。
田口ナビゲータ： 安光さんに聞くが、本当にプロセスからいくとうまくいかないのか？
安光氏： プロセスからいくと判断がつかないと思う。
山手氏： As-IsからTo-Beを作ったわけではない。本来どうするべきか、ということから考えた。
田口ナビゲータ： プロセスとは何を指すか、人によって捉えているものは違う。プロセス整理という作業の中では、このあたりもきちんと整理されていたということだと思う。
安光氏： システムを作るというより、会社の概念や組織をつくるというイメージが強かった。As-Isのシステムを整理すればシステムをつくれるシステムもあるが、ほとんどのシステムでは、プロセスがどんどん変わるのでつくれない。
田口ナビゲータ： 最後に成功の要因を4つ挙げているが、システム側から見るとそれは成功の要因になっているか聞きたい。
安光氏： 第一の基幹システムの開発目的、獲得目標が経営レベルで共有されていたことはその通り。第二の業務プロセスの定義が十分できたこと、データの定義、用語整備が十分できたことももちろん成功のポイントとなった。しかもそれらをすべてユーザーが主導したこと。ここは大きなポイントだったと思う。そのほかの要因としては、繰り返しになるが、商品とは何かという概念モデルがきっちり定められていたこと。このあたりはビジネスコンサルタントに頑張ってもらいたいと思っている。
田口ナビゲータ： 次回も当事例を参考にさらなる議論をしたいと思う。