OJTを通じたアプリ開発中に工夫してうまくいったことと、失敗したことについて

2025-04-03Android, OJT, アプリ開発, 新卒1年目

はじめに

こんにちは、株式会社レコチョク新卒1年目の本多啓路と申します。
現在はプロダクト開発第1グループに所属しており、Androidアプリの開発に携わっています。

本記事は、我那覇さんのOJTを通じたアプリ開発の取り組みの続きの記事になります。
アプリ開発中に工夫してうまくいったことと、失敗したことについて紹介していきます。

工夫してうまくいったこと

まずは開発中に工夫したことについて紹介していきます。

・GitHub Projectsの使用

アプリ開発についての進捗や自分の担当しているタスクを管理するために、今回はGitHub Projectsを使用しました。
GitHub Projectsは、GitHub上でプロジェクト管理を行うための機能になります。
ソフトウェア開発のプロジェクト管理やタスク管理を支援するために提供されており、以下のような特徴を持っています。

カンバンスタイルのボードを利用して、タスクを視覚的に管理できます。
GitHubのIssueとPull Requestを直接プロジェクトにリンクでき、それらをタスクとして扱うことができます。

この特徴を利用しつつ、毎週ミーティングを行うことで効率的に進捗確認や1週間ごとに行うタスクの割り振りを行うことができたと考えています。

・mermaid.jsを使用したダイアグラムの作成

アプリ作成には要件(詳しくは我那覇さんの記事を参照)があり、その中の一つにシーケンス図とクラス図の作成がありました。
今回は、これらのダイアグラムの作成にmermaid.jsを使用しました。

mermaid.jsはMarkdownで記載でき、テキストからダイアグラムを生成するためのJavaScriptライブラリになります。

実際の開発期間は2ヶ月ですが業務との兼ね合いもあり、最初から機能をあれこれ詰め込んでしまうと期限中にアプリが完成しないケースがあると考えました。
このケースを避けるため、開発の方針として必要最小限の価値を提供できる状態を作成したのち、アップデートしていくMVP(Minimum Viable Product)の観点を意識しました。

テキストの変更のみでダイアグラムのアップデートが行えるmermaid.jsはMVPの観点と相性が良く、結果として更新の手間を削減することができました！

初期段階のクラス図	最終的に完成したクラス図

最初に作成したクラス図ではViewModelとModelの要素を主に記載していました。
しかし、MVVMの観点からViewもクラス図に載せた方がアプリの設計図としてはベターだと考え、最終的にはView要素も追加しています。
またダークモードの切り替え設定のViewModelや、質問の要素を新たに追加しています。

初期段階のシーケンス図	最終的に完成したシーケンス図

最初は検索結果のページ送りの機能を加味していませんでしたが、あった方が操作性が良くなると考えページ送りのシーケンスを追加しています。

開発のフェーズごとにクラス図とシーケンス図を最新のものにできたため、これらを基準として手戻りの少ないチーム開発ができたと感じています！

また、クラス図やシーケンス図以外にもmermaid.jsは使用しました。

Issuesに参考資料としてフローチャートを記載

GitHubのWikiや、Issues、PRにもmermaid.jsを使用することが出来るため、チーム内での共通認識を持つ手助けにもなったと感じています！

開発中に失敗したこと

次に開発中に失敗したと思うことについて紹介できればと思います。
特に失敗したな、と感じたことの要因はAPIの仕様書を全て確認していなかったことによるものが大きいです。

この仕様書の確認不足により生じた失敗を2点ピックアップしてご紹介します。

・APIが想定通り動かない

ホットペッパーグルメの無料APIのうちグルメサーチAPIというものを今回使用させていただきました。
こちらはパラメータにお店ジャンルコードやエリアコードなどを入力することでヒットしたお店をレスポンスで返してくれるものとなります。

今考えれば見切り発車だったと思うのですが、実際のホットペッパーグルメさんのサイトにて検索を行い想定通りの結果を出力していそうだというところまでしか確認せずに開発に入りました。

案の定ですが実際に実装してAPIを叩いてみると思うようなレスポンスが返ってくることはありませんでした。
例えば、エリアコードのパラメータに表参道であったり、ジャンルに和食と入力して検索しても返ってくるレスポンスは検索結果0ヒットのレスポンスとなっていました。

お店ジャンルコードの説明文には、

お店のジャンル(サブジャンル含む)で絞込むことができます。
指定できるコードについてはジャンルマスタAPI参照

と書かれてあり、ジャンルマスタAPIでのレスポンスを見てみると

genre

|_ code //ジャンルコード ex)G002

|_ name //ジャンル名 ex)ダイニングバー

となっており、その当時はnameでもいけそうだと決めつけていました。

しかし、実際に見るべきはリクエストの方であり、ジャンルコードは G002といったような文字列で完全一致でなければならないということを仕様書を改めて読み込むことで発見しました。

ジャンルコードで検索(完全一致)します。（２個まで指定可、3個以上指定すると3個目以降無視します）

主な原因はAPIの仕様書をしっかり確認していなかったことにありますが、原因を明らかにするために進捗が遅れてしまうこととなりました。

・検索結果の最大出力数が少ないことを仕様だと思い込んでいた

これはパラメーターを全て確認しなかったことに起因していると思います。
検索結果を表示する際に、検索結果が100件あっても、検索結果の詳細が最大10件までしかレスポンスで取得できていませんでした。
これを「無料のAPIだし、10件までしか取得できない仕様なんだろうなぁ〜」と思ってしまい、その当時は仕様書を見直すことはしませんでした。

そして、開発を終了する1週間前のタイミングでアプリを先輩方に触ってもらいフィードバックをいただく動作確認会を設け、ここでのフィードバックをもとに改めて仕様書を確認しました。
ここで判明したのがデフォルトが10件になっているだけであり、データ件数や何件目から表示するなどをパラメータで調節することができるということです。

パラメータ	項目名	説明	値
start	検索の開始位置	検索結果の何件目から出力するかを指定します。	初期値1
count	1ページあたりの取得数	検索結果の最大出力データ数を指定します。	初期値10、最小1、最大100