開発の初めから順番に書いていってみる その１７：要求分析（３）事前調査。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　現在、要求分析フェーズに入っています。
　その手順としては、

・ヒアリング前の準備をする
・ヒアリングする
・ヒアリング内容をまとめる
・要求仕様書にまとめる

　とあるわけですが、今回は、「ヒアリング前の準備をする」という話です。

---

■ヒアリング前の準備をする（事前準備）

　すでに、RFPは受け取っています。
　また、ここまで来る前に、事前に帳票などを受け取っている場合が多いです。
　少なくとも会社の名前は分かってて、業種はわかってて、たいてい、何をシステム化するかも漠然と分かっています。

　っていうことは、これらの資料から、その会社において、今回のシステムに関係する人や会社等の組織（すべてでなくてもいい、この人は出てきそうという人や会社等の組織）、モノやサービスについては、わかります。

　できれば、その業界の標準フォーマット（統一伝票とか）や、規制などもわかるはずです。これも調べておいたほうがいいです（その伝票を使うかどうかは関係ないです。標準的な方法を知るために調べます）

　それらのまとめ方に関しては、
必要な業務知識とは？
http://blog.goo.ne.jp/xmldtp/e/df8025d175eb65e943956ac59f33b1ea
に書きました。

ま、事前調査ってことですね。

---

■質問する内容をまとめる？

　ここで、「質問する内容をまとめたほうがいい」という意見と、「いや、相手にいいたいように言わせるべきだ。そもそも、事前調査は、絶対すべきではない、先入観をもってしまい、正しく聞きだすことが不可能になる！」という意見があります。

　ま、どっちをとるかは、その人次第です。

　今の風潮では。。あんまり事前調査はしない気がする。。

　ただ、ヒアリングできない場合、調査紙を使うしかない場合は、質問する内容をまとめざるを得ないですよね。

---

ということで、ここで書く話は、必要な業務知識とは？に大体書いているので、今回はこのくらいにして、次回、「ヒアリング」の話しに行きましょう。

要求仕様がまとまらない→見切り発車でプログラム→アジャイル→デスマーチへ

　昨日、アジャイルで開発すると品質は高くなるのか？という話を書いた。

　そこで書いた話は、

・仕様がまとまっていない段階でも、アジャイルでは開発に入れるが、
・そうすると、度重なる仕様変更がおこり、
・プログラムが崩壊し、
・デスマーチ化する

という話だった。
　で、今日は、その「仕様がまとまっていない段階で」どうして、開発に入らないといけないか？っていう話です。

---

■要求仕様がまとめられないから

　この理由は、一言で言うと、

　「要求仕様がまとめられないから」

　この結果、要求仕様の段階で、結構月日がたってしまう。
　そーすると、後工程が遅れてしまうので、最悪の「できたところからやろう」という発想になる（＝できないところはいつまでたってもできない。それをやるとき、大幅仕様変更になり、無駄になるかもしれないけど、ともかく、やってしまう）。

　そのため、わかんないところをブラックボックス化して開発してしまう（とりあえず、クラスとメソッドを作って、ダミーを返す）。もう、要求仕様の段階で時間が足りないのだから、テストも、単体は省略となる（というか、アジャイルでやっていて、とくにJUnitでやっている場合、青くなっているのでコーディング完了と判断したわけだから、その時点で単体テスト完といわれても、まあ、間違いじゃない）。

　で、結合に入るが。。
　そもそも、要求仕様がまとまらないのであれば、要求仕様に矛盾があって当たり前で、そうすると、結合でその矛盾は露呈し。。仕様変更となる。。そのうち仕様変更が何回もおこり、崩壊していく。。。

　つまり、要求仕様がまとまらず、開発期間を押してくるので、見切り発車せざるを得なくなるが、それにアジャイルは向いているということです。でも、要求仕様がまとまってないんだから。。。品質は低いですよね。

　なお、開発期間を押さないケースでも、要求仕様をあいまいに定義するという場合もあります。この場合も、アジャイルは向いているということです。でも、要求仕様があいまいだから。。。品質は低いですよね。

---

■要求仕様がまとまらない理由

　では、問題は、要求仕様がまとまらない理由です。
　で、この前書いたとおり、もし、完璧なヒアリングができているのであれば、その後工程というのは、もはや、述語をどうする、名詞句をどうするというレベルで、ER、DFDないしはUMLの図やクラスに展開できます。

