Oracle Open World 2009 2日目に参加してきました。
http://www.oracle.co.jp/openworld/2009/index.html

今回参加したセッションは、下記の通りです。

Oracle Open World 2009 2日目 参加レポート

日時場所

2009/04/23（木） 09:30-20:00 国際フォーラム＠有楽町

12:50～13:40 SOAによってもたらされた価値と、失敗しない導入術

会社を出るのが遅くなった為、途中からの参加でした。

• ビジネスモデルにシステムが追随して行かない

解決策とその効果（出光）

• 混在モデルを意識したアーキテクチャ標準を整備

• 各システム実装の抽象化と、システム間連携管理の一極集中化を実現する共通基盤を構築
• I/F数 30%削減、50%以上の開発コスト削減

解決策とその効果（docomo）

• 各携帯サービスを構成している機能を共通化し、再利用可能なサービス・コンポーネントを整備
• 各携帯サービスを立ち上げる度に、社内システムとの連携が必要となることから、その手続きの標準化と生産性向上を目的に、連携基盤を構築
• 再利用可能な部分を把握出来るように、設計モデルを可視化

• [Q} 混在モデル、パッケージ、スクラッチを、既存のものと新規のものを混在した場合の問題点は？
  • [A] 一度に多くの試験を必要としてしまう。コストがかかる。
  • [A] 自分たちの会社の事業モデルやプロセスがどうあるべきなのか、それに対してシステムはどうなっていればいいのか、を、考えた上で、技術を選択していく、というプロセスが必要。

現在の評価と今後の方向性（出光）

• SOAの定量的な効果測定は難しい
  • 環境前提に見積を行うため
• ITシステムの製品・サービスの多様化が進んでおり、もはや一社のSIベンダーに丸投げして物事が進められる時代ではなくなった。
• ユーザ企業自身がマネジメントしていかなければ、コストの増大、スピードの鈍化に加え、そもそもやりたいことが出来ないという事態にもなりうる。

現在の評価と今後の方向性（docomo）

• 事業環境の変化に対応しうるシステム開発について「はじめの一歩」を踏み出すことができた
• 実現に辺り、事業部サイド、開発、ベンダの役割が明確化でき、見える化によって検討を加速することができた
• 柔軟かつ効率化に実現することを踏まえ、適用範囲を拡大した検討を推進するに至っている
• なんでもかんでもSOAにするべきかといえばそうではなく、システム要件によって変えればよい
• 開発そのものを共通化していくようなアプローチが必要

まとめ

• アーキテクチャの最適化の検討をユーザ側も主体性を持って取り組むことは重要
• SOAというのは、現在の最適なアーキテクチャを考え場合に、最も近い現実解の一つ
• SOAの効果は、ビジネス要件に対してユーザ側がコントロールできる部分が増えることが最も大きい
• コスト削減やスピード向上は、必ず実現できるはず

14:10～15:00 ERP+SOAハイブリッド事例に学ぶ、変化対応力の最大化とスピード構築の両立

• 企業にとってITがどうあるべきか（あるべき姿）
  • 企業の成長を支えるIT基盤が必要
  • 縦軸：経営要求＆IT基盤対応力
  • 横軸：時間
  • 実線：経営方針・戦略
• IT基盤進化サイクル

の順

• モノが売れない時代に何を売るのか
  • サービスを売るしかない
  • 今までの従来方式のビジネスモデルではダメ
• バリューチェーン最適化を支えるITシステム
  • 組織の壁を越えたスムーズな業務遂行を実現するのが、統合されたITシステム
  • 組織の構造とシステムの構造が比例：弊害を生んでいる
  • プロセス統合されたシステム
    • 間に組織の壁がない
    • どうやって実現するか->標準を作るしかない
• 標準化には2パターンある
  1. 全社を横断する標準
  2. その領域に閉じる縦の水準
• 目指すITシステムの形
  • 既存システムを出来るだけ延命させて将来に備えたいという要望から、SOAを再度検討されているお客様が増えている
  • 異種混在型でシステムを構成するのは普通になっている
  • いろいろなシステムの同期をする為に、中央に「全社統合基盤」を用意
    • 以前に比べて性能もよくなってきており、利用するお客様も増えている
• パッケージ＋SOA
  1. 素早く実装する（作らない開発）
  2. 要件の継続的な同期（変化対応力最適化）

どうやって実現するか？

• 全体のアーキテクチャをどうすべきか
  • サービス指向化で目指すToBe像
    • 迅速に全社レベルの業務の可視化、モニタリング、最適化を行うことが可能
      1. 業務プロセス -> 業務の可視化とモニタリング、全社レベルの最適化へ
      2. サービス -> システム固有の違いを吸収する
      3. 業務システム -> 疎結合化
  • 業務要件を素早くシステム（IT）化（やりたいことが早く出来る）
  1. 業務部門とIT部門の認識を併せやすい（手戻り防止、品質向上）
  2. 業務要件とシステム機能を1:1にマッピングできる（システムとしての可読性が向上->影響分析しやすい）
  3. ITの複雑性が減る
