こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 技術カンファレンス向けのモバイルアプリ「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日目の記事は山本さんです！お楽しみに！！

こんにちは、ラクス技術広報です。 2026年7月15日、主催イベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、楽楽精算 開発3課の平川裕多さんが発表した「仕様駆動開発、導入半年。『本当に速くなってるの?』にデータで答える」について、技術広報がレポート記事でご紹介します。 この記事はこのような方におすすめです AI活用で実装は速くなった気がするのに、なぜか設計やレビューの負荷が増えていると感じているエンジニアの方 仕様駆動開発(SDD)の導入を検討している、あるいは導入したものの効果を数字で説明できずに悩んでいる方 「AIネイティブな開発」を、感覚ではなくデータで語りたいと考えているエンジニアの方 【目次】 「それ、本当に速くなってるの?」に答えられなかった半年 仕様駆動開発に"飛びついた"というのが実態でした 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 データを掘って初めて分かった、3つの指標の意外な共通点 指標①：時間 指標②：レビュー 指標③：バグ（事故） 3つの指標から見えてきたもの 正直に語られた課題と、「仕様を決める力」への投資 終わりに 「それ、本当に速くなってるの?」に答えられなかった半年 平川さんのチームが担当するのは、経費精算クラウドサービス「楽楽精算」のモバイルアプリです。iOS、Android、バックエンド、フロントエンドという複数のプラットフォームを、6名のエンジニアがアジャイルの2週間スプリントで開発しています。 ここ1〜2年でAI活用が本格化し、個人の実装スピードは体感としても数字としても間違いなく上がったといいます。コードを書く作業は、以前ほど開発のボトルネックではなくなりました。 ところがその裏で、3つの問題が起きていました。 意図のよく分からないコードが混ざるようになったこと レビューの負荷に偏りが出るようになったこと テストフェーズになって初めて「考慮漏れ」に気づく事故が多発するようになったこと 設計段階で気づかず、後工程で発覚するほど、修正のコストは高くつきます。 「早くはなったけど、何か別のものを払っている感覚があった」 この違和感から生まれたのが、「AIで早くなった裏で、本当は何を払っていたのか」という問いでした。 仕様駆動開発に"飛びついた"というのが実態でした この問いに対して、平川さんたちがたどり着いたのが仕様駆動開発(SDD)でした。ただし、最初からSDDを狙って導入したわけではなかった、と平川さんは振り返ります。 最初にやっていたのは、今まで手で書いていた設計書をAIに書かせて時短できないか、という「AI設計テンプレート」的な試みでした。それを1ヶ月ほど地道に作り込んでいたそうです。ちょうどそこに、世の中で「仕様駆動開発」という言葉が流行り始め、「これ、自分がやりたかったやつだ」と思ったといいます。慎重に比較検討して選んだというより、飛びついたという感覚の方が実態に近いと振り返ります。 飛びついたあとで、あらためて「なぜ他のやり方ではなくSDDだったのか」を整理しました。 Planモード ：AIがタスクを組んでくれて便利だが、結局それを使うエンジニア個人の能力に依存する点で、直接指示と本質的に変わらない テスト駆動開発(TDD) ：リファクタリングには強いが、そもそも仕様がブレていればテスト自体が空中分解してしまう Planモードの質もTDDのテストの質も、たどっていくと結局は「仕様」に行き着く。だったら一番上流の「仕様」そのものを中心に据えるのが筋が良い、という腹落ちだったとのことでした。 具体的には、マークダウンで構造化した自然言語の仕様書を使い、設計そのものをPRとしてレビューする運用を敷きました。とはいえ、自然言語の成果物にはコードのようなリンターもテストも効きません。「問題ない」と判断するにはしっかり読む必要があり、コストがかかります。仕様を構造化したり重複を減らしたりという地味なチューニングを、今も積み重ねている最中とのことでした。 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 SDDを始めてすぐ、突っ込まれる日々が始まりました。 上司からは「それ本当に早くなってるの」「設計に時間をかけている分、トータルで遅くなっているんじゃないの」という声。メンバーからは「設計フェーズが大変になった」「一番頭を使う部分が重くなった」という声が上がりました。 この2つのツッコミに、感覚で「いや、早くなっていますよ」と返しても説得力がありません。そう考えた平川さんは、1年分のデータを本気で掘り返して検証することにしました。 なお、平川さん自身「そもそもSDDを品質のために入れたわけではなく、狙いは実装を誰がやっても同じ質にして属人性をなくすことだった」と前置きしています。この後の検証結果は、当初の狙いとは別のところで平川さんたちを驚かせることになります。 データを掘って初めて分かった、3つの指標の意外な共通点 AIもアジャイルも定着した時期以降のデータに絞り、フェアな比較を心がけたうえで、3つの指標を見ていきます。 指標①：時間 実装フェーズの数字は、確かに速くなっていました。ただし、その「速さ」の正体を追うと、後工程にあった意思決定の負荷が、設計フェーズに前倒しされただけでした。たとえば「複数ある実装方針のどれを採用するか」という判断は、SDD以前は実装しながら決めることもありました。今はそれを設計のタイミングで行います。AIが選択肢を出してくれる分、考えるのは楽になった場面はあるものの、最終的にどれにするかを人間が決め、レビューやステークホルダーの合意を得る必要がある点は変わりません。SDD自体は時短策ではない、というのが平川さんの見立てです。 指標②：レビュー 1つのPRあたりの他者からのコメント数は、中央値がずっと1でほぼ横ばいでした。レビューの総量そのものは減っていません。ただし中身は変わっていました。実装PRで「この仕様どうなってるの?」という揉め事が減り、その議論が仕様レビューの場に前倒しされたのです。レビューが純粋なコード品質チェックに近づいたという意味では狙い通りですが、「楽になった」わけではなく、「議論する場所が移った」というのが実態に近い、と平川さんは説明します。 指標③：バグ（事故） バグの発生件数そのものは、劇的には変わっていませんでした。ただし2つの変化がありました。1つは、1件あたりの対応時間（※着手からテスト完了までのリードタイム）が17時間から11時間に短縮したこと。もう1つが、平川さんいわく「これが大きい」変化でした。以前は1スプリントで20件を超えるような"バグの大爆発"が起きることがあったのが、最大でも8件程度に収まるようになりました。事故の数ではなく、事故の振れ幅が小さくなったということです。 なお、この集計はテストまで完了したスプリントのみを対象にしており、サンプル数はまだ多くありません。平川さん自身、断定ではなく傾向として見てほしいと、数字の限界を率直に語っていました。 3つの指標から見えてきたもの 3つの指標を並べると、見えてくるものがあります。時間もレビューも、内容は移っただけで総量は変わらず、バグは件数こそ横ばいながら振れ幅が縮みました。 ここから導かれる結論を、平川さんはこう言い切ります。「SDDの本当の成果は、速さじゃない」。開発そのもののスピードは、AIをガムシャラに使っていた1年前とほとんど変わっていません。得られたのは、予測可能性でした。裏を返せば、以前ガムシャラに速度を出していた頃、代わりに払っていたのは、この予測可能性だったのです。 平川さんはこれを具体的なエピソードで語っていました。怖いのは、バグ修正にかかる時間そのものより、「何件出るか読めないこと」だそうです。2週間スプリントの7日目まで予定通り進み、残業もせず帰れていたとします。それなのにテストでバグがたくさん出ると、残り数日で焦って対応するか、別スプリントに送るかという判断に迫られ、計画が崩れます。SDDによって仕様の検討が上流に寄った結果、この「予想外の大爆発」が起きにくくなったのです。平均的な件数は大きく変わらなくても、最悪のケースが消えて振れ幅が縮み、立てた計画が、そのまま計画として機能するようになりました。 そしてこれは、働きやすさだけの話ではありません。事故で開発が止まらないということは、顧客に安定したペースで価値を届け続けられるということでもあります。予測可能性は、顧客への価値提供の土台でもある。平川さんはそう位置づけていました。 正直に語られた課題と、「仕様を決める力」への投資 SDDは時短の手法ではなく、決めごとの総量も変わりません。それでも品質と予測可能性への投資だった、というのが平川さんの結論です。実装スピードそのものは変わらなくても、速さの出方が変わりました。昔は事故が起きるかどうか読めないまま勢いで速度を出していたのに対し、今は上流で足場を固めてから、同じ速度を読める形で出している。アジャイルを捨てたわけでもなく、2週間スプリントという枠のなかで「決める位置」を前にずらしただけだ、という整理も印象的でした。 ここで終われば美談ですが、平川さんは課題も正直に語っていました。時間もレビューも総量は「移っただけ」で減ってはおらず、総量そのものをどう減らすかは宿題のままです。さらに、レビューを上流に寄せた結果、今度は仕様レビューの方が渋滞するという新しいボトルネックも生まれています。 興味深かったのは、仕様が設計段階で固まることで、そこからテストを作るのも楽になるという発見です。固まった仕様を起点にすれば、テスト設計やユニットテストを考える時間も減り、AIに任せられる部分も増えます。上流で固めた仕様を、テスト作成の自動化にそのまま流し込む。この接続を今まさに模索しているそうです。 またメンバーの「設計フェーズが大変」という声の実体は、仕様書を作ったあとのモブレビューではなく、その前段階、個人がローカルで仕様を練っている時間が最も頭を使う、というものでした。ここに「ループ」や「ハーネス」といった仕組みを当てはめ、機械的に拾える考慮漏れはモブレビュー前に潰しておきたいとのこと。ただし、モブレビューそのものは残したいとも話していました。人を育てる場であり、テックリード一人がすべてをレビューしなくても、メンバー同士でレビューが回るようになる効果もあるからです。自動化するのは生成の負荷にあたる部分で、人間の判断や育成の機会は残す。この線引きを大切にしているとのことでした。 この先の展望として、平川さんは「ループエンジニアリング」という考え方も紹介していました。海外のAI開発ツールの責任者が「もうAIに指示は出していない、自分の仕事はループを書くことだ」と話しているそうで、その考え方の提唱者とされる人物も「これは仕事が簡単になったわけではなく、レバレッジの効く点が移っただけ」と釘を刺しているとのことでした。これは平川さんが今回データで語った「決める場所が上流に移っただけ」と、驚くほど重なる指摘です。その人物はさらに、全部を自動ループに任せればプロダクトの品質は落ちるとまで話しているそうです。つまりループは「何が正解か」の判断までは代わってくれません。その「何が正解か」を上流ではっきりさせるのが、まさにSDDです。ループの時代が来るほど、その前段にある「仕様を決める力」の価値は上がっていく。開発をAIに委ねても、「何が正解かを決めるカロリー」だけは人間に残る、という見方を示していました。 予測可能性が手に入るということは、AIに安全に任せられる範囲が見えてくるということでもあります。読めないものは任せられませんが、振れ幅が小さく読めるものなら任せられます。その範囲を安全に広げていけば、いずれボリュームが増え、トータルのリードタイムも縮んでいくはずです。平川さんは、今回手に入れた予測可能性を、その先の自動化を安全に広げるための「足場」だと位置づけていました。 終わりに 時短にはなっていない、新しいボトルネックも生まれた。それでも正直に数字と向き合う姿勢そのものが、AIネイティブな開発組織のリアルなのだと感じます。「なんとなく速くなった気がする」で終わらせず、データで自分たちの仮説を裏切る勇気を持てるかどうか。仕様駆動開発を検討している方にとって、平川さんの検証プロセスそのものが参考になれば幸いです。 当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 発表資料 speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 ラクスエンジニア情報ポータルサイト career-recruit.rakus.co.jp 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ラクスでは、こうした「顧客志向」と「AIネイティブ」の両方を大切にしながら、地に足のついた検証を重ねる開発組織を、一緒に作っていく仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！