モバイル の記事一覧

今回、社内向けのアプリケーションを開発するにあたり、上流工程を担当する機会がありました。せっかくなので「試せるところはすべてAIに任せる」といった方針でAIを使ってみました。実務メモとして、使用したプロンプト例と運用のコツを公開します。使用モデルはChatGPT（GPT-5）です。 背景 社内の顧客管理系スタッフツールを新規開発することになりました。スケジュールが厳しめだったこともあり、上流工程に割ける時間が限られている状況でした。「じゃあAIで上流を効率化しよう」と腹をくくり、試行錯誤しながらプロジェクトを進めました。 先に結論（うまくいったこと/難しかったこと） うまくいったこと 画面UIや構成図をSVGで出力し、編集可能なたたき台を高速で作成できたそのSVGを足がかりに、詳細設計のたたきや単体テストケースの初版まで作れたDB設計後の定型チェックを一気に回せた（表記揺れ、型の整合、ルール違反の洗い出し） 難しかったこと スケジュール作成は挫折（プロンプト設計の詰めが甘く、期待通りにならず）DB定義書のゼロから生成は非効率だった（要件伝達のコストが高く、自作の方が速い） 画面UIの叩き台をAIに任せてみた 関係者の合意形成と、開発メンバーとの同期のために画面UIのイメージが必要でした。前提として、今回は社内向けの小規模案件だったため、UIツールで作り込むよりも、納期遵守とスピード優先で「まず形を出す」ことに振り、GPTに依頼してみました。 プロンプト例 一般的な顧客管理用のスタッフツールの画面UIをSVGで生成してください。 構成要素： ・顧客情報、申請情報、お問い合わせ情報が管理されるアプリ ・サイドメニューとメイン画面の構成 ・メイン画面には顧客情報管理画面を表示 ユースケース： 1. 検索条件入力 → 検索実行 → 一覧表示 2. 行クリック → 詳細表示/編集 3. CSVダウンロード、メール送信 ルール： ・すべて日本語ラベル 出力：ダウンロード出来る形でSVGファイルを返すこと。 結果（生成されたSVGファイル） あっという間にこのクオリティの画像が生成されました。UIデザインのスキルがない自分にはこれは参考になります。ありがたい。２度３度と出力させてみても、色々な結果が出てきて勉強にもなります。 そして、このSVGファイルをPowerPointで、挿入＞画像から読み込みます。その後、グループ化解除を選択すると各要素を編集可能となります↓ 必要な要素の追加、不要な要素の削除、微調整などを行って、さくっと画面UIのイメージを作成できました。 実務メモ このフローはアプリケーション構成図にも流用できました。「まず1枚作ってから考える」用途なら、画面遷移図やデータフロー図などにも横展開できそう。実務では、作った画面イメージをGPTに読み込ませて、詳細設計のたたきや単体テストケースの初版まで発展させて生成させました。 DBテーブル定義書の一次レビューを任せてみた 次はDBテーブル定義書です。まずは、ゼロから定義書を作ってもらうのを試しましたが、要件を伝えるのに時間がかかってしまい、効率が悪かったため挫折しました。さらに要件伝達が甘いと、雰囲気のあるものは出るものの、結局全量精査が必要で自分で作った方が速いという結論です。一方で、完成済み定義書の機械チェックは強力でした。今回はExcelで作成した定義書を対象に、下記2工程でのチェックを行いました。(1)同名カラムの型・桁・NOT NULLや命名の揺れを横断比較(2)命名規則・型統一などのルール準拠を点検。 (1)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルを横断的に比較し、同じカラム名でデータ型・桁数・NOT NULL条件が異なる箇所や、命名の表記揺れがある箇所を洗い出してください。 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (1)の結果 （実際の出力のため、テーブル名をマスキングしています）1つ目のチェック。初期のばらつきを一括で潰し、後工程の手戻りを防ぎます。 (2)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルが下記ルールに沿って定義されているかを確認し、違反している箇所を洗い出してください。 ルール： ・命名規則は小文字＋snake_caseで統一。略語やスペルミスも指摘してください ・主キーは数値のサロゲートキーであること。型はNUMBER(28,0)であること ・時刻型はDATEに統一 ・フラグの型はNUMBER(1)で制約はCHECK (col IN (0,1))、NOT NULL、DEFAULT 0であること 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (2)の結果 2つ目のチェック。ルール違反を網羅的に拾ってもらいました。 この2工程で、見落としがちなばらつきを短時間で洗い出せました。 実務メモ 機械的チェックはAI、要件に適合しているかの最終チェックは人の役割として切り分けてレビューしました。定義書の丸投げは難易度が高かったです。ただし「一般的な会員テーブルに必要なカラム列挙」など部分タスクの支援は有効でした。定義書のフォーマットを固定しておけば、同プロンプトで同品質の機械チェックを繰り返し適用できます。 最後のまとめ 「試せるところは全部AI」に振り切ったことの学びとしては、うまく回せば上流工程でAIが生きる場面は多いなと気づけました。上流では、曖昧な要求を形にしていく場面が多いですよね。そこをAIに投げてみると、自分では出せなかったパターンや視点を提案してくれてかなり助けられました。（記事では割愛していますが、細かいタスクもいろいろお願いしています。通信フローの表をまとめてもらったり、ログ出力仕様を一緒に詰めたり、作成したテストの観点漏れを指摘してもらったり。）ただ、結局のところ現場や人によって最適解は違うと思います。今回は社内向けで図の品質基準もゆるめという前提だったので、「AIのたたき台→人の手直し」はハマったなと思っています。一方で、複雑な前提や厳密さが求められる成果物（DB設計や仕様設計など）は、最初から人が手を動かした方が効率的な場面もあると感じました。まずは何でも試して、広げていくのがいいんじゃないかなと。もしどこか一つでも持ち帰ってもらえるポイントがあれば嬉しいです。

