udon's blog

思いついたことを、思いついた時に。忘れないように。

Let's よーきゅーかいはつ!

言葉だけは知ってたんですが、中身は全く知りませんでした。

7月11日 要求開発アライアンス西日本勉強会#19(大阪府)

ほんとにまるっきり丸腰でしたが、まぁいつものことですね!

◯要求分析ツリー
今回はワークがメインとのことで、説明もそこそこにワークに突入。
・・・えっと、何も知らんのですが、要求分析ツリーとうものを作るとのこと。

一応こくちーずに参考URLとかあったので事前にちらっと見たりはしてみたのですが

要求開発アライアンスのビジネス・モデリング道場 - 「要求分析ツリー」を使って要求の構造をとらえる:ITpro

これぱっと見て理解できる人おる?!

簡単に言うと、

  • 一番左に「問題点」を
  • 一番右に「解決策」を
  • その間を論理的につないでいく

ということらしいです。
ふむふむ。発想のブレークダウンを見える化するわけですね。

◯お題
関西の要求開発アライアンスをもっと広めるにはどうするか?

全く参加していない勉強会について話すのは、結構難しかったです。
とりあえず「問題点」は、いくつか出せたのですが、そこから先がつながらない。。。

問題点の出し方は

  • hogeだからfooできない

と出して行くらしいのですが、これがなんとも。
出した内容が「手段」なのか「目的」なのか。

このあたりって、いわゆるインセプションデッキにも近いものがあったりするかなと思ったのですが、あちらの様に「穴埋め」的な枠が存在するといいかもと思いました。

やっぱり「言い方」って大事だなと。「〜する」とかって言うと手段になるしと。

◯感想
ワークの間ただひたすら「むずいわ〜」でした。言葉が出てこない。
しかも途中から話が脱線してしまって、結局何が解決したい問題だったのかを見失う始末 orz

やっぱり最初に「ゴール」を明確にしておくべきだったと反省。。。

あと「ゴール記述書」というのがあるらしいですが、これってエレベーターピッチっていうか、インセプションデッキのテーマにすごく近いなと感じました。

後気になったのは

  • 「要求開発」して出したアウトプットは誰が見るのか?

と、

でした。懇親会に行けなかったので講師の方には聞けませんでしたが。。。

誰が見るかについては、「マネージャーとお客さんだけ見てる」なんてダメですよね、たぶん。
帰りに話しをチラッと聞くと、要求開発には「こたつモデル」という概念があるそうで。やっぱりプロジェクトに関わる人みんなが近いところでちゃんとコミュニケーションとって、っては似た発想を持ってるみたいです。よかったよかった。

悪いウォータフォール・・・。「要求さえちゃんと固めて出せればOKさ!」な奴。。。
もちろん「本当にちゃんと出せれば」いいんですよ、えぇ。

ただ「どっちが正しい」とかってのも無いわけなので、これからはこの辺の分野も勉強したいですね。

あとはTOCとか。