Step6.さまざまなシステム導入方法 ― カスタム開発、パッケージ

ひとくちでITシステムといっても、実際には非常に多様な形態があります。特にここ10年ほどの間、企業に導入されるようなソフトウェアでの形態の多様化が進んでいます。

以前は特注で開発してもらうか、パッケージを導入するか、オフコンのようなハードウェアと一体になったようなものを買うかぐらいしか選択肢はなかったのではないでしょうか。今回はどのような導入形態があり、それぞれ何が利点で、何が欠点かを概観したいと思います。

最近ではさまざまな種類のシステムが企業のあちこちに導入され、混在しているのが現状です。まずユーザがどのようにシステムを使うかでは、次のような種類があります。

時代の流れとしてはWebブラウザに集約されていくでしょうが、モバイル機器からの利用も増えていくと思われます。

次にソフトウェア本体やデータがどこにあるかによっても、次のような種類があります。

最近問題を起こしているのは、集中管理されていないアプリケーションやデータ、つまり図6-2でいえば個々の従業員の持つPCや第三者のサーバにあるものです。

委託先のサーバとは、例えば会社として契約したデータ・センタなどで、これはあまり問題ではないでしょう。最近では従業員が個人やグループの単位で、無償や低料金のWeb上のサービスを業務に利用する場合が増えています。これが第三者のサーバに相当します。

この場合には、どこにどんな情報がどう管理されているのか、会社としてはさっぱり分からないということになってしまいます。専用システム内のデータは安全ではあるのですが、一般的にオープン性に欠けています。

これらの特徴、今後の傾向を考えながら、ITシステム自体の調達方法について見てみましょう。

6.1.外注によるカスタム開発

外注によるカスタム開発とは、ソフトウェア開発業者やSIer （エスアイアー） と呼ばれるシステム開発業者に、自社向けの専用システムを原則的にゼロから開発してもらうことを指します。

今までにまったく存在しないような種類のシステムが必要な場合には、カスタム開発を行うしか方法がありません。また、既存製品が存在する場合でも、特に同業他社との差別化がキーとなったり、特殊な効率化や機能が必要であったり、ノウハウを外部に漏らしたくないようなときには、カスタム開発が優先度の高い選択肢となります。

SIerは、ソフトウェア単体ではなく、ハードウェアまで含めたシステム全体として提案し、納品してくれるところがソフトウェア開発業者と異なるところです。またSIerは、その中のソフトウェア部分を他のソフトウェア開発業者に開発させることもあります。

いずれにしろ、他の調達方法に較べて調達コストは高くなりがちです。その代わりに、必要な部分にうまくカスタム開発を適用すれば、ITシステムの導入によって非常に大きな価値を獲得することができます。

外注によるカスタム開発を行う場合には、以下のような点を十分に検討する必要があります。

（a）要求を誰がどのようにまとめるか

カスタム開発を行う場合には「どんなシステムを実現したいのか」を明確に開発者に伝えなければ、せっかくお金をかけてもそれに見合うだけの価値を持つシステムを得ることができません。

開発者はあなたが考えていることを（少なくとも最初は）よく理解できていないものと考えて下さい。実現したいことが特別なことだからこそ、カスタム開発をしようとしているわけです。

要求をまとめ、開発者に理解できる言葉にして伝えるために、要求工学の専門家を使うことも考えられます。彼らはあなたの業務の領域の専門家ではなくても、インタビューや調査を行い、それを技術の言葉に変換して要求としてまとめて、開発者に伝えてくれるはずです。

もう一つ重要な点は、要求を最初に決めれば後は自動的にシステムができあがってくるわけではない、ということです。要求はどんなに時間とコストをかけても最初は不完全です。また時間が経てば変わっていきます。

さらに開発者が要求を正しく理解して、それを的確に実現するシステムを作っているかどうかのチェックも必要です。これは次のポイント（b）にもつながっていきます。

（b）開発コストや開発工程の正当性を誰がどのようにチェックするか

本来ユーザはシステムの専門家ではありません。そして必要に迫られてカスタム開発を行う場合には特に、システム開発にかかる費用が適正かどうかを判断するのは非常に難しいものです。

また（a）でも述べたように、いったんシステム開発が始まったら、できあがるまで報告を受けながら待っていればいいというものではありません。常に「正しい」やり方でシステムが作られているかをチェックしなければ、使い始めてしばらく経ってから大きな問題が発生します。

ユーザが頭の中で予想しているものと、実際に作られているシステムにズレがないかどうかを開発中からチェックしなければ、いざ納品されてからではもうどうすることもできません。

これらの評価やチェック作業をユーザ企業の情報システム担当者が行うのは一つのやり方です。また、Step5でも述べたように開発監理を専門家に任せる方法もあります。（a）で述べたような要求のとりまとめも開発監理の一部としてくれる場合もあります。

（c）導入保守運用を誰がどのように行うか

長い時間を掛けて要求をまとめ、開発が行われ、納品されても、それはITシステムとしては出発点に過ぎません。このITシステムを使えるようにするためには、まず

• きちんと使える状態にセットアップする
• ユーザに使い方を学ばせる
• 今までのデータを移行する

などの導入作業が的確に行われることが重要です。

ITシステムの運用は自社内で行うことも可能です。この場合はデータやソフトウェアの秘匿性は高くなりますが、運用のコスト（特にハードウェアなどに問題が起きたときの対処など）は高く、しかもそれ自身は本業とは直接関係がありません。

そこで最近では運用をSIerやデータ・センタに任せる場合が多くなっています。その場合には「どこまでが誰の責任か」（サービス・レベル）を明確にする必要があります。

また、ITシステムは運用をしていれば必ず変更の要求が出てきます。また状況や社会、法令の変化に伴って変更が必要になる場合もあるでしょう。その場合に、誰がどの程度の費用で変更に応じてくれるのかを明確にしておかなければなりません。

年間定額で保守費用を請求される場合もありますし、初期構築は安くても変更費用が著しく高額というような場合もあります。カスタム開発の場合、第三者が保守を行うのは難しい場合も多いので、この点は十分考慮の必要があります。