14年ぶりの自著

技術書の翻訳本は20冊以上行ってきましたが、自分で執筆する本は2012年9月に出版した『"プログラマー"まだまだ"現役続行』が最後でした。紙の本は絶版ですが、Kindle版やPDF版で今でも読むことができます。

プログラマー"まだまだ"現役続行 技評SE選書

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2023/08/01
• メディア: Kindle版

最終的な発売日は未定ですが、14年ぶりに自著としての技術書を出版します。内容は、58歳から経験してきたWebサービスのバックエンドサービスに関して、「API仕様ファースト開発」をまとめたものとなります。

4月から（少し）働きます（その後）

「4月から（少し）働きます」では、会社勤めを終えて、個人事業主として働くということを書きました。その時点は、業務委託で少し働く予定でした。しかし、フルタイムで働いていないので、業務委託で働くことを打診されて、働くことになりました。次の2社で業務委託でソフトウェア開発に従事します。

• Digital Platformer（2024年4月1日〜）
• カウシェ（2024年4月22日〜）

どちらも自宅からのフルリモートです。稼働時間としては、両社で週に4.5日程度になりそうですので、ほぼフルタイムになります。

4月から（少し）働きます

4月から知り合いの会社の開発組織を手伝うということで、週に2日あるいは3日、リモートで働きます。

令和トラベルを退職して行ったこととして、以下のことを行いました。

• 国民健康保険の手続き
• こどもの国のウィークデーパスポートの購入

40年間の会社勤めで、会社を変わるごとに健康保険証が届くのに1週間以上を要していたので、同じように時間を要するのかなと思っていました。でも、実際は違っていました。

郵送での申請でも可能なのですが、必要書類を準備してから横浜市青葉区の区役所へ出向いて、保険年金課で申請しました。申請したら、その場で国民健康保険の健康保険証が発行されて、もらって帰ることができました。

こどのも国のそばに暮らし始めてから20年以上が経過していますが、今までは数えるほどしか行ったことがありませんでした。普段の心臓リハビリテーションとしては、天気が悪い日は家でエアロバイク、天気が良い日はウォーキングをしててきたのですが、仕事しながらだとどうしても朝10時のミーティングに間に合うようにしないといけませんでした。

これからは、時間的に余裕があるので、ウォーキングコースにこどもの国を入れたいと思い、こどもの国の「ウィークデーパスポート」（3,000円/年）を購入しました。

申し込み書と代金を窓口に出すと、引き換え証をもらえるので、それで入園できます。帰りに案内所で引き換え証と交換でウィークデーパスポートをもらえます。

こどもの国は水曜日は休園日なので、実質的に週4日しか使えません。ただ、季節によっては水曜日も休園しない日があります。

バックエンドサービス開発で当たり前に行ってきたこと

2000年以降に継続的インテグレーションが広まっていき、今ではCIということで当たり前に行われています。Go言語でウェブサービスのバックエンドサービスを開発するようになって6年ほど経過していますが、日々の開発の中で私自身が当たり前と思って行ってきたことがいくつかあります。

• ローカル実行：自分の開発用マシン（MacBook Pro）で、開発しているサービスの自動テストをローカルで実行できる
• カバレッジ：テストを実行した結果、どの行が実行されなかったかをカバレッジで確認できる
• 並列実行：Go言語の`testing`パッケージの`t.Parallel()`を使って並列にテストを実行することで、テスト対象のサービスに並列にリクエストを処理させる
• 長時間ランニングテスト：長時間ランニングテストができる

これらすべてができないとバックエンドサービスが開発できないわけではありません。そして、次のように反論されるかもしれません。

• ローカルで実行できなくても、CIですべてのテストを実行できています
• どの行が実行されていないかを確認しなくても、CIですべてのテストがPASSしているので問題ないのでは？
• 逐次的にすべてのテストがCIで実行されてPASSしているので問題ないのでは？
• ローカルで長時間ランニングテストをしなくても、CIでテストが1回PASSしているので問題ないのでは？

おそらく、この反論に対して相手が納得する説明を行うのは容易ではないです。なぜなら、私自身が当たり前に行ってきたことが何をもたらすかは、実際に行ってみてどのような問題を見つけるかを経験してみないと、容易に納得できないからです。

Hotfixとテスト失敗

何らかの緊急の障害に対して、Hotfixとして緊急に修正がリリースされることはよくあると思います。そのHotfixリリースのPull Requestを見たときに、既存のテストの修正が含まれていない場合、次のことが起きていることが分かります。

• 修正に該当する部分の機能をテストしているテストコードが存在しなかった。存在していればそのテストが失敗するので、一緒に修正されているはずです。
• 既存のテストが存在しないため、既存のテストに追加/修正を加えるといった再現テストの作成ができなかったし、新たに作成する時間もなかった。

