“経営者の視点”で考えるアーキテクチャ：顧客指向開発のすすめ（4）
グッド・カスタマー・エクスペリエンスを実現する情報システムとするためには、経営者の視点で演繹的に考えることや、ITアーキテクトとして企業のバリューチェーン、ビジネスプロセスを俯瞰（ふかん）し、ヒトや組織が遂行する部分と、ITにより支援する部分をバランスさせる必要がある。
グッド・カスタマー・エクスペリエンスを生み出す組織
顧客に「次も買いたい」「次も使いたい」と明確に意思を持って選択してもらうためには、「グッド・カスタマー・エクスペリエンス＝良好な商品／サービスの経験」を提供しなければならない。
グッド・カスタマー・エクスペリエンスを生み出す企業組織とは、どのようなものであろうか。連載第3回「ナレッジマネジメントのIT化と家族経営の八百屋」では、組織内の構成員、部門・部署間のナレッジの共有について述べた。今回は、企業組織のバリューチェーン、顧客に商品やサービスが提供するまでのサプライチェーンとそのIT化の考え方について述べる。
企業組織のバリューチェーン
図1に示すポーターのバリューチェーン・モデルでは、企業の活動を「購買物流」「製造オペレーション」「出荷物流」「マーケティングと販売」「サービス」の5つの『主活動』に分けている。また、これら主活動をサポートする「調達活動」「技術開発」「人的資源管理」「全般管理（財務、法務、情報サービスなど）」を4つの『支援活動』として区分している。
バリューチェーン・モデルのとおり、企業組織の中には、バリュー＝価値を生み出すための価値活動（加工）を持つ複数の部門／部署が存在する。そして、1つの価値活動のアウトプットが次の価値活動のインプットとなる。この相互依存の関係がバリューチェーンであり、資源（ヒト・モノ・カネ）を必要とし、コストが発生する。
そもそも企業組織内のバリューチェーンはどのように決まったのか？
企業組織は、ある日突然昨日までは全く関係がなかった人々が集まり、なぜか役割がきちんと割り振られていて、連鎖的活動によって顧客に向けた最終的な「価値」を生み出す価値活動を行うというものではない。元は1人?数人程度の小さな組織から始まったものであったり、ある大きな組織から切り出された（例えば分社）ものであったり、2つ以上の組織を統合（例えば企業合併）したものであったりする。このような企業組織のライフサイクルに合わせて、価値活動の担当範囲の大小も変遷していくことになる。
まず、主活動と支援活動という大きな区分を考えてみよう。図1のように主活動と支援活動はマトリクス状になっていて、いずれも不可欠なものである。
主活動は、企業が価値を生み出すための主な活動に分類されるものであり、「購買物流」「製造オペレーション」「出荷物流」「マーケティングと販売」「サービス」がそれに当たる。一方支援活動には、「調達活動」「技術開発」「人的資源管理」「全般管理」があり、主活動をサポートしていく。
その企業が行う事業において、主活動の部分は事業ごとに特性があり企業固有のコンピタンシーや競争優位を持つ。一方、支援活動はどの企業にも共通的に必要とされる。図1のバリューチェーンの図では、一企業内にすべての機能を持つように表しているが、主活動あるいは支援活動のある部分だけを行う企業もあり、サプライチェーン全体で1つのバリューチェーンを成す場合もある。
サプライチェーン全体で考えた場合、企業組織内のバリューチェーンのどの部分をシェアドサービス化するか、どの部分をアウトソーシングするかなどについては、ABC/ABMの手法を用いたり、BPO企業の提案価格と内製価格を比較するなどの検討が必要である。企業内外の環境変化に合わせて常にWatchしておくことが重要である。
部署間の担当範囲
では、部署間の担当範囲はどのように決まっていくのであろうか？
顧客視点で考えてみると、対外的に直接顧客対応を行うフロントオフィス部門がある。代理店を管轄する営業部署、顧客と直接取引する営業部署、コールセンタ（電話）、Web／電子メールのやりとりをハンドリングするコンタクトセンタなどがフロントオフィスに当たる。
一方フロントオフィスを支援し、対外的に顧客対応を行うのではなく後方で総務・人事、経理・会計などを行うバックオフィス部門がある。
部門があるとは書いたが、フロントオフィスの部署内にバックオフィス機能の一部を持つ場合も多い。実際に組織の規模や作り方、その部署の存在する場所によっては、支援可能な場所にバックオフィス機能が存在していなければならないためである。近年ではITによる支援によってバックオフィス機能が集約されたり、ITそのものがバックオフィス機能を担うケースも出てきている。
部署間の担当範囲とは、経営判断そのものといってよい。どのような組織体を作り、その中でどのような部門／部署を作り、担当範囲を割り振っていくのか、トップダウンで落とし込まれていくべきものである。バリューチェーン・モデルで示す主活動「購買物流」「製造オペレーション」「出荷物流」「マーケティングと販売」「サービス」をどのように企業組織内にインプリメント（implement：組み込み）し、サプライヤから仕入れた材料・部品・機材などに価値を付加し、顧客に提供するのかがビジネスプロセスとして考慮されているべきものである。また、バリューチェーン・モデルで示す支援活動「調達活動」「技術開発」「人的資源管理」「全般管理」が実際に主活動を支援するようにビジネスプロセスとして考慮されていることになる。
ビジネスプロセスとITアーキテクチャ
ビジネスプロセスとは、顧客に対し製品、サービス、サポート、情報といった価値を提供する一連の流れである。個人や1つの部署で完結せず、複数の部署がそれぞれの役割を果たしながら連鎖し、顧客に対して価値活動を行っていく。
グッド・カスタマー・エクスペリエンスをもたらすビジネスプロセスとは、どのように作り出すべきものであろうか？
企業内外のビジネスプロセス、バリューチェーン、サプライチェーンを動かし、成長させていくためには、すでにITのアシストなくして実行不可能である。
例えばサービスの質と効率を向上させるためには、サービスを各個人に依存するものではなく、製造と同様に効率よく生産するものである。製造方法を向上させる場合、個人の能力や現状の作業を高める方法だけに目を向けるのではなく、全く新しい方法を探すか、さらに作業そのものを変える方法を見つけようとする。一層の重労働や自己犠牲などをさらに要求しようとは考えない。サービスも同様に個人の能力や現状の作業を高める方法だけに目を向けず、新たな方法や仕組みなどを考えることで質と効率の向上を図るべきである。近年ではITの進化に伴い、ITによるアシストによって質と効率の向上を図ることが多い。
しかし、ITのアシストによって質と効率の向上が図れるとはいえ、単体の部門／部署だ
けの質と効率の向上では、グッド・カスタマー・エクスペリエンスを生み出し続けることはできない。ここで必要な視点は、組織＝enterpriseを俯瞰（ふかん）し、組織という複雑な構造物を各要素の範囲や関係を分類・整理するというものである。このフレームワークがザックマン・フレームワークである。
ザックマン・フレームワークは、エンタープライズ・アーキテクチャ（EA）を考えるために用いられるものであり、EAを設計・構築・評価するためのガイドラインとなる。表にザックマン・フレームワークを示す。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ザックマン・フレームワークは、企業階層・関与者の観点を縦軸、5W1Hの観点を横軸に取った6行×6列のマトリクスで表現される。各項目が抽象化されているので、適用範囲が広い。 業種・業界を問わずさまざまな組織構造を整理・分析するのに利用可能である。また対象とする組織やシステムの規模も問わない。逆にマス目を埋めていく作業の具体的な手順は用意されていないため、 あくまでもシステムや組織の全体像を整理する際の視点として用いるべきである。
このように整理・分析を進めると、どこがボトルネックになっていて、どこが過剰になっているのかが見えてくるはずである。
ここで、ビジネスプロセス・リエンジニアリング（BPR）に進むのか、これまでの戦略・戦術を踏襲した連続性のある改革に進むのかは、課題の大きさや時間軸、投入できるリソース（ヒト・モノ・カネ）による。また、組織に組み込まれているビジネスプロセスそのものが、経営的意思決定の集積である。これに変更を加えるということは、過去から現在に至るまでの経営的意思決定の集積を否定することも含む。このため、課題の大きさや時間軸、投入できるリソースではなく、別の政治的な判断により決定されることもある。
いずれにせよ、組織、ビジネスプロセス、経営、ITは複層的な関係性を持っている。実際のビジネスプロセスの変革・改革が主、ITシステムの再構築が従で進めるか、あるいはBPRとITシステムの再構築を一体で進めるべきである。
機能要件と非機能要件
少し話題を変え、組織をグッド・カスタマー・エクスペリエンスを生み出せるように変えていくためのシステム要件定義について触れたい。
部門／部署に割り振られた役割については、部門／部署の視点から見ると所与のものであることが多い。これをIT化（あるいはITによるアシストの実現）しようと考えたとき、各部門／部署ではそれぞれの役割に合わせた要件を持っているはずである。
一方、組織＝enterpriseを俯瞰（ふかん）してみると、その要件は不足であったり、部分的に過剰であったり、企業経営と方向性が合っていなかったりする。そのような問題が起きる理由とプロセスを図2に示す。
経営者の視点は演繹（えんえき）的であり、実際にシステムに投資をするのであれば、投資効果が見込めない小手先の改善には投資をしたくないものである。一方、部門／部署の視点は帰納的であり、従来の考え方や現状の実務に照らし合わせ、「できるのはこれが精いっぱい」という判断をすることが多い。しかし、グッド・カスタマー・エクスペリエンスを生み出す組織に変えていくためのシステム構築では、従来から続く業務改善的な思考や方法ではなく、経営者の発想と同じ形式で、システム要件を決めていく必要がある。
次に、非機能要件を考える。非機能要件とは、性能や信頼性・拡張性・セキュリティ・移行や他システムとの連携など、機能要件以外のもの全般である。これはエンドユーザーからヒアリングするものではなく、ITアーキテクチャとして組み込まれるべきものである。
筆者のこれまでのアーキテクトとしての経験では、エンドユーザーから非機能要件が出てくる場合は、現在使用しているシステムに対するコンプレインがあるケースや、過去に特徴的な事故が起きたケースなどである。非機能要件は、痛い目に遭った人にだけ分かるということかもしれない。当然筆者もアーキテクトになる以前に、システムエンジニアとして痛い経験を山盛りで持っている。非機能要件については機能要件を詰め始める前からリストアップしておくように心掛けている。
昨今では、会社法、金融商品取引法に含まれる内部統制の規定への対応など、制約を含めた機能要件・非機能要件などが好例である。機能要件としてはSoD（Segregation of Duties：職務分掌）に対応するIDMや、そのエビデンスを明示的に確保するログ管理機能などが機能要件と考えられる。一方、非機能要件としては、コンプライアンス・リスクやレピュテーション・リスクに対応するための、セキュリティ強化や必要に応じたシステムマネジメントの強化などが考えられる。
グッド・カスタマー・エクスペリエンスを実現するための組織とプロセス、情報システムの関係について述べた。さまざまな要件や制約を明らかにしていけば、おのずと要件が求めるあるべき姿（ToBe）が見えるはずである。いわゆる上流工程、システムの要件や制約（特にビジネス上の）を明らかにすることが難しいのは、利用者自身がその要件や制約について言語化できていないためであることが多い。また、帰納的な視点で考えてしまい、「これくらいだったらなんとかできそう」程度で終わってしまうためである。また、機能要件をまとめるだけで満足してしまい、非機能要件について欠落することもある。
これらを防ぎ、グッド・カスタマー・エクスペリエンスを実現する情報システムとするためには、経営者の視点で演繹的に考えることや、図3に示すようにITアーキテクトとして企業のバリューチェーン、ビジネスプロセスを俯瞰（ふかん）し、ヒトや組織が遂行する部分と、ITにより支援する部分をバランスさせる必要がある。
次回は、「いつでも・どこでも」信頼されるためのチャネル間連携について述べる。
筆者プロフィール
營田 茂生（つくた しげお）
日立ソフトウェアエンジニアリング株式会社
セキュリティサービス本部 シニアコンサルタント
大学時代は構造化プログラミングを学ぶ。日立ソフト入社後，主として保険、証券会社システムのシステムエンジニアリングに従事後，現在は仮想化ビジネスを推進中。
Copyright © ITmedia, Inc. All Rights Reserved.