時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記

最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ

[non_117]

制約が出そろって、「ここまで考えたので、これでいけそう」の感覚が経験知なんだよね。経験知ができてない人はコードを書く寸前まで具体的に設計する必要がありそう（もちろん熟練者も具体的にすると良い）。

[moons]

ただ、どこかで建て始めなければ永遠に家は立たないので、多少不恰好でも家は建てなければならない。

[laiso]

以前は時系列に設計して実装してってやっていたけど最近は問題を分解して考えられるようになったので分かる

[sawat]

「下手の考え休むに似たり」いくら設計に時間を費やしても気づかなかった問題が実装を初めてみるとすぐ分かったりもする（視点がなければ気づかない）。重要なのはその時に柔軟に設計を変えれるようにすることと思う

[knosa]

木にタイヤのブランコ付けるあの画像を思い出した

[mas-higa]

だいたい終わったときに分解の仕方ミスったなぁという気持になる

[mooonymann]

“設計の最初の段階で考えることは、問題の解き方ではなくて、問題の分解の仕方ということになる。”

[to4iki]

解き方ではなく分解の仕方

[tattyu]

この手の問題は振り返りするまでの期間が長すぎる所にある。初期設計が糞でも細かく振り返る事が出来れば大惨事は大体防げるんだけど、初期設計の段階で120%の物を要求しスケジュール絶対は地獄しかない。

[hatest]

大枠がしっかりしてたら細かく分解して回すこともできるけど、だいたい大枠がふにゃふにゃで分解するのに困る

[yetch]

そもそも建てる理由が分からなかったりする

[quick_past]

日本のプロダクトにありがち。とりあえず要求仕様を全部実装して、細かいところは後で詰めよう＝＞時間もコストもなくて放置。結果、メンテや運用しにくいものが出来上がる。生産性も皆無。

[ducktoon]

音読止められんのかい

[TimerTan]

メンバーにこういう人がいるとプロジェクトマネジメントは大変

[pokuwagata]

問題の分割、依存関係の理解が初手なのは分かりみ

[su_zu_ki_1010]

著者の気持ちはわかるけど、受託開発だと契約金額的にそうも言ってられん。

[fumisan]

じゃあ、いつできるのという見通しはどうするのだろう 柱の例えは、意図はわかるけど伝わりにくい 照会（やりたいこと）からインプットに戻した方がいいかなと思う

[peller]

時間をかけても失敗はある。だからやり直し・繰り返しのできるプロセスをってなったんだよね。それを回せないなら、確かにじっくりやるのも手ではある。でも間違うんだよ、人は。

[ghostbass]

制約あるいは制限、性質特質に関するもの（要件）に対する活動を「設計」と呼んでしまうから設計活動のタスクが増え、結果時間が足らなくなり、中途半端な設計で実装を始めてしまい結果として要件を満たさないものが

[daichirata]

良い設計論って大抵こう言う後からの変更に対応できる為にだったりするよね

[miiruW]

私もだいたい3回は書き直す、、

[cl-gaku]

後でひっくり返したくなりそうなところはひっくり返せるような設計を心がけてる

[yamadadadada2]

正しい設計とは、正確だが精密ではない。っていうの理想だけどなかなかできない。

[jacoby]

初期のアーキテクチャ選びは重要。要求に優先順位つけて、優先度の高い要求を満たすアーキテクチャ決め、制約考えて、プランBは用意しておく。重要なところは動かしてから決めるっというのが現実解のように思う。

[saiyu99sp]

完成形がわからないまま作って負債ができるんだよ。将来を見据えた設計ができる人しか時間を区切ってはいけない。

[BOOOOOOOON]

こういうことする最近のアジャイル、QAがめちゃくちゃになりがちなので大枠のRequirementsはさっさと決めてほしい

[moromoro]

このパターンですすめると全体整合性を後回しにしてしまい、開発が進んだ結果、テストフェーズのバグがエグいのばっかりになるが、設計者や開発者はなぜバグなのか理解できない壮絶な状況になる。1stベンダでありがち

[masatomo-m]

データフローとか概念レベルでのモデリングみたいな大方針レベルでの設計はある程度最初に明らかにしてから実装を始めたいけど、実装を始める中でイレギュラーケースが出たらいつだって考え直す余裕は欲しいところ

[mikage014]

手触りを確かめながら作る感覚

[baronhorse]

結局見えなくて3回くらい書き直すことが多い

[asrog]

“設計の最初の段階で考えることは、問題の解き方ではなくて、問題の分解の仕方ということになる。”ああー。これがへたると人増やして開発スピード上げることすら出来なくなるー。