　ってことは、完璧なヒアリング（にかぎらず、業務の情報収集）ができないってことです。あともうひとつのケースがあって、無茶なことを要求するって言う場合もあります。そのフレームワークでそれはできないってっていうかんじ。。

まとめると、こんなかんじ

（A)無茶な要求
　　→そもそも、できないってことを営業が気づかない(気づいていてもあおる）
　　　新しい技術で本当はできるかどうかわからない(実はだれも成功してない）
　　　そのSE、営業自体、本当は知識がない（会社や業界には成功事例はある）
　　　可能だが、期間的、予算的に無理！
　　　　：

（B)完璧な情報収集(ヒアリング、帳票分析ふくむ）ができない（業務も要望も）
　　　B-1、SEに、情報が伝わらない、情報収集できない
　　　　　→ヒアリングで言ってる内容をSEが理解できない
　　　　　　関連業務などをSEが知らない

　　　B-2、会社が業務を表現できない
　　　　　→業務は、矛盾なく、滞りなくできているが、それを言葉で的確に
　　　　　　表現できない。要望も、的確に表現できない

　　　B-3、会社自体、本当は業務をちゃんと行ってない
　　　　　→適当なローカルルールや臨機応変という名の恣意的な判断で
　　　　　　どうにかこうにか回っているので、業務自体、決まったやり方がない
　　　　　→新規事業で実は、だれもやったことはない。
　　　　　→改善案なのだが、それでできるかどうかわからない。

　この場合、B-2,B-3の場合、誰がやっても、ユーザー自体が言葉にできないのだから、それをヒアリングしても、要件はまとまらない。
　で、会社の業務スピードが上がり、十分な引継ぎもできず、専門外でもやらなければならない昨今、ユーザー企業は、B-2,B-3のケースに陥っているケースが多いと思う。

---

■もはや業務すべてを言語化できない

　つまり、ユーザーは「もはや業務すべてを言語化できない」状態に陥っている。
　したがって、SEのほうで、業務をみきって、まとめる力がないと、要件はいつまでたってもまとまらない。
　でも、SE自体も業務知識を軽視し、UMLなどの技術論に向かう傾向にある。
　ここで、UMLをどんなにやっても、ユーザーが、「業務すべてを言語化できない」のだから、システムには仕様漏れがでる。
　
結果として
ユーザーは「もはや業務すべてを言語化できない」
　　　　↓
SEも、業務知識は軽視しているので、業務をみきって、まとめる力はない。
　　　　↓
その結果、言語化されない仕様漏れ、
　　　　　言語化しなかったことによる論理矛盾や勘違いが生まれ
　　　　↓
それを見切り発車すると
　　　　↓
どっかで矛盾が発覚し
　　　　↓
仕様変更となり（仕様変更が続発し）
　　　　↓
そのうち、プログラムが崩壊し、単体レベルのバグが多発してきて
　　　　↓
システムが崩壊し
　　　　↓
デスマーチ化する

　っていう構図になっていると思う。

---

■つーことは

　すんげー単純な話、各業界の業務を標準化し、明確化(言語化）し
　自社はどこが違うかだけを明示すればいいようにすればいいんだよね。

　そのためには、いままでの技術中心から、業界知識中心(中心までしなくていいけど、多少重視）に方向転換すればいいんだけど。。

　それをしてないってこと。。

必要な業務知識とは？

　最近のブログの中で、業務知識が、要求仕様の品質に左右し、要求仕様の品質（仕様漏れや勘違いの少なさ）が、開発全体の品質に影響するということ、そして、現在は、この業務知識を重視しない（形式化されてない割には、形式化しようという研究も少ない）ため、要求仕様の品質が低く、仕様漏れや勘違いが多く、それがデスマーチを招いていると書いてきた。

　で、ここで問題になるのは、「じゃあ、業務知識って？どんなのがあればいいの？」ってことになる。これを形式化して、標準的な業務知識というのを定めないと、これから開発しようとしているシステムと比較できないので、あんまり、効果的でない。

　ってことで、必要な業務知識の枠組みを形式化してみよう

---

■まず、登場人物

　はじめに抑えたいのは、その業界の業務において、どのような登場人物が現れるのかということだ。人物といっても、ヒトとは限らない。会社や組織っていうこともある。

　たとえば、訪問介護業界なら、介護される人と、介護するヘルパーさん、その内容を決めるケアマネージャーは、すぐ出てくる（あとで、国保連とか、お金を払う人とかも登場する）。

---

■そして、そこに流れるモノ

　そのつぎに、出てくるのは、人がやり取りする、モノについて。
　これは、販売する商品や製品、サービス、製作する部品はもちろん、そこに行き交う書類や電子媒体も含まれる。たとえば、EDIなどでネット上に流れるデータやXMLなども含まれる。

　訪問介護業界なら、ヘルパーさんが行うサービスはもちろんだが、ケアマネージャーが作成するケアプラン、国保連に送る伝送データなどもはいる。

---

■そして、カネ

　そして、お金。これは、キャッシュ、現金の場合もあるが、最近は集金代行やクレジットカードなどもある。この集金代行やカードの知識は、どんな業界でも使えるので、基本的に覚えておくべきっていうか、エンティティとそこで行われる業務内容、また伝送データや書類（新規のときに送るもの）などは、ソフト会社で（いや、ソフト業界で。。中小企業庁あたりで？？）まとめておいたほうがいい気がする。。

　訪問介護の場合も、集金の問題はある。

---

■これらが、エンティティとなる

　そして、これら、ヒト、モノ、カネはエンティティとなる。

　とくに、業界標準の伝送データがある場合、こういうエンティティを必要とするという制約がでてくるので、そこは、あらかじめ抑えておく必要がある。
（伝送データを帳票分析の手法で分析すれば、エンティティは出てくる）。

---

■エンティティの必要な属性も抑えておく
　そして、業界標準の伝送データがある場合は、エンティティに必要な属性もきまってくる（その属性がないと伝送できない）。それらは、抑えておく。

---

■業界に共通した手順があれば、それも抑えておく

　あと、手順について、標準的なというか、不可欠な手順があればおさえておく。

　訪問介護の場合、

１．ケアマネージャーがケアプランを作成する

２．ヘルパーを割り当てる

３．ヘルパーが介護する

４．介護した内容を集計して

５．国保連(公費分）とお金を払うヒト（自費分）を請求する
　　→お金を払うヒト＝介護されるヒトではない。
　　　認知症で禁治産者は？

６．国保連からおかねもらう

７．自費分のお金をもらう。

という手順はかならずある。このやり方が、訪問介護の事業所によって、各種バリエーションがあったり、この間に、各社ごとに、いろんなことをしたりする。その内容をヒアリングすることになる（上記のプロセスにおいて、入出力は決まっている。それは業界知識としてあらかじめ分析しておくべき。ただし、ここでは、省略する）

　なお、訪問介護は、サービスを提供するので、サービス業の側面もある。
　そこで、サービス業の業務である、「クレーム処理」っていうのも、当然ある。
　これはこれで、標準的手法を分析しておく必要がある。

　また、訪問介護の事業所は、会社であり、ヘルパーは従業員である。
　会社は平均的な会社業務である「会計処理」が存在し、従業員には「労務管理」が存在する（給与、採用などなど）。これも、標準的手法を分析しておく必要がある。

　標準的手法とは、上記のヒト・モノ・カネのエンティティ分析及び標準業務、あと、後述する関連法規をさす。

---

■関連法規なども、抑えておく必要がある

　そして、関連法規。
　たとえば、介護保険は、何年ごとに大きな見直しがあり、小さい見直しは何年ごとにあるかなど、業界関連法規は抑えておく必要がある。

---

■こんなことで、ERと、基本的プロセス、基本用語はまとめておいたほうがいい

　そーすると、エンティティとその関係（属性ふくむ）、基本プロセス（入出力も含む）と、基本用語、共通的な帳票（小売なら統一伝票）、データ（EDIデータや国保連の伝送データ）などは、まとめておいたほうがいい。

　ちょっと書いたけど、こーいうの、中小企業の場合はたいへんだから、診断士の研究会あたりでまとめて、それを中小企業に対してセミナーみたいな形で公開して、そーしたら、診断士の更新研修の点数になるとかするべきだと思うんですけどお。。。

　中小企業庁さまあ。。