まえに、トップダウンアプローチとボトムアップアプローチによる違いというのを書きました。
結局、そこでの結論は、
・ボトムアップアプローチの場合、帳票分析やヒアリングから、データを起こしていく、ということは、帳票に書いてあることがすべてでなかったり、ヒアリングで間違ったことを聞くと、そのまま、間違いや漏れがあるまま進んでしまう。
・一方、トップダウンアプローチで、とくにある程度のその業界での標準的なシステムの開発方法を知っていると、標準とその会社の差の分を埋めればいい。なので、逆に、「ここはどうなの？」と、ヒアリングのときに確認できる。間違っているときに差が見つけやすい
ということになります。
このことは、データだけでなく、業務プロセスについてもいえます。
業界的にかならずやる手順や慣行がある場合、その手順を知っているのと知らないのでは、大きな問題が出ることがあります。
そして、データ構造でも、手続きでもそうなのですが、ユーザーが知らないテクニックというのが存在するときがあります。
たとえば、介護業界において、訪問介護で言うと（いや、他の介護関係でもあるんですけど）、サービスコードというのがあります
これ（PDF)http://www.kokuhoren-kagoshima.or.jp/kokuho09/service_code/normal/11.pdf
この、合計単位数の出し方ですが、多分、ユーザーに聞くと、計算方法を教えてくれます。
でも、実はこれ、左側のサービス内容略称と、合計単位数のテーブルを作ったほうが、システム的にうまくいきます（というのは、ユーザーは知りません）
理由は、じつはこれ、２年毎くらいに見直されて変わっちゃうんです。
あと、四捨五入の問題とか、規定時間以上の介護の場合とか、計算式にしてると、いろいろな条件があり、さらに、見直しごとにそこのエンジンを変えないといけなくなるので、それは面倒。。。だったら、サービス内容略称と、合計単位数のテーブルをもったほうが早いというわけです。
手続きでいうと、国保連というところに、介護保険分のお金を請求するんですけど、その請求の際に、返戻(データがおかしいので戻ってくる）と月遅れ（集計が月遅れのデータ）とかが、めんどっちい。２つ重なると（＞＿＜！）
でも、意識しておかないと、あとでたいへんなのよね。
でも、ヒアリングのときに返戻なんてはじめに言う人いないしい。。
(初めに言われても、意味通じない）
聞きもれたりしたら、たいへんたいへん。。
ただ、国保連の請求なんていうのは、業界的に決まっているわけで、その作り方を知っていれば（仕様書はここ）あとは、その介護会社ごとのバリエーションなわけ（訪問介護と施設をやっていて、どのように入力するかとか。。。）ですよ。
だから業界標準を知っていれば、こちらから、業界標準と比べて（業界の標準的なパッケージソフトというのもあります）、今回の開発では、どこで何をやって欲しいのかというカスタマイズのポイントを聞きだすことができるってわけです。で、そうすると、話は早いし、正確に要望を聞き出せます。問題点も分かるし、テストのタイミング（ベンダーテストをやってるときに変えたほうがいい）もわかるし。。。
これ、まったく知らない人が帳票分析すると（とくに、国保連のインターフェースがここにあるということをしらず、国保連のソフトの画面や帳票から解析すると）結構たいへんなことになる。。。って、まあ、そんなやつが、介護のほうに手を出すとも思えんが。。
とくに、じゃあ、訪問介護の実績を入力して、国保連請求と、集金に分けたシステムを作りたいといった場合、代金回収業者のことを知らないと、途方にくれてしまいます。
っていうことで、とくに、業界で、データのやり取りをするような場合、（たとえば、統一伝票とかの帳票もふくまれる）、
その基本的なデータ構造と、
必要となるエンティティ、
そのエンティティの属性値を知っていて、
標準的なシステムの作り方(業務とそれをプログラムに落とす落とし方）
を知っているのと知らないのとでは、要求分析やシステム設計の段階で差が出ると思います。まったく知らない状態で、ユーザーさんに全部を語ってもらうって言うのは無理だし、そもそも、ユーザーさんも知らないことがあるし。。
具体的には、仕様漏れ(返戻を想定外にしてしまったり）や、勘違い（サービスポイントの身体が９を超えた場合の処理）などが、頻発しちゃいます。仕様変更です（＞＿＜！）
で、この差がどう、開発全体に響いてくるか。。。っていうことを、またこんど、書きたいと思いまーす(今回はここまで）。
アクセス
トータル
ランキング
