プログラミングスキルとは何か?

ちょっと前に初心者にプログラミングを教える約束をした。
だが、そもそも「プログラミングスキル」というものについてちゃんと評価基準を考えたことが無かったので、どのように教えると効果的なのかイマイチ方針が定まらない。
ちょっと真面目に「プログラミングスキル」について考えてみる。

学校ではどうやってプログラミングを教えているのか

自分がどうやってプログラミングを教わったのか記憶を辿ってみよう。
オイラは大学の授業で初めてプログラミングに触れた。プログラミング科目では「指定の処理を行うプログラムを期限までに書き上げて提出する」という課題が多かった。各単元のスニペットコードを書くことが習得基準だった。
だが、それだけでは職業プログラマーとして使いものにならないことが数年の会社員経験で何となく分かってきた。

職業としてプログラムを書く場合、複数人が共同で1つのアプリケーションを開発したり、同じソースコードを長く保守管理する必要も出てくる。
学校の演習課題をクリアするスキル、つまり個人による一過性のコーディングだけでは立ち行かない。

規模の大きいアプリケーションを作るためには、他人と協力したり、長期的なスパンで計画的に開発する必要がある。開発規模をスケールできるように、初期段階からベースを作っておくことが重要だ。コードを適度な粒度に分割し、可読性と拡張性を保つのも重要だ。この辺は他人への配慮という意味合いが強いかもしれない。(長い時間が経ったら未来の自分も他人と言える)

「プログラミング」を「自動車の運転」に置き換えて考えてみる

個々のディティールだけ追っていてもドツボにハマりそうなので、視点を変えて「プログラミングスキル」を別のことに例えて考えてみよう。

「プログラミングスキル」を「自動車の運転スキル」に例えてみてはどうだろうか。自動車の運転なら多くの人がイメージできるし、実際に運転免許を取得して公道を走っている人も多いだろう。

自動車の運転免許を取得するには、大きく分けて以下2つのスキルの習得が必要だと分解できる↓

  1. ドライビングテクニック:純粋に「自動車」という機械の動かし方を学ぶ
  2. 交通法規:公道での社会的な立ち振る舞いのルールを学ぶ

どちらか一方のスキルが欠けていると、自動車の運転免許は取得できない。
それと同様に、プログラミングにも2軸のスキルがあると言えないだろうか。

1つ目は自動車の「ドライビングテクニック」に相当するコーディングスキル、つまり「プログラミング言語を通じて計算機を動かすスキル」だ。自動車を自分の手足のように操る車両感覚みたいなもの。

2つ目は、自動車の「交通法規」に相当する「他人にも理解できるようにコードを安全・シンプルに保つスキル」だ。この2つ目は上手い言葉で言い切れないんだけど、「社会性」の要素を多分に含んだスキルだと思う。「他者」に配慮するスキル。

この「社会性」について例を挙げると、書いた本人しか読めないようなオレオレコードは、学校の課題として提出する分には評価が下がることはあまりない。処理速度の面で言うと、案外こういうオレオレコードの方が速かったりもする。だが、「コードの保守性」という面では最悪だ。コード中に何らかのバグがあって動作しなくなっても、誰も読めないコードでは他者の力を借りることができない。また、書いた本人であっても時間が経つとコードが読めなくなってしまうことが多い。(数ヶ月後の自分はほぼ他人)

仕事としてプログラミングする場合は、保険という意味でも、処理速度を多少犠牲にして可読性・保守性を優先させる。これは、法律で制限速度を設けて安全性を担保する公道と非常に良く似ている。


スポンサーリンク

学校教育と実務の断絶

振り返ってみると、学校の授業で教わるのは上記2つのスキルの中でも特に「ドライビングテクニック」に相当する「プログラミング言語を通じて計算機を動かすスキル」だった。学校の授業では、それに加えて「エンジンの仕組み」や「ハンドルの仕組み」に相当しそうな「データ構造とアルゴリズム」に時間を割いて教えている印象。各種ソートアルゴリズムの比較とか、データ構造によるアクセス効率の違いとか色々あった。(オイラは1度単位を落としましたけど…)

