関西P2M研究会コーナー
先号　　　次号

「身丈に合うIT化」
－真のROIを重視したIT経営戦略の一方策

関西P2M研究会　戴 春莉　[プロフィール]　：4月号
　現代の経営にとって、情報システムを導入することは必須と言っても過言ではないでしょう。しかし、サブプライムローン問題、アメリカの証券大手リーマン・ブラザーズが経営破綻したことなどから見られるように、世界経済の雲行きが再び怪しくなってきました。そのような環境の中で、経営者はますますROIを重視した投資を行う必要があります。それは情報システム投資に関しても同じ事が言えるのではないでしょうか。
自社業務と比較して処理プロセスが多い、使わない機能が多数ある規模の大きいシステムが導入されてしまうと、投資額に対するリターンが低くなってしまします。また、逆に単純処理機能のみのシステムであれば、自社の強みを発揮できず、システム導入の効果が得られず、投資は失敗に終わります。ゆえに、経営者にとって、いかに「身丈に合うIT化」を行うかが問われています。では、「身丈に合うIT化」とは、一体どのようなものでしょうか。市販されているパッケージだけ使えばいいのか。それともシステム全体を自社主導で開発すればよいのか。私はこの「身丈に合うIT化」を、次のように考えています。
  • 自社の強みである部分は、その強みをより発揮すべく、大事な部分は自社主導で開発する
  • その他の部分はパッケージの導入で最低限の標準化を実現する
このような「揚長避短」(長所を伸ばし、短所を避ける)に成功しているIT化こそ、今後の情報システム設計に必要だと考えております。しかし、自社で開発するとしてもコストが掛かります。如何に最小のコスト、最大のパフォーマンス、短い期間でのシステム開発を求められているのかは、IT調達、IT導入、ITサービス活用などのフェーズで大きな課題になってきています。
　前置きが長くなりましたが、今回のコラムでは、私は特に①自社主導の開発についての一手法である、オフショア開発におけるリスク及び対応策の一部について述べさせていただきます。

＜1＞　上流工程でアーキテクチャ設計を用いて、リスクを最小限まで抑える
①　ユーザーの身になります
　プロジェクトをはじめる前、このプロジェクトは何をするのか？何のためにするのか？・・・など5W1Hを明確にすること、つまりユーザーの立場になりきることが一番重要だと考えています。
　技術者の立場＋ユーザーの目線で現状分析(AsIsの理解)すること、成果物をシミュレーションすること(ToBeのイメージ化)が出来れば上流工程で開発が失敗する可能性を最小限に抑えられます。ここで注意するべきことは、設計者自身がユーザーの立場になれるかどうかです。
　ユーザーの立場になりきる覚悟がないなら、開発の仕様設計段階に踏み込まないことを心掛けるべきだと考えています。
私の場合、ある日「着物縫製加工」管理についてシステムを二ヶ月ぐらいで構築してほしいと経営者から要望がありました。現状などをいろいろと調べる内、現場での指図作業の煩雑、多重伝票の写し、付属品の数の曖昧、顧客加工情報の即時返答不能・・・数百枚～数千枚の着物加工工程について、手作業では対応困難であることが分かりました。
　そして現場担当者、管理者、経営者それぞれのIT化への強い要望を理解することが出来ました。しかし自分が着物の着付けも知らない外国人ソフトウェア技術者なので、着物縫製加工管理のシステム構築について要求分析、要件定義など上流工程を行うことが可能だろうか、と戸惑うことがたくさん有りました。技術上ではIT化することができても、システム設計はかなり難しく、単純な流通業務における伝票のやり取りだけでは済まないことが分かりました。市販ソフトもいろいろと調べましたが、ベンダー企業にもこのシステムはややこしいと言われ、市販システムのほとんどが縫製加工管理の部分を避けていました。しかし、現場に入って、ユーザーの立場になって、二週間ぐらい一緒に作業をしたり、打合せをしたり、皆さんの悩みの深刻さを肌で感じました。それから自分もユーザーの一人になった気持ちで中国チームと一緒に二ヶ月でシステムを完成しました。
　現在このシステムは5年目に入り順調稼動しています。　現場の方々は、もはやこのシステムなくして仕事は進まないと私に言いってくれます。システムに頼り過ぎることはシステムの改善に良くない事ですが、現場の担当者達の評価は、私にとって大変うれしいことです。
②　開発のリスクを最小限に抑えることは上流工程でのアーキテクチャ設計です。
　開発のリスクはたくさん挙げられますが、どれが一番大きな問題でしょうか。
　私の十数年間の現場開発経験から言わせて頂きますと、「仕様書変更」は国境に関係なく、日中技術者がともに悩む問題です。しかし、完璧な仕様書は世の中に存在しません。仕様書の変更も何処の国でもごく当たり前なことです。
　私の場合、仕様変更時に困らないために、いつも仕様の変更があると事前に想定しています。設計上では、プロダクトとモジュール化を並行し、カプセル化できる処理、呼び出すことができる処理、繰り返す処理をアプリケーションアーキテクチャ設計段階で分別させ、インターフェース＋コンポーネントの階層＋構造設計で、できるだけ、ユーザー自身でもプロダクトとモジュールの組み合わせで、仕様変更に対応することが可能にしています。
　ベンダーの立場としてカスタマイズ収入は減りますが、ユーザーにとっては大きなメリットがあるので、ユーザーの立場になれれば自然にこのような設計を行います(ベンダーとしては仕方のないことかもしれません)。

＜2＞　オフショアソフトウェア開発のリスク＝ソフトウェア開発のリスク
　オフショア開発は単にソフトウェア開発の一手段です。
　私の経験では、オフショア開発のリスク管理については、実は海外だけではない、日本国内でも同じことを考えるべきだと思います。海外にしても日本国内にしても同じリスクが発生していますので、リスクに対する認識から言うと国境を区別すること自体がリスクの一つだと思っています。
　今日、グローバル化の進行のため、海外の資源により簡単にアクセスすることができるようになりました。その結果、海外でのソフトウェア開発要望も日々増えています。しかし、グローバルな環境におけるソフトウェア開発も、究極的にはユーザーの立場になって考え、ユーザーの要望に沿って開発する必要があります。そのためには、ユーザーの要求を理解しなければならないので、開発者にとっては技術能力もさることながら、ユーザーとのコミュニケーション能力が今まで以上に必要となるでしょう。

　最小のコスト、最大のパフォーマンス、短い期間でエンドユーザーの要望に応えるソフトウェアの開発は一番理想だとよく言われています。現在日本多数のソフトウェア開発ベンダー企業は日本のユーザーの海外進出と共に、海外でソフトウエアサービス事業を展開しています。グローバル社会で事業を行っている企業が多ければ多いほどオフショア開発の問題が発生します。問題が多いことを真摯に受けとめ、前向きに、素直に問題解決に取り組むことにより、開発プロセスはますます良くなります。完璧ではないですが、皆さんのご存知のように十年前のオフショア開発現場と今の現場とは全然違います。真のROIを求めることはグローバルIT社会の大きなミッションであり、そして、「身丈に合うIT化」はグローバル社会での無駄のない合理的なIT経営を実現する一方策でもあると思います。

※ IT経営の定義：「ビジネス環境が不安定化する状況においては、ますます高性能化、低廉化する。情報通信技術(IT)を駆使して、適切な情報化を推進しつつ、社会的存在として組織を維持・発展させることが求められている。
ご参考： 「IT経営の総合評価」　

ページトップに戻る