きちんとしたAPI仕様の作成能力

「API仕様を書く」でも述べていますが、振り返ってみると、ソフトウェアエンジニアとしては、プログラミングできることに加えて、書いているソフトウェアのAPI仕様をきちんと書く能力を身に付けることも重要です。

きちんとAPI仕様を書く際には、次の視点が求められます。

1. そのソフトウェアを使う人達が提供される機能を理解し、間違いなく正しく使えるかという視点
2. 将来保守する人達の理解を助けるという視点

1. は機能の説明だけでなく、防御的プログラミングの視点を盛り込んだ仕様が書かれている必要があります。2. は説明するまでもなく、将来保守する人達が仕様を理解できる必要があります。

仕様が書かれていない場合、作られたソフトウェアは技術的負債となります。そのようなソフトウェアの仕様を理解するには、実装のコードを読んで理解する必要があります。ライブラリやマイクロサービスのAPIであれば、不正なパラメータを伴う呼び出しがどのようなエラーを返してくるかを理解するために、実装のコードを読んで理解する必要があります。そして、時間をかけて理解したことは、実は間違っているかもしれまん。

実装を読んでコードを理解したとしても、しばらくすると忘れてしまい、再度コードを読む必要があるかもしれません。もっと悪いのは、仕様に書かれていないために、いつの間にか、返って来るエラーの種類が増えていたりすることもあります。

返済が非常に困難な技術的負債

技術的負債の中で返済するのが極端に難しいのが、「API仕様が全く書かれていないソフトウェアのAPI仕様を書くこと」です。これは技術的に難しいというのではなく、担当者の能力的に難しい部類の技術的負債です。

• API仕様をきちんと書く訓練を積んで来なかったため、そもそも技術的負債であると認識していない。
• 結果として、API仕様を書くモチベーションが担当者にないため、負債を返済するのは苦痛であり、本人の中では優先順位が低い。その結果、「時間が取れたら」と言い訳しても、本人の中では優先順位が低いため、決して「時間を取らない」という結果になる。
• 「技術的負債を返済したい」とエンジニアが言ったとしても、悪い設計の変更やひどいコードの修正だけが技術的負債の返済だと思っている人が多い。API仕様書は本人にとっては優先順位が低いことから、技術的負債の対象になっていなかったり、対象となっていても優先順位が低いため、結果として返済されることはない。

開発の最初からきちんとAPI仕様を書くことは、ソフトウェアエンジニアが身に付けるべき習慣であるべきです。最初に書いていれば、開発中に必要に応じて修正することは容易です。

2009年9月にリコーに転職して以来、さまざまなソフトウェア開発の現場でAPI仕様のレビューをしてきましたが、きちんとAPI仕様を書いている人達に会ったことはほとんどありません。

継続的な学習習慣

ソフトウェア技術は、発展し続けているため、非常に興味が尽きない領域です。そのために継続して学習を続ける必要があります。継続的な学習習慣の重要性については、何度も述べている（継続的学習）ので、ここでは別の視点で話をします。

本の買いすぎに注意

新たなソフトウェア技術に興味を持って学習する、あるいは今使っている技術を深く知るために学習するときに、私自身は書籍を購入することがほとんどでした。技術書の電子版を購入できるようになったのはいつ頃だったか思い出せませんが、2009年ぐらいまでは紙の本を購入していました。

紙の本、電子版のどちらであっても、新たな技術を学び続ける上での問題点は、本を買いすぎることです。読むつもりで技術書を購入するのですが、結局ほとんど読まなかった技術書の数の方が、読んだ技術書の数よりも圧倒的に多かったと言えます。つまり、読まない本に多くのお金をつぎ込んだことになります。

どうしても積ん読になってしまうのは避けられない側面がありますが、もう少し何とかならなかったかなと思っています。技術書によっては、購入したときに読まないと、数年後には内容が古くなってしまうものも多く、結果として読まないで処分してしまうことになります。

また、紙の本を持っておいくためには物理的な空間を必要とします。そのため、ときどき書斎にある書籍を処分することになります。若い頃は将来読むだろうと思ってとっておくことが多かったです。しかし、60歳を目の前に控えて、今は「本当に将来読むのか？」と考えて、読まない本は処分するようにしています。もちろん、もう一度読まないと分かっているが処分しない本もあります（たとえば、今では入手できない学生時代の技術書、自分の本、サイン本などなど）。

みなさんも、買いすぎには注意してください。

今はどうしているか

メルペイに入社してからは、とりあえず日々の開発のために手元に置いておきたい本は会社で購入してもらっています（その結果、退職時に持ち帰る必要もありません）。英語の技術書に関しては、Safariに会社で契約してくれており、多くの技術書を読むことができます。

