経営者不在のIT化は無い

今日は雨。ムシムシと寝苦しい季節がやってきましたね。まだ涼しいからマシですが。。。

さて、今回はパッケージ導入に関して。

業務アプリケーションは、世の中にピンからキリまで。そのため、自社の業務への適応性を勘案して、選択する必要があります。

ただ、以前にも書きましたが、汎用パッケージは全てではありませんが、商業的に規模の経済を狙うべく、ニッチな業界は意識していません。そのため、カスタマイズやアドオンを考慮せざるを得ません。

カスタマイズでは、ソフトウェア開発言語やOS（WindowsやLinuxなどのバージョン）動向、互換性を考慮しなければならず、また、アドオンする際も、元になっているパッケージとの連携は将来に渡って保証される訳ではありません。

業務を細分化し、適用に無理のないパッケージ選定を行うことは大切ですが、これを機に、業務プロセスを変更することも大切です。

但し、ボトムアップでは時間も掛かり、部門間のエゴが出ます。全社目線で最適な解を出すには、トップダウンが欠かせませんね。

ポテンヒットでサヨナラゲーム

ここ最近の天候は猫の目のように変わります。冬物をクリーニングに出せずにいますし、体調管理も大変です。皆さんもお体にはお気を付け下さい。

さて、現在、基幹システムの全面刷新を目指す提案依頼書（RFP:[Request For Proposal]）への対応で私自身、バタバタしております。RFPの作成側も大変ですが、読み込む側も大変です。RFP作成側（要求側）は最善の提案を求め、ベンダー側は競合を排除し選定されるべく必死です。

しかし、このRFPには全ての事項が明記されている訳ではありません。もちろん、ベンダー側は機能や費用、スケジュール、サービス方針等に影響を与えかねない事項は明確にした上で提案する必要があるため、事前に定められた質問方式に則り確認しますが、それでもグレーな部分が出てきます。（RFP提示時点で詳細設計レベルまで落とせないですよね。落としたとしたら、本来提案して貰いたい自社の潜在的な部分が手に入りませんし。）

そのため、プロジェクトにはリスクが付き物です。事前にリスクを回避すべく事項を洗い出し、スケジュールや費用面に於いても、双方の見解を明確にし、SLA[Service Level Agreement]（サービス品質保証）を固めなければなりません。提案書に記載される前提条件はベンダーの自己防衛、RFP作成側（要求側）はこの解釈を怠ってはいけません。

そのため、グレーな部分をシロ・クロはっきりさせなければなりませんが、必ずしも「金を払う側」が主導権を取り、「ベンダーが泣く」のではありません。提案・見積の甘さに起因するのか、双方ともに想定できなかったことかを協議しなければなりません。スケジュール面は調整が必要ですが、費用面では双方が見え形で共有する「プロジェクトリスク費」を設け、運営することも検討要です。

それにしても日本語は曖昧ですね。色んな解釈ができます。アナログとデジタルをどう使い分けるかで、その人のセンスが問われるのかも知れません。。。

要件定義と要求定義

日本語は非常にアナログで、解釈が多岐に渡り、ビジネスに於いては誤解を招くことが多々あります。IT化を実現する上では、「仕様の明確化」は非常に重要です。IT導入の初期段階には、「要件定義」が存在しますね。

まず、「要件定義」とは何でしょう？企業・団体毎に解釈が異なるのでしょうが、一般的には、「システム構築や開発に於いて、どのような機能を実装すべきかを決定すること」で、これを書面化し、各ステイクホルダーで合意形成されたものを「要件定義書」と呼びます。

では、この「要件定義書」は本来、誰が考え、作成するのでしょうか？ユーザ（ITを利活用する部門や企業）側か、それともシステム構築・開発を行うベンダー側でしょうか？難しいところですが、答えは「ベンダー側」となります。

ベンダーが要件をまとめ、開発する？ユーザは各合意の場に居るだけ？いいえ、そうではありません。そもそも、要件を定義する上では、エンジニアによる技術的な見解が必須であり、IT資源調達計画後に選定されたベンダーをパートナーとし、外部リソースであるエンジニアにユーザの要求事項に対する次期システム要件を定義させます。もちろん、ユーザ部門・企業の合意が必要なのは言うまでもありません。

