気がついたらこの商売はじめて３０年以上経ちました(笑). そんな中、仕事をする上でこれやっておけば良かったなぁ、と後悔したこと、その一方で、これやってたおかげで意外なところで役立ったなぁ、と思ったことをかいてみます.

もっとやっておけばよかったこと

まずはこれ勉強してればなぁ、ということから…

計算機科学

電気系の学科出身なのでいわゆる情報系の学科で学ぶようなことを全く知らずに社会に出ました.ですので、仕事の上で初めていろんなことを知る、ということも多いです.

ですのでいわゆる情報系の大学で学ぶようなことを勉強してたらなぁ、とその必要性を今頃強く感じてます.

少なくても,
・リスト、木構造などのデータ構造
・ソートなどのアルゴリズム.
は分かってたら、仕事始めるうえでも楽だったなぁ、と思ってます.

これを知らないと全くプログラムが書けないか？と聞かれれば No ですが、Linux のカーネルやオープンソースのコードを読むときにデータ構造について知っていれば、理解も早いと思います.

最近注目しているのが技術出版 ラムダノート株式会社. そこから出版されている『みんなのデータ構造』がなかなかよさそうです. この本の紹介文に、

計算機科学の授業で当たり前のように学ぶさまざまなデータ構造。学部生向けの教科書としてはもちろん、理論を学ぶチャンスがないまま業務でプログラムを開発しているエンジニアや、そもそも学ぶ機会がまだ訪れていない高校生プログラマが、その考え方の基本を学ぼうとするときに手に取るべき一冊です

とありますので、ちゃんと学んでこなかった私にうってつけの本のようです. 近いうちに取り寄せて読んでみたいと思います.

英語

英語、といえば英会話…と思いがちですが、長い会社員人生、英会話力が試されたのはごくわずかです. ここで言いたいのは会話よりも英語の読み書き、特に読み、のチカラです.

仕事上、ちょっと調べものをしていくと必ずぶつかるのが言語の壁. Linux man コマンド、オープンソースのドキュメントやソースコードのコメント、全部英語です.
さらに、仕事上関わっている分野、たとえばLinux カーネルの内部やNetoworkに関する事柄、C++の情報など、その手の日本語で読める新しい本がほとんど出てこなくなってます.

技術関連の出版業界も厳しいようで、最近はやりの機械学習、phythonやWeb関連等、ある程度の数の読者があるものだけが出版できないようで…

英語で書かれた文献でまだ日本語訳されてない本がまだまだあるのは事実です.

ちゃんとペイする本しか日本語訳の本だけが出版されないのが技術系の出版業界の厳しいところ, ここが日本のエンジニア全体の課題でありハンディだと最近強く思ってます.

…と思って英語で書かれた本を買ってみたものの、なかなか読み進めるのは辛い、遅い…
図やコードを見るとなんとなく有益な情報が書いてありそうだけど、あ゛～！！…すらすら読めるようになりたい!!
ということで学生時代もっと英語を勉強しておけばよかったなぁ、老体に鞭打って頑張ります…と強く思う次第です.

教訓 英語、会話できなくても何とかなるけど、読めないと詰む.　です.

数学

ディジタルフィルタやディジタル変調などディジタル信号処理の仕事をやっていた時期がありました. その時に痛感したのが、ああ、数学ちゃんと勉強しておけばよかった…

三角関数、微積分、複素数などなど…フィルタ設計でラプラス変換を使うんですけど、あれ、これって大学で勉強したことになってるんだけど全然覚えてないわ(汗).

仕事で使うまで複素数や微積分なんて何に使うのか全然分かって無かったけど、その目的を先に教えてくれればなぁもうちょっと理解できたのかも、なんて思ったりしてます.
いずれにせよ数式アレルギーは治さないと…

描画関連をやっている人は三角関数と行列演算が必要なようです.

やっててよかったこと

次は偶然にもやってたことが後々役になった、という話です.

ハードウェア開発

最初に配属された部署が電気回路設計のセクションでしたので、先輩の手伝いで基板の試作などやってました. はんだごてを使って基板作ったり、オシロスコープやロジックアナライザなどの測定器を使って測定などやった経験が後々のハードウェアとソフトウェアの境界に関連するトラブルシューティングに役にたっています.

ただ未だに電気回路はよくわかってないです. ですから回路設計できる人、まじリスペクトです.

アセンブラプログラミング

最初にソフトウェアの開発に携わったCPUにはC言語などのコンパイラはありませんでした. アセンブラしか選択の余地がありません. 直接CPUを制御するプログラム、そのため、CPUの仕様を理解が必要でした.

そのおかげでレジスタ、割り込み、スタックなどの理解が今のC言語を使ったLinuxプログラミングでも役にたってます. たとえば,スタックを大量に消費するデカいローカル変数を使うヤバさが感覚的にわかる…とか.

あと、C言語でプログラミングを始めたころ, コンパイラが出力するアセンブラコードを読んだことがあります. それがいい経験となってCでプログラムを書くとどんなアセンブラコードが出力されるかをある程度イメージできるのは、Cのプログラムの最適化するときに大変役にたっています.

ただC++でSTLを使ったプログラミングはさっぱりイメージできません. ちょっとこれで勉強中なんですが、この本はとても良い. 新しいC++とその最適化を両方に言及した本は他にちょっとないです. そのうちブックレビューしたいと思います.

オープンソースのインストール

少し前(と言っても20年くらい前)、LinuxやFreeBSDが出てくる前は, SUN のワークステーションで仕事してました.

いまでこそ必要なソフトウェアはパッケージが用意されてますが、当時は必要なソフトウェアはすべてソースコードを入手してコンパイルしてインストールしてました.

まず, ワークステーションが届いたら
・OS (SUN OS 4.3) インストールとメーカーからリリースされたパッチの適用.
・gccのビルドとインストール.
・X Window System のビルドとインストール.
・Wnnなど日本語入力環境のビルドとインストール.
・emacs のビルドとインストール.
・LaTeXやGhostScriptなどの文章作成ソフトウェアのビルドとインストール.
などなど、半月くらい使って仕事環境の整備してましたが、いやはやのんびりした時代だったものだなぁ、と今さらながら思う次第です.

いろんなソフトウェアをビルドするとビルドエラーやらいろんなトラブルに出くわします. Makefileの修正や configureの引数の変更、足りないライブラリの追加やらなんやら.

もうそんな知識なんぞ誰も使わないだろなーと思ってましたが, そのときの経験が最近 Linxu を使った組み込みシステムで OSSをで利用するときにとても役に立っています. 意外なところで役にたつんですねー、と老エンジニアでも活躍できることがあって嬉しい次第です(笑)

という感じでやっておけばよかったこと、やっててよかったことを書いてみましたが、(知識や経験は)必要なことは身に着けた(あるいは身に着ける機会があった)ずっと後から分かる、というのが最近改めて分かりました. 学生時代にもっと勉強しときゃよかった、ということなんでしょうね. ただ老体に鞭打って足りない知識を補っていきたいと思ってます.

こちらも読んでね

私がソフトウェアエンジニアになったわけ