第６回 要求シンポジウム その１

昨日、「第６回　要求シンポジウム」に行ってきた。
そのときのメモメモ（前半）

---

■ＩＰＡの挨拶
民事の争いが多くなっている
　　・医療事故
　　・知的財産
　　・建築
　　・ＩＴ(システム開発）
→情報の非対称性がある
　　→でも、最低限、双方理解しないといけないものがある
　　　　→前半：はっきり伝える、受ける、フィードバックして確認

司会：名古屋大学の山本先生
　裁判
　　　・運用がする前、してから問題が起こる
　　　　　　→過去に引き戻される

---

■ビジネスアナリシス　最前線
　ＩＩＢＡ日本支部　研究担当理事　宋　氏
（山本先生のコメント：アメリカと日本では開発のコンテクストが違う）

【ＩＩＢＡとは？】
　２００３年１０月創設
　ビジネスアナリシスの実践と資格のスタンダード開発・維持

【ＢＡＢＯＫ】
２００９年１２月　ＢＡＢＯＫ日本語版　７つの知識エリア
　　　タスクとテクニックの組み合わせ、知識の体系
２０１１年５月　　ＢＡＢＯＫ　Ｖｅｒ３　開発開始

・かなり抽象的に書いてあるので、直接的な問題解決マニュアルではない

【今日のお話】
北米：企業の組織の活動としてビジネスアナリシス
　→技術トレンドとしてある
　→ビジネスアナリシスの活動の傾向

【問題の起点】
・システムが複雑で、みな困っている
　　→システムは現場を写す鏡
・企業組織を４つに単純化
　　ビジネスシステムの世界
　　　　１．経営層が責任を持つ：経営のスコープ
　　　　　　　↓
　　　　２．業務組織が責任をもつ：ビジネスモデル
　　情報システムの世界
　　　　３．ＩＳマネージメント層が責任を持つ
　　　　　　　↓
　　　　４．情報システム開発・運用
　→様々な組織の壁、コミュニケーションギャップ

　　　現実の世界　　－（写像）→　　仮想の世界

【典型的な課題：その１　要求が複雑】
・要求の盛れ、ダブり
・要求の対立（複雑になると）→干渉していることを見つけるのが難しい
・要求が複雑→企画・要求定義を強化する→チェックしきれない
●解決策：いったん業務のシンプル化
　　　　　　商品のシンプル化
　　　　　　プロセスのシンプル化

【課題：その２】
・ビジネスを取り巻く環境変化
　　→経営目標・戦略が俊敏に適応
　　→情報システムもアジャイルに適用できないと・・
　　　　→実装段階でコードを凍結
　　　　→このギャップは？

・北米では
　ビジネスアナリシスマネジメント
　　　　＝ビジネスプロセスマネジメント
　　　　　　＋ビジネスルールマネジメント

　ファクトモデルで業務の基本構造をあらわす
　　・名詞を取り出す→四角い箱にいれる
　　・動詞を取り出す

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

　・ビジネスイベント
　　　・業務処理
　　　・評価ポイント
　　　・処理

　アプリケーション本体に、ビジネスルールの評価と処理の部分は混在していないか？
　　　処理はシンプル：変わらない
　　　ビジネスルールの評価と処理が変わる

　北米：業務(ビジネスプロセス）とビジネスルールを分離する

---

■ＲＥＢＯＫ　南山大学　青山先生

　顧客要求からソフトウェア要求までをカバーする知識体系が欠如している
　　　要求工学方法論をいろいろ出しているのは、日本しかない
　ビジネス・プロダクト要求
　システム要求
　ソフトウェア要求
　（ソフトウェア開発）
　　→ＩＳＯ２９１４８に対応

４つのプロセス：特別なものではない
　　　　　→ＳＷＥＢＯＫ第二章と基本的には同じ枠組み

　・要求獲得
　・要求分析
　・要求仕様化
　・要求の検証・妥当性確認・評価

要求獲得：要求の原泉Ｘ獲得方法
　・ステークホルダー分析
　・ゴール分析
　　　　ソフトゴール・ハードゴール・タスク
　・シナリオ分析

文書化
　・ビジネス要求の文書化　IEEE Std.１３６２
　・システム要求の文書化　IEEE Std.１２３３
　・ソフトウエア要求の文書化　IEEE Std.８３０

要求管理
　・ＰＭＢＯＫといかに組み合わせるか

現在、人材育成とモデルカリキュラム→報告書が作成できそう

３つの提言
・要求の価値を生かそう
・要求工学の本格的な実践を図ろう
・要求工学の人材を育成しよう

---

■ディスカッション

　宗さん、青山先生、山本先生

【要求のＢＯＫ】：下流から上流に上がってきた。
　他の知識体系との融合は？

・宗さん
　ＢＡＢＯＫはどのように利用する？：目的指向
　　→どのくらい、整理統合されている？
　　　どういう目的に対して、Change of Change
　　　　ビジネスケイパビリティの実現

・青山先生
　スコープ：ＲＥＢＯＫのミッション
　ＲＥＢＯＫ：知識とタスクの組み合わせ

・ＥＡとの親和性、ファクトモデル（＝ＤＯＡ）
　ＳＢＶＲ（Semantics of Business Vocabulary and Rule)
　　　：ファクトモデルのノーテーションツールでもある

【リスク分析は？】
　ＲＡＣＩが役立った。
　ＰＭＢＯＫのリスク（リスク・ブレークダウン・ストラクチャー）
　
・青山先生

・宗さん
　現状の問題解決方法では解決しない。
　有効な解決策の導出→リスクが出てくる

【クラウド】
・つくるだけじゃなくって、すでにあるんじゃないの？

・宗さん
・ビジネスシステムと情報アーキテクチャーに整合しているか？
　　ノンコアならＯＫ
・わが社のビジネスアーキテクチャは？

・青山先生
・アジャイル、クラウドでも
　　→ＳＬＡ

【複雑なものに対して】
・保証ケース（アシュアランスケース）
　　→エビデンスがあるから、保証される：ゴール指向で
・要求発展型開発ワーキング
　　→ＩＴ技術の発展

・青山先生
　　複雑さを低減しようとしている：要求工学

・宗さん
　　そういう問題を意識している（ＢＰＯとかも）
　　物売りビジネス→サービスに変化

【ＥＡ】
・ザックマンのフレーム：基盤
　　→チェンジフレームワーク
・ＥＡ：フレームワークと、ユーザーの視点（シナリオ・ユースケース）


【運用】
・オペーレーション要求に対する分析が必要なのでは

・宗さん
　例外：ビジネスルールから仕様化

・青山先生
　チェックとアクション

---

ここで、休憩になって、後半戦へ

なので、このエントリもここでいったん、きります。