しかし、学校の授業では、自動車で言う「交通法規」に相当する「社会性」のスキルを教えることはほとんど無かったように思う。学校の演習は基本的に「個のスキルを問う」という教え方なので、スキルレベルがバラバラな集団の中で他者との兼ね合いを問われることはない。
情報系の大学の授業なので、プログラミングを通じて計算機の仕組みを学ぶ側面が強かったのもある。

そう考えると、この「社会性」の訓練は職場でのOJTにかなり頼っている要素に感じる。
別に全部学校で職業訓練しろとも思わないが、この「プログラミングにおける社会性」、つまり「一般常識」となる知識は教材もあまり無いので独学しにくい。所属する組織が違えば社会も違うのだから。
もし個人でこの「社会性」を訓練するとしたら、有名なライブラリを触りながら常識的なお作法を読み取っていくぐらいしかできないだろう。


スポンサーリンク

交通法規を知らない超絶ドライバー

社会性の欠けたオレオレコードについて、もう少し自動車に例えてみる。
端的に言うと、暴走族や走り屋のようなイメージだ。公道でトリッキーな運転をしたら、それを見て混乱した周りの車が事故を起こしてしまうかもしれない。映画「ワイルド・スピード」みたいな超絶ドライビングテクニックを公道で展開されるのはかなり迷惑である。

ワイルド・スピード (字幕版)

超絶ドライビングテクニックは、1人で走る分には気持ちが良いし、目的地まで速くたどり着くかもしれない。だが、事故を起こすリスクは高まる。公道には対向車や後続車、原チャリや自転車だっているのだ。走るのが速ければ良いというものではない。

就職活動をしていた頃、面接でたまに「書いたプログラムはどれぐらいの行数ですか?」という質問があった。いちいち記憶していなかったから答えられなかったけど、これはおそらく「ドライビングテクニック」を見積もるための質問で「長い距離を走っていれば自ずと運転は上手くなる」という考えだろう。採用する側が優れた「ドライビングテクニック」を持った人材を採用したいのも理解はできる。新卒のプログラミングスキルにおいて「社会性」はあまり問われない。

ただ、この手の判断基準で厄介なのは、プログラミングコンテストの類の実績を持ったタイプである。もちろんコンテストにもよるのだが、制限時間内にコードを書き上げて評価される競技では超短距離ドライバーが実績を上げてしまう。スニペットは書けるが、アプリケーションとしてまとめることができないタイプで、実はドライビングテクニックも大したことがない人もたまにいる。「スタートダッシュは超上手いが、コースを完走できない」と言ったところだろうか。(競プロ出身者が全員そうだとは言っているわけではありません)

マニュアル車とオートマチック車

時代が進めば、自動車は進化して運転の仕方も多少変わる。国や地域が違えば交通ルールやマナーも変わる。プログラミング言語の違いは、右ハンドル車と左ハンドル車ぐらいの差なのかもしれない。(異論は認める)
ここ最近のプログラミング環境の進化は著しくて、マニュアル車からどんどん快適なオートマ車へ進化しているみたいな感覚。知識が浅くても職業プログラマーにはなれる時代がすぐに来るだろうとも思う。
オイラが初めて触れたプログラミングはJava + Eclipseだったので、超オートマ環境からのスタートだった。翌年のC言語の演習科目では、Linux環境でコマンドラインからコーディングとコンパイルをする演習授業になって結構戸惑ったのを覚えている。(オートマ車からマニュアル車に乗り換えた感じですかね)

人材を採用する側からすれば、AT限定免許取得者よりは、マニュアル免許を持っている人の方が良いだろう。
しかし、業務内容によっては大型特殊やA級ライセンスまで持っている必要はないし、AT限定免許を取得した人ばかりの集団に1人だけA級ライセンスの人がいたところでその実力は発揮されないだろう。販売されている自動車がAT車ばかりなら、AT限定免許の人を集めるだけでも十分に仕事になるはずだ。