この記事は GMOインターネットグループ Advent Calendar 2024 12日目の記事です。こんにちは、GMOペパボでシニアエンジニアを務めている酒井です。私は現在、minneの開発を担当しているモバイルアプリエンジニアとして活動しています。今回は、11月14日に開催された「Spectrum Tokyo Meetup #15」での登壇内容を振り返り、改めてまとめました。この時のテーマは「デザインエンジニアリングにまつわるお話」でした。そこで使用した登壇資料にいくつかの補足を加えて、皆様にポイントをご紹介していきます。 登壇のきっかけ 私が今回の登壇を決意したきっかけは、これまでの経験にありました。過去にデザイナーとしての経験があり、その後はモバイルエンジニアとしてUI実装に携わってきました。このため、業務内外で得られた知見や事例を共有することで、少しでも皆様のお役に立てればと考えたのです。 iOSとAndroidにおいて、同じUI体験をネイティブで実現しようとする場面は、日常の業務や個人開発で頻繁に直面する課題です。例えば、実装の難易度を見誤ったり、無意味に複雑な実装をしてしまったりして、標準の動きと比較して違和感が生じることがあります。 本発表では、この様な課題にどのように向き合い、上手に付き合いながらプロジェクトを進めていくかという考え方とアプローチをお伝えしたいと思いました。 登壇時に利用した全スライドはこちら 意外とこの様なケースってありませんか？ iOSとAndroidのネイティブアプリ開発において、振る舞いが似ているように見えても、実際には異なる方向性が必要になることがあります。例えば、1つのOSではスムーズに進む一方で別のOSでは苦戦するケースや、純正部品が提供されていない場合があります。同様に、他のアプリで見られるような表現でも難解で複雑な構造が問題となることもあります。こうした状況では、異なるプラットフォーム間での注意深い対応が求められます。 アプリ開発でのiOSとAndroid間の違いを減らすには、いくつかの着眼点が重要です。まず、両プラットフォームで提供されている純正部品への理解を深めること。また、新旧を問わず、実現方法やOSSの活用法についても理解が求められます。さらに、デザインデータを実際に構築する際のイメージを具体化することも有用です。こうした視点を持つことで、予期しない問題に対処しやすくなります。 ネイティブアプリ開発において、iOSとAndroidそれぞれのガイドラインに立ち返ることが重要です。特に、機能を考える際に対応するUIを設計するためには、各OSの純正部品もこのガイドラインに沿って提供されるので、Human Interface GuidelineやMaterial Designの確認が不可欠です。やむを得ずカスタマイズが必要な場合でも、ガイドラインから逸脱しないよう注意し、保守性の高い実装を心がけることが大切です。 実際に出会したややこしいケースをご紹介 私は2023年と2024年に、DroidKaigi公式アプリでiOS側のコントリビューションを行いました。 特に私が担当したUI実装に関連する部分では、AndroidとiOSでそれぞれのプラットフォームに応じた異なるアプローチが必要でした。本稿では2023年に取り組んだ事例を紹介します。 Android版のUI構築では、純正Componentを活用する方針を採用していました。UI要素はJetpack Composeの基本Componentを組み合わせることで実現し、スクロールの変化量をScrollStateで管理していました。また、NestedScrollの特性を活用して、Tab要素とContents要素におけるスクロール動作を実現していました。 一方iOS版では、SwiftUIを使用したUI構築においてカスタマイズが必要でした。難しかったのは、ScrollViewの拡張でOffset値を取得し、LazyVStackを基にしてTab要素の動きを再現する工夫が必要な点でした。取得したスクロール変化量を利用して、SectionHeaderに配置したTab要素の状態を変化させる処理がポイントになりますが、この表現はAndroid版の振る舞いを参考にし、できる限り近い形となる様に自作しました。 スライド内で紹介したiOS版の再現実装コード 複雑なGrid表現の例として、iOSとAndroidのアプローチを比較します。 iOSでは、UICollectionViewを使用し、高さやアスペクト比を元に工夫が必要です。一方、AndroidではStaggeredGridLayoutManagerを用いることで、よりシンプルに実現できます。 これにより、プラットフォーム間での考え方や実装方法の相違が明確になります。 Swipe切替表現の実装に関して、iOSとAndroidではアプローチが異なります。 iOSでは、UIKitを利用する事で表示要素や位置変化を活用し、工夫次第で多様な表現が可能です。一方、Androidでは、ViewPagerとTabLayoutの組み合わせが基本で、細かなデザインのカスタマイズは難しい場合があります。 カスタマイズの余地を考慮し、どちらのプラットフォームにも適した実装を選ぶことが重要です。 iOSに存在しないがAndroidにはある表現（またはその逆）を実装する際は、慎重にアプローチを検討する必要があります。特に、汎用的な形で多用途に活用される場合には、特に注意が必要です。 用意されていない表現を自作し、汎用的で活用しやすい形に整えるには、かなりの工数がかかります。そのため、こうした場合にはOSSの活用も視野に入れると良いでしょう。 端末固有機能である動画再生やプッシュ通知の実装には、プラットフォームごとに大きな違いがあります。同じ機能でもiOSとAndroidでは振る舞いが異なるため、実装方針には注意が必要です。また、OS準拠機能の違いを理解し、必要な知識を把握することも重要です。 スライドで紹介しているのは、アプリがバックグラウンド状態になる際も音声が途切れることなく再生できる機能の例です。一見、同様の機能に見えても、実装方針は全く異なります。それぞれのOSに応じた対応が求められる点に注意が必要です。 落とし穴をうまく回避するために デザインから逆算して実装の難易度を正確に見積もることが、落とし穴を回避する鍵になると考えています。 デザインからは、実装イメージやハマりそうな点、想定工数など、実装に役立つ様々な情報を読み取ることができます。その情報を見逃さず、曖昧な見積もりを避けるために、見えない情報を具体化することが重要だと思います。 モバイルアプリ開発における難易度の見積もりで重要な観点として、UIコンポーネントの複雑さやプラットフォーム間の差異に加え、データフロー・パフォーマンス・API連携・セキュリティ・アクセシビリティ・ローカライズ・テスト・メンテナンス性等の項目挙げられると思います。 これらの要素を考慮してデザインから逆算し、実装難易度を正確に見積もることが、長期的なプロジェクトの成功と円滑な進行につながると考えています。 iOSとAndroidのUI実装では、それぞれのプラットフォーム間で考え方やコンポーネントにおける相違点を理解することが重要だと考えています。 アニメーションやトランジション・カスタムUIコンポーネントの実装・システムUIとの統合・アプリのライフサイクルなどが異なるため、アジャイル開発の観点からもこれらの違いを把握して計画することが求められます。これにより、スプリント計画の精度が向上し、リソースを最適に配分することが可能になります。 正確な見積もりを行うと同時に、「実現しやすい手段や方法」を模索すると良いでしょう。スライドで紹介しているのは、従来の手法では難しかったUI実装を、宣言的UIを活用してシンプルに実現する例です。 SwiftUIやJetpack Composeを用いてSection構造を工夫することで、視覚的に分かりやすいデザインが可能になります。選択する方針次第では、View構造が簡素化され、実装が一層容易になることもあります。 1つのUI実装に対して様々なアプローチを知っておくことで、選択肢を広げることができ、見積もりや実装に対する引き出しが増えるため、とても有益だと考えています。 実装イメージを整理して言葉に直してみる 私が個人的に実践していることの一つに、気になったUI実装や表現に関する事例を紐解き、ポイントになり得る点をノートにまとめる作業があります。 情報源としては海外ブログ記事やYouTubeの解説動画など多岐にわたります。動作するサンプルコードにも触れ、自分の言葉でまとめるとともに、図解を用いてイメージを整理し、応用事例を深く理解しながら、今後の実装に活かすことを心がけています。 紹介しているノートはこちらで公開しています まとめ 本記事を通じて、一見すると簡単そうに見えるものでも、実は複雑であることを認識する重要性をお伝えしました。 iOSとAndroidの共通点と相違点を理解し、困難な事例に備えることで、自分なりの解決策を持つことが重要だと考えています。そして、デザインを基に難易度を逆算し、実装イメージを固めるアプローチを取るためには、実装経験から得た気づきや、目に見えない情報を大切にする姿勢が重要になると思います。 参考資料 円滑なUI＆機能実装やデザイナーとの共同作業を進めるために心がけてきた事 iOSエンジニアがAndroid・Kotlinでの開発を加速させた3年間の実践テクニック Androidアプリでバックグラウンド再生機能を実現するためのヒントとiOSアプリとの見比べた際の特徴を簡単にまとめてみた Footprints about Contribution of DroidKaigi 2023 あとがき 今回の5分間のスライドは、予想以上に盛りだくさんとなり、当日はかなり早口で話すことになりました。しかし、参加者の方々から共感やお褒めの言葉をいただき、大変嬉しく思いました。 私は、モバイルアプリのUI実装に関連するトピックや事例に触れることが好きなので、今後もこのような活動を続けていきたいと考えています。