今日から8社目

今日（10月1日）から、私にとって8社目となる新たな会社で働き始めます。ただ、今日は土曜日なので、実際には3日（月）からとなります。

1978年4月に、当時としては全国でも数少ない情報工学科（九州工業大学）に入学してから、すでに44年が過ぎました。高校生のときに、なぜ情報工学科を選択したのかあまり覚えていませんが、一般家庭の多くに電卓さえなく、コンピュータに触ったことがない人がほとんどだった時代でしたので、コンピュータを学びたいと思ったのかもしれません。当時、情報工学を提供しているのは、九州では、九州大学と九州工業大学だけでした。私は、情報工学科の第8期生だったと思いますので、九州工業大学では早くから情報工学科※があったことになります。
※ 現在は、当時なかった飯塚キャンパスに情報工学部があり、戸畑キャンパスの工学部には情報工学科はありません。

大学生の頃、60歳過ぎまでソフトウェア開発に従事しているとは想像できませんでした。社会人になっても、多くの同期が30歳過ぎぐらいにはソフトウェアを開発しなくなっていく中で、私自身はソフトウェア開発を続けていたいと思っていました。36歳で最初の転職をしたのですが、その後は、実際にソフトウェア開発をしたり、管理職をしたり、あるいはプレイングマネージャとして両方を行ったりしてきました。

メルペイでは、一人のソフトウェアエンジニアとして4年4か月働きました。Covid-19により、2020年2月18日から在宅勤務となり、その後は昨日（9月30日）の退職日を含めて2回しか出社していません。そして、この間に、世の中の働き方が変わり、フルリモートで働くことが可能な会社が増えました。

今後も在宅勤務で働きながらソフトウェア開発を続けることになります。今の時代は、通勤することなく、どこからでも、何歳までもソフトウェア開発を続けることが可能になったとも言えます。私自身は、正直なところ、何歳まで働くのか分からないですが、いつまでもソフトウェア開発を楽しめるように健康でいたいと思っています。

「で、どこの会社で働くの？」・・・来週金曜日までには、おそらくアナウンスします。

外部発信よりも内部共有・実践

エンジニアが集まって、LTを行ったり、20分から30分程度の発表を平日の夜に行うというのは、いつ頃から広まっているのか定かではありませんが、この10年間で確実に広まってきています。さらに、コロナ禍により、オンライン開催も加わり、広く行われるようになりました。

一方、Advent Calendarといったtech blog（技術文書）を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。

外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで行われていくと思いますし、ソフトウェア業界で知見を共有する上でとても有益だと思います。

このような情報発信を外部から見てみると、発信されている知見がその企業で広く共有され、ベストプラクティスと思われるようなことは、その企業内で広く実践されていると思いがちだと思います。しかし、本当にそうなっているのでしょうか？

多くのIT企業やスタートアップでの情報発信は、「外部へ発信」することが目的であり、「知見を社内で共有する」ことは目的ではなかったりするのではないでしょうか。得られた知見やベストプラクティスなどは、外部へ発信するのではなく、内部で共有して実践することが、企業にとっては本来優先順位が高くあるべきだと思います。その上で、外部発信することで、業界全体へ貢献することになります。

おそらく、このような状況になるのは、外部への発信を促進する責任を持つチームやグループが組織内にはあるけど、内部での共有や実践を促進することに責任を持つチームやグループが存在しないからではないでしょうか。あるいは、個々のエンジニアにとって、そのような活動をすることが責務ではないからかもしれません。あるいは、一人のエンジニアとして強く推進するのにはかなりの努力が必要な場合があるからかもしれません。

組織として何らかの活動をしないと、さまざまな知見やベストプラクティスが、属人化したものとなってしまい、たとえそれらが外部へ積極的に発信されていていも、組織内で広く共有されいなかったり、実践されていなかったりするのではないでしょうか。

手動テストだけのソフトウェアは腐っていく

1990年代までのソフトウェアテスト

1990年代までのソフトウェア開発におけるテストは、手作業で目視確認が主流でした。今日のようにテスト駆動開発で、自動テストを書くという習慣はありませんでした。いくつかの書籍から、本当でそうであったかを引用すると次の通りです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

• 出版社/メーカー: オーム社
• 発売日: 2014/07/26
• メディア: 単行本（ソフトカバー）

著者のMartin Flowerは、この本の中で次のように述べています。