• ところで、どうしたら作れるか
  • 一番安く、確実に作れる、ベストな方法を探す
  • [Q] 業務システムの実現方法はどれが適当か？
    1. 既存システムを利用
       • 既存システムがある
       • 要件の変更が不要（または変更軽減）
       • 必要なサービスの切り出しが出来る
       • （本当に使えるかAS-IS調査）
    2. 手組で一から開発
       • パッケージでは機能要件が満たせない
       • パッケージ製品自体が存在しない領域である
    3. パッケージを利用
       • 要件に対する適合率がある程度見込める
  • [Q] サービスのデザインはどのように行うか
    1. 既存サービスを利用
    2. 新規にサービスを作る
       • 全体の整合性を考慮し、適切な粒度で、標準サービスを決定する
    3. サービスのひな形利用
       • 事前定義されたテンプレートを使い、標準サービスとして最終化する
• どう実現するか？何をサービス化？（サービス識別：サービスを決定する行為）
  • SOAを実現する上での課題
    1. サービス指向の目的
       • 変更柔軟性を最大限高め、様々な変更要求に対して、素早く、最小限の労力で対応する。
       • ITの複雑性を意識することなく、業務の視点で組み替えが自由に行える。

• サービス指向の実現に必要なこと
  1. 業務の観点
     • 使いたいサービスを決定する
     • サービスの使い方を決定する
  2. システム（IT）の観点
     • メンテナンスのしやすさを向上させる
     • その他のシステム要件
• SOA適用プロジェクトの傾向
  • 競争力の源泉、ERPで閉じれない箇所にニーズが多い
    • 商品、取引先などがトランザクションとして流れる部分は、SOA化が進んでいる
• ITが複雑化した典型的な原因
  • これまでは増築、改革の繰り返し
• どうサービスを識別するか
  1. As-Isの実装にとらわれすぎない
  2. 業務の目線からToBe要件を整理
     • 本来やりたかった要件ごとに分割
  3. 他社との優位性から、求められる機能を分類する
     1. 共通要件
        • パッケージを利用
     2. 他社との差別化要件（競争の源泉になっている、お客様のコアコンピタンスに貢献しているビジネス要件）
        • 手組で実現
        • パッケージを利用しないのは、コアコンピタンスそのものがいずれ変わる可能性があるから
     3. 部門・地域限定要件
        • 手組で実現
• どう実現するか？どうサービス化？（サービス実装）
• アプリケーション実装方式別の特徴と懸念点
  • 完全パッケージ利用型
    • 自由度が低い
  • 完全カスタム開発型
    • コストが非常に高い

• 新規構築
  1. 画面
  2. モジュール、機能、ロジック、連携機能
• 実現方式非依存に隠蔽する（疎結合化）
  1. サービス
  2. プロセス
• 既存資産活用
  1. I/F
  2. 既存システム

• SOAが開発プロセスに与える影響
  • 工数差異の要員
• サービスをどこに開発するべきか？
  • APの外側に実装する場合
    1. 複数の情報を束ねる為のサービス化
       • サービスの実体（サービス実装）をアプリケーションの外側に開発するパターン
       • 今後、アプリ側のインスタンスが増減しても「グローバル在庫サービス」は利用する側にとって変化が出ない（疎結合である）
    2. 期待している効果
       • サービス提供側の変化対応力を向上
  • APの内側に実装する場合
    1. 複数の利用者のために標準化するためのサービス化
       • サービスの実体（サービス実装）をアプリケーションの内側に開発するパターン
    2. 期待している効果
       • サービス利用側の変化対応力を向上
• オラクルの優位性
  • ERP+SOAが目指していること
    1. パッケージとSOAの混在
    • 今まで：システムの要件を満たすためにシステムを開発してカットオーバーしていた
    • これから：解決策は2パターンある
      1. パッケージ・アプリケーションによるシステム構築
      2. SOAによるシステム構築
         • 初期の検討の時間に時間がかかる
         • 一度カットオーバーされれば、小刻みに・部分的に機能の入れ替えが可能
      3. 両方いいとこ取りしたのがハイブリッド型
         • 先にパッケージを利用、その後競争の源泉に関わる部分を手組にしていく
• SOAのテンプレート（Oracle AIA）
  • 実体はXML
    • データモデル、サービス、プロセスを包含

15:30～16:20 経営判断の迅速化と運用コストの削減を両立するBPM実践事例

• 問題点
  1. ビジネスの変更にシステムが追いつかない
  2. コスト削減といっても、どこをコスト削減すればよいのかわからない
