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

「伸ばすのが難しい能力（２）」の状況から、技術負債を返却して、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を定義するという行為は、この程度でよいという認識のエンジニアによって作成される」からなのです。

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

（続き）