図書館で『標準MS-DOSハンドブック』を発見したので勢いで借りてみた。
標準MS-DOSハンドブック (ASCII ハンドブックス)
- 作者: アスキー出版局
- 出版社/メーカー: アスキー
- 発売日: 1984/07
- メディア: 単行本
- 購入: 1人 クリック: 4回
- この商品を含むブログを見る
この本は『エキスパートCプログラミング―知られざるCの深層 (Ascii books)』を少し厚くした程度のサイズなのだけど、驚くべきことにこの1冊で、
――全部網羅されている。特に内部構造周りはキッチリ書いてある。まあ「ある程度分かる人向け」ではあるけど。
現在使用しているWindowsやLinuxからするとMS-DOSは低水準のサポートしかしてくれないし色々と不便だし、不満な点が多い。しかしシステムはシンプルで、個人で全体を把握することは（今日のOSと比較すれば）難しくなかったのだろうと想像させられる。
そういえば昔、ある人が「MS-DOSの頃はバイブル3冊で済んだけど、Macintoshになったら本棚の棚1つ半を埋め尽くすマニュアルが必要になった」みたいなことを言っていたなあ*2。GUIになったことでユーザは便利になった反面、プログラマの苦労は倍増したとか。
今の流行はWebアプリだ。システム全体となるとクライアントサイド（HTML、JavaScriptと各種ライブラリ、時にはブラウザ間の互換性）、プロトコル（HTTP、URI、XML、JSONなど）、サーバサイド（よくある例ではPHP、CGI、SQL、OSやWebサーバやRDBMなどのインフラ構築・運用技術、大規模サービス運用のノウハウ、その他）などなど。見落としがある気がするけど*3、それを無視したとしても必要な技術要素が膨大だということは確実だろう。
「○○を知らない新人」についての考察
年をとると愚痴っぽくなるらしい。年月を重ねるにつれて段々と「今時の若者は……」的なことを言いたくなるのは古代エジプト人も同じだったようで、もしかしたらヒトのDNAに関連する因子でも刻まれているのではないかと疑いたくなる*4。
最近聞いたのが「ASCIIコードを知らない新人」という話で、それを聞いて脱力したというか「ヲイヲイ、それソフトウェア開発をやってる会社としてマズくないか？」と思ったのだけど*5、ここでふと思った。
そういえば自分はASCIIコードのことをいつ知ったのだろうか？
私の場合、プログラマになる前に半年ほど情報処理関連の職業訓練を受けていて、ASCIIコード自体の存在はそこで知った。でもそれ以前からJIS（ISO-2022-JP）、シフトJIS、EUC-JPが身近な存在だった訳で、ASCIIコードというか文字コードについて意識するようになる下地ができていたように思う。
プログラミングを始めたのは21世紀になって数年経った頃だけど、先に書いたようにパソコン自体はギリギリ20世紀の頃から使っていた。テレホーダイでプロバイダのアクセスポイントにダイヤルアップ接続していた頃はWikiもblogもなくて「Webサイトを公開する＝エディタでHTML書いてFTPでアップロードする」だったので、比較的初期の頃からテキストエディタを使っていた*6。そんな中で日本語圏特有の複数の文字コードが混在する環境に自然と慣れていったように思う。*7
誤解の無いようにハッキリさせておこう。当時の私は多少パソコンに詳しかったものの、正直な所素人に毛が生えた程度だった。プログラミングやシステム構築／管理などの世界とは全く無縁だった。そんな素人でも文字コードの違いについて身近なところで意識する機会はあった。
翻って、例えばここ数年のことを考えてみたとして、日本語圏の一般人がパソコンなりタブレットなりを使っていて文字コードのことを意識することはあるだろうか？ 思いつくのは「ブラウザが文字コードの判定を間違えて文字化けしてしまった」ぐらいだけど、昔はともかく最近はブラウザで文字化けが起こること自体が減っているように思う。*8
要するに最近はパソコン等の機器のユーザが文字コードについて意識する機会が激減したのではないだろうか？ その状態でASCIIコードについて学んだとしても単なる知識にしかならず、そのうちに忘れてしまうのではないか？ 情報処理試験の対策で勉強しただけなら尚更忘れてしまうのではなかろうか。
プログラマはシステムを便利にする為に抽象化層を何層も重ねてきた。そしてユーザは重ねられた表面に触れればよくなり、中身を気にする必要はなくなった――その分、中身のことなど気にも留めなくなった。だがプログラマは中身を知っていなくてはならない。
抽象化層が厚くなるにつれて、コの業界に入ってくる人と中の人のレベル差が広がってきてはいないだろうか？ 例えば単なるパソコン好きな人が新人枠や未経験者枠でコの業界に飛び込んだとして、20年前のパソコンユーザと今のユーザとでは抽象化層が薄かった20年前のユーザの方が色々と知っていたのではないか？（層が薄い分だけ自分で何とかしなくてはならなかったから）
だとしたら、私達は20年前の新人が受けた新人教育と同じレベルの内容を今の新人に対して実施するだけでは不十分だということになる。もとより未経験者の教育は大変なのだけど、そうではない新人――例えば大学や専門学校で情報処理やら何やら学んできたという触れ込みの新人を教育する時でさえ、「これぐらい知っているだろう」と自分の世代の常識に照らし合わせて考えてしまいがちな（かつては基礎の基礎だった）部分を教えなくてはならない可能性がある。
それに「抽象化層が厚く」なったという仮定が正しいのなら、上層に重ねられた部分――その昔は高度な内容だったけど今では一般的になった事柄についても教育を行わなくてはならない。ベテランが業務や自習を通じて20年かけて習得し構築してきた各種技術が、今年の新人がスタートの時点で理解すべき事柄となる。
OJTの罠――分厚い抽象化層の果て
しかし問題はそれだけだろうか？ 仮に前項の推測に基づいて座学を含む新人研修の時間と密度を増やしたとして、その後に日本のソフトウェア開発的OJT*9の精神でプロジェクトに投入して後は業務漬けの日々――という従来のパターンに問題はないだろうか？
『標準MS-DOSハンドブック』を思い出してほしい。あの頃は何もかもがシンプルだった。システムは現在ほど抽象化されてなく、低水準で且つ危ないこともできる野蛮さがあった。正直、不便だった。でも1つ1つの要素がシンプルで、個人で全てを把握することは今よりも容易だった。
今はどうだろうか？ 抽象化層が厚くなった分だけシステムの中身も大きくなった。個々の要素も肥大化し、それぞれの要素ごとに何冊もの専門書が出回っている。1つの要素だけでも専門的な知識を必要として――時には1つの要素に対して異なる方向の専門家が誕生していることもある。複数の要素にまたがって知識を持っている人材は優秀な部類だと言われ、全ての要素を見渡せる人材は一握りとなってしまった。
何か言いたいかというと、1つの分野にて必要な技術が高度化している現在では、業務を通じて学べる技術は1つの分野の中のことだけに限定されてしまう、ということだ。正確に書けば「1つの分野に精通するだけも一苦労」ということだ。
昔はシステムの個々の要素が小さくシンプルだったので、OJTにてある要素を新人に任せることに心理抵抗が少なく、新人はその要素を理解しやすく*10、周囲はフォローしやすかったのではないか？ 個々の要素が小さく理解に必要な時間が少なくて済むこともあり、色々な要素を担当しても問題なかったのではないか？ つまり業務を通じてある分野に精通することが今よりも容易で、複数の分野に通じることもそれほど難しくなく、場合によってはシステム全体を見渡せるようになることも可能だったのではないか？
この辺りは私は昔のことを知らないので想像になってしまうのだけど*11、概ねその通りだったと仮定しよう。その当時の水準を物差しとして「OJTでも（昔と同じような按配で）人材は育つ」と考えているとしたら、それは間違いだ。今では贔屓目に見ても「OJTで放り込んだ先でやらせた内容に精通した人材」しか育たない。むしろ高度化が進んでいるので、個人的に自習でもしていない限り「その分野に限っても中途半端な知識しか持たない人材（他の分野は全く知らない）」にしかならないだろう。
実際の所――これは私の周囲での話で他所では不明だが――技術的に一日の長がある人は業務以外の機会にコードを書いたりハードを弄ったりしていることが多いように思う。
しかしここで気をつけなければならないのは、「コンピュータやプログラミングに興味がある一個人」として私生活にて技術書を買って読んだりコードを書くのは自由だし、私生活で友人のプログラマに「余暇の個人的学習」を勧めるのはセーフだけど、例えば会社で部下に勧めるのはグレーかブラックな行為かもしれない、ということだ。そりゃあ自発的に勉強してくれる分には構わないけど……間接的とはいえ業務に関わってくるとなると、就業時間内にやらせないと法律的にNGと判断される余地はないだろうか。
私個人の考えとしては「プライベートの時間に技術的なことに手を出す」という点がプログラマとして働く上での資質の1つではないかと思うものの、それを前提として業務を回そうとする（そういう意図はなくとも結果的にそうなってしまう）のは何か変ではないか？*12 プライベートで趣味の一環で手を出す技術が業務と直接関係ある内容だとは限らないし、私生活が忙しくて手を出す暇がないこともある。業務そのものが忙しくて手を出す暇がないこともあるだろう。プライベート時間の自習が業務に直接的に結びつくとは限らないし、時間が取れないこともあるのだから、自習を前提として業務を組み立てることには無理があるし、何より健全だとは思えない*13。
結局、今となっては業務だけでは（昔のようには）技術力は育たない。プライベートな時間に期待するのは（少なくとも会社としては）間違っている。ならば、もし社員の技術力を向上させたいのなら、就業時間の範囲*14において直接的に金銭と関わってくる業務とは別に何らかの機会を設けなくてはならないだろう。自主的に色々やる人なら「20％ルール」的な内容が向いている。そうでない人にはお仕着せの技術的な教育を継続的に行うべきだろう*15。「未経験者OK」と謳って採用しているのなら尚更だ。コの業界は主要技術の変化が激しいので、コの業界に入る前の段階（学校教育など）にだけ教育のコストを移転する方法はあまり有効ではないと思うし、そもそも未経験者には「前の段階」すらない。
こうなってくると「そもそも民間企業が全くの未経験者をプログラマ（候補）として採用することに無理がないか？」という疑問が生じるのだけど、自分自身が9割程度「全くの未経験者」な状態でコの業界に入った人なので*16そう言ってしまうことに抵抗がある。いや、私みたいに色々勝手にやって迷惑をかけつつも自主的に育っていくのならともかく、そうでない人を抱え込んで継続的に教育していくのは例え相手が情報処理の教育を受けた人であっても大変だ*17。
*1:もっとも見たことは無いもののFAシステムあたりではMS-DOSが現役なものも意外と残っているらしい。Windows NT 3.1で組まれた現役の出荷システムなら何年か前に見たことがある。
*2:記憶が曖昧なので色々と間違っている可能性あり。
*4:まあそんな都合のよいDNAなんて存在しないだろうけど。
*5:少なくともASCIIやら日本語文字コード御三家+2が間接的に関わってくる類の仕事が多いので。コの業界は思ったより幅が広いので、分野によってはASCIIコードとか知らなくても済む所もあるかも。
*6:その頃はお金が無かったこともあってフリーウェアのTeraPadを使っていた。
*7:ちなみにこの頃のLinuxディストリで日本語といえばEUC-JPだった。日本語文字コードの選択肢としてのUTF-8はまだ一般的ではなかったように記憶している。
*8:それはコンテンツを作る側のレベルが向上したからだろうし、Webブラウザの文字コード判定の精度が向上したからだろう。
*9:一般的に語られるOJTの中身は、本来の意味でのOJTとは随分と異なるようだ……。
*10:ここではその新人の適性や力量は無視している。
*11:とはいえ40代前後の人の話を聞く限り、あながち間違っていないのではないかと思う。ただ組み込みやPCアプリケーション開発の分野に偏っているとは思う（エンタープライズのように元々大規模開発だった分野の話ではない）。
*14:正確には給料が払われる時間の範囲。「サービス残業あり」で勘定するのはNG。
*15:但し効果があるか否かは不明。教育効果を計る簡易な仕組みがあればよいのだけど……。
*16:先にも書いたとおり、職業訓練で半年ぐらい情報処理の勉強をしていた。まあそこでコードを書くことに苦痛を覚えなかったのでコの業界に入る気になったのだけど。
*17:自主的に育つ人でも、私のように周りに迷惑を振りまくタイプもいる訳で。
