Furigana - もう漢字で立ち止まらない

• 日本語を学んだことがある方なら共感していただけると思いますが、日本語の文章を読むうえで最大の壁となるのが漢字です。Furiganaは、文脈に合った適切なふりがなを自動で付けることを出発点に、最終的には、日本語を読むときに感じる心理的な負担を、コンテンツへの興味や期待感に変えていきたいと考えています。日本のドラマやアニメを楽しみに観るように、日本語の文章そのものを自然に楽しめる学習体験を提供することが目標です。
• ふりがなを自動生成するツールはすでに存在し、私自身も必要に応じて使ったことがあります。しかし、辞書に載っている読み方だけに頼っているため、文脈に合わない読み方が表示されることが少なくありませんでした。大規模言語モデル(LLM)を活用すれば、こうした問題を比較的簡単に解決できるのではないかと思いました。

• 当初はLLMを使えば簡単に実現できると考えていましたが、さまざまな文脈に応じて自然なふりがなを生成するのは、想像以上に複雑でした。試行錯誤を重ねながら、モデルが最も力を発揮できる指示の出し方や文脈の範囲を検証し、前処理・後処理によって精度を高めるなど、取り組むべきことが数多くあります。モデルの進化も速いため、今後も続くこの改善プロセスをいかに効率よく運用していくかを模索しています。
• ユーザーに継続して良い読書体験を提供するために、最も重視しているのは質の高いコンテンツの確保です。この目標に共感してくださる日本のクリエイターの方々と協力し、オリジナルのコンテンツライブラリの構築を進めています。教育目的の学習教材ではなく、クリエイター独自の視点が反映された個性豊かな文章を提供したいと考えています。また、ユーザー自身も参加者として自分の文章を投稿できる、コミュニティ型のコンテンツプラットフォームを目指しています。

• 漢字で立ち止まることなく、日本語を読みたい

AI Filmmaking

• AIを活用することで、ストーリーテリングの質が高い映像作品をどこまで制作できるのか、実験を重ねています。AIはあくまでも制作過程におけるツールとして活用し、完成した作品ではAIそのものが前面に出ることなく、観る人に楽しさや感動、そしてメッセージを届けられるような、作家主義的な映像制作を目指しています。

• オリジナル脚本の執筆と、AIを活用したプリビズのワークフロー構築に力を注いでいます。近い将来、短編映画やドラマという形で作品をお届けできるよう、準備を進めています。

AI Meeting Cheat-sheetの企画・開発

• Yessの主なターゲット顧客は、エージェンシーやスタジオなど、サービスを提供する企業です。こうした企業が案件を受注するまでの過程で直面する実際の課題を深く掘り下げ、機能の企画・開発に取り組みました。

• 一定期間、エンジニアと企画担当者の区別なく、チーム全員でプロダクトの企画に取り組みました。その中で、顧客は営業プロセスの初期段階にあたるミーティングの準備に最も多くの時間を費やし、それだけ大きな負担を感じているのではないかという仮説を立てました。そして、顧客インタビューを通じて、これが実際の課題であることを確認しました。この課題を解決するため、Meeting Cheat-sheetという機能を構想し、自らローファイのワイヤーフレームを描きながら企画を進めました。
• AIからリアルタイムに受け取るデータを、シームレスなストリーミングUI/UXとして提供するため、さまざまな技術的アプローチを試しました。既存のテキストエディタやWebSocketライブラリへの依存があったため、複雑さを切り離した環境で検証することが役立ちました。チームメンバーとハッカソンに参加してVercel AI SDKを試したり、RxJSを使って独自のストリーミングモジュールを実装したりしました。しかし、実際のプロダクトに組み込むと、依然として複雑さが増し、動作の一貫性も確保できませんでした。そこで、レスポンスにストリーミング用のカーソル位置情報を含めるサーバー主導の方式を提案しました。チームでの議論を経て、サーバーとクライアント間のWebSocketライブラリ層でこの処理を行う折衷案を採用し、改善を進めました。

• Meeting Cheat-sheetをきっかけに、プロジェクトの文脈分析、ミーティングの要約、提案書の生成など、顧客の営業プロセスを支援する主要な機能が企画されました。これらの機能が組み合わさることで、Yess 1.0のAI Sales Copilotが完成しました。同じ領域にはすでに大規模なサービスが存在していましたが、AIネイティブの最初のプレーヤーとしてYessを世に送り出すための基盤となりました。
• 企画段階で最も重視したのは、顧客が実際の業務で本当に必要とするUXとは何かを考えることでした。機能のネーミングも、こうしたアプローチから生まれたアイデアです。

