ソフトウェアエンジニアとして転機（４）

米国ゼロックス社に駐在

米国に駐在してソフトウェア開発をするようにと、1988年の夏前ぐらいに言われました。それまでゼロックス社固有のハードウェア上で動作していたStarワークステーションのソフトウェアをSunワークステーション上のSunOSへ移植するSalientと呼ばれたプロジェクトでした。正確な人数は覚えていませんが、当時の富士ゼロックスから私と同期や先輩達の20名以上が米国のEl Segundo, CAおよびSunnyvale, CAへ駐在員として送り出されました。

米国へ赴任したのが1988年11月で29歳でした。そして、私にとっては生まれて初めて日本を出たときであり、多くの不安を抱えながらの赴任でした。

赴任前の送別会で、今は亡くなられた先輩のS.U.さんが「米国では与えられた仕事をやり遂げたら、次に難しい仕事が割り当てられるけど、仕事ができないと判断された、日本と違って仕事が割り当てられなくなる」といった趣旨のことを言われて、そうかなと思ったのですが、実際の米国ゼロックス社でのソフトウェア開発はそうでした。

2年半弱、El Segundo, CAでSalientプロジェクトに従事して感じたことは次の通りです。

• 歳を取ってもソフトウェア開発は続けられる
• プロジェクトに面白さが失われていくと、優秀な人は転職していく

William Maybury

私が所属したVP Document Editorチームには、William Mayburyという年配のソフトウェアエンジニアがいました（でも、おそらく今の私よりも若かったと思います）。当時の日本では、彼と同じ年齢の人がソフトウェアを開発し続けているというのは全く想像できなかったので、私にとっては衝撃でした。

私事ですが、「さらなる学習」に掲載されている「Mesa Language Manual」の著者の１人であるWilliam Mayburyの名前を見ると、彼と一緒に仕事をした２年半の米国El Segundo, CA時代が懐かしく思い出されます。彼は、私よりもかなり年上でしたが、驚いたことにマネジャーではなく、現役のソフトウェアエンジニアとして働き続けていました。本書が生涯ソフトウェアエンジニアを目指して、常に新たな技術を学び続けている人々に読まれれば幸いです。

『プログラミング言語Java 第4版』の「訳者まえがき」より

そして、米国に赴任してから31年の月日が流れて、私自身が今でも日々ソフトウェア開発をしているのは、彼の影響が大きかったのかもしれません。

優秀な人は転職していく

Salientプロジェクトは、Mesa言語で書かれたStarワークステーションの膨大なソフトウェアを移植するプロジェクトでした。しかし、プロジェクトの終盤になってくると優秀な人からゼロックスを辞めていきました。プロジェクト次第で、優秀は人は会社を変わっていくことを実感したのはこの頃です。当時、うらやましく思った転職先は、PenPointを開発していたサンフランシスコにあったGO Corporation社でした。残念ながらPenPointは時代的に早すぎ、製品を出さずに7年間後にGO社は解散しました。

追記

El Segundo, CAでのSalientプロジェクトも終わりが近づき、日本への帰国がそろそろだと思ったので、1990年12月にはリオデジャネイロとブエノスアイレスへ旅行しました。しかし、1991年になると多くの駐在員が帰国するなか、PARC（ゼロックス社のパロアルト研究所）に駐在することになりました。PARCへ転勤する前にPARCで従事するプロジェクトの説明を聞くために初めてPARCへ行った日は、1991年1月17日でした。その日は、米国がイラクを空爆して湾岸戦争が始まった日でした。

『プログラマー現役続行』から12年

雑誌に執筆した記事をまとめて書籍にした『プログラマー現役続行』から12年が過ぎ（改訂版である『プログラマー”まだまだ”現役続行』からは9年）、60歳になりました。

