情報システム学会　メールマガジン 2013.4.25　No.08-01 [6]
PDFは http://www.issj.net/mm/mm08/01/mm0801-kj-hr.pdf

連載　企業および社会における情報システムの意味を考える
第7回　ビジネスの変化に迅速に対応できる情報システムにするための課題 その6

大島　正善（MBC:Method　Based　Consulting）

　昨年の１０月から連載をはじめ、３月まで「ビジネスの変化に迅速に対応できない情報システム」ということについてその問題の本質と解決策を探ってきました。今回は、これまでの連載で述べてきたことをサマリーしてみたいと思います。連載で述べてきたポイントは以下の点です。

　　　　(1) 企業や行政組織等において、業種を問わず顧客、非顧客、競争相手、外国政府、国民、市場などの動向を“情報”として入手し、それに基づいて戦略や方針を決定することが行われている。競争優位ないしサービスの質は収集する情報の範囲・量とその取り扱い方に大きく依存している。
　　　　(2) 情報システムの開発において、手段（how）としての方法論は数多く提唱されているが、対象であるビジネスそのものがどういう構造を持っているのかということは考慮されない。情報システムが企業の活動を真に支え、変化に迅速に対応できるようになるためには、組織が自らの活動にかかわる要素を認識しその構造がどのようなものなのかを理解することが求められる（ビジネス・モデルを可視化することが必要）。しかし、ビジネス・モデルの可視化に関して言えば、現在の企業や行政組織はせいぜい紙とＯｆｆｉｃｅツールでそれらを行っているにすぎず、ビジネス・モデル情報は管理されずに、意思決定は直感を頼りになされている（経営者の洞察力に依存している）。
　　　　(3) ビジネス活動の要素には顧客に対してどのような製品やサービスを提供すのかという視点にたって目標、戦略、組織、拠点、チャネル（販売および調達）、ビジネス・プロセス、ビジネス・ルールなどの要素が複雑に絡み合って存在している。それぞれの要素は多対多の多次元構造であり、現在、経営者はひとつの要素の変化がほかの要素に与える影響を直感で判断しているのが実態である。
　　　　(4) ビジネス・プロセスの最適化は、PDCAの観点からプロセスの単位を決定し、プロセス間を流れる情報がPDCAサイクルで完結するようにしていくことが肝要である。（Doの結果が確実にControlプロセスに戻りActionを通じて次のサイクルが回るようにする）
　　　　(5) 業務フロー（ワークフロー）はタスク・レベルの仕事の流れであり、上位レベルであるプロセス・レベルやアクティビティ・レベルでPDCAが確実に回っていることを確認せずに可視化しても、業務課題の真の解決やビジネス・プロセス全体の最適化に結びつくとは限らない。
　　　　(6) ビジネス・モデルは、ビジネスを行う上でのリソースであり、それは、たとえてみればモノ作りにおける材料・部品と同じである。ビジネス・モデルをメタ・モデルで管理していない事務処理の現在の状況は、モノ作りをBOM（Bill Of Materials or Bill Of Manufacturing）を持たずに実施しているのと同じであり、事務処理の生産性があがらない大きな原因である。
　　　　(7) 情報システムとの関係でいえば、可視化されていないビジネス・モデルをもとに人手をかけて情報システムへの影響分析をせざるをえない状況であり、迅速な対応ができなくても仕方がない。
　　　　(8) 情報システムを構成する要素もそれ自身が多次元の構造を持っており、しかも、ビジネス・モデルとの対応付けがほとんどなされていないのが実態である。
　　　　(9) ソフトウェアの構造が多次元構造であることを認識すると、サブシステム、サービス、コンポーネントをどう括るのか、開発体制をどうすべきなのか、あるいは、開発をどう進めるべきなのかといったことなどについて、新たな視点が浮かび上がってくる。
　　　　(10) 経営の変化に迅速に対応できる情報システムとするためには、ビジネス・モデルを可視化し、それと情報システムにかかわる要素との関係を明らかにしたメタ・モデルの構築が求められる。それは、競争優位のための必要条件である。

　このようなメタ・モデルの構築に関連して、ビジネス・プロセスが戦略を実現する手段であること、さらに、現在多少混乱がみられる“ビジネス・ルール”の意味付け、そして、業務機能とシステム機能との関係などについて記述してきました。

