​Column Back number

■保険システムよもやまばなし 


第15回: 「ビジネスに資するシステム利活用(4)」

  三寒四温、春を感じる時季となりました、花粉症の方には辛い時期かも知れませんが、如何お過ごしでしょうか?

  さて、「ビジネスに資するシステム利活用」の四回目。システム関連プロジェクトを炎上プロジェクト・デスマーチにしないための勘所を、「計画」、「調達」、「開発」、「導入」、「評価」の各局面毎にお伝えしています。前回、「調達」局面における、「したいことの明確化」(RFP作成)と「適切なパートナー・ソリューション選定と契約」についてお伝えし、この局面では、高い専門性と一致団結して取り組むことが求められるとお伝えしました。特にパートナー・ソリューション選定については、重要で難しいテーマでもありますので、もう少し詳しくお伝えします。

 RFPをベースにベンダーに提案を依頼すると、多くのベンダーから「出来ます」・「頑張ります」的な提案書を受け取ることになると思います。この中から、「適切なパートナー・ソリューション」選定を行うことは、なかなか至難の業!です。ついつい、これまでのお付き合いや、大手ITベンダーだったら的な妄想、コスト最優先! と言った理由で選定していく傾向に流れてしまうと思いますが、ここが頑張りどころ! 提案書をどう読み解き、どう評価していくか!

 提案書の多くは、次のような構成になっています。
「(1)提案にあたっての考え方」、「(2)提案の内容(含む、プロジェクトの進め方、手法・方法論、具体的な実現方法)」、「(3) スケジュール」、「(4) プロジェクト体制」、「(5)役割分担・会議体」、「(6)価格」等々ここから、適合性や実現性、将来の拡張性、コスト等を確認・評価していくことになるわけですが、次のような提案書は、まず、排除しておくべきです。
・如何にも使いまわしの提案書
・自社の強みや優位性のみを主張する独善的で押し付けがましい提案書
・抽象的で具体的な内容が分からない提案書

「貴社の課題やニーズをこのように解釈しました」的な表現で始まる提案書には、誠意も感じられ、その後の展開も期待できます。提案書の選定・評価項目は概ね次のような点になると思いますが、こういった項目はあらかじめ社内での重要性など含めて決めておくことが望ましいと思います。
「(1)RFP理解度」、「(2)要件充足度」、「(3)実現性(会社・担当SEスキル評価、技術的評価等)」、「(4)スケジュール・コスト」、「(5) 役割分担・体制(開発、進捗・品質管理等)」

 これらの項目の中で、評価がなかなか難しいのは、実現性や将来の拡張性に係る点だと思います。実現性は開発体制や進捗・品質管理のやり方により影響を受けますし、拡張性は利用しているシステム技術に影響を受けます。
いずれも、システムの専門性を求められる項目です。だんだん技術的な話に入り込み始めましたので、少し視点を変えてみたいと思います。

 昨年9月に経済産業省から、『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』と言った報告書が発表されました。本報告書については、第9回:「システムの寿命(2)」にでも触れましたが、経産省として、日本のデジタルトランスフォーメーションへ(DX)の出遅れ ⇒国際競争力の低下を憂えてのレポートであり、DXを本格的に展開していく上での課題として、「ビジネスをどう変えるかといった経営戦略の明確化」を言及していますが、それ以前の課題として、各企業が抱える「既存システムの老朽化・複雑化・ブラックボックス化」を技術的負債として指摘し、2025年までには解消すべきと強く訴えているものです。
■DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~
https://www.meti.go.jp/press/2018/09/20180907010/20180907010.html

この中で、システムのブラックボックス化を本質的問題として、その解決に向けては、「単なるシステム再構築、中途半端なオープン化、単純なクラウド化」を行うことなく、適切なマネジメントに基づいた、明確な目標設定、適切なソリューション選択を行っていくことを訴えています。考えるべきソリューションとして特定の具体的な技術を示すことはしていませんが、「システム基盤」の重要性に触れ、「クラウド、共通プラットフォーム、アジャイル」と言うキーワードを出しています。

これを踏まえると、システム基盤の選択肢としては、「クラウド」か「オープンソース」:要は特定のOSやハードウェアに束縛されないようにすることでその環境下で「パッケージ利用」か「スクラッチ(新規に開発)」を選択していくことになります。「パッケージ利用」にあたっては、業務プロセスをパッケージベースに合わせるか、業務プロセスに合わせてパッケージをカスタマイズして行くかの選択肢があります。過剰なカスタマイズは開発期間・テスト期間の延伸要因であり、コスト増にも繋がります。また、システムブラックボックス化の要因ともなりますので、この見極めがポイントになります。

 ウ~ン・・・ システムの専門的な言葉の羅列と言う感じになってしまいました。次回は「開発」局面を踏まえての実現性についてお伝えしていきたいと思います。

K System Planning
島田洋之