システム化計画プロジェクトのポイント!!(その8) 〜つまらないIT仕事をワクワクさせる
「システム化計画」プロジェクトについて話の第8回目になりました。
前回に引き続き、「新業務/システムの概要設計」の進め方を続けます。
前回まで主に機能要件と非機能要件の概要設計が終わりました。最後にこの時点で出て来た(たぶん)膨大な課題を整理しておく必要があります。
システム化に係る課題の整理
「新システム機能概要の定義」から関連する他のデータ、I/O、インターフェースなどの定義、またその元となる「新業務/システムの定義」において、たくさんの課題がでてきます。また先ほどの「非機能要件の定義」においても課題がでてきます。多くの課題は、現段階では決定できない事項が課題となります。例としては以下のようなものがあります。
- 新業務を行うに当たって、現行の方法を変える必要があり、そのコンセンサスがユーザー部門から得られていない
- 新システムは現行システムとは異なる操作方法、サービスレベルであり、ユーザーのコンセンサスを得る必要がある
- データを標準化したいが、現行と大きく変わるため検証が必要
- 現行システムが行っていた他システムインターフェースを新システムにすると他のシステムに改修が発生する
- 他システムインターフェースが多いのでえETLを導入したい
- システム部が従来行って来た処理(例としてデータ分析)をユーザー部門に今後実施してもらうことのコンセンサス
- ユーザー認証の方法、他システムと統一するか
- 新システムの設置場所が決まっていない
- 一気に移行するか段階的に移行するかは未定
- インフラにクラウドを採用する可能性もあり
- 運用要件としてITIL対応を行いたい
こうしたシステム化に係る課題については、この時点(システム化計画)ではまず、きちんと書き留めておく事が必要です。
この段階で沢山課題がでてくれば後で、突然、その課題が勃発することを防いでくれます。
また各課題について、方針レベルのものについては、このシステム化計画の中で決めておくべきであると思います。なぜなら方針を決めていないと、システム化計画のアウトプットである開発費用が実際に実施した場合とブレてしまうからです。方針レベルさえ決めておけば、あとの作り方は後続の基本設計などのフェーズで行えばよいと思います。
またこの段階で、課題が山積みになることが普通ですが、それでめげない心の持ち方も必要です。また変に課題を隠す必要もないので、ある程度課題がでてきたら、プロジェクトメンバーを集めて、課題共有のファシリテーションミーティングを開催しましょう!
プロジェクトマネージャーは一人で課題を抱え込むことはなく、チーム全員で共有するばいいのです。ファシリテーションミーティングを行うことで課題に対してチームが一丸となって向かって行く、クリアしていく気持ちが出てくるはずです。ですから、課題についてはオープンに共有してしまいましょう!!
そのファシリテーションミーティングの中では、追加で課題はないか、課題について出尽くしているかのチェックと、さらに課題の緊急度、優先度などについて皆の意見を共有化することも大事だと思います。通常のファシリテーションミーティングの流れで課題共有→対応策の立案→アクションプランの策定を行ってみることが大事です。
次回はいよいよシステム化計画、最後のステップである「新システム構築計画の策定」の話をします。乞うご期待。