問題の発見と設定

1. 問題の発見と設定
工藤 由美

2. 自己紹介
異業種から転職してきたIT３年目。
役職はSoS案件でビジネスアーキテクトで、一部PM、PdMの役割も兼務。
事業戦略といったシステムに依存しないレイヤーから品質を考慮することにこだわってる。
ビジネスサイドにソフトウェアアーキテクチャの思想をパクって引用。
2024/2/21

3. そもそも論
前提)
顧客が正確に己の要求を言語化なんてできていない。
言っているのは、あくまでも蒸留前の不純物だらけの
【要望】。
2024/2/21

4. 論点がないまま進むDX案件、、、
そもそも「この問題を解決するのがもっとも効果的であろう」という仮説をたてること
もなく、
システム開発をすることが目的と化したプロジェクト。
納期はたったの２、３か月ほど。
顧客は表面的な問題しか視えていない。
わが社も要求定義は苦手とている、、、、。
毎回のミーティングも定例化し、論点や前提の共有もなく暗黙化されたまま進む。
2024/2/21

5. そこで今年になってから取得
・ラテラルシンキング
・クリティカルシンキング
・サービスコンテキスト境界による、逆コンウェイ法則でのチーム設計
・TOC制約理論
・戦略思考
・推論の技法(帰納法、演繹法、アブダクション)
・論点思考(別名イシュードリブン)
・仮説思考 などなど
2024/2/21

6. UAF 視座の管理がしやすいFW
2024/2/21

7. 論点(固有問題領域)はどこに？
全ての問題に一斉に取り組み、なんだか大した効果も得られず、、、。
原因は、
問題の粒度に応じて選択と集中をしていなかったこと。
特に受託案件では、ToBeとAsIsとの乖離があり、かつ
それが他社では容易に解決できそうにないけど、
自社ではちょっと頑張れば解決できそうなものをチョイスすべき！ コアドメインになり得るか
ら。
2024/2/21

8. 要望からの要求定義
１人が述べる要望リストには互いに矛盾したものが混ざってる。
それらを帰納法と演繹法チェックで要求を炙りだす。
2024/2/21

9. 各視座の価値を定義する
今度は同じ視座の別の全く異なる視点のステークホルダー要求を
クリティカル思考を用いて炙りだす。(すでにそんな人がいたらラッキー)
そいつらの重複した共通の要求こそがその視座のステークホルダーにとっての価値
として定義する。
もしなかったら、さらに１段階抽象化してみる。
あとは各視座の人々の要求が目的手段で
階層因果関係になってればOK!
2024/2/21

10. ラテラルで前提スコープを見直す
下位の視座のステークホルダーの要求と
上位のステークホルダー要求が重ならないようなら、
上位の前提スコープをラテラルシンキングで見直す！！
2024/2/21

11. Whatツリー
キャッシュフローなどからボトルネック特定し、そこにのみ注力。(TOC制約理論から引用
した考え)
2024/2/21

12. Whyツリー(マクロミクロ両方で)
いきなり
売上＝顧客数×単価×購入頻度 てよくある公式にあてはめて分解
↑ナンセンス！！
まずは市場規模などといったマクロからみた原因分析。
いきなり内部環境視点のミクロでの分解では、売り出す市場の間違えな
ど
本質を見失う。
2024/2/21

13. Why分析(マクロ)
外部環境は自分達ではコントロールできないもの。
つまり、論点にはならない。
論点になるべきは自分たちでコントロール
できるような変数！
2024/2/21

14. Why分析(ミクロ)
内部環境、自分たちでコントロールできるような原因の特定。
市場が伸びてるのに顧客数が減少してるのと、
市場が低迷していて顧客数が減少では、
全く打つべき手が異なる。
構造化しておくことで、無駄な原因分析を
無くし、目に視えない原因→問題
のメカニズムを明らかにする。
(アブダクション)
これによってそのプロジェクト方針が決まる。
2024/2/21

15. 適時ステークホルダーマネジメント
による要求の監視と
動く論点の調査が重要。
内部プロダクト同士の力学の
相関関係とかをキャッシュフローなどか
ら明らかにしておく。
-コアドメインは時間経過とともに動く。
プロダクト同士に働く内力も、外部からの力学も時間と共に変化。