『21世紀型情報システムを考える』研究会
─20世紀型アプローチからいかに決別するか──
─20世紀型アプローチからいかに決別するか──
第15回 第3フェーズ「情報の海をどう作るか」
| 講 師： | 三嶽 政則
株式会社インプレスホールディングス システム開発部 部長
|
|---|---|
| 日 時： | 2010 年9月1日（水）16:00〜18:00 |
| 場 所： | (株)アーク情報システム AK大会議室 |
「21世紀型情報システムを考える」研究会では昨年末より、情報の海を提供するための情報システムのあり方、作り方について議論する段階（第3フェーズ）へと入っている。前回の研究会では、その一つとしてインプレスホールディングス（以下インプレス）の事例が紹介された。
田口潤ナビゲータは、前回の内容を次のように振り返り、今回の講演に至る経緯を説明した。
「インプレスは2度の失敗を経て、基幹システムの構築に成功した。3回目に成功した要因、1回目、2回目の失敗をどう乗り越えたかなどは、前回の事例発表で披露されたとおりである。
前回のインプレスの事例発表によりわかったことは、業務プロセスを整理してas-isを可視化しても、新しいシステムができるわけではないということ、そうではなく会社が目指そうとしているビジネスの概念モデルを定義することが大事ということである。前回の事例発表後の質疑応答では、これら2つのことに参加者の関心が集まった。
そこで、今回はインプレスがどんなきっかけで概念モデルの策定に取り組んだのか、またそれが基幹システムの開発に必須だという意識があったのかについて、概念モデル策定の中心的人物だったインプレスホールディングス システム開発部部長、三嶽政則氏に講演を依頼した」
三嶽氏の講演内容は以下の通り。
グループ基幹システム「P-1」がどのように開発されていったのか、流れを説明する。当社では過去2度の基幹システム開発の失敗経験があった。そこで「P-1」開発に当たり、アトリスの安光氏に協力を要請。まずは基幹システムを開発するための準備段階として、グループすべての業務プロセスをユースケース図化した（地球シミュレーション）。その結果、まずはシステム開発なしの「業務改革プロジェクト」を実施することになり、2億円／年のコスト削減を達成した。
次に取り組んだのが「グループIT戦略」の策定である。IT戦略がなくては、基幹システムなど作りようがないからである。これは塚本前社長（現最高相談役）と私が膝をつき合わせて作成した。トップダウンの視点である。
同時に、ボトムアップの意見を取りまとめるための「グループ基幹システム検討委員会」を設置した。委員長は私が務め、会計、生産管理、販売管理の業務を担うメンバーとともに、問題点と改善策を徹底的に検討し、IT戦略との整合を考えながら「グループ基幹システム開発に関する答申」を作成した。答申には、全体最適の優先、マスターの一元管理、データ基盤の構築、といった方針も盛り込まれた。この答申が承認されたところで、正式にプロジェクトがスタートした。プロジェクト・マネージャーには、山崎敦史前CIOが任命された。
「P-1」開発プロジェクトが始まってすぐに行ったのが、業務モデルの概念化「クロスメディア・ビジネスパターン」の策定である。クロスメディア・ビジネスパターンとは、経営戦略「クロスメディア」と業務モデルを概念化したもの。ここには概念をシステムにつなげるためのアイディアも盛り込んだ。
プロジェクトが始まってから「クロスメディア・ビジネスパターン」を策定した理由はふたつある。
一つはプロジェクトが始まった後に、新経営戦略「クロスメディア」が打ち出されたからである。新経営戦略の考え方を基幹システムに取り込む必要があった。
もう一つの理由は、開発規模が大きかったため、4つのドメイン（会計、生産管理、販売管理、情報）に分割して、ドメインごとに開発を進めることになったからだ。システム全体を貫く思想、つまり「IT戦略」「新経営戦略」「業務改革」を、だれにでも分かるような形ではっきりと記述し、それらが実際にシステムに実装されるように、釘を刺しておく必要があった。
クロスメディア・ビジネスパターンには、クロスメディア・ビジネスパターン概念図、広告概念図、顧客概念図、用語定義、その他様々な考え方を記述した。
クロスメディア・ビジネスパターン概念図には、当社のビジネスの基本である、顧客が求める知識・知恵を制作して届ける方法を示した。知識・知恵の全体である「ナレッジ」は、「コンテント」によって構成される。ひとつのコンテントからはさまざまな「プロダクト」が制作され、そのプロダクトが複数の「バリュー」（収益モデル）を生む、というようなことである。例えば雑誌は「製造販売」と「広告」のふたつの「バリュー」（収益モデル）から成り立っている。
広告概念図には、雑誌におけるスペース、WEB広告におけるスペースと掲載期間、さらにインプレッションといった概念を図示した。
顧客概念図には、顧客、得意先、ユーザー、会員、潜在顧客などの関係をまとめた。ただし、顧客概念図についてはグループ内でコンセンサスが得られているというわけではない。
その他、共通原価の扱いや、開示に必要な項目なども記述した。
山田ナビゲータ： モデル化の図は、システム開発の現場でも必要になるのか。
三嶽氏： 概念図を見ながらでないと仕様は作れない。システム開発した後もこれらの図は生きている。
山田ナビゲータ： ビジネスの現場のユーザーは経営概念モデルをどの程度知っておく必要があるのか。
安光氏： プロダクトコード知らないと、現場の人は旅費精算もできない。
田口ナビゲータ： 例えば私のように編集部の社員は自分が使った旅費精算をするとき、どのプロダクトの旅費かを入力しないといけない。単なる旅費というわけにはいかない。前職の会社では単なる旅費として精算できた。それと比べると面倒くさいと思うが、仕方がない。
三嶽氏： 編集部は製造部門なので、旅費をプロダクトに計上する場合もある。私のような管理部門の人間の場合は、旅費とプロダクトは結びつかない。
田口ナビゲータ： プロダクトと結び付いていることで、原価計算の精度が上がるのはよい。前職の会社の場合は、雑誌部門の場合、あらゆる経費は雑誌が吸収するようになっている。例えばムックを作った場合、それにかかった人件費や打ち合わせ費なども、雑誌の経費として処理されてしまう。その結果、ムックはすごく儲かっているように見えてしまう。しかしインプレスグループの場合は、何がどれだけ儲かったかちゃんと分かる。
鶴保氏： 人件費はどう処理されているのか。
三嶽氏： 人件費は部門に計上しており、プロダクトには直接結び付けていない。
鶴保氏： 部門とプロダクト、バリューの関係について、もう少し詳しく教えて欲しい。
三嶽氏： 売上に関連してプロダクトは複数のバリューを持ち、バリューは売上の集計に用いられる。プロダクトは属性として売上計上部門を持つ。原価に関連して、プロダクトは複数の制作をもち、制作は原価の集計に用いられる。制作は属性として原価計上部門を持つ。
鶴保氏： 概念モデルはどのくらいの時間で作ったのか。
三嶽氏： クロスメディア・ビジネスパターンは約 3 カ月をかけて作成した。この概念モデルをアトリスがシステムに反映してくれた。部分的には、概念モデルの実装が業務プロセスに大きく影響し、本番稼動に際して現場への落とし込みに苦労することもあった。
概念モデルを作成したことで、完成したシステムに「経営戦略」「IT戦略」「業務改革」などの思想を反映することができた。現在でも利用者・技術者がシステムの思想を理解している。運用ベースでも思想が生きているので、システムのアーキテクチャが崩れたり、データが汚れにくい、というメリットがある。例えば電子書籍関連で新しいビジネスモデルが生まれてきても、それほど右往左往しなくてすむと思う。
今後の課題として、思想の維持・発展、データ基盤の拡張、システムのさらなる活用、新ビジネスモデルの収益化サポート、などを考えている。
蛇足ではあるが、「P-1」開発の経験からプロジェクト成功の秘訣を述べてみたい。
インプレスグループは分社構造をとっており、各社の自由を重んじる文化が特徴である。そのためグループ各社を横断するプロジェクトにおいては、関係者の意見を統一することが非常に難しい。このような困難な中でプロジェクトを成功に導くには、それなりの方法論が必要である。
【段階1】 検討委員会（目標の明確化・計画立案）
【段階2】 プロジェクト（実行と管理）
【段階3】 運用（まとめ）
三嶽氏の講演は以上で終了した。続いて安光氏が以下を補足した。その後、質疑応答が始まった。
安光氏： インプレスが基幹システム開発に取り組んだのは約 7 年も前。その当時から将来の出版社がどうなるんだということを想定して、概念モデルを作ろうとしたのが今回の成功の要因である。今あるものをどうするかというのではなく、どんな概念でシステムをつくるか思想を明確に持っていないと、作ったシステムはゴミになる。
坪田氏： 出版社の経営で一番難しいのは、返品、返本があった場合の計算だと思う。その辺の処理はどうなっているのか。
三嶽氏： 出荷から返品を差し引きしたものを売上としている。計算自体に問題はなかったが、出版ビジネスで大事なのは、いかに無駄な出荷をせずに返品を減らすかである。そのための工夫はいろいろしている。出荷数、返品数、POS情報は、「P-1」のデータ基盤にあるので、簡単に利用できる。配本と実売の差異も分かる。
山田ナビゲータ： 検討委員会のメンバーは何人ぐらいで行ったのか。
三嶽氏： 検討委員会は13人。このメンバーで提案書をまとめた。
鶴保氏： 全社的に共通で管理するデータ項目も決めたのか。
三嶽氏： 例えば、支払先マスターを一本化するか各社別にするかについては悩んだが、結局各社別にすることになった。プロダクト・マスターや制作マスターは一本化した。連結に必要な項目ももちろん一本化している。
かせ沢氏： 人事マスターなども統一しているのか。
三嶽氏： 「P-1」の利用者マスターは一本化している。給与計算や勤怠は別システムで管理しており、連携していない。部門コードのみ共通化している。
鶴保氏： ビジネスパターンを作って、データを整理してという手順で、実装は容易にできたのか。
安光氏： 実装は容易ではなかった。項目数は4,000。その言葉の定義をするだけでも大変だった。
田口ナビゲータ： 項目とは具体的にどんなものか。
安光氏： データベースのカラムと考えてもらえれば分かりやすい。住所録であれば、住所や電話番号、名前など。データの中身ではなくそれを表すメタ的なもの。
田口ナビゲータ： モデル化の話について、話を聞きたい。コンテンツを包括するものがナレッジで、コンテンツをプロダクトという形で認識可能なものするという形で抽象化しようというのは、三嶽氏が考えたのか。
三嶽氏： 私が考えた。
神谷氏： 具体的に日々の運営で、新しいコンテントの登録は担当者が機械的にできるのか。
三嶽氏： それを行うのが生産ドメイン。コンテントやプロダクトの登録はこれまで各社のやり方がバラバラだったので、慣れるまで難しかったようだが、現在は問題なく業務が回っている。
かせ沢氏： コンテンツの原価の単位はどうなっているのか。
三嶽氏： いたってシンプルな構造だ。プロダクト・マスターの中にコンテントという属性があり、そこにコンテントを入力しておけば集計できる。
鶴保氏： 安光氏はさきほど業務項目数が 4,000 個でも大変だったというが、仮に項目数が 1 万個あると、実装できないということか。
安光氏： 項目数と作業量はリニアな関係になるので難しくなる。
鶴保氏： 項目数が分かるのはいつごろなのか。
三嶽氏： ドメインごとに仕様を詰めると項目数が出てくる。
鶴保氏： それが出ないと工数も経費も出ない。線表も引っ張れない。線表や経費はいつ決まるのか。この概念モデルを書いているときは分からないのでは。
三嶽氏： 概念モデルができた頃には、各ドメインとも分析が進み、項目もかなり分かっていた。
山田ナビゲータ： その役目をするのが PEXA（ペクサ）Suite だと思うのだが、三嶽氏は PEXA をどう評価しているのか。
三嶽氏： PEXA は J2EE のフレームワークと捉えている。PEXA があるおかげで、たとえ追加開発したとしても、システムを把握し続けられる。
安光氏： 今、三嶽氏が話したのはオブジェクトリレーションマッピング技術のこと。これにより物理的なデータテーブルと業務項目を切り離している。データテーブルを直で扱うとデータが汚れるため、それを防ごうと十数年前よりデータモデルとテーブルを切り離すものとして OR マッパーが登場したが、今回のようにデータ項目が 4,000 個にも達すると、64 ビットのコンピュータでないと使えなかった。PEXA は最小の機能業務をSVOステートメントで記述することができる。また、データベース本体と切り離しておくことで、エンドユーザーでも運用ができるようにした。
山田ナビゲータ： データ項目が1万個でも PEXA を使うと実装できるようになるのだろうか。
安光氏： データ項目が密結合していたら難しいが、疎結合で項目数と関連するリレーションが少なければ、可能だと思われる。
鶴保氏： 密結合していているかどうかなどは、詳細設計まで進まないと分からないのか。4,000項目か1,000項目かという業務項目の見積もり法はないのだろうか。
安光氏： シーケンス図を出せば大まかには見積もることはできると思う。
田口ナビゲータ： インプレスの基幹システム「P-1」がうまくいった要因の一つは、概念モデルがあったからというのは正しい？
安光氏： 概念モデルがないと何を求めてシステムを作っているか分からない。
田口ナビゲータ： 概念モデルから業務項目やビジネスの流れが分かるわけではない。でもこれがあることで、エンジニアは何ができるようになるのか。
鶴保氏： シナリオドメイン表を書き、シーケンス図を書くという手順が分かる。
安光氏： 概念モデルはシステムの原点ともいうべきもの。いつでもここに戻ることができる。
田口ナビゲータ： 概念モデルを見れば、エンジニアは「出版社のビジネスはこういうことなんだ」ということが分かるということか。
大西氏： 当初の管理単位が業務改革するうちに変化して、コンテンツとして捉えようということになり、概念モデルが形成されていったということではないのか。
三嶽氏： そうではない。最初に莫大な工数をかけて地球シミュレーション（ユースケース図）を作成した。これは間接的には概念モデルに結びついたが、直接的には結びついていない。ただ、地球シミュレーションを作成したことで、ビジネス全体が見えたという安心感は得られた。
大西氏： ではコンテントという見方にいつ変わったのか。
三嶽氏： 変わったというのではなく、クロスメディア・ビジネスパターンができたことで、コンテントで見ていこうということになった。
山田ナビゲータ： コンテントという見方ができたことで、フロント側はさまざまなビジネスを展開できるようになったのではないか。
三嶽氏： そうではなく、フロント側が新しいビジネスモデルに取り組んで も、きちんと集計できるように対応したというのが正しい。
かせ沢氏： データ構造が汚くならないのかが気になるところ。誰かが監視したり、チェックしたりしているのか。工夫のポイントを教えてほしい。
三嶽氏： データオーナーは会社別になっているものも多い。会社別になっている部分はその会社に任せている。ただ、イントラに用語の定義や「P-1」利用マニュアルを掲載してメンテナンスを継続することで、誤った使い方がされないように気を配っている。連結のための共通マスターも、連結の数字が正しく集計されるようにきっちりと管理している。
山田ナビゲータ： ほかの業界でもインプレスの概念モデルの考え方が生かせそうだが。
大西氏： 製造業だと工場内のモノの動きをきちんと管理することが重要になる。例えばトラッキングが出来るようにコードを追いかけていくとできるのではないか。
安光氏： 製造業では製品と製造工程の概念モデルを作ることが必要だろう。
田口ナビゲータ： 通常のシステムはビジネスモデルをas-is分析して、余分なものはカットし、業務効率が良くなるように改善して構築する。そのときに、インプレスのようにもう一歩本質に入って自社のビジネスを見つめなおすことが必要になる。その上で洗い出せていない業務プロセスを見直してみると、もう少しロングライフに対応できるシステムができるということが言えそうだ。
鶴保氏： 本来、SE と称する人は 5W1H （誰が何をどういうタイミングでどうする）ということを、きちんと書くのが仕事である。つまりあらゆるシステムは概念モデルを作る努力をしているはずなのだが……。50 万人ものソフトウェアエンジニアのうち、SEと呼ばれる人は約 10 万人いると言われている。しかし優秀な SE は多くない。優秀な SE であれば分析をちゃんと分析をしているはずだ。
安光氏： 最近の SE はシステムを作らず、パッケージを導入しているので、概念モデルなどは書くという経験がほとんどない。だから書けない人が増えている。
田口ナビゲータ： 約50万人のうちその多くのソフトエンジニアは、概念モデルを作ることは考えたことがないのではないだろうか。
白熱した議論が続く中、最後に田口ナビゲータは「21世紀企業情報システム研究会ではここで議論したことをまとめて発表していく。今回の講演で業務モデルを概念化することは21世紀の企業情報システムにとって重要な要素の一つに入ってくると思う。次回は SSM など、聞いたことはあるけどどういうものか知らない言葉について、鶴保氏に語ってもらいたいと思う。次回もぜひ、参加してほしい」と言葉を結び、研究会は終了した。
