設計工程とか、設計手法とかで思ってること
某所で設計と実装の話が出てて思ったことだけメモ代わりに・・・
むか〜〜〜しの話、設計をせずに実装をやってた頃によく思ってたこと
- なんでこんな実装しにくい設計書いてるんだろう
- つか、設計って何やってんだ〜
それからちょっと経って判ったことを要約すると
- 設計する人は実装のことはほぼ考えてない
- 設計の前工程も結構だめだめっぽい
これがその組織だけの問題かと思ったらどうも違ってて普通のことらしい。
ハンコさえもらえれば発注元がOKしたからって責任転嫁するのが目的だってｗ
そんなこんなで、それ以降は設計書をあんまり信用しなくなりましたとさ。
めでたしめでたし
それからすんごい時間が過ぎて・・・某社での話
目標
- 中小企業向け業務システムの開発速度向上
手法は元々問わなかったので、要件定義〜実装までの作業をよーく思い出してみた
そして気がついたこと
- 開発の各工程は翻訳をしているだけ
- 要件定義工程はユーザの希望から何となく設計できそうな形に翻訳
- 設計工程はなんとなく設計できそうな形からなんとなく実装できそうな形に翻訳
- 実装工程はなんとなく実装できそうな形を元にコードを書いてテストをする
って事は、受け取った情報の解釈をミスすると手戻りがあるし、翻訳にミスがあるとバグの元だし、そもそも何となくだからミスがある前提だし、最終的に実装までに気がつけばラッキーって状態
これはひどいなぁ〜って思ったので・・・
翻訳作業を可能な限り不要にするために、要件定義〜実装までを単一の概念にまとめてみた。
それに必要なものをみんなでせっせと用意した結果
- 開発の各工程の翻訳作業が激減
- 要件定義で引き出すべきものが明確になった
- 設計工程が単純化＆短期化
- ついでにDB設計も自動化してたｗ
- 実装も単純な部分を全部自動生成して、業務ルールとかこだわりの画面は手作業で追加
そんな感じで、この辺は上手くいったし、開発速度は過去に体験したことの無い位の速度だったのは間違いない
＃根本的な概念が違ってたから必要最小限の用意が出来た後も理解されるのに時間がかかったｗ
まぁ何が言いたいかって言うと・・・
「設計が無い」のが問題の原因じゃなく、「使える設計手法が欠落」してるのが根本的な問題で、役に立たないことをやってるから要らなくなるんだと思う。
