もう開発ベンダー任せにはできない(2) - "お任せ"の連鎖を断ち切れ

前回、システム開発でよく発生するトラブルの例として、要件定義時の予算超過とリリース後のシステムダウンの話を紹介しました。非常によく起きるトラブルなので、経験済みの方も少なからずいらっしゃったはずです。

では、なぜそうしたトラブルが後を絶たないのか。そこには、システム開発業界の社会的構造が大きく関係しています。

今回は、そうした背景を説明したうえで、トラブルを未然に防ぐためにユーザ企業側でできることについて、少し詳しく説明していきます。

トラブルの背後にある「"お任せ"の連鎖」

前回紹介したようなトラブルは、ほとんどの場合、「"お任せ"の連鎖」に原因があると言えます。

企業の経営トップは情報シス部門にシステム開発を任せます。このとき、自分の守備範囲ではないという理由で、最後までほとんど口出しすることなく"お任せ"することが多いようです。その後、情シス部門は開発ベンダーに開発を委託しますが、やはり開発は自分たちの仕事ではないという理由で、開発マネジメントをほぼそっくり"お任せ"するという事象が起きます。

経営トップから見えるのは、おそらくこのあたりまでだと思いますが、実はこの先にもさらにお任せの構造が存在します。

昨今の一次請け開発ベンダーは、その多くがプロジェクト管理のみを行うようになってきています。そのため、一次請けのプロジェクトマネージャがシステムの内容を詳しく知らないまま、品質管理も含めて開発を二次請けの会社に"お任せ"してしまうことが増えているのです。

そのうえ、さらにこの先に三次請けの開発会社やオフショアの開発会社がいるケースも珍しくありません。この結果、実質的なシステム開発作業がはるか先まで"お任せ"されているというのが、現在のシステム開発の実情です。

前回紹介した2つのトラブルは、"お任せ"の連鎖の遠い先で処理された内容が、長い時間をかけて発注企業の経営トップの前に戻ってきたために起きたものと言えます。

追加費用の件は、"お任せ"した先々で要件定義の不足を補う作業が行われ、その作業ミスが積み上がって大きな遅延となり、それが金額となって現れたものです。システムダウンの件では、"お任せ"した先のどこかで行われた技術上の判断ミスが、リリース後のトラブルという形となって現れたものです。

これらはいずれも、本来ならもっと前に気づいて解決されるべき性質のものなのです。

経営トップから始めるユーザ主導開発

こうした状況を抜本的に解決するために私達が提唱しているのが、「ユーザ主導開発」です。

これは、システム開発にユーザ側が主体的に関わり、より良いシステムを作りあげていくという考え方です。開発ベンダーへ完全に任せきりにするのではなく、進捗や品質の確認、プロジェクトの問題解決などにユーザー企業が積極的に取り組んでいくことを意味しています。

「"お任せ"の連鎖」は、お任せした先の状況が共有されない状態で開発が進められているところに問題があります。予算超過やシステムトラブルは開発ベンダー側も好きでやっているわけではありません。それを避けたい気持ちはユーザ企業に優るとも劣らないと言えます。

こうしたトラブルは、問題やリスクに早期に気づいて手を打つことができれば、深刻な結果になることなく解決できることがほとんどです。開発ベンダーがユーザ企業にリスクや課題を適切なタイミングで伝えなかったり、逆に開発ベンダーからの相談をユーザ企業が真剣に聞かなかったり、といったことが起きるために手遅れになってしまうのです。

それに対し、ユーザ企業のトップが情シス部門の活動により深く踏み込み、情シス部門が開発ベンダーの活動により深く関わっていくと、「"お任せ"の連鎖」で見えなくなっていた状況や問題にいち早く気付き、手を打てるようになります。この形態がユーザ主導開発です。ユーザ主導開発は、経営トップが最初の一歩を踏み出すことから始まるのです。

経営トップは俯瞰的な知識で武装する

