Lazy Diary @ Hatena Blog

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

平均的プログラマ以前のメンバーにどう対処していけばよいか? (1/2)

note.mu

非常によい知見というか、経験談の集まりで、共感するところも多く、興味深く読んだ。大学のプログラミング実習の話のようだけど、企業においても、新卒採用で情報系以外の学科から採用をしている場合、状況はあまり変わらない。

以下、上記記事から面白いと思ったポイントをとりあげて、下記の指標でいったらどのくらいのレベルなのか?を考えていきたい。

satob.hatenablog.com

どこまで進んだかな......?えっまだそこ?進んでなくない?

ときどき見かける。指標でいうとレベル1~4くらい(スキルミスマッチがかなり大きい状態)と思われる。

ただ「作業が進まない」という事象はプログラミングに限った話ではなく、作業者のレベルによっては一般的な事務作業でも発生する。 たとえば「Excelのこのファイルをこう編集して。期限は明日の正午ね」と作業を伝えると、「はい、分かりました!」というハキハキした返事が返ってくる……返事は返ってくるのだが、作業は完全に止まっていたりする。 作業が止まる様子にもいろいろあって、ファイルも開かずマウスにもキーボードにも触らず膝に手を置いてモニタをにらみつけながらピタリと固まっているケースもあれば、ファイルも開くしマウスも動かすし何かやってるっぽいんだけど全く作業が進んでないケースもある(別の仕事があるのかと思って、「その時間は別の作業をやってた?もし別の作業が残ってるなら、調整しよう」と話しかけると「いや、別に……」とか返される)。

「ぼくはxxxだと思ってるんですけど、動かないんですよ」

指標でいうとレベル5~6くらいかな。プログラムの設計・開発のうち、どこからどこまでをプログラマに行なわせているのか?にもよると思うけれど、「アーキテクチャも決まっていて、業務処理の内容もかなり詳細化されている」という状況でプログラマが作業をする場合、このような事象にはあまり遭遇しない(あるとしたら、アーキテクチャの理解が誤っているケース)。

「エラー出たんですけど、どうすればいいんですか」

自分の経験では、何をさておきコレが圧倒的に多い。

正常に処理が行えたらどうなるか、は手順書にも載ってるし研修でも教えられた……でもそれ以外のケースではどうしたらいいか?が分かっていないために発生している事象なので、何をすればいいか教えれば比較的簡単に脱出できるという印象。

「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるの でしょうか」

というケースも、よく発生するけどすぐに減っていくイメージがある。

10年くらい前には「エラーメッセージの英語が読めない」というケースが多かったけど、最近は減ってきた印象。代わりに、分かってないポイントが「エラーメッセージを読めばいい」「エラーメッセージを読んでいい*1」といったあたりへシフトしている印象がある。

C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの 人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とか にしとけ。

これ、自分の経験では、対処によってはローカル変数ひとつひとつに対して「こういう名前はつけてもいいですか」という質問が発生するので、手放しはマズい(書いてる方は「教科書に書いてある通りにして怒られる訳がない」と思っているので、教科書に書いてある通りの名前にしているだけ)。なので、命名規則の整備が必要です。

これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作 だと思っていた。

「forをアトミックな操作と誤解している」というのは、非常に面白い知見。制御構造と操作を区別できていない、というわけですね。

この知見と、自分の経験とを合わせて考えると、「ループを理解できない勢は、もしかしたらGOTOだったら大丈夫なのでは?」という仮説が立てられる。

私が高校生のときに、C言語はまるきりダメだったがZ80アセンブラは余裕でこなせる、という奴がいました。そいつが言うには「Cは難しすぎる。比べてアセンブラは簡単だ。なぜなら、アセンブラでは何をやっているのかは書いてある通りだから」というわけ。 つまり、構造化プログラミングを適用すると、プログラムの構造理解が逆に困難になる層というのが一定数いて、それが「ループが理解できない勢」として見えているのでは、という仮説です(ただ、GOTOを使えばそういう人たちを救えるとしても、さて実際にそうすべきか、という話は残るわけですが……)。

彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。

これはこれまで見たことない事例。関数を作ることを嫌うのはレベル12くらいだけど、それよりもっと低いように見える。

ループも関数もそうだけど、本来はプログラムの構造を理解しやすくするための仕組みだったはずの抽象化が、理解の妨げになっているのは興味深い。抽象的概念を理解できない人間は確実にいる。

たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。

もはやプログラミング一切関係ないが、「自分がやりたいことを、何も言わなくても理解してくれる人間が必ずいるはずだ」(そして、そこが自分がいるべき場所なのだ)という考えを生きる指標にしている人が結構いるという印象がある。なので、「『ここにいる人間と、コンピュータには』お前の頭の中にあることは伝えなきゃ分からん」というようにしている。

こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか

これ、なぜだか分からないんだけど、メモ用紙じゃなく、ホワイトボードを使って説明すると上手くいくケースが多いらしく、自分のまわりの指導員はみんな持ち運び用のホワイトボードを持っている(SEだからかもしれないが……)。

初心者って関数とかクラスとかめちゃくちゃ嫌うよね。ベタ書き至上主義というか、自分の目の届く範囲に全部置いときときたいというか。

これはまさにレベル12で、「処理の記述順序と実行順序を区別できないので、記述の内容も実行される処理の内容も上から読めば分かる状態を維持したい」がためにこういう行動に出るっぽい。

さて、こういった事例を踏まえた上で、どうやって「業務プログラムは書ける」レベルにまで育成するか……というのはまた別の記事で。

2019/01/20 追記:書きました。 satob.hatenablog.com

*1:エラーメッセージを読んでいいですよ、と言われていないから読んでいないわけですね