ビジネスアナリシス最前線 - ipababok v2.0日本語版翻訳プロジェクト...

【SEC特別セミナー】超上流工程～システムエンジニアリングとビジネスアナリシスの観点から～

ビジネスアナリシス最前線

北米のビジネスアナリシスを取り巻く最新技術動向解説

宗雅彦IIBA日本支部研究担当理事株式会社サイクス代表取締役

Copyright(c) Cyx Inc. All Rights Reserved. http://www.cyx.co.jp

2011/7/12

最新技術動向解説

株式会社サイクス http://[email protected]

自己紹介

宗雅彦(そうまさひこ)

IIBA日本支部 http://iiba-japan.org研究担当理事ビジネスアナリシス研究部会・部会長

日本のビジネスを強くする!元気にする!日本の産業の競争力強化に貢献します!

ビジネスアナリシスの実践適用支援、およびビジネスアナリストを創造的問題解決型人財ととらえ、その育成支援に取り組んでいます。

ビジネスに寄与する情報システムの導入構築

ビジネスアナリシスの普及・促進に取り組んでいます!

IIBA日本支部でビジネスアナリシスの普及・促進にかんする活動を展開しています。●ビジネスアナリシス研究部会における

ビジネスアナリシス/BABOK研究活動の企画・推進ビジネスに寄与する情報システムの導入・構築

支援から、業務改革・プロダクト/サービス企画の改革支援まで、お客様のビジネスを強くする!元気にする!ビジネス競争力強化の貢献を目指して活動しています。

Copyright(c) Cyx Inc. All Rights Reserved. http://www.cyx.co.jp 1

企画・推進●BABOK v2.0日本語版翻訳プロジェクト

プロジェクトマネージャ・監訳●IIBA本部のBABOK v3.0開発プロジェクト

コンテンツ(開発)リーダー

ビジネスアナリシス・BABOKに関連する活動

次世代版BABOKv3開発開始!!2011.05～

次世代版BABOKv3開発開始!!2011.05～

左より：・IIBA日本支部福嶋代表理事・IIBA VP Mr. Kevin Brennan・IIBA CEO Ms. Kathleen Barrett・IIBA日本支部研究担当理事宗

ビジネスアナリシス研究部会・部会長※入会についてのお問い合わせは

[email protected]まで

BABOK v3 開発(コンテンツ)リーダー

IIBA日本支部としてもBABOK v3開発に貢献しています


http://itpro.nikkeibp.co.jp/article/NEWS/20100616/349244/

IIBA日本支部BAコンファランス2010(2010.06.16)ビジネスアナリシス研究部会パネルディスカッション風景右から：みずほCB ITシステム統括部富澤さま日産自動車グローバル情報システム本部山本さまIIBA日本支部研究担当理事宗

日経コンピュータセミナーシステム開発を成功に近づける! (2010.04.27) 「BABOK」最新活用!現場で実践!BABOK最新活用!(2011.04.19)

BABOK® v2.0日本語版監修・翻訳プロジェクトマネージャ

執筆・翻訳活動

「要求開発と要求管理」「要求開発ワークショップ「ビジネスアナリシス ITアキテクト V l 23ITPro「要求開発と要求管理」

Karl Wiegers著宗雅彦監修マイクロソフトプレス刊

要開発の進め方」Ellen Gottesdiener著三島邦彦、前田卓雄、宗雅彦監訳日経BP社刊

ビジネスアナリシス知識体系ガイド」IIBA発行宗雅彦等監修IIBA日本支部刊

ITアーキテクト Vol.23BABOK特集記事宗雅彦著

o「BABOK全解説」宗雅彦著

http://itpro.nikkeibp.co.jp/article/COLUMN/20100729/350789/


「アジャイルソフトウェアマネジメント」

宗雅彦、前田卓雄訳日刊工業新聞社刊

ITアーキテクト Vol.24「アジャイル開発の真価」宗雅彦著

「体系的ソフトウェアテスト入門」Rick Craig他著宗雅彦監訳成田光彰訳日経BP社刊

「はじめて学ぶソフトウェアのテスト技法」

Lee Copeland 著宗雅彦訳日経BP社刊

[ソフトウェアの欠陥予防]宗雅彦監訳日経BPソフトプレス刊

「パターンによるソフトウェア構成管理」宗雅彦訳翔泳社刊

本日、お話ししたいこと

いよいよはじまった次世代版BABOK(version 3.00)の開発。IIBA日本支部としてもこの開発プロジェクトに貢献すべく、全世界から

