HOME > 経営をよくする > SaaS & ASP 活用術

SaaS & ASP 活用術

SaaS&ASPサービス導入マニュアル

Step5.IT化を推進する道筋 ― システムのライフサイクル

ITシステムのライフサイクル 図5-1 ITシステムのライフサイクル

ここでIT化を推進する場合の道筋をいまいちど、まとめておきましょう。 まず第一に、次の二つの点が重要です。

  • いったんITシステムを導入したら、そのシステムと10〜20年という長い期間の付き合いが待っている
  • ビジネスの進化とITシステムの進化は表裏一体の関係にある

つまりITシステムにも、生命と同じように受精から誕生、成長、死、次の世代への交代というライフサイクルがあり、その重なりがビジネスの進化を支えているということです(図5-1)

(1) 発注前 ― 
ユーザ企業経営者のアイデアや意志を受精させる時期
(2) 発注 ― 
胎内でITシステムがはぐくまれる時期
(3) 初期構築 ― 
ITシステムの幼児期

初期構築が終わると、とりあえずITシステムはユーザに引き渡されます。IT化というときに「この段階までしか考えない」「ここから後はまとめて『保守』」という名前でひとくくりにしてしまう場合が多いのですが、この段階ではITシステムはまだ赤ちゃんに過ぎません。実はこの後の段階の方がITシステムとして重要性の高い段階と考えた方がいいかもしれません。

(4) 進化 ― 
成長期、ITシステムは利用を通じて進化し続ける
(5) 引継 ― 
死、次の世代にどうやってうまくIT資産を引き継ぐか

5.1.発注前

この連載で今まで述べてきた部分です。図にまとめておきます。

IT化を推進する道筋 図5-2 IT化を推進する道筋

5.2.発注

この前の段階で作成した提案依頼書 (RFP) を、可能ならば複数の開発組織に提示して、提案書を出してもらいます。RFPの中には次のような項目が必要です。

業務指示/要件

  • どんなことを実現したいか
  • どんなスケジュールが望ましいか
  • どんな制約条件があるか
  • 開発期間中どのようにコミュニケーションを取るか
  • どのように検収、納品するか
  • 契約の種類、金額、支払い日程など

提案書作成要領

  • いつまでに
  • どの程度の規模で
  • どのような目次立てで
  • どのようなフォーマットで提案書を書けばいいか

評価基準

  • 提出された提案書をどのような観点からどのような基準で評価するか

完璧なRFPが書ければそれに越したことはありませんが、不確定な部分はその旨をありのままに書きます。RFPに書かれていない部分への提案や、RFPに書いたことでもよりよい提案があれば、それを出してもらうといいでしょう。

また前述したように、重要なのは初期構築 (いわゆる開発) だけではなく、むしろその後の進化の過程にあります。 ITシステムのライフサイクル全般に神経の行き届いた提案を求めるといいと思います。

開発組織ではこのRFPに対して提案書を書きます。 提案書には、最低でも次のような項目が含まれているはずです。

  • 工数/金額/スケジュールの見積もり
  • プロジェクト管理計画
  • 開発方法論
  • 開発に用いる技術
  • システムの全体像

開発組織の側でも、少なくないコストを自前で負担して提案書を書いているのだということを忘れないで下さい。きちんとした見積もりが出せないようなRFPの内容だったり、提案書提出までに期限が短すぎるようだと、提案書への信頼性は低くなってしまいます。

5.3. 初期構築

もっとも理想的な開発は、開発が始まる前にユーザ側はすべての要求を完全に揃えて、それを開発側に明確に伝え、開発中には何の変更もせず、開発が終わったときには最初の要求がすべてユーザの思ったとおりに実現されていることです。多くの場合、契約やプロジェクト計画はその理想を前提として立てられます。

しかし、そのような理想通りに進んだ案件は今までの経験の中で、ひとつも見たことがありません。と言っても、それは開発組織に能力がなかったからでも、ユーザが先を見通せていなかったからでもありません。ITとはそういうものなのです。

ソフトウェアはその名前の通り「柔らかい」ものですから、目に見えにくく、複雑で変化しやすいものです。一方でコンピュータの基礎は数学 (論理学) であり、人間の曖昧さを許してくれません。「完全な要求」は数学の証明と等しいものになりますが、ITシステム全体を数学の証明として書き下せる能力を持つ人はいないでしょう。

また、開発中に状況が変われば要求も変わるでしょうし、ITシステムとして実現されてきたものを見れば「ああすればよかった」「こうした方がよかった」となるものなのです(図5-3)

リスクの大きすぎる開発 図5-3 リスクの大きすぎる開発

ではどうすればいいでしょうか。ひとつは最初の計画を絶対に守るべきルールとするのではなく、ものごとの進捗を測る物差しとして柔軟に運用することです。経営においても計画はとても重要だと思います。とはいえ、計画がすべてでもありません。

重要なのは最終的な目標を達成することであって、計画の一つひとつを厳守することではないはずです。だから市場の変化に応じて、競合他社の動向に応じて、計画の細部は随時変えながら、最終目標に向かうことが経営の本質です。これはITシステム開発においてもおなじことです。

もうひとつは開発の単位をできるだけ小さくすることです。これは計画をこまめにチェックして、最終目標に向かって機敏に進路変更しやすくすることにもつながります。

一般的に、開発においては要求仕様書、基本設計書、詳細設計書などの文書をたくさん作って、開発が思いどおりに進んでいるかを形にしてチェックします。しかし、この文書がくせ者なのです。ほとんどは(曖昧さを完全に取り除くことができない)日本語で書かれています。

そして残念ながら、その文書と最終的にできあがったITシステムとは、直接の関係はないのです。だから文書をたくさん作るのに工数とお金をかけても、それが最終的なITシステムの正当性には必ずしもつながりません。

そこで、「実際に一部分が動くITシステム」を作る複数の開発に分割します。そこで、部分開発が終わるたびにテスト・リリースをしてもらい、これが本当に思ったとおりのものか、次の開発分は予定どおりで行くのか変更するのかなどを検討します。

これによって、リスクを分散させることもできますし、ユーザが「自分が本当に欲しいのはどういうものなのか」を確認しながら初期構築を進めることもできます(図5-4)

リスクを分散した開発 図5-4 リスクを分散した開発
1|2

SaaS&ASPサービス導入マニュアル目次

  1. Step1.経営にとっての情報化 何のためのIT化なのかを考える[2007年12月26日]
  2. Step2.ビジョンとミッションを明確にする[2007年12月26日]
  3. Step3.業務を可視化する[2007年12月26日]
  4. Step4.ビジネスからシステムへ エンタプライズ・アーキテクチャ[2007年12月26日]
  5. Step5.IT化を推進する道筋 ― システムのライフサイクル[2008年01月30日]
Copyright(c)Metabolics,ltd. このコンテンツの著作権は、(有)メタボリックスに帰属します。著作権者の承諾なしに無断で転用することはできません。