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

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

他社メンバーの場合

まず、標準レベル未満のメンバーが自社でなく他社にいる場合ですが、この場合はさすがに手出しのしようがありません。そのためどうしても上位者の人にお任せ、になってしまいます。スキルの低い担当者が単騎で案件にあたっているケースは稀で、大抵はスキル継承のために経験値の高いメンバーとバディを組んでるので、そっちでカバーされることを期待するわけです。

他国の企業で見た事例

他には、私が知ってるインドのIT企業なんかだと、まず情報科学情報工学を修めた人間のみ雇うという方針でした。その上で、適正のない人間は新人研修の間にクビにしてしまいます! 新人向けの案内に「新人研修の試験で◯点を下回ったら解雇です。手続きするから3階のHR Dept.まで来てね♪」みたいなことが軽いノリで書いてあります。実際目の前で何人か斬られていったけど、目にするとキツいもんがあるぞ……他の社員の気持ちを引き締める効果はあるかもしれないけど。

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

あとは日本企業において、自社のメンバーを標準レベル未満のメンバーがいる場合にはどうするか、という訳ですが、まずはどうにかして「業務プログラムは書ける」レベルにする方法を考えることになります。

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

企業内の研修で自分が指導する側に回ったときは、さすがにメッセージの翻訳までは行いませんでしたが、「一つ覚えでいいからエラーメッセージとログファイルは読め」ということを繰り返し伝えました。他の指導員は、新人はツールの機能を知らない(たとえば、ブラウザにDeveloper Toolがついてることを知らない)場合が多いので、その操作方法を教えてたりしました。他にも、スクリーンショットたっぷりの「手順書」を作って、「とにかくこの通りに操作すれば何かしら分かる」という状態に持っていったりとか。どちらにしても、手を動かしはじめられる取っ掛かりを増やすのが効果的なようでした。どうしようもない場合は指導員が直接が手を出す方がいいけど……。

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

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

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

あとは素直に研修としてプログラムをいっぱい書かせるという方法です。受講者にもよると思いますが、自分のいた環境では、半年から一年研修を受けさせる余裕があれば、上記の指標でレベル8~10くらいまでは持っていける場合が多いという印象です。その上で、質問できる受講者の方が伸びが早い。

ただ、一年叩き込んでもどうしようもないケースはもちろんあります。感覚的には3~5%くらいかな? D.E.Knuthの言う「コンピュータサイエンスに向いている人材」が50人に1人か2人ということだから(これ元文献なんでしたっけ……)、大体同じくらいの割合でしょうか。

他の仕事を割り当てる

さて「どうしようもない」場合は、早めに引っぺがして別の仕事に割り当てないと、実際に安全衛生が悪化するので、躊躇しないほうがいい、というのが現時点の認識です。

じゃぁ引っぺがしたあとはどうするか?という話ですが、単にプログラミングの適正がないだけでそれ以外は優秀な人材であればドメインスペシャリストを目指してもらったり、ほどほどであれば開発環境の維持保守や製品の輸出管理といったYak Shavingをお願いしたりすることになるかと思います。

あと、どうしようもない場合には「テスター」になってもらうというケースがあります。これは「製品のテスト計画やテストケースの管理方法を上手く策定して品質を上げるぜ!」というテスターのことではなく、ひたすらGUIからデータを投入するキーパンチャーに近い役割ですね。Seleniumとか使うから、コンピュータの素養ゼロだとさすがにツラいんですが……。

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

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

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

www.megamouth.info

他にも、上の記事で言う「グラップラー」というか、「コードはバリバリ書けるけどアーキテクチャ設計は一切できない人」というのが結構いるんですよ。これが結構厄介で、コードは書くの早いしプログラミングの知識もあるように見えるから、プロマネから見ると「この人をアーキテクトに据えればいいじゃない」としか見えない。その体制でプロジェクトが始まって、さて遅延が目立ちだしたからと外部の人間がヘルプに入ると、まぁアンチパターンの巣みたいなことになってて、その上アーキテクチャ上の未検討事項がまだ残ってる、みたいな……

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