• 俊敏性とコスト削減を求めて
  1. ビジネスモデルをモデル化しないといけない
  2. 業務が見える化されてきて、初めて改善ポイントがわかる
• 運用コストを削減する為に、QCDを守る、向上させていくことが必要
  • QCDを上げながら、運用コストを削減することが必要
  • 無理・ムラ・無駄を無くす
• 業務側の流れ
  • ITと全社戦略・ビジネスが融合する必要がある
• 日常業務プロセスの見える化
  1. 日常業務プロセスの文書化が実施できた
  2. 内部統制の観点で管理している文書にも対応可能
  3. 組織と機能の連鎖が、人に頼っていた部分が組織として持つことが出来るようになった
• システム全体での効果の考察
  1. 影響範囲や効果の度合いがわかるようになった

17:00-18:30 第5回BPMオフ会「いまさら聞けないBPM」

http://wiki.oracle.com/page/%E7%AC%AC5%E5%9B%9EBPM%E3%82%AA%E3%83%95%E4%BC%9A+%E3%80%8C%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E8%81%9E%E3%81%91%E3%81%AA%E3%81%84BPM%E3%80%8D?t=anon

• BPMをネタにして盛り上がるためのコミュニティ

1.大井貴文さんによる「BPM入門」

• BPMとはコミュニケーションツール
• [Q] BPMでは何が出来る？
  • [A] 仕事の流れが制御できる
• [Q] BPMが出来ないこと
  • [A] 何か最後の決断をするのは人間
• [雑談] シューティングゲームの視点にはFPS（First person Shooting）1人称視点、TPS（Third Person Shooting）3人称視点
  • [雑談] 小説の視点では、3人称視点は"神"の視点
  • [雑談] 1人称視点は"紙"の視点？
• BPMは、仕事の流れの視点で管理が出来る

2.大谷さんの「BPMプロジェクトのKickOff/Closing」で始めよければ終わりよしなPJの勘所を！

• [Q] BPMとは
  • [A] 「ビジネス管理手法」であるという考え
• [Q] BPMに何が出来ますか？
  • [A] 業務の可視化については可能性はある
  • [A] BPMSがすべての業務の問題を解決するわけではない
• [Q] まずBPMプロジェクトとは何か
  • [A] 開発プロジェクトオンリーではない
  • [A] 業務改善プロジェクト->可視化プロジェクト->BPMS開発PJプロジェクト
  • [A] BPMは業務改善のための手段にすぎない
• BPMは業務の問題点を改善するというスタートが良い
• 何のためにBPMを導入するのか、目的を考えることが重要

3.市川さんが「BPMの現場から」でリアルな実感を伝える！

日本オラクル技術エンジニア 市川義規（いちかわよしのり）

• [Q] BPM（Business Process Management）とは？
  • [A] 業務改善手法の一つ
• [Q] BPMのルーツ
  • [A] QC活動、シックスシグマ、BPR
• [Q] BPMの特徴
  1. [A] プロセス指向
  2. [A] モデル駆動
  3. [A] 継続的改善活動
• [Q] BPMに何が出来ますか？
  • [A] 間接コストの提言、提供サービスの品質向上
• [Q] BPMに何が出来ませんか？
  • [A] BPM自体は手法でしかないので、単体では何一つ出来ません
• [Q] BPMのメリットは何か？
  • [A] 自動化、可視化、の為のツールではない
  • [A] 自動化・可視化したからといって業務が改善されるわけではない
  • [A] 世間一般のBPMツールから直接的に導き出せる効果
  • [A] 業務プロセスの課題点は解消する
    • 手作業によるプロセスが抱えるコンプライアンスの課題
    • 可視化されていないプロセスが抱える作業の効率低下の課題
• [Q] BPMは業務改善手法
  • [A] 改善効果が得られなければ意味がない
  • [A] 業務の可視化は改善効果か？
  • [A] アイスクリームサンデーのチェリーでは困る（あったらいいけどなくてもよい、ではダメという比喩表現）
• [Q] BPMは業務改善手法
  • [A] 間接コストの削減
• [Q] どうすればBPMができるか？
  • [A] データベース製品ではない（買って設定しただけではNG）
  • [A] 業務を改善するには業務を知り、課題点を明確にし、評価指標を定める
• [Q] BOMは人が主役
  • [A] 製品を買う必要はある
  • [A] プロジェクト計画を立てる必要もある
  • [A] 成功させるのも人、失敗させるのも人

4.古久保さんが「京都発ビジネスとBPM」でBPMベンダーの本音を！

• [Q] BPMとは？
  • [A] 世界中のサラリーマンを救う管理手法
  • [A] 企業活動を業務プロセスの視点で捉え、その業務プロセスを継続的にカイゼンする、という手法
  • PDCAサイクル ≒ BPMライフサイクル