コンピュータ・サイエンスの基礎

九州工業大学 情報工学科※でコンピュータ・サイエンスを学んだと言っても40年も前のことです。ハードウェアの基礎的な事柄、CPUの仕組み、コンパイラ、データ構造とアルゴリズムといったものを学びましたが、オペレーティングシステムについては何を学んだのかあまり記憶にありません。

※ 今日の九州工業大学には「工学部」（戸畑）や「情報工学部」（飯塚）などがありますが、当時は戸畑にしかキャンパスはなく、学部もありませんでした。当時の情報工学科に相当する学科は、現在の工学部にはありません。

日本では、大学でコンピュータ・サイエンスを学ぶことなく、プログラミング言語やウェブシステムの作り方を学んで、ソフトウェア業界に入ってくる人達が多いように感じます。その上で、何らかのシステムを開発する経験を積んだり、そのために必要な知識を学んだりするのでしょうが、コンピュータがどのように動作しているのかを全く知らない人達が多いのではないでしょうか。

たとえば、前職のソラミツ社では、面接（面談）で「macOSやWindows上ではさまざまアプリケーションが同時に多数動作しますが、マルチコアとは言え、CPUコアは数個しかないですよね。どうやって同時に多数のアプリケーションが動作しているのか説明してください」、「ハッシュテーブルを説明してください」、「スレッドとプロセスの違いを説明してください」、「O表記（O-notation）を説明してください」など聞いたりしていました。

このような質問に答えられなくても、ソフトウェア開発はできます。その結果、コンピュータ・サイエンスの基礎的な事柄を学ぶことなく、ソフトウェアの開発経験年数を積み上げることになります（「許される無知の範囲は開発経験年数に反比例する」）。

私自身は、すべての知識を大学で学んだ訳ではありません。社会人となってから学習したものも多いです。学習と言っても、独学というよりは勉強会という形式で行ってきたものが多いです。自分自身が学習するというよりも若い人達に学習してもらうという意味で過去に行った勉強会で使った書籍を紹介します。

ハードウェアに関する知識

この本は、トランジスターから始まって、前半はCPUの仕組みを学ぶ内容となっており、後半はC言語がどのようにコンパイルされて実行されるのかを解説しています。富士ゼロックス情報システムに勤務していたときに、新卒新人に強制的に勉強会を行った本で、読み終えるのに2年を要しました。日本語には翻訳されていません。今年、第3版が出版される予定です。

この本の勉強会は2年も要したので1回しか開催していないのですが、当時私が属する事業部（富士ゼロックス情報システム）に配属された新卒新人全員に、英語の本ですが必須で学習させました。



この2冊は、リコーに勤務していたときに、読書会として読んだ本です（「『コンピュータの構成と設計』勉強会終了しました」）

オペレーティングシステム

富士ゼロックス情報システムに勤務していたときに、月に1回土曜日に読書会を開催して読みました。読み終えるのに3年を要しました。


この本は、私自身は初版、第2版、第3版と読んだ本です。第2版は富士ゼロックス情報システムのとき、第3版はリコーのときに社内の読書会で読んでいます。日本語には翻訳されていません。

データ構造とアルゴリズム

この本は、第2章の「アルゴリズムとデータ構造」をきちんと学んでもらうために、強制的に新卒新人に学ばせた本です。基本的に私が作成した「勉強会ノート」に沿って、そこに書かれている説明ポイントに解答してもらい、その解答をレビューして、解答が不十分であれば差し戻ししたりして学習してもらいました（「書籍『プログラミング作法』」）。

富士ゼロックス情報システムに勤務していたときは、私の部門に配属された新卒新人は（派遣の新人も含めて）、必ず学習させていました。また、リコーに勤務していたときは、2年間でしたが、私が属している開発本部に配属された新卒新人は、学習が必須とされていました。

いつ学ぶべきか

コンピュータ・サイエンスの基礎的な事柄は陳腐化しないので、今日では、できるだけ若い時学んでおくべきだと思います。そうすれば、その後のソフトウェアエンジニアとしてキャリアを積んでいくための基盤になります。

新たなプログラミング言語への取り組み

ソフトウェア業界は停滞することなく、常に発展してきました。さまざな問題を解決するために、さまざまなプログラミング言語が登場してきましたし、これからも登場してくると思います。登場するすべてのプログラミング言語に取り組み、スラスラとその言語でコードを書けるようになるのは難しいと思います。したがって、私を含めて、多くのソフトウェアエンジニアは、書いたことがあるとしても、スラスラと書ける言語とそうではない言語に分かれると思います。

