時の流れは早く、今日で65歳になりました。

今年の3月で、40年間支払い続けてきた厚生年金保険料と会社勤めを終え、4月から個人事業主として業務委託でソフトウェア開発に従事しています。これまで保険料を支払う側だったのが、今は年金を受け取る側に変わりました。

コンピュータやプログラミングがどのようなものか全く知らなかった高校3年生の時に、情報工学科に進学すると決めて、九州工業大学情報工学科へ進学したのが1978年4月でした。それから、気がつけばもう46年が経ちました。もしあと4年、健康でソフトウェア開発を続けられれば、ちょうど半世紀になります。

何歳まで続けることができるか分かりませんが、これからもソフトウェア業界に対して微力ながら、貢献していければと思っています。

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


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

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

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

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

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リリースの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設計」で述べています。


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

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

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


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

その後、メルペイ内では、チームを移動していくつかのマイクロサービスの開発に従事したのですが、その多くが以下の状態でした（「第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を定義するという行為は、この程度でよいという認識のエンジニアによって作成される」からなのです。

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

（続き）

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


目次は次の通りです。

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