テストの実行は確かに簡単になりました。しかしテストの実行は簡単になってもテストは依然として極めて退屈なものでした。これは、コンソールに出力されるテスト結果を私がチェックしなければならないためです。

Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ)

• 出版社/メーカー: ドワンゴ
• 発売日: 2017/12/28
• メディア: Kindle版

この本で、著者のRobert Martinも、次のように述べています。

この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。

Coders at Work プログラミングの技をめぐる探求

• 出版社/メーカー: オーム社
• 発売日: 2011/05/25
• メディア: 単行本（ソフトカバー）

『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。

「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」
それに対して、Joshua Blochは、

「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」

という話をしています。

1週間半費やしてその原因が何であったかというと、彼が書いたコードではなくて彼が書いたコードが使っていたミューテックスのライブラリにバグがあったっていうことです。それに対してインタビュアーが、

「そのミューテックスの作者がテストを書いていればバグは見つかったはずで自分が1週間半デバッグすることはなかったのにと思いますか？」

と聞いています。

インタビュアーの質問に対するJoshua Blochの回答は次の通りです。

頭に入れておく必要があるのはこれが90年代初期の話だということです。十分なユニットテストを書いていないということで、そのエンジニアを非難しようという気は全く起きませんでした。

1990年代は、このような時代だったのです。実際、私自身も、テスト駆動開発を行うようになったのは、2003年からです。

手動テストだけのソフトウェアは腐っていく

私自身は、1980年代、1990年代といくつかのプロジェクトに従事してきました。そのほとんどが、新規開発プロジェクトでしたが、後継の商品が開発されないものがほとんどでした。結果、手作業でテストしていたにも関わらず、開発されたソフトウェアが長年にわたって肥大化する前にプロジェクトが終わってしまい、ソフトウェアが腐っていくといことをあまり実感していませんでした。

2000年以降も新規開発プロジェクトにいくつか従事したのですが、一方で、既存のソフトウェアの修正などのレビューも多く行ってきました。さまざまなソフトウェアをレビューしていくなかで、分かったのは、「手動テストだけに頼っているソフトウェアは、年々腐っていく」ということです。

1. 手動テストだけに頼ってテストされており、すべての機能のテストに多くのテスターと長い期間を必要とする
2. 機能が毎年追加されたり、修正されたりしている

1．に関しては、最初は少人数で短期間であっても、機能追加が行われるごとにテスターの人数が増えて、テスト期間が長くなっていきます。

すべての機能を一通りテストする工数が増大してくると、追加された機能やバグ修正された機能だけをQAがテストして、リリースしようとします。そうなると、機能の追加やバグ修正の際に、次のことが（マネジメントから）要求されるようになります。

• 既存の機能のコードには一切変更を入れない。たとえ、新規機能で追加されるコードと共通化できるコードがあっても、共通化が既存の機能のコードの修正になるなら、共通化は行わない。
• バグを修正する場合も、修正コードを追加した結果、仮にif文のネストが深くなったり、caseラベルの処理が長くなったりしても、関数化やメソッド化によって既存の機能のコード変更になる場合、関数化やメソッド化は行わない。

つまり、既存の機能のコードは、一切触らないし、リファクタリングもしないまま、次のようなコードが生み出されていきます。

• 似て非なるコードが多くある。つまり、既存の機能のコードをコピーしてきて、一部を修正しただけのコードが増えていく。
• if文のネストがとても深くなっていく。
• caseラベルの処理が長くなっていく。さらに、その処理にネストが深いif文が書かれる
• 一つの関数やメソッドが長くなっていき、その中のローカル変数のスコープが広くなって、実質的にグルーバル変数のようになってしまう。

このように腐ってしまったソースコードは、エディタで開いた瞬間、そっと閉じたくなるものです。

テストファースト開発（2）

以前、「テストファースト開発」と題して、当時どのように開発していたかを書いています。その中で開発のフローについて、次のように書いています。各ステップの解説については、前述のブログを読んでください。

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

今週は、あるマイクロサービスの機能の一部を別のマイクロサービスへ移行する作業をしました。機能そのものは小さかったのですが、実際に行ったことは、次の通りです。

API仕様の確認

最初に、API仕様、つまりgRPCの.protoに書かれているrpcの仕様を確認しました。仕様を読んで、疑問に思うことが何点かありました。つまり、仕様から読み取れない振る舞いがあった訳です。それで、既存の実装コードを調べたり、既存のe2eテストを修正して試したりして、不明な振る舞いの動作を確認しました。

