原因が判明した

福岡県　＜－＞　福岡市

大阪府　＜－＞　大阪市


福岡市や大阪市は自治体である


元来なら、大阪府や福岡県の仕事を市がやっている


市の役割分担、責任分担が誤っている、市の権限が拡大しすぎた

結局、この問題に行きつく

ガルブレイスのアメリカンドリームは、放送による消費の誘因

２１世紀のアメリカンドリームは、放送と通信による広告の公正化


３．オンタイムとオンデマンドの在り方

放送はオンタイムである、ブロードキャスト系である、Whole-sale Politicsである

通信はオンデマンドである、パブリッシャー系である、Retailed-sale Politicsである




グローバル（国際会議など）　－　国　－　州　－　自治体　－　ローカル（市民、住民）




メジャー（放送）　＜－＞　ホットスポット（放送と通信）　＜－＞　インディーズ（通信）




トップダウン　＜－＞　ミドルアウト　＜－＞　ボトムアップ

州政府制

ミドルアウト戦略に、コミュニケーション能力は欠かせない

椅子から飛び出して、町に出よう　－　都知事

ミドルアウトとは？

http://www.itmedia.co.jp/enterprise/articles/0609/13/news002_2.html

ITRではSOA実現のステップを図1のように4つのステップで定義している。それぞれのステップごとに、課題および留意点とその解決に向けた基本的な考え方を紹介する。

図1●SOA実現のためのステップ（出典：ITR）

ステップ1：現状調査

このステップでは現状のシステムやアプリケーションについての棚卸しを行う。多くの企業においてシステムは継続的に変化しているため、稼働当初に書かれたドキュメントとシステムの実態が異なっている可能性がある。そのため、システム全体の俯瞰（ふかん）図を作成することは非常に重要だ。俯瞰図にシステム名、所有者、ビジネスプロセス、システム間インタフェース、使用されている技術、現在の利用状況と問題点などの情報を盛り込む必要がある。

さらに、サービス化すべきプロセスを選定するのだが、この判断を行うには幾つかのアプローチが考えられる（図2）。

図2●サービス抽出のアプローチ（出典：ITR）

ボトムアップ型の意思決定は、現場の声を反映するという点では適切であるが、「局所最適」という弊害が生じるリスクがある。システムが縦割り化し、相互運用に困難をきたす状況である。日本企業のほとんどが多かれ少なかれこのような問題を抱えている。ゆえに、アーキテクチャー設計プロジェクトがトップダウン型で推進されるのは当然の流れであろう。

もともと、アーキテクチャーという言葉自体に共通の標準をトップダウンで決定していくというニュアンスがあるのは否めない。しかし、トップダウン志向が強すぎると、別の問題が発生する可能性が出てくる。

まず、大規模企業のすべての情報システムに対して共通の規約や仕様を決定していくことは、その作業負荷を考えると非現実的といわざるを得ないケースが多い。また、各現場の状況を無視した全社的標準を強制することは、かえって変化への迅速な対応を妨げるおそれがある。さらに、現場の特殊事情を無視し、重要な例外処理が見逃されたり、アーキテクチャーから排除されたりすることで、現場の効率や顧客サービスの質をかえって悪化させることもある。

どちらのアプローチにも一長一短があるとすると、アーキテクチャー設計においては、トップダウンとボトムアップを組み合わせたアプローチが必要となる。このアプローチは「ミドルアウト」と呼ぶことができる。各アプリケーション内ではトップダウン的な厳密なアーキテクチャーを適用し、複数アプリケーション間ではボトムアップ的な柔軟なアーキテクチャーを適用するという考え方である。

ミドルアウト型アプローチの留意点

ミドルアウト型のアプローチでサービスを抽出する際には、以下の点に注意することを推奨する。

• 業務上の重要性が高い
• 利用頻度が高い
• 使用ユーザーが多い
• 変化の頻度が高い
• 複数のシステムで使用されている

また、以下のような、サービス化に向いていないシステムやアプリケーションを無理にサービス化しないことも重要となる。

• ほかのシステムとの関係がなく単一のシステム内のみで利用されているプロセス：これは、将来的にも単一システムのみで利用されている場合はサービス化するメリットはない。
• 非常に高いパフォーマンスを要求されるプロセス：SOAはサービス間を疎結合とするために、サービス間での転送は非同期通信を採用する。そのためにサービス間でのデータの受け渡しにオーバーヘッドが発生する。
• 一括大量のバッチ処理：サービス化するとは、固有のプロトコルを標準のプロトコルに変換して接続することであるので、単一のフォーマットやコードの変換を一度に大量に行うような処理には向かない。

ステップ2：サービス要件の定義と管理体制の確立

サービスは複数のプロセスからの利用を前提とするので、変更の手続きを明確にしておかないと障害が発生してしまう可能性がある。また、サービスは再利用を前提とするため、カタログ化とカタログの更新に関する責任と手続きを明確化しておくことも重要となる。SOAの実践において、技術の実装は1つのステップにすぎず、注力すべきはライフサイクルにわたってサービスを管理維持していくためのルールと体制の構築である。