システム企画の進め方

システム企画の進め方

システム企画の全体像

前のフェーズ(基本構想立案フェーズ)は、いわば「事業要件定義」です。このフェーズ(システム企画)は「業務要件定義」と言えます。「業務要件定義」なのに「システム企画」と呼ぶからややこしいのかもしれませんが、主として業務要件を定義し、従としてシステムの絵姿を描く(企画する)のがこのフェーズでやるべきことです。

(システム開発を発注する)企業にとっては、この辺りから苦手意識を持つかもしれませんが、ここに真剣に取り組むことができるか否かで、企業のIT活用力に大きな差が生まれます。

業務要件を定義するとともに新システムのイメージを策定し、最後に投資判断を行います。

仮に3年間のロードマップが策定されており、初年度はシステムA、次年度はシステムB、最終年度はシステムCの構築がそれぞれ設定されているとしたら、初年度はシステムAをスコープとして「システム企画」を行います。

システム企画のプロセスは次の7つのプロセスで構成されます。

Step1.基本構想の確認
Step2.新業務の検討
Step3.新システムの検討
Step4.移行・展開の検討
Step5.運用・保守の検討
Step6.投資対効果の算定
Step7.提案依頼書の作成とITベンダーの選定

システム企画プロセス図

Step1.基本構想の確認

「基本構想立案」で策定したグランドデザインとロードマップを改めて確認します。「システム企画」着手までの間に事業環境が変化していることもあります。場合によっては基本構想自体の見直しを行います。

システム企画の方向性の共有

プロジェクトメンバー間で、基本構想について異なった理解をしている場合があります。メンバー間で意見交換する「場」を設け「システム企画」の方向性を共有します。

プロジェクトが進むにつれ手段にばかり注目し、目的を見失ってしまうことがよくあります。本プロセスで確認・共有した内容は、迷ったときのよりどころとなります。

Step2.新業務の検討

新業務がどのようなもので、どのように進めるのかを策定します。現行業務を疑ってかかる必要があります。なぜこの業務を行っているのか?本当に必要な業務なのか?他のやり方があるのではないか?自分たちでやらずに外にお願いする方法もあるのではないか?というような視点を持って新業務を検討します。

主な検討項目

バリューチェーン、業務フロー、ビジネスルール、めざすべきサービスレベル、組織体制と役割分担など

業務を見直す際のポイント

ECRSの原則(なくせないか、一緒にできないか、順番を変えれないか、簡素化できないか)

現場の抵抗

基本構想立案時に業務改革のテーマの一つとして「業務運用の統一化」があげられることが多々ありますが、各部門、各営業所が「特殊事情」を持ち出して「統一化」に反対することが多々あります。

本当に「特殊事情」なのか?「特殊事情」だとしてそれが「統一化」できない理由になりうるのか?を客観的に判断しなければなりません。そのうえで現場との密なコミュニケーションが必要です。根気よくコミュニケーションをとり信頼感を構築しなければなりません。

業務改革のようなプロジェクトでは一定数の「抵抗者」が現れるものです。「総論賛成,各論反対」も珍しくありません。一般に、業務改革に賛同し、能動的に動いてくれる人は全体の1~2割いればよいほうと言われています。推進リーダーは時に孤独を感じるかもしれませんが、根気よく取り組んでほしいと思います。

Step3.新システムの検討

新システムについて一通りの検討を行います。詳細は要件定義工程で定義しますが、投資判断ができる程度には検討する必要があります。「投資判断ができる程度」とは、「投資対効果を見積もれる程度」という事です。

新システムの全体イメージ

システム関連図(システム相関図、システム鳥瞰図)として整理します。これによりターゲットとするシステムとその周辺システムとの関係性とスコープを定義します。

システム機能

機能イメージ(画面イメージ、帳票イメージ、データモデルを用いてシステム機能の概略を説明した資料)を整理します。

データモデルについては概念レベルの整理で構いません。大まかなデータ項目、データ量を整理する程度に留めます。

非機能要求

業務に求められる処理性能、信頼性、可用性、拡張性、保守性について整理します。

世の中のIT技術レベルをキャッチアップしておくことが重要です。特にハードウェアなどはわずか数年で大きく進展する。数年前には考えられなかった機能や、コスト的に見合わなかった機能であっても、現時点では検討の余地があるという事もあります。

システム構成

どのようなハード・ソフト構成とする必要がありそうなのか、どこに設置するのか、IaaSやPaaSの利用を想定するのか、ネットワーク構成はどのようなものになるのかを整理します。

Step4.移行・展開の検討

移行対象、移行方法、移行時期、移行期間中のシステムイメージと運用イメージについて整理します。

特に次の点留意して検討を行います。

新旧システム間の連携

場合によっては新旧システム間でインターフェースが発生したり、新旧の両システムに対してマスタ登録を行う必要があったりと、移行期間中ならではの機能、運用が必要となる事もあります。

