開発現場の混乱、紛争はRFPで解決されない：闘うマネジャー（2/2 ページ）

[島村秀世，ITmedia]

開発の最上流と最下流の距離

　市民権を得たような状態になっているRFPだが、現実に誰が作っているかといえば、コンサルやシンクタンク系の企業だったり、相変わらずベンダーだったりする。発注者側が主体的に書くというところまでは、まだまだ来ていないようだ。ベンダーが要件定義書作りに失敗してRFPになったのだから、ベンダーに任せるのは論外として、コンサルやシンクタンクというのもおかしい。彼らはアドバイスや指導のプロであって、顧客業務のプロでもなければシステムのプロでもない。むしろ、「どうすれば、発注側が苦労することなくRFPを主体的に作れるか」をアドバイスする立場にあるはずだ。

　RFPの後には従来通り、基本設計/詳細設計/開発が控えている。どうを考えても、RFPという最上流の部分と最下流の開発現場までの距離は極めて長い。とすれば、開発現場の混乱や紛争の発生の原因がRFPで解決されるはずがない。RFP以降の課程の中でも原因を埋め込んできたに決まっている。やはり、やり方を変えなくては駄目だ。

　筆者もSE時代に数々の基本設計書を見てきたが、分厚い割には何が書いてあるのかよく分からないものの方が多かった。詳細設計書に至っては、細かすぎてさっぱり分からないものをよく見かけた。さらに、要件定義を行った者と、基本設計を行った者、詳細設計を行った者がそれぞれ異なるため、内容に一貫性がない。どこまでが基本設計で、どこからが詳細設計かも曖昧であったように思う。

RFPではなくA3の設計書で

　そもそも設計書は、システムで実現したいことをプログラマーがささっと理解し、手早く開発に移れるようにするためのものだ。だったら、要件であるRFPから詳細設計までの各段階を分離して書くのではなく、分かりやすくまとめ1冊の設計書とすべきではないだろうか。また、内容に一貫性を持たせられるように、中心となる者は1人とすべきではないだろうか。もちろん、システムサイズが大きいと1人で行うわけにはいかないので、システムを分割することになる。巨大システムといっても、小さなシステムの集合体に過ぎない。分割は可能だ。

　設計書を1冊にしたとき、分厚いようでは理解しづらい。薄くすべきである。その手法は建築の設計書の中にある。まず、整理した情報を可能な限り1枚の中に詰め込んでいる。そのために建築の設計書では紙サイズをA1としている。A4で情報を伝えるには紙面が狭すぎるのだ。書き方も図を基本とし、文字を補足的に用いるようにしている。実際、「だらだらと設計書を書くな、少ない枚数で多くの情報を伝えろ」と学校でも建築現場でも教えられた。「設計書を細部まで読み込める発注者なんていない。分厚い方が儲かる」と筆者に教えたシステムベンダーの営業とは随分と違うのだ。

　長崎県庁ではRFPではなく、図を多用した詳細な設計書を発注者として用意している。RFPでは自由度がありすぎて、統一感のあるシステムとならないからだ。OSや開発言語がバラバラだったり、システム環境がバラバラでは、ハードの共有さえできない。設計書の紙サイズもA3を用いることにした。

　本来であれば、ここで、設計書お見せできればいいのだが、残念だが紙面では伝えられない。長崎まで来てもらうしかない。百聞は一見にしかずである。

過去のニュース一覧はこちら

プロフィール

しまむら・ひでよ 1963年3月生まれ。長崎県総務部理事(情報政策担当)。大手建設会社、民間シンクタンクSE職を経て2001年より現職。県CIOとして「県庁IT調達コストの低減」「地元SI企業の活性化」「県職員のITスキル向上」を知事から命じられ、日々奮闘中。オープンソースを活用した電子決裁システムなどを開発。これを無償公開し、他県からの引き合いも増えている。「やって見せて、納得させる」をマネジメントの基本と考える。