• AIを扱ううえで、UXの目標を明確に定義することの重要性を学びました。AIストリーミングの実装方法はさまざまですが、実装の難易度や複雑さだけで選ぶのではなく、実現したい体験を基準に選ぶほうが、結果的に時間の節約につながります。AI自体もあくまで手段の一つであるため、目標を細分化し、本当に必要で役立つ場面に適切に活用することが重要だと考えています。

• AI Sales Copilotの開発記録 — (1) 企画するエンジニア
• AI Sales Copilotの開発記録 - (2) Streaming Queue
• AI Sales Copilotの開発記録 - (3) Delta-Driven UI

デザインシステムの構築・改善

• デザインシステムは、Webアプリ全体で一貫性のある直感的なUI/UXを提供し、ユーザーが少ない学習コストでプロダクトを使いこなせるようにするために欠かせないものだと、チーム全員が認識していました。
• デザインシステムは品質と開発スピードを両立させるための仕組みでもあります。毎週新しい機能を実装する場合でも、デザインシステムがカバーする範囲であれば、細かな設計に悩むことなく一定の品質を確保できます。既存のコンポーネントを再利用することで、個別に設計・実装する手間も省けます。

• Material Designを参考にデザイントークンを定義しました。主要なコンポーネントについては、ヘッドレスUIライブラリであるRadix Primitivesを活用して基本的な動作を実装し、スタイルは独自にカスタマイズしました。
• コンポーネントを導入する順序についても検討しました。最初は、Webアプリ内のすべてのボタンを新しく開発したコンポーネントに置き換える作業を試みました。この方法ではデザインの一貫性を確保できる一方、作業に時間がかかりすぎるという課題がありました。そこで次の段階では、特定のコンポーネントを一斉に置き換えるのではなく、ユーザーがWebアプリにアクセスして最初に目にする第1階層のページを優先して、デザインシステムを適用しました。
• メンテナンスの過程では、コンパウンドコンポーネントパターンを応用し、再利用性と使いやすさを改善しました。

• デザインシステムの導入後、デザイン案をUIとして実装する作業の効率が向上しました。スタイルに関する不要なコミュニケーションが明らかに減り、新しい機能を追加する際にもUIのばらつきを抑えられるようになりました。
• 優先順位を考慮し、重要な部分から段階的に適用することで、比較的短期間で多くの改善を実現できました。

• 職種を問わず、チーム全体でデザインシステムに対する考え方や認識をすり合わせていく過程は、とても有意義な経験でした。特に、デザインの意図とコードによる実装の間にずれが生じないよう、全員が同じ認識を持っているかを継続的に確認することの重要性を学びました。
• デザインシステムは、最初に構築すること以上に、継続的な改善とメンテナンスが重要です。そのため、不要なコミュニケーションは最小限に抑えつつも、より成熟したシステムへと発展させるには、チームメンバーによる積極的なレビューと地道な改善の積み重ねが欠かせません。

• コンパウンドコンポーネントパターンを応用してデザインシステムを改善する

新しいエディターライブラリの段階的な導入

• ドキュメント編集はYessのWebアプリにおける最も重要な機能の一つであり、エディターライブラリへの依存度が高い状態でした。従来使用していたQuillは、メンテナンスやアップデートの進みが遅く、カスタマイズの柔軟性にも欠けていたため、過去に作成したフォーク版の上にさまざまな機能が追加されていました。その結果、通常のバージョンアップによる恩恵を受けにくい構造になっていました。さらに、フォーク版のコードは厳密な型付けがされておらず、機能を迅速かつ安定的に開発するうえでの障壁となっていました。今後、生成AIの導入によって、よりインタラクティブな要件への対応が求められることを考えると、新しいエディターライブラリの導入が必要だと判断しました。