プログラマー現役続行 (技評SE新書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2007/09
• メディア: 新書

この本で現役続行に必要な7つの力として、「論理思考力」、「読みやすいコードを書く力」、「継続学習力」、「コンピュータサイエンスの基礎」、「朝型力」、「コミュニケーション力」、「英語力」を説明しています。それらに関して、この12年間私自身がどうであったかを簡単に振り返ってみたいと思います。

論理思考力

現在、メルペイでbackendのソフトウェアエンジニアとしてソフトウェア開発を行っていますが、何か問題が発生した場合に、仮説によって推定された原因から、発生している問題が論理的に説明できるかという問いは常に行っています。一方で、間違った仮説を立ててしまい、問題が説明できずに、さらなる調査にさらに時間を要してしまうこともあります。

ソフトウェア開発では、デバッグや問題調査は避けて通れないため、論理的に説明できなければ納得しないという態度は常に必要です。

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

長年ソフトウェアを開発していても、他人が読んだときに読みやすいかと振り返りながらコードを書くのは簡単ではないです。自分ではよいと思っても、レビューで指摘されることもあり、まだまだなと思うことがあります。

継続学習力

継続的に学習することに関しては、この12年間でさまざまな社内外の勉強会を開催したり、技術書を翻訳したり（この12年間で12冊）、技術書の英語の原著の草稿をレビューしたりとやってきました。ただ、それ以外の一人で学習するというのが少なかったと思います。現在は、私にとって18冊目となる技術書の翻訳（2020年春の出版予定）を通して、Java 10以降のJavaの概要を学んでいます。

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

この12年間では、リコーに勤務している頃に『Linux Kernel Development』の社内読書会をやったり、『プログラミング作法』の第1章「スタイル」と第2章「アルゴリズムとデータ構造」の指導を新卒新入社員に行ったりしました。

現在も行っているGo言語研修やJava言語研修では、必ずと言ってよいぐらいハッシュテーブルを説明することが多いです。逆にきちんと説明できる受講生はほとんどいないです。

最近では、復習を兼ねて、『Introduction to Computing Systems: From Bits & Gates to C & Beyond』を読んでいますが、忘れていることも多いです。P型トランジスタとN型トランジスタから始まりますが、コンピュータがどのように構築されているかを知るにはお勧めの本です。

朝型力

早朝に何らかの活動を行うことは、ずっと続いています。特に、技術書の翻訳作業は基本は朝です。出社前のスターバックスだったり、通勤電車内だったりします。メルペイで働き始めてからは、出社前にスターバックスへ行くとことはなく、もっぱら通勤電車内で翻訳作業をしています。

コミュニケーション力

相手に分かるように説明することに関して、自分自身が向上しているかについては、何とも言えないかなと思っています。ただ、Java言語研修やGo言語研修では、できるだけ受講生の理解レベルに合わせて質問に回答するように努めてはいますが、なかなか難しいです。

英語力

英語に関しては、ほとんど進歩していないと思います（「英語とTOEIC」）。普段は、ポッドキャストでBBC、NBC、CBSといったニュースを聞いてはいますが、日本語のニュースを何かしながらながらで聞いていても理解できるように、何かしながらながらでも英語のニュースを聞いて理解できるレベルには到達しそうにないです。おそらく、多くの英語を速く読む努力が足りないのだと思います。話す方に関しても、普段英語で話す機会もこの12年間はほとんどないので、後退しているのではないかと思います。

まとめ

何歳までソフトウェア開発を仕事として続けられるかは分かりませんが、スマフォ決済の始まりの時代にそのシステム開発に従事でき、一方でGo言語研修やJava言語研修を通して言語の知識だけでなく、私自身の経験を伝えていくことができるのは、幸運なのかもしれません。

ソフトウェアエンジニアとして転機（３）

Fuji Xerox 6060ワークステーション

Fuji Xerox 6060 ワークステーション
http://www.fujixerox.co.jp/company/profile/history/product.html

1984年に就職して夏に配属されたのは、独自のワークステーションを開発するグループでした。当時、富士ゼロックスはBTronにも取り組んでおり、プロトタイプもあったのですが、独自にJ-Starに似たワークステーションの開発に着手しました。J-Starのソフトウェアを移植するのではなく、OS（Idris: Unixクローン）を除き、CPUボードからすべてを一から開発するプロジェクトでした。

この開発で私が初めて学んだ主な技術は、以下の通りです。

• Unixの基本知識
• Unixのコマンド
• vi
• C言語
• Ethernetプロトコルを含むXNS（Xerox Network Systems)のプロトコル体系

