今回のプロジェクトで自分の経験と大きく異なることがいくつもあり、私も混乱しました。将来また同じことがあったときに備えて今の自分の考えをメモしておきます。
(内容は完全にプライベートな内容です。)
そもそも、今回のプロジェクトのフェーズは要件定義。いつもと異なるのは現行システムのリプレースでパッケージを導入すると言うこと。パッケージの導入は初めての経験だったけれども、要件定義は今までにもいくつもこなしていたよ。
混乱したことは、「要件定義はどのように行うのか?」というところかな。画面が登場したり、ユーザの業務をヒアリング・分析しないで進むドキュメント作成。ドキュメントが10くらいあるのに打合せ時間は1時間程度しかない。これでは要件定義は進まない。
自分の中で考えていることを明確にしよう。
まず要件定義の流れ。要件定義の流れや次のようなフローを行ったり来たりしつつ進めていくと思う。
- システム化の目的を明確にする。
これはシステム化の目的を明確にすることだと思う。たとえばハードウェアの保守切れや、業務効率化など。 - 現在の業務とその問題点を把握する。
システム化の目的が業務効率化なら、システム化するべきかがこの段階で明確になる。主にユーザ部門の代表者との打合せが中心になる。何でもかんでもシステム化することがユーザにとっていいことではないから。 - システム化の範囲を把握する。
現在の業務とその問題点から、何をシステム化するかが明確になるので今回のシステム化対象を明確にする。たとえば、外部データとの連係の要否などはこの段階で明確にする。また、同じシステム化対象でも大きく業務フローが異なる場合はその対応を行うのかどうかも明確にする。 - システム化した後の業務フローを明確にする。
システム化した場合の業務フローを新旧比較できる形で明確にする。新旧の業務フロートシステム化対象をリンクした形で明示することでシステム化の目的に沿った内容となっているかを検証できるようにする。 - 必要なシステムリソースと運用方法を明確にする。
ハードウェア(サーバ・クライアント)やネットワークなど必要なシステムリソースを明確にする。また、システムの運用方法やリカバリ方法を明確にする。 - セキュリティ要件を明確にする。
内部統制や個人情報法護法などログや認証の仕組みが厳格に求められることがあるため、ログの出力方法や運用方法、保存要件などはこの段階で明確にする。ここで明確にしていないと基本設計以降で大幅な手戻りが発生する可能性があるので注意する。 - 導入にかかる教育や保守要件を明確にする。
システムの導入にかかるユーザ教育や保守要件(バージョンアップ対応や修正プログラムの対応)を明確にする。
だいたいここまでのことを明確にした上で、ユーザとの合意が得られれば要件定義終了で設計フェーズへいこうという認識。何よりも難しいのが、「2.現在の業務とその問題点を把握」で今回はここをないがしろにして何となく要件定義を進めていたためにうまくいかなかったのだと思う。
対象が簡単なシステムの場合、この部分は現行のシステムを把握することだけで何となく進めてしまいがちだけれども、現行のシステムに問題がないと言うことは考えづらい。たとえ、現状のままでといわれてもユーザ部門の代表者からヒアリングを行いシステム化したあとのイメージについて情報を共有する必要があると思う。
こうしてみると、要件定義とは「ユーザの業務を客観的に評価・把握してその問題点を明確にした上で、その問題を解決する道筋をつける」と言うことになる。その道筋は必ずしもシステム化することにはならない。
文章にすると自分の今の考えがまとまっていいですね。