選抜された8名のコンテンツ開発リーダーのひとりとしてIIBA本部の活動に参画する中で、北米におけるビジネスアナリシスの実践に顕著な影響をもたらしている技術トレンドが浮かび上がってきました。本日は、北米で実践が進むビジネスアナリシスをとりまく、IIBA本部も

注目する技術トレンドをヒントにしながら、ビジネスアナリシスの実践がわれわれになにをもたらすのかについて、見解を述べさせていただきたいと思います。限られた時間ではありますが、よろしくお願いします。

北米のビジネスアナリシス実践の最前線で注目されている技術的な


北米のビジネスアナリシス実践の最前線で注目されている技術的なキーワードの観点から、北米の組織がどのように“ビジネスとIT”の課題解決をはかっているかについての解説を行います。ここでは、個々の技術的なキーワードの詳細な解説を行うことが目的というよりはむしろ、なぜこれらのキーワードに焦点があてられているのか、その理由を探り、理解することが主目的であります。

この違いはどこから生まれるのか?

2,000 vs 100

日本の某保険会社の情報システム関連組織

の人数

欧米の某保険会社の情報システム関連組織

の人数

Why?


の人数の人数

厳密に定量的に分析することは困難であるものの20:1の違いはあまりにも大きい・・・

北米のビジネスアナリシスの最前線を取り巻くキーワード①

アジャイル・ビジネスアナリシス

9%

9%

10%

27%

41%

45%

56%

その他

シックスシグマ

リーン

RUP

アジャイル

SWOT

内部開発の方法論

ビジネスアナリストはどのようなアナリシス・フレームワーク/方法論を利用しているか?

アジャイル開発を実施した経験がある米国企業の割り合い

経験あり(69%)

経験なし(31%)


出典: ITアーキテクト誌Vol.24『アジャイル開発の真価』執筆：宗雅彦Dr.Dobb’s Journal 2008 Agile Adoption Surveyより

4%

5%

5%

9%

9%

TOC

ポーターの５フォース

なし

リーンシックスシグマ

その他

出典: Forrester ResearchQ2/2009 Business Analyst Survey

アジャイル開発とは～アジャイル開発に対する一般的な理解～

一般的にアジャイル開発とは、ウォーターフォール型開発の性能限界を打破するためのプロセスの変革と理解されている。

ウォーターフォールアジャイル

固定する要求スケジュールコスト

計画

バリュー / ビジョン駆動型

計画段階でコストとスケジュールを見積もる

ビジョンから要求の見積もりを行う


見積もるスケジュールコスト要求

計画駆動型

駆動型

Source: DSDM: www.dsdm.org

プロセス変革

プロセス変革

プロセス変革：アジャイル開発に典型的なイテレーティブ・マネジメント

優先度・高成果物2～4週間コストとスケジュールは固定

イテレーティブ・マネジメントは、柔軟な要求の追加・変更への適応を可能にする

イテレーション１イテレーション１

優先

度

イテレーション２イテレーション２

イテレーション３イテレーション３

・・・・・・・・・・

成果物要求(スコープ)は可変イテレーション途中の要求の追加・変更は禁止

ＮＯＮＯ


優先度・低

しかしプロセスの変革のみで2000:100のギャップの説明は可能か?

北米のビジネスアナリシスの最前線を取り巻くキーワード②

アーキテクチャ

ビジネスアキテクチ

情報システムアキテクチ


アーキテクチャアーキテクチャ

“アーキテクチャ”というキーワードに注目してみたい

WHAT データ

HOW 機能

WHERE ネットワーク

WHO人

WHEN 時間

WHY 動機

計画立案者

ビジネスモデル

エンタープライズ・アーキテクチャ – Zachmanフレームワーク

スコープ文脈的

ビジネスにとって重要なもののリスト

例：セマンティックモデル

ビジネスが遂行するプロセスのリスト

例：ビジネスプロセス

ビジネス運用拠点のリスト

例：ビジネス流通システム

ビジネスにとって重要な組織のリスト

例：ワークフローモデル

ビジネスにとって顕著なイベント/サイクルのリスト

例：マスタースケジュール

ビジネスゴール/戦略のリスト

例：ビジネスプラン

ビジネスモデル概念的

オーナー

システムモデル論理的

設計者

テクノロジーモデル物理的

モデル

例：論理データモデル

例：物理データモデル

例：アプリケーションアーキテクチャ

例：システムデザイン

システム