Unixの基本知識、コマンド、vi

大学院の終わりの頃に、どこかの研究室にUnixワークステーションが導入されたのですが、ほとんど触ったことはありませんでした。6060ワークステーションでは、UnixクローンであるIdrisと呼ばれるOSを採用していましたし、開発にはVAXを使って、その上でBSD 4.2（？）が動作していました。当時のUnixは、今日のLinuxやmacOSなどと比べると非常にシンプルでした。

• スレッドはなく、プロセスのみ
• プロセス間通信は、fork/execしてパイプでの通信のみであり、共有メモリもない。

私はXNSプロトコルの設計・実装を担当したのですが、上記の単純なプロセス間通信では複雑なネットワープロトコルを実装するのは非常に困難だと判断しました。そして、OSチームにIdrisを改造して以下の機能を提供することをお願いしました。

• 任意のプロセス間で通信するためのメッセージング機構
• プロセス間でメモリを共有する共有メモリ機構

今日のUnix/Linuxでは当たり前の機能ですが、当時は「こんな改造したらUnixではなくなるな」と思っていました。OSチームは、共有メモリ機構をさらに発展させて共有ライブラリ機構も追加しました。今では当たり前ですが、メモリが少ない当時としては、かなり画期的だと思っていました（そして、1993年頃にSunOSでmmapが使えるようになったときも画期的だと思いました）。

今日でも使っている基本的なUnixのコマンドはこの頃に学びましたし、エディタとしてのviも学びました。しかし、今から振り返ると非常に貧弱なエディタ環境でした。80桁×24行のキャラクタ端末を使ってソースコードを編集していたので、ソースコード全体の見通しが悪かったのです。そのため、ソースコードはいつも印刷していました。印刷するといっても、当時はドットインパクト式プリンタでしたので、音がしてうるさかったです。

この6060ワークステーションの開発環境をはるかに飛躍させたのは、4.3BSDが登場して、4.3BSDにXNSプロトコルが提供され、J-Starワークステーション開発用のXDE（Xerox Development Environment）から4.3BSDが使えるようになったことです。4.3BSDに提供されたXDE用のコマンド（確かREdit）のネットワークプロトコルをリバースエンジニアリングして、同じコマンドをIdris環境にC言語で実装してからは、エディタとしてXDEが使えるようになり、マルチウィンドウやウィンドウ分割、それに、XDEからのターミナル接続などができて快適になりました。

開発ツールの整備

6060ワークステーションの開発は、ユーザに提供するアプリケーションの開発のみならず、すべての開発用ツールを独自に開発するものでした。XNSプロトコルの設計・実装を担当していましたので、英語の仕様書しかなったXNSプロトコルを理解して、Idris上で動作する以下の開発用ツールを開発しました。

• Ethernet上のパケットをキャプチャーしたり、TCPに相当するXNSプロトコルのSPP（Sequence Packet Protocol）レベルでファイルにダンプしたりするツール。
• Printingプロトコルを実装して、ソースコードをInterpress形式（Xerox社のPDL：Page Description Language）へ変換して、レーザープリンターへ送って印刷するツール（ドットインパクト式プリンタと違い、オフィスが静かになりました）。Interpressへの変換は他のエンジニアが実装しました。
• Filingプロトコルを実装して、J-Starのフィルサーバを使えるようにするツール。これで、離れた開発拠点へファイルを電子的に送ることができるようになりました（これ以前は、フロッピーディスクに保存したファイルを物理的に運ぶためにバイク便を使っていました）。
• Mailingプロトコルを実装して、Idrisからも社内の電子メールを読んだり送信できたりするようにしました。
• リモートログイン機能。Idris間でリモートログインできるようにするためのデーモンとrlogin相当の機能。これは、私ではなく他のエンジニアが作成しました。SPPを使って実装してあり、Unix 4.3BSDに搭載されたデーモンと同じプロトコルを採用していたと思います。

