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

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

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

株式会社メルペイを退職します

2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。

週4日勤務

「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。

初めてのウェブサービス開発

富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に従事してました。ウェブサービス開発に従事するのは、（gRPCの経験は、前のソラミツで多少は経験していましたが）メルペイがほぼ最初と言ってもよい状態でした。

メルペイでは私が入社した時点で、すでにマイクロサービスをGo言語で開発していました。私自身は、Go 1がリリースされるより前の2010年夏からGo言語を学んでおり、メルペイへ入社した時点で、次の2冊のGo言語に関する翻訳本を出していました。

プログラミング言語Goフレーズブック

• 出版社/メーカー: ピアソン桐原
• 発売日: 2012/10/04
• メディア: 単行本（ソフトカバー）

プログラミング言語Go

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

Go言語に関しては特に問題はなかったのですが、それ以外の使っている技術やサービスは初めて触れる物がほとんどでした。

最初に担当したマイクロサービス

最初に担当したマイクロサービスは、「加盟店様向けの管理画面」用のAPIマイクロサービスでした。管理画面の仕様に対して、バックエンドのAPIマイクロサービスがどのような機能を提供すれば仕様を実現できるかと検討しながら、マイクロサービスのAPI仕様を.protoファイルにコメントとして記述して、API仕様を策定する作業を2か月ほど行いました（「gRPCを用いたマイクロサービスのAPI仕様の記述」）。

最初の仕様が確定してから、マイクロサービスをどうやってテストするのかを検討しました。正直、ウェブサービスが初めてで、マイクロサービスも初めてでしたので、どのようにテストするのが標準的なのか全く知らない状態で、テスト方法を検討しました。

その結果、gRPCのエンドポイントを呼び出して、マイクロサービスの本番コードをほぼそのまま起動して、手元のMacBook Proでテストできるテストフレームワークを考案しました。正直、その時点で、メルペイ内の他のマイクロサービスがどのようにして、gRPCのエンドポイントを呼び出してテストしているのかはほとんど知りませんでした。

フレームワークの実装が終わったら、gRPCのエンドポイントを順にテストファーストで開発していきました。この時の経験をGDG Dev Fest Tokyo 2019で話をしました。その後、同じ話をいくつかのカンファレンスで話したのですが、最後は、Mercari Gearsとして動画（およびテキスト）にしてもらいました（merpay マイクロサービスの開発とテストファースト/テスト駆動開発）。

私が考案したマイクロサービスのテストフレームワークは、後に独立したリポジトリとして共通ライブラリとして私自身で整備し、現在では、採用しているマイクロサービスが増えています。

他のマイクロサービスチームへの異動

その後、いくつかのチームを異動して、2020年7月からは「メルペイスマート払い」に関連するマイクロサービスチームへ異動しました。このチームでは、私自身で何らかのビジネスロジックを実装することはほとんど行っていません。しかし、行った作業の中でも印象的なのは、「テストの安定化」です。

異動してきた時点で、そのマイクロサービスの自動テストは安定しておらず、かなりflakyなテスト群となっていました。テストを安定させるために、何が問題なのかを一つずつ調べて修正していきました。その際に、問題点を洗い出すための用いた手法が、「長時間ランニングテスト」です（「長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」「（続）長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」）。

長時間ランニングテストは、私自身にとっては、目新しい手法ではなく、2003年からずっと行ってきた手法です（「マルチスレッドプログラミングにおける重要な４要件」）。基本的に、この長時間ランニングテストは、ずっと続けてきました。

テストが安定化した後に、問題になったのは、テスト時間でした。そのため、t.Parallel()を呼び出したら並列に動作しないテストコードを一つずつ修正して、できる限り並列に実行するようにしました。そのときの知見をまとめたのが、「Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜」です。

複業の継続

「複業を20年」に書いていますが、週4日勤務というのもあって、メルペイ在籍中も継続して行ってきました。

技術書の翻訳

翻訳本としては、以下の4冊を出版しました。

Effective Java 第3版

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

新世代Javaプログラミングガイド[Java SE 10/11/12/13と言語拡張プロジェクト] (impress top gear)

