■

そもそも、今回の要件の中にはＳＱＬ文の構成がある。
select、update、insert、delete全部ある。
項目を逐一書いていたらそれはそれで時間を食う。
それに加えてテストがある。
データ作りの時間も必要だ。
画面からの連携も確認しなきゃいけない。
時間足りるのか？
画面のレイアウトも厄介だ。
項目数が多ければそれだけ代入文が多くなる。
多くなればそれだけソースが長くなる。
長くなればそれだけ読みづらくなる。
そうはさせないところにソース構成の妙があるのだが、
万人にそれは求められんことは、おもしろソースをちょこちょこ見かける事実でわかる。

この単純な代入式。
単純な項目定義をどれだけ楽に構成できるか？
各種の定義や実装方法をどれだけ楽に似たり寄ったりな形で構成できるか？
これらがテンプレートに求められる要因である。
足りないところは他のツールで補う。
補うことも含めてテンプレートを作る。
作らねば作業の効率化は見込めない。

閑話休題。

自分自身の実績から再度予定を立ててみよう。
「倍の時間をかけてテンプレートなりウィザードを作って２／３の製作時間を実現」
ってのが多かった。
そこからもう１回１個分の時間をかけて１／３の製作時間にしてきた。
今回ので試算してみる
１４日かけて１個分を作りつつ、残りは２／３の時間見積りができるようになり、
２１日かけてさらに１個つくり、残りが１／３の時間見積り可になる。
えっと。
２１日時点で２個できて、残り３個。作業見積り時間が１／３だから３つで７日。
２１日＋７日＝２９日。
おお。なんとか３０日以内に出来そうな気がする。
相方の時間を考えると。
最初の１個は７日。次の１個も７日。
次の１個は７日×２／３で約４．６７日習熟時間があるから＋１日ほどして約６日。
のこり２個はツールの適用ができるから７日×２個＝１４日×１／３でやっぱり約４．６７日。
計算しやすくするのに５日で計算したとして、
７＋７＋６＋５＝２５日。
ちょっとゆとりが見込めそうだ。

しかしまて。
もし作らなかったら。
７日×５個＝３５日。
３５日は７週間なので１週間の遅れ。
ちなみに遅れ始めると何かと管理されはじめたりするので、
１週間が１週間で終わることなどなぜかない。
不思議なことだ。
しかしここに理由はある。
どこで間違ったか？
どこで予定と実績を見誤るポイントがあったのか？
ってか３０日が縛りになった理由はどこだ？

あった。

それは。

人月マジックなあたりだ(゜Д゜)クワッ!!