ちょっとよむと、前の話で、ＤＯＡでコンテキストダイアグラムをつくれば、何でもいいように読めてしまうので、ちょっとつけたし。
ＥＡのように、全体をトップダウンで分析しようとして、同じようにＤＯＡにしても、オブジェクト指向にしても（ＥＡでもそうなんだけど）幅ひろくとってしまうと、いろんな仕事が関連してきてしまって、図も描ききれないし、にっちもさっちもいかなくなり、発散して、システムが崩壊してしまう。
数学を考えてもらえばわかるけど、問題をとくとき、まず具体例をいれていき、特殊例でとき、最終的に一般化したものをとくように、範囲を限定する必要がある。
その際、いままでは、内部的に分割していく方向だけを考えるけど、それでは、利用者がおいてきぼりになってしまうし、利用者の最適化もできない。
まず、外部の体系化、つまり、利用者を体系化して、そのなかで、自分の扱える範囲でやっていき、一通りできたら、さらに範囲を広げるというようにする。
たとえば、税金について考えてみると、いろんな切り口がある。届出、申告、納税などという切り口もあるし、移転したとき、毎年の作業、死んだときなどの切り口もある。
どんな切り口を選ぶかは、その会社なりシステムを作る人なり、経営者なりのセンスとなる。
で、その切り口を細分化して体系化する。
たとえば、申告なら、所得税、消費税、法人税など、で、さらに所得税は、サラリーマンが確定申告、事業所得のひとの確定申告、不動産所得のひと、年金の人、譲渡税があるとき。。。いろいろ細分化できる。
そして、自分が扱える細分化の範囲でまず考えてみる。
このとき、大きくないほうがいい。
たとえば、白色申告で、事業税があり、譲渡税がない場合の確定申告とか。
そうすると、外部からの入力は、申告書１表、２表、ＰＬ相当、原始証憑（源泉など）っていうことになる（たぶん。。ちがうかも ＾＾；）。
これを書くのが、コンテキストダイアグラムになる。
で、ここから、その申告書を受け取ったら、どこの課にいき。。。というふうに、内部的にどんどん細かくしていく。
で、これで、一通りの流れができたら、その次、サラリーマン、その次不動産所得、そのつぎ、公的年金その次、譲渡税（３表あり）などというふうに、範囲を広げていく。
これを繰り返し、目的の開発システムの範囲までひろげていくという考え方だ。
つまり、利用者を体系化して、手に追える範囲に切り出し最適化したあと、トップダウンで考えていく必要がある。
この手法について、今日は休日なので、もっとみんなが見ている平日に、利用者指向として、もう少しまとめて書いてみたいと思う。
アクセス
トータル
ランキング