6060開発の後半ではクロスコンパイル用に4.3BSDも開発環境として使っていましたので、4.3BSDでも動作するようにツールの多くを移植しました。

6060ワークステーションの開発は、私にとってUnix関連の基礎となる多くの経験を積むことができたプロジェクトでした。最初に述べた事柄に加えて、「不便なことを解決するために自分達でツールを開発して、配布する」ことを行うようになったプロジェクトでもありました。

6060ワークステーションの当時のテレビCM

こちらです。

ソフトウェアエンジニアとして転機（２）

富士ゼロックスへの就職

就職先として選んだのは、富士ゼロックス株式会社でした。当時は、推薦状をもらって1社受けるだけで、落ちない限り次の会社を選ぶことはなかったのと、修士課程を出て不合格になることはまれだったこともあり、富士ゼロックスに就職することになりました。情報工学科の先輩で就職した人はいなかったのですが、当時としては、福利厚生（特に住宅補助）が非常に良かったという不純な理由で選びました。

入社後の塚原研修所での3か月の新人研修期間は、ほとんどがコピー機に関連する研修ばかりで、就職する会社を間違えたと思いました。

J-Starワークステーション

配属された開発部門は、当時のJ-Starを開発している部署でした。しかし、私は、J-Starではなく、独自のワークステーションを開発する開発グループに配属されました。J-Star関連の開発に従事するようになったのは、2年後の1988年からですが、J-Starおよびその開発環境であるXDE（Xerox Development Environment）は、時代の先端を行っているソフトウェアでした。就職した1984年（Windows 95もMacintoshも登場していない）で、すでに以下の機能を備えていました。

• ビットマップディスプレイとマウス
• マルチウィンドウ（J-Starはタイリングのウィンドウシステムでしたが、XDEは普通にオーバーラップするウィンドウシステムでした）
• Ethernetと各種ネットワークプロトコル
• レーザープリンター
• リモートデバッグ機能（別のワークステーションからデバッグできる）
• 依存モジュールを世界中のゼロックスグループ内のファイルサーバーから自動でフェッチする機能

これらすべては大学時代は全く想像もでできませんでしたし、見たことも触ったこともありませんでした。マウスを初めて操作し、マルチウィンドウシステムでドキュメントを作成しレーザープリンターで綺麗に印刷し、ファイルサーバーにドキュメントを格納したり、電子メールを使うという体験をしたのが1984年でした。そして、Starだけでなく、ゼロックスにはすでにSmalltalk-80やInterLisp-Dの統合開発環境も存在していました。

私は、J-Starの開発グループではなく、独自のワークステーションを開発するグループに配属されたので、上記の機能の多くを独自に開発することになります。

ソフトウェアエンジニアとして転機（1）

60歳を前に、これまでの人生でソフトウェアエンジニアとして転機となった出来事をまとめていきたいと思います。

九州工業大学情報工学科への進学

中学3年生になったときに、父の転勤で佐賀県の嬉野から山口県の下関に引っ越しました。高校は、下関西高等学校の理数科へ進学しました。当時、理数科は普通科と異なりクラスが一つしかなかったので、三年間、クラス替えなく過ごしました。

