台風キター

[db]楽観的ロックでいいじゃん！
http://blogs.sqlpassj.org/akiraonishi/articles/5026.aspx
（理由２）がイイ！

理由２について：
業務システムにおいて、情報が更新されるためには、何らかのビジネスプロセスと対応している必要があります。たとえば、「人事情報の変更」というものを考えた場合、人事部に変更届を提出するのが普通だと思います。このときの媒体は何であってもかまいません。変更というイベントが認知される証拠が必要という話です。何らかの届けが提出され、それが認知されて処理されるにあたっては、「審査」というワークフローを通る必要があるかと思います。したがって、審査が通るまでは、トランザクション処理は実行されることがありません。審査が通れば、更新権限を持ったユーザのコンテキストにより、トランザクションが実行されることになります。しかし、このような「変更」〓「審査」といった業務フローの場合、同じ行が複数の人から同時に更新されることは起こりえません。
業務における「変更」には、必ず権限を持つ人の「承認・審査」が伴うはずです。この制約がある限り、「変更」は即座には実行されず、「変更要求」〓「承認・審査」〓「変更実行あるいは変更の却下」の流れになります。この承認・審査プロセスを含めてデータベース化するならば、直接行を更新するという流れにはならず、後述の対照表を用いた更新履歴の管理が求められるはずです。

T字形の考え方の１つ「対照表」が出てきます。納得。サブセットを適切に切り出したデータベースなら更新がグッと減るはず。実践してないけど・・（謝る

TODO:T字形を実案件で実践する

[pm]体育会系PM（とのこと）
・成功のイメージを描けるか？
・実行計画を立てれているか？（最低WBSまで）
・不安要素を認識できているか？
・プロジェクトで発生する問題を地道に一つ一つ潰していくのがPMの仕事。
　⇒問題の発見
　⇒問題の原因究明
　⇒問題の解決策立案

ユーザーとの交渉の姿勢についても聞きたいなあ・・