　かつてビジネス活動が地域社会に閉じられ、比較的安定していた時代には、情報システムは一度構築すれば、ある程度の期間は使用に耐えるものという前提で開発されてきました。しかし今はそうではなく、経営の変化に迅速に追従できることが求められています。変化に対応できるようにするためには、経営環境の変化がどのようにビジネス活動に及ぶのかが可視化されていることが必要でしょう。そのためには、ビジネス・モデルそのものを管理することが求められると思います。

　経営の変化最近の情報テクノロジー（IT）にかかわる関心は、クラウド、ＳＮＳ、ユーザー・エクスペリエンス、ビッグデータ、M2M（Machine to Machine）、O2O(Online to Offline)、セキュリティなどに主眼が置かれています。基幹業務はシステム化が終了し、顧客接点に近いところでの情報あるいはITの利活用に重点投資が行われようとしています。そういった投資はもちろん重要です。イノベーションの機会が多く存在しているからです。

　しかしながら、ビジネス視点で見たとき、基幹業務の仕組みがこれ以上改善の余地がないとはいえないというのが本当のところです。情報流の視点からみると、日本企業の事務処理には。まだまだ改善の余地がたくさんあります。また基幹業務システムは稼働後10年から20年を経て、「怖くて手をつけられない状態」になっている企業も多いようです。ビジネス・ルールは文書化されておらず、プログラムのみに実装されていて解読不能の状況という組織は多くあるでしょう。そういった状況でグローバルな市場で競争に打ち勝とうというわけですが、勝算はあるのでしょうか?

　自社、自組織のビジネス・モデルを可視化し、Ｏｆｆｉｃｅツールなどで文書化するのではなく、それをリポジトリーで保管・管理しその情報をもとに、情報システムを作り出す（望ましい姿は自動生成すること）仕組みを構築していくことを考えるべきではないでしょうか。

　すでに、BPMS (Business Process Management System), BRMS (Business Rule Management System) ,アプリケーション生成ツールは多く存在しています。ビジネス・モデルのすべての要素を管理できるほど完璧ではありませんが、それらを組み合わせることにより、ビジネスの変化を迅速に情報システムに反映させることができるようになるのだと思っています。重要なのはトレーサビリティです。この仕組みは短期間で完成できるものではありません。少なくとも、３年から５年程度はかかるでしょう。そのことを理解して少しずつ手がけ始めることをお勧めします。

　最後に、ビジネス活動と情報システムのアーキテクチャの図を示します。ビジネス活動と情報システムのアーキテクチャは、その要素の抽象度は異なりますが、似た構造をしていることがわかると思います。

図１　ビジネス活動のモデル、図２　情報システムのアーキテクチャ
図１　ビジネス活動のモデル　　　　　図２　情報システムのアーキテクチャ

　この図が示唆することは、情報システムの構造を決めるためにも、ビジネス活動のモデルを明らかにすることが重要であるということです。

　最後に、ビジネス・モデルと情報システムの主要要素間の関係の例を図３と図４に示します。これは、あくまで特定の企業に適用するにはテーラリングが必要ですが参考になれば幸いです。

図３　ビジネス・モデルと情報システム・モデルの追跡可能性

　図３　ビジネス・モデルと情報システム・モデルの追跡可能性

図４　ビジネスと情報システムの主要エンティティの関連図

　図４　ビジネスと情報システムの主要エンティティの関連図

　昨年１０月からの連載で、ビジネス・モデルの構造と情報システムの要素の構造の関係について書いてきました。過去長期にわたって多くの問題があるといわれ続けている、要件定義（要求分析・定義）、上流工程、超上流工程などといわれる工程の作業をどのように考えるのか、何を目指した作業なのかといった点に関して、読者の皆様の何かヒントになるようなことがあったとすれば幸いです。なお、ご質問などありましたら、下記メールアドレスへお問い合わせください。

　お問い合わせ先　：infonail_mbc■yahoo.co.jp

　次回は、ソフトウェア開発と通常の“モノ作り”とは何が違うのか?という点について触れてみたいと思います。そのことを考えることにより、ソフトウェア開発がモノ作りの生産活動とは何が違うのか、それによってどのような困難さが生まれているのか、などといった点について触れてみたいと思います。
　以上