ふむ。
量産型プログラマを撲滅したい – Yoshihito Kuranuki – Medium
最近、量産型プログラマに遭遇したのだが、彼らを観察しているうちに、量産型プログラマとそれ以外のプログラマとでは、次の点に違いが見られることに気づいた。
- ソースコード・ドキュメント・「『デバッガ上でのプログラムのふるまいや、テストデータを食わせた時の挙動』の観察から得られた知見」などから、対象システムについての一貫性のあるメンタルモデル／概念モデルを、頭の中に構築することができるか否か？
- 頭の中に構築したメンタルモデル／概念モデルが、実際のシステムと比較して、妥当なものであるか否か？
- 頭の中に構築したメンタルモデル／概念モデルが、実際のシステムのそれなりの範囲をカバーしているか否か？
- 頭の中に構築したメンタルモデル／概念モデルに基づいて、理路整然と議論や推測を行うことができるか否か？
- 頭の中に構築したメンタルモデル／概念モデルを、ソースコードやドキュメントという形態に変換出力できるか否か？
「量産型プログラマ」と言われる人は、上記5項目の多く（時には全て）において、何かしらの問題を抱えているように見える。
例えば、先の記事のこのあたり：
ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。
まず、エラーメッセージを見ない。動かないってことは、どこがおかしいかわからない。パラメータを変えてみたり、手をいっぱい動かす。なんとなく勘で直そうとする。動いたから良いじゃないか、と考える。
量産型プログラマは、対象システムについてのメンタルモデル／概念モデルを構築しようとしないか、もしくは構築することができない。つまり、デバッグの時、先にメンタルモデル／概念モデルという明かりを灯すことなく、暗闇を手探りで突き進もうとする。だから、作業の進め方が行き当たりばったりで、見当違いの方向にフラフラと迷走していってしまうことが多い。
一方、量産型じゃないプログラマは、メンタルモデル／概念モデルを構築した上で、モデルに基づいて理路整然とデバッグしようとする。
例えば通信プログラムで、送信側が送ったデータと受信側で受け取ったデータとで一部が一致しない問題が起きたとする。量産型じゃないプログラマは、例えば：
- 送信側で、send処理を実行する直前の送信予定データ
- 送信側のネットワークインタフェース
- 受信側のネットワークインタフェース
- 受信側で、recv処理を実行した直後の受信済みデータ
――といったあたりにモニター（ログ出力やパケットキャプチャ）を仕込んで、問題を再現させて、ログやパケットキャプチャを解析して、どの時点でデータが変化しているか調べることで、バグがあると思われる箇所を絞り込もうとするかもしれない。
（仮に「送信側で、send処理を実行する直前の送信予定データ」の時点で意図せぬ値となっているなら、送信側にバグがある可能性が高いだろう。しかし「受信側で、recv処理を実行した直後の受信済みデータ」まで正しいなら、それ以降に受信側プログラムで行う処理のどこかでデータを壊している可能性が高いだろう。パケットキャプチャの段階で初めて値が壊れているなら、send/recv用のAPIの叩き方を間違えているとか、send/recv用のAPIを提供しているライブラリ／フレームワークにバグがあるとか、いくつかの可能性が考えられるだろう）
すなわち、量産型じゃないプログラマは、その通信プログラムにおける大雑把なデータの流れを把握していて、そのデータフローに基づいて、理路整然と、チェックポイントとして適切な箇所を判断してモニターを仕込もうとするだろう。
これが量産型プログラマとなると、こういった切り分けを一切せずに「送信データと受信データとで、データの一部が一致しないです。どう頑張っても不一致となるんです」という報告を上げる。「いや、そこは問題の切り分けをしようよ……（『どう頑張っても』って、念力じゃバグは直らないよ）」と、量産型じゃないプログラマはため息をつくことになる。
量産型プログラマは、対象システムについて「メンタルモデル／概念モデルを構築し、活用する能力」に欠けている。量産型じゃないプログラマは、メンタルモデル／概念モデルを構築し、活用することで、システムの設計・実装・デバッグなどを進めていく。
（この点は、諸刃の剣でもある。要するに、思い込みに起因する失敗を起こす可能性があるのだ）
私が個人的に興味を抱いているのは、メンタルモデル／概念モデルをめぐる量産型プログラマとそれ以外のプログラマの差異が、どこまで教育で補完できるか、という点だ。
ベテランでも、未経験のプログラミング言語・フレームワークで書かれたソースコードに直面した場合には、対象システムについてのメンタルモデル／概念モデルを構築するのに苦労するし、頭の中で構築したイメージをソースコード化するのに難儀するものだ。技術面の知識の有無がモデル構築絡みの作業パフォーマンスに影響を与えるわけだが、この辺は教育でカバーできる余地があるだろう。
では「メンタルモデル／概念モデルを構築し、活用する能力」そのものについてはどうだろうか？ この方面の教育や訓練については、まだまだ手探り状態というか、未開の大地であるような気がする。コンピュテーショナルシンキングの一部とかが関係してくるような、そうでもないような……？
現状では、私の周囲の量産型じゃないプログラマは、経験を通じて自然とこの辺の能力を獲得してきた人ばかりだ。なので、少なくとも今までのやり方は、「メンタルモデル／概念モデルを構築し、活用する能力」そのものを育てるという観点では、量産型プログラマが存在するという事実より、あまり成功しているとはいえないだろう。
だから、おそらく、今までとは違うアプローチが必要だと思われるが、まだエビデンスが見当たらないので、効果のほどは定かではない。
たぶん、究極的には、向き不向きがあるのだろうけど――教育でどこまで補完できるのか、仮に補完できるとしたらコストはどの程度なのか（従来のいわゆる「文系プログラマ」が生み出される採用・教育システムにて負担できるコストなのか）。非常に興味深い。
