経営戦略からシステム企画・調達までをつなぐ

情報システム戦略は、経営戦略や事業戦略を実現するために、情報システムをどのように活用・整備するかの方向性を定めるものです。

例えば『顧客対応を速くする』という事業目標があるなら、単に最新製品を導入するのではなく、現状の業務、顧客接点、データ、既存システムを調査して、どの課題をITで解くかを決めます。

戦略段階では、複数の投資候補について効果、期間、実現可能性、リスク、経営戦略との整合性を比較します。『技術的に可能』と『投資すべき』は同じではありません。

As-Isは現在の業務や情報システムの状態、To-Beは将来目指す状態です。両者を比較することで、解決すべき課題や必要な変化を具体化できます。

業務改善では、業務フローやデータの流れを可視化し、重複作業、待ち時間、手作業、情報の分断などを発見します。

BPRは業務プロセスを抜本的に見直す考え方、BPMは業務プロセスを継続的に管理・改善する考え方として整理できます。単なるシステム置換だけでなく、業務そのものをどう変えるかが重要です。

システム化構想では、経営戦略や情報システム戦略を踏まえて、対象業務、目標、システム投資の対象など大きな方向性を定めます。

システム化計画では、対象範囲、開発や導入の優先順位、概算コスト、期待効果、体制、スケジュール、リスクなどを具体化し、システム化の全体像を明らかにします。

複数のシステムを同時に進められない場合は、経営への寄与、緊急度、依存関係、実現可能性などを考慮して優先順位を付けます。

計画後も、環境変化や実績に応じて投資の妥当性を評価し、必要なら見直します。

業務要件は、経営戦略、システム戦略、利用者のニーズなどを踏まえて、業務として何を実現する必要があるかを定めます。

その後、業務要件を実現するために情報システムへ求める機能を機能要件として、性能、信頼性、セキュリティ、運用性など機能以外の条件を非機能要件として整理します。

異なるステークホルダの要求は衝突することがあります。実現可能性や優先順位、戦略との整合性を確認し、関係者間で合意・承認することが重要です。

要件定義は、設計者が実装方法を決める工程と同じではありません。まず『何を満たすべきか』を明確にします。

調達では、外部製品やサービスを購入するのか、内部開発するのか、外部委託するのかなど、要件に合う調達方法を検討します。

RFIはRequest For Informationの略で、RFPを作る前などに、考えられる技術や手段、製品・サービスの情報をベンダーから集めるための依頼です。

RFPはRequest For Proposalの略で、システム概要、提案依頼事項、調達条件などを示し、ベンダーへ具体的な提案を求めます。

ベンダーはRFPを基に提案書を作成し、システム構成や開発方法などを提示します。見積書は費用を示す文書であり、提案内容の比較評価と合わせて選定に使います。

システム投資では、導入費用だけでなく、運用・保守費用、教育、移行、既存システムとの連携なども含めて考える必要があります。

効果には、売上増加やコスト削減のように金額へ換算しやすいものだけでなく、処理時間短縮、品質向上、リスク低減、顧客満足向上などがあります。

複数案を比較するときは、費用対効果だけでなく、効果が出るまでの期間、実現可能性、リスク、経営戦略との整合性などを合わせて評価します。

導入後も、利用実態や効果を評価して、継続・改善・刷新・廃棄などを判断することが重要です。