うまくいかない業務の"見える化"

業務の"見える化"の問題を解決するためには

最近は、業務の"見える化"が流行しています。
システム開発を行う前に、業務を見える(分かる)ようにして、その中で必要な箇所をIT化していく取り組みのことですが、同時に業務を理解し、問題課題を解決するためにも、非常によいことだと思います。
さて、ここで言う、業務の"見える化"とは何でしょうか?
これには様々な方法がありますが、最もポピュラーな方法としては業務フローがあります。まずは、業務フローを書くことが業務の"見える化"とここでは考えておいてくださいね。後ほど、しっかりと説明していきます。

さて、ユーザー企業や政府における、このような取り組みの多くは、残念ながら成功しているとは言えません。
なぜ、業務をわかるようにする大切な取り組みが失敗に終わるのでしょうか?
今回は、業務の"見える化"のうまくいかなかった失敗例を見ながら、それを解決するにはどうしたらいいか考えてみましょう。

 

失敗例(1)業務の非"見える化"

これは、業務の"見える化"を行わずに進めてしまうことです。このようなやり方は、ユーザーにシステムの要求を聞くことから始まります。このような要求定義を僕は、"点の要求を整理している"とよく言っています。そうです、そもそもIT要求は、業務を面として捉え、その面の流れの中で必要とされるIT要求を捉えるべきですね。

図1 要求は面で捕らえよ
図1 要求は面で捕らえよ

ページトップへ

 

失敗例(2)AsIs業務を"見える化"しているだけ

現状の業務のことをAsIs業務とここでは呼ぶことにします。トップが業務改革・業務改善の旗を高々と挙げて業務の"見える化"を進め、その中で業務を整理・標準化することでシステム開発コストを低減させ、IT利活用を効率的に行うというミッションで進めたはずなのに、なぜかAsIs業務のフローを大量に書いてしまった。これをもってシステムに要求をだしても何も価値がでないのではないか。
これは意外によくある話です。この問題の深層には、プロジェクトの中で抵抗勢力が出てAsIs業務を変えさせないといったこともあるでしょう。また、作業的な時間が足りなくなり、最も分かりやすいAsIs業務をベースに業務フローを書いてしまう、などという原因も考えられます。
そもそもビジネス戦略やプロジェクト戦略、プロジェクトゴールはどこにいったのでしょうね?
さて、ここから、要求開発マイスターのスゴーくんに登場してもらって、これらの問題を心に残る一言で語ってもらいましょう。

図2 プロジェクトゴールを決めよう
図2 プロジェクトゴールを決めよう

ページトップへ

 

先の見えない業務の"見える化"

業務フローを書く際に、その範囲と作業量を見誤り、何百枚にもわたる大量の業務フローを作成してしまったが、膨大なドキュメントが管理されているように思えない。このままでは、何も活用されずにゴミくずになってしまう。
この問題はプロジェクトを成功させるための戦略が足りていません。プロジェクトを成功させるための適切な範囲を決め、なれないうちはできるだけ小さめにプロジェクトを回し、一通りプロジェクトの進め方や作業量が見え始めた際に、しっかりとプロジェクトプランを立てるような戦略が足らないのです。

図3 プロジェクト成果の結果イメージを予測せよ
図3 プロジェクト成果の結果イメージを予測せよ

ページトップへ

 

絵に描いた餅

業務フローをToBe(新規業務)として書いたものの、どうも非現実的のように思える。そもそもこの業務フローで新しい業務をまわしていける自信が利用者にあるのだろうか疑問が残る。
このような感触を持つプロジェクトは、ToBe業務に対して、チームとしての覚悟を取り付けていないという問題があります。

図4 ToBe業務の
図4 ToBe業務の"見える化"とは

いかがでしょうか。
このような問題を持っているプロジェクトは、みなさんの周りにも見かけられるのではないでしょうか?
要求開発の考え方は、このような問題を解決するためにも必要となるのです。これから詳しく説明していきますので、まあ、慌てることなくじっくりお付き合いください。


  • ※掲載されている製品・サービスは、掲載当時のものです。
  • ※掲載されている社名および製品名は、各社の商標または登録商標です。

ページトップへ