定期開催している秀玄舎メンバーによる意見交換会。今回のテーマは仕様検討や要件定義を進める上で欠かせないものの方法論が確立されていない「業務の可視化」について。前編では各メンバーがこれまでプロジェクトで実際に行ってきた事例とそのメリット、デメリットを中心に意見を交わした。
業務フローをクライアントに作成してもらうのは効果的。その後のプロセスに役立つかは「？」
今日は業務の可視化と、システム仕様化について話そうかなと考えています。
個人的にPMの観点からうまい解決策とか勝ちパターンみたいなものがあまりない領域であること、そして、これからのシステム開発やプロジェクトマネジメントって昔よりもスピードが速くなっていくでしょうし、不安定、不確実性が高まっている背景もありますよね。UXデザインにフォーカスがあたるスタートアップもいますし、技術的にもある程度、出来合いのものを使って開発できるようになっていますから、プロジェクトマネジメント的にも、「どう作るか＝How」よりも「なぜ作るのか＝Why、What」のあたりに少しずつ焦点がシフトして行くんじゃないかと思っているんです。その割にはここに知見が蓄積されていない印象があるので事例などを共有できる場にできればと。
皆さん今まで、そして現在、それぞれ業務の可視化と、システムの仕様化において、何をやっていますか？僕が思いつく限りは業務フローやDFD、バリューストリームマッピングなどがあるのですが。
DFD、ユースケースになるとだんだんシステムっぽくなるみたいですが、初心者にもとっつきやすいという理由から、IT講座では業務フローをやりましたね。僕はとにかくお客さんにヒアリングして、やり方を教えて、書いてもらうことに比重を置いているんです。しかしお客さんが自分で考えることがメリットになる一方で、その後のプロセスにはあまり役に立たない、それを要件定義と呼べないというのがデメリットでもあるんですよね。
僕自身はやったことないんですけど、その先にマニュアルを書いてもらうというのもあるかもしれないですね。
難易度高くないですか？
製品を作るときは、やったことありますよ。でも、初めての人にとってとっつきやすいのは、やはり業務フローですよね。
とある、若くてかつチャレンジ精神に溢れているお客さんには、業務フローより難しいことにチャレンジしてもらおうという理由からDFDをやってもらったことがあります。
あとは業務上に課題があったときに、一旦データにフォーカスする目的でDFDを使ったこともありますね。僕が本当に重視しているのは、お客さん自身が、自分たちの業務を可視化するっていうことだから、正しさだとかその後の工程に役立つかまでは、そこまで気にしていません。
システム化されていない、個人の暗黙知を形式知にすることが業務フローの肝？
結局、何のためにやるのかというと理解促進がメインテーマなんですかね？
お客さんが、システムのイメージを捉えられるという示唆は結構大きいと思いますよ。
きっと副産物は色々あるけど、たとえば、経営陣に対する説明能力みたいなものを現場に培ってほしいですよね。「今、システムがこのような状況だから、このような問題が発生してて、こう改善したいんです」って僕が登場しなくても語れるようになってほしい。自分事として構造を理解して自分で考えられるようになってもらうためにやっている。
僕は経営者に説明するのにDFDは不要で、どちらかというとシステムをデータの観点から整理するための可視化はすごく有効だと思っています。業務フローも、本当に現場の人たちが業務をするためものであれば、粒度を細かくするだろうし、「我々がやってる大きな業務ってこういうことなんですよ」っていう経営陣に説明するようなものであればもっとざっくりしたものになるし、それ次第で用途や目的が変わってきますよね。
昔あった案件も、DFDをやる大きな意義の1つがシステムの切れ目を整理することだったと思うんですよね。そうすれば、今後開発ベンダーに依頼する際にもそれぞれに分けられるというメリットがありました。
10年ぐらい前、あるお客さんが40年ずっと使ってきた業務の基幹システムを根本から変えるプロジェクトに
さんと
さんが参画したんですよ。2人が半分手とり足とり、若者5人くらいに会社全体の業務フローやDFDを書かせたのを元に、お客さん主導で基幹システムを再構築できたのが、私たちの中ではランドマーク的な事例になったと思っているんです。
この時、DFD作るようにしましょうって言ったのはその会社のCTOです。恐らく業務フローを作り始めていたら、もっと炎上してた気がするんですよね。そこをDFDにしたのは、目的にかなっていたのかなという気がします。その後の業務に役立ったかというと評価はあまり分かっていないですが。
でも開発のインプットになっていますよ。基幹システム全体を描いたレベル0みたいなものから分解していく過程は開発会社側からすると非常にありがたいですよね。そこから「あなた達が作るのはこの領域です」とか「この領域の外側には誰と誰がいます」など分かりやすくなりますよね。説明も楽だし、受け手にとっても、開発会社と話しやすいドキュメントだと思います。
業務の意味がデータの変化で伝わるよね
そうなんですよ。結局、誰に向けた資料であるかですよね。
コスパというか、何のためにこれを書くんだろうって考えるのは重要だと思います。
業務フローとかDFDでアウトプットできるのは、形式知になっているところじゃないですか。システム化されたところを業務フローにするのはたくさん作れるけども、個人が暗黙知でやってるようなところをどうやって形式知に引きずりだすかが、本来業務フローなりDFDなりの役割だとも思うんです。何だか例外が多いな、とか同じ商品を買うにしても、複数パターンあるんじゃないかっていう気づきが本来の肝なんじゃないかと。
暗黙知を引き出すという点では、業務フローの作成は結構難しいと感じます。やり始めるとすごい出るんですよ、暗黙知って。出したはいいけど、これどうするんだってなってしまうので、そこのさじ加減は悩ましいです。
しかし、それらをノイズだと思ってスルーすると、後で仕様変更や追加で、業務が回らない。だからって追加改修が発生するきっかけでもあるので、判断は難しいんですよね。ちなみに、業務フローやDFDに関して業務の方が変わった事例ってありますか？システムを作るために業務フローやDFDを書き起こしてみたら、「これとこれは結構冗長じゃん」みたいに業務の方を見直したようなことってあるんでしょうか。
業務フローを全部システム化すると、コスパが悪くなるので、バリエーションが出ちゃうところは、システム化するのをやめましょうというのはありますよ。というか、そのためにやっているみたいなところはある。業務を変えるって事ではないけどね。
業務フローが出来ることはプロセスの可視化
業務フローを読むのって相当難易度高いイメージありますが、素朴な疑問として皆さん読めますか？
例えばDX講座では、それぞれ自分の業務フローを書いてきてくださいってお願いするんですよ。網羅性とかルールとかめちゃくちゃだけど、こんな仕事をしているんだってことは、すごく伝わるよね。業務の流れとか、どのような関係者がどのような仕事の受け渡しで、どのようなチェックをどこでしてみたいなことは、口頭で説明するより700倍ぐらいは効果があると思う。
現場の方に「今、こんな無駄なことしてませんかね？」って気づきを促す時にはあった方がいいかなと思います。これは業務改善ポイントあるあるですけど、作業が差し戻しになった時に、かなり前のステップに戻ってしまいますよね。それって口で言ってもなかなか分からないんですけれども、業務フローで示すと、「これやばくないですか？」って何となく分かってもらえるんです。見た目のインパクトを与えるという意味で、業務フローは効果的でした。
業務フローが出来る事ってプロセスの可視化でしかないと。業務系というか基幹系というか、プロセスマネジメント系はそれなりにツールがあるけど、じゃあ情報を共有してみんなの判断の精度を上げようと早くしようと会話をする時に本当はDFDが有効だと思うんだよ。けど、いちいち可視化することにそんなに意味はない気がしているから難しいですね。
すごくありきたりなまとめっぽくなっちゃうけど、本当に何が必要なのかを考えて作らないといけませんね。何も考えずに網羅的につくるみたいなのは最悪だってことは共通見解的なところかなって気がします。
＜後編へ続く＞
