お盆休みに考える「プロSE論」――ITマネジャーが見抜く設計書：闘うマネジャー（2/2 ページ）

[島村秀世，ITmedia]

設計書の1ページ目に全ての「登場人物」を

　話を本題に戻す。前々回までの話で、発注側においてシステム画面とDBのテーブル・フォーマットが用意された。次は、設計書として仕上げる作業だ。大変そうに思えるが、実は地場のSEに委託するので、職員が苦労することはあまりない。

　詳細に検討され、プロがデザインしたシステム画面とテーブル・フォーマットが用意されている場合、設計書を書くのはSEとして大変ではない。さらに県庁内のハードウェア構成とサンプルとなる設計書を用意しているし、開発言語やWebサーバなども指定してある。SEなら誰でも設計書が書けるはずだ。逆に、これだけ用意されているのに「書けない」というSEがいたら「こいつは偽物だ」と思った方がいい。

　長崎県では、SEが適当にまねて設計書を書いてくると、筆者からこてんぱんにされる。特に1ページ目がいい加減な場合は、これでプロかと叱り飛ばされる。

　業務システムは、最初にログイン画面があり、ログインに成功すると業務画面が出るようになっていることが普通だ。そこでA3紙の左側に、ログイン画面とログイン後の業務画面を書き、右側に、クライアントPC、Webサーバ、DBサーバ間のログインから業務画面が出るまでのシーケンスを書くようにしている。シーケンス図には、文字コード、言語やDBのバージョンの記載がなくてはならない。シーケンスの矢印の上には具体的なプログラム名や引数、応答コードについても書くことが求められる。サーバからの応答がXMLなら、その名称も書かなくてはいけない。空いた場所には、どのディレクトリにプログラムを配置するのか、図示もしなくてはいけない。そして、これらを最初の1ページに収めなくてはいけない。2ページ目に書いてはいけないのだ。

　設計書を読む者は、プログラムを書く人だ。できることなら最初のページでシステムに出てくるサーバなどの登場人物を押さえさせてあげたい。そして、登場人物の特徴である、「サーバのOSは何？」「バージョンは？」「文字コードは？」「言語は？」を押さえさせたい。次は、どこにプログラムを配置するかのルール、プログラム名やXML名や応答コード等の基本的なルールを押さえさせたい。例外処理まで含めて丁寧に書けば、ごちゃごちゃするだけだし、分かりづらいものになってしまう。とてもではないが1ページに収まらない。必要なものは確実に伝え、上手にはしょる。ここがプロとしての腕の見せ所だ。

　別に数ページになってもいいじゃん、と思う読者もいるだろう。しかし、1ページに収めることができないってことは、だらだらと書くことしかできないということにつながる。プログラムを書く人のためではなく、自分に都合の良い分厚い設計書しか書けないSEとなることにつながるわけだ。

　そうなれば、丁寧かつ誠実なSEではないから、「社会的責任を自覚」している人とは思われない。ほら、プロであることから外れた。いずれ排除されるだろう。

プロフィール

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