• ProseMirrorをベースとしたエディターライブラリであるTiptapを検証対象に選び、複数回にわたってPoC(概念実証)を実施しました。難しい課題に取り組む際の心理的な負担を減らすため、通常のスプリントの範囲外でペアプログラミング形式で進めました。
• PoCの後、実際のスプリントでWorkflow Automation機能のメール本文エディターを実装するため、Tiptapを部分的に導入しました。予期せぬ問題が発生した際には、ProseMirrorのデータ構造を十分に理解できておらず、解決に苦労することもありました。しかし、チームメンバーの助けを借りながら一緒にトラブルシューティングを進めることで、新しいライブラリの学習の壁を乗り越えることができました。

• 比較的シンプルな機能から部分的に導入したことで、その後のコア機能に関するPoCにも、以前ほど負担を感じずに取り組めるようになりました。もし最初から新しいエディターで同時編集やAIストリーミングを実装しようとしていたら、未知の要素があまりにも多く、導入に踏み切ることは難しかったと思います。
• 編集可能な領域に関する新たな機能要件が出てきた際にも、迅速に試せるようになりました。従来のQuillベースのモジュールしかなかった頃とは異なり、型安全性が高く、開発者体験にも優れたTiptapという選択肢が加わったことで、適用範囲を段階的に広げています。

• 学習のハードルが高くても、チームの力を借りて一緒に取り組めば、よりスムーズかつ短期間で乗り越えられることを学びました。他人の助けに頼るだけでなく、自分自身で努力することも大切ですが、本当に助けが必要なときには、積極的に相談することも同じくらい重要です。また、助けを求める際には、問題についてこれまでに把握したことと、これから解決すべきことを明確に整理して伝える必要があると感じました。

• 新しいWYSIWYGエディターライブラリの導入プロセス

Widget SDKのパフォーマンス改善

• Yessでは、ユーザーが自分のWebサイトにコードスニペットを埋め込むことで、顧客からの問い合わせ窓口を設置できるJavaScriptウィジェットSDKを提供しています。しかし、ウィジェット内で顧客からの問い合わせを受け付けるInquiry Formは、初回表示までに約5秒かかるという問題がありました。ロード時間をほとんど感じさせない、非常に高速なユーザー体験を実現するため、パフォーマンスの改善に取り組みました。

• ウィジェットが最初に開発された当時、Inquiry Formは独立したサービスとして提供されていたため、公開されているInquiry FormのURLをiframeで埋め込む形で実装されていました。しかし、ウィジェットSDK自体もiframe内で動作していたため、iframeが入れ子になり、追加のネットワークリクエストが発生していました。
• ネットワークの応答速度を改善することも選択肢の一つでしたが、より根本的な解決策を検討した結果、モノレポへの移行を決めました。Yessは垂直特化型SaaS(Vertical SaaS)であり、独立したサービスとして動作しながらも、互いに機能や依存関係を共有する可能性のある機能を複数備えています。こうしたプロダクトの特性を考慮し、それまで別々のリポジトリで管理されていたWebアプリとウィジェットを、一つのモノレポに統合しました。

• 複数のアプリがビルド時に互いを参照できる環境が整い、ウィジェット内のInquiry Formで発生していた追加のロード時間を解消できました。また、モノレポ構成が定着したことで、共通コードの管理が容易になり、既存の共通コードを活用して新しいアプリを構築し、デプロイ環境を整えることも簡単になりました。

• ある程度の規模があるレガシーコードベースに対して、根本的なアーキテクチャの変更を加える作業だったため、地道な作業と予期せぬビルドエラーへの対応の連続でした。しかし、「ロード時間をほとんど感じさせない高速な体験を提供する」という明確な目標があったからこそ、それらを必要なプロセスとして受け止め、チーム全員で取り組むことができました。また、理想のユーザー体験から逆算して考える「Working Backwards」というアプローチは、開発戦略を提案し、チームの合意を得て実行するうえでも有効であることを学びました。

• 顧客体験から逆算して実装方法を考える

パートナー向けサービスのエラーハンドリング改善

• パートナー向けサービスは、初期開発以降、十分なメンテナンスが行われておらず、開発の経緯を把握することが難しい状態でした。また、コードの複雑さや柔軟性の低さから、新しい機能を実装する際にも多くの困難がありました。今後のパートナー関連プロジェクトで発生するボトルネックを最小限に抑えるため、最も優先度が高いと考えたエラーハンドリングの改善に取り組みました。

