プログラマー 現役続行

2016年12月、本棚を整理していたら昔に購入した「プログラマー“まだまだ”現役続行」という本が出てきましたので、久しぶりに読み直してみました。

Still Continue Active as A PROGRAMMER

私は、1974年に大学で初めてコンピュータを使用しました。当時は大型コンピュータで、バッチ方式やタイムシェアリング方式を経験しました。

あれから42年の間に、パソコン／タブレット／スマートフォンなどが誕生して、コンピュータは持ち歩ける時代になりました。マイクロプロセッサの登場で、コンピュータの応用分野が広がりコンピュータ技術は大きく発展しました。

ソフトウェア技術に関しては、構造化プログラミングやオブジェクト指向などの新しい手法が定着してきました。しかし、ソフトウェアを人が手で作るという状況には、大きな進展がありません。

プログラマー “まだまだ”現役続行

• プログラマー “まだまだ”現役続行
• 柴田芳樹　著
• 株式会社 技術評論社
• 2010年10月10日 初版 第1刷発行

---

 

 

目次

第01章　ソフトウェアは「人」が作る
第02章　プログラマー現役続行
第03章　論理思考力
第04章　読みやすいコードを書く力
第05章　継続学習力
第06章　コンピュータサイエンスの基礎力
第07章　朝型力
第08章　コミュニケーション力
第09章　英語力
第10章　コードレビューのすすめ
第11章　若い人たちへ
第12章　30代、40代の人たちへ

プログラマー現役続行

ソフトウェア・スキルを7レベルで定義しています。その要約を示します。

•  レベル１ : 初心者 ・・・基礎知識が不足している
•  レベル２ : 見習い ・・・指導を受けながら簡単なプログラミングなどの実践ができる
•  レベル３ : 初級職人 ・・見習いレベルの実践はできるが、ときどき指導が必要である
•  レベル４ : 中級職人 ・・必要な技術を仕事の上で自然に自動的に使っている
•  レベル５ : 上級職人 ・・新たな技術も含めて自分で常に学習を行い自然と実践できている
•  レベル６ : 名人　 ・・・技術を完全に消化していて、「型破り」ができる
•  レベル７ : 匠　　 ・・・技術を拡張する方法を探求し、専門書の著作や講演をする

---

名人も、上級職人と同様に、新たな技術を学んで自分の腕を磨くことに興味があり、そのための活動もします。ただし、それに加えて職人を育成することで、開発組織全体のスキルアップをすることの重要性も認識しています。ここが、上級職人と違うわけです。

---

匠は、名人と同様に、職人をいかに育成するかを常に探求し、それを試みて、成果がでれば広く普及させるべく活動することが、ソフトウェア業界では求められると思います。

---

さて、私自身はどうでしょうか？
ソフトウェア技術者の道を約40年間歩み続けていろんなことを経験しました。たぶん、マイクロプロセッサへの最適化実装においては「名人」のレベルには達しているのではないかと思います。

論理思考力

当時はコンピュータの速度が今よりずっと遅く、実行結果を得るにもしばらく待たなければなりませんでした。それだけプログラミング環境が今より劣っていたわけですが、そのために当時のエンジニアたちは、結果を待つ間に自分のソースコードをじっくり読み返し、思考を重ねることができました。

私も同じような体験をしています。コンピュータリソースが不足していたので、1台のパソコンを3人で時間帯を区切ってシェアリングしてマシンデバッグしていました。パソコンを使用できない時間帯は、プログラムリストを印刷したものを机に広げて、赤ペンと黄色マーカーペンを持ち、じっくりと机上デバッグをしていました。2016年現在においては、「机上デバッグ」は死語なのでしょうか？ここ10年ほど、こんな光景は見ていないような気がします。

論理思考は、特にデバッグする場合に非常に重要です。
・・・
ソフトウェアエンジニアにとって、このように論理的に推論することは、求められる重要な素質の一つです。

 

