メッセージ管理の方針
Status: Accepted
要約
メッセージ管理に関する方針は以下とします。
- モバイルアプリの利用者の目に触れるメッセージは、一意なキーと文言や文章で管理する
- 開発しやすいようIDE補完が働くようなキーを定義する
- 可読性が高まるよう日本語をキーとして良い
コンテキスト
モバイルアプリのメッセージはバックエンドと違い、操作ガイダンスやエラーの文言などが利用者に直接表示されることが前提になっています。 これらは開発側の事情よりも、顧客や利用者の意図によって変わりやすいため、集中管理が必要となる場合もあります。
集中管理することでハードコーディングの防止や同一文言の集約、文体や体裁の統一などが簡単になり、メンテナンス性が高まります。
また、サーバでメッセージを管理しておき、アプリでロードして表示するような方式であれば文言の変更によるアプリの更新が不要となります。 管理が必要となる他の理由に、多言語対応もあります。
ただし、上であげた理由よりも、管理の効果が低い小規模開発の場合や短期間での開発の速度を求められる場合は、メッセージ管理をしないという選択もあります。
議論
なぜ管理が必要になるのか
モバイルアプリのメッセージは、ユーザの目に触れやすくUI/UXの観点からも変わりやすいものです。 コードのメンテナンス性や文言の一意性から、集中管理が必要になります。 メッセージ一覧は、UI/UX責任者と合意しやすいよう抽出できるとなお良いでしょう。
管理するメッセージの候補
管理しなければならないメッセージの候補には以下のようなものがあります。
| メッセージ候補 | 例 |
|---|---|
| 画面のラベル | UI部品（ログイン画面）のラベル（アカウント、パスワード）など |
| 画面で表示するメッセージ | 確認ダイアログ、操作ガイダンス、トーストでの通知など |
| OSで出す許可ダイアログのメッセージ | カメラやマイクの許可など |
| エラーメッセージ | エラー発生時に表示するメッセージダイアログ、スナックバーなど |
| プッシュ通知（リモート） | サーバからのプッシュ通知メッセージ |
| プッシュ通知（ローカル） | アプリからのプッシュ通知メッセージ |
| APIのレスポンス内の文言 | レスポンスに含まれる文言（例えば、サーバメンテナンス中の表示メッセージ、残金不足エラーの金額表示など） |
| ログに出すメッセージ | モバイルアプリ内のログメッセージ |
この方式で管理するメッセージ
| メッセージ候補 | 管理する・しない |
|---|---|
| 画面のラベル | する |
| 画面で表示するメッセージ | する |
| OSで出す許可ダイアログのメッセージ | しない（※1） |
| エラーメッセージ | する |
| プッシュ通知（リモート） | しない（※1） |
| プッシュ通知（ローカル） | する |
| APIのレスポンス内の文言 | ケースバイケース（※2） |
| ログに出すメッセージ | しない（※3） |
（※1）カメラやマイク許可などのOS側の組み込みメッセージと、サーバからのプッシュ通知を表示するリモート通知はJavaScript外で設定されるため含めない。 （※2）APIレスポンスに含まれている文言は、例えば、サーバメンテナンスなどはそのまま表示すれば良い。 一方、残金不足で金額がバックエンドしか分からないような値を表示するときは、 レスポンス内の金額を加工する場合もあれば、バックエンドのメッセージをそのまま表示する場合もあると考えケースバイケースとした。 （※3）ログメッセージは通常ユーザの目に触れないことと文言が頻繁に変わることから、開発効率を考えて管理対象外としている。
管理する場所
メッセージを管理する場所として、大きく以下2つが候補として挙がりました。
- アプリ内（バンドルされたファイルなどから取得）
- サーバ（APIなどから取得）
メッセージをアプリ内にバンドルした場合は、メッセージを更新するために都度アプリをApp StoreやGoogle Playにリリースする必要があります。
その反面、メッセージをサーバで管理した場合は、アプリの起動時にAPIから全てのメッセージを取得することで、アプリをリリースしなくても常に最新のメッセージが利用できます。
新たにメッセージを追加した場合は、追加されたメッセージを利用するようにプログラムを修正する必要があります。その場合はアプリをApp StoreやGoogle Playにリリースする必要があります。
アプリの運用を考えると、「メッセージをサーバで管理した方が良いのではないか」という意見が挙がりましたが、それらに費やすコストなども鑑みた結果、アプリ内にメッセージをバンドルする方針としました。
開発のしやすさ
キーを元にメッセージを取得しますが、日本人開発者が多く日本語しか使わない場合は、 英語ではなく日本語をキーとした方が画面コンポーネントやエラーなどで可読性が高まります。 他の要素として、IDEでキーが補完されると良いでしょう。
国際化対応や多言語対応
OSSのライブラリで、国際化対応できる react-i18next のようなライブラリも存在しますが 自作する場合の機能の容易さと外部ライブラリのモジュール管理の煩雑さを考慮して採用はしていません。 ただしインターフェースに対する実装を切り替えることでアダプター的に利用することは可能と考えます。
決定
モバイルアプリのメッセージは、利用者の目に触れるものは可能な限り管理下に含み、集約化を行います。 外部の多言語化のOSSライブラリは使用せず開発するものとします。しかしインターフェースの切り替えで利用できるよう考慮します。 サーバからメッセージ一覧を取得する方式は採用せず、用途として一番多い想定のモバイルアプリ内でメッセージ一覧を管理する方式で実装することとします。 メッセージ管理コンポーネントは、IDEの補完が効くようなキーを定義しておき開発効率を良くします。 日本語のみでの開発では、日本語をキーにすることで可読性が高まります。