前に、結局、これだけ聞き出せば、業務分析は、DOAでもオブジェクト指向でも落とせる。。ハズ(^^;) っていうところで、ヒアリングでこれだけ聞き出せばいいはず!?というのを出した。
それは結局まとめると、
●いつ
作業のタイミングで、「時間」、「順番」、「条件」のきまりを聞く
・どこで
作業を行う場所。きけたら。
●だれが
作業を行う人、担当者
●なにを
作業に対する入出力
・(なぜ)
聞き出せない場合はいい。わからないかも
●どのように
作業内容そのもの、作業手順
(下位の作業をつかって、手順を表現する。
最下位の作業は、すでに明白な作業となる)
このうち、●のものが、重要で、ここで書いたシートで、それらはまとめられることも示した。
しかし、問題は、これらの作業に矛盾がなく、整合性が取れていないといけない。
EAでもいっている。資料全体を整合性をもって描くことが重要であると(斜体はリンク先より引用)。。。
では、整合性をとるとは、どういうことかについて、今日は書いてみたい。
■一般的に、業務に整合性があるとは、どういう状態をさすか
一般的に、業務に整合性があるというのは、ビジネスモデルの「絵が描ける」こと
だと思うんですけど、じゃあ、その「絵が描ける」というのは、どういうことか?
というと、こんなポイントになるんじゃないかなあと思うんです。
(1)各業務における
・モノの流れと
・お金の流れと
・情報(技術、知識も含む)の流れが
矛盾がなくて(*)、
(2)各業務を行う人(担当者、もちろんロボット、コンピューターのモノでもOK)が、
ちゃんと存在すること。
→ここで、「だれが」
そして、(*)の矛盾がないというのは、
・業務を行うにあたり、必要な入力が、タイミング的にすでに存在し、業務に投入できること
→ここで、「いつ」と「なにを」の入力
・業務を行えば、その出力が作り出せること
→ここで、「なにを」の出力
というふうに業務(「どのように」)が配置されていることをさします。
ということで、●をつけたものが、全部話の中にでてきますが、
ちょっと、これについて、具体的に説明します。
■業務を行うにあたり、必要な入力が、タイミング的にすでに存在し、業務に投入できること
これを、モノと、お金と、情報の3つの観点からかんがえないといけません。
モノとお金が対応しないと、まず、ビジネスとしてなりたちません。
で、それを行う情報がないと、ビジネスとして、継続的に行っていくのに問題があります。
知ってる人はできるけど、知らないとできないという場当たり的になります。
そうすると、システム化できません。
なので、この3つが必要になります。
ただし、業務によっては、お金のやり取りは一切ないっていうこともあります。
モノのやり取りは一切ないっていうこともあります(ネット証券の株取引とか)。
でも、情報のやり取りは、たいていあります。なかったら、システム化しなくていいので。。
で、システム設計の場合は、とりあえず、情報の流れだけ追っていけば、いいと思います。
ビジネスを構築する場合は、全部必要です。
で、それぞれの矛盾について説明すると、
お金におけるここでの矛盾って言うのは、たとえば、14日に支払い、15日に入金があるという場合。。。14日にはお金がない。。支払えないジャン(>_<!)とかいうやつ。
モノにおける矛盾は、組立作業なのに、部品はないっていうようなとき。
情報における矛盾って言うのは、その人は知らないじゃん!っていうような話。
たとえば、バグがあったら、バグ票にかいて、関係者に渡しますというとき、
「関係者ってだれ?どこにそんな情報があるの?」
「マネージャーが関係者を判断します」
「じゃあ、マネージャーは、関係者が分かるってこと」
「はい」
「COBOLしか知らなくて、どんなシステムだか中身もわかんないのに、
バグ票にはフリーズしたとしか書いてなくて、問題点も書いてないのに、
どうして、システムのバグ、つまり、問題点に関係する人がわかるの??」
「・・・・」
っていうようなケース。
ただ、これはビジネスモデル上の矛盾であり、システム開発においては、
関係者がバグ票に記入されていますといえば、そこに情報があるので、
それでよしとしちゃいます(本当は、問題ありありだけど、システム開発の人は
そこまで面倒はみれん)
■業務を行えば、その出力が作り出せること
入力から、ある処理をおこなって、出力内容が導きさせることです。
ここでの矛盾のひとつは、情報が欠落していて、出力できないって言うような話。
5年分のデータを比較します。でも保存してるデータは3年分ですとか、
Aさんが、この書類を作成します。
でも、Aさんは新人で、引継ぎ作業がしっかりされなかったので、
この書類の作り方を知りません(どーすんだよ(^^;)
とかいうのが、これにあたります。
あとほかに、実現不可能というのもあります。
入力:ゾウ、家庭用冷蔵庫
出力:家庭用冷蔵庫(ゾウが入った状態)
業務内容:家庭用冷蔵庫にゾウを押し込む
むり、絶対無理、実現不可能(^^;)みたいな。。。
■各業務を行う人が、ちゃんと存在すること。
で、業務がでてきて、流れても、その業務をやる人が存在し、実現可能でなくてはいけません。
ここでの矛盾は、業務をやる人が居ない
「トイレをきれいにするには、毎日掃除する人がいれば、いいと思います。」
「さんせー」
「で、あなたトイレ掃除する」
「やだ」
「あなたは」
「やだ」
「ところで、そーいうあんたは」
「やだ」
・・・みんなやだ・・・じゃあ、トイレは(^^;)
みたいなやつ。
もうひとつの矛盾は、その人がその場に存在し得ない
Aさんは、大阪で、16日15:00書類整理をします。
Aさんは、東京で、16日16:00検品をします
Aさんは、博多で、16日17:00会議に出席しています。
むり、絶対無理。それぞれで考えたら、Aさんが行うって言うことで、
成立するんだけど、で、時間も重ならないんだけど、
実際には、Aさんは、どらえもんではないので、どこでもドアはないから、
存在できないって言う話。。。
(ホームヘルパーの配置などでやってしまいます。
午前中と午後に分けているのですが、そこから、そこへは、その時間では
移動できない(奈良県で山を越えないといけないみたいな)っていう話)
これをチェックするのに、(システム開発の立場ではなく)
コンサルタントとして、お客さんに説明するには、モノをつかってロールプレイ
しますね。
ジュースをもってきて、まず、これを、Aさんとする、
コップをもってきて、これを、Bさんとする、
消しゴムをもってきて、これを、Cさんとする、
まず、Aさん(ジュース)から、Cさん(消しゴム)にお金(かみきれに適当に書いて)を渡すと、
で、そーすると、このもの(といってジュースのキャップをとりだし)が
もらえると。。
なんていうかんじ。
まあ、実際には、これが、ユースケースシナリオになってきて、
お客さんにはロールプレイで見せながら話すっていうことになるんでしょうなあ。。