例：分散システムアーキテクチャ

例：テクノロジーアーキテクチャ

例：ヒューマンインターフェース・アーキテクチャ

例：プレゼンテーションアーキテクチャ

例：プロセス構造

例：コントロール構造

例：ビジネスルールモデル

例：ルールデザイン

例：データ例：機能例：ネットワーク例：組織例：スケジュール例：戦略

構築者

詳細表現文脈離れ

サブコントラクタ

機能するエンタープライズ

10

例：データ定義例：プログラム例：ネットワークアーキテクチャ

例：セキュリティアーキテクチャ

例：時間定義例：ルール仕様

Copyright© John Zachman, Zachman InternationalCopyright(c) Cyx Inc. All Rights Reserved. http://www.cyx.co.jp

WHAT データ

HOW 機能

WHERE ネットワーク

WHO人

WHEN 時間

WHY 動機

計画立案者

ビジネスモデル

エンタープライズ・アーキテクチャ – 6つの観点(Perspective)

スコープ文脈的

ビジネスにとって重要なもののリスト

例：セマンティックモデル

ビジネスが遂行するプロセスのリスト

例：ビジネスプロセス

ビジネス運用拠点のリスト

例：ビジネス流通システム

ビジネスにとって重要な組織のリスト

例：ワークフローモデル

ビジネスにとって顕著なイベント/サイクルのリスト

例：マスタースケジュール

ビジネスゴール/戦略のリスト

例：ビジネスプラン

スコープ（境界)スコープ（境界)

ビジネス(業務)モデルビジネス(業務)モデル

注目注目

注目注目ビジネスモデル概念的オーナー

システムモデル論理的

設計者

テクノロジーモデル物理的

モデル

例：論理データモデル

例：物理データモデル

例：アプリケーションアーキテクチャ

例：システムデザイン

システム

例：分散システムアーキテクチャ

例：テクノロジーアーキテクチャ

例：ヒューマンインターフェース・アーキテクチャ

例：プレゼンテーションアーキテクチャ

例：プロセス構造

例：コントロール構造

例：ビジネスルールモデル

例：ルールデザイン

ビジネス(業務)モデルビジネス(業務)モデル

システムモデルシステムモデル

テクノロジーモデルテクノロジーモデル

注目注目

注目注目

例：データ例：機能例：ネットワーク例：組織例：スケジュール例：戦略

構築者

詳細表現文脈離れ

サブコントラクタ

機能するエンタープライズ

11

例：データ定義例：プログラム例：ネットワークアーキテクチャ

例：セキュリティアーキテクチャ

例：時間定義例：ルール仕様

Copyright© John Zachman, Zachman International

ツール仕様ツール仕様

運用インスタンス運用インスタンス


ビジネスとITのギャップはなぜ生まれるのか? - アーキテクチャの不整合 –

自組織を取り巻く環境

要求・コンセプトの流れ

経営層が責任を持つ領域

経営のスコープ ISのスコープ

ISマネジメント層が責任を持つ領域

の流れ

ISの目的と目標

IS要求モデル

業務の目的と目標

業務プロセスモデル

ISのスコプ

ISモデルビジネス(業務)モデル

例: 経営の目標、経営戦略例: ISの目標、IS戦略

ビジネスアーキテクチャ

ISアーキテクチャ


業務組織が責任を持つ領域

さまざまな組織の壁で発生するコミュニケーションギャップ組織内ですらも成立しないコミュニケーション

情報システム開発・運用組織

IS:情報システム

例: 業務プロセス例: ISプロセス

現実の業務の世界

情報システム

仮想の業務の世界

ビジネスアーキテクチャと情報システムアーキテクチャ

ビジネス（業務)システム

ビジネス

写像

ビジネスアーキテクチャ IS


13


情報システムはビジネス（業務)システムの写像

ビジネス(業務)と情報システムのアーキテクチャを描き出し整合をはからなければならない

IS:情報システム

60%

70%

80%

90%

100%

要求複雑

ビジネスと情報システムには典型的な問題がある

要求複雑要求干渉要求未達情報システム・ソフトウェアの典型的な問題はなにか？

要求が複雑で干渉しているが干渉をみつけることが難しい

問題問題

0%

10%

20%

30%

40%

50%

ソフトウェア製品ハードウェア製品新商品・サービス開発

要求複雑

要求干渉

要求未達

出典：「続・失敗百選」中尾政之著森北出版株式会社

■新商品・サービス開発要求未達の割り合いが高い

