フローを整理する前に
業務フローを整理する際は関係する多くの人々にインタビューすることになると思いますが、インタビュー結果を上手に反映させても上手くいかないことも多いのです。理由を考えてみると
- 担当者同士は現場だけで通じる符丁で会話をする。部署が違うと言葉の意味が違うことがよくある。
- 現場の担当者にとってあまりにも普通だと思っていることは話さない。あるいは頭の中にあるフローから抜けている。
- 現場の担当者は次の現場の業務内容を理解していないことが多いので流れがスムーズではない。場合によっては二度手間になっていることも多い。
- データベースで何ができるのか理解できないため、過度の期待を持ってしまう。
などでしょうか。
請求書や納品書などのように一般的で業務内容を推察しやすいものはいいのですが、生産現場の工程管理などでは開発する側にはその業務内容は分からないことだらけで何を質問していいのかもわかりません。インタビューをしてはフローを整理し、考えられる問題点を洗い出し、再度インタビューをするしかありません。口頭だけのやり取りではなく、担当者に業務内容とフローを紙に書いてもらうことも必要だと思います。同じ業務内容でも人によってやり方が異なっていることもよくあります。
用語を統一する
用語の統一と書きましたが、データベースの用語ではありません。現場で使われている符丁や言葉のことです。
前職の学校で実習管理システムを開発していた時、依頼状という言葉が出てきました。ある担当者は依頼状の発送は1回と言い、別の担当者は1回のことも2回のこともあると言っていました。依頼状というのはAさんという学生の実習を依頼しますというものだと思っていたのですが、2回と答えた担当者はそれ以外に来年度は何人の学生を受け入れてもらえるかという受け入れ打診も含まれていました。担当者にとっては依頼状は依頼状なのです。
印刷会社で働いていた頃にも、見積書にも受注前に出すものと納品後に出すものがあり驚いてしまいました。納品後に発注者が見積書を要求するのはグレーなのですが、、、
他にも似たような事例はたくさんあります。
私が学んだことは自分の常識で判断しないということ。私の常識は世間の非常識、会社の常識は別の会社の非常識ということです。
用語の問題点を探ることは難しいことです。同じ言葉を使う担当者たちが何を言い表そうとしているのか複数の担当者の共通点と相違点から探り、具体的な事例で説明して確認するしかありまん。些細なことでも執着して調べます。
違いがはっきりとしたら、それぞれの内容に異なる用語を使うようにします。これはコミュニケーションを取るために担当者にも徹底してもらいます。
2回の依頼状は受入打診書、実習依頼状に分けることにしました。単に打診書と依頼状と略しても混同しないような用語にします。
インタビューを繰り返す
「現場の担当者にとってあまりにも普通のことは話さない。あるいは頭の中にあるフローから抜けている」と書きましたが、インタビューを繰り返していくしかありません。最初のインタビューをまとめ、整理してフローが途切れているところを探します。そして、途切れているところはどう処理されているのか想像してみます。再度インタビューするわけですが、自分で想像したことを「こうしているのではないですか？」と質問してはいけません。相手が思考しなくなるからです。フローに沿って「こうやったら、こうなりますよね」「次にこうやったら、どうなるのですか？」という具合に質問していきます。問い詰める感じにならないように注意します。「普通に考えてやっているよ」とか「いつも通りにやっているよ」という答えが返ってきたら、想像した処理方法を「こう判断してやっているのではないですか？それともこう判断していませんか？」という風に質問を投げかけます。
答えが返ってきたら紙に書いたフローに書き足し、相手に見せながら「これでいいですか？」と確認してもらいます。
他の担当者にも同じような質問をしてフローをまとめていきます。
業務内容の整理統合、追加
「現場の担当者は次の現場の業務内容を理解していないことが多いので流れがスムーズではない。場合によっては二度手間になっていることも多い。」と書きました。業務全般を管理する統括者がいれば話が早いと思いますが、統括者が全ての業務を理解していないこともあります。業務の統合整理や追加は開発者側からの提案になると思います。特に業務を追加する場合はその理由をわかりやすく説明する必要があります。
小さな効果でも結果を早く出す
現場では何がどう便利になるのかよく分からないので、夢物語のような効果を期待するものです。が、基本的なデータ入力が面倒臭くて、便利さを実感できないでいると慣れている以前の方法に戻ろうとするものです。それまでは住所の入力にしても都道府県名は省いていたり、名前のフリガナがひらがなだったりカタカナだったり、実習先の名称が略称だったり、今まで気にしていなかったこともデータベースへの入力は意外と厳格なものです。頭の中にしまっておけば問題なかったことも入力しなければならないかもしれません。情報の共有化というやつです。
でも、これは避けて通れないことです。住所の入力も一度入力すれば、それで済みます。過去のファイルから目指す住所を探し出してコピペーストするよりスピーディーになるのがデータベースです。
便利さを実感し始めると使い続けてもらえますし、より効率良くするためのフィードバックも出てきます。最初のインタビューでは出なかった要望も出てきます。そしてデータベースはドンドン大きくなっています。
最初から壮大なシステムを完成させようとせず、最低限の根幹で効果がある部分から稼働させ、骨を作り、徐々に肉をつけるのが良いのではないでしょうか。
FileMakerに向く開発方法だと思います。
ただ、データベースを単純に拡張させると廊下で迷子になるような増築増築の温泉宿になってしまいます。完成した時のデータベースの規模とテーブルという要素を関連づける概念図、拡張方法などは持っておく必要があります。
視点を変えてフローを考える
フローというものを考える時、始めから順を追ってどのような結果を出すかと考えると思います。しかし、人間の思考方法には決まりがありません。期待する結果から遡って何が必要かを考えることもできますし、根幹の部分から出来ることを考えてみるということもできます。フローを順番に考えていると行き詰ることもありますから、時々視点を変えて考えてみましょう。
また、よくある事例に照らして考えてみるといろんなヒントが見えてくるかもしれません。
私が実習生というテーブルを考えたときは、データベースの事例として良くある請求書の作り方に照らしてみました。
顧客は学生、購入商品は実習先、請求書を実習生と考えるとわかりやすいのではないでしょうか。顧客と月別に作る請求書は １：多、学生と実習ごとに作る実習生は １：多 です。請求書と購入商品は １：多、実習生と実習先は １：１、となります。普通は購入商品は商品マスターに結びついているので実習先には実習先マスターが必要になるかもしれません。
システム開発会社に発注するのと異なり、個人ベースで開発する場合は開発者以外にFileMakerユーザーがいないことも多いと思います。
私にはできませんでしたが、ユーザー仲間を作ることも必要かもしれません。いずれ、システムの拡張や、メンテナンスは他のユーザーやシステム開発会社に委ねるか、別のシステムを導入することになると思います。そのような時のためにも私のやり方が正しいのかどうか自信はありませんが、システム開発に関わるドキュメントは残しておいたほうがいいですし、データベースの構造もわかりやすいものの方が良いと思います。
ボーイング787。この写真を撮影した当時は職場が千葉にあり、毎日々々、羽田空港へ着陸する飛行機が上空を飛んでいました。夕暮れ時になると東の空にはいつも飛行機の灯が3機ほど見えていました。4〜5分間隔かもっと短い間隔だったと思います。
Canon EOS 50D EF-S 18-200mm 185mm ISO100 1/400 F7.1 P
jpg
2012/8/16 Ichihara City
