みなさん業務フローの書き方って習いましたか？システムをやっている人間だったら名前を知らないことはないと思いますが、業務フローのいい参考書ってないんですよね。
移行もそうなのですが、システムプロジェクトの要衝部分って参考書がない。知識では太刀打ちできるものではなくて、仕事、実務経験を通じてしか上達できない。そういうものみたいです。業務フローなんて要は時間軸と人軸のマトリックスですから。書き方について教わることなんて少しだけ。
予算に収めるため、納期を短くするため、画面を簡素化しましょうとか、帳票を共通化しましょうとか、そんな努力（ユーザーにとっては妥協）がいっぺんに吹き飛んでしまうのが業務フローのミスなんですよね。一言でいうと要件漏れです。たいがい例外系で、“注文した商品がなかったら・・” とか、“住所が変わっていたら・・” とか、そういった場合のロジックがなかったり、データ項目が不足していたり、テーブル構造的に無理だったり。
で、犯人捜しが始まります。ベンダーは「言ってくれなかったから」、お客さんは「聞いてくれなかったから」です。お決まりの言った、言わない、です。だいたい、システムテストとか、受け入れテストで問題が判明します。アジャイルだろうと何だろう同じで、実際の業務想定でないと例外系のことなんて表面化しません。
使おうとしたら使えない。例外系であろうと、なければ移行できない。予算も使い切っているし、時間もない。ひどい場合は例外系だけ手業務でお願いしますなんてケースもあります。
じゃあどうすればいいのか？
業務フローのインプットって、業務ヒアリングですよね。あたりまえですが。
業務ヒアリングにはコツがあります。
議事録作りにもコツがあります。
要件レビューの進め方にもコツがあります。
※経験も必要です
業務ヒアリングはプロジェクトの初めのところですね。まだまた修正がききます。１、2週の調整なんて難しくありません。ところが受け入れテストの段階で１、２週の調整は難しい。実際はシステムの作り直しなので１、２週じゃすまなくて、システムテストもやり直すことになり月単位の遅れになるでしょう。こんな感じでシステムの費用対効果は悪化します。品質も性能も巻き添えにしながら。
永島志津夫
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)