新旧システムの比較検証

並行稼働を経て移行する場合、新旧システムの比較検証を行うことがあります。比較検証の対象、方法について方針を出しておきます。

新旧システムデータの取扱

段階的に移行する場合、新旧システムが同時に本稼働していることになります。例えばエリアごとに移行展開する場合、北海道では新システムを使っているが、東北以南は旧システムを使っているというケースがでてきます。このようなケースを何も考慮しないと、全社集計データがうまくとれないなどということになりかねません。

ユーザー研修

新たな業務運用と情報システムについて、新規ユーザーに対して研修が必要となります。ここではそのアウトライン(座学は?、実機は?、繁忙期回避は?・・・など)を整理します。

Step5.運用・保守の検討

システムは開発しただけでは何の役にも立ちません。活用し続けてこそ意味があります。情報システムは、ユーザーに対して安定したサービスを提供しなければなりません。そのためにサービスマネジメントという考え方があります。

ここでは、サービスマネジメントのライブラリであるITILを参考に、情報システムの運用・保守イメージを整理します。

ITIL V3のフレームワークと主な検討事項

サービスストラテジ

どのようにしてサービスを設計、開発、実装をしていくべきかを戦略としてまとめます。

サービスデザイン

既存サービスや新規サービスのビジネス要件を満たすためにどのような設計、開発をしていくべきかをまとめます。

サービストランジション

本番環境に対するサービスの変更をスムーズに行う方法をまとめます。

サービスオペレーション

定常運用下におけるITサービスの提供を効果的に行うための方法をまとめます。

継続的サービス改善

顧客に対してより良いITサービスを提供する方法をまとめます。

Step6.投資対効果の算定

システム投資効果が大きくても、システム構築費用が投資効果を上回ってしまえば、投資は難しくなります。もちろん、上記のような定量的な効果のみならず、定性効果とあわせて総合的に判断しなければなりません。

投資額について

IT投資額の目安は年商の1.0%(うち0.5%が既存システムの保守、残り0.5%が新規投資)と言われています。年商100億円の企業で、新規投資額の目安は5,000万円ということになります。あくまでも目安ですが、参考にはなると思います。

効果について

「定性効果」とは数字で表しがたい効果です。例えば「意思決定スピードの向上」や「インフラの整備・維持」などがあります。「定量効果」とは数字で表現可能な(表現しやすい)効果です。究極的には売上アップ、コストダウン(及びその結果としての利益アップ)に集約されます。

投資回収期間

投資額が5,000万円で、投資効果2,500万円/年であれば、2年で投資回収可能です。

投資額が5,000万円で、投資効果1,000万円年であれば、5年で投資回収可能ですが、5年は長すぎかもしれません。回収期間が長ければ長いほど不確実性が高まります。

Step7.提案依頼書の作成とITベンダーの選定

次の工程である「要件定義工程」はITベンダー(Sier、ソフトハウス)に多くを委ねることになります。ITベンダーへ依頼するにあたりRFP(Request for Proposal:提案依頼書)を準備します。通常は、数社から提案してもらったうえで、ITベンダーとその提案内容について評価します。

RFPに記載する項目

システム概要

背景・目的・方針、課題と期待効果、現行システムとの関連、組織・利用者、予算規模

提案依頼事項

提案範囲、納品成果物、業務概要、システム概要、スケジュール、体制、費用見積、貴社情報

提案手続

提案スケジュール、弊社窓口、提供資料、選定方法

開発条件

開発期間、作業場所、開発機器など、貸与物件・資料

契約条件

添付資料(別紙)

業務フロー/業務モデル/業務一覧、システム機能/機能関連図、データフロー/概念データモデル、非機能要求一覧、システム構成、移行展開方針、運用保守方針、現行データレイアウト、現行データボリューム

補足事項

上記Step3~5については、この後のフェーズである「要件定義(システム要件定義)」と内容的には被ります。この段階での検討は、実現性判断、投資対効果判断のための「素案」「たたき」的な側面が強くなります。想定されるシステム規模やその内容によって、このフェーズでどこまで定義するかは変わってきますし、「基本構想立案」と「システム企画」をひとまとめにやってしまう場合もあります。

参考文献

ここでは「要件定義(システム要件定義)」に関する本をご紹介します。発注企業がITベンダーまかせにしてしまわないよう、最低限の考え方や基礎知識を知る上で役に立ちそうな本を選んでみました。


SE(システムエンジニア)向けに書かれた本だと思いますが、発注企業(ユーザー企業)側の担当者が読んでもまったく問題ありません。むしろ、これからの時代は発注者側こそ読むべきなのかもしれません。システムエンジニアがユーザー企業の業務について学ぶように、ユーザー企業もシステムについて今まで以上に学ぶべき時代なのかもしれません。