当時、家に電卓もない時代で、そもそもコンピュータを触ったことも見たこともありませんでした。それでも、コンピュータについて学んでみたいと思い情報工学科に進学することにしました。その頃、九州で情報工学科を持っている大学は、九州大学と九州工業大学の二校だけでした。自分の成績から判断して、九州工業大学の情報工学科へ進学することにして、幸い合格できて進学しました。

当時、九州工業大学は単科大学（学部はなく、さまざまな学科から構成され、現在の工学部がある戸畑キャンパスのみ）だったためか、一般教養の教科に加えて、一年生から専門教科も教えられていました。つまり、一年生のときから、プログラミングやコンピュータの動作原理などの基礎知識の教科がありました。

初めて学んだプログラミング言語は、Fortranでした。大学では、プログラミング言語だけでなく、コンピュータの動作原理、データ構造とアルゴリズム、コンパイラの動作原理とコンパイラの作成演習といったさまざなことを学びました。振り返ってみると、社会人になってから学ぶ機会がないような知識だったと言えます。

大学時代使ったコンピュータシステムで、今日では見かけることがない以下のようなものがありました。

• 80桁×24行の「キャラクタ端末」
• パンチカード、マークカード、紙テープ
• コアメモリのコンピュータ（実験で使いました）
• APL端末（APL言語に特化した端末。ALUを含むCPUの原理をAPL言語で記述した本で学ぶ講座がありました）
• 8インチフロッピーディスク
• 音響カプラー
• ラインプリンタ
• etc

ハードウェアは進歩していきますが、ソフトウェアに関する基礎知識を学んだがの大学でした。

HOLENETの開発

大学4年生になったときに、当時の安在教授の研究室に入り、重松保弘助手の下で、HOLENET（HDLC Oriented Local Area Network）というローカルネットワークの構築に行うことになりました。大学4年と修士の2年の合計3年間は、このHOLENETのハードウェア開発、ソフトウェア開発、そして、HOLENETを使った学生実験の指導を行いました。この3年間は、九州工業大学での6年間の中でも、最も楽しく多くのことを学んだ3年間でした。

HOLENETは、通信コントローラボード作りからでした。最初は、回路図の読み方から始まり、DMAコントローラとCPUとの間でどのようなタイミングシーケンスでDMA転送が行われるのか、割り込みとCPUの動きといったことを座学で学びました。また、HDLC/SDLC用の通信LSIを使うので、ネットワークプロトコルも当時はかなり勉強しました。ネットワークプロトコル関連では、当時の電電公社の横須賀通信研究所のデータ通信網研究室には、2回もインターンとして行きました。

実際の通信コントローラボードは、2枚の基板から構成され、1枚は1層のプリント基板であり、もう1枚はラッピングで作るというものです。その2枚1組の通信コントローラボードの5セットをほぼ一人で組み上げて、プローブが1つしかないオシロスコープだけで5セットをデバッグしました。5セットがある程度安定するまで何か月を要したか覚えていませんが、長い期間ハードウェアをデバッグしていました。ハードウェアが安定してきたら、その上で動作する通信ソフトウェアをZ80アセンブリ言語でひたすら書いてはデバッグしていました。

九州工業大学での最後の3年間は、ハードウェアのデバッグから、Z80アセンブリ言語でのプログラミング、ネットワークプロトコルと広範囲な経験をすることができました。

まとめ

九州工業大学への入学は、ソフトウェアエンジニアとしてのキャリアの始まりであり、その後のキャリアにとっての基礎を学ぶことができました。「コンピュータの基礎はいつ学ぶのか」でも書いていますが、今日では学んだり経験したりすることが難しいことの多くを大学で経験したと思います。

技術研修の予習

長年、いわゆるバイブル本を使った技術教育を行っていますが、昨年から始めた『Effective Java 第3版』研修では、事前予習での質問数がかなり少ないです。本来、さまざまな基礎知識を学んだ後に読まないと理解するのが難しいのが『Effective Java 第3版』なのです。そのため、通常のJava研修では、一年以上の研修の最後に学習してもらいます。

