プログラマの思索

　 「抵抗と戦い自治体の『丸投げ意識』を変えた」――長崎県総務部参事監 島村秀世氏　の記事を読んで、参事監が手がけたシステム設計の手順は、非常に参考になった。
　「建設では許されない設計書が当たり前のIT業界」という言葉は耳に痛い。
　記事では、要求から設計まで下記のような流れが紹介されていた。

【１】画面イメージ
　職員に業務フローに基づいた画面イメージを書かせて、デザイナーに書き直してもらう。

【２】データベース・フォーマット
　SEが画面イメージを基にDB設計する。

【３】システム連携
　ベテランSEが画面イメージとデータベース・フォーマットを基に、システム間連携まできちんと書かれた設計書を書き上げる。

　【１】は画面定義書、【２】はDB定義書、【３】は外部設計書に相当すると思われる。
　手順を解読するとDOAではなかろうか？
　
　また、マネジメント手法として「業務を分割する」ことが大事だ、という。業務を分割する目的は、担当職員が1人で無理なく携われるようにしてベンダーに丸投げする意識をなくすことがあるという。更に、サイズが小さければ失敗のリスクが小さいので、思い切ってやれる、と。

　上記の話を読むと、IT業界で身に着けたテクニックが他の業界でも使えるのではないか、という感触を持った。
　業務を分割する作業は、要件を分割してプログラムに落としていく作業に似ている。
　SEの仕事は何かといえば、業務フローを洗い出し、業務を分割して、外部設計をすること。更に、プロジェクトを運営して、きちんとCloseさせること。
　論理的に業務を設計することとプロジェクト・マネジメントという手法は、公務員だろうが、土建業界だろうが、どこでも通用するのではないか？