• 出版社/メーカー: インプレス
• 発売日: 2020/03/13
• メディア: 単行本（ソフトカバー）

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

• 出版社/メーカー: インプレス
• 発売日: 2022/03/08
• メディア: 単行本（ソフトカバー）

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

• 出版社/メーカー: オライリージャパン
• 発売日: 2022/08/03
• メディア: 単行本（ソフトカバー）

技術教育

企業向けの技術教育としては、「Go言語研修」と「Java言語研修」を行ってきました。2020年2月まではオフラインの教育でしたが、それ以降は、オンラインの教育でした。オフラインの教育では、研修後に受講生の人達と懇親会をするのも楽しみでした。また、Go言語研修では、古川陽介さんや和田卓人さんも受講してくれました（「第6期、第7期のGo言語研修が終了しました」）

これから

これからもソフトウェアエンジニアとして働きながら、技術教育や技術書の翻訳、それにオンライン読書会（ブログのPC版で左上に一覧があります）も続けていきたいと思っています。

書籍『The Kubernetes Book』

The Kubernetes Book: 2022 Edition (English Edition)

• 作者: Poulton, Nigel
• 出版社/メーカー:
• 発売日: 2017/06/18
• メディア: Kindle版

過去のEditionは読んでいませんが、2022 Editionとなっている2022年版を読みました。Kubernetesにに関する書籍を読んだのは、2018年6月にメルペイに入社してから読んだ『Kubernetes in Action』以来です。

Kubernetesを学ぶのが初めてではないこともあり、内容も分かりやすく、知識が深まった部分も多かったです。

この本で特筆するとしたら、セキュリティに関する章があることだと思います。「15: Threat modeling Kubernetes」「16: Real-world Kubernetes security」です。詳細に説明されているわけではありませんが、Kubernetesに関するセキュリティの概要を知ることができます。

『プログラミング言語Go』オンライン読書会の第2サイクルが終わりました

プログラミング言語Go

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

書籍『プログラミング言語Go』のオンライン読書会の第2サイクルは、8月6日で終了しました。第1サイクルと第2サイクルの期間は、以下の通りでした。

• 第1サイクル：2020年6月6日〜2021年6月5日（計13回）
• 第2サイクル：2021年7月3日〜2021年8月6日（計13回、11月は未開催）

初回と最終回の参加者数は、次の通りでした。

• 第1サイクル：初回22名、最終回10名、全出席2名
• 第2サイクル：初回25名、最終回6名、全出席1名

『プログラミング言語Go』は2016年6月に出版され、Go 1.5をベースとしているため、それ以降の言語仕様の変更や標準ライブラリの拡張は当然含まれていませんが、多くの基礎的な事柄が含まれています。一方で、「ロック（ミューテックス）の再入可能性」などのように、（おそらくほとんどの読者が）理解するのが難しい説明が含まれていることがあります。読書会では、都度言語仕様の変更やライブラリの拡張の補足、それに理解するのが難しい内容の説明などと行ってきました。

『プログラミング言語Go』オンライン読書会は、しばらく休会とします。

正誤表：『Go言語による分散サービス』

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

• 出版社/メーカー: オライリージャパン
• 発売日: 2022/08/03
• メディア: 単行本（ソフトカバー）

正誤表を追加しました：「正誤表」のタブを選択してください。

https://yoshikishibata.github.io/

書籍『Docker Deep Dive』

Docker Deep Dive: Zero to Docker in a single book (English Edition)

• 作者: Poulton, Nigel
• 出版社/メーカー:
• 発売日: 2016/09/20
• メディア: Kindle版

「MAY 2020」とカバーにある（おそらく最新版）を読みました。普段、Dockerを深く使いこなしてはいないので、Docker全体を知るために読んでみました。

Dockerfileやdocker-composeについてはもちろん説明はされています。それ以外にも、Docker Swarm、Docker Stacks、ネットワーキングについても解説されていますし、15章「Security In Docker」ではセキュリティに関する基本的な事柄も説明されています。

Dockerのセキュリティに関しては、ちょうど「Security Journey」で基本を学んだばかりでしたので、復習にもなりました。