私のJava研修やGo研修の事前予習では、「読んで理解できていない箇所」を質問表に記入して欲しいのですが、そもそも、きちんと「理解できているか」という自問自答をせずに、流し読みしている人が多い印象を受けます。なぜなら、質問がない部分の記述に関して、「○○○○の部分はどのような意味か説明してください」と逆に私から質問すると、答えられない人がほとんどです。

感覚的なものに過ぎませんが、真剣に理解できているかと自問しなが予習する人ほど質問数が多くなります。逆に、質問が全くない人は、「完全に理解している」のではなく、「ほとんど理解していない」ことが多いです。

最近の例として、Go言語研修で多くの質問をされたのは@yosuke_furukawaさんですし、『Effective Java第3版』研修では、@orisanoさんです。

バグの修正の前に再現テストを先に書く

2003年以降、私自身のソフトウェア開発は、テスト駆動開発が基本です。ただ、私自身が開発せずに、指導やレビューを行ったテスト駆動開発もあります。

経験した中で大規模で技術的に複雑だったテスト駆動開発は、以下の二つです。

• 2003年2月から2009年8月：Linux/C++によるデジタル複合機コントローラソフトウェア
• 2013年7月から20015年5月：Linux/Goによるデジタル複合機コントローラソフトウェア

残念ながらどちらのプロジェクトも最終的なデジタル複合機製品とはなりませんでした。

コピー/スキャン/プリントなどの複合機※をテスト駆動開発でスクラッチから開発した経験やノウハウは、部分的にJaSST'18 Tokyoの招待講演とJaSST'19 Tokaiの特別講演で話しました。
※ 今日のオフィスにある富士ゼロックスやリコーなどのデジタル複合機のソフトウェアは、ソースコードの量として1,000万行に達しているようです。残念ながら、ほとんどが自動テストがないレガシーコードです。

テスト駆動開発の経験がない人がテスト駆動開発のプロジェクトに従事したときに、テストコードを書くことに加えて難しいのは「テストファースト開発」と「バグの修正の前に再現テストを先に書く」ことです。

不具合への対処手順

何らかの不具合が発見、あるいは報告されたときの手順は次のようになります。

1. 不具合の原因の調査
2. 不具合の再現テストの作成
3. 不具合の修正

1.で原因の調査を行って、不具合の原因を調べます。原因は、条件判定の漏れや間違いだったり、想定外の事象が発生していたりとさまざまです。

2.では、原因が分かったので、「パスしない再現テストを作成する」ことが重要です。そのようなテストを作成した経験のないエンジニアの場合、作成せずにいきなり不具合修正を行ってしまいます。不具合を修正したと報告を受けたときに、「再現テストは書いた？」と聞くと「書いていません」という返事をもらったことが多々ありました。

最後に不具合を修正して、2.で作成したテストがパスすることを確認します。同時に、既存のすべてのテストがパスすることも確認します。

不具合の原因によっては、再現テストを書くのが非常に難しことがあります。特に不具合の発生がスレッドのスケジューリングに依存する場合です。その場合には、ロギングを工夫して、テストコードからスケジューリングを指定できる機構を入れたこともあります。

まとめ

パスしない再現テストを書く習慣を持つことは重要です。テスト駆動開発を行っているのであれば、テストファースト開発と共に意識して行ってみてください。

テストファースト開発

（私自身のテスト駆動開発については、こちらにまとめてあります）

一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。

開発順序

現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。

1. 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
2. 既存のAPIの実装の調査（新たなAPIの場合には似たAPIの実装の調査）
3. テストコードの作成
4. 機能の実装
5. リファクタリング

1.ではAPIの仕様を記述していきます（「API仕様を書く」）。既存のAPIの仕様変更に関しては、もともとの仕様がきちんと書かれていない場合もあり、その場合は、ソースコードを調べて仕様記述を追記することもあります。

