LINEヤフー株式会社では、技術に関するイベントや勉強会の主催・協賛などを行っています。最新情報は各リンク先でご確認ください。タイミングによっては、申し込み開始前や既に満席となっていることがあります。...

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 技術カンファレンス向けのモバイルアプリ「Findy Events」を、React Nativeで開発しています。iOSは App Store 、Androidは Google Play で公開しています。 Findy Conferenceチームでは、職種を問わず、プロダクトを作っている本人がカンファレンスの会場に立ち、参加者へのユーザーヒアリングを実施しています。私も AI Engineering Summit Tokyo 2026 の会場に立った1人です。この会場でチームとして集めた101人分の声から、ナビゲーション構造の作り直しと、次のカンファレンスでの仮説検証まで一周させました。 この記事では、ユーザーヒアリングを通して得られた課題から、どう仮説を立てて検証したのかについて書きます。 モーダルの中にタブバーを置いていた当初の画面構成 101人へのヒアリングで見つかった2つの発見 見た目と文言を直す案に残った引っかかり ターゲットペルソナの認識をチームで揃え直す Appleのガイドラインを読み直して見えた構成の問題 起動直後の画面を直近のカンファレンスのホームに変える 96人への再ヒアリングの結果 まとめ モーダルの中にタブバーを置いていた当初の画面構成 Findy Eventsには、当初からUI/UXの課題感がありました。それは、本来トップレベルに置くべき「タブバー」を一時的なモーダルの中に置いてしまったことです。 アプリを起動すると、参加予定のカンファレンスが並ぶチケット一覧が表示されます。カードの下には「入場チケットを表示」ボタンが並んでおり、タップすると入場用のQRコードが開きます。カード自体をタップした場合はモーダルで詳細画面が開き、そのモーダルの中に、ホームやタイムテーブルを行き来するタブバーを配置していました。 ※本記事に掲載している画面はすべてテスト環境のもので、カンファレンス名や日付はテストデータです。 タブバー は、アプリのトップレベルのセクション間を移動するためのものです。一方で モーダル は、今の画面の上に一時的に重なり、閉じれば消える層であって、トップレベルのセクションではありません。冒頭に書いた課題は、この定義のズレのことです。 Androidで同じ役割を担う ナビゲーションバー も、アプリの画面をまたいで一貫した行き先を並べるものだとされています。モーダルの中にだけ現れる置き方は、こちらの条件も満たしていません。 この構成を選んだ理由は、ユーザーがカンファレンスに参加する前と当日とで、欲しい情報が異なると考えていたためでした。参加前であれば申し込んだカンファレンスやおすすめのカンファレンスを、当日であれば参加するカンファレンスの情報だけを見たくなるはずだ、という想定です。 1stビューはどちらか一方にしか倒せません。両立させるために取ったのが、この苦肉の構成でした。カンファレンス当日もチケット一覧から該当のカンファレンスをタップすれば見たい情報にはたどり着けますし、モーダルの中の操作も使い始めれば慣れるはずだと考えていた側面もあります。 つまり、原理原則から外れていることは理解した上で、代わりの案を出せずにいました。そして開発を続けるうちに、開発者である自分自身がその操作に慣れてしまい、違和感は少しずつ薄れていきました。 101人へのヒアリングで見つかった2つの発見 違和感が薄れたまま迎えたのが、2026年6月8日から9日にかけて開催されたAI Engineering Summit Tokyo 2026です。この会場で、チームで手分けして101人に話を聞きました。 「アプリを見て使いにくかった点や、もっとこういう機能があれば嬉しいなどあれば教えてください」というオープンクエスチョンでヒアリングしました。まだアプリを使っていない方には持ち込んだデモ機をお渡しし、操作していただきながら答えていただく形です。 この質問を用意しながら、内心期待していたのは機能要望でした。あの情報が足りない、こういう画面が欲しい、といった声が集まるものだと考えていたのです。 実際に多かったのは、カードをタップすると開く詳細画面やタイムテーブルの存在に気づかれていない、という話でした。デモ機で見られたのは、一覧を眺める、上下にスクロールする、「入場チケットを表示」からQRコードを出す、設定画面を開く、といった操作です。カードをタップしてモーダルを開くところには至っていませんでした。モーダルの先で既に提供している情報が、そのまま「あったら嬉しい」という要望として挙がることもありました。 もうひとつ、モーダルのタブバーの「ホーム」を連打する様子が見られました。その意図を尋ねたところ、「ホームに戻りたいから」とのことでした。つまり、チケット一覧画面をホームと捉えていた、ということです。モーダルを閉じる導線は左上にありましたが、選択肢として認識されていませんでした。ユーザーが思い描いていた動きと実態のズレです。 この2つから、薄れていた違和感を改めて突きつけられました。使い慣れた開発者に見えなくなっていただけで、構成そのものの問題は残っていたわけです。 見た目と文言を直す案に残った引っかかり 最初に出した答えは、モーダルに気づいてもらうためにチケット一覧のカードをタップできる見た目に寄せることと、タブバーの「ホーム」という項目名を実態に合わせて連打をなくすよう誘導することでした。会場で見えた2つの症状に、それぞれ手を打つ形です。 ただ、この案では、モーダルの中にタブバーがあるという構成そのものは変わりません。気づいてもらえるかどうかを見た目の強さに委ねているだけで、なぜ気づかれなかったのかには答えられていない、という引っかかりが残りました。 ターゲットペルソナの認識をチームで揃え直す 立ち返ったのは、誰に向けたアプリなのかというところでした。 Findy Eventsが向き合うのは技術カンファレンスの参加者で、参加の頻度は年に数回です。前回の利用から数ヶ月空いた状態で起動されることを前提にすると、原理原則から乖離した構成は、アプリを開くたびにユーザーへ再学習を求めることになります。会場で見えたのと同じことが、次の機会にも起こる可能性があるということです。 Appleのガイドラインを読み直して見えた構成の問題 参考にしたのが、Appleの Human Interface Guidelines です。設計の原則がいくつか挙げられており、そのうちPurpose、Agency、Familiarityの3つが、当時の構成を見直す手がかりになりました。 Purposeは、人々がどう使いたいかに沿って最も重要な機能を絞り込むという原則です。参加前と当日の両方を1stビューで抱えようとしていたため、どちらの利用目的にも焦点が合っていませんでした。 Agencyは、ユーザーが主導権を持てるようにするという原則で、目の前のタスクやコンテンツに直接導くこと、特定のフローやモードに閉じ込めないことが述べられています。チケット一覧から段階を踏む構成は当日必要な情報へ直接導けておらず、モーダルを閉じる導線が認識されないままホームを連打していた状態は、ユーザーの行動を不自然な形で閉じ込めているのと変わりません。 Familiarityは、人々が既に知っている概念を使うという原則です。現実世界や他のソフトウェアで得た知識を持ち込むことで、インターフェースは馴染みやすく直感的になるとされています。年に数回の利用が前提のアプリで頼れるのは、アプリの中で積み上がる学習ではなく、人々が普段から慣れ親しんだ知識や経験のほうでした。 最初の案に残っていた引っかかりの正体は、ここにありました。単に表面を整えるだけでは、このPurpose、Agency、Familiarityはどれも変わりません。構成そのものを見直す必要があると考えました。 起動直後の画面を直近のカンファレンスのホームに変える ターゲットペルソナを踏まえると、アプリが起動されるのはカンファレンス開催日の直前から当日である可能性が高いと考えられます。それであれば、参加当日に欲しい情報へ直接導くのが妥当です。代案を出せずにいた「参加前と当日のどちらに倒すか」も、ここで決着がつきました。 そこでアプリ起動時の1stビューを、直近の参加予定カンファレンスのホーム画面に変更しました。これまでモーダルの中に置かれていた画面が、そのまま最初に表示される形です。結果として、モーダルの中にタブバーがある構成も解消されました。 変更前は起動後にチケット一覧が表示され、そこから先に進む必要がありました。変更後は、当日必要になる情報が最初から表示されます。 もちろん、他に参加予定のカンファレンスの情報などへの導線は残しています。行き先を塞いだわけではなく、あくまでも1stビューで最も必要な情報へ導くことを意識した整理になります。 なお、この変更はAndroidの Principles of navigation でいうstart destinationを選び直したことにあたります。Material DesignにHIGの3原則と直接対応するものはありませんが、Androidのナビゲーション原則から外れる判断ではありませんでした。 96人への再ヒアリングの結果 1stビューを変えることで、機能の見落としや、ユーザーが思い描く動きと実態のズレを減らせるはずだ。この仮説を持って、2026年7月22日から23日に開催された AI DevEx Conference 2026 の会場で、同じくチームで手分けして96人に話を聞きました。 1回目は「画面遷移に気づかない」という趣旨の声が15件以上あがり、タブバーの「ホーム」を連打する様子も見られました。2回目は、その声は0件で、連打する様子も見られませんでした。 ただし、これをもって因果の断定はできません。同一人物に聞き直したわけではなく、カンファレンスが異なるため参加者の属性も揃っていないためです。言えるのは、101人と96人というほぼ同規模のヒアリングで、仮説を否定する材料は出てこなかった、というところまでです。 まとめ 改めて感じたのは、現場に出て直接ユーザーの声を聞くことの大切さでした。違和感そのものは、チームの中でも気づけます。ただ、それが本当に直すべき問題なのかまでは確信が持てず、時間とともに薄れていきました。実際に使っていただき、その言葉と操作に触れたことで、はじめて確信に変わりました。 そうして一周させた結果、「恒常的に起動されるアプリではない場合ほど、原理原則に準ずることが効いてくる」という手応えを得ることができました。日常的に起動しないアプリでは、ユーザーが他のアプリを通じて既に学習している使い方をそのまま持ち込めれば、自然に使えるアプリに近づきます。 会場で聞いて直し、次の機会に確かめる。この形で仮説と検証を回しながら、引き続き会場に立ち、聞いた声を改善につなげていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こちらの記事は「MEDLEY Summer Tech Blog Relay」の20日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに メドレー 医療プラットフォーム開発室 SREグループに2026年4月に入社した柏木と申します。 これまでの経歴は以下のとおりです。 1社目: 人事給与系企業の子会社に入社し、パッケージソフトウェアの導入設定やビジネスチャットのAndroidアプリ開発などを担当 2社目: メール配信SaaSのインフラ構築から開発、レンタルサーバー事業のエンジニアなどを担当 3社目: メドレー 医療プラットフォーム開発室 SREグループ（現職） このような流れで幅広い技術領域の経験を積んできたエンジニアです。 本記事では、社内向けの業務Webアプリを短期間で開発した経験を通じて、「AIによってWebアプリ開発がどう変わったか」についてお伝えします。 メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。 何を作ったのか この1〜2週間で、社内業務の運用に必要な一部機能を備えた社内向けWebアプリを開発しました。 なぜ作ったのか（背景） メドレーの医療プラットフォームでは、医療事業者向けに複数のSaaSプロダクトを提供しています。私は社内業務の運用改善にも関わっています。 対象となる管理データは、運用しながら改善を重ねてきました。今後さらに効率的かつ再現性高く管理するため、一部の作業では Claude も活用しながら、データを正規化して仕組みとして管理できる状態を目指すことにしました。こうした課題感から、今回の開発をスタートしました。 「Webアプリ作りが簡単になった」と感じた3つの瞬間 「単なるCRUDのWebアプリならAIを使わずとも簡単に作れるのでは?」と思われるかもしれません。しかし今回は、既存のExcel形式を踏襲したスプレッドシート風の入力画面に加え、コメント機能、バージョン管理、差分比較、さらには管理メニューでの組織ツリー管理など、それなりの規模のアプリケーションになっています。 このアプリを開発する中で、「Webアプリ作りが本当に簡単になった」と確信した瞬間が3回ありました。 1. インフラ構成と要件を少し伝えただけで形になったとき AIに伝えたのは、インフラ構成、使用言語、開発の流れだけでした。文字数にすると、本記事のここまでの文章よりも少ない分量です。 その程度のプロンプトでほぼ全機能のコードが完成したとき、「最小限の知識とプロンプトで、新しいものをゼロから作れる時代になった」と実感しました。 2. Playwrightにテストを任せて、デグレを自動で発見・修正してくれたとき スプレッドシート風の入力画面は、手作業でのテストに非常に手間がかかり、デグレ（意図しない機能の後退や不具合）を見つけるのが困難です。 そこで Playwright によるテストの追加をAIに依頼し、すべてのテストをパスする状態を作りました。すると、次の修正を入れた際にAIがデグレを発見し、自律的に修正まで完了させてくれたのです。 開発の中でもっとも地道で骨の折れる作業が不要になった瞬間でした。 3. MCP（Model Context Protocol）サーバーを活用したとき 一番驚いたのはここです。 初期データの整備では、 MCP（Model Context Protocol） サーバーの機能を追加し、Claude経由で「自然言語による処理内容の設計からシェルスクリプトの作成まで」を行いました。 これが成功したとき、「Webアプリは、データを保持する『箱』と『インターフェース』に過ぎなくなったのだ」と深く納得しました。 なお、AIにデータベースを直接操作させるのではなくシェルスクリプトを出力させたのは、処理内容をコードとして固定化し、実行前にレビューできるようにすることでリスクを抑えるためです。 まとめ 上記の3点を、開発サイクルとして表現すると次のような形です。 この開発サイクルを通して、「業務Webアプリは誰でも簡単に作れる時代になった」ということを実感しました。 この学びから、エンジニアとしての今後の向き合い方は2つあると考えています。 AIを使い倒して開発プロセスを「シフトレフト」するか、AIを圧倒的に上回る専門性を磨くか 自分が作るプロダクトには積極的にAI機能を組み込んでいく AIを機能として組み込んだプロダクト開発ができれば、SaaS企業が提供できる価値はまだまだ広がりますし、AI時代を生き抜くエンジニアになれるはずです。 またどこかで体験談や知見を共有できればと思いますので、ぜひメドレーのDeveloper Portalのフォローをお願いします。 We’re hiring メドレーでは、SREをはじめ「医療ヘルスケアの未来をつくる」ことに取り組むエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 21日目の記事は山本さんです！お楽しみに！！