バグを解析するときは、現象から原因を推測して説明がつくまでソースコードを修正しませんでした。変な修正をしてしまうと、現象が消えてしまうことがあります。そうなると、潜在バグを埋め込んでしまい再現できないという、とても怖い状態になります。

重大なバグを発見した場合は、ソースコードが目の前に無くても、頭の中のプログラムロジックと現象を付き合わせ、帰宅中に考え込んだこともありました。

読みやすいコードを書く力

ソースコードを見たり、ＵＭＬで描かれたクラス図を見たりしていると、「何か臭う」ことがあります。

この「臭う」という感覚、私もわかります。バグが発生する可能性のあるプログラムは、何か怪しい臭いがします。この感覚がよくわかるのは、プログラム構造図のPAD図に書き起こした場合です。プログラム論理を２次元木構造で表現したPAD図を眺めると、違和感を抱くことがあります。美しいプログラム構造は、対称的であり、個々の処理があるべきタイミングの位置に配置されるものです。

 

著者が名著を紹介しています。

• プログラミング作法
• 達人プログラマー
• リファクタリング
• アジャイルソフトウェア開発の奥義
• コードコンプリート 第２版
• パターン指向リファクタリング入門
• クリーンコード
• 実装パターン

 

 

継続学習力

自分の時間とお金を自分自身へ投資して、継続した学習を行うことは、ソフトウェア業界に限らず、今日の社会では一般に求められることです。

自分自身へ投資して、新しいことを修得することは大事だと思います。

1980年代に2つ目のソフトウェア会社に在籍していた頃です。情報処理学会のシンポジウムを聞きたくて上司に申請したら、予算が無いとかで許可が下りるまで2週間程度待たされました。最終的に参加できたのですが、何か気まずくなってしまいました。次回からは会社への申請をやめて、年休取得して自費で情報処理学会のシンポジウムに何回も参加しました。金沢－東京間の旅費と宿泊費など高くつきますが、金額には変えられない学びと刺激を受けました。

また、1993年に3つ目の会社に在籍していたときの話です。夏季休暇を利用して北海道の稚内で開催された「UNIXサマースクール システム管理初級コース」に参加して、SUN Solaris ワークステーションでシステム管理の技術を修得し、刺激的な5日間を過ごしました。

---

 

継続して本を読むことです。本を読むことで、他人が何年も要して蓄積した知識を数週間で得ることができます。
・・・
書籍の選択の方法はいろいろあると思いますが、まずはJolt Awardsの候補に挙げられたり、賞を獲得したりしている書籍をチェックしてみてください。

私も、気になる技術について専門書をよく購入しました。残念ながら、実務が忙しいときには休日でもあまり時間を確保できずに、流し読みすることや、本棚に積んでしまうことがありました。もう少し、しっかり勉強すれば良かったと反省します。

ソフトウェアエンジニアとしては、経験年数とともに、自分の道具箱の中の道具を増やす努力を積み重ねていくことが求められます。

いろいろな道具がありますが、ソフトウェアエンジニアは各種ツールを使いこなして武装して開発効率の向上を図るべきと考えます。例えば、軽量プログラミング言語（lightweight language）と呼ばれるスクリプト言語を使用すると、用途により開発効率があがります。私は、UNIXを経験してsh/sed/awkを修得して活用しました。その後も、JavaScript/VBScript/JScript/PowerShellなどを使用しました。Pythonがとても気になっていたのですが、じっくり勉強することができませんでした。定年退職した今は、時間的な余裕ができてやっとPythonを勉強してRaspberry Piで趣味のプログラミングをしています。

ソフトウェア開発を楽しめるかどうかということです。
・・・
ソフトウェア開発では、学ぶべき事柄は、一生かけても学びきれないほどあり、一方で新たな技術が次々と登場して、発展したり、あるいは消えていったりします。

ソフトウェア開発は、苦しいこともありますが楽しいです。たくさんある技術から何を優先的に学ぶか選択することも必要です。廃刊になってしまいましたが共立出版の技術情報誌bitは、数多くの技術情報を提供してくれたので私の愛読書でした。