スラスラと書ける言語は、日々のソフトウェア開発で使ってきた結果として、指が自然と動くということです。そして、日々のソフトウェア開発で使うプログラミング言語は、バイブル本（「プログラミング言語のバイブル本と言語仕様」）を通してきちんと学ぶべきです（あるいは自己学習すべきです）。その理由としては、以下のことが挙げられます。

1. 毎日使っているプログラミング言語なので基礎知識があり、読むためのハードルが低い
2. 毎日使っているといっても、実際のソフトウェア開発では、そのプログラミング言語の機能をすべて使うことはない（「業務を通した学習の落とし穴」）。バイブル本の学習を通して、自分が使っていない機能を学習できる。
3. 毎日使っているプログラミング言語をバイブル本を通してきちんと学ぶことにより、他のプログラミング言語を学ぶ際に、きちんと学んだプログラミング言語との対比ができるようになる。

1. に関しては、説明する必要はないかと思いますが、基礎知識の量によっては、バイブル本の内容が難しかったり、あるいは知っていることだったりします。

2. に関しては、自分が知らない機能があることが多いです。たとえば、今日の多くのプログラミング言語にあるリフレクションですが、業務でリフレクションを使ったプログラミングをしたことがない人は、「リフレクション」という言葉やその機能を知らなかもしれません。『プログラミング言語Java第4版』や『プログラミング言語Go』などのバイブル本では、リフレクションにそれなりのページ数を割いて説明しています。逆に初心者本では扱われない機能です。

3. に関しては、一つのプログラミング言語をきちんと学ぶことで、他の言語の機能を理解する際に、すでに学んだ言語との対比ができることで、理解が容易になることがあります。

言語によって学習時間が異なる

バイブル本を学ぶといっても、言語によってはその学習に要する時間が変わってきます。Javaであれば、学習の最終目標が『Effective Java 第3版』の内容を全部理解することとすると、以下の書籍を全部読まないと理解できません。

• プログラミング言語Java第4版
• Java SE 8実践プログラミング
• Java SE 5.0 Standard Edition Tiger

これらの書籍の学習には練習問題にも真剣に取り組んで一年は要します（「Java研修」）。その意味で、初心者が『Effective Java 第3版』をいきなり読んで理解することはできません。

一方、『プログラミング言語Go』であれば、練習問題にも真剣に取り組んでも半年で終わります（「Go言語研修」）。ただし、130問以上ある練習問題の多くは、今日のウェブ技術（HTTP、JSON、Restful API、etc）をある程度知っていることが前提となっており、プログラミングの初心者には難しい内容となっています。

一度読んでも意外と覚えていない

新たなプログラミング言語を学ぶためにバイブル本を読んだとしても、一度読んだだけだと、その内容を意外と覚えていなかったり、あるいは忘れたりしています（ひょっとしたら私自身が歳をとったためなのかもしれませんが）。

たとえば、技術書を翻訳する場合、原著を読みながら日本語に訳していきます。そして、日本語訳を見直すために何度か読み直します。これだけでも、最低でも3、4回は読んでいることになります。さらに書籍によっては、翻訳前に原著の英語の草稿をレビューするために読んでいます。たとえば、『プログラミング言語Go』は、原著の英語の草稿をレビューするために2回読んで、気づいた点や誤りなどを著者達にフィードバックしています。これだけ読んでいても、社内で毎週月曜日に行っている読書会では、忘れていた内容を思い出すことがあります。

一度読んだ技術書をもう一度一人で読み直すのは難しいと思いますので、その場合には、社内（あるいは社外）で読書会を開催して読むとよいかと思います。

新たなプログラミング言語を学ぶときはバイブル本を読む

仕事で使うのではなく、趣味で使うのであれば、手っ取り早く初心者本やウェブの記事で新たなプログラミング言語を学んで試してみてもよいかと思います。しかし、仕事で使うプログラミング言語は、時間がかかっても、きちんとバイブル本を読むようにしてください。仕事で使う技術に関しては、きちんとした技術書で学ぶ習慣を身に付けないと、ソフトウェア開発を何年経験していても、中途半端なソフトウェアエンジニアになってしまいます。

1978年4月、大学一年生で初めてのプログラミングをFORTRANで学びました。それから、今月末で丸41年が過ぎたことになります。今と違って当時は、プログラミングは大学の計算機センターに行かなとできませんでした。当時の九州工業大学の計算機センターは、幸いパンチカードではなく、TSS（Time Sharing System）の端末を使ってプログラミングできました。でも、自分の学科（情報工学科）のさまざまなコースの演習は違っていました。