「ユーザ企業は開発を本業としていない。プロであるベンダーに一括で依頼することのどこが悪いのか? 家を建てるときに自分で現場監督せずに、プロの業者に頼むのと同じではないのか? 」――そんな声が聞こえてきそうです。

ユーザ主導開発は、ユーザ企業が現場監督をするべきだと言っているのではありません。システム開発がちゃんと進んでいるかどうか、ときどき様子を見に行くだけでも結果は大きく変わるという話です。

任せているから、できあがるまでノータッチというのは、数千万、数億円の規模の買い物にしては、いささか関わり方が薄いのではないでしょうか。家を建てる場合なら、週末には建築現場に足を運んで、どこまで進んでいるのか、どんな人達が作っているのかくらいは見に行きたくなるものです。ユーザ企業の経営トップも、自社の情シス部門が開発ベンダーと共にユーザ主導で開発を進めているかどうか、しっかりと様子を見ておくべきでしょう。

「様子を見ると言っても、何をどう見て、どう判断すればよいのかわからない」――これは確かにそうかもしれません。

普通の経営トップにとって、情シス部門からの説明を聞いても、いまひとつピンとこないことが多いというのは仕方のないことです。経営トップには、一歩踏み込もうにも必要最低限の知識が不足しているからです。

持っている知識の差があまりにも大きい場合、同じ状況を見てもその認識結果が異なることがあります。そのため、伝えたつもりのことが伝わらなかったり、ボタンを掛け違えたりしかねません。また、見当違いの指示によって現場が混乱することもありますし、下手に口出しすると足下を見られかねません。

「最近のシステム開発は普通どんな風に進むものなのか? 」、「どんな要員がいてだれがプログラムを書いているのか? 」、「何が難しくて何が簡単なのか? 」、「費用がかかりすぎているのか、そうでないのか? 」――こうした基本的なところがわかっていなければ、開発ベンダーはもちろん情シス部門ともコミュニケーションができません。そして、これが多くのユーザ企業の経営トップが置かれている状況です。

システムに関する知識は膨大です。しかも、技術も開発の進め方も時間とともにどんどん変わっています。もっともらしいソリューションを定期的に持ってくるコンサルタントやベンダーの営業をどこまで信じていいものかも難しいところです。Webや雑誌にはシステム開発に関するさまざまな情報があふれていますが、その多くは開発ベンダーや情報システム部門向けのものでユーザ企業のトップが知るには詳細すぎるものがほとんどです。むしろ、経営トップが的確な判断を下すために必要なのは、技術や開発事情について俯瞰的な知識を持つことです。

本連載では、引き続き、ユーザ企業が開発に主体的に関われるようになるために、経営トップが頭に入れておくべき今どきの開発基礎知識や開発事情を紹介していきたいと思います。

執筆者紹介

林 浩一(KOICHI HAYASHI) - ウルシステムズ ディレクター

1986年大阪大学大学院卒。富士ゼロックスの総合研究所、外資系データベースベンダーを経て、2002年より現職。インターネット電子商取引、SOAによるシステム連携、XMLによるワークフロー制御、非定型ドキュメント管理などの分野で、理論と実践の両面において深い知見を持つ。

現在は、ビジネスとITのギャップを埋めることをミッションとするコンサルティング事業部を率い、ユーザー企業に対して「ITを活用したビジネス企画立案」「PMO組織の立ち上げ」「企業内標準フレームワーク構築」「開発プロセスの導入」などを中心としたコンサルティングサービスを提供している。

また、「ビジネスを成功に導くシステムの開発には、発注者であるユーザ企業の主体的な関わりが大切だ」とする考えの下、「ユーザ主導開発」手法の確立に向けた活動を推進。それを担うことのできる高度IT人材の育成にも注力している。

著書に『間違いだらけのシステム開発』(翔泳社刊)、『ITエンジニアのロジカル・シンキング・テクニック』(IDGジャパン刊)がある。