ここ１０年で数件の実績を経て、特定の条件で効果があるソフトウェア開発製造工程の手法が完成しました。
それを私のブログに書き出していきたいです。
仮に「プロトタイピング」と呼称します。
名前の存在しない方法で、説明のときに「プロトタイピングをしまして」と言っていたことによります。

効果がある場合とは次です。
・イニシャルコーディング
・製造チームの規模がたかだか数人（４０画面以下程度？）
・ウィザードレベルのベテランプログラマを一人編成できる
　なおかつ製造工程一ヶ月前にウィザードが製造を始められる
・ウィザード意外のＰＧは経験がない
　経験がないＰＧも最低限の製造の資質は有している

これ以外の場合は他の製造手法を選択するべきだと思います。
あちこちの現場でアジャイルの誤用を見て思うのですが、効果があるパターンを有する手法はありますが、都合のいい万能である手法はないです。
どのようなとき、どのように適応すれば効果があるのか？それを把握すべきです。
手間で呼ばれたときは私がケツ持つわけではないので黙って黙々と手を動かしますが、マネージャーとして呼ばれたときそれでプロジェクトが倒壊しかかっている場合は一言よりは多く言わせてもらってます。

利点は次です。
①　品質とスケジュールを担保しやすい
②　ＯＪＴでＰＧが育つ
③　あとあと役に立つフレームワークやライブラリなどの共通機能が生み出される

①　品質とスケジュールを担保しやすい

ウィザードを模倣することで経験がないプログラマでも一定レベルの品質を確保できます。
共通機能はウィザードが一手に引き受けます。
ウィザードが先行してリーディングサイアーの画面を作るので、その結果より工程を組みやすくなります。
難易度の高い画面はウィザードが引き受けます。

②　ＯＪＴでＰＧが育つ

まず認識を合わせたいのですが、このプロトタイピングでは「他人に教えることができて」技術が身についたと定義します。
プロトタイピングでは他人の模倣を積極的に行い、技術力が低い技術者が製造した画面でも、後続の他の画面の模倣元になります（そのように画面の親子関係をスケジュールする）。
ですので、先駆者となったＰＧはたとえウィザードに対してでも、模倣元親画面の説明をします。
自分で説明できることが更に伸びて、指示待ちスタッフからの脱却までいけます。
また、大事な点なのですが、間違いを咎めない。そして、同じ質問の繰り返しを咎めない。
何が障害になっているのか？これを見てみぬふりをするのが成長にとっての最大の障害です。
次第に要領を得てくれば、同じ質問の繰り返しは減ります。
頭の中に成功体験の連結が発生し、なにが正しいのか、うすぼんやりとでも見えてくるのではないかと思っております。
しかしながら、どれだけ好意的に見ても、そもそもコーディングに適正がないスタッフはごくまれにいらっしゃいます。
その場合は本人とよく話し合って、ロールとミッションを見直すべきです。
勘違いしていただきたくないのですが、私が出会ったなかで、ほんとうに自分を見つめ直されたほうがいいと感じたのはせいぜい２人です。
「つかえない」と聞くほとんどはリーダーの力不足、熱意不足です。
元に私は「使えないこだけど」と若手をあずかり、立派に育て、そして私にそのこを押し付けたくそぼけリーダーにドナドナされていきました。

③　あとあと役に立つフレームワークやライブラリなどの共通機能が生み出される

画面を製造する順番と担当を決めるマネージャーの技量になるのですが、模倣の仮定で共通機能が鍛えられていきます。
しかしながら、この利点に関してはウィザードのセンスによるところが大きいです。
経験も技術もセンスも高い技術者の発想で生み出された設計思想。
これがどれだけ優れているか。
逆にウィザードにこここそ生み出させないともったいない。
他のプロジェクトでも使えますので。

このポストは以上とさせていただきます。
かなりながくなるので、ここまでで。
また、時間を作って具体的な手順などをポストさせていただきます。