「業務の可視化」をテーマに催した秀玄舎メンバーによる意見交換会レポート後編。
業務フローをすべてシステム化するのではなく、クライアントとの対話を重視すること、クラウドツール全盛のいま、ITコンサルタントとしての役割をどこに持つかなど活発な議論が交わされた。
後続のフェーズに役立たないドキュメントを作れるのは、クライアントとの信頼関係ありき？
僕は、お客さんが自分で可視化するとか考えるとか、自分たちが向き合っている業務を自分で語れるようになってもらうためにやっているので、後続のフェーズにほとんど役立ってはいないというか、ドキュメントがそのまま使われるケースはほとんど無いんですよね。もちろんインプットとして作ってはいるけど、ベンダーさんに説明しやすくするためぐらいのもので、それを元にシステム作られても困るかな。
業務フローを作りはするけど後続には使わないでとか この部分はDFDを作ろうっていう意思決定って、相当クリエイティブで難易度が高いですよね。
システムってそんなに簡単にできないんだよねって、あらかじめ言える信頼関係があるっていうのは結構大事かもしれないですね。以前、
さんに言われたんけど、「お客さんにDFDを書きましょうって言って、素直に受け入れてもらえるのは、たぶん
さんのことを信頼しているからですよ」って。「作っても後続には使えませんよ」なんて、それなりに信頼関係がないと言えないもんね。
後続のシステム開発に使えるようなものを作るのと、業務を自覚するために作るのでは目的が違いますよね。さんが言っているのは後続に役立たなくても良いって割り切っていいかもしれないけども、後で使うものであれば、粒度を細かく作らなきゃいけない印象はあります。さんは信頼されているから、後続のためにちゃんとしたドキュメントを作ってほしいって思われていないんじゃないかな。
後続のフェーズで使うようなドキュメントが欲しい時に、僕は呼ばないって事ですね。
でも確かに後続は発生しますよね。業務フローは利用者のテスト仕様書のインプットになりますし。
業務フローを全てシステム化することがベストではない
皆さんがどう思うか知りたいんですけど、個人的に思っているのは、業務フローがものすごくたくさんあるプロジェクトはだいたい炎上するっていう。すごくたくさん業務フローを作ったところで、後続に本当に使えてかつ、うまく機能するのかはまだ懐疑的です。
結局、システムの要件を読み取るには業務フローじゃ足りないんだと思う。たとえば業務フローの中にシステムが登場するじゃん。TBDだったとして、「ここでこういうものをインプットします」みたいなことを書かれたところで、要件としては2割ぐらいのものじゃない？
僕の印象だとノイズが多すぎるっていうイメージで、それを真面目にやろうとすると複雑化するとか、システムがその負債を持ってしまうとか大変なことが起きやすいのかもと思います。特に、何が本当に大事なのかみたいな濃淡があまりないと、特にうまくいかないイメージです。
ビジネスサイドはシステム屋に、業務背景を知った上でシステムを作ってくださいって望んでいるんですよね。要はこういう過程、全体像の中でこんな機能がいるんだと。だけど、システム屋からするとそれは不要で、システムのインプットとアウトプットさえ教えてくれれば作りますよっていう。だから、文脈みたいなものを理解して、何だったらちょっと忖度して機能を変えてもいいよ、みたいな感じが、ビジネス側の永遠の希望なんだけどそれをノイズって言われちゃうと難しいね。
逆にそのノイズと言われるものさえ表現できれば、いいんじゃないですか？ビジネスサイドからすると、書いてからあとはシステム屋さんに任せてみたよっていう感覚だし。
業務フローが多すぎるとか複雑なケースって、基本的にお客さん側の意思決定に問題があるということが私の経験値では多い気がします。
たとえば、親会社の言うことを全部聞かざるを得ない立場の弱いお客さんの業務フローとか、めちゃくちゃ複雑化してますよね。いくら「このフローに問題がありますよ」って言っても、「それは分かってるんです」で返ってきそうな。
複雑であれば複雑であるほど、業務フローも複雑なまま出てきますね。
でもそこはシステム化で解決する問題じゃなくて、交渉するなり、人脈なり、ちょっと違う部分で解決しなくちゃいけないですよね。業務フローがたくさんある場合はそれをシステム化するんじゃなくて、システム化する前のアクションをしましょうっていうのがたぶん次の手だと思うんですよ。そこからシステム化できるかもしれないけど、多分まだ粒度が荒いと思うんですね。数はあるけど、深さが足りないとか。
スーパーに商品を卸している流通の仕事があるんですけど、1つの商品が小売店に届くまでに商流が7つか8つあるんです。ものは全く通っていないのに伝票だけ通って、都度手数料が抜かれているんだけど、それって日本特有の商習慣なんですよね。だけど、それが絶対悪かって言われると意外と必要だったりするんです。スーパーからすると必要なものが必要な時にあればいいんだけど、ものすごく供給不安定な商品でもあるから、色んな所を経由してくるんですよ。スーパーが、例えば200～300か所から商品を調達していると毎月違う請求書が来て困るから、集約したり、リスクヘッジしたり在庫したり、まとめている会社があるんです。その７つか８つある商流の中に同じ会社が2、3回登場するから業務が複雑になりすぎてシステム化したいんですって言われて。先ほどの立場が弱いとはまた違う話だけど、そのまま全部システムにするとよくないねって判断から、エクセルに毛が生えた程度のすごくシンプルなプラットフォームを作ろうってなりました。つまり、立場が弱いことを売りにして生存している会社が結構あるので、業務フローをそのままシステム化しようってならないことも大事なのかもしれない。必ずしも、方法をシンプルにできないあなた達がダメなんですよってわけでもないんだよね。
システム化の切り口に意外なところを見つけられたら、それ自体がイノベーションですよね。普通システム化しようとしたら何千万、何億とかかかるところを、切り口さえ見つけられたら、あとは全部人間に頼ったらいいんじゃないですかね。
やっぱりここで立ち止まるんですよね。フローがすごく複雑とか大量にある時にこれはマジなのか？本当に意味があるのか？価値があるのかないのか？問題が隠れてるのか？って真剣に突き詰めないと、そこから先がすでに負け試合になりますよね。
業務の方がすごく複雑だな、これを全てシステム化するとしたら、何千万、何億ですってなりそうな時には、一旦その後ろ側にまで入り込むってことだね。
量の多さでコストとの関係性が視覚的に分かりやすいですよね。
でも、そのまま普通に見積もっちゃう会社が多い気がするな。
クラウドツール全盛の今、マネジメント部分を切り出せるかはこれからのテーマ
この領域って日本だと、コンサルがやっているイメージだけど海外だと割とビジネスアナリストが出るケースが多いと数年前は聞いてました。BABOKのような知識体系もあるんですけど、最近あまり耳にしませんよね。そこの専門性、あるいはメソドロジーに決定打がないんでしょうか。
まず1つは、ビジネスアナリシスをやってる間に事態が変わっていくから、悠長なことをやれなくなったんだなという気がする。あと、講座を作っている時に思ったのは、結局どんなツールを使うかによって、プロセスやアウトプットが変わっちゃうのでクラウドツールドリブンなんだよね。どのように業務を回したいかを予め考えずに、「今はみんなこのツールを使って仕事してるみたいだから同じようにしよう」みたいな。ベンダーが100回言っても耳を傾けなかったユーザーがそうし始めてますよね。
乗っかるってことですよね。
さほどITに対する知見がなくても、Slackのワークフロー機能などを使って部分的なERPみたいなものを作っている会社もあるからちょっとびっくりしますよね。でも、それで育ってきた人たちが増えてくると、情報システム系じゃない人たちが業務の自動化に取り組むようになっていますよね。
最近、IT業界でなくてもスタートアップっていっぱいあるじゃない。そういう人たち裏側の仕組みは全然分からなくてもクラウドツールをスマートに使いこなしているのを目の当たりにすると、僕たちがずっと大事にしてきたデータ保証みたいな世界はもうないよ。どこで何が起きてるかなってSlackを遡る世界だよ。中小企業の人たちはお金をかけずにうまくやっている。
それは分かる気がする。最終的に思うのがマネジメントは結構難易度も高いし、その後の影響も大きいし、すごく重要ですよね。ここを切り出してサービスができるのか、商売にできるのかは分かりませんけど、今後のテーマの1つだなとは思っています。それでは今日はこのへんで。
いかがでしたでしょうか。”適合点”を見つけ出す難しさは誰もが感じているようです。
