« 実用企業小説 プロジェクト・マネジメント | トップページ | ペアプロの重要性 »

2004/10/13

建設では許されない設計書が当たり前のIT業界

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

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

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

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

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

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

|

« 実用企業小説 プロジェクト・マネジメント | トップページ | ペアプロの重要性 »

プロジェクトマネジメント」カテゴリの記事

モデリング」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

コメント

自分たちで到達目標を決めることができる場合は、設計して開発するのは、あたりまえの話です。問題なのは、法令や政省令の改正に伴う開発です。どうなるかわからない内容をわずか2~3ヶ月でカットオーバーする必要があるシステムで、これを長崎方式でやると永遠に開発できません。物事を単純化してしまうのがマスコミの悪いくせです。マスコミは、レガシーIT業界→悪という構図を面白がっていますが、必要なことをきちんと伝えれば、安くシステムができてみんなWINWINの関係になれる事が真実です。要は、自分でできることは、じぶんでする事がもっとも安上がりで、それもケースバイケースというという結論ですね。また、建設もITも専門家に対する信頼感が薄れている。いや、昔では考えられないモラル低下が始まっていることが真実かもしれません。物事の真実を見極めましょう。

投稿: | 2006/03/23 21:22

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/1671070

この記事へのトラックバック一覧です: 建設では許されない設計書が当たり前のIT業界:

» [dev]トラックバックに突っ込んでみる。 [PM見習いの読書日記]
あきぴーさんから紹介していただいた記事を読みましたが、内容はちょっと気になったので。 http://forza.cocolog-nifty.com/blog/2... [続きを読む]

受信: 2005/01/19 00:46

» 国の発注について [眠る開発屋blog]
ここ経由で知った、「抵抗と戦い自治体の『丸投げ意識』を変えた」という記事。 まぁ興味深いことが色々と書かれています。 オープンソースが云々かんぬんは・・・まぁ偏見とどう付き合うか?ってことですね。 試してみなきゃあ分からない、つーかMySQLだからといって何にでも使えるってわけじゃあないですし。 今までのやり方は,最初から全部SEに委託してしまいますが,私のやり方では3人のプロにそれぞれの専門性を活かした仕事をしてもらっています。また,それぞれのプロには事前の整理が済んだ段階で仕事し... [続きを読む]

受信: 2005/07/26 03:46

« 実用企業小説 プロジェクト・マネジメント | トップページ | ペアプロの重要性 »