サイトアイコン NegativeMindException

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

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

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

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

職業としてプログラムを書く場合、複数人が共同で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番やっかいで、課題の本質を見誤ってしまう。
プロセスの難易度よりも、少ない労力で結果を出すこと。課題を効率的に解決する「ハッカー」を目指せということなのかもしれない。

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

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



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

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

さらに追記:
システムエンジニアとプログラマーの関係は、編集者とライターに例えて説明できそうな気がする。


スポンサーリンク

関連記事

  • Iridescence:プロトタイピング向け軽量3D可視化ライブラリ
  • 『さらば あぶない刑事』を観た
  • Raspberry Pi 2を買いました
  • adskShaderSDK
  • pythonもかじってみようかと
  • 映画『空の大怪獣ラドン』 4Kデジタルリマスター版
  • 法線マップを用意してCanvas上でShadingするサンプル
  • OpenMVSのサンプルを動かしてみる
  • 感じたことを言語化する
  • オープンソースの顔認識フレームワーク『OpenBR』
  • 書籍『自分の強みを見つけよう』読了
  • CEDEC 3日目
  • オープンソースの顔の動作解析ツールキット『OpenFace』
  • 2015年10月21日
  • 2021年6月 振り返り
  • 2023年5月 振り返り
  • ファンの力
  • Cartographer:オープンソースのSLAMライブラリ
  • WordPressプラグインの作り方
  • 手軽な娯楽
  • リメイクコンテンツにお金を払う歳になった
  • Mr.ビーン
  • 2019年の振り返り
  • Faster R-CNN:ディープラーニングによる一般物体検出手法
  • MVStudio:オープンソースのPhotogrammetryツール
  • 2019年7月 行動振り返り
  • Deep Learningとその他の機械学習手法の性能比較
  • 2022年10月 振り返り
  • FreeMoCap Project:オープンソースのマーカーレスモーションキャプチャ
  • DensePose:画像中の人物表面のUV座標を推定する
  • OpenCV 3.1から追加されたSfMモジュール
  • 2022年3月 振り返り
  • 2021年4月 振り返り
  • UnityでShaderの入力パラメータとして行列を渡す
  • Unity Scriptコーディング→Unreal Engine Scriptコーディング
  • Mayaのポリゴン分割ツールの進化
  • OpenCVの顔検出過程を可視化した動画
  • 機械学習で遊ぶ
  • 映画『地球防衛軍』 4Kデジタルリマスター
  • 2D→3D復元技術で使われる用語まとめ
  • 書籍『鈴木さんにも分かるネットの未来』読了
  • インフラがアウトプットの質を左右する
  • モバイルバージョンを終了