いわゆる複雑な要求の問題が情報産業全体の問題の3割を占めている

要求の数干渉をチェックすべき数10個 100個100個 10000個(1万個)

Why?


要求未達の割り合いが高い（要求のもれ・だぶり）

■ハードウェア製品開発要求干渉の割り合いが高い(要求の対立・矛盾)

■ソフトウェア製品開発要求複雑の割り合いが高い

100個 10000個(1万個)1000個 100００００個(100万個)

とどのつまり現代のビジネスは大規模・複雑化しており、その写像である情報システムも大規模・複雑化していることが問題解決を

困難にしていることを意味している

■解決策レベル１企画・要求定義の強化

しかし工数の半分をチクに費やしても

解決策解決策

どのように問題解決をはかることができるのか?

→しかし工数の半分をチェックに費やしてもチェックしきれない

■解決策レベル2業務の標準化・シンプル化によるIS要求の標準化・シンプル化


ビジネスと情報システムの問題の解決にあたってはこの対策が必須となった

【事例】某保険会社の「抜本改革プロジェクト」

ビジネス（業務) 情報システム

自組織を取り巻く環境

①問題の起点：

お客様

③事件は業務の現場で起きている

ビジネスアーキテクチャ

ISアーキテクチャ

①問題の起点：「システムが複雑でみな困っている」

②原因の表明「システムは現場を映す鏡。商品・業務処理の規定を複雑にしているからシステムも複雑にならざるをえない。」

③事件は業務現場で起きている複雑な顧客・代理店の保険料の授受

etc.

④対応策その①：業務のシンプル化商品のシンプル化プロセスのシンプル化

⑥効果：ビジネス・業務の効率化


⑤対応策その②：情報システムの全面再構築

「抜本改革プロジェクト」

⑥効果：ビジネス・業務の効率化代理店さんの声：ペーパーレス化で1日100枚近くやりとりしていたＦＡＸがなくなったキャッシュレスで仕事がらくになった社内の声： etc.

【事例】堀場製作所の現場中心主義

堀場製作所の現場中心主義：情報システムはビジネスの手段であり目的ではない。ビジネスに貢献する情報システムとは、情報システムの戦略的目的、すなわちビジネス要求に情報システムがどれだけ全体最適化されるかで評価される。しかし現場の要求は部門の利益部門固有の要求の追求つまりしかし、現場の要求は、部門の利益・部門固有の要求の追求、つまり部分最適を追求することとなりがちである。これは、情報システムが追究すべき全体最適との矛盾・対立要因となる。その結果、情報システム組織主導の全体最適の追究は、あらゆる現場からの反対・反発を招く結果となりがちである。しかしこれを許せば、情報システムの複雑化・硬直化を招き、結果としてビジネスの要求に迅速かつ柔軟な適応の不良を招きビジネスとIT


てビジネスの要求に迅速かつ柔軟な適応の不良を招き、ビジネスとITのギャップ、投資対効果の低下を自ら認めることとなる。堀場製作所は、これを「現場（自己）中心主義」と呼んで戒めている。

出典：「京様式経営-モジュール化戦略」末松千尋著に加筆

日々の要求の追加・変更にあたってもアーキテクチャの整合性を維持できなければならない

北米のビジネスアナリシスの最前線を取り巻くキーワード③

ビジネスアナリシスマネジメント

ビジネスプロセスマネジメント

ビジネスルールマネジメント

+


マネジメントマネジメント

もうひとつの困難な課題 - 環境変化へのアジャイル(俊敏)な適応 -

ビジネスを取り巻く環境変化の激化

ビジネスのアジャイル（俊敏）な変化適応を情報システムはどのように支援することができるか?

望ましい情報システム

望ましくない情報システム

要求仕様を満たせばよい

環境変化にアジャイル(俊敏)に適応

成長・発展する情報システム

アーキテクチャ(構造)劣化


情報システム満たせばよい劣化要求への不適応

情報システムは、成長・発展可能なアジャイル（俊敏）なアーキテクチャを備えなければならないという課題

問題解決のアプローチ：ビジネスルールマネジメント(BRM)とは

人体

神経コントロール

ビジネス(業務)

ビジネスルール一元管理変化変化

筋肉

骨格

パワー

構造

業務プロセス

構造化業務語彙

シンプルシンプル分離

[ファクトモデル]

業務運用にかかわる本質的な“もの”や“こと”にかかわる知識を体系化(構造化)したもの

変化適応

安定安定