コンパイラの授業では、パンチカードを使ってPL/Iでプログラミングしました。パンチ室が3階で、計算機室が4階だったので、自分が書いたコンパイラのコードである7百枚ぐらいのパンチカード（つまり、700行のソースコード）を持って3階と4階を行ったり来たりして、デバッグして完成させました。

CPUの内部を学習する授業では、APLで動作が記述されている英語の教科書でした、その授業の最終課題は当時の情報処理技術者試験のアセンブリ言語をAPLで書けるようにする一種のDSLの作成でした。APLには130個以上の演算子があり、計算機センターのAPL端末で苦労しながら演算子を探して課題を仕上げました。

「コア」メモリの計算機を使った実験演習もありました。アセンブリ言語でプログラミングするのですが、プログラムは手書きで紙に書きます。そして、それを手作業で変換して（人間アセンブラー）16進数の機械語にして、手書きで紙に書きます。その紙に書かれた16進数の機械語をコアメモリの計算機のパネルスイッチを使って、2進数で1命令ずつ手作業で入力するものでした。

大学4年から大学院修士課程の2年生までは、HOLENETと呼んでいたローカルネットワークシステムをハードウェアの作成から通信プロトコルの作成までを行い、8ビットCPUである、Z-80のアセンブリ言語でプログラミングしていました。

41年の間、さまざまなソフトウェア開発に従事し、一人のソフトウェアエンジニアという立場だけではなく、開発のマネージャや開発部門の部門長などを経験してきました。そして、今は、一人のソフトウェアエンジニアとしてソフトウェア開発に従事して、Go言語で毎日開発しています。昨年6月にメルペイ社へ入社以来、開発に従事してきたあるマイクロサービスも本番運用され始めます。私にとっては、人生で初めてのウェブサービスです。

この41年間を振り返ってみると、特定の技術知識とは別に、以下のことが重要だと思います。

• 新たなプログラミング言語への取り組み
• コンピュータ・サイエンスの基礎
• 継続的な学習習慣
• きちんとしたAPI仕様の作成能力
• よみやすいコードを書く能力
• テスト駆動開発の実践
• テスト設計能力
• 若手人材を育成していく能力
• 教育を行う能力
• 文書作成能力
• 英語能力

そして、今日技術的知識として知っておく必要があるのは、以下のものであり、現在の私に不足している部分です。

• ウェブ関連の技術
• DB/SQL関連の技術

過去の私のブログの内容や拙著『プログラマー”まだまだ”現役続行』と内容が重なる部分はあるかと思いますが、上記の項目について、振り返ってみて思うことを、これから書いていこうと思います。

この本は、ソフトウェアの複雑さ（complexity）を減らすために、ソフトウェアエンジニアが日々の開発で注意を払うべきことが述べられています。その多くのは、さまざまな書籍で述べられている基本的な事柄です。しかし、それらの基本的な事柄は、習得するのが容易ではないものが多いです。

たとえば、『リーダブルコード』を読むだけで読みやすいコードが書けるようになるのではなかったり、『Effective Java』を読むだけできちんとしたAPI設計ができるようにならなかったりするのと同じです。読んで学んだことを意識して実践し、当たり前となるまで繰り返していく必要があります。

この本を読んで、その内容を実践してみようと思うのか、もう当たり前に行っていることだと思うかは、読み手の経験によって変わってくると思います。この本の中で、私自身は意識して実践しているが、多くのソフトウェアエンジニアができていないと思うことが「Chapter 15 Write The Comments First」です。副題として、「Use Comments As Part Of The Design Process」と書かれています。その導入部分には、次のように書かれています。

Many developers put off writing documentation until the end of the development process, after coding and unit testing are complete. This is one of the surest ways to produce poor quality documentation. The best time to write comments is at the beginning of the process, as you write the code. Writing the comments first makes documentation part of the design process. Not only does this produce better documentation, but it also produces better designs and it makes the process of writing document more enjoyable.

Chapter 15, “Write the Comments First”
John Ousterhout, “A Philosophy of Software Design”

「API仕様を書く」でも書いていますが、最初に仕様を書くことは、それが当たり前になるまで意識して自分で自分自身を訓練するか、指導してもらうかのどちらかでない限り、身に付かない習慣だと思います。

私が知る限り、残念ながら、この本は日本語へは翻訳されないようです。

