業務変革とＤＸ（２）

業務変革での私の役割は、事業企画・開発の経験者として、事業部の要件をまとめ、現場で本当に使える業務プロセスとシステムを作ることだ。

事業部の中長期の計画や戦略を把握した上で、現状、どんな業務をどのように行っているのか、現場を直接観察する。説明を聞くだけでは不十分で、直接観察することが重要なのは、説明者の認識や解釈が差しはさまれるからである。認識や解釈が間違っている、あるいは、関係者間で異なっていることにも気づきながら、将来のあるべき業務を描いたうえで、今の業務からどのような過渡期を経てどう移行させるのかを計画する。

そして、描いたあるべき業務の姿が実現した際に、どのような効果がどれくらい得られるのか、質的および量的試算を行う。そのために必要なリソースはどれくらいで、費用対効果が成り立っているのか。試算が試算で終わっては意味がないので、試算された効果を事業部が実現させるようコミットを取り付ける。ベースとなる前提条件から徐々に合意し、最終的な効果に至るまで、事業部の合意が得られる内容ではなければならない。

以上を踏まえて合意された業務要件をシステム開発チームへ説明し、開発依頼を行うと、システム開発チームが、それらをシステム要件に置き換え、システム開発が走り出す。システム開発やＤＸといっても、システム開発の人だけでは進められないのである。

意外に知られていないが、病院の電子カルテを導入する際のシステム担当者が医師免許を持っていたりすることがよくある。現場をわかる人であることが求められている例のひとつだ。医師となったものの、いろいろな理由で臨床を離れる医師が一定割合いて、その中でシステムに通じた人が病院内で担当している場合があるのだ。このケースのようにシステムと現場業務の両方に精通している人がいる場合は一人で成り立つが、そうでない場合の方が多く、システム要員と業務要員とでチームを組むことになる。システム要員だけでシステム設計を行い、現場で使えないシステムが作られかかって、それに気づいた経営層がプロジェクトを中止し、仕切り直しがかかったところからお声がけいただいて参画したこともある。

しかし、このシステム要員と業務要員の間でのコミュニケーションがかなり難しい。システム言語とビジネス言語が噛み合わない。どちらも同じ英語で話しているのだから通じそうなものだと思いきや、英語のシステム言語と英語のビジネス言語の間で通訳が必要となるのだ。

たとえば、globalという単語。なんだか話が通じないと思っていたら、ビジネス側は、グローバル企業というような「世界（中）」という意味で使っていたのだが、システム側にとってはglobalというと開発中のアプリケーション内全体という意味で使うらしく、システム言語とビジネス言語の通訳が得意な人が気づいて解説をいれてもらって、お互いに納得したということもある。通訳は、システム側の誰かがすることもあれば、業務側の誰かがすることもあるが、これまでの経験だと、この通訳をできる人は限られているようだ。色んな人が通訳を試みるものの、特定の人の成功確率が圧倒的に高い。

ある企業の事業部にいた知人から声をかけてもらった際、当時の私の仕事の都合で着任までに半年ほどを要したのだが、その間に、事業部からシステムの人へ要件を伝えたにもかかわらず、まったく伝わっていないようだというのだ。もう５回ぐらい方法を変えて説明しているのに伝わっておらず、出てくるものが全くお門違いで困っている、というのが、私が着任した最初に聞いた事業部からの苦情だったくらいだ。

ビジネス言語とシステム言語がいかに交わらないかということがおわかりいただけるだろうか。

（つづく）