確認した内容のすべてをもとの.protoファイルに記述するPR（Pull Request）を作成し、もとの開発者にレビューをお願いしました。私が調査から読み取れていなかった点の指摘があったので、指摘点を修正して、PRをapproveしてもらい、マージしました。.protoファイル内にコメントして記述されている仕様の修正なので、特に実装の変更はありません。

テストコードの作成

もとのマイクロサービスにあったe2eテストを参考に、修正されたAPI仕様に書かれていることをすべて網羅するのを確認しながら、新たなe2eテストを作成して、すべてのテストが失敗するのを確認しました。

実装

テストが合格するように順次実装していくのですが、まだ実装していない箇所にコードが到達した場合には、panicするかUnimplementedエラーを返すようにコードを入れながら実装していきます。テストがすべて合格するまで、実装を行っていきます。

すべてのテストが合格したら、テストによって実際に実行されたコードをカバレッジで確認します。ここで重要なのは、カバレッジのパーセントではなく、実装したコードがすべて実行されたかです。私個人としては、「開発者はカバレッジのパーセントではなく、実行されたコードを確認することが重要」と思っています。

確認してみると、実際に起きたらInternalエラーになるコードが実行されていないことが判明しました。Internalエラーは、設計上想定していないことが起きていることを意味しますので、そのエラーをテストで起こせるかどうかは、内容次第となります。今回は、テストコードで起こせるものだったので、追加のテストコードを作成しました。

この追加のテストコードは、すでに実装が書かれているので、合格するテストを最初から書いてしまうと単に合格してしまいます。それでは該当コードが実行されたことによって合格しているのか、それとは別の理由で合格しているのか分からなくなってします。それで、わざと（正しくはない）合格しないテストを書いて、失敗することを確認してから、正しいテストへ修正して、合格することを確認しました。

最後にカバレッジで実行された実装コードを確認して、実装作業は終了です。

コードを見直して、とくにリファクタリングは必要ないと判断し、PRをレビューに出しました。

20冊目の技術書の翻訳の状況

私にとって通算20冊目となる技術書の翻訳本ですが、早ければ今週中に出版社での組版が終わった初校が上がってきそうです。初校のPDFが送られてくたら、私の方で10日ほどでチェックすることになります。

一年で2冊出すのはあまりないのですが、今年3月に出版した19冊目の『スーパーユーザーなら知っておくべきLinuxシステムの仕組み』と比べると、20冊目はページ数も少なくコードも多いので、翻訳に要した時間は、19冊目の1/3程度となっています。

メルペイで4年が過ぎました

ソラミツを退職して、メルペイに入社したのが、2018年6月1日でした。ちょうど4年前です。

入社前の面談で、週4日勤務（金曜日は休み）を希望したのですが、雇用形態としてはそのような制度はないということで、正社員として採用されました。ただし、金曜日は欠勤としたり、有給休暇を使ったりして休んでよいということで、入社しました。メルペイのサービスを最初にリリースする前の2か月ほどは、金曜日に働いたことはありますが、それ以外は金曜日は欠勤か有給休暇で休んでいます（欠勤すると所定労働時間に達しないので、不足分は給与が減額されます）。

技術教育と技術書の翻訳

金曜日は、主に複業としての技術教育（Java言語教育やGo言語教育）や技術書の翻訳などを行ってきました。もちろん、単に休むこともあります。副業としてのソフトウェア開発を行っているエンジニアも多いですが、ソフトウェア開発は締め切りがあったり、デバッグがいつ終わるか予想できないことがあるので、私は行わないようにしています。

Go言語教育では、古川陽介さんと和田卓人さんが受講してくれました。古川さんは、彼が社会人になった頃からの知り合いですが、和田さんとも知り合えたのがよかったです。

技術書の翻訳も以下の4冊を行えています。4冊目（Go言語による分散サービスに関する書籍）はまだ発売されていませんが、4月末には私の作業は終わっており、現在出版社による組版を待っています。

• Effective Java 第3版
• 新世代Javaプログラミングガイド
• スーパーユーザーなら知っておくべきLinuxシステムの仕組み
• タイトル未定（2022年夏発売予定）

メルペイでの活動

