捨てる、という判断 — エンジニアの役割の変化に向き合うConference

ファインディ株式会社主催オンラインカンファレンス「エンジニアの役割の変化に向き合うConference 2026」Day1（2026年6月17日）12:00〜12:30
約30年の歴史を持つアップルワールドには、レガシーな体制やシステムが多く残っています。海外展開の新プロジェクトでは、PoCのシステムを捨てる大きな判断をしました。失敗の本質は、課題が曖昧なまま実装が決まっていたこと。本セッションでは、この経験を起点に、「課題を考える組織」へのスクラム導入、課題の解像度を上げる承認プロセス、事業と開発がワンチームになるプロダクトレビューへと変えてきた過程を話します。AIで変わったエンジニアの視点と、今後エンジニアが考えるべき問いも共有します。
株式会社アップルワールド プロダクト開発部開発戦略グループ エグゼクティブマネージャー

Transcript

1. 捨てる、 という判断 課題が曖昧なまま、実装を決めてはいけない AIで「速く作れる」時代だからこそ、素早く正しい判断をすることがチームの成否を 分ける。 S P E A K E R 高丸 翔英 Shoei Takamaru 株式会社アップルワールド プロダクト開発部 開発戦略グループ エグゼクティブマネージャー 2026.06.17
2. SPEAKER 高丸 翔英 株式会社アップルワールド プロダクト開発部 開発戦略グループ エグゼクティブマネージャー AI推進・レガシー刷新・生産性・セキュリティ・採用まで、開発組織全体の戦略を見 る。技術だけでなく組織や事業も自分の力で変えたい、領域を越えて動きたいタイ プ。 CAREER 楽天 ポータルサービス、国際市場PFのエンジニアチームをリード note サービス立ち上げ時のエンジニア リクルート テックリードとしてサロン予約サービスの技術品質をリード 共同創業・CTO 技術組織を立ち上げ、技術と組織の両面に責任を持つ アップルワールド 2025年3月入社。開発組織全体の戦略を統括 Speaker — 自己紹介 02
3. 旅する人と、それを支える すべての人が一歩先の未来へ 踏み出す後押しをします。 旅は新たな発見や感動をもたらし、多様な価値観との出会いは人 生を豊かにしてくれます。私たちは、情報・テクノロジーの力 と、お客様の期待を超えるサービスで、情報流通の最大化と選択 の最適化を実現し、旅の可能性を広げるとともに、旅する人とそ れを支えるすべての人が、自信と誇りを持ち、自分らしく輝ける 社会を実現します。 Philosophy — 企業理念・ミッション 03 GATEWAY TO POSSIBILITIES Your
4. 旅行産業における テクノロジー プラットフォーム 世界中のランドオペレーターからホテル情報を収集・ 整理し、国内を中心とする旅行会社3,000社や提携企 業、個人ユーザーに対して提供するランドオペレータ ーアグリゲーターの地位を業界最大規模で築いていま す。 今後は、現在の主力である海外ホテル・国内航空券の 強化と同時に、ツアー・ホテル・海外航空券など商材 の拡張を行い、持続的な成長を目指します。 Service — アップルワールドの事業 04
5. 今日のテーマ 「捨てる」という判断。 課題が曖昧なまま、 実装を決めてはいけない。 AIで「速く作れる」時代だからこそ——素早く正しい決断をすることが、チームの成否を分ける。 Intro — 今日のテーマ 05
6. CHAPTER 01 海外展開プロジェクトで、 何を捨てたか？ 楽に見えた道が、制限の塊になった。その立て直しの話。 APPLE WORLD × エンジニアの役割の変化に向き合うConference — What we threw away
7. カンファレンスの問い — 広がった責任範囲の中で、何を軸に決めるべきか 海外展開プロジェクトで、 重要な判断を何度も迫られた。 2025.08 参画 入社して半年も経たないうちに参画 1年3か月 入社からの期間 変化のスピードは、本当に早かった 何度も 迫られた判断 広がった責任範囲の中で、何を軸に決 めるか スピード感を持って開発を進めるためには、捨てなければならないものも、数多くあった。 Chapter 01 — 海外展開プロジェクト 06
8. 出発点は、 "楽に見える道" だった。 参画時、すでにPoCは進行。社内には、非常にレガシーな予約基幹システム。 前提 APIを一から開発せず、 ノーコードツールで レガシーな予約基幹システムにつなぐ。 ≈ 期待 「これで簡易的に 実現できるだろう」 この判断をしたのは私が入る前。前任者を批判したいわけではない。リソースが限られた当時としては、 合理的な判断だった。 Chapter 01 — 出発点 — PoC 07 ——一見、楽に見えた。
9. なぜ、楽な道が 行き止まったのか？ 01 レガシー側の縛り 既存の予約基幹システムの仕様に縛られる 02 ノーコード側の縛り ツールが許す範囲しか実装できない 少し複雑なことをやろうとした瞬間に、できなくなる。楽をしようとしたら、制限ばかりが立ちはだかっ た。 Chapter 01 — 二重の縛り 08
10. 本当の原因は、 技術選定だったか？ No. 「技術の選び方を間違えた」と捉えるのは簡単。だが、それだけではない。 課題が曖昧なまま、 実装手段が先に決まっていた。それが本質だった。 Chapter 01 — 本質 09
11. 立て直しで、何を捨てたか？ プロジェクト半ばで、上長と二人で立て直しに入った。それまで使ってきた技術を、すべて即座に 捨てると決めた。 Chapter 01 — 立て直し 10 01 ノーコードツール 既存システムの制限を、そのまま運用 に固定してしまう ✕ 02 会計パッケージ 要件と合っていない、既製の会計シス テム ✕ 03 変則的なDB設計 メンテナンス性を損なう、変則的な STI ✕
12. 何を軸に、捨てると決めたか？ Q Quality 取る C Cost かかる D Delivery 遅れる メンテナンス性とオペレーターの負荷を考えれば、品質を取るべきだ。サンクコストを断ち切るのは重い が、捨てなければ制限がそのまま運用に固定されていた。 Chapter 01 — 判断の軸 11
13. CHAPTER 02 捨てたあと、 何を作り直したか？ 作り直すだけでは、また同じことが起きる。だからスクラ ムを導入した。 APPLE WORLD × エンジニアの役割の変化に向き合うConference — Building the structure
14. なぜ、同時に スクラムを導入したか？ 狙いはひとつ——「何が必要なのか」を、言われる前に開発側が自分で 考えられる構造をつくる。 BEFORE PMスキルに依存した 属人性の高い進め方 → AFTER チーム自身が 「何が必要か」を考える Chapter 02 — スクラム導入 12
15. なぜ、全社にまで広げたか？ 元々はウォーターフォールに近い形。そこには、こんな課題があった。 事業と一体になる機会が少ない 振り返りがない プロダクトについて考えきれて いない リリース時期になんとか間に合わせる。責任は負っていたが、境界がはっきりしていなかった。事業側 も、具体的な挙動を確認しないままリリースしていた。 Chapter 02 — 全社展開 13
16. "スプリントレビュー" を、なぜ "プロダクトレビュー" と呼ぶか？ → Product Review プロダクトの在り方を常に問い直す——その意味を込めて、あえてこう呼 ぶ。 実際のプロダクトを触りながら議論し、事業と開発がワンチームになる瞬間を、仕組みとして作る。 Chapter 02 — プロダクトレビュー 14 Sprint Review
17. CHAPTER 03 課題を明確にする軸を、 組織の仕組みへ 一つのプロジェクトから、会社全体の仕組みへ。 APPLE WORLD × エンジニアの役割の変化に向き合うConference — Embedding judgment into the org
18. 開発プロジェクトの健全性は、 何で決まるか？ レガシーなビジネスでも、開発は会社にとって大きな投資。経営はROIで健全性を判断する。だが ——健全性は、開発生産性だけでは語れない。 顧客の負を捉える → 仮説・課題設定 → 開発 → どう売るか戦略 すべてつながった "連鎖" で決まる Four Keysのような生産性指標はアウトプットの量を測っているにすぎず、この連鎖の一部を見ているだ け。 Chapter 03 — 健全性とは 15
19. 仕組み 01 — ROIを判断する委員会 なぜ、議論のフォーマット 自体を変えたか？ これまでの傾向 スコープが大きく、 遅延や予算超過が多々。 課題の解像度が低いまま進めていた。 変えたこと 本来スラスラ書けるはずの 「課題」の項目を必須に。 書けないなら、まだ課題が見えていない——と判断できるようにした。 Chapter 03 — 予算委員会 16
20. 予算委員会のフォーマットを、こう変えた。 BEFORE 「やること」＋ ざっくり事業影響 （＋ROI計算） AFTER — 課題を書き切る 7項目 1 課題 対象ユーザー／状況・トリガー／摩擦 2 現状の影響 範囲・件数・頻度／時間・金額換算 3 根拠・エビデンス ログ／ユーザーIV／問合せ／失注 4 目指す状態 KPI現状値→目標値／判定タイミング 5 検討した解決策 案1/2/3＋採用案と却下理由 6 検証の進め方 仮説／検証指標／撤退基準 7 想定リスク 価値／ユーザビリティ／実現性／事業性 Chapter 03 — フォーマット改善の実物 17
21. 課題のほかに、 何を問うようにしたか？ DATA 客観的なデータに基づいて、仮説を 立てているか ALT 他の軸の代替案を検討したうえで、 判断しているか 本来は経営やPdM・PMOが決めることが多い。だが最終的には開発に関わる。だから、設計し直した。 Chapter 03 — 問いの設計 18
22. 仕組み 02 — プロジェクト管理ツール なぜ、Notionを捨てて Linearにしたか？ → Linear DBの柔軟さゆえに、かえってルールを作るのが難しい。 あえて制約のあるツールを入れることで、ルールの徹底を選んだ。 Chapter 03 — ツール — Linear 19 Notion
23. LinearとAIは、 何を残してくれるか？ 01 Slack同期 開発中の重要な会話はSlackで起き る。issueと同期すれば、いつも通り 話すだけで「判断の履歴」が残る。 02 自動プロジェクト報告 Projectに紐づくissueの進捗を、 LinearのAIが読み、プロジェクトのア ップデートを自動で更新する。 03 健全性確認へ その自動プロジェクト報告を、経営 層による健全性確認の一つとして使え るようにする。 Chapter 03 — LinearとAI 20
24. CHAPTER 04 役割は、隣の領域へ 染み出していく。 デザイナーはフロントへ、フロントはバックへ、バックは インフラへ。本来 PdM・経営が担う判断にも、開発が踏み 込む。 APPLE WORLD × エンジニアの役割の変化に向き合うConference — Crossing into adjacent domains
25. 職種は、隣の領域へ 自ら染み出していく。 各エンジニアが、自分の専門の「隣」に、自ら踏み込めるようになった。 デザイナー → フロントエンド の領域へ フロントエンジニア → バックエンド の領域へ バックエンドエンジニア → インフラ の領域へ Chapter 04 — 職種の染み出し 21
26. 染み出した先で、 インフラが一番効率化していた。 定量的な数値は出せないが、実感として——インフラ作業の効率が、もっとも上がっている。 IaC コードとして宣言的に組み上げられる 冪等性 作り上げるものが冪等で、結果がぶれ ない 検証しやすさ テストや確認がしやすく、手戻りが小 さい 逆に言えば——そういう設計にしていけば、AIでの効率性を上げられる。 Chapter 04 — 染み出しの先 — インフラ 22
27. CHAPTER 05 AIが普及する時代に、 どう判断するか？ ここまでは「判断を迫られた話」 。ここからは「これから どう判断するか」 。 APPLE WORLD × エンジニアの役割の変化に向き合うConference — Deciding in the age of AI
28. AIは、生産性をどう変えたか？ アウトプットの量は本当に増えた。最初に仕様策定をしっかりやり、あとはAIに任せる。オーケス トレーションで、実装はかなり便利になった。 仕様策定 → AIに任せる → 実装 → 繰り返す = "短いウォーターフォール" エンジニアの枠を抜け出せていない？ Chapter 05 — AIと生産性 23
29. AIは、ROIの見方を変える。 上位モデルはトークンを多く消費する。だが、その額に対してアウトプット・アウトカムが大きいなら——人間のスキルす ら、金額に換算して捉える見方が強まってくる。 人に支払うお金 人間のスキルへの対価 vs AIに投資するお金 トークン・モデルへの投資 ただし、ツールを入れるだけで成果が変わるわけではない（Uberのように、投資しすぎと判断される例 もある） 。だからこそ「測る」ことが、これからも重要になる。 Chapter 05 — AIとROI 24
30. 本当に問うべきことは、何か？ 「それは、 そもそも正しいのか」 場合によっては、"作らない" という判断もある。 Chapter 05 — 作らない判断 25
31. なぜ、速いアウトプットが スプリントを壊すのか？ AIにタスクの中身を考えさせると、 「これもやった方がいい」 「あれも」とどんどん積み上げてく る。結果、スプリントが達成できないことが何度もあった。 AIの出力 速く・多く・一定の品質で出してくる でも それが適切かどうかは別の話 「やらない・後回しにする」という判断がなければ、速さはむしろスプリントを壊す。 Chapter 05 — やらない判断 26
32. 手戻りは、すべて "悪" か？ ウォーターフォールの世界観 手戻り = 悪 すべて避けるべきもの → アジャイル 修正込みで受け入れ、 フィードバックループが極めて速い 手戻りが仮説を検証するステップなら、それは必要なもの。AIの時代は、そちらに寄っていく。 Chapter 05 — 手戻りの捉え方 27
33. AIは、技術負債と どう向き合わせるか？ AIと壁打ちで「技術負債」を相談するケースが増えていないか。昔は「いつかやらないとね」とバ ックログに残り続けた負債解消も、今は使える時間が増えた。 Bun ZigからRustへリプレイス Stripe Rubyコードをリプレイス ＊ 1週間もかからずコードを丸ごと置き換える例が出てきた 自分たちもやれるんじゃないか。技術負債には、誠実に向き合っていかなければならない。 Chapter 05 — 技術負債 28
34. コードを書く楽しみは、 どこへ行ったのか？ 立ち返れば——コードを書くのは、楽しいものだったはず。その楽しみが消えたのは、率直に残 念。 AIは熟練したプログラマーのコードを学習して、今がある。では熟練の プログラマーは、今後どう生まれるのか？ 私の仮説は——AIを使って学習しつつ、自分の専門性を極める。コードを書く機会は減っても、技 術に触れることは続ける。 Chapter 05 — 未解決の問い 29
35. 捨てる、という判断とは 諦めることではない。 課題に対して仮説を立て、誠実に向き合うこと。 Closing — 結論
36. W E ' R E H I R I N G あらゆる旅の ベストパートナーへ。 Link your destination 旅の新しい価値を生み出すクルーを募集しています。 CAREERS https://herp.careers/careers/companies/appleworld/jobs
37. ご清聴ありがとうございました THANK YOU
38. Appendix — 参考リンク 01 Linear Slack Integration https://linear.app/integrations/slack 02 UberのCOOは「AIの過剰利用」への支出を正当化するのが難しくなっていると明かした https://www.businessinsider.jp/article/2605-uber-coo-andrew-macdonald-ai-token-spending-harder-justify/ 03 トークンマキシングからトークンマネジメントへ https://note.com/fukkyy/n/n2a6a68814e72 04 Bun's unreleased Rust port has 13,365 unsafe blocks. Most can be removed. https://bun.com/bun-unsafe-audit 05 Stripe: Claude Fable 5 Compressed Months of Engineering into Days on a 50-Million-Line Migration https://claude5.ai/en/news/stripe-claude-fable-5-50-million-line-migration-one-day Appendix — 参考リンク