業務フロー図作成 入門の入門 (師匠の言葉を添えて)
「業務フロー図、、、描いたことはあるけど、、、なんか自信ないわぁ」
そんな方いませんか? 私は、自信なかったです。
• 社内でBPRを率いることになった
• システムサイドからこのフロー図じゃわからんって言われる
• テスト項目書作成時にフロー作ったほうがよくね? ってなった
という方向けの入門記事です。
このnoteは、 Leverages Advent Calendar 2019 の24日目記事になります。
(私はエンジニアではありません。)
| 1 Box : 1 Action
師匠)
お前、1つの箱に入れすぎ。
そんなにいっぺんに仕事してないやろ。笑
1つの箱に1アクション。 (1スライド1メッセージ的な。)
BPRでは、As-Is / To-BeにおいてBoxを消せないか、他のアクター (特にシステム) に移せないか検討します。1 Boxに複数Actionが紐付いていると、To-Be作成のときにフロー図を最初から書き直し、なんてこともありえます。
テスト項目書作成においては、Actionごとにテスト項目存在するべきです。きちんと 1 Box : 1 Action で書けば、テスト項目書作成もはかどります。
| アクターを個別に認識し、網羅すること
師匠)
え、お前の会社には「システム」ってやつがいるの?
それとも 「〇〇営業支援システム」「XX管理システム」ってやつがいるの?
あとさ、これ全員いる? 手抜きしてね?
ここで言うアクターは、業務フロー図の登場人物を指します。仕事を行ってくれる人・システムのことです。
現場営業、リーダー、部長の欄は設けるのに、システム、バックオフィスを一括りにしていませんか? 優しさやリスペクトが欠如してるのかもしれませんね・・・。存在を認めてあげてください。
誰が、いつ、どの工程で、どんな仕事をしているのかを明確にするために描いているので、アクター1人1人と向き合ってください。
ここで、
• なんで、こんなに出てくるんだ!?
• こいつら、ほんとはこういう仕事してるはずじゃなくない!?
• え、ここで、こいつに仕事させる意味はなに!?
となったら、それは、業務フロー作成の勝利です。改善ポイント発見です。
左だとさくっと承認とれそうですが、右のように描けば承認されるまでに何日もかかっていることがわかりやすいですね。
| Box がちゃんとつながっているか詰め切れ
師匠)
これさ、ココね。(指差して)
ユーザーが申請するとCS担当者が確認するってあるけど・・・。
CS担当者は、エスパーかなんかなの?
「Boxがちゃんとつながっている」というのは、「前のBoxが次のBoxのトリガーになっている」ことを指します。
上記の例で言うと、実際は、下のようなフロー図がより正しいわけです。
言うのは簡単ですが、既存業務のフロー作成で何回か修正していくうちに初稿とは全く違うものに!? なんてこともあります。
なお、前のBoxがないのに唐突に始まっているBoxには注意してください。改善対象の可能性大です。
(気まぐれ発生業務、と私は呼んでいます。)
誰が、いつ、どの工程で、どんな仕事をしているのかを明確にするために描いているので (本日2回目) 、Boxのつながりに向き合ってください。
| ナラティブでとにかく残すこと
師匠)
ここのニュアンスわからんな。
美しいとか、正しいとか、そういうのええから。
とにかく書け。あとで削れ。ナラティブを残せ。
私は、こんな感じでナラティブ (注意書き, 細かな説明) を入れます。各組織で書き方の流儀があると思うので、うまくやってください。
Boxと他の記号だけで完全に説明できたら、喜ばしいことです。
ですが、まぁ、そんなことないから業務フロー図を描いている側面もあるわけです。誰が、いつ、どの工程で、どんな仕事を (以下略)
| 妄想せよ
師匠)
なぁ、このリーダーさぁ、実はもっと仕事してるんじゃない?
あ、この業務さ、ほんとに部長に確認とってる?
ん、これだけ? 例外ってないわけ?
ヒアリングして業務フロー図を作成する場合に何が大変って、、、だいたいヒアリング内容と現実が違うことです。
でも、これは、しょうがない。
• 本人たちも止むに止まれぬ理由がある
• 知らぬ間にほんとにそうだと思い込んでいる
• 例外などが認識から外れている
ヒアリングして、まともな情報を引き出せないやつ、鵜呑みにしたやつが悪い! 笑 (そう、私のことだ)
疑えってわけではないですが、自分だったらどうだろう、あの人だったらどうだろう、と相手の立場にたって考える訓練をしましょう。
正しく、あるがままに、網羅性高くフローに落とし込むことが重要。そうでないと、理想状態のときにしか対応できない役立たずな仕組みができあがります。
私が自分を問い詰めるときは、こんな質問をしています。
• この人はこれしか仕事をしていないのか?
• 一人で作業しているけど、仲間はいないのか?
• 意思決定は別の人に委ねてたりしないか?
• 言っているが、実はやってないことあるんじゃないか?
• ほんとうに、これで全てか? 例外は存在しないか?
| 最後に
こんなこと書いておいてなんですが、、、ぶっちゃけ、業務がうまく進めばどんな図でもOKです。
ただ、迷ったり、人を迷わせてしまうなら改善できます。
最後に師匠から譲り受けた業務フロー図最低要件を載せて締めます。
• 業務フローから得たいものは明確化
• 逆算して解像度を明確にすること
• 業務の詳細がタスクレベルで書かれているか
• 誰が
• なんの目的で
• どうやって
• 業務分岐が丁寧に記述されているか
• アクターはすべて正確に存在するか
• 網羅性は担保されているか
• 分岐後の扱いは適切化
• イレギュラーを含んでいるか
業務フロー図作成・入門の入門、学びがあったなら幸いです。
次回は、実例でお会いしましょう。(宣言すれば書くはず。)
| おまけ
弊社では、企画やりたい人、サービサーやりたいんですけどって人、要件・仕様書詰まってないのに疲れたって開発の人、、、待ってます。
企画・マーケの人、中の人はこんな感じの人です。
開発の方、企画・マーケの人はこんな感じの人です。
We Are Hiring!
私の部署
全体
ご支援は新鮮なお野菜に変わり、やがて文章となる見込みです。