要求開発の"見える化"に大切な事

要求開発の"見える化"とは

さて、今回は要求開発の見える化にとって大切な事をお話ししましょう。これを知っているだけでも要求開発の"見える化"の心がわかるようになりますよ。

見える化作業はユーザ中心で行うべし

たとえばあなたが開発者としてユーザ企業に要求開発の支援に入ったとしましょう。さあ、あなたはある程度要求開発の知識があり、モデリングも少し上達した状況でしょうから腕の見せ所ですね!

しかし、ちょっと待ってください。
よく考えてみてください、見える化の特性を!
見える化(モデル)とは、複数人で本質的に重要な部分にフォーカスを当て、重要でない部分を省くことで完成されるものです。

このような特性を持った見える化(モデル)は、あくまでユーザ企業のコタツに入っている人たちで書くべきなのです。そうしないと、重要なポイントが欠落したり、あるいは、見える化したドキュメントをユーザがしっかり見ていなかったりするからです。 もちろん、みなさんは、数が多くなったときの支援および清書等のお手伝いをすることは問題ありません。しかしあくまで見える化の主役はユーザ企業なのです。また皆さんの役割は、見える化作業のポイントをユーザに教えるということも重要な仕事です。

エンジニアはロジカルに物事を整理することを得意とします。その得意な面を、見える化作業の支援で活かしてください。

 

ToBeの見える化は覚悟するために書くもの

これは「Vol.3 うまくいかない業務の"見える化"」で要求開発マイスターのスゴー君が熱く語っていたことです。
よく"見える化"すればみんなで業務構造を共有できるといったことも言われます。それは正しいことです。みなさんが業務を"見える化"する際に、最初に効果として表われるのは、共有理解できる業務モデルが作れたことです。

しかし、実際に業務改革や業務統合化を本格的に行う場合は、もっとコタツチームの中でToBeの業務について覚悟を取り付けることが必要となります。ToBeの業務を"見える化"するという事は、この覚悟を取り付ける事が目的なのです。

図1 ToBe業務の
図1 ToBe業務の"見える化"は覚悟するために書く

ページトップへ

 

どうしたら覚悟を取り付けられるか?

では、そのためにどのようにすればよいのでしょうか? それではここで要求開発マイスタースゴー君に登場してもらい、このToBeモデルをどのようにしたら覚悟できるか説明してもらいましょう。

スゴー君 そうねえ。では業務改革のためのToBe業務フローをとって考えてみましょうか?
覚悟させるための業務フローは、まずは親切でなければならないと思うよ。
そのためには次のような事に気をつけよう!

業務フローの書き方

  • タイトルが適切に書かれているか?
  • フローの概説が書かれているか?
  • 改革ポイントが業務フローの必要個所に書かれているか(吹き出しでもよい)
  • 業務処理名が標準化されているか(これは用語辞書を作ろう)
  • システムを使う場所が明確になっていてイメージしやすいか?

さらに、業務フローに加えて必要になるものがあります。
それは、画面イメージ、および業務フローを構成する個々のアクティビティ(活動:業務処理)のシナリオ(これをオペレーションシナリオと呼びましょう)です。

筆者 スゴー君ありがとうございました。
スゴー君 いやいやこれだけではだめなのです。
それはやっぱりコレですよ(笑)

図2 覚悟のチーム
図2 覚悟のチーム

スゴーくん今日はありがとうございました。
みなさんも、しっかり覚悟できる業務モデルを書けるようコタツチームを支援してくださいね。


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

ページトップへ