そーいやわんくまBLOG最近静かだなぁメールないなぁ～と思ってたらメールの配信（メール転送サービス）が止まってたり。
そしてそーいったタイミングでエライ人からの反応があるわけです（汗

縛る(ひよっこプログラミング)にてまつもと氏らしき方からコメントが！！！

【次世代開発フォーラム 2006 Winter】「ツールの進化で少人数での“大規模開発”が可能に，必要なのは割り切りと信頼」---まつもとゆきひろ氏：ITpro
こちらに写真がありますね。男前ですな。

まったく放置してしまってました。中さんが反応してくれてたのでよかった。ありがとうございますm(_ _)m

んで、かなり遅いけれどもいまさら反応・・・

当方小規模開発ばかりやってきたのですが、それでもメンバー間で何度も話し合いをしなければお互いの考えに「差」が生まれてきます。
考え方だけであれば、何度も話をし認識を統一することでその差をなくすことができると思います。
システムやアプリの正しい姿というのはそういったところから見えてくるものだと思います。

そして認識を統一するということは大抵、誰かの考えを（ベースにして）採用し、それを遵守する。ということだと思います。
要は「オブジェクトAは○○のような振る舞いをする。」といった仕様です。

あとはそれを仕様書に落とし込まれるか開発メンバー全員の頭にあるかだと思います。

まつもとさんの言われる信頼というものはここからの話かなぁと時間を置いて再度考えると思ったりしました。
この前段階で作業を任せるということは「Aさんに任せてたオブジェクトAはしっかりと○○のような振る舞いをさせるように考えてくれた！GJ！」
ということで、これは単に仕様決定の作業となる。なのでこの時点で「迷惑をかける」とか「正しいオブジェクト」といった定義を作っている段階。

仕様ができた後であれば「すでにオブジェクトAの振る舞いは決まってるんだからそれを勝手に変えてみんなの迷惑になるようなことはしない。」といった前提をもとに作業を任せることができる。
けどそれって「信頼」というプレッシャー『縛り』であるように思う。
その仕様を理解していないと駄目なわけで、そのためにはやはりメンバー間のコミュニケーションは必須でそれに関するスキルも求められる。

メンバーが3人いてドキュメントがないとき、メンバー2人の認識では「オブジェクトAの振る舞いは○○」なんだけれどもう1人の認識では「オブジェクトAの振る舞いは△△」だったとき、誰の責任なのでしょうか？
そして実はユーザーとしては「オブジェクトAの振る舞いは□□」と思ってたりしたときにどうすればそういった認識のずれを解消することができるでしょうか？

多分「設計書」というなの縛りを設けることが結果的には一番低コストなのかもしれません。

まあ最近は1人でコーディングしてるのでそういったコミュニケーションを行うことも少ないんですけどね^^;
それでもシステム規模が大きくなると「忘れる」とか「勘違い」をする確立があがるので設計書必須と思ってたりします。

まあケースバイケースっす。

ん～まとまんない（汗