2.では、既存の実装の作り（構造）とテストコードを調べることになります。新たな機能をどのように作ればよいか、理解できるまで調査します。理解できたと判断したら、3.へ移ります。

3.の開始に際して、修正を行うマイクロサービスの既存のテストのフレームワークでは、私が書きたいテストが書けない場合があります。その場合には、新たなテストフレームワークの構築を行います。実際、メルペイで最初に担当したマイクロサービス用に私が開発したテストフレームワークを導入することが多いです。

3.と4.は実際には繰り返し行っていきます。まず、3.でAPI呼び出しがエラーになることが期待されるテストコードを書きます。そして、期待されるエラーが返ってこない（実際には実装部分には単純にpanic("Not Implemeted Yet")と書いてあるだけ）のを確認して、4.としてその部分の実装を行います。

エラーの実装が終わったら、正常ケースのテストコードを書きます。この時点でも該当する実装部分には、panic("Not Implemeted Yet")と書いてあるだけなので、テストが合格しないのを確認して、実装を行います。

すべてのテストの作成とその実装が完了したら、コードを見直して、リファクタリングです（5.）。そして、最後にPRのレビューをTech Leadへ依頼することになります。

テストファースト開発について

上記の開発順序は、私個人の開発順序です。実際に、最後のPRのレビュー依頼を行った時点では、テストコードと実装の両方が揃っていますので、どのような順序で開発しているかは分かりにくいです。

私自身がテストファーストで開発している主な理由は、短い勤務時間で担当する開発を着実に間違いなく行うためです。私自身は、テストファースト開発を最近始めたのではなく、昔から行っています。しかし、今は強く意識して行っています。

課題

ペアプログラミングがほとんど行われてない職場では、各人がどのような順序で開発しているのかが分かりにくいという問題があります。

テスト駆動開発とテストファースト開発には、ある程度の規律を必要とします。たとえば、不具合を修正する場合には、原因を調査後に、「再現テストを書いてから実装を修正する」ことが求められます（これも一種のテストファーストです）。本来、そのような規律は、ペアプログラミングなどを通して強制して習慣化させる必要があります。しかし、PRを最後にレビューするという開発スタイルの開発組織では、難しいものがあります。

お勧め本

僕たちの厳密さの一つの例が、自動化したユニットテストをテスト対象のコードより先に書くというルールだ。たいていのプログラマーはすぐにコードを書きたがる。書き上がれば出来映えに自己満足して、そのコードのために自動テストを書こうという気にはなかなかならないものだ。こういった習慣をやめてしまうのは簡単だろうが、僕たちがコードに期待する品質には極めて重大なものなのだ。テストコードを対象コードの前に書くという規律により、常に守れるようになるわけだ。

リチャード・シェリダン著『Joy, Inc.』（日本語版、p.212)

ジョイ・インク 役職も部署もない全員主役のマネジメント

• 作者: リチャード・シェリダン
• 出版社/メーカー: 翔泳社
• 発売日: 2016/12/20
• メディア: 単行本（ソフトカバー）

---

スポンサーリンク

複業を20年

振り返ってみると私自身がまだ40歳であった2000年の初めからほぼ20年間複業をしてきました。1984年に社会人になって、1999年までは会社での開発業務という単一の仕事をしていたのですが、2000年からは主に次の三つです。

1. 会社での開発業務（マネジメントや社内コンサルティングも含む）
2. 技術教育や講演
3. 技術書の執筆（雑誌の記事を含む）や技術書の翻訳

1. 会社での開発業務

1984年4月に富士ゼロックスに就職してから、6回の転職を経て現在はメルペイで働いています。自分で実際にソフトウェア開発をしている時期もあれば、開発のマネージャをやっていることもありますが、現在は、毎日Go言語でbackendのサービス開発をしています。

社会人となってから、実際に自分でコードをほとんど書いていないかったのは、日本オラクル、ジャストシステム、富士ゼロックス情報システム（FXIS）での最初の5年、リコーでの8年です。プログラミングしていないといっても、FXISやリコーではさまざな技術レビューは行っていました。

