アプリ開発で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変更の流れは「サーバー側の修正」→「修正箇所の連絡」→「クライアント側の修正」となる。「ここで自動化したいのは、修正箇所の連絡とクライアント側の修正の部分。サーバー側の修正は人間しかできないので、ここはそのままにしました」（岡山さん）
「当たり前」の自動化に挑戦して見えたこと
次に取り組んだのは、「自動化の手法の検討」である。修正箇所の連絡の自動化については、「GitHub Actionsというサービスを利用すると自動化できることがわかりました」と岡山さん。GitHub Actionsはさまざまなワークフローを自動化できるサービスである。
一方で、クライアント側の修正の自動化をするために目星をつけたのが「OpenAPI Generator」である。OpenAPI Generatorはクライアントやサーバーのコードを、OpenAPIドキュメントから生成するツールである。「触ってみると、非常に便利なことがわかりました」と岡山さんは振り返る。今回は試さなかったが、OpenAPI Generatorを使うと、APIサーバー側のソースコードも生成できるという。
自動化のフローは次のようになる。前提としてAPIの仕様書とソースコードをGitHubで管理する。その上でOpenAPIドキュメント形式のOpenAPIの仕様書を更新し、GitHub Actionsを使って、APIの更新通知を受信する。その後、API仕様書を読み取り、APIクライアントコードを生成する。コードの生成が終わったら、APIクライアントのGitリポジトリに対して、プルリクエストを作成する。
このフローで実際に試したところ、期待通り、サーバー側の修正を行うと、自動でクライアント側のリポジトリにプルリクエストが作成されたという。
実際のプロジェクトに導入していこうと考えたが、「課題は山積みだった」と岡山さん。課題の第一は、API仕様書がGit管理されていない場合があるということ。第二にGitHub Actionsの権限を持っていない場合があるということ。「お客さまのセキュリティの都合上、どうしてもこちらに権限を譲渡できないことがあります」（岡山さん）
第三がOpenAPI Generatorには未対応な部分があること。「最近、AndroidアプリをRetrofitとCoroutine、Kotlinx Serializationの組み合わせで開発するのですが、現状はこの組み合わせでAPI Clientコードを自動生成できないという問題があります」（岡山さん）
現在、プルリクエストが出されているので、次のバージョンからは自動生成ができるようになるのではと期待しているというが、新しいライブラリを使うときは、OpenAPI Generator側が対応するまで待つか、自分で対応するかという二択になってしまうという。
このように課題はあるが、これからも「できるだけ自動化に取り組んでいく」と岡山さんは力強く語る。
もちろん、自動化する上では、「大変だったこともたくさんあった」と言う。その取り組みの中で最も大切だと感じたことは、「前提を疑うこと」と岡山さんは言う。例えば今回の自動化に取り組んだのも、元々は「APIを変更したことと、その箇所をきちんと報告する」という、当たり前の流れで実行してほしいと思ったことがきっかけである。そして、さらにその当たり前の流れを、「本当にそれで良いのか」と疑ったからこそ、課題を発見し、考えて行動して自動化することにつながった。「もし前提を疑うことなく改善しようとしていたら、作業フローを見直して、新たな作業フローのドキュメントを作るという運用でカバーする残念な選択になっていたと思う」と吐露する。
実はこの前提を疑うということは、ゆめみ社内のOJTチャンネルガイドラインにも記載されていることである。つまりゆめみ社員は普段から、「物事の前提を疑って考える」という姿勢が身に付いているのだ。岡山さんは最後にこう参加者に呼びかけ、セッションを締めた。
「みなさんもぜひ、前提を疑うことを心がけて仕事をしてみてはいかがでしょうか」
お問い合わせ
株式会社ゆめみ