何のために自動車を運転するのか

ここまで、だいぶエラそうなことを書いてきたけど、オイラ自身も大したプログラミングスキルを持っているわけではなく、どういうスキルを磨いた方が良いのか思考実験を通じて考えたかったのである。AT限定免許の人を馬鹿にするわけではないし、プログラミングを自動車のように免許制にしろと言いたいわけでもない。

ここまでの話には「何のために自動車を運転するのか」という、「目的」の話が無かった。スキルの話になると大抵この「目的」がスッポリと抜け落ちてしまうが、「目的に対して最適な方法を選択できる」のが何にも勝るスキルのように思う。目的に対して最適な車種と道順を選択すること、つまり段取りを決めることこそが最高のスキル。アプリケーション開発は、決められたコースで競う車種限定レースではないのだから。

AT車で済むことをわざわざマニュアル車でやる必要はないし、目的によっては、自分が使いやすい専用のAT車を作ってしまっても良いのではないだろうか。IDE(統合開発環境)はそうやって進化してきたはずだ。より効率の良い手段が登場したら、そちらを選べばいい。1つの手段に固執してしまうのが1番やっかいで、課題の本質を見誤ってしまう。
プロセスの難易度よりも、少ない労力で結果を出すこと。課題を効率的に解決する「ハッカー」を目指せということなのかもしれない。

というのが、今のオイラの考えです。

こちらは以前流行った書籍。
今回の例えに則ると、公道でトラブルを起こさないための”マナー“を具体的に語っている内容↓

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

追記:ここでの議論は、暗黙的にプログラミングで最終製品(アプリケーション)を作ることを想定して語ってしまったが、近年はデータ分析・観察のためにプログラムを書くことも増えている。この場合、様々なデータ集計コードを書いて、探索的にデータの全貌を解き明かしていくのが目的。
また、機械学習のためのプログラミングでの成果物は、ソースコード自体ではなく、学習済みモデルだ。

「プログラミングは手段」であるし、その利用範囲はどんどん広がっている。スキルを目的と切り離して測ろうとするのは不毛だ。


スポンサーリンク

関連記事

Unityで強化学習できる『Unity ML-Agents』
OpenCVでPhotoshopのプラグイン開発
Deep Fluids:流体シミュレーションをディープラーニングで近似する
ウルトラマンパワードがBlu-Ray Box化!
.NETで使えるTensorFlowライクなニューラルネットワークライブラリ『NeuralNetwo...
エニアグラム
Pythonの自然言語処理ライブラリ『NLTK(Natural Language Toolkit)』
自分の性質
ブログのデザイン変えました
過程を晒す
2020年6月 振り返り
シュールな光景
UnityのMonoBehaviourクラスをシングルトン化する
感じたことを言語化する
Google App Engineのデプロイ失敗
2017年の振り返り
Unityで学ぶC#
書籍『人生は、運よりも実力よりも「勘違いさせる力」で決まっている』読了
CEDEC 3日目
ゴジラ トレーディングバトル
書籍『メモの魔力』読了
フォトンの放射から格納までを可視化した動画
アメブロをしばらく放置してみた
Structured Approach
サンライズの勇者シリーズ30周年
Unity MonoBehaviourクラスのオーバーライド関数が呼び出される順番
今年も「すいかキャンディ」の季節がやってきました
携帯電話ロボット『RoBoHoN(ロボホン)』
2018年10月~11月 振り返り
サンプルコードにも間違いはある?
自分を育てる技術
Google App Engine上のWordPressでFlickrの画像を貼る
二次創作というやつ
AfterEffectsプラグイン開発
ドットインストールのWordPress入門レッスン
UnityからROSを利用できる『ROS#』
PythonのStructure from Motionライブラリ『OpenSfM』
WordPressの表示を高速化する
他人に水面下の苦労は見えない
複数画像から3次元形状を再構築するライブラリ『Multi-View Environment』
Javaで作られたオープンソースの3DCGレンダラ『Sunflow』
学習の到達目標は「点と点が線で繋がるまで」

コメント