API仕様ファースト開発

「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」を執筆する際に考えた造語です。

全く新規にサービスを開発する場合の開発順序は次のようになります（記事の題3章の図1）。

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

これは、私自身が初めてメルペイで担当して、一からマイクロサービスを開発したときの開発順序です。そして、その後、チーム移動により別のマイクロサービスの開発へ移動したり、カウシェへ転職したりした際に、最初に導入したのはE2Eテストフレームワーク（記事の第4章「E2Eテストフレームワークの構築」）でした。

そして、API仕様の技術的負債（エンドポイントの仕様が書かれていなくて、それをテストするE2Eテストもない状態）を返済するために、次の開発順序（記事の第5章の図1）を自分自身も行い、他の開発者達にも行ってもらうようになりました。

図1 既存のエンドポイントの修正順序

新たなエンドポイントの追加の場合は、次の開発順序（記事の第5章の図2）となります。

図2 新たなエンドポイントの追加順序

この開発プロセスが定着すると、バックエンドサービスの既存のエンドポイントの修正や新規のエンドポイントの追加の際に、最初に行われるのは次のようになります。

1. 仕様の修正のPR（Pull Request）の作成（新規の場合、新規の仕様のPR）
2. 主にフロントエンド開発者による仕様PRのレビューとフィードバック（そして、承認）
3. バックエンド開発（E2Eテスト修正・作成およ実装）
4. バックエンド開発者によるテストコードと実装のPRのレビュー、フィードバック、承認

この開発プロセスが定着すると、次のようなことが利点として発生します。

• フロントエンド開発者は、バックエンドのAPI仕様がきちんと記述されていることを期待し、不明点や不足点は仕様に反映される。つまり、ミーティングで口頭で聞いたり、Slackで問い合わせただけの状態にならないようになります。
• バックエンド開発者も、たとえ自分で過去に担当して開発してエンドポイントであっても、その詳細を忘れることはよく発生します。その場合、実装を読み直すことなく、API仕様を確認できる。結果として、問い合わせがあった時に、実装を読み直す必要がなくなります。
• 新たにチームに加わったしたフロントエンドおよびバックエンドの開発者は、個々のエンドポイントの仕様を、他のバックエンド開発者に問い合わせることなく理解できます。

さらに、このような開発手順が定着して日々行われている開発組織に、同じ経験がない開発者が新たに加わった場合でも、次のようになるはずです。

• API仕様を記述しないで仕様のPRを出しても却下される。たとえば、gRPCであれば、.protoファイルにメッセージ定義しかなく、何も説明が書かれていなかったり、記述されていなかったりする。GraphQLでは、Mutationの新たなエンドポイントのtype定義はあるが、何も仕様が記述されていないとか。
• 実装のPRに、エンドポイントの仕様に基づくE2Eテストが書かれていない場合、却下される。

結果として、API仕様ファースト開発経験がない開発者が開発組織に加わっても、かなり早い段階で、API仕様ファースト開発を行うようになり、API仕様の技術的負債を積み上げることはなくなります。つまり、開発者の増加に対して、スケールアップする組織となっていきます。

逆の状況では、API仕様の記述がなく、API仕様に基づくE2Eテストがないまま開発していると、API仕様の技術的負債を積み上げていくだけです。そして、新たな開発者が加わっても、API仕様ファースト開発経験がない開発者なら、技術的負債を返済することなく積み上げるだけとなってしまいます。

WEB+DB PRESS Vol.134

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

E2Eテスト vs E2Eテスト

私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。

どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト／テスト駆動開発」からそのまま引用します。

この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。

一般的なE2Eテストとは

一般的な書籍では、テストピラミッドにおける頂点にあるE2E（End-To-End）テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境（たとえば、Docker、あるいは開発用のクラウド環境）にデプロイして「加盟店管理用APIマイクロサービス」をテストすることを指すものが多いです。

テストピラミッドの例

このテストピラミッドでは、「統合テスト」は、依存しているサービスへの呼び出し部分をモックで置き換えてサービス単体でテストすることを指すことが多いです。したがって、依存しているサービスへの呼び出しを、テスト時だけモックで置き換えられるような仕組みを埋め込む必要があります。つまり、本番環境で動作するコードの動作を確認しているわけではありません。

たとえば、実際に本番環境（もしくは開発用環境）で依存するサービスを呼び出したら、呼び出しコードに間違いがあり、モックとは異なる動作をしたり、正しく動作しなかったりする可能性があります。

そのため、統合テストの次の上の段階で行いたいのは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うことになります。

この時に、依存するサービスをどうするのかという問題に直面することになります。その結果、一般的な書籍で述べられている「E2Eテスト」ということになります。しかし、それは他の依存するサービスも動作させないといけないし、それらのサービスが動作するためのデータベースの設定が必要かもしれなく、設定が非常に面倒になります。

その結果、一般的な書籍では、E2Eテストは構築が難しいくテスト時間も要するので、単体テストや統合テストを強く勧めています。

私が定義しているE2Eテストとは

私がマイクロサービスの開発とテストファースト／テスト駆動開発」や「WEB+DB PRESS, Vol.134」の特集1「実践API設計」で述べているE2Eテストは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うのですが、以下の点が異なります。

• 本物の依存するサービスは使わない
• 開発者の開発PC（たとえば、MacBook Pro）上でローカルにテストが実行できる

Go言語で開発している場合、コンパイルも速いので、開発しているサービスだけを自分の開発PCで素早く開発・テストを行えます。どのように実現しているのかは、記事を参考にしてください。

必要に迫られて開発した方法

2018年6月にメルペイに入社して、本格的にウェブサービスのバックエンドサービスの開発に従事するようになって担当したのが、上の図にある「加盟店管理用APIマイクロサービス」です。

当時は、ほぼすべてのマイクロサービスが同時に開発されており、私が担当するマイクロサービスが依存するマイクロサービスも開発中という状態でした。それで考え出したE2Eテストです。

考え出した背景は、次の通りです。

• 自分が開発を担当するマイクロサービスの開発・テストが終わったと責任を持って言えるようにするにはどうすればよいか
• マイクロサービスが定義しているAPIの仕様に書かれている動作をすべて自動テストで確認してから、フロントエンドの担当者に、マイクロサービスの開発が終わっているので使ってくださいと言いたい

私が定義しているE2Eテスト用のテストフレームワークは、メルペイやカウシェで「E2Eテストフレームワーク」として整備されており、サービスの開発に用いられています。メルペイでは、一般的な書籍でのE2Eテストは、「シナリオテスト」と呼ばれていて、別途整備されていました。

2019年12月14日に開催されたGDG DevFest Tokyo 2019で最初の発表を行っています。

〓GDG DevFest Tokyo 2019 ご登壇者紹介〓
Main Sessionにて柴田 芳樹さんにご講演いただきます。『マイクロサービスの開発とテストファースト/テスト駆動開発』と題して、merpayのバックエンドエンジニアとしてどのような手順で開発し工夫をしているのかなど紹介いただきます。 #DevFest19 #gdgtokyo pic.twitter.com/IZG1rglNCT

— GDG Tokyo (@gdgtokyo) November 16, 2019

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

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」という制度を導入するまでに変わっていきました。

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

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

今日から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文が書かれる
• 一つの関数やメソッドが長くなっていき、その中のローカル変数のスコープが広くなって、実質的にグルーバル変数のようになってしまう。

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