システム化計画プロジェクトのポイント！！（その３） 　　　　　　〜つまらないIT仕事をワクワクさせる

　前回の（その１）（その２）に引き続いて、最上流の「システム化計画」における「システム化の目的の定義」の７つのステップを説明していきます。

• 経営課題の整理
• 組織内問題点の分析
• 外的課題の分析
• 現行システムの問題点の分析
• 上記課題に対する解決の方向性の検討
• 解決の方向性の優先度付け
• システム化の目的、目標の定義

今回は「外的課題の分析」からお話しします。

１．外的課題の分析

　外的課題としては、大きくビジネス上の外的課題、とIT上の外的課題に分けて抽出しておくと良いと思います。

＜ビジネス上の外的課題＞

　ビジネス上の外的課題を洗い出すアプローチもファシリテーションのテクニックを使います。

　一般的なやり方としては、検討チームのメンバーを集めてホワイトボードまたはフリップチャートに「SWOT分析チャート」を描きます。

　SWOT分析の中で特に、Opportunity（機会）とThreat（脅威）の欄に洗い出される内容が外的課題となります。

　Opportunity（機会）には、ビジネスにとってチャンスと思われる規制緩和、新規トレンド、景気動向などの外的要因が挙ります。

　Threat（脅威）の欄には、ネガティブな影響を持つ法改正、競合企業の台頭、市場の減退などがあげられます。

　ただし、ここで会社全体のSWOTを試みる、というよりはあくまで今回システム化する対象のビジネスについてフォーカスして行う事が重要です。システム化をすることによって、こうした外的課題に対応できることを整理することが目的であるからです。

　ちなみにSWOTの残りのStrength（強み）とWeakness（弱み）といった内的課題についてもシステム化の対象ビジネスにフォーカスしたうえで整理しておくとよいと思います。あくまで定性的な課題として挙げられると思いますが、会社の人間が自分の会社のビジネスをどう認識しているかがわかると、それを解決していくことがシステム化の目的につながることが感覚的に理解できるためワクワクしてきますよ。

＜IT上の外的課題＞

　システムエンジニアの方にはこちらの課題のほうが、馴染みがあると思います（笑）が、ITの動向に関連する課題です。以下のものが一般的です。

• 新しいテクノロジーの適用可能性
• 今回のシステム化対象と同種類の他のシステム化事例
• ITに関わる標準化の動向

　まず「新しいテクノロジーの適用可能性」についてはビッグデータ、クラウドコンピューティング、セキュリティーなどのいわゆるバズワードとしての新たなシステムの考え方の中で、当システムに関連する情報を整理する、またもう少し技術よりのサーバ、ネットワーク、ストレージなどのハードウェアの性能向上による新しいアーキテクチャ等についての情報を整理しておきます。

　次に「同種類の他社システム化事例」です。こちらは業界における先進的なシステムと呼ばれる他社のシステム化事例の情報を整理して、当社のシステム化に活かすことを考える、であるとか、もっと具体的に競合他社が同種のシステムを導入している場合はそれに負けないことがターゲットになりますので、その情報を整理しておく、などとなります。

「ITに関わる標準化の動向」については、例えばITIL,EAなどの一般的なものから、その業界に特化したシステム標準化の動向などを整理しておくことです。

　次に以上の３つの視点から収集した外部のトレンドが、今回のシステム化にどのような影響を与えるかを考えましょう。

　この「影響度合いを考える」ステップも検討メンバーによるファシリテーションを行う事で、効率的にまとめることができます。皆でワクワクしながら知恵を出し合いましょう！

４．現行システムの問題点の分析

今の時代、新規ビジネスでもない限り、現行システムは必ず存在するはずです。それはホストコンピュータの古いシステムであったり、またPCのエクセルで運用しているなどの現行システムもあると思います。

　一般に「現行システムの問題点の分析」で整理しておくことを挙げておきます。

• アプリケーションの機能、データ、非機能要件
• プラットフォーム（サーバ等）のグレード、年次
• ユーザーからのシステムに対する評価、改善要望
• システムの運用サービスレベル

まず「アプリケーションの機能、データ、非機能要件」では使わていない機能があるか、機能の充足度やデータの精度が現代のビジネスにあっているか、現行の非機能要件としてパフォーマンスが低下していないか、セキュリティレベルが適切かなどの、評価を行います。

「プラットフォーム（サーバ等）のグレード、年次」におけるよくある問題点は、EOSつまりベンダーによるサポート期間の終了です。ホストコンピュータなどの古い機種ではよくあることです。原則、サポート終了した場合に故障などに対応できなくなるため、その前に新システム（ここでは新サーバ）にリプレースすることが必要となります。

「ユーザーからのシステムに対する評価、改善要望」が新システム化の大きな目的になります。ここでは、ユーザーは複数いるため、一人一人聞くよりも先ほどの「組織内問題点の分析」で行ったファシリテーションを活用しましょう。

　関連するユーザーを集めて、ファシリテーターが現行システムに対する問題点、苦情、または改善点を、ホワイトボードやフリップチャートに整理していきます。この場合も事前にアンケートなどをとっておくとベストです。こうして整理された現行システムの問題点、課題はユーザーにとっては現行のビジネスとシステムのフィットギャップになりますから、このステップは非常に重要です。ここで出てくる内容の多くがシステム化の目的になります。

　最後に、「現行システムの問題点の分析」の「アプリケーションの機能、データ、非機能要件」は以外に手間取る事があります。分析のための情報が存在しない、または上手く集まらない事が多いからです。その場合、それ自体が「現行システムの問題点」となります。

• 現行システムのドキュメントが存在しない、またはドキュメントが古く更新されていない
• システムの内容（機能、データ）を知っている人間が少ない
• システムの保守、運用が属人的に行われている

　上記のうちのドキュメントが存在しない場合、この「現行システムの問題点の分析」作業が実施できないばかりか、その後のステップにおける「新業務/システムの概要設計」の際に現行の仕様がわからないため、概要設計が効率的にできない、ということになりかねません。

　従って現行システムのドキュメントが無い場合には、リバースエンジニアリング、すなわちソースコードから仕様を作り直す、といったステップを行う必要がでてきます。

　または、現行システムの仕様を無視して、再度一から、新規システムとして、システムの要件を決めていく方法もありますが、こちらは時間がかかります。現行システムの仕様が有る場合は、開発コストが一から開発するよりも少なくてもすみますし、期間も短くてすむ場合が多いです。ですから現行システムの仕様についてはきちんと整理しておく必要があるのです。（次回につづく）