• [Q] BPMに何が出来ますか？
  • [A] 「継続的なカイゼン」による「生産性の向上、作業品質の向上」
• [Q] BPMに何が出来ませんか？
  • [A] 管理手法なので、「有形物」を生み出すことは出来ません
• [Q] BPMの目的
  • [A] 弱みの克服：企業に潜む問題やリスクを顕在化、カイゼン実施
  • [A] 強み強化：業務効率の改善や作業品質の更なる向上
• Human-Centric BPM
  • 人間の判断や行動がタスクとして定義されている業務プロセスを対象とし、最適化を求める
• Integration-Centric BPM（Oracle, IBMなどが取り組んでいる）
  • システムが制御するタスクを中心に構成されている業務プロセスを対象とし、最適化を求める
• [Q] BPMに必要な機能は？
  1. [A] モデリング機能
     • 業務プロセスズ描画機能、プロセスデータ編集機能、インタフェースカスタマイズ機能、プロセスアーカイブインポート・エクスポート機能
  2. [A] オペレーティング機能
  3. [A] モニタリング機能
  4. [A] システム管理機能
• [Q] どのようにしてBPMを実践するのか
  • [A] BPMサイクルを回す

5.和田正則さんによる「ビジネス視点のBPM」で経営とBPMの関係を理解する

• [Q] BPMに出来ることは？
  • [A] 事業とITの橋渡しが可能
• [Q] BPMが出来ないことは？
  • [A] 経営改革、SIerの売上アップは出来ません
• [Q] なぜBPMが出てきたのか
  • [A] イノベーションを起こす可能性を感じる（従来のやり方を崩して、新しいやり方を導入する可能性）
• [Q] これまでの常識とは
  • [A] 業務システムは開発するものである
  • [A] あいまいなことはシステム化できない
  • [A] システム化要求はコードで実現する
• [Q] BPMを実践するには
  • [A] BPMを理解するところからは入ってはいけない
  • [A] ビジネス上、あるいは業務システムで抱える問題を解決するための仕組みや仕掛けはどうしたらいいかと考える
• [Q] 現状抱える問題点とは？
  1. [A] 戦略や事業とITの乖離
  2. [A] システム構造が変化に弱い
  3. [A] 低い開発生産性
• [Q] なぜ、戦略や事業をITで表現出来ないのか
  1. [A] 要求定義->要件定義->実装の一貫性がない
  2. [A] ITを意識せずに作った業務プロセスなので、そのまま実装できない
  3. [A] 非定型業務（人間系）をIT化できない
  4. [A] システムを作って終わり
  5. [A] 結局、業務そのものが可視化出来ていない
• [Q] 今の業務プロセスに多い間違い
  1. [A] 手作業が多い
  2. [A] システムを人間が手作業で繋いでいる
  3. [A] システムは、単にデータ登録とレポート作成を行っているだけ
• [Q] 問題解決の方向性
  1. [A] 上流から下流まで一貫性を保つ
  2. [A] BPM on SOAの考え方
  3. [A] コードを書かない開発
     • 業務システム構築は、製品をつなぎ合わせる
• [Q] BPMの価値とは？
  1. [A] 「機能とプロセスとデータを明確に分離し、機能とプロセスは疎結合で連結させる」ことにより、企業情報システムが抱えている課題を解決出来ることがある
• [Q] BPMがもたらす変化とは
  1. [A] IT主体のシステムから人間主体のシステムへ
  2. [A] DevelopmentからControl&Operation

6.羽生さんによる「BPMの夢と現実」で綺麗に収まる・・・のか？

• [Q] BPMに出来ないことは？
  • [A] 社内の人間関係の修復は出来ません
• [提言] 社内の人間関係を置き去りにして業務システムを構築するのは無理
• [雑談] 3人を超えるとPublicになる
• [Q] 組織の二面性とは
  • [A] 機能体としての組織
  • [A] 共同体としての組織
• [提言] 機能体としての組織に対してBPMはアプローチ出来るが、共同体としての組織に対してBPMがアプローチすることは出来ない
• 組織文化が個人は染める
  • 3Uな組織文化（内向き・上向き・後ろ向き）
  • 3Yな個人の姿勢（やらない・優柔不断・許さない）
• BPMの前に「文化」を変えろ！
  • 3Cな組織支援（チェンジを受け入れる・チャレンジの水晶・チャンスを与える）
  • 3Tな個人の姿勢（Try：チャレンジ・Think：考える・Trust：信頼）
• スモール＆クイックWin
  • こんなこと誰にでも出来て当然と思うくらいに、小さなチャンスを用意して、短期間で確実に成功させろ
• [Q] BPMの原動力は「ハート」！
  • [A] もっといい仕事をしたい！だからBPM！