Kotatsu-Model in Openthology
•
0 likes•2,240 views
オープンコミュニティ「要求開発アライアンス」の2008年3月定例勉強会の発表資料。 要求開発方法論Openthologyにおける、ステークホルダーの関係性のメタファー「コタツモデル」に関する話です。
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
More from Kent Ishizawa
More from Kent Ishizawa (20)
Kotatsu-Model in Openthology
- 1. コタツモデル再考 Openthology2.0 AAWG 石沢
- 2. 今回の発表の目的 • 「コタツモデル」についての「ふりかえり」 • アンチパターン – 「皆さんのアンチパターン」を聞きます • プラクティス – 「皆さんのプラクティス」を聞きます • 皆さんに「気づき」を持ち帰ってもらいたい • Openthology 2.0への収録の準備 2
- 3. コタツモデルとは • 要求開発におけるメタファー • 合意形成のための関係性 • 「コタツモデル」では、ビジネスオー ナーと業務担当者、システム開発者 が問題の視覚化(モデル)と改善プロ セスによる活動を行うことによって、「正しい要求の 獲得」を行います。 • 意外なことに、書籍「要求開発(Openthology Ver 1.0)では言及されていませんでした。 3
- 4. 要求開発とは – 正しい要求の獲得と合意のための活動 業務理念を統制し、業務効率化を図るため の業務とは○○あるべきだ、しかし現実は △△だから、それをどう改善できるか現場と 話し合ってみよう。 ビジネスオーナの論理 あの業務は、○○パッケージや○○フ レームワークを使って開発すればよさそ うだ、しかし、本当に求められている業務 我々のやり方がベストだと思っていたけど、 の姿を明確にして３者で合意しなければ、 見方を変えれば欠点が多いね。問題分析ツ 真の要求など獲得できるはずがないね。 問題の視覚化(モデル)と リーでもう少し業務のあるべき姿を考えてみ 改善プロセスによる活動 よう。 コタツ システム開発者の論理 開発された要求 （システム要件） 業務担当者の論理 モデル 4
- 5. Part.1 コタツについて考える コタツとはいったい何か？ 5
- 8. 8
- 9. 9
- 10. コタツの要素 • 熱源 • こたつ布団 • ミカン 10
- 11. 熱源 • コタツを暖めるためには、装置としての「熱源」 が必要 • コタツモデルにおける熱源とは – 要求開発実施の目的が明確である。 – 要求開発の実施が同意されている。 11
- 12. こたつ布団 • こたつ布団の効果 – 足を入れる – 足を隠す • 足を入れる – 要求開発参加に対する覚悟 • 足を隠す – フォーマルな世界だけではなく、インフォーマルな 世界もあわせて価値を作る 12
- 13. インフォーマルな世界 13
- 14. ミカン • 食べ物 • 見ることや触ることができるモノ • コタツモデルにおける、共有・議論・合意する 「見えるもの」 – 視覚化された問題 – 視覚化されたプロセス、構造 – ビジネスモデル 14
- 16. 既知のアンチパターン • 全員コタツの外 Outside with Kotatsu Pattern • 利用者不在 Users Absence Pattern • オーナー不在 Owner Absence Pattern ※英語部分に意味はありません。 16
- 17. 全員コタツの外 Outside with Kotatsu • 最悪のシナリオ • ビジネスオーナー、 業務ユーザー、 エンジニアの間に壁がある。 （コタツに入ってない） • 合意形成が行われない。 • 最初の企画案などをベースに、検証をせずに「間違 った」システムを「正しく」作ることになるが、結局使 われない。 • 無駄な投資に終わる。 17
- 18. 利用者不在 Users Absence • うまくいきそうでダメな シナリオ（１） • オーナーの意見「あるべき業務 の姿」を聞いてシステムを開発 • 業務ユーザーから大クレーム 結局は使われないシステムに。 18
- 19. オーナー不在 Owner Absence • うまくいきそうでダメな シナリオ（２） • 業務ユーザに要件をヒアリ ングして、開発をする。 • 現状業務にあわせてしまう。 結果として、業務の改善や 標準化はできなかった。 • 要求が発散してしまった。 • 仕様変更により、システムがキメラ化する。 19
- 20. 新しいアンチパターンの提言 • 寒い！ Cold Pattern • ミカンがない Without Mikan Pattern • ミカンがマズい Bad Mikan Pattern • 鍋奉行 Nabe-bugyo Pattern • これはコタツではない Not Kotatsu Pattern • 密約 Huddle Pattern 20
- 21. 寒い！ Cold! • 電気が切れてる （熱源がない） • 要求開発を進める為の 熱意（目的）が無い状態。 • または、全員が何をやっていいのかわからな い。リーダーシップが不在である。 21
- 22. ミカンがない Without Mikan • 合意するためのミカン （モデル）がない為、 議論ができない。 • または、ミカンを準備する ことが誰もできない。 • 単なる井戸端会議と なってしまう。 22
- 23. ミカンがマズい Bad Mikan • 噛んで美味しい戦略が ない。 • モデルが悪く 議論にならない。 • しらけてしまう。 23
- 24. 鍋奉行 Nabe-bugyo • 特定の参加者の声が 大きく、結果として 議論が不完全に。 • 議論への不満が残る。 • 強引な合意形成。 24
- 25. これはコタツではない Not Kotatsu • こたつ布団がない （これは机である） • 議論がフォーマルすぎて、 適切な議論や合意形成ができない。 （言うべきことが言えない） 25
- 26. 密約 Huddle • コタツの外で合意が 行われる。 • コタツモデルにおける、 合意形成が適切ではなくなる。 26
- 28. Part.3 プラクティス コタツモデルを形成するための アイデアと提言 28
- 29. プラクティス • 事前準備のプラクティス – ステークホルダー分析 – GE式ワークアウトに学ぶ – プレモデルの活用 • プロセス内のプラクティス – ファシリテーション – 非日常を演出する • 皆さんのプラクティス 29
- 30. （１）ステークホルダー分析 • 参加者の利害関係を分析する • ポイント – 参加者は何を代表しているのか？ （利用者の代表、部門の代表、顧客の代表） – 権威勾配は適切か？ • 操縦室内権威勾配(Trans-cockpit Authority Gradient) • 参加者の権威差があるかどうかに注目する – 参加者は何を望んでいないのか？ 30
- 31. （２）ワークアウトに学ぶ 31
- 32. （２）ワークアウトに学ぶ • 組織横断的チームによる変革プロセス →要求開発と位置づけが類似している。 • 経営幹部によるイントロダクション • 基本原則 – 聖域をつくらない – 縄張り争いの禁止 – 非難はしない – マネージャはその地位を悪用しない – 愚痴の禁止 – 解決策に焦点を当てる • グループワークについての様々なアイデア 32
- 33. （３）プレモデルの活用 • 戦略マップ、要求ツリー、概念モデルについて 事前情報と仮説のもとに、プレモデルを作成し て要求開発に望む。 • ざっくりとモデリング 「ざくモデ」 • 要求開発の序盤にスピード感を出す。 • 参加者に、慣れるための時間を作る。 • 空中戦になりがちな序盤を早く終わらせ、地上 戦に持ち込む。 • 鍋奉行パターンに注意 33
- 34. （４）ファシリテーション 34
- 35. （４）ファシリテーション • 議論を円滑にすすめるための道具集として • コタツモデルで活用できそうなツール – 各種の思考フレームワーク – インテグレーション・ミーティング – 制御可能 vs 制御不能 – 賛成（プロ） vs 反対（コン） • ホワイトボード等を活用した議論の「見える化」 – ファシリテーション・グラフィック 35
- 36. （５）非日常を演出する • 日常業務が議論の妨げとなる場合がある。 – 有識者は忙しい • 日常業務から距離を置く – 終日ミーティング – 会議室以外でミーティング – 専用会議室（ウォールーム） – 現地現物、現場でミーティングする – ゲストを呼ぶ • 研修会場から将来のユーザーを呼ぶ • 長老を呼ぶ 36
- 37. 発想を豊かに 37
- 39. ご清聴ありがとうございました。 39