少し時間があったので「発注者ビューガイドライン」なるものを読んだ。NTTデータや富士通など大手SIerが共同で作成したものだそうで、要は顧客に分かりやすい外部設計書の書き方をまとめたものだ。「こんな“業界標準”が必要なの」とツッコミを入れたくもなったが、やはり重要だと思い直した。

　外部設計書はシステム仕様のうち顧客から見た機能の定義だから、ここがいい加減だとプログラマ向けの内部設計書も作れず、システム開発なんかできないはずだ。それでもシステムを作れてしまうのが恐ろしいところで、後で顧客から「話が違う」と文句が出て、手戻りが発生、下手をすると火だるまのプロジェクトになる。だから、しっかりとした要件定義を基に分かりやすい外部設計書を作り、顧客と合意するというのは本来、不可欠な作業だ。

　でも、そんなことはSIerなら先刻承知。各社とも分かりやすい外部設計書を作るノウハウを持っているだろうから、改めて“業界標準”のガイドラインを作る意味はどれほどあるのだろう。第一、こうしたノウハウはSIerにとって他社に教えたくない業務ノウハウだろうし、顧客との関係で外へ出せないものもあるはず。当たり障りのない“ノウハウ”ばかりをまとめても、あまり意味がないようにも思えた。

　ただ、これをユーザー企業へ広くアピールする試みとするならば、話は少し違ってくる。そもそも、設計段階でユーザーとの厳密な合意がないままシステム開発に突入してしまうのは、顧客との長年のぬるい商慣行のなせるわざ。最近は要件定義もまともに出来ないユーザー企業が増えているから、外部仕様を完全に確定してから開発に着手するというのが、ますます難しくなっている。

　だから、こうした取り組みをアピールすることで、システム開発の前提として明確な外部設計書による合意が必要であることを、ユーザー企業に周知していけるなら悪くない話だ。「我々もできるだけ分かりやすい外部設計書を作りますので、お客さんもまず、しっかりした要件定義を行ってください。そして設計書をしっかり確認してください」。そうしたことがシステム設計・開発の常識として定着できれば、失敗プロジェクトの火種はほぼ消える。

　もちろん実際にできるかどうかは別の話だが、実はそんな悠長なことを言ってはいられない。外部設計がしっかりできないと、2009年4月以降はSIビジネスに重大な支障が生じる。工事進行基準による会計処理が事実上、義務付けられるからだ。

　進行基準ではプロジェクトの進捗状況に合わせて売上を計上するが、その進捗状況はコストで測る。従って、事前に原価総額を正確に見積もれなければならない。外部設計が確定していないと正確な原価総額なんか出せないから、要件定義や外部設計をいい加減にやっていると、システム開発の売上計上ができないなんていう事態にもなりかねない。

　そんなわけで、要件定義や設計の工程を正すのはSIerにとって緊急の課題。「発注者ビューガイドライン」のような試みは、業界全体がもっと熱心に取り組んだ方がよい。