マエカワの備忘録的な何か

思い立ったが吉日

ソフトウェア工学 其の七 20171207

前回の続きをちょっとだけ

 企業を選ぶ際のコツ。「勤務地を見る」というのが前回出てきたが、そのほかにも

  • 取引先
  • 単価レンジ

などにも気を付けたほうがいい。取引先にユーザ企業があったなら、その企業はプライムである可能性が高い。また、単価レンジが80万円以上であればいいとも(企業の方も水増ししているので、提示してある金額から20%くらい差し引いて見る必要があるとも言っていた)。

要求開発

 要求開発の流れは次の通り。

  1. 要求獲得
  2. 仕様定義
  3. 要求モデリング

工程が進んでいくにつれて、具体的になっていく。

要求獲得

 お客さんがどのようなシステムを欲しているのかを聞き出していく。この方法には次のようなものがある。

  • 対話
  • ワークショップ
  • ブレーンストーミング
  • 絵コンテ
  • ロールプレイング(寸劇)
  • プロトタイピング
  • ペルソナ(仮想人格を作って、その人にとって合うものなのかを考えていく)
  • ユーザーストーリーマッピング(客の気持ちの動きをシミュレーション)

 しかし、これらの要求獲得にはいくつか問題がある。

「Yes, but...」問題

 よくよく見ると、ここおかしくない?ということが無限にできてしまう問題。慎重になるがゆえに、ミスがないようにするがために起こってしまう。
 解決策は、実際に試作版を使ってもらうこと。

「未発見の遺跡」問題

 まだ見つけられていない要求があるかもしれないと感じてしまう問題。ガチャを回してしまう精神と似ているかもしれない。
 解決策は、要求の範囲をあらかじめ決めておくこと。その範囲を超える要求は考えないようにすること。

「ユーザと開発者は違う星に住んでいる」問題

 そのままの意味。完全な意思疎通は不可能だという問題。
 解決策は、できるだけ具体的に客とコミュニケーションすること。

仕様定義

 システム開発において一番重要な「仕様」決めていく。聞き出した要求をもとに、開発側とお客さんの落としどころを決めていく。この落としどころのことを「スイートスポット」と呼ぶ*1。あいまいでもダメ、明確過ぎてもダメなので難しい。ここばかりは、人間が複数の観点から判断しなければならない。

要求のブランコ

 「お客さんが要求するブランコ」を各観点から解釈していくとどうなるのか。こんなことをイラストで分かりやすく説明したもの。
crossthebreeze.com
このサイトから画像をひぱってきます。
f:id:maekawa_yoshimiki_1119:20180201192343j:plain:h500
これを見ると、「客が必要としていたもの」は「運用すべきもの」に似ていることが分かる。

要求モデリング

 ソフトウェアが持つべき機能を詳細化し、モデリングしていく。注意したいのは、設計モデリングとは異なるということ。
 ここで大事になってくるのが、「開発パラダイム*2。ソフトウェア開発では、このパラダイムを統一しながら進めていかなければならない。この講義で扱うパラダイム

  • 機能
  • データ
  • 状態
  • オブジェクト

の4つ。最初は、機能とデータに注目した「構造化分析」から扱っていく。

構造化分析

 「業務をモデリング」するもの。その構造は、データを入力・出力を受け取る外部エンティティ、入力されたデータを処理する複数のプロセスからなる。講義では、次のような業務を「寸劇」によって再現した。

  1. 外部エンティティ1が文字列を入力
  2. 1番目のプロセスは文字列を逆にして次のプロセスへ渡す
  3. 2番目のプロセスは各文字の後ろに「ンゴ」をつけて次のプロセスへ
  4. 3番目のプロセスは渡された文字列を逆順にして出力
  5. 出力を外部エンティティ2が受け取る

 例えば、「ラムネ」という文字列が入力されたら、「ネムラ」→「ネンゴムンゴランゴ」→「ゴンラゴンムゴンネ」となり出力される。といった具合だ。もう一回書くが、これはシステムではなく、「何をするのか」という業務をモデリングしている。HowではなくWhatを考える。これが要求開発の基本だからだ。


*1:テニスでしか聞かない言葉だったので、何気に感動しました(個人の意見です)。野球のバットの芯のこともこう呼ぶそうですね。

*2:パラダイムとは「ものの見方」のことを言う。