Docker Swarm関連では、分散サービス用のRaft、gossipプロトコル、リーダー選出（leader election）などの用語が事前説明なしで使われています。これらも『Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築』で学んだばかりだったので、問題なく理解することができました。

本の内容は、実際に手元でDockerを動作させて確認できますし、Docker Swarmについても（全部ではないですがある程度）Play with Dockerで試すことができます。

『人月の神話』オンライン読書会を開催します

人月の神話

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

9月より、月に1回、土曜日の午後1時〜5時で、書籍『人月の神話』のオンライン読書会を開催します。

第1回『人月の神話』オンライン読書会

この本については、拙著『ソフトウェア開発の名著を読む【第二版】』でも紹介しています。

ソフトウェア開発の名著を読む 【第二版】 (技評SE選書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2009/10/21
• メディア: 単行本（ソフトカバー）

『Go言語による分散サービス』オンライン読書会を開催します

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

• 出版社/メーカー: オライリージャパン
• 発売日: 2022/08/03
• メディア: 単行本（ソフトカバー）

今までのオンライン読書会は、出版されてから時間がしばらく経過している本を取り上げることが多かったのですが、8月に出版される私の新たな翻訳本を使ったオンライン読書会を開催します。

第1回『Go言語による分散サービス』オンライン読書会

月に1回、土曜日の午後1時から5時までの読書会です。

2020年からさまざまなオンライン読書会を開催してきていますが、第1回が最も参加者が多く、徐々に少なくなっていきます。最後まで参加される人は、だいたい決まっています。これは、オンラインの読書会に限った話ではなく、会社内で行ってきた読書会も同じ傾向でした。

オンライン読書会での特徴の一つとして、過去に私の他のオンライン読書会に参加経験がなくて、ある本のオンライン読書会の何回目かに初めて参加される人の中には、必ずといってよいほど、キャンセル処理をすることなく欠席される人がいます（開催の案内メッセージで、「都合により欠席される場合、キャンセル処理をお願いします。」と毎回書いているのですが）。そのようなキャンセル処理なしで欠席されたことがある参加者は、申し込まれても私の方でキャンセル処理することがあります。

書籍『Googleのソフトウェアエンジニアリング』

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

• 出版社/メーカー: オライリージャパン
• 発売日: 2021/11/29
• メディア: 単行本（ソフトカバー）

職種としての「ソフトウェアエンジニア」は、ソフトウェアの設計から実装まで行うものと考えられることがあると思います。しかし、そこにエンジニアリングという視点はどの程度含まれるのでしょうか。さまざまな設計手法、さまざまなレビュー、テスト駆動開発、継続的インテグレーションなどの実践は、確かにエンジニアリングではあります。しかし、実践できていない開発組織もまだまだ多いと思います。

仮に実践できているとしても、小さな組織で行っているエンジニアリングが、Googleほどの大きな組織へと拡大するためには、スケールするのかを考える必要があります。Googleほどの大きさにならなくても、ビジネスが成長しているのであれば、それを支える開発組織も大きくなっていき、今までのエンジニアリング的な実践がスケールするのかを考える必要が自然と発生していきます。

この本では、大きなソフトウェア開発組織へと成長する過程で、試行錯誤しながらGoogleが取り組んできたソフトウェアエンジニアリングについて述べられています。

私自身のウェブサービスの開発経験はメルペイで働き始めてからなので限られてはいますが、この本を読みながら、現在自分達が直面している問題、あるいは、今後直面するであろう問題を色々と考えさせられることが多い内容でした。ただ、私自身があまり馴染みがない領域に関しては内容を理解できないものもありましたが、全体としてはとても参考になることが多い本でした。

この本で紹介されているHyrumの法則というのがあります。

あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要でない。作られたシステムが持つあらゆる観測可能（obserbable）な挙動に関して、それに依存するユーザーが出てくるものである。

この法則に、いかに苦しんできたかは、この本全体でいろいろなところに登場します。小さな組織であれば、API仕様をきちんと書いておくだけでおそらく十分なのでしょうが、組織が大きくなれば、Hyrumの法則が登場して、思わぬ使われ方や想定が行われるようになっていくということです。