koeだめ 過去アーカイブ[〜2013-12-14]

最新情報は https://www.pixiv.net/fanbox/creator/3780274 にて

距離が増えると情報は減衰し変質する

普段、ソフトウェアを作る上での「距離」なんてことは考えてみたこともなかったですが、実は「距離」は開発におけるリスクを下げる重要なワードな気がしてきました。

設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、1つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。

設計とコーディングとの「距離」が増えることの面倒臭さや、逆に設計とコーディングのが接近する事のスピード感は、実際に携わっている人なら感覚としてはわかると思いますが、少し離れた人にはなかなか納得していただけない事はよくあります。しかし逆に距離を増やすような「要件をガチッと固めて、あいまいさを排した設計書を作ったら、正しいものが製造できて、試験工数も増えない」という”正論”も強力であり、これを理想として居る人も多いかと思います。

しかし、そこに距離の考えを持ち込むことで、距離が増えることによる情報の減衰と変質というリスクが浮かび上がってきます。「要件をガチッと固めて、あいまいさを排した設計書を作っ」ても、ちんたらやってたら伝わるものも伝わらなくなるから損だよということです。
つまり、要件としてまとめた情報は早く具体的な形にしないと距離が増えると妙な読み違い起したり、メンバーの変化によって細かいニュアンスの読み取りが変わることで、妙ちきりんなものが出来上がったりするよ、という事が言えるようになると思います。

市場の変化が速いからそれに対応するように早くシステムを作らないと陳腐化するよ、というのは前々からあった警句ですが、市場の変化が遅かろうとも要件や設計から実装までの距離が長いと誤ったものを作ってしまう確率が上がり損することになるということも、訴えていくべきではないでしょうか。

ただ、このことはたまたま今の仕事上、発注サイドの技術支援的立場で参画しているから言えるのであって、開発側の立場からはどう進言すればいいのか、まったく思いつきません。
次の課題です。