エンジニアの背骨： プログラミング
IT業界で仕事を始めて18年が過ぎました。
これまでにアプリケーションSE、PdM、プリセールス、データサイエンティストなどを経験してきましたが、ITをビジネスに役立てるという意味では軸は変わっていません。
仕事でのものの見方や行動規範の土台はどこにあるだろうか？と考えてみると、やはり初めての仕事であるアプリケーションSEの経験が土台になっているような気がします。そして、その下地になっているのは「プログラミング」の経験だと思います。
つまり、自分の基本的な土台はエンジニア的な考え方や方法論にあるのだと自覚しています。
このnoteではプログラミングに焦点を当て、自分のエンジニアとしての背骨を紐解いていきたいと思います。
ただ、何かすごいことをしたとか、バリバリとコードを量産したとかいうエピソードはありませんのでご容赦ください。パソコン黎明期、片田舎でどうやってプログラミングに触れ学んでいったのか。あるいは、それらの経験の中で何を学んだのかという素朴な話です。
長くなってしまったので、プログラミングを通して学んだことを先にまとめてみました。
プログラミングを通して学んだこと
・興味に従って周囲の目を気にせず学ぶことの楽しさ。
・自分にとって難解なコンセプトを粘って理解するという成功体験。
・身銭を切って専門書を買って読むことの重要性。
・自分なりの独学アプローチ。
・こんがらがったものに手を入れても良くならないこと。
・処理を分割し再利用できるようにすることの効用。
・資産管理の重要性。
・技術の選択はその意味を考える必要があること。誠実であること。
・継続的な自己研鑽が必要であること。
学ぶ環境にあふれた現代であれば、このnoteに書いた内容など何方でも短期間で学ぶことができるでしょう。
ものの見方を変えると、興味に従って学ぶこと、未知のことを独学で探究することの楽しさに気づいたことが一番大きいと思っています。
それではまずコンピューターとの出会いから書いていきます。
幼稚園児の心を掴んだパソコンサンデー
コンピューターなるものに興味を持ったのは幼少のころでした。時は昭和50年代。個人向けのコンピューターがマイコンとも呼ばれていたITの黎明期。アラン・ケイが暫定ダイナブックを開発し、パーソナルコンピューターの行く末を照らしてからまだ数年という時期でした。
そんな時代、家に転がっていた月間マイコンやOh!MZといったパソコン雑誌の広告欄を見て、「何か楽しそうなキカイがある！ 面白そう！ カッコイイ！」と思ったのが始まりでした。これらの雑誌は父が知り合いから譲り受けたもので、父も関心があったのだと思います。
そして、テレビ番組「パソコンサンデー」というものを発見。毎週欠かさず見るようになり、どんどん引き込まれていきました。
日曜日の早朝に嬉々としてパソコン番組を見る幼稚園児は不気味だったかもしれませんが、子どもらしさ・男らしさといったステレオタイプな型に押し込めず、好きなことをさせてくれた両親には今でも感謝しています。
8ビットパソコンが見せた不気味の谷
小学校に上がった頃、唐突に日立のS1という8ビットパソコンがわが家にやってきました。父の気まぐれでしたが、これが息子の将来を暗示するとは思ってなかったのではないでしょうか。パソコンサンデーで取り上げられていたシャープのMZ-1500でないのが少し残念でしたが、とにかく家に夢のパソコンが来たことにワクワクしたものです。
家族の中で最年少だった私は、「壊したらだめだから」という理由でなかなかパソコンに触らせてもらえませんでした。しかし、父や兄が真っ黒なコンソール画面を眺めて途方に暮れ始めると、自由に触れる時間が増えていきました。
とはいえ、周囲にパソコンショップがあるわけでもパソコンに詳しい人がいるわけでもなかったので活用方法がわからず、興味本位で触っていただけでした。
カセットテープのソフトがついていたのですが、LOADしてRUNしても"ヨウコソ！" 的なメッセージと無骨なコンソールが表示されるだけで一向に進まなかった記憶があります。何を入力しても "ヨウコソ！"みたいなメッセージが出続けるわけで、家族一同不気味さ感じていました。
いわば、これが私にとって初めての「不気味の谷」体験だったと言えます。もちろん、このチューリングテストは失敗に終わったわけですが、なにやらよくわからない機械が人に語り掛けてくる体験は新鮮でした。
不気味でよくわからないものとはいえ、子供は興味のあるものはなんでもいじり倒したくなるものです。BASICインタプリタが動く真っ黒なスクリーン画面を眺めながら、物怖じせず適当にタイピングをしたり、特殊文字を組み合わせて様々な絵を描いて遊んだりしました。当時の私にとっては高級なお絵かき帖のようなもの。
この遊びによって、キーボードと真っ黒なコンソールを見てもビビらなくなったという効用はあったかもしれません。また、カセットテープのソフトウェアを読み込むときに変な音がするとか、本当はFDDがあると便利だよとか、当時の小学生にしてはマニアックで無駄な知識をストックすることになりました。
このように、原理が分からないながらも、自分の好奇心に素直に従いつつ自分の手で触ることの楽しさを感じていました。触って試すというのもエンジニア的行動かもしれません。今にして思えばですが。
また、世間でマイノリティな分野で遊び、ともすれば同世代からの理解を得られない行動を取るという志向性が芽生えた時期でもありました。
「こんにちはマイコン」という救世主
さて、プログラミングを本格的に勉強し始めたのは小学校3年生の頃で、しかも独学でした。古本屋で「こんにちは マイコン」というマンガを見つけて購入したのがきっかけです。
当時、パソコンへの憧れはあったものの使いこなし方もわからずジリジリとしていたのですが、この本を見つけて「これだ！」と直感し恭しく購入したというわけです。ちなみに古本屋すらないほどの田舎に住んでいたので、車で1時間半ほど走った先にある大きな街で買った本でした。
本書は、ゲームセンター嵐というマンガの登場人物が、BASIC言語をマンガで解説してくれるという画期的なものでした。小学生でも読みやすい工夫があり、漢字も優しく図解も豊富でした。
とはいえ、全く前提知識がなく周囲に指導者がいない状況で学ぶのは大変なことでした。例えば、当時の小学校では算数で二桁の掛け算やひっ算をやっていた時期でしたので、当然ながら変数や方程式の考え方を知らない状態です。
特に難しかったのが「変数」で、何か月も悩んでいた記憶があります。どういうきっかけかは忘れたのですが、畳の上でゴロゴロしながらこのマンガを読んでいたときに、ふっと「変数って入れ物みたいなものか！」と分かった感じがして、FOR文、IF文の理解が進むようになったというわけです。
このようにしてマンガでBASICの基本構文を覚えることができました。
エンジニアとしての第一歩はここから始まったのだと考えています。また、変数という概念を通して、記号的なものの見方、すなわち抽象的な視点を手に入れたのだと思います。自分にとって難解なコンセプトを粘り強く学べたという、小さな成功体験となりました。
一方、これの副作用もあり、数学で等式や変数を習う前にプログラミングを学んでしまったので"="を代入とイメージづけてしまい、等式の概念を習ったときに違和感があったのを覚えています。当時のBASIC言語では、代入記号と論理式の等式が同一記号だったからです。
この点、こんにちはマイコンでも丁寧な解説があって、A=A+1という代入式はA←A+1と書いた方が適切なんだと説明していました。読んだ当時はわからなかったのですが、大学進学後にPascalでアルゴリズムを取り上げる講義を聴いていたときに代入記号が":="で表現されていたのを見て、「あぁ、こんにちはマイコンのアレってこのことだったのか」と感心した記憶があります。
X68000とintとcos
小学校高学年頃になると、世のパソコン好きの少年と同じくマイコンBASICマガジン（ベーマガ）を購読するようになっていきました。その頃、父と兄のパソコン熱が再び高まり、なんとシャープのX68000 Ace HDが自宅にやってきたのでした。この購入騒動においては、MSX2機を押す私、富士通のFM-77AV/EXを押す兄の意見を押しのけて、農協で取り扱っていたという事情も加味してX68000が選ばれたのでした。
そう、私の実家は専業農家だったのです。
片田舎の農家の家に突如として65,536色表示可能な16ビットパソコンがやってきたというわけで、お祭り騒ぎになりました。しかもHDDが20MBもついており、セットアップをすれば電源を入れるだけでOSとセンスの良いGUIが立ち上がるのです。なんという先端技術。
X68000はワープロから作曲までできる上、源平討魔伝やアフターバーナーといったアーケードの人気ゲームもできる夢のようなマシンでした。何といってもデザインがかっこよく、FDDやHDDのアクセス音すらエレガントに感じられました。
この環境を使ってプログラミングをするぞ！ と意気込み、日立S1とこんにちはマイコンで培った知識を試してみることにしました。そこで、BASICを立ち上げて適当なコードを入れてみたのですが、見たことのないエラーが出て全く動かないではありませんか。
のたうち回りながら調べてみると、X68000が採用していたX-BASICはC言語ライクで普通のBASICとは違うということがわかりました。変数は宣言をしないと使えない上、命令文を小文字で書く必要があったのです。ぎゃふん。
今思えば非常に高機能で素晴らしい言語だと思います。しかし、インターネットのない時代、10歳の少年には重たい現実でした。せっかくS1とこんにちはマイコンで学んだのに歯が立たないのです。"int"って何ですか、変数型って何ですかという状態。気を取り直してマニュアルや兄の部屋から拝借したX68000活用研究という本を見ても、知らない漢字と難しい表現で何が何だかわからない状況に陥りました。
ならば、サンプルコードから理解するぞ！とベーマガのコードを読んでみました。しかし、コードに"cos"とか"sin"とかいう変な単語が出てくるではありませんか。コス？シン？何もわからん……。X68000は高機能であったがゆえにゲームプログラミングも高度なものが多く、何も理解ができなかったのです。
片田舎の公立小学校に通うごく平凡な少年には果てしなく大きな壁。プログラミングに挫折した瞬間でした。そう、intとcosにやられたのです。
次第にベーマガを買わなくなったのは言うまでもありません。そして、X68000は高級ゲームマシンとして君臨していくのでした。
パソコンの世界から遠ざかった時期
X68000が高級ゲームマシンと化してから高校を卒業するまでの間、私のパソコン熱は冷めたままでした。
X-BASICの挫折もありましたが、DOS/Vが登場して標準化が進むとともにパソコンのバリエーションが大人しくなっていき、「よくわからない装置」としての魅力が失われていったように感じられたのです。その10年後、DOS/VによるPC/AT互換機の普及に関連した企業に就職するとは当時は思ってもみませんでした。
パソコンの代わりに私の心を捕えたのはオーディオの世界で、これまたマニアックな道で楽しく迷子になっていました。スピーカー下のインシュレーターに凝ったり、修学旅行先でオーディオショップを見つけてスピーカーケーブルを買うなど、周囲から見るとヘンテコ以外の何者でもありませんでした。
しかし、高校3年生になって受験の重圧が高まってくると、自分が純粋に興味を持てることは何だろうかと真剣に考えるようになりました。様々な回り道をしつつ、最終的にたどり着いたのはやはり「コンピューター」でした。4年間も学問として学ぶのであれば、やっぱりコンピューターのことを学びたい。そう思ったのでした。X-BASICの挫折から数年経ち、傷が癒えていたのかもしれません。
最終的に進路希望は情報工学科一択となりました。進路指導教官から偏差値と模試判定を考慮して「こっちの学科が安全だしもっと偏差値の高い大学が狙えるぞ」と言われても、学科は譲りませんでした。興味のないことに4年間も費やすのは無駄だと思ったからです。
大学でC言語に触れる
こうして地元の大学の情報工学科に入学することになり、晴れてコンピューターの世界を探索できるようになりました。予想に反して大学の講義は理論や数学の内容が多いなと思ったのですが、学問としてのコンピューターサイエンスは興味深く、情報工学科を選んでよかったと思ったものでした。自分が知らないことを学べるのは大変魅力的だったのです。
さて、大学でのプログラミングに関する講義や実験は実用的なテクニックを習うものではありませんでしたが、その中でも印象に残っているのはC言語を使った講義と実験でした。C言語と言えば、トラウマ一歩手前に私を追い込んだX-BASICを連想させるものでしたが、挽回のチャンスとも言えました。
C言語で何を作っていたのか今では覚えていません。しかし、すべての配列をポインタで処理するようにリファクタリングしたことは大変印象に残っています。ポインタの概念は難しかったものの、やるからには最後までやろうと決めて悪戦苦闘しながらも粘っていました。
とはいえ、どうしても上手く行かないところがあって指導教官に質問したところ、こんな風に書いたらいいよとその場でサンプルコードを見せていただきました。動的にメモリを確保するmallocだったと思います。
確かに先生の言うとおりにコーディングすると上手く行ったのですが、今ひとつ納得ができませんでした。大学指定の教科書にはほとんど記載がなかったからです。
そこで再び先生のところに行き詳しく解説している参考書はありませんか？と尋ねたところ、良い本があるよと言ってSteve Ouallineの「現実的なCプログラミング」という本を薦めていただきました。
早速、街一番の大きな本屋で見つけることができました。ただ、表紙に生々しい動物の絵がある上に分厚く、何よりお財布に優しくない値段に躊躇してしまいました。しかし、これは必要な本だと思って思い切って購入しました。
この本が優れていたのは単なる文法の解説にとどまらず、プログラミングのスタイルや考え方まで指南してくれるところにありました。人生で初めてプログラミングの先生に出会った気分で、うれしい気持ちになったのを覚えています。
本書はもう手元にないのですが、私のプログラミングにおける土台になった本と言えるでしょう。また、きちんとした専門書を読むことの重要性を学びました。これをきっかけにして、自分が知りたいと思ったことについては、身銭を切って専門書を買うようになっていきました。
量子コンピューターなる深淵
大学4回生になると卒論に向けて研究室を選ぶことになります。
私が入った研究室の研究テーマは数式処理・計算代数分野だったのですが、教授の方針で「自分で発掘したテーマなら何でもよい」という考えの元で運営されていました。やりたいことがやれるという自由さがある一方で、研究テーマが決まらず露頭に迷うことも十分にあり得ました。
私が卒論に選んだテーマは「量子コンピューター」でした。当時、量子コンピューターは実用的なハードウェアがない状態でした。しかし、暗号解読(素因数分解)を多項式時間で処理できるShorのアルゴリズムや、高速なデータ探索を実現するGroverのアルゴリズムが登場し盛り上がってきた時期でした。
このテーマに取り組んでいる人は研究室に誰もいなかったのですが、教授とディスカッションしているときに「君が興味があるのはこの話とちゃうか？」と次の本を薦めていただいたのが始まりでした。
私は英語がそんなに得意ではなかったので腰が引けつつも、「何か面白そうだ」と思ってこわごわと足を踏み入れたのでした。
こうして研究が始まったのですが、私は量子力学なるものを知らなかったため、そうとうに混乱していた記憶があります。ただ、知らないことを知れる、未知の難解なコンセプトを粘って読み解くというのは楽しく、卒業までテーマを変えることはありませんでした。
この一冊では到底理解ができず、当時唯一の邦訳書であった「量子コンピューティング」に頼りつつ、量子力学を学ぶために様々な入門書を読んでいきました。そして、院に入ってからはNielsenの「Quantum Computation and Quantum Information」が羅針盤になりました。
量子コンピューターのハードも計算理論も確立されていない中で何を研究テーマとするかが問題となりました。結論から言うと、学部時代には量子アルゴリズムを既往のコンピューター上でシミュレートしてその挙動を観察すること、修士時代には計算代数のアルゴリズムと量子アルゴリズムの接点を見出すことがテーマとなりました。
どちらもやり切ったという感じはなく自信を持てないままではありましたが、未知の探求としては非常に身になるものでした。本当の学びとはこういうことを言うのだろうか、と卒業式の時に思ったものです。
実験のためのプログラミングへ
とはいえ、この記事のテーマはプログラミングですので、この話の焦点を実装に移します。
さて、このような研究を進めるためには既往のコンピューター上で実験を行う必要があります。そのため、実験のためにプログラミングを行っていきました。
当時、研究室と研究テーマの関係から、数式処理システムを活用して研究を進めることになりました。数式処理というのは、数式をそのままコンピュータにて処理させる方式で、例えば有理数1/3をそのまま保持・計算ができるというものです。
実験に利用したのはMapleやRisa/Asirというソフトウェアでした。これらの上で実験用のプログラミングを行いました。
スパゲッティに埋もれる
学部生のときには、Shorのアルゴリズムを模倣する形で実装し、実行速度を上げるための工夫を行いました。このとき、人生で初めて目的を持った大規模なコードを書くことになったのですが、瞬く間にスパゲッティ状態になっていきました。性能を改善しようといじればいじるほどわけがわからなくなってきたのです。
そこで、秋から冬に至る卒論のプレッシャーがかかる時期になって、それまで書いたコードを全部捨てて、イチから新しくコードを書くことに決めました。自分にとっては清水の舞台から飛び降りるが如くの決断でしたが、このまま進めてもどこにもたどり着けないと直観的に思ったのです。
改めて処理の構造化を行い、メインルーチンは処理のプロセスのみを記載するようにしました。こうすることで処理がモジュール化されて実験がしやすくなり、なんとか卒論に間に合わせることができました。
コードのシンプルさを保つことの重要性と、スパゲッティ状態のコードは手を入れても悪化するだけということを学んだ瞬間でした。この実体験は、就職後にアプリケーションSEになってから活かされることになります。
力技の実験から資産管理の大切さを学ぶ
修士になってからは高次の代数方程式をヒューリスティックに解くことにフォーカスしていきました。この実験には高次の代数方程式を準備する必要がありますが、正直にいってどうやって準備したらよいかよくわかりませんでした。苦肉の策で乱数を使って多項式を生成するという力技を思いつき、ランダムな式をランダムな方法で解くという、こんがらがった道に進んでいきました。
この点で、数理的なセンスと知見があれば全く異なったアプローチで研究が進んだのでしょうけど、残念ながら私にはそういったセンスはこれっぽっちもなく、大量の実験を重ねることしかできませんでした。
さて、このような形で実験を重ねていくと、当然ながら様々なインプットデータとコードと実験結果のファイルが誕生します。つまりは、フォルダの中がファイルでいっぱいになってくるわけです。
そうこうしているうちに、間抜けな話ですが、どのファイルがどの実験で生じたものかわからなくなってきました。そこで、ファイル名を工夫するようになるのですが、それだけだと当然ながら解消されずデグレや上書きも起きるようになっていきました。こうした事態を解消するため、またもや過去のファイル群を捨てることになったのでした。まさに、資産管理の問題でした。
実験のバリエーションとコードやデータの格納先の階層を先に決めて再び実験をやり直してみると、滞りなく実験が進み大変おどろきました。やはり散らかった机というのは効率が悪いのです。
このようにして、多様な実験を行う際には計画が大切なことと、システムにおける資産管理の重要性を学ぶことなったというわけです。この学びは、後のアプリケーション開発では資産管理・構成管理の文脈で、研究所でのデータ分析タスクでは実験計画の文脈で活かされることになりました。
アプリケーションSEとして
ここまでで就職前のプログラミングの学びはおわり、就職活動を経てアプリケーションSEとしてキャリアをスタートしました。
アプリケーションSEとして学んだことも多くありますが、端的に言えば次のようなことを学びました。
・曖昧な設計からまともな出力を期待することはできない。
・製品ローンチ後のリファクタリングは様々な面で高く付く。
・高度に意味のある構造化は保守コストを大幅に下げる。
・仕様とテストは同時に考えるべき。テストで設計ミスに気付いても遅い。
・業務システムの画面やバッチの設計考慮点。
・製品開発には規律と俊敏性の両面が必要なこと。
しかし、アプリケーションSEからPdMとして製品開発のリーダになっていく中で必要になったのは非エンジニアリング的な視点でした。つまり、HowでなくWhatに焦点を当てる必要に迫られたのです。これについては、また別の機会に書きたいと思います。
とはいえ、トラブル対応や難易度の高い設計案件が発生したときには、エンジニア的発想で切り抜けることも多かったですし、場合によっては実装や検査にも手を出しました。このバランスを取るのは難しかったのですが、以下の記事などを参考にしつつ試行錯誤していた記憶があります。
研究員として再びプログラミングに向き合う（七転八倒）
私が再びプログラミングと向き合ったのは、研究員に転身した後になります。この時のエピソードは以下の記事にまとめました。
この経験、一言でいえば七転八倒としか言えません。例えば、以下のような姿をイメージしてみてください。
方眼紙Excelによる設計書やコミュニケーションを主体とするワークスタイルに慣れ切っていた30歳過ぎのおっさんが、将来有望な若手研究員と席を並べてコードを書く。
Linuxのコンソールを眺めながら必死にコマンドを思い出している。viのコマンドを忘れて右往左往している。
ビジネスでJavaとCOBOLでの実装経験しかない者がデータ分析の知識ゼロでいきなりテキストデータの分類モデルを作る。
なんとうい場違い。なんという無謀な挑戦でしょうか。
SE/PdMとして8年ほど経験を積んだ後に転身していたのでそれなりに自信も積み上っていたのですが、見事に鼻をへし折られました。技術的な面だけでなく、得意だと思っていたロジカルシンキングですら全く役に立たず、それどころか自分の考えの浅い部分がどんどん露呈していきました。まさに、8年間のSE/PdM経験の中で井の中の蛙になっていたのです。
しかしながら、このゼロリセットともいえる経験は、自分の物の見方を変え武器を増やす上で非常によい経験になりました。
この時期にエンジニアとして学んだことは大変多いです。技術面では、データサイエンスに係る技術の経験を積めたことに加えて、統計的・帰納的な考え方を学べたことが大きいです。これは、ある意味アプリケーションSEとは対極にある考え方で、アンラーンするのが大変でした。
研究所での4年間は、人生で最もコードを書いた時期かもしれません。Perl, Ruby, Python, AWK, bash。スクリプト言語を中心に、基本的なデータ加工から機械学習のモデリングに至るまで、様々なコードを書きました。この中で、以下のような点を学ぶことができました。
・計画性をもって大量の実験を回すこと。
・計算機に効率よく働いてもらうための工夫。
・データ処理の方法で計算時間が大きく変わること。
・データサイエンス全般。
また、エンジニアとしては、問題解決に対するアプローチを選択するときに、安易に選択するのではなく技術・問題の背景をしっかりと考えることの重要性を叩き込まれました。
これを少し掘り下げてみます。
初学者として先輩や上司の指示の元で実験を進めてレビューに持ち込んだとき、議論になったのは結果だけではなく「なぜそのアプローチで実験をしたのか」ということでした。これには正直面くらった記憶があります。
それまでのビジネスアプリケーション開発の現場では、事前にコンセンサスを取った方法論で開発を進めた場合、その意義を問うのは想定外の事態が起きたときだけだったからです。
しかしながら、「プロの分析者」として分析プロジェクトに携わる場合、自分の分析結果には入口から出口まで責任を持つ必要があります。当然ながら、アプローチの選択に対しても責任が発生するわけで、レビュアーの指摘は当然のことでした。
このように、技術・アプローチの選択に責任を持ち、エンジニアとして誠実に取り組むことの大切さを学びまなした。また、What/Howに対してWhyを問い続けることの姿勢を学びました。
これらは、その後キャリアに大いにプラスになりましたし、改めて継続的な自己研鑽の必要性を痛感しました。
まとめ
だいぶ長くなりました。私がプログラミングを通して学んだことを改めてまとめてみます。
プログラミングを通して学んだこと
・興味に従って周囲の目を気にせず学ぶことの楽しさ。
・自分にとって難解なコンセプトを粘って理解するという成功体験。
・身銭を切って専門書を買って読むことの重要性。
・自分なりの独学アプローチ。
・こんがらがったものに手を入れても良くならないこと。
・処理を分割し再利用できるようにすることの効用。
・資産管理の重要性。
・技術の選択はその意味を考える必要があること。誠実であること。
・継続的な自己研鑽が必要であること。
このようにたくさんの学びがあったわけですが、エンジニアでよかったと思うことは、興味に従って学ぶ楽しさを経験できたことだと思います。
そして、未知のものや難解なコンセプトを粘り強く理解することの成功体験を得られ、自分なりの独学のアプローチを形作れたことも大きいものでした。
今はデータサイエンティストチームのマネジャーをしていて、分析プロジェクトの立ち上げや新しいビジネスの企画検討など様々な活動に従事しています。多くの活動でその焦点は「ビジネス」「経営」「市場」が優先されます。しかし、頭の中で構想を描くときにはエンジニア的な発想で考えている部分も多くあることに気づきました。
やはり、自分の根っこにはプログラミングからスタートしたエンジニア観があるのだと思っています。
-----
ということで、プログラミングに焦点を当ててエンジニアとしての背骨をあぶり出してみたのですが、何か自分のルーツのようなものを感じることができました。書いてみてよかったなと思います。
この記事が気に入ったらサポートをしてみませんか？