• 既存のサービス機能に影響を与えずに、大規模な変更を加える必要があったため、さまざまなユースケースの検証や、問題が発生した際の防御策を慎重に検討しながら進めました。
• パートナー関連の開発を担当するチームメンバー2名に声をかけ、役割を分担して取り組みました。その一方で、定期的に議論の場を設け、積極的にコードレビューを行いながら、実装の一貫性を確保しました。

• 従来のパートナー向けサービスには、API通信の失敗やJavaScriptエラーが発生した際に、適切に対処するための仕組みがありませんでした。エラーハンドリングを改善したことで、想定可能な例外の標準化と、予期せぬエラーが発生した際のUIの防御的な処理が可能になりました。また、本番環境で発生するエラーを追跡できるツールを導入し、ユーザー体験と開発者体験の両方を改善しました。

• エラーハンドリングはどのようなサービスにも必要な仕組みであるため、共通化できる部分とビジネスロジックに依存する部分を切り分け、それぞれを改善していく貴重な経験になりました。
• 自ら課題を見つけて積極的に解決に取り組み、共通の目標に向かって協力できる仲間を集め、主体的にプロジェクトをマネジメントする経験を積むことができました。

• レガシーコードから始めるエラーハンドリング

宿泊・交通領域の開発を担当

• ガイドツアーを主力とするMyRealTripのサービス多角化に向けて、宿泊・交通領域を担当し、さまざまなプロジェクトに取り組みました。
• 担当領域のコードベースを安定させるため、技術的負債の解消にも注力しました。

• ECにおける主要なプロセスである商品検索と予約のうち、商品検索を担当し、主体的に開発を進めました。レンタカーサービスの内製化、全国規模の宿泊キャンペーン「대국민 숙박대전」の特設ページ制作、国内宿泊施設向けサービスの全面的なリファクタリング、宿泊施設パートナー向け機能の改善などに取り組みました。
• レガシーと呼ばれていた2.0のコードベースから、改善された3.0への移行を進め、宿泊・交通領域のすべてのプロダクトを新しいコードベースで実装しました。3.0では、TypeScriptを採用して安定性を高め、サーバー側の状態とクライアント側の状態を分離することで複雑さを軽減しました。新たにチームで合意した開発規約を適用し、改善されたコードベースを担当領域全体に定着させました。

• レンタカーサービスはリリース後、急速に実績を伸ばし、1日の取扱高1億ウォンを達成しました。サービスの指標をモニタリングする中で、モーダルを閉じる際に意図しないページ遷移が発生し、決済コンバージョン率に影響していることを発見しました。そこで、モーダルのスタックをブラウザの履歴に保存する仕組みを実装し、決済コンバージョン率を3%向上させました。
• 老朽化していた全国規模の宿泊キャンペーンページと国内宿泊施設向けサービスを全面的にリファクタリングし、保守性と拡張性を改善しました。特に、URLのクエリパラメータが失われることでユーザーに不便を与えていた問題を解消し、顧客体験とサービス運営の両面で改善を実現しました。

• 短期間でビジネス上の成果を出しながらも、コードの品質を犠牲にしないためには、どのような開発プロセスが必要なのかを考えるきっかけになりました。単に機能を実装するだけでなく、保守性や拡張性を考慮し、開発者自身によるテストを重視することの大切さを学びました。
• 同じ領域を担当するチームメンバーと協力しながら、タスクやスケジュールの管理を担った際には、自分自身の開発に充てられる時間が減ってしまい、マネジメントの難しさを実感しました。効率よく業務を分担するためには、目標を細分化し、優先順位を明確にすることが重要だと学びました。

• ロジックを分離するか、しないか。その判断基準について

画像管理ツールの開発

• ポップアップ画像やアイコンなど、サービス開発に必要なさまざまなアセットのアップロードは、フロントエンドエンジニアが手作業で行っていました。そのため、簡単なアセットの変更であっても、企画担当者やデザイナーからチケットで依頼を受け、エンジニアが対応するという手間のかかる作業が繰り返されていました。このプロセスを簡略化するため、生産性向上ツールを開発しました。

• 必要な人が誰でもFigmaのデザインデータから直接アセットのURLを取得できるよう、Figmaプラグインとして実装しました。
• さらに、Figmaプラグインに加えて、より拡張性が高く、幅広い機能を提供できるWebベースの画像管理ツールも開発しました。