技術書に掲載されているサンプルコードを読んだり、オープンソースのソースコードを読んだりしているときに、「あれ、このような書き方ができるのかな？」と疑問に思える書き方を目にすることがあると思います。そのような場合、そのプログラミング言語のいわゆるバイブル本か、公式の言語仕様を調べて、書き方が許されることを確認する必要があります。

言語仕様は分かりにくいために、最初はバイブル本を調べます。Go言語の場合、『プログラミング言語Go』です。そこにも記載が見当たらない場合には、言語仕様「The Go Programming Language Specification」を調べることになります。この書き方はメモリモデル※に関して問題はないのかなと疑問に思った場合、メモリモデルに関しても、『プログラミング言語Go』にある程度書いてありますが、詳細は「The Go Memory Model」に書かれていますので参照することになります。

※　メモリモデルは、言語仕様の一部と考えるべきです。Java言語の場合、公式の『The Java Language Specification』の「17.4 Memory Model」に記述されています。

今日では、あるプログラミング言語を学ぶために、どの本がその言語のバイブル本であるかを調べて、バイブル本から学習を始める人が少なくなっているような気がします。その結果、手元にバイブル本はなく、もっぱらネット検索で得た知識だけでプログラミングしている人が増えているのではないでしょうか。

結果として、ある書き方ができるか否かを調べるのはもっぱらネット検索だけであり、英語が読めなければ、日本語になっていない言語仕様を調べることはないでしょう。あるいは、ネットの情報だけに頼ってしまい言語仕様やメモリモデルを間違って解釈してしまうかもしれません。

一般にバイブル本には最低限これだけは知っていて欲しいことが書かれていますが、すべての言語仕様が網羅されるわけではありません。したがって、バイブル本は読んでおいて、必要なときに言語仕様（やメモリモデル）を調べる習慣を身に付けることは遠回りのようですが、優秀なソフトウェアエンジニアになるための近道だと思います。

私自身は、backendのサービスを開発し、それが実際にデプロイされるのを経験するのはメルペイでの開発が初めてです。監視というのは以前には経験していないため、本書を読みました。

原著は、『Practical Monitoring』ですが、日本語版ではタイトルが『入門 監視』となっています。残念ながら、監視の経験不足からくるのだと思うのですが、本書の後半は、内容がピンとこない項目が多かったです。

細かな詳細は省きますが、以下の章から構成されています。

• 1 章　監視のアンチパターン
• 2 章　監視のデザインパターン
• 3 章　アラート、オンコール、インシデント管理
• 4 章　統計入門
• 5 章　ビジネスを監視する
• 6 章　フロントエンド監視
• 7 章　アプリケーション監視
• 8 章　サーバ監視
• 9 章　ネットワーク監視
• 10 章　セキュリティ監視
• 11 章　監視アセスメントの実行
• 付録A　手順書の例：Demo App
• 付録B　可用性表
• 付録C　実践 監視SaaS

「1 章　監視のアンチパターン」と「2 章　監視のデザインパターン」は、監視をする上で基本的に認識しておくべきことが書かれています。

残りの章は、全体的に個々の項目を深掘りしているというよりも浅く広く必要なことを述べているのですが、私自身は経験がないためかピンとこないものが多かったです。私のような全くの初心者は、監視の経験と知識がある人と一緒に読みながら、補足や解説をしてもらいながら読むと理解が深まるのではないかと思います。

前回の「メルペイで5か月が過ぎました」から4か月が過ぎました。10か月目に入ったわけですが、メルペイを含めた7社の中では5番目に長い勤務期間となります。

この4か月は、backendエンジニアとして、あるマイクロサービスの開発を担当しているので、そのAPI仕様の作成、テストコードの作成、機能実装、不具合の再現テストと修正（「不具合が発生した場合、必ず再現テストを書く」）、あるいは、API仕様の変更とそれに伴うテストコードや機能実装の修正といったソフトウェア開発を行っています。

2月に非接触決済サービス「iD」に対応したiOS/Androidアプリケーションがリリースされ、私も会社支給のiPhoneでスマホ決済を行っています（個人としては、今もガラケー）。今月には、「コード決済」のリリースが予定されています。このようなサービスの立ち上げ前から開発に関われたのは、幸運だったと思います。

振り返ってみると、1984年から社会人となって、これまでに関わった商品開発の多くで（日の目を見なかったプロジェクトも含めて）、それらの開発プロジェクトの当初から参加していることが多かったです。

メルペイでのサービス開発は今後も続きますが、今年は「プログラマーとして現役を続行」できそうです。

昨年の6月に入社した時の社員数は分かりませんが、それ以来、毎月社員が増えています。そして今も、さまざまなエンジニアリング領域で人材を募集しています。