よりよい要件定義やソフトウェア設計をするには

よりよい要件定義やソフトウェア設計をするには

　今回はこのテーマでは設計思想やアーキテクチャ、仕様の落とし込み、
戦略や実装テクニック・デザインパターンなどといったそういった話ではなく、
アプローチの仕方について書いていきたいと思います。


要件定義とは
　顧客から世にない新しいアイデアを実現したいと要望が来たとき、
既存技術に精通している人がヒアリングして実現可能なモデルに落とし込んで文書化、そこから設計・実装へとプロセスが変化してしていくのですが
最初の仕様を落とし込む段階でホント人様々なアプローチがあって製品の良し悪しに決定的な差が出てきます。
なぜ解釈の違いが生まれるのか、同じアイデアなのに差が出るのかについて触れていきます。


それはなぜなのかを一言でいうと

　顧客は技術について詳しくない

という事に尽きると思います。


ではどういった事をしたらよいのかというと

・ゴールを決める

・ヒアリングした内容をそのまま文書化してアイデアをまとめる事で、顧客が思い描いているアイデアと実装のミスマッチを防ぐ。

・アイデアと既存技術のマッチングを行い、システムの全貌を描き概算する。


この3点をしっかり網羅しているかが重要であり、実装よりの話は出さない事。
実装よりの話を出してしまうと、それが足かせ（依存関係）が発生してどんどんこじれていくこと間違いなしです。
ということでまずはざっくり、実績ある技術の組み合わせ、次にやったことのないチャレンジ課題に分けて技術に値段をつけていきます。
ここを失敗すると、アイデアというものはナマモノなので時間が経つにつれて変化していきます。
ゴールを決めた上で課題を洗い出しておくとやりたい事が明確になり、それが目的となって簡単には仕様変更は発生しなくなります。


・目的と手段
　よくあるのが手段が目的化してしまう事です。
Aという課題を解決するのにBを使う。

これが、BをしないとAという課題が解決しない。

という具合になる事です。

より具体的な例を出すと、

画像解析で猫を認識したいので、ディープラーニングを使う。

これが、ディープラーニングを使わないと画像解析で猫が認識できない。

というような感じです。


「画像解析で猫を認識する」という事を解決するにはいろんな手段があります。

そのいろんな手段がある中でディープラーニングを選択するのは良いことです。

ですが、最初からディープラーニングを使う前提で「画像解析で猫を認識する」というのは

手段が目的化してしまったと言えます。

解決策はより簡単でシンプルなものを選べばいいところを茨の道を進んでしまったことで

結果的に失敗する可能性もでてきますので。

このケースをモデル化（言い換えれば）これも１：Nの関係といえますね。目的は１つのみ（ゴール）で、そこに様々な手段がN個ぶら下がっている状態です。

つまり目的を達成するには、沢山の手段を知っておかなくてはいけないということです。


もっと概念的な他の例でいえば

　年々国の借金は膨らんでいく問題があって、解決手段として

　「借金を減らす」ために「消費税を上げる」

これは目的と手段。


しかし手段が目的になると

　「消費税を上げる」が目的になってしまいますので、

「消費税を上げる」ために「国の借金を増やす」という手段も起こりえます。

いやはや、手段が目的化するというのは恐ろしいですね。


目的と手段の適正に使われない事がどのくらい恐ろしいことか

この事を書きたいと思い、今回はこのテーマを掲げてみました。