と、言うことは、定義すべき要件が存在する前に、要求事項が存在することになります。つまり、「要件定義」 の前には「要求定義（要求仕様）」が必要だと言うことです。これを書面化したものが「要求定義書」です。

この「要求定義書」の作成はベンダー側の仕事ではありません。ユーザ側がベンダーに提示するためにまとめる定義書です。繰り返しになりますが、ユーザ側は経営戦略に整合したIT戦略の策定を行う中で課題を可視化し、自社（または自部門）の新業務プロセスをまとめます。そして、これを次期ITの要求事項としてベンダーに提示する形式的なもの「要求定義書」として作成します。要求の定義なしにユーザ側はベンダー側に要件定義をしろ、とは言えません。

ベンダー側はこの「要求定義書」を元に「ユーザ要件のシステム定義」をします。ベンダー側はユーザ側が定義 したものを「そのまま」システム開発する訳にはいきません。なぜならば、技術的な見解からの実現可否やコスト面、スケジュール、品質等を勘案しなければならないからです。

もちろん、ユーザ側に技術力があれば要求定義から要件定義にまで発展させ、設計以降をどうするか考えればいいでしょう。

しかし、その反面、ベンダー側には「言われた通りにシステム化すればいい」という考えではいかなくなります。要件定義能力が問われることになります。ここが崩れると以降のフェースがうまく進みません。

とは言え、要求定義もかなり難しい作業です。場当たり的な問題を抽出するのみに留まるケースも多々存在します。どのように進めてゆけばいいのか？そこは、いつでもご相談下さい。一緒に汗をかいて頑張ります！

失敗しない最適なIT導入とは？

昨日は子供の運動会。朝から小雨で「中止かな？」と、思っていましたが雨も上がり、開催時はカンカン照りで日焼けをする始末。1O月とはとても思えない気候にビックリです。

さて、前回は「IT戦略企画書」をまとめ、経営者の合意・承認を得る。そして、この「IT戦略企画書」に基づいた短期計画を抽出し、「IT戦略実行計画書」としてまとめるところまでを書きました。

今回は「IT資源調達フェーズ（どこから何をどんな風に導入する？）」に続きます。ここではコストや納期、その他諸条件を詰める必要があります。

まず最初に情報収集から入ります。最新のIT動向やベストプラクティス、導入方法論などの外部情報に関しては、ベンダーに対する情報提供依頼（RFI:[Request For Information]）を通じて入手し、あわせて、「IT戦略実行計画書」では得られていない具体的な内部情報（内部ベストプラクティスや業務フロー、入出力帳票等）の収集を行います。ここでは、情報の鮮度や精度、信頼性を考慮しなければなりません。

次に、調達要件を明確にします。ベンダーが理解できる形で、現状（As Is）とあるべき姿（To Be）の業務フローや情報モデルを整理します。全体最適の観点からエンタープライズアーキテクチャ（EA:[Enterprise Architecture]）の思想・方法論を用いたり、DMM:[Diamond Mandala Matrix]による分析からDFD:[Data Flow Diagram]による構造化を用いたりします。（ややこしいので、この辺は別途、詳細を書くことにします。）

そして、評価基準を明確にした上で、ベンダーリストの作成及び、提案依頼書（RFP:[Request For Proposal]）の作成、発行を行います。ベンダーの選定は技術力や実績に加え、財務安定性なども重要な評価点となります。ベンダーの数は4～5社程度が妥当と言われています。多すぎれば説明や対応に要する時間が増え、評価も煩雑になります。少ないと比較が難しく、偏ってしまいます。

各ベンダーからの提案を受け、場合によってはデモンストレーションや事例を要求し、選定してゆきます。契約に関しては、変更ルールや瑕疵担保条件、使用権・著作権等の権利、体制、検収条件、教育方針等、明確にしておかないと、お互いが不幸になります。

ざっくりと早足ではありましたが、今回はここまで。要するにベンダーに対しては、自由で「色」のある提案を受けることが大切なので、ガチガチに提案依頼内容を狭めない、とは言え、要求は明確にすることも大切です。 また、提案依頼書（RFP）に対する質問回答も質問者のみならず、全参加者に対し回答集の発行を行って、平準化と正当化を図ることを心掛ける必要があります。それでは次回に！


【画像クリックで拡大表示】