業務システム 仕様編 6/30

 業務システムだけではありませんが、要求仕様の検討は常に問題がいっぱい発生します。ざっと並べると、

  1. 性能・業務フロー・画面・帳票・カスタマイズ性等どこまで要求仕様段階に盛り込むか
  2. 現状の業務フロー(ユーザさんが大概、例外対応と思っているフローが多いです)をユーザが把握していない場合の対処
  3. 今後、修正されていくであろう業務フローへの対応
  4. 検討メンバーは誰が入り、最終権限は誰が持つのか、責任は誰が持つのか
  5. 成果物の形態、ドキュメントの書式は
  6. 仕様FIX後の修正ルール(誰が修正する・責任は誰等)はどうするか

これ以外にも細かい話は色々ありますが、なにより問題なのは、予算と時間と人材は限られているということです、したがって、解決策というか、対応方法はユーザさんといっしょに、ベストではなくても、ベターな対処をめざすことで、最初に納得しておいてもらうことが前提になりますが、

対処1.本当は、性能、業務フローのシステム化する部分 のみが理想なんでしょうが、なぜかこの段階で、画面・帳票を決定したいと思うのもユーザさんの人情です、ここはユーザが必須と思う範囲は盛り込みましょう。また、ある程度ユーザさんが理解してもらえなくても、今後発生するであろう修正に対応できるよう予算と時間が許す範囲であらかじめカスタマイズ可能なように設計することを盛り込んでしまいましょう。

対処2.3. 結局この2つはいっしょで、完璧な業務フローを元に設計できるとは考えないことです、対処1の最後に触れた、カスタマイズ可能なように設計できるようにあらかじめ要求仕様に盛り込んでおくことが必須です。

対処4. 検討メンバーはまず、エンドユーザ・ユーザの情報システムサイド、ベンダーサイド 関係者は出来るだけ広い範囲から選ぶ必要があります。これは、ユーザサイドでは、仕様段階からかかわってもらうことで、システムへの理解度・協力度を上げる上で非常に効果があります、またベンダーサイドから選ぶことで、限られた予算と時間と人材の中でベターなシステムとすることが可能になるよう調整することが可能です。 また同時にキャラクターとして、前向きな人間が絶対条件となります。でないと、こんなシステムならいらないと言う話にまで発展することがあります(いやまじで、それでユーザさんの役員まで話がいって、ユーザ担当者さんがとばされたという・・・・・・・・)

対処5.これがまた難物です、ここ何年かはUMLとかいうものが主流になっていますが、ようは絵にすることです。で、あまりUMLとかなんとかにはこだわらず、ユーザさんも入れていっしょに絵を書きます。で最後のとりまとめは、ベンダーサイドの人間が行い、そのときに、出来るだけUML[等のそのとき選んだ書式に則りつつ、ユーザさんでも、わざわざ勉強しなくてもわかるような絵にまとめます。説明文書くのはもちろんベンダーサイドの人間です。責任はユーザさんですので、かならずハンコをもらいましょう。

対処6.仕様FIX後の修正ルールは、かならず作り要求仕様といっしょにハンコをもらっておきましょう。たとえ、ルールどおり運用できなくても・・・・T_T 特に(ベンダサイトから見た)仕様変更が多発し、予算オーバーになりそうな一歩手前で持ち出し、このまま野放図にいくと予算オーバーになることを含めて説明すれば、以外とその後はきちんと運用されるようになるものです(たぶん、私は大概そうでした、でもうまくいかないチームも多かった・・・・・)

というわけで、予算と時間と人材がどう考えても不足しているプロジェクトばかりやってきたので(決して潤沢な予算とか時間と希望しているわけではないのですが)ベストではなく、ベターな解決策ばかりになってしまいましたが、でも、大概のjプロジェクトってこんなもんですよね、それに潤沢な予算があり、数百人もの人を掛けているようなプロジェクトって、なんとなく無駄がおおいような気がするのは、貧乏プロジェクトマネージャの僻みでしょうか^_^;

戻る