メルペイでは、Backendのソフトウェアエンジニアとして、マイクロサービスの開発に従事してきました。1984年4月に社会人になってから、主にワークステーション開発とデジタル複合機の組み込みシステムの開発を行ってきており、ウェブサービスの開発に本格的に従事したのはメルペイが初めてでした。Kubernetesについては、書籍『Kubernetes in Action』で独学しながらの開発でした。

マイクロサービスの開発を通しての成果として、いくつかのTech Blogを書いています。また、GDG DevFest Tokyo 2019やJaSST'19 Tokaiで登壇して、マイクロサービスでのテスト駆動開発について話しました。

今後

現在の私の年齢は62歳6か月であり、65歳までにあと2年半となりました。今後もソフトウェア開発に従事しながら、複業を続けていきたいと考えています。

伸ばすのが難しい能力

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。

ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。

• 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない
• テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない
• Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない

API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書き方」としてmerpay Tech Talkで話しています。

実装を一切書かずに、きちんとAPI仕様を書けないと、おそらくテストファースト開発もできないと思います。色々な人達とソフトウェア開発を行った経験から、この二つは、かなり密接に関連しているのではないかと思っています。

残念ながら、上記の三つは、プログラミングを覚える際に習うことはないため、身に付かないまま年数を経ている開発者が多いと思います。では、どうやったら身に付くかというと、上記の三つを伸ばすための活動をきちんと行っている開発組織で働くことです。そうでなければ、たいていは無理ではないかと思います。もちろん、個人で身に付ける人はいるとは思いますが、継続したレビューで指導してくれる人達がいないと、多くの人にとってはなかなか難しいでしょう。

しかし、そのような開発組織を見つけるのは、容易ではありません。多くの企業は、使っている技術や組織の文化とかは盛んにアピールします。しかし、上記の三つの能力育成活動をきちんと行っている組織はもともと少なく、その上で外に向けてアピールする企業はほとんどないからです。さらに、きちんと行っている組織は、そうするのが当たり前だと考えられていて、わざわざ当たり前と思うことを外に向けて発信することはないと思います。

翻訳する技術書の選択

以前から聞かれる質問に、「翻訳する技術書はどのように決まるのですか」というのがあります。どのように決まるかは、次の二つのパターンに分かれます（一度翻訳した本の改訂版は別として、新たな技術書の翻訳の場合です）。

• 出版社が翻訳する技術書を選定して、その翻訳を依頼される
• 私が翻訳したいと思う技術書を、出版社へ打診する

今まで19冊を出版していますが、一度翻訳した本の改訂版を除くと、出版社からの依頼が7冊、私から出版社に打診して翻訳したのが9冊です。

私から打診した本がすべて採用される訳ではなく、以下の理由でダメな場合があります。

• 翻訳しても売れそうにないと判断される
• 実はすでに翻訳が進行中である
• （まれですが）翻訳されることを、著者が許可していない

ちなみに、19冊目の『Linuxシステムの仕組み』は、私から出版社へ打診した本です。そして、今年の夏に出版予定の20冊目は、出版社から依頼された本です。

最近、予約注文した専門書

読みかけの専門書もまだ多くあるのです、新たに以下の3冊を予約注文しました。

Code: The Hidden Language of Computer Hardware and Software

• 作者: Petzold, Charles
• 出版社/メーカー: Microsoft Press
• 発売日: 2022/08/19
• メディア: ペーパーバック

第2版ということで、どのような内容になっているのか楽しみ。

API Design Patterns: Simplify Your Remote Service Interface (Addison-Wesley Signature Series (Vernon))

• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2022/09/16
• メディア: ペーパーバック

API Design Patternsというタイトルに惹かれて。

Tour of C++, A (C++ In-Depth Series)

• 作者: Stroustrup, Bjarne
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2022/10/10
• メディア: ペーパーバック

私のC++に関する知識は2009年で止まっているので、C++を学び直したいと思い。

FORTRANから始まって41年（まとめ）

3年前に「FORTRANから始まって41年」と題した一連のブログを書いたのですが、再度まとめを掲載します。各ブログのタイトルは全部「FORTRANから始まって41年」となっているのですが、それでは分かりにくいので、各テーマを代わりに列挙しています。

• FORTRANから始まって41年
• 新たなプログラミング言語への取り組み
• コンピュータ・サイエンスの基礎
• 継続的な学習習慣
• きちんとしたAPI仕様の作成能力
• 読みやすいコードを書く能力
• テスト駆動開発の実践
• テスト設計能力
• 若手人材を育成していく能力
• 教育を行う能力