メディア

ビジネスとITのギャップを埋めるのは誰？：情シスをもっと強くしよう（1）（4/4 ページ）

» 2009年04月24日 12時00分公開

[林浩一，＠IT]

前のページへ 1|2|3|4 　　　　　　

発注側主体の開発が適正なコストを実現する

　SI業界の構造的な問題のために、ユーザー企業は見かけの低コストに惑わされて「質の悪いシステムを高いコストで導入してしまう」という、現在の経済環境下で最も避けたい状況にすぐに陥ってしまいます。

　それを避け、ビジネスの期待に応えられるシステムを“適正なコスト”で実現するには、これまでとは違う取り組み方が必要です。それが「発注者主体の開発手法」です。

発注側主体の開発で悪循環が良循環に変わる

　発注者主体の開発は、3つの悪循環を良循環に変え、ビジネスの期待に応えることのできるシステムを作るための鍵になります。

　1社の取り組みだけで、業界全体を覆う悪循環の構造自体を解決することはできませんが、それぞれの企業で自社のシステム開発にかかわる範囲での正常化を行っていけます。

Triplet Devils：3つ子の良循環（クリックで拡大）

　まず、発注者主体でシステム構築を行うということは、開発業者に開発工程の管理を任せきりにするのでなく、自ら計画通りの開発プロジェクトの進行に責任を負うということを意味します。

　そうすることで、経営者やユーザー部門の期待に応えるITを作ることができるようになれば、情シス部門に対する社内の信頼が高まり、好循環が回り始めます。発注者主体の開発をすることで開発失敗リスクが減らせるのは、発注側の意識の変化が受注側に対してよい影響をもたらすためです。

　「発注側が開発プロジェクトを計画通りに進行させることをコミットする」という態度で臨むことで、受注側にも緊張感をもたらします。発注側からの要請に応えていくためには、プロジェクトマネージャなどのリーダー層をはじめとした体制を強化し、開発工程の効率を高める必要が出てきます。

　開発体制の強化は、開発プロジェクトの開発技術者のモチベーションを高めます。また、最初の時点で見通せなかった仕様などの問題が見つかったときに、発注側が開発ベンダに責任を押し付けるのではなく、一緒に解決しようとする姿勢を示すことが重要です。これにより、開発プロジェクトの一体感が高まり、よいパフォーマンスが出せるようになっていきます。

　また、発注側が必要に応じてコードの中身まで確認することによって、システムの品質を担保する姿勢を示すことで、受注側も品質確保できる体制をとる必要性が生じます。このことは、開発技術者の能力に見合った評価にもつながり、長期的に見たときには優秀な人材を確保し、高い技術力を維持しつつビジネスも分かる高度な人材を育てていく動機付けになります。

発注側に必要なGAPSのギャップを埋める力

　発注者主体の開発を導入することで、ビジネスの期待に応えられるシステムを作っていくことができるのだと仮定すると、それに対して「現在の情シス部門に実施できるのか？」「具体的に何をすればよいのか？」という疑問を持たれる方もいるかもしれません。

　そもそも本連載の目的は、これらの疑問に対して答えていくところにあります。

　筆者の会社では、ITコンサルティングという位置付けでさまざまなサービスを提供しています。この中で、特に力を入れているのが発注者側主体での開発を支援するためのコンサルティングです。

　このサービスでは、発注者側の情シス部門を主な対象として、発注側主体の開発を行うための活動をコンサルタントが支援するとともに、その活動を通じて、情シス部門のメンバーにスキル移管を行っています。

　発注者主体の開発を行うために必要なことは、次に示すビジネスとITの間の4種類のギャップを埋めていくことになります。これら4種類のギャップをGAPSと呼びます。

（1）ゴール（G）のギャップを埋める

　これは、経営にとってのシステムの目的（ゴール）をしっかりととらえ、開発ベンダに徹底していくことです。

　開発ベンダが開発意図を取り違えてしまい、できあがったシステムが経営上の目的を満たさないケースがあります。こうしたことが起きると、経営層がITや情シス部門に大きな不信感を持つことになります。

　開発ベンダに対して、ビジネス上の目的の浸透を意識的に行うと同時に、経営層に対しても、システムにどこまで期待できて、その実現にどの程度のコストがかかるものなのかを正確に伝えていくことが大切です。

（2）アクティビティ（A）のギャップを埋める

　ユーザー部門の業務（アクティビティ）を理解し、開発ベンダとの間で調整を行うことです。

　開発業者との間で非常によく起きるトラブルが、ユーザー部門との仕様調整の失敗です。ユーザー部門からの要求仕様が想定よりも大きくあふれてしまう場合や、取り違えによる手戻りが発生した場合は、コスト超過に直結します。

　情シス部門は、開発ベンダに正確に情報が伝わるような調整を行うとともに、ユーザー部門からの要求に対して優先順位を定め、コスト内に納めるようなリードをしていく必要があります。

（3）プロセス（P）のギャップを埋める

　開発プロジェクトの進行状況（プロセス）を把握し、開発ベンダと一緒に問題の解決を行うこと。

　開発ベンダにプロジェクト管理と問題解決を任せきりにしていると、プロジェクトの状況はすぐに把握できなくなってしまいます。

　また、発注側で対処すればすぐに解決できた問題点が、開発ベンダ側からなかなか上がってこなかったために、遅延になってしまうようなことも珍しくありません。発注側が主体的にかかわり、一緒にプロジェクト管理をすることで問題を早期に解決し、開発ベンダに最大のパフォーマンスを発揮してもらえるようにします。

（4）スキル（S）のギャップを埋める

　開発メンバーの設計・実装の力量（スキル）を把握し、システムの品質を確保すること。

　できあがったシステムで、不具合の発生や性能上のトラブルが発生する原因は、設計や実装の品質にあります。

　設計や実装の内容は、開発ベンダに任せきりにすると、最後までブラックボックスになってしまいます。これらについても、発注側で主体的にレビューを行うことによって、品質を確保することが可能です。

　これらの活動は、これまでシステム開発を開発ベンダに任せきりにしてきた情シス部門のスタッフにとって、すぐに取り組むにはハードルが高いかもしれません。一方で、“実施できない”というレベルのものでもありません。最初は厳しくても、繰り返し実施していく中で、徐々に必要なスキルやノウハウが蓄積してきます。

　次回以降は、実際にそれぞれのギャップを埋めるサービスを行ってきたコンサルタントから、発注側主体の開発についての具体的な話題について詳しく紹介してもらうことにします。

著者紹介

▼著者名　林浩一（はやしこういち）

ウルシステムズディレクター。富士ゼロックス、日本エクセロンを経て現職。オブジェクト指向、XML文書処理、ワークフロー、Webサービス、SOAについて、基礎研究から実システム開発への適用まで幅広く経験。ITを用いた企業変革のための戦略立案／業務分析を行うコンサルティング部門を率いている。現在、発注側主体のシステム開発手法ULSD（User-Led System Development）の確立と、IT技術者のコンサルティングスキル獲得のための新ロジカルシンキングMALT（Modeling As Logical Thinking）の体系化という2つのテーマに注力している。

「情シスをもっと強くしよう」バックナンバー