More Related Content
More from Kent Ishizawa (20)
Kotatsu-Model in Openthology
- 4. 要求開発とは
– 正しい要求の獲得と合意のための活動
業務理念を統制し、業務効率化を図るため
の業務とは○○あるべきだ、しかし現実は
△△だから、それをどう改善できるか現場と
話し合ってみよう。
ビジネスオーナの論理
あの業務は、○○パッケージや○○フ
レームワークを使って開発すればよさそ
うだ、しかし、本当に求められている業務 我々のやり方がベストだと思っていたけど、
の姿を明確にして3者で合意しなければ、 見方を変えれば欠点が多いね。問題分析ツ
真の要求など獲得できるはずがないね。 問題の視覚化(モデル)と リーでもう少し業務のあるべき姿を考えてみ
改善プロセスによる活動 よう。
コタツ
システム開発者の論理
開発された要求
(システム要件) 業務担当者の論理
モデル
4
- 12. こたつ布団
• こたつ布団の効果
– 足を入れる
– 足を隠す
• 足を入れる
– 要求開発参加に対する覚悟
• 足を隠す
– フォーマルな世界だけではなく、インフォーマルな
世界もあわせて価値を作る
12
- 17. 全員コタツの外 Outside with Kotatsu
• 最悪のシナリオ
• ビジネスオーナー、
業務ユーザー、
エンジニアの間に壁がある。
(コタツに入ってない)
• 合意形成が行われない。
• 最初の企画案などをベースに、検証をせずに「間違
った」システムを「正しく」作ることになるが、結局使
われない。
• 無駄な投資に終わる。
17
- 20. 新しいアンチパターンの提言
• 寒い! Cold Pattern
• ミカンがない Without Mikan Pattern
• ミカンがマズい Bad Mikan Pattern
• 鍋奉行 Nabe-bugyo Pattern
• これはコタツではない Not Kotatsu Pattern
• 密約 Huddle Pattern
20
- 21. 寒い! Cold!
• 電気が切れてる
(熱源がない)
• 要求開発を進める為の
熱意(目的)が無い状態。
• または、全員が何をやっていいのかわからな
い。リーダーシップが不在である。
21
- 29. プラクティス
• 事前準備のプラクティス
– ステークホルダー分析
– GE式ワークアウトに学ぶ
– プレモデルの活用
• プロセス内のプラクティス
– ファシリテーション
– 非日常を演出する
• 皆さんのプラクティス
29
- 32. (2)ワークアウトに学ぶ
• 組織横断的チームによる変革プロセス
→要求開発と位置づけが類似している。
• 経営幹部によるイントロダクション
• 基本原則
– 聖域をつくらない
– 縄張り争いの禁止
– 非難はしない
– マネージャはその地位を悪用しない
– 愚痴の禁止
– 解決策に焦点を当てる
• グループワークについての様々なアイデア 32
- 33. (3)プレモデルの活用
• 戦略マップ、要求ツリー、概念モデルについて
事前情報と仮説のもとに、プレモデルを作成し
て要求開発に望む。
• ざっくりとモデリング 「ざくモデ」
• 要求開発の序盤にスピード感を出す。
• 参加者に、慣れるための時間を作る。
• 空中戦になりがちな序盤を早く終わらせ、地上
戦に持ち込む。
• 鍋奉行パターンに注意
33