コンピュータサイエンスの基礎力

基本的なデータ構造とアルゴリズムに関しても、ほとんど知らない人が多いようです。

四角形の4辺の長さを短い順に取得するために、4辺の長さをクイックソートしているソースコードを見たことがあります。データ件数4件と少ないのに、なぜクイックソートを使ったのかとても不思議でした。

その理由がわかったのは、別の組み込み系のDSP開発件名でソースコードレビューしたときです。10件のデータをソートする内容でしたが、クイックソートを使用していました。理由を聞いたら、ライブラリにクイックソートがあり、キー比較の関数だけ作ればソートできるので、ソートアルゴリズムコードを書くのは無駄だとの主張です。私は、データ量が多い場合はクイックソートは速いので利用すべきで、データ件数が少ない場合はかえって逆効果で遅くなると考えています。

担当者は、納得できないようでした。組み込みシステムで十分大きなスタック量を確保できないことを説明し、クイックソートは再帰的処理でスタックを消費するので最悪値でスタックの消費量を計算できるか質問しました。さらに、DSPプロセッサの開発環境なので、標準ライブラリがすべて使用できるわけではないことも説明しました。

これらを調査してソートを実現するより、ソートアルゴリズムコードを書いた方が早いと考えたのかどうかはわかりませんが、クイックソートを使用しないことに理解を示してくれました。

---

「自分はソフトウェアエンジニアだから、ハードウェアの勉強をする必要がない」と思ったりしているとしたら、それも間違いです。

私は、8080マイクロプロセッサのアセンブラ言語を勉強して育ちました。ソースコード・デバッガなど無い時代です。ICE（in-circuit emulator : インサーキット・エミュレータ）を使用して機械語レベルでデバッグしていました。テストフェーズで、ある特定のメモリを破壊するバグを追跡していたときは、メモリ番地を指定してメモリ・ライト信号で不正をするプログラムの番地を特定するなどして解析していました。最近のプロセッサは統合化されて、半導体の集積度が高くなりチップからの信号線が限られており、ソフトウェアエンジニアはハードウェアに触れる機会が減ってしまったことは残念です。

最近のC++言語でWindowsプログラムを書いているソフトウェアエンジニアは、アセンブラの経験も無いですし、コンパイラがどんなコードを生成しているか興味も無く知らないことが多いです。

私は、マイクロプロセッサ向けに最適化実装する場合は、Cコンパイラの出力したアセンブラコードを読んで最適な実装になっているか確認しながら最適化を進めます。C/C++言語でソースプログラムを記述したとしても、そのプロセッサのアセンブラ言語を知らないと最適化実装するのは困難です。

朝型力

貴重な朝の時間を有効に使う
朝の1時間は、夜の2時間に匹敵するといわれます。

1980年頃、CSKからM電器に派遣になったときは勤務時間が8時からでした。朝は早めに到着して食堂でコーヒーを飲んでから、さわやかに仕事を開始しました。

それから、10年が過ぎて1990年頃は、3社目に転職した会社でとても忙しい日々を過ごしていました。どんどん帰宅時間が遅くなり、夜の22時に会社を出る生活が続いていました。勤務時間は8時30分からですが、フレックス・タイム制を導入していたので、コアタイムの10時ギリギリの出社となり、夜型にシフトしてしまいました。夜にどんなに頑張っても、疲れがたまって効率よく開発が進みませんでした。ここで悪い習慣がついてしまいました。

翌1991年には金沢拠点での開発となり、フレックス・タイム制でも朝早くに自宅を出て、バスに乗らず30分ほど歩いて8時過ぎには出社する生活パターンとなり、朝の時間を大事に使うようになりました。

コミュニケーション力

ソフトウェアを開発する場合には、特に論理的に相手に説明できる必要があります。
何らかのバグがあり、その調査を行おうとしている場合に、どのようなバグの原因が考えられ、それに対してどのような調査を行おうとしているかを説明できなければなりません。