おそらく、会社の仕事だけをずっとしていたとしたら、今も実際にプログラミングしながらソフトウェア開発をしていなかったかもしれません。マネージャとして管理職業務を行いながら、ソフトウェア開発を続けるには、複業を行っていたことが大きな要因かもしれません。

2. 技術教育や講演

2000年から2017年8月までは主にグループ会社向けの技術教育が中心でした。最も長く続けているのはJava研修ですが、それ以外にもさまざな技術教育をグループ会社向けに行っていました。技術教育によっては会社が売り上げを上げるものはありましたが、私自身は、社員として業務の一部として行っていましたので、技術教育で別途私に収入があるわけではありませんでした。

20017年9月からは、週4日勤務で働き、金曜日に個人として技術教育を行っています。ソラミツでは雇用契約そのものを週4日にしてもらって働いていました。メルペイではそのような雇用形態は（現在は）なく、正社員として働いています。しかし、金曜日は原則欠勤しています。もちろん、欠勤すれば不足労働時間に対する勤怠控除が行われ給与が減額されます。

地方での講演の依頼に対しては、多くは手弁当で、妻と旅行を兼ねて行くことが多いです。函館、鹿児島、岡山、高松、長野、徳島、仙台、新潟、名古屋などがそうです。

3. 技術書の翻訳など

2000年から技術書の翻訳を私的な時間に始めたのですが、同時に技術雑誌に記事を書くようにもなりました。雑誌の記事は2007年まで続いており、記事をまとめて単行本にしたのが『プログラマー現役続行』、『ソフトウェア開発の名著を読む』、それに『Java 2 Standard Edition 5.0: Tiger』です。

技術書の翻訳も、継続して続けており、翻訳を通して技術を学習したり、自分の知識を再整理したりしますし、著者と多くのメールのやり取りをすることも多いです。現在は、私にとって18冊目になる技術書の翻訳を行っています。

振り返ってみて

60歳を目前にしてプログラミングしながらソフトウェア開発を続けられているのは、複業をこの20年間を行ってきたからではないかと思います。それぞれの活動が、いろいろな側面で相互に影響してきたと思います。

何歳まで続けられるか分からないですが、まだまだソフトウェア開発を続けていきたいと思っていますし、複業も続けていきたいと思っています。

---

スポンサーリンク

JaSST'19 Tokaiで話しました

10月4日（金）に愛知県刈谷市で開催された「ソフトウェアテストシンポジウム 2019 東海」で「私が経験したソフトウェアテスト 〜 ワークステーション、組み込みシステム、ウェブサービス 〜」と題して話しました。JaSSTでの講演は、JaSST'16 Niigataが初めてでしたので、今回で3回目となります。JaSSTの翌日の土曜日は、トヨタ産業技術館、名古屋城、徳川園、徳川美術館と観光して、日曜に横浜に戻ってきました。

今回のJaSSTでは、昨年のJaSST'18 Tokyoでの講演内容を修正して、メルペイでの経験も追加した内容を話しました。

会場の刈谷市総合文化センター

私の講演は午後2時からでしたので、講演後はkyon_mmさんの「アジャイル井戸端会議」のセッションに参加し、その後は情報交換会ということで、参加者といろいろと話しをすることができました。

3年前の新潟のときもそうですが、多くのソフトウェア開発組織でまだまだテスト駆動開発や継続的インテグレーションが普及していないというのを痛感しました。「継続的インテグレーションは強みでなくなった」という記事を書いたのが7年前ですが、なかなか当たり前にならないようです。

現在、私自身はメルペイでbackendのサービスの開発をしていますが、短い勤務時間※に担当する新たな機能や機能修正を確実に開発するために、テストファースト開発に日々努めています。
※ 単に、私自身の勤務時間が短いだけです。