BCGが指摘、「ビルを建てようとして橋をつくりかねない」日本のシステム開発の現実(2/2)

「ビル」を建てようとして「橋」をつくりかねない

　新しいシステムをつくると言ったときに、読者はどのようなものを思い描くだろうか。システム開発の経験者であれば、インフラとしてネットワークやサーバーがあり、その上にミドルウェアやアプリケーションが載って、それぞれのアプリケーションのユーザーインターフェースや、画面の背後で動く処理ロジック、ユーザーの作業をトリガーとせずに作動するバッチ処理、さまざまな処理の結果を他のシステムに受け渡しをするインターフェースなど、いろいろな要素がすべて組み合わさった姿を想像できるだろう。

　しかし、経営陣や事業部の担当者、さらにはIT部門であっても自身でシステム開発をしたことがない社員が同じような解像度で理解しているわけではない。それどころか、何をつくるのかわからないまま、ベンダーへ依頼を出していることも少なくないのが実情だ。

　たとえば、新しいビルを建てるとしよう。こんなコンセプトで、広さ・大きさはこれぐらいで、間取りはこうで、壁や床にこの資材を使い、このような色やデザインで統一感を出すというように、具体的なパーツがイメージできるだろう。その結果、完成度の違いはあれ、出来上がったものが橋だったというような事態は起こらない。

　それがシステム開発になると、発注者側がそうしたパーツを具体的にイメージできなくなる。便利な機能を果たすブラックボックスで、中身がどうなっているか、どんな仕組みで成り立っているのかは見当もつかない。

　それゆえ、つくりたいものを言葉でうまく伝えられないし、そもそも依頼を出すために自分が何を決めるべきかもわからない。要するに、ビルがどういうものか知らない人が、業者を雇ってビルを建てさせているような状況になっているのだ。それでは、自分たちがほしい成果物が得られないのは当然だ。

やるべきこともやらず「コスト増」を嘆く企業も

　認識をそろえる際には、共通語が必要になる。しかし、IT業界ではコンサルタントやベンダーがそれぞれ独自に言葉の意味を定義して話すため、用語の示す範囲や内容が必ずしも統一されてない。実際に、A社ではある工程でここまで決めたのに、B社の計画書には別の工程で実施することになっているという状況がよく見られる。

　特に近年、要件定義と基本設計はどこまでが要件でどこまでが設計かという垣根が大きく崩れていると感じる。企画構想で実施しておくべきことを要件定義フェーズで実施していたり、要件定義で実施すべき内容を基本設計工程で実施していたりする企業が散見される。

　そのような企業に限って、「開発に入ってからプロジェクトコストが大幅に増加した、期間が大幅に延伸した」と嘆いているように思える。本来そのフェーズでやるべきことをやらずに次のフェーズに進んでいるのだから、ある意味必然の結果である。企業や人によって言葉の解釈が異なるため、混乱が生じ、ますます話が通じにくくなっていることに注意しなくてはならない。

さまざまな目的を織り込んでしまった結果…

　システムを構築する目的は幅が広く、特に大型のシステム開発案件ではコストが非常に高いため、さまざまな目的を織り込みたくなってしまう。その結果、目的が総花的になり、何を目的に開発しているのかがわかりにくくなりがちだ。また、効果のすべてを金額換算できるわけでも、単純な足し算ができるわけでもない。

　たとえば、業務効率化や新しく出てきたビジネス要件に対応するのが目的であれば、削減されるコスト、売上貢献や利益貢献など、定量的に費用対効果を測ることができる。しかし、当初は事業上の目的で使うためにシステムを開発しても、長年使っていくうちに状況が変わっていく。使用している製品の販売終了、保守やサポート期間の終了など、ベンダー都合で今のシステムが使えなくなってしまったため刷新が必要ということもある。

　あるいは、社内でメンテナンスできる人材が高齢化して定年退職が近い、改修に改修を重ねてシステムが複雑化（俗にいうスパゲッティ化）し過ぎて何をやるにもコストと期間がかかってしまうなど、システム自体の原因により刷新しなくてはならない場合もある。

　このようなシステム事由の場合、事業側に必ずしも新たなメリットが生じるとは限らず、その効果を説明するのが難しい。その結果、何とか経営会議を通すために、考えうるさまざまな目的を織り込む、効果をこじつける、といった本末転倒な事態を招きやすい。この状態でプロジェクトに大幅なコスト増加や期間の延伸といった大問題が発生した場合、目的が総花的であるがゆえに、どの目的を死守しどの目的は諦めてよいのかという議論ができず、抜本的な対策を講じることが難しくなる。

発注者側と受注者側、どちらが悪い？ と言われても

　システムのイメージが湧きづらく、何を決めればいいか明確ではないのに、規定する要素の量が多いという構造上の特徴により、どこまでが発注者側の責任で、どこからが受注者側の責任かが曖昧になりやすい。

　ビルの例でいえば、ビルのコンセプトを考えて、イメージ図を書き、それに沿ってデザインを考え、色や素材を選定していくのは発注者側の責任だが、それを設計図に落として建築基準法に違反しないように実際に建てていくのは受注者側の責任だ。発注者が設計図を見てこの設計がおかしいと指摘したり、ビルを建てている途中で建築方法が問題だと言ったりすることはまずない。ここから先はプロに任せる領域という共通認識があるからだ。認識合わせしたイメージ図や間取図の通りになっているか、選択した部材が揃っているか、建築法に違反していないかを確認するところは受注者側の責任となる。設計図通りに完成していれば、いざ使ってみたら使い勝手が悪い、イメージとは違うなどの不満が出たとしても、それは的確に要求を伝えなかった発注者の責任だとみなされる。

　それに対して、システム開発の場合はそう簡単に切り分けられない。たとえば、インターネットで買い物ができるようなウェブサイトをイメージしてほしい。アマゾンでも楽天でも、商品を検索し、候補となる商品が表示され、それを購入するという意味では同じと言える。しかし、その使い勝手や見た目の印象、関連する機能、何を売りにしているかは、読者も感じる通り大きく異なっている。

　「インターネット経由で自社製品を購入してもらえるウェブサイトを構築したい」というような粗い粒度で要望をITベンダーに発注したとすると、アマゾン、楽天のどちらのウェブサイトが出来上がっても文句は言えない。一方で、「最初の画面の上部真ん中に検索ボックスがあって、そこに文字を入力すると、先頭の文字を認識して商品候補が出て、そこから商品名を入力して、検索ボタンを押す、もしくはEnterボタンを押すと、検索結果が画面に表示されて……」というように、インターネットで買い物をする上で当たり前とも思える要件まで発注者側が一言一句指定しなければならないかというと、そんな細かい所までは指示する必要はないだろう。

　では、どこまでは発注者側の責任で指定すべきで、どこからは受注者であるITベンダーの責任で担保すべきか、という境界線はどこにあるのか。明確な境界線を定めることは難しそうという感覚は伝わったのではないか。出来上がったシステムの使い勝手が悪かったり、機能が不足したりしているのは、発注の仕方が悪いからなのか、開発者がうまくつくれなかったのか。どちらにも原因があるかもしれない。

　発注者としてここまで伝えれば、後は受注者に任せて大丈夫、受注者としても、発注者がここまで決めてくれれば問題なくつくれる、という線引きが難しいこと自体がシステム開発の難しさであり、各フェーズの落とし穴へとつながっている。