• これにより、エンジニアが手作業でアップロードする必要がなくなり、依頼者もチケットの作成や進捗管理を行う必要がなくなりました。
• アップロードに必要な情報をプログラムで管理することで、従来の手作業に比べて、アセットをより一貫性のある効率的な方法で管理できるようになりました。

• 手作業で繰り返される業務に不便さを感じたとき、自ら自動化の方法を考え、主体的に実装する経験ができました。
• Figma APIとの連携を通じて、プラグインの有用性と、そうした拡張性を提供するプラットフォームの重要性を実感しました。特に、FigmaのキャンバスデータをpostMessage経由で受け取る実装では、異なるJavaScriptの実行環境間で安定した通信を実現する方法について考えるきっかけになりました。

メールコンテンツエディターの開発

• メールマーケティングSaaS「VARY」は、顧客一人ひとりにパーソナライズされたメール体験を提供することで、マーケティングの効果を高めるサービスです。メール体験においては、質の高いコンテンツを制作することも重要ですが、専任のデザイナーやエンジニアがいない企業では、コンテンツ制作に課題を抱えることがあります。そこで、デザイナーやエンジニアがいなくても質の高いコンテンツを制作できるよう、メールエディターを開発しました。

• ブロック単位でコンテンツの内容やデザインを作成・参照・更新・削除(CRUD)できるようにし、Undo・Redoやプレビューなど、エディターの基本機能を実装しました。また、ブロックのデータ構造を統一することで、JSXやメール用マークアップなど、用途に応じた表示形式を動的にレンダリングできるようにしました。
• 状態管理にはReduxを採用し、非同期通信が必要な処理にはRedux-Observableを使用して、リアクティブストリームとして処理しました。データの永続化はメインプロダクトのAPIに委ね、フロントエンド単体で動作するスタンドアロンアプリとして実装しました。

• 既存のメールエディターを参考に改善点を洗い出し、直感的に操作できるUIを実装した結果、使いやすさについてユーザーから好意的なフィードバックを得ることができました。
• エディターをサービス内に組み込むことで、ユーザーが途中で外部ツールに移ることなく、メールマーケティングの一連のプロセスを完結できるようになりました。

• すべてのデータを一元的なグローバルステートで管理していたため、複雑さが増し、パフォーマンスの低下が発生しました。この経験を通じて、グローバルな状態管理に伴うリスクを意識するようになりました。
• 当初選定したWYSIWYGライブラリに重大な問題があり、別のライブラリへ置き換える経験をしました。このことから、ライブラリを導入する際には、メリットやデメリットを十分に把握し、実際に検証したうえで採用することの重要性を学びました。
• メール用マークアップ特有の制約を理解し、最新のWeb技術を利用できない環境でレスポンシブなレイアウトを実装する経験を積みました。

• ReduxとReact Context APIを併用する
• WYSIWYGエディターの選び方
• プロジェクトのフォルダ構成の変化、変更した理由、そして学んだこと

メインプロダクトの開発

• メールマーケティングサービスを迅速にリリースするためには、さまざまな機能や仕組みを整える必要がありました。その中で、メール配信管理、受信者管理、アカウント管理などの主要なページの開発に携わりました。

• 開発効率を高めるため、デザインシステムを構築しました。Styled Systemをベースにコンポーネントを設計・構造化し、Storybookを活用してテストやドキュメントの整備も行いました。
• 少人数の新規事業開発チームだったため、エンジニアも企画段階から積極的に参加し、意見を出し合いながら、プロダクトの開発と改善をスピーディーに繰り返しました。

• メールエディターとメインプロダクトの開発を1年以内に完了し、サービスをリリースすることができました。また、実際のユーザーから、より効果的にメールマーケティングを行えるようになったというフィードバックをいただきました。
• 個人的には、初めて実務で開発を担当したサービスだったこともあり、ゼロから多くのことを学び、エンジニアとして大きく成長するきっかけとなりました。

• デザインシステムを最初に構築した後も、継続的にリファクタリングを行い、より再利用性の高いコードへと改善しました。その過程で、コンポーネントのインターフェースを通じて外部に委ねるべき責務と、デザインシステムの内部で担うべき責務を区別することを学びました。
• 一般的なWebサービスで使用されるUIコンポーネントには、どのような仕様や機能が求められるのかについても理解を深めることができました。