1984年に、H社のユーティリティ・ソフト開発を受託したときのことです。システムテスト工程でのバグに対しては、H社の品質管理に従ってバグ管理(B票)やプログラム変更管理(P票)を書いて品質管理者のレビューを受け、バグ管理を徹底した経験があります。バグ管理(B票)は、そのバグはどのような状況で発生して、どんな現象となるかメカニズムを説明するわけです。プログラム変更管理(P票)は、そのバグの対策はどのように修正するか説明し、その修正で新たなバグが発生しないことを管理するわけです。

バグに対して、安易にすぐ修正するのではなく、どんなバグがなぜ発生しているのか論理的に説明し、対策によりなぜ発生しなくなるか説明するのです。その当時は、面倒だと思っていましたが、今振り返ってみると良い経験をしたと考えます。

英語力

英語力に関しては、どの程度の力が必要になるかといえば、やはりTOEICで900点台ということになるでしょう。このレベルでなければ、原著の専門書をある程度のスピードで内容の理解に集中して読むことはできません。

私の英語力は弱く、この目標からはほど遠いレベルです。

大学生時代に、DEC社のSystem-20が導入されたときに、マニュアルは英語でしたので必死に読んで理解していました。SNOBOL言語を使用するときも、英語のマニュアルしかありませんでしたので、英文マニュアルを読んでプログラムを作成しました。

社会人になってから英語の勉強をあまりしませんでしたので、海外出張でCOMDEX’95で説明員を行ったときは苦労しました。

コードレビューのすすめ

コードレビューの重要性について記述しています。

クリーンなソースコードが準備できたら、次に作成者が行うことは、パーソナルレビューです。つまり、まずは自分自身でソースコードをチェックします。

「ひとり時間差レビュー」ということを聞いたことがあります。
レビューは、有識者を含めて数名で実施すると効果があります。しかし、みんなが忙しくてレビューの対応ができない場合は、1日以上の時間を空けて時間差を設けてからひとりでコードレビューすることです。ソースコードを書き上げた直後では、頭の中にソースコードがあるので、自から書いたソースコードを見ても間違いに気づきにくいものです。時間が経過すれば第三者の目でレビューできるわけです。

若い人たちへ

与えられた仕事をこなすのは当然であり、そのことだけで有能と認められるわけではなく、たとえ101%であっても期待以上の成果をあげて、初めて上司から有能だと認められるということです。

私も期待以上の成果をあげることを心がけてきました。
特に3社目の開発研究所時代は、委託元のお客さまに対して期待以上の成果を出し続けることにより、継続的に開発受託することができました。静止画物体検出の画像認識の最適化実装で約3倍に高速化できたときは、事業部が困っていた別のモジュールについても高速化を受託することができました。逆に、期待を裏切る成果となった場合は、次の委託につながらないことがありますので、心して開発に当たっていました。

30代、40代の人たちへ

ソフトウェア開発は、新しい技術が次から次へと登場して、興味が尽きることがない領域です。そして、終わりがない道のりなのです。その長い道のりで、さまざまな理由から開発の現場に留まるのが困難な状況になり、管理する立場になることもあるかと思います。

私のソフトウェアエンジニアとしての約40年を振り返ってみて、本当にワクワク感にあふれた技術者人生でした。

開発研究所では、約15年間にわたり課長職を務めましたが、プレーイングマネージャーとして自ら開発も担当しました。2008年からは、技術職に専念して主幹技師としていろいろな開発に携わりました。

私は2016年に定年退職して、ファーストステージを走りきりました。セカンドステージをどう歩むか思案しているところです。

最後に

著者の柴田芳樹さんは、匠（たくみ）レベルのすごい技術者だと思います。私は、著者の足元にもおよびませんが、私の経験と照らし合わせて共感しながら読み進めることができました。

若手のソフトウェア技術者に知ってもらいたい内容がたくさんあります。読んで刺激を受けてもらいたいと思います。