アプリ開発のスピードと品質を両立させる「アプリケーション基盤」とは？
クロス・コミュニケーションにおいては、金融系のアプリ開発であれば国内随一の実績を持っており、アプリのフロントのみならず、バックエンドのシステム開発やデータ基盤の構築などアプリにまつわる幅広い領域をお手伝いしています。
それらのノウハウを蓄積した「アプリケーション基盤」を活用しスピーディーかつ高品質なアプリの提供がなぜ可能なのかをこの記事ではご紹介しております。
開発・制作・コンサルティングを無料でお見積もりをいたします。
目次
開発実績（ソリューションの規模）
GitLab
弊社ではGitLabを使用し、ソースコードの管理をしており、現在リポジトリ数でいうと850個程度あります。
主にスマートフォンアプリの開発を行っておりますので、1プロジェクトにつき、iOSアプリ・Androidアプリで各1個ずつ、ドキュメント用のリポジトリが1個で合計3個程度と考えると、300弱の案件のソースコードを抱えているような状態となっております。
Jenkins（CI環境）
CI環境としてjenkinsを導入しております。
こちらはJobという単位で自動化の仕組みがあるのですが、このJobがちょうどリポジトリ数と同じく850個程度あります。
この中で1日あたりの実行数が130回～150回程度です。
上記を基に規模感としてこれぐらいの案件のノウハウや実績がある状態とご理解いただければと思います。
アプリケーション基盤
アプリケーション基盤とは
アプリケーション基盤構築の背景といたしましては、複数アプリの開発を進めていくにあたり、同じような要件の開発が重なってきまして、 その中でもクレジットカードの明細アプリを作るということが何度かありました。
毎回ゼロから作っていると成功するプロジェクトもあればそうでないプロジェクトもあったりと、開発チームによりばらつきが幾分か見られるというリスクがありました。
そこで、これまでの開発実績を基にカード明細アプリのお手本となるような基盤を先に作っておこうと社内的に計画がされて、構築されたものがアプリケーション基盤です。
これまでのアプリ開発実績を基に「クレジットカードの利用明細」のドメインから抽出したベースとなる機能をアプリケーション基盤に集約し、実装しております。
実態といたしましては、iOSはSwift、AndroidはKotlinごとに作られたソースコード一式と実装サンプルです。
カード明細アプリとして求められるようなアプリケーション規模とUIの複雑さから良いであろうと考えている、MVP（iOS）、MVVM（Android）のアーキテクチャで構築されたものです。
ソースコードについては弊社に帰属する形です。
画面一覧
画面一覧としては以下の通りです。
| 画面名 | 画面内機能 |
|---|---|
| スプラッシュ | 起動スプラッシュ、強制バージョンアップ |
| 同意事項確認 | 利用規約・プライバシーポリシー、同意ボタン |
| カード登録（ログイン） | ID・パスワード認証、自動ログイン、外部ブラウザ起動リンク |
| ホーム | カード名表示、カード券面表示、お支払日付表示、お支払金額表示、ダイレクトログインリンク |
| ネイティブバルク | ネイティブ実装用白紙画面 |
| Webview | Webviewサンプル画面 |
| メニュー | 他のカードでログイン、アプリ内へのリンク、アプリ外へのリンク、アプリ情報 |
| セキュリティ | パスコードロックの設定、生体認証設定 |
| 利用規約 | ー |
| プライバシーポリシー | ー |
機能一覧
機能一覧としては以下の通りです。
| 機能名 | 内容 |
|---|---|
| ダイレクトログイン | アプリにログインしているアカウントでIDとパスワードの入力をすることなくログインされた対象のWeb画面を表示する |
| リトライ | 通信に失敗したときにリトライダイアログを表示させ、通信を再度行えるようにする |
| 家族カード | 家族カードで利用できる機能を制限する |
| セキュリティ | パスコード（パスコード設定をONにしている場合、アプリ起動時にパスコード解除ボタンを表示する）、指紋・顔認証（生体認証をONにしている場合（対応端末のみ）、アプリ起動時に生体認証を要求する。） |
| クラッシュレポート | Firebase Crashrytics |
| Push通知 | ブロードキャスト配信、アプリ起動まで |
| 独自スキーマ | アプリ起動まで |
| テストコード | ユニットテスト |
| スタブAPI | アプリ内スタブ |
パッケージ構成
このアプリケーション基盤を使って開発を進めていただくにあたり、以下がパッケージ構成です。
【iOS】
【Android】
これに加えて各クラスの説明や使い方は今用意されています。
アプリケーション基盤のメリット
-
アーキテクチャの統一が図れる
弊社では色々な外部パートナー会社と協力することが多いのですが、パートナー会社ごとに得意なもの、得意な作り方があります。
「同じような要件でもなんかこっちのアプリとこっちのアプリで作り方が違うし、品質も様々。」ということになりがちなのですが、これを使えばアーキテクチャの統一が図れます。
そしてレビューも大枠のロジックを把握した上で行えるため、ビジネスロジックだけ中心にレビューを行う等スムーズに進めることが可能です。 -
そのまま利用できる機能については、ほぼ実装工数がかからない
実装工数がかからないということは、スケジュールもコストも圧縮できるということなので、大きなポイントです。
-
機能要件についても、デフォルトとカスタマイズ部分で追加でかかる工数を考慮して交渉ができる
画面一覧、機能一覧で紹介したデフォルト部分とカスタマイズ部分で切り分けているので一つの案件を進める上では交渉材料になるかと考えています。
アプリケーション基盤のデメリット
-
使いこなすにはある程度のスキルが必要
ソースを読んでもらい理解出来れば便利なのですが、そこまで理解に深くない方ですと使用しにくいという点があります。
可能な限り弊社のテストまで済んだものを使用していただいた方が考え方の統一もできますし、バグがないという意味でもより良い品質として出来上がります。 -
レールから外れるほど、時間とコストがかかる
カスタマイズ機能が増えたり、レイヤーから大きく変えたり、データの持ち方が大きく変わってくるとそこは普通の開発と時間やコストは変わらなくなっていきます。
今後の展開
立ち位置
アプリケーション基盤を使って数社構築しておりますが、立ち位置としては機能にどれぐらい特化しているかというのと導入コストをマッピングすると以下のあたりです。
新規アプリ開発
要望に沿った機能で開発するので機能は100%特化しております。 ただ、その分の導入コストも高いです。
アプリプラットフォーム
割と汎用的なアプリパッケージみたいなものですとコストは安いのですが、機能も汎用的なものになります。 そこにはまるようなお客様の要望でしたらお得にアプリ開発ができます。
toB特化パッケージアップ
業界が絞られていれば機能も特化したアプリ開発ができます。
アプリケーション基盤
現在はカード明細向けの業界に特化している方法でして、完全にパッケージにしているものではなく、あくまでもこれをサンプル実装として使っていただき、新規アプリ開発よりコストとしては下げて、スピードとしては上げるようなイメージです。
拡大
アプリケーション基盤の今後の拡大としては以下のような未来を考えています。
-
カード明細アプリ基盤として、カード明細ドメインを取り組んでいく
前述で「リボ払い」など出てきましたが、もう少し共通になるという機能もいくつか見えてきていますので、そこを盛り込んで実装していくという動きがあります。
-
汎用的な基盤プロセスとして活用していく
アプリプラットフォームのような立ち位置に持って行くつもりはありませんが、アーキテクチャを統一するというプロセスは、図でいう左下の位置でも活かせるかと思っています。
-
他業界向けのアプリ基盤に道を開いていく
現在はカード明細のアプリ基盤を構築しており、実装するアプリはクレジットカード等金融業界のアプリが多いのですが、別の業界に特化したようなアプリ基盤をもう一つ構築するという道を検討しております。
まとめ
このように弊社ではカード明細アプリのお手本となるような「アプリケーション基盤」を構築しております。
これまでのノウハウを蓄積した「アプリケーション基盤」を活用し、スピーディーかつ高品質なアプリの提供ができるよう今後も機能追加や品質の安定化に取り組んでまいります。
品質向上のための取り組みにつきましては、
QCDの課題と品質向上の取り組みとは？
をご覧ください。
執筆者
