オブジェクト倶楽部夏イベント リンク

オブジェクト倶楽部夏イベントhttp://www.objectclub.jp/event/2005summer/report
@IT:エンジニアとして過ごす「人生の時間の質」http://www.atmarkit.co.jp/news/200506/30/love.html
平鍋さん:An Agile Wayhttp://blogs.itmedia.co.jp/hiranabe/2005/07/post_c5bf.html
天野さん:ぁまんにょだぁ~http://d.hatena.ne.jp/amapyon/20050629#1120075123
松本さん:J.Matsumotoの日記http://d.hatena.ne.jp/J_Matsumoto/20050701#1120231496
伊藤さん:mindmap.jphttp://mindmap.jp/000168.html
赤坂さん:Akaponのメモ帳http://d.hatena.ne.jp/Akapon/20050630/1120097399

担当の要件≠会社の要件

眠る開発屋blog:ソースはぐちゃぐちゃだけど、高いユーザビリティ
上記サイトに書かれているように顧客の業務とシステムが完全に一体化
している場合、新しいシステムを設計するのは難しい。
前のシステムがダメダメな設計でそれをあるべき姿に変更する場合、
アーキテクト的には正しいのだが業務担当者には受け入れられない。
一体化すぎて一箇所変更しようものなら業務全体を見直す必要がでてしまう。
で、見直された業務は既存と違いすぎて担当者がなかなかイメージできず
運用できないと判断されてしまう。
それを打破できないと、新しい環境(OS、言語)で既存と同じものを
作ってしまうだけとなってしまう。
困ったことに既存とそっくりに作れば作るほど業務担当者の満足度は高い。
でもそれって今後の業務を拡張などに配慮できなかったりって問題を
全く解決できていない。
ここで気をつけなくてはならないのは業務担当者の要件が
その会社の要件では無いってこと。
あたりまえのことなのだがなかなか難しい。