アプリ開発でAPIを使うときの「あるある」を解決したい
ゆめみは2000年に「アイデアと技術をもって『夢』を実現し、社会に貢献できる新しいものを創りだすことを目標」に、モバイルソリューション事業を提供するため設立されたモバイルインターネットの老舗ベンチャーである。現在はBnB2C（BandBtoC）という法人向けのデジタルメディア・Webサービス・公式アプリの立ち上げと成長に関連した支援事業を行っている。具体的にはスマートフォン向けアプリやWebサービス、デジタルメディアの企画・開発・運用、およびUI/UX設計などを手がけている。
今回、登壇した岡山達哉氏は、2019年11月にゆめみに入社し、Androidアプリの開発に従事しているエンジニアである。趣味は将棋とのことだが、個人でも、ほぼ毎日2時間ほど「Flutterを使っている開発している」と話すほど、開発が大好きなエンジニアだ。
そんな岡山さんのキャリアは非常にユニーク。元々は公務員からスタートしており、「プログラムは趣味で書いていました」と明かす。公務員として働いているうちに、「エンジニアのほうが向いている」と思い、公務員を辞めて3カ月間勉強し、地元の小さな開発会社に入ったという。「入社当初は7人しかいなかったので、開発だけではなくいろんな経験を積むことができました」と岡山さん。Twitterを活用した転職活動をしたところ、ゆめみの片岡代表からDMをもらい、ゆめみへの転職が実現したという。
岡山さんのセッションタイトルは「OpenAPI GeneratorによるAPI Clientコードの完全自動生成」。API Clientの自動生成に取り組んだきっかけは、開発者あるある話である。
アプリ開発でAPIを使うときに、「いつの間にか仕様が変わっている」「仕様が変わったのはわかったが、どこが変更になったのかがわからない」「そもそも開発した人に聞いても、どこを変更したのか把握していない」という経験をした人は多いだろう。このようなことがあると、ついついAPIを開発した人を責めるような思いにとらわれてしまうこともある。
たしかに「仕様変更したときはちゃんと言ってほしい」「どこを変更したかきちんと教えてほしい」と言うのは正論かもしれない。しかし、人のすることは完璧ではない。岡山さんは「人間はミスをする生き物なので、それを前提で作業のフローを組んだほうが良いと考えた」と言う。
何か仕様変更をしたら、変更箇所をまとめて報告をするフローを作って、複数人でチェックするという、運用でカバーする方法がある。「だがこの方法を採用しても必ずしもミスがなくなるわけではありません。個人的にはやりたくないと思いました」と岡山さん。そもそもAPIの変更があったときに、アプリ開発側が修正するというのは気乗りしないし、面倒である。そこで「こういうときこそ、自動化だ」と考えたという。
まずAPI変更の流れの整理に着手した。図を見ればわかるように、API変更の流れは「サーバー側の修正」→「修正箇所の連絡」→「クライアント側の修正」となる。「ここで自動化したいのは、修正箇所の連絡とクライアント側の修正の部分。サーバー側の修正は人間しかできないので、ここはそのままにしました」（岡山さん）
