Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

標準レベル未満のメンバーにどう対処していけばよいか? (2/2)

satob.hatenablog.com

satob.hatenablog.com

さて、指標を用意してレベルを可視化した上で、標準レベル未満のメンバーがいる場合にどうしたらいいか?という話。

手を動かす取っ掛かりを作る

まずはどうにかして「業務プログラムは書ける」レベルにする方法を考えることになります。

その点で、エラーメッセージを翻訳する授業は面白い試みですね。「読めない文字には情報はない」という理解を越えるための、「そこに情報がある」ということに気づかせるための翻訳というか。

フレームワークによる補助

「ループが分からなくても書ける」レベルまでプログラミング言語の方を引きずりおろしてくる、という手もあります*1バッチ処理のジョブであれば、入力ファイルを1レコードずつ最後まで処理するのは当たり前だから、そこは雛形としてコードを生成してしまって、プログラマは1レコードぶんの処理を決められた場所に書けばいい、というわけ。ループが書けないプログラマでも、テストやデバッグの手順が理解できる状態まで持っていければ、この方法である程度救えます。

プログラミング研修とその限界

あとは素直に研修としてプログラムをいっぱい書かせるという方法です。ただもちろん、一年叩き込んでもどうしようもないケースもあります。D.E.Knuthの言う「コンピュータサイエンスに向いている人材」が50人に1人か2人(これ元文献なんでしたっけ……)というのと大体同じくらいの割合でしょうか。

他の仕事を割り当てる

さて「どうしようもない」場合は、早めに引っぺがして別の仕事に割り当てないと、実際に安全衛生が悪化するおそれがあります。じゃぁ引っぺがしたあとはどうするか?という話ですが、単にプログラミングの適正がないだけの優秀な人材であればドメインスペシャリストを目指すとか、ほどほどであれば開発に伴う様々なYak Shavingをお願いしたりすることになるだろうと思います。

レベルを上げてどうするか?

さて問題は、上に書いたような方法でプログラミングのレベルを上げた人材がその後どうなるか、という話。

おそらく、上記に書いたような方法はあくまで「業務コードが書けない人」を「業務コードは書ける人」にする方法であって、「業務コードが書けない人」を「アーキテクチャ設計ができる人」にまで持っていくには他の方法が必要だろうと思います。

www.megamouth.info

他にも、上の記事で言う「グラップラー」というか、「コードはバリバリ書けるけどアーキテクチャ設計は一切できない人」というケースがけっこうあるように思います。これが罠で、コードは書くの早いしプログラミングの知識もあるように見えるから、プロマネから見ると「この人をアーキテクトに据えればいいじゃない」としか見えない。

とはいえ、上記に書いたような対策もそれはそれで必要だと考えています。プログラミングを仕事にしている人がみんな、高いスキルのあるエンジニアになりたいと考えている訳ではないですし*2、それなりのスキルの人がそれなりに食っていける状況を作っていきたいところですね。