かかわる知識を体系化(構造化)したもの

“構造化業務語彙(ファクトモデル)”を舞台にすることで同じ意味を持つ業務用語で、ビジネスルール、業務プロセス

についてコミュニケーションが成立する

“ビジネス内”および”ビジネスとＩＴ“のギャップの解消

構造化業務語彙(ファクトモデル)で業務の基本構造をあらわす

構造化業務語彙(ファクトモデル)のシンプルな例

例：「顧客は商品を注文する」「顧客は受注担当者に割り当てられる「顧客は受注担当者に割り当てられる」

受注担当者商品顧客注文する割り当てられる

構造化業務語彙(ファクトモデル)はビジネス（業務）モデルの


構造化業務語彙(ファクトモデル)はビジネス（業務）モデルの基本構造をあらわす

ビジネス（業務）モデルの構造化業務語彙(ファクトモデル)は安定している普遍的といっても良い

ビジネスルール、ビジネスプロセスと構造化業務語彙(ファクトモデル)

構造化業務語彙(ファクトモデル)という舞台の上でビジネスルールでコントロールされた業務のシナリオ(手続き)を語る

ビジネスイベント

商品を注文する

ビジネス

イベント

商品注文のイベント(手続き)

評価ポイント

ビジネスルール#116を評価する

ビジネスルール

#116商品を注文した顧客には受注担当者が割り当てられなければならない

ルールの侵害

エラーメッセージを返す

エラーメッセージの伝達


受注担当者商品顧客注文する割り当てられる

構造化業務語彙(ファクトモデル)

ビジネスプロセス

ばならない

なぜ情報システムは変化に適応できないのか

業務手続き


日々、頻繁に変更されるビジネスルールを分離した本質的な業務手続きはシンプルである

情報システム

アプリケーション

業務手続き

混在している

日々、頻繁に変更されるビジネスルールへの対応のために莫大なリソースが

費やされている


ビジネスルールを手続きから分離することで

アーキテクチャはアジャイル（俊敏）になる

アジャイル・アーキテクチャの実装アプローチ例

ビジネスルールマネジメントシステム(BRMS)は、組織のポリシーおよび、組織のポリシーに関連した業務運用上の意志決定ルールを、定義し、適用し、モニタリングすることを可能にする。それをアプリケーションコードと分離して行う。

業務運用している人

ビジネスルール文書

スプレッドシートに記述した


ビジネスルールマネジメントシステム

ビジネスルールレポジトリ

ルールマネジメントアプリケーション

ルール開発IDE

ルールを管理する

ルールを引き出す


ビジネスルル

情報システム

レポジトリ

ルールの実行とモニタリング

意志決定サービスとしてルールを利用する

業務運用しているIS

ビジネスとITのギャップの問題を解決する

とどのつまりキーワードはどう関連するのか?

2,000 vs 100


日本の某保険会社の情報システム関連組織

の人数

英国の某保険会社の情報システム関連組織

の人数

【再確認】ビジネスとITのギャップの問題

情報システムは金喰い虫情報システムは金喰い虫

ビジネスへの貢献がみえないビジネスへの貢献がみえない

ちょっとした変更に莫大なテストが必要ちょっとした変更に莫大なテストが必要

ビジネスへの貢献がみえないビジネスへの貢献がみえない

つかいにくいつかいにくい

つかえないつかえない

IT投資のかなりが保守費にくわれるIT投資のかなりが保守費にくわれる

大量の変更要求バックログ

大量の変更要求バックログ


ビジネス環境の変化スピードに情報システムが追従できない

ビジネスと情報システムの

ギャップを埋めることが

できない

まとめ：BAの最前線を取り巻くキーワードはどのように関連するのか?

アジャイル情報システム

アジャイル・ビジネスアナリシス

アジャイルビジネスシステム + 情報システム


ビジネスプロセスマネジメント

ビジネスルールマネジメント

ビジネスシステムアーキテクチャ

+

+


Business ProcessMgmt System

Business RuleMgmt System

ビジネスとISのギャップの解消

ビジネスの環境変化への俊敏な適応を支えるIS

ご参考にしていただければ幸甚です

講演：IIBA日本支部研究担当理事URL: http://www iiba japan orgURL: http://www.iiba-japan.org

株式会社サイクスURL: http://www.cyx.co.jp

コンタクト：宗雅彦(そうまさひこ)Email: [email protected]


28

ビジネスアナリシス最前線 - ipababok v2.0日本語版翻訳プロジェクト...

Documents