前回の続きをちょっとだけ企業を選ぶ際のコツ。単価レンジなどにも気を付けたほうがいい。取引先にユーザ企業があったなら、その企業はプライムである可能性が高い。モデリング工程が進んでいくにつれて、具体的になっていく。要求獲得お客さんがどのようなシステムを欲しているのかを聞き出していく。この方法には次のようなものがある。対話ワークショップブレーンストーミング絵コンテロールプレイング(寸劇)プロトタイピングペルソナ(仮想人格を作って、その人にとって合うものなのかを考えていく)ユーザーストーリーマッピング(客の気持ちの動きをシミュレーション)しかし、これらの要求獲得にはいくつか問題がある。but...」問題よくよく見ると、ここおかしくない?ということが無限にできてしまう問題。慎重になるがゆえに、ミスがないようにするがために起こってしまう。解決策は、実際に試作版を使ってもらうこと。「未発見の遺跡」問題まだ見つけられていない要求があるかもしれないと感じてしまう問題。回してしまう精神と似ているかもしれない。解決策は、要求の範囲をあらかじめ決めておくこと。その範囲を超える要求は考えないようにすること。「ユーザと開発者は違う星に住んでいる」問題そのままの意味。完全な意思疎通は不可能だという問題。解決策は、できるだけ具体的に客とコミュニケーションすること。仕様定義システム開発において一番重要な「仕様」決めていく。聞き出した要求をもとに、開発側とお客さんの落としどころを決めていく。この落としどころのことを「スイートスポット」と呼ぶ*1。あいまいでもダメ、明確過ぎてもダメなので難しい。ここばかりは、人間が複数の観点から判断しなければならない。要求のブランコ「お客さんが要求するブランコ」を各観点から解釈していくとどうなるのか。こんなことをイラストで分かりやすく説明したもの。crossthebreeze.comこのサイトから画像をひぱってきます。これを見ると、「客が必要としていたもの」は「運用すべきもの」に似ていることが分かる。要求モデリングソフトウェアが持つべき機能を詳細化し、モデリングしていく。注意したいのは、設計モデリングとは異なるということ。ここで大事になってくるのが、「開発パラダイム」*2。ソフトウェア開発では、このパラダイムを統一しながら進めていかなければならない。この講義で扱うパラダイムは機能データ状態オブジェクトの4つ。モデリング」するもの。その構造は、データを入力・出力を受け取る外部エンティティ、入力されたデータを処理する複数のプロセスからなる。講義では、次のような業務を「寸劇」によって再現した。出力を外部エンティティ2が受け取る例えば、「ラムネ」という文字列が入力されたら、「ネムラ」→「ネンゴムンゴランゴ」→「ゴンラゴンムゴンネ」となり出力される。一回書くが、これはシステムではなく、「何をするのか」という業務をモデリングしている。HowではなくWhatを考える。これが要求開発の基本だからだ。*1:テニスでしか聞かない言葉だったので、何気に感動しました(個人の意見です)。野球のバットの芯のこともこう呼ぶそうですね。*2:パラダイムとは「ものの見方」のことを言う。»Searchマエカワ思い立ったら更新。忘れちゃダメなことをその日のうちに。Maekawa_studyはてなブログをはじめよう!maekawa_yoshimiki_1119さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。