緊急なので、後者も仕方ないです。しかし、リリース後に不足しているテストコードを作成したいものです。ソフトウェアエンジニアなら、後からでもよいので、テストを追加する習慣を身に付けるようにしてください。

伸ばすのが難しい能力（４）

2003年以降のデジタル複合機のコントローラソフトウェア、2017年9月からのウェブサービスのバックエンド開発をテストファースト開発によるソフトウェアの自動テストを長年行ってきて、バックエンド開発については「WEB+DB PRESS Vol.134」の特集1「実践API設計」としてまとめました。デジタル複合機のコントローラソフトウェア開発については、過去にカンファレンスなどで話しています。

これらの長年の開発で気付いていなくて、最近気付いたことは、次の2つの活動は強く関連していることです。

• API仕様をきちんと書く
• そのAPI仕様に基づく、自動テストコードを作成する

ウェブサービスで、バックエンドがフロントエンドに提供するAPI仕様をきちんと書き、そのAPI仕様に基づいて自動テストコード（E2Eテスト）を作成する行為で説明したいと思います。

自動テストがない

API仕様に基づいて、そのエンドポイントを直接呼びだして行うE2Eテストコードがない場合、API仕様をどれだけきちんと書いて、修正や追加の際に更新することのモチベーションはあるでしょうか？

API仕様をきちんと書かずに開発している場合、フロントエンドの開発者は、適当に仕様を推測して試してみたり、バックエンドの開発者に（Slackなどで）問い合わせたりしながら開発を続けていることが多いでしょう。

このような開発であると、バックエンド開発者にはAPI仕様を書くというモチベーションはありません。仮に書いたとしても、長期的にきちんと保守するというモチベーションもありません。

仮に、バックエンド開発者が書いた自動テストコードがあるとしても、それがすべての機能を網羅しているのか、あるいは足りないテストがあるのかは、その開発者以外は分かりません。ひょっとしたら、その開発者も分かっていないかもしれません。

あるべき開発サイクル

記事「実践API設計」で明示的には述べていませんでしたが、バックエンドでAPIの新たなエンドポイントを追加する場合、あるべき開発サイクルは次のようになります。

1. 新たなエンドポイントを定義して、その仕様（正常な動作だけでなく、エラーも含めて）を記述して、PR（Pull Request）のレビューをフロントエンド開発者に依頼する。フロンドエンド開発者は仕様から不明な点があれば、不明な点を明確にした内容を仕様に反映してもらうようにフィードバックする。
2. API仕様のPRの内容をフロントエンド開発者がレビューして問題がなければ、承認する。
3. バックエンド開発者は、API仕様に基づいて、そのエンドポイントを呼びだしてテストするE2Eテストを作成しながら、実装を行う。
4. テストコードの作成と実装が終われば、PRを他のバックエンド開発へレビュー依頼する。
5. レビューを依頼されたバックエンド開発者は、API仕様を確認して、E2Eテストで仕様が網羅されているか、漏れはないかを確認した後、実装をレビューして確認します。もしE2Eテストに、仕様に書かれていない動作がテストされてる場合、API仕様の更新を要求することになります。

このような開発サイクルが回っている場合、API仕様を書かないということはなくなります。ここで重要なので、API仕様に基づいて、エンドポイントを直接呼びだすE2Eテストを書けるフレームワークが整備されていることになります。

さらに、このような開発サイクルが回っている開発組織へ新たな開発者が参加しても、この開発サイクルを逸脱した開発を行うことはできません。なぜなら、API仕様や実装のPRが承認されないからです。その結果、その新たな開発者は、参加する以前の開発経験に関係なく、API仕様を書いてE2Eテストを開発することを経験することになります。

しかし、多くのソフトウェア開発組織は、そのようなE2Eテストフレームワークがないため、「自動テストがない」で述べたような状況で開発が進められてしまうことが多いと推測されます。そして、そのような開発組織でしか働いたことがない開発者は、API仕様を書くという習慣を身に付けないままとなります。

伸ばすのが難しい能力（３）

「伸ばすのが難しい能力（２）」の状況から、技術負債を返却して、API仕様ファースト開発への手順については、「実践API設計」で述べています。

WEB+DB PRESS Vol.134

• 出版社/メーカー: 技術評論社
• 発売日: 2023/04/22
• メディア: Kindle版

記事では書いていませんが、「第5章 API仕様の技術的負債の返済」で述べている返済を実行する上での課題は、多くのソフトウェアエンジニアは、経験したことがないことなので、そのメリットを十分に理解できないことです。そのため、実際に行ってみる強い動機を持って、実践できる開発者はとても少ないと思います。

このような状況を改善にするには、私の経験からは、「やってみせるしかない」ということです。私自身がウェブサービスに本格的に従事し始めたのは、2018年6月にメルペイ社へ入社して、加盟店様向けのマイクロサービスを一から開発することを担当したときです。

