現状は次の記事に非常にリアルに書かれていると思います。
現状わかったから、じゃあ、どうしようか？という話を書きます。
今回扱わない話
適性ミスマッチについては扱いません。 新卒でIT企業に開発職で入ってみたが、プログラマが向いていないと気づいたときの話です。 これはメンバーシップ型雇用の欠点なので、1企業がどうこうする話ではないので、扱いません。
特に規模の小さな会社では、他の職種への転換が難しいです。 かといって、今すぐジョブ型雇用に転換できるかといえば、新卒の職業訓練する機関が足りてないので難しそうです。
DIVE INTO CODE | プログラミングスクール のような企業が増え、競争によって洗練されると違うのかもしれません*1。
社内教育
ブートキャンプ
現在では、私が新卒であった2002年頃に比べ、ブートキャンプ的な新入社員研修の効率はかなり上げれる社会情勢になってきました。
常駐を要求されない案件が増えてきました。 これにより開発チームは社内で働くことができるようになりました。 現役エンジニアが社内で働いていれば、現役エンジニアの労働時間の一部を研修に当てることができます。
エンジニアのが常駐していると、研修に参加するには案件から抜ける必要があります。 そうすると研修に参加するエンジニアの売上が100%減になるため、研修にかかるコストが大きくなります。 そのため研修の教師役には、何らかの理由で現場から引退したエンジニアが当たることが多かったです。 教師役の知識が制約になって、現場で使っている技術を題材できないことがありました。
次に、今は社会人プログラミングスクールが出てきたため、未経験を新卒採用する必要がなくなりました。 新卒採用の問題点は、入社時期が年間で特定の一日に固定されることです。 これが制約となって、研修スケジュールが決まります。 つまり4月〜5月に多くの新人をまとめて研修する必要があります。 複数の教師役を一時期に投入する必要があります。
新卒採用をやめれば、未経験を通年採用できます。 さらに一人ずつ採用することができます。 すると研修内容を特定の一人に対して設計することができます。 研修を複数人に同時に実施すると、どうしても進みが遅い人に合わせて進める必要があります。 研修効率が良くない人が出てきます。 一人ずつ採用すれば、この効率を上げることができます。
常駐案件をやめ、未経験者を通年採用すると、複数人の現役エンジニアが分担して一人の未経験者を教育することができます。 これは15年前の新卒採用一括研修と比較すると、大きなアドバンテージです。
OJT
一方でOJTに関しては、未だに大きな問題があります。
受託開発にて、教育をプロジェクトマネージャーの責務にするのは無理があります。 プロジェクトの利益と教育のコストは矛盾しています。 プロジェクトの利益を上げるには、教育に掛かるコストを削って
ベテランプログラマでも困るような雑な投げ方で案件を振って、出来たらヨシヨシ、出来なかったら、ハイハイとばかりに全部書き直して納品
するほうが効率が良いのです。
それでも最大限の善意で教育はします。しますが、掛けられるコストの上限はプロジェクトの利益です。 その結果
話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」
になります。
これを打破するには、プロジェクト外の人が教育する必要があると思っています。 そのためにも常駐しない案件は大事です*2。 具体的な施策は模索中です。
プログラミング教育の難しさ
ここからは愚痴っぽい話です。興味がない人は、この辺でお帰りください。
プログラミング教育
教育は難しいです。 私の教育のイメージは「100mの壁へのチャレンジを、1mずつにわけて100回のチャレンジに変える」ことです。 教える側の教育スキルが不足していると、チャレンジの分割が上手くできず、100mの壁を見せてそのまま挑戦させます。
ベテランプログラマでも困るような雑な投げ方で案件を振って
です。多少上手くなっても、50mずつ2つにわけれるとか、せいぜい10mずつの10個にわけれる程度です。
現時点では社会全体で、プログラミング教育のノウハウが蓄積されていません。 おそらく誰も100分割することはできていないのでしょう。 長い伝統があり教えるプロセスが細かく分割されている分野は小学校教育です。 例えば、小学校の算数の授業時間は1011時間*3です。 126営業日です。小学校算数を理解するだけでも、半年ぐらいは掛かるわけです。 それより遥かに複雑なプログラミングの入門が1〜2ヶ月の社内研修でできるわけないのです。
というわけでOJT、さらに主に個人の自習に頼っているのが、現状のプログラミング教育です。 そしてOJTだけで生産されるのは
この術式から得られる人材というのは、どんな要件に対しても、ググり＆コピペで向かい撃つ、素手で熊を殴り続ける、よくわからないグラップラーのような存在
です。
プログラムに関するすごい知見を有した向上心の塊みたいな俊英
になるのは、自習したやつだけです。
インプットとアウトプット
ところが、自習できるには自習のスキルが必要です。 インプットとアウトプットです。
を読んでも、インプットとアウトプットができることが前提です。
インプットは、要するに、日本語が読めて、論理が理解できて、応用できることです。 アウトプットは日本語が書けて、その日本語の論理が通っていて、検証できることです。
アウトプットの訓練はやろうと思えばできます。文章を書かせて添削すればいいのです。 コードレビューとそんなに変りません。ソースコードのイディオムが日本語のイディオムに変わるだけです。 議事録の添削であるとか、読書レポートの添削であるとかやればなんとかなります。 多くの場合は、「喋る日本語」と「書く日本語」が違うことを知らずに「喋る日本語」をそのまま書いていることが原因です。 「書く日本語」のテクニックを教えれば、日本語が書けるようになります。 作業量としては、対象者の元のスキルに依存しますが、A4 2枚のレポートを10回ぐらい書き直させれば、それなりの日本語になります。 お互い時間は掛かりますが、やろうと思えばできます*4。
インプットの訓練は正直わかりません。 インプットはアウトプットと違い目に見えません。 何に躓いているのか見えません。 文法的に読み取れるかどうかの訓練はできると思います。 おそらく問題はそこではありません。
本の題材と自分の経験がミスマッチだった時に、まったく何も読み取れなくなる人がいます。 私は、そういう場合に、話の抽象度を上げてコンテキストを一致させます。 例えば
を読んだ時に、工場長をやった経験も無ければ奥さんに出ていかれた経験はないので、そのまま役に立つノウハウを得ることはできません。 それでも「ボトルネックを探してそれを中心に最適化していく」概念は理解できます。 そこから「ソフトウェア開発プロセスのボトルネックは何か？」という問いを得ることができます。
これができない人がいます。 できないということは未経験の内容の本が読めません。つまり新しい技術を本から学ぶことができません。 この人達は、本を読む時に、その文言をなんのアレンジもせずに、ただひたすら文を暗記しようとするようです。 想像では、娯楽として本を読んだ経験がなく、読んだことある本の90%ぐらいが教科書と参考書だったのではないかと思っています。 そのため「読書とは本の内容を暗記すること」で「想像のために刺激を得るためのもの」とは認識していないようです。 これに対しては読書会のように複数人で一つの本を読んで、読み方の違いを共有するのが良いのではないかと予想しています。 読書会は同期的なイベントで、時間調整の都合があり、今の所試したことはありません*5。
論理的思考力
「プログラミングが論理的思考力を育てる」という言説がありますが、あれは半分正解で半分不正解です。 論理的思考力は
- 論理を読み取る
- 論理を適用する
- 適用を検証する
のプロセスで成り立っています。 プログラミングが強いのは3の「適用を検証する」環境を作るのが早いところです。 ただ、早すぎるのです。1と2を飛ばしても作れてしまうのです。
つまり
ググり＆コピペで向かい撃つ、素手で熊を殴り続ける
部分だけが繰り返せるのです。
「論理的思考力を育てる」面に関しては、検証環境の作りやすさが、既存の手工業よりは簡単という程度に思えます。
- 論理を読み取る
- 論理を適用する
が、できる人にとっては、検証環境の作りやすさは大きな武器になると思います。 これはインプットとアウトプットの能力があると同値です。 プログラミングは、自習できる人は大きく力を伸ばせるが、できない人はグラップラーになる分野のようです。
そして自習に必要な、日本語の読み書きの能力はOJTでは伸ばせません。 プロジェクト中の教育で「日本語の読み書きを教える」って、意味わからないですよね？ ブートキャンプ的な教育でもそうです。日本語教えるよりプログラミング言語を教えたいですよね？ 採用の時に日本語能力でフィルタリングするといいのかもしれません。
*1:現時点は受け入れ側企業としては、プログラミングスクールの卒業生は「即戦力」とは言い難いと感じています。自己投資に一定額以上を投入する気があって、プログラミングに興味がある人のフィルタリングには使えるとは思っています。
*2:一般論として「常駐の多いSIerでは、社内教育制度にある程度制約が掛かる」と判断して良いと思います。
*3:http://www.mext.go.jp/component/b_menu/shingi/giji/__icsFiles/afieldfile/2015/11/09/1363415_006.pdf
*4:ブログをこんだけ書いていて、技術同人誌を3冊書いて、技術同人誌のレビュー経験もある、日本語ライティング強者の感想です。すべてのプログラマが今すぐできることは保証しません。
*5:つまり完全に仮説です。検証していないので、問題設定があっているかすらわかりません。
