ちょっと乱暴なタイトルだろうなあ、と思いながらつけています。
以前のエントリ
[会社][研修] 「アルゴリズムとデータ構造」が後回しになっているという危惧
でも似たようなことを書いたのですが、自分が関わっている研修では、ついついこういうこと（コードで作ったことのないものを設計させる）に陥ってしまうことがよくあります。カリキュラムの前半で、基礎研修と称して文法やAPIの使い方といった実装手法中心の指導をし、後半の仕上げの総合演習的なもので、グループに分かれて、設計を含めたシステム構築の体験を、というようなカリキュラムが割と私の経験では多いです。
こういうとき、どうしても後半の演習のテーマに新規性を持たせたいという（一度作ったものをまたもう一度作るのは受講者も退屈であろうと考えてしまう）心理が研修コンテンツの開発側に働いてしまうため、新規のアプリケーションをゼロから作るようなものになりがちなんですね。実際、私もそういうカリキュラムを組むことが結構ありました。
しかし、特に新入社員の場合、もともとシステム開発の経験もなく、実装自体の経験も研修内で初めて、という方が多いわけですから、実装結果のイメージが頭に思い浮かばないようなものをいきなり設計するというのは実は相当に難しいはずです。要件定義だけならまだ何とかなる（手も足も出ないわけではない、というレベルの意味でですが）かもしれませんが、いわゆる詳細設計にまでなれば、それがそのまま実装にマッピングされる性質のものですから、なおのこと困難なものになるでしょう。
スケールやレベルがかなり違いますが、IT業界全体の構造にも、これに似たようなものがあるとよく耳にします。大手SIが開発案件を一次請けして「プログラミングは新人研修でやったきり」というような若手SEが要件定義や概要設計を行い、下請けの中堅SIに詳細設計をさせ、さらに中小のSIやフリーSEが実装をする、というような話をよく聞きますが、こういった構造の危うさも、「コードで作ったことのないものを、うまく設計できるはずがない」ということが言えるのではないかと思えます。
ちょっと話がそれました。
研修においては、どうしてもそういうカリキュラムを考えてしまいがちなのです。しかし、当の自分たち自身がどうやって設計の考え方を定着させたかといえば、すでに理解している実装結果と設計の突き合わせみたいなことをやって、納得し、徐々にモノにした、ということが多いのではないかと思うんですね。
研修の場合は指導してくれる講師がいるので、そこまでしなくてもいいのかもしれませんが、しかしできればそれに近いことをさせてあげたいという気持ちもあります。
なかなか、限られた日程でそこまで盛り込むのは難しいところもあるのですが。でも、なんとかしていきたいと思っています。