「第3章 API仕様ファースト開発」で説明している手順で開発しました。その大枠の手順は、次の図（第3章の図１）で示されています（詳しいくは記事を参照してださい）。

図1 API仕様ファーストでの開発順序

初めてのウェブサービス開発ではありましたが、この手順が私にとっては素直な手順であり、これを実施して最初のマイクロサービスを開発しました。

その後、メルペイ内では、チームを移動していくつかのマイクロサービスの開発に従事したのですが、その多くが以下の状態でした（「第5章 API仕様の技術的負債の返済」参照）。

• サービスのAPIに対する仕様が記述されていない
• サービスのAPIをテストする自動テストが存在しない

単体テストは多数あっても、開発しているマイクロサービスが提供するエンドポイント（gRPCのRPCエンドポイント）を直接呼び出してテストするテストコードが存在しないという状況でした。

そのため、新たなチームへ移動するごとに「第5章 API仕様の技術的負債の返済」で述べている内容を繰り返し、一緒に開発している他の開発者にも実践してもらうように働きかけてきました。

ただし、E2Eテストフレームワークの構築は、私自身で行いました。そうやって作成したE2Eテストフレームワークは、どのマイクロサービスからも使えるように独立したライブラリとして退職前には構築しました。

このような活動の結果として、最後にいたチームでは、既存機能の修正や新規機能の追加に際しては、かならずきちんとしたAPI仕様を記述し、そのエンドポイントを呼び出すE2Eテストを作成するということを普通に行ってもらえるようになりました。

ここでの重要な点は、残念ながら「API仕様ファースト開発」はやってみせないと広がらないということです。カウシェで働き始めてから一年近くなりますが、カウシェでも今では定着しています。

伸ばすのが難しい能力（２）

ウェブサービスは、フロントエンド（iOS、Android、ウェブブラウザ）とバックエンドから構成されます。バックエンドが提供する機能は、APIとして定義され、フロントエンドから呼び出されます。

この場合、「APIを定義する」行為にはいくつかのレベルが存在します。話を単純にするために、バックエンドのAPIがgRPCで定義されているとします。その場合、フロントエンドが呼び出すAPIは、protobufとして.protoファイルに定義されます。その.protoファイルに定義されるAPIにいくつかのレベルが存在します。

次は、最低限の定義のみの例です。呼び出すrpcやmessage定義が定義されているだけです。

service Greeter {
  rpc SayHello (SayHelloRequest) returns (SayHelloResponse) {}
}
message SayHelloRequest {
    string name = 1;
}
message SayHelloResponse {
    string message = 1;
}

実は、このレベルの定義だけで開発されているウェブサービスは多いと思います。その理由として以下のものが考えられます。

• フロントエンドとバックエンドを同一のエンジニアが開発しているので、この程度で分かるから問題ないと考えてしまう。
• フロントエンドのエンジニアからの問い合わせには、都度、Slackで回答しているから問題ない。

API仕様をきちんと記述することは開発スピードを落としてしまうので省いてしまうことが正当化されているように思われるかもしれませんが、実はそうではありません。その証しとして、サービスをローンチした後で時間的余裕が生まれてものこの状態が続くからです。

サービスを短期間で開発し、顧客に価値を提供し、サービスの価値を検証するためには、この程度の仕様で十分と考えて開発が進むと、結果的に、将来のサービスの成長を大きく阻害する技術的負債を積み上げていきます。

そもそもの原因は、「APIを定義するという行為は、この程度でよいという認識のエンジニアによって作成される」からなのです。

つまり、「伸ばすのが難しい能力」で述べた経験を積んでいないエンジニアが開発することにより、この状況は発生しているとも言えます。

（続き）

Kindle版『プログラマー”まだまだ”現役続行』

2010年9月4日に発売された『プログラマー”まだまだ”現役続行』ですが、8月1日よりKindle版がリリースされます。

プログラマー”まだまだ”現役続行 (技評SE選書)

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

目次は次の通りです。

第1章　ソフトウェアは「人」が作る
第2章　プログラマー現役続行
第3章　論理思考力：現役続行に必要な七つの力（1）
第4章　読みやすいコードを書く力：現役続行に必要な七つの力（2）
第5章　コンピュータサイエンスの基礎力：現役続行に必要な七つの力（3）
第6章　継続学習力：現役続行に必要な七つの力（4）
第7章　朝型力：現役続行に必要な七つの力（5）
第8章　コミュニケーション力：現役続行に必要な七つの力（6）
第9章　英語力：現役続行に必要な七つの力（7）
第10章　コードレビューのすすめ
第11章　若い人たちへ
第12章　30代，40代の人たちへ

三年間の在宅勤務

