要求開発する目的はシステム開発をちゃんとやるため。
エンジニアリング(ex.きちんとオブジェクト指向で構築するなど)をちゃんとやっても
お客さんにそれを認めてもらえず苦戦した。
エンジニアリングはメンテナンスの段階で初めて価値がわかるものだから。
システム開発においては
- 業務管理者
- システム開発者
- 業務担当者
の3者間にそれぞれ壁がある。
それを突き崩すためにみんなで一緒にコタツに入って話を進めていく「コタツモデル」。
現在のシステム開発では、見える化を進めても結局 as is を見える化しているだけ。
そしてシステム要求というのは業務要求から導出されるものであるにもかかわらず
業務要求は隠されている（発注や2次受けの業界構造）。
システム要求はハードでしかないということ。
ドキュメントなど紙だけではダメで、プロトタイプや画面フローなどでシミュレーションし早期のフィードバックを得ることが大切である。
（このあたりはもちろんアジャイルの考え方と一致する）
つまり、to beを早く見せること。
ビジネスオペレーションはユーザー企業が作成できない領域であり、
ITエンジニアが進出すべき領域である。
そして、ドキュメントは保守や再構築の段階でほとんど利用されないことを認識し、
「本当に必要な」ドキュメントだけを作成すべきである。
要求開発はトップダウンのように見えて実はボトムアップであり、トップはそれを承認するだけ。
現状エンジニアはわからないことを何とか形にすることが苦手であり、
論理的に説明できないものを形にすることができるようになるべきである。
論理を追求しすぎると虚像になる。
（象牙の塔ってことですね。）
懇親会
カオスでしたｗｗ
てつ。さんが飛ばし過ぎですｗｗｗｗ