コロナがきっかけで2020年2月18日から在宅勤務（WFH：Work From Home）を始めて、ちょうど二年が経過しました。二年前と一年前の記事は、以下の通りです。

• 一年間の在宅勤務
• 二年間の在宅勤務

この一年間を簡単に振り返ります。

7回目の転職

大学院を修了して1984年4月に富士ゼロックスに就職してから7回目となる転職を、2022年10月にしました。年賀状も、先輩からは再雇用が終わりました、後輩からは定年を迎えましたというものが増えてきました。8社目となるカウシェでも、メルペイのときと同様に、ウェブサービスのバックエンドサービスをGo言語で開発をしています。Go言語との付き合いも13年となります（ちなみに、Javaは27年）。

メルペイおよびカウシェで私なりに工夫してきたバックエンドサービスのテストについては、4月下旬発売の雑誌に記事として掲載される予定です。雑誌の記事を執筆したのは、「Software People, Vol.8」（2006年3月発売）以来なので、17年振りとなります。

技術書の翻訳

この一年間では、幸い2冊の技術書を翻訳して出版することができました。

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

• 出版社/メーカー: インプレス
• 発売日: 2022/03/08
• メディア: Kindle版

PDF版は、出版社のサイトから購入できます（こちらです）。

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

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

PDF版は出版社のサイトから購入できます（こちらです）。

技術書の翻訳としては、『Go言語による分散サービス』でちょうど20冊目となりました。現在、21冊目となるGo言語に関する書籍の翻訳を行っていますので、夏以降に発売になるかと思います。

オンライン読書会

この一年間もいろいろとオンライン読書会を主催してきました。

• 横浜Go読書会
• 技術書読書会
• 技術書読書会2

基本的に月1回、土曜日の午後1時から午後5時までの4時間のオンライン読書会ですが、継続して実施することで、一冊の本を読み切ることができます。「横浜Go読書会」は、Go言語に関する書籍を読む読書会です。「技術書読書会」は、特定の技術に関する技術書ではなく、ソフトウェアカルチャーやソフトウェアエンジニアとしての心得的な技術書を読む読書会です。「技術書読書会2」は、基本的に私が翻訳した技術書を読む読書会になっています。

技術教育

この一年は、『Effective Java 第3版』研修を1コースだけ実施しました。月に1回で、合計6回に分けて、各回で指定された範囲を事前に読んで、疑問点を質問表に記入してもらいます。研修当日はその質問に回答していくという形式の研修です。休憩ごとに気分転換に『Java Puzzlers』のパズルを解いてもらいますが、正解する人はあまりいません。

『Effective Java 第3版』は、多くのJavaプログラマが読んでいると思いますが、詳細まできちんと理解して読めている人は少ないのではないかと思います。以前は、オンライン読書会として、「Effective Java 第3版読書会」を主催していましたが、参加者があまりにも少ないので、現在は開催していません。

健康面

2020年6月20日（土）に急性心筋梗塞で救急搬送されて以降、薬と食事制限を続けており、週に５，6日は自宅での30分間のエアロバイクも継続しています。お酒も、基本的には一日おきです。

30代から50代まではずっと、健康診断や人間ドックでの血液検査でさまざまな値が悪かったのですが、現在はほとんどすべての検査項目が正常値に収まっています。また、長年、人間ドックでは超音波エコーによる「脂肪肝」の所見があったので、過去2回の人間ドックでは「脂肪肝」の所見はなくなりました。

在宅勤務という働き方

1984年に就職した頃は、ソフトウェア開発を行うには、会社に行くしか選択肢はありませんでした。ソフトウェアの開発環境はすべて会社にしかなかった時代です。1990年代には、電話回線を使って会社のコンピュータへ入って、自宅から簡単な作業ならできたりもしたのですが、基本は会社へ出社でした。そして、2020年初めにコロナの感染が広がる前まで、出社していた訳です。ただし、その頃は、何かのときには自宅から普通に作業できる環境にはなっていました。しかし、体調不良とか、雪で交通機関がマヒしているとかでない限り、出社でした。

そして、コロナによる在宅勤務が始まり、それが長期間となったため、2018年の入社当時は原則出社であったメルカリも「YOUR CHOICE」という制度を導入するまでに変わっていきました。

現在勤めているカウシェでも、基本的に在宅勤務を続けていますし、入社してからまだ一度も出社していません。在宅勤務における一番の問題はコミュニケーションだと思います。しか、在宅勤務という働き方が、後退して出社するという時代に戻ることはなく、コミュニケーションの問題は今後さまざま方法や技術により緩和されていくと思います。

社会全体が在宅勤務になることはありえませんが、ソフトウェア開発は、その性質上、在宅勤務が可能な領域が多いと思います。コロナが収束しても、おそらく今後もずっと在宅勤務を続けていくだろうと思います。