はじめに LIFULLにて基盤グループのマネジメントをしている磯野です。 2025年8月28日に開催された「 Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update 」に参加し、LIFULLでの活用事例について発表させていただきました。 当日は株式会社マイナビ様の事例発表もあり、他社での活用状況を知ることで多くの共通点や共感できる部分がありました。また、懇親会では各社の担当者の方々と直接お話しでき、様々な活用方法や課題について情報交換することができ、今後更にいろいろ試せそうで非常に有意義な時間を過ごさせていただきました。 本記事ではイベントで発表した内容をもとに、Amazon Q Developerの導入から社内展開、そして多職種での活用事例について、LIFULLでの実践例をご紹介します。エンジニアだけでなく、サービス企画やデザイナーまで幅広い職種で活用が広がっている現状と、その具体的な事例をお伝えします。 はじめに 導入から拡大まで 導入のきっかけ 拡大戦略 1. 草の根で広げる 2. 波に乗る 現在の利用者数 事例紹介① スライド作成自動化 課題：スライド作成の効率化 解決策：HTMLスライドの生成 HTMLスライドのメリット 自動化ワークフロー 事例紹介② サービス企画・PMでの活用 1. プロトタイプ作成 社内への影響 2. 施策のアイデア出し 設定するコンテキスト 制約条件ドキュメントの育成プロセス 3. 効果測定レポート自動化 Before vs After 品質向上への取り組み その他の活用事例 社内MCPサーバー Qランキング ローカルMCP 通知機能 社内AIサービスとの連携 プロジェクト専用エージェント設定（検証段階） エージェント用設定ファイル 起動方法 実際の動作例 デザイナーでの活用（検証段階） プロトタイピング サービス改善 まとめ 導入から拡大まで 導入のきっかけ 昨年10月から今の部門のマネジメントを任されており既存の課題である対応スピードの改善を主要なミッションの1つとして持っています。 とくに、LIFULL HOME'Sの主要サービスのAWSアカウントやそこで動くインフラの管理をしている関係で、自動化やIaCの推進をしてくことが急務だったため、AIエージェントを活用していきたいと考えていました。 具体的には以下のようなことを意識して選定しています ほとんどコードを書かない基盤グループでCDKでの開発を推進する CLIでの作業が基盤グループの業務にマッチしていた AWSコンソールや認証への統合など、AWS環境との親和性が高い 利用していく中で、開発だけでなく調査や分析もLinuxコマンドを活用しながら処理でき、想像以上に便利だったため、「これはイケる！」という手応えを感じました。 拡大戦略 その手ごたえを受けて、もっと広く活用してもらえるのではないかと考えた結果、 Amazon Q Developerの社内展開を以下の2つのアプローチで進めました： 1. 草の根で広げる 近くのエンジニア部門のマネージャ、リードエンジニアに自分の使っているところを見せて使ってもらう 乗り換えを受け入れられるように予算・登録・利用方法を整備する 2. 波に乗る Qのアップデートを積極的に取り入れる MCP対応 / Claude Sonnet 4対応 企画の検証の1つとして使ってもらう この草の根 + 波に乗る戦略により、利用者が着実に拡大していきました。 特にマネジメント層が前向きに導入を進めてくれた部門では部門の総会などで活用事例を共有してくれるなど周りの後押しにも支えられています。 また、Q自体のアップデートのタイミングも本当に素晴らしく、ほしいときに欲しい機能がリリースされてくれたため強い後押しになりました。 導入検証開始 → Q CLIがmcpに対応 エンジニア全体に拡大開始 → Q CLIがClaude Sonnet 4に対応 サービス企画の導入検証開始 → 上記2つがIDE版に対応 直近ではエージェントの作成機能が追加されるなどまだまだ追加されるものは多く、今後にもとても期待しています。 話が少しそれてしまいますが、個人的に最近のアップデートで最高だったものはログインのawscliへの統合です。 これによりQへのログインはせずにAWSにログインするだけで利用できるため、朝のログイン作業が劇的に楽になりました。 # 環境変数を設定 export AMAZON_Q_SIGV4=1 export AWS_PROFILE=[プロファイル] # AWS SSOでログイン aws sso login # Q Chatを開始 q chat 現在の利用者数 現在ではエンジニアを中心にサービス企画やデザイナーなどに浸透し、その範囲においては9割以上のメンバーが登録済みの状態です。 ここから先は当日発表した事例についての説明です。 当日はスライド自動作成はLIFULL HOME'Sの流通領域のエンジニアチームにてマネジメントをしている渡邉から、サービス企画・PMでの活用事例はパーソナライズやレコメンド機能などのPMをしている井上から発表させていただきました。本記事は私が取りまとめて執筆しています。 事例紹介① スライド作成自動化 課題：スライド作成の効率化 管理職になってスライド作成機会が激増する中で、以下の課題を抱えていました： デザインに自信がない 細かい調整が苦手 時間がかかりすぎる 従来は4時間かけてPowerPointと睨めっこしていたのが、Amazon Q Developerを使うことで数分で完成するようになりました。 解決策：HTMLスライドの生成 最初はpptxをAIに作らせようと考えましたが、「伝える」上でフォーマットにこだわる必要はないと気づき、 Amazon Q DeveloperにHTMLでスライドを生成してもらう アプローチを採用しました。 HTMLスライドのメリット コードブロック対応 : スクローラブルなデザイン、コピー機能付き Git管理 : バージョニングが容易、チーム共有も簡単 高い自由度 : デザインや画面幅の制約が少ない、レスポンシブ対応 統一感 : GUIDELINE.mdで自動適用、再現性のあるデザイン 自動化ワークフロー GUIDELINE.mdで定義された3ステップで自動化を実現： アウトライン生成 : README内容を読み解いてOUTLINE.md作成 スライド生成 : アウトラインを元にHTMLスライド作成 ファイル出力 : 絶対パスで表示、ブラウザ確認可能 実際に今回のスライドも5分程度で生成することができています。 例えば、"自動化ワークフロー"の実際の生成されたページは以下のようになっています。 自分でパワーポイントでやってもできる自信はないです。 HTMLでのスライドの為ここに貼れないのが残念ではありますが、スライド作成についての詳細は以下を是非ご覧ください www.lifull.blog 事例紹介② サービス企画・PMでの活用 1. プロトタイプ作成 DeNAさんが企画書にプロトタイプを必須化というニュースにインスパイアされ、早速トライしたところ、 1時間程度でかなり良いプロトタイプが完成 しました。 社内への影響 「企画でもプロトタイプが作れる！」というインパクトから利用者が急増し、以下の効果が生まれました： プロトタイプを作成するプロジェクトが 増加中 従来の企画書・仕様書に代わる 新しいコミュニケーション手段 として定着 デザイナー・エンジニアとのコミュニケーションが 格段にスムーズ に 「動くもの」で認識合わせを行うことで、認識齟齬を大幅削減できています。 2. 施策のアイデア出し ChatGPTなどでもアイデア出しは可能ですが、コーディングエージェントのメリットは コンテキストの活用 です。 設定するコンテキスト プロダクトの概要・ターゲットユーザー・仕様など 技術的制約、予算制約、時間制約などの 制約条件（特に重要） 制約条件がないと実現性度外視のアイデアばかりが出てくるため、 制約条件の提供がアイデア精度向上の鍵 となります。 制約条件ドキュメントの育成プロセス 実践的な3ステップで制約条件ドキュメントを育成： まずAmazon Q Developerにアイデアをたくさん出してもらう 「◯◯という理由でできない」を逐一伝えていく 「今回伝えた制約条件をドキュメントにまとめておいて」 制約条件ドキュメントを育てることで、かなり精度の高い（ハズレの少ない）アイデア出しができています。 3. 効果測定レポート自動化 Before vs After 従来の作業プロセス（半日〜1日の手作業） - データの抽出 - 分析・考察の作成 - ネクストアクションの検討 - 他の人に読みやすく整理 Amazon Q Developerで効率化（1〜2時間で完結） - データをテキストで貼り付け - 自動で分析・考察を生成 - 次の施策案も自動提案 - MCP経由で直接投稿 結果として、 80%の作業時間削減 を実現しています。 品質向上への取り組み 初回から完璧な結果は得られないため、以下の問題に対処： 問題1 : 事実と推測が混在、推測を事実かのように断言 問題2 : 根拠の低い、説得力のない仮説を立ててくる 問題3 : ネクストアクション（施策）が10個以上出てきて絞り込めない 逐一修正指示を行い、その内容を ルールとして蓄積 し、次回以降の効率化につなげています。 その他にも企画業務全般で活用が広がっています。さらなる生産性向上に向けて、企画職全体で取り組みが進んでいます。 その他の活用事例 以上が主な活用事例ですが、他にも社内では活用していくにあたっていろいろと進めていますので簡単な事例として紹介させてもらいます。 おそらく各担当が今後ブログなどで記事を作成してくれると思います。 社内MCPサーバー 社内システムとの連携を実現するMCPサーバーを構築し、Amazon Q Developerから直接社内システムにアクセスできる環境を整備しています。 インストール型ではなくサーバーで稼働させることで職種の隔てなく簡単に導入できるようになっています。 具体的なシステムとしては Jira/Confluence, データベースのテーブル定義情報などです。 Qランキング 利用状況の可視化と競争要素の導入により、利用促進を図っています。 ランキング出力部分もAmazon Q Developerに指示して作成してもらっているので、こういった活用により自分のランキングもかなり上位になっています。 (TOP3には入れるんですが1位にはなれないのでまだまだ活用が足りないようです） ローカルMCP 通知機能 タスク完了の通知をMCP経由でOSの通知に送信 通知でも弱いのでOSの音声再生に送信 ※Qの処理時間が長くなると忘れてて20分後に通知がくる場合があって、MTG始まってたりするとざわつくので最近止めてます 社内AIサービスとの連携 使い道は模索中 将来的な拡張性を見込んだ基盤構築 開発者体験の向上を追求しています。 プロジェクト専用エージェント設定（検証段階） 最近追加されたエージェント機能により、開発だけでなく、調査や運用でも活躍できる特化エージェントを設定できます。手順書があれば細かいコードを書かなくてもエージェントが助けてくれる環境を構築中です。 以下は最近作ってみた「静的サイトをS3+CloudFrontで公開するためのエージェント」の例です。 エージェント用設定ファイル 基盤グループで稀に発生する静的サイトの公開をエージェントでできるようにしています。 もともとはエージェント関係なくQ用にコンテキストを作成していたので、エージェントはこのファイルを読み込む設定をしただけで数分で完成しています。 定義ファイルを簡単に記載しつつ、詳細なコンテキストは別ファイルとして渡しています。 起動方法 設定ファイルに指定した名前を指定してプロジェクト内で起動します。 実際の動作例 このように手順書やAI用のコンテキストがあれば、簡単に特定機能に特化したエージェントを作成できるので可能性は無限大だと思います。 事例1で紹介したプレゼンテーション作成のエージェントも今後はリポジトリ上でエージェントとして管理していけるように調整中です。 デザイナーでの活用（検証段階） まだこれからの段階ですがデザイナーでもPMでの活用をうけて検証を開始しています。 それによりAIを活用し素早いユーザー価値提供を目指しています。 プロトタイピング HTML/CSSでプロトタイプ作成 簡単な動作確認 FigmaとのMCP連携 サービス改善 企画からデザインのガイドライン化 企画から直接HTMLへ反映 デザインプロセスの省力化 まとめ Amazon Q Developerは、コーディングだけではなく、 設計からタスク定義、そしてエンジニア以外の生産性を革新的に向上させるプラットフォーム として機能しています。 LIFULLでは、エンジニアから始まった活用が、サービス企画、デザイナーまで広がり、各職種の特性に合わせた活用方法を見つけることで、組織全体の生産性向上を実現しています。 今後もさらなる活用を目指し、新しい可能性を探求していきます。 ※本記事はスライド用HTMLを出力する前のmarkdownファイルをもとにQ CLIでブログ用に出力し手動で整形して提供しています。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。プロダクトエンジニアリング部の江口です。主に賃貸部門の開発を担当しています。 このたび、LIFULL HOME'Sの賃貸詳細ページにおけるサーバーサイドの処理速度を改善し、 99パーセンタイルを60%改善しました 。 本記事では、このパフォーマンス改善をどのように実現したのか、具体的な技術的アプローチについて解説します。 背景 分析から見えたパフォーマンスボトルネック 改善のためのアプローチ 成果 終わりに 背景 サーバーサイドの処理遅延は、ユーザー体験だけでなく収益にも悪影響を及ぼします *1 。特に、平均処理時間は良好でも99パーセンタイル（p99） *2 が高い場合、一部のユーザーは大きな遅延に遭遇し、不満を感じてサイトから離脱してしまいます。そのため、p99を改善することは離脱率の低下に直結し、長期的には収益にも良い影響をもたらします。 こうした課題は多くのWebサービスで共通していますが、LIFULL HOME'Sの賃貸詳細ページでも例外ではありませんでした。詳細ページのサーバー処理時間のp99は、平均値と比較して大きく遅延している状態でした。 賃貸詳細システムにおけるサーバーサイド処理時間の比較 そこで、詳細ページにおけるボトルネックを特定し、p99の改善活動に取り組みました。 分析から見えたパフォーマンスボトルネック まず、アプリケーションのメトリクスやトレースから、ボトルネックとなっている処理の特定を試みました。分析を進める中で、特に以下の点が明らかになりました。 計測不能な処理時間の存在 ： トレースのスパンとして計測されない、実体の不明な処理に時間がかかっている箇所が見られました。 イベントループの遅延 ： 最大1秒にも及ぶイベントループの遅延が判明しました。これは、他のリクエスト処理もブロックし、サービス全体の応答性能を低下させる要因となりえます。 賃貸詳細システムのトレース イベントループの最大遅延（秒） これらのデータから、イベントループのブロッキングがアプリケーションロジックに起因する可能性が高いと判断しました。そこで、CPUの使用状況とメモリ消費を継続的に監視できるPyroscope（継続的プロファイラ）を導入し、詳細な調査を開始しました。Pyroscopeによる継続的プロファイリングの結果、イベントループのブロッキングとCPU占有を引き起こしていた可能性のある処理を見つけることができました。 URLエンコードの同期的な高負荷処理 ： APIへのリクエスト送信前に、特にセッション情報のような長い文字列をURLエンコードする処理が、同期的に実行されていました。この処理はCPUを長時間占有することで、イベントループをブロックし、アプリケーション全体の応答性を低下させる要因となる可能性があります。 セッション情報のデシリアライズ ： バックエンドAPIから取得するセッション情報は、PHPのシリアライズ形式で格納されています。このPHP形式のデータをアプリケーションで利用可能な形式にデシリアライズする処理もまた、CPUを大量に消費する同期処理でした。この処理がイベントループをブロックし、パフォーマンスの低下につながる可能性がありました。 同期的なサーバーサイドレンダリング ： 賃貸詳細システムのHTMLレンダリングにはPreactを使用しています。サーバーサイドレンダリング（SSR）の際、tsxデータから仮想DOMノードを生成し、それをHTML文字列に変換する処理が同期的に実行されていました。この一連の処理はCPUを長時間占有することで、他のリクエスト処理の応答性を阻害する要因となりえます。 これらのボトルネックは、いずれも同期的な高負荷処理が原因でイベントループをブロックし、アプリケーション全体のパフォーマンスに影響を与えていたと考えられます。これら以外にも多数のボトルネックが存在しますが、代表的なものは上記の3点でした。 改善のためのアプローチ イベントループのブロッキングを抑制する一般的なアプローチとしては、CPUバウンドな処理の高速化やWorker Threadsへの処理のオフロードなどがあります。 試行錯誤の結果、URLエンコードの同期的な高負荷処理がイベントループをブロッキングする主要な原因の一つであることが判明しました。この処理を、外部ライブラリの qs からネイティブのURLSearchParamsに置き換えることで、イベントループのブロッキングが大幅に改善されました。特に、大規模なクエリパラメータを処理する場合、URLSearchParamsはqsと比較して最大で4倍以上高速に処理できることが確認できました。 // 変更前（qs） private convertQueryString(param: object) { return qs.stringify(param, { sort : ( a : string , b : string ) => { return a. localeCompare (b); } , arrayFormat : 'comma' , } ); } // 変更後（URLSearchParams） private convertQueryString(param: Record< string , unknown >) { const urlSearchParams = new URLSearchParams (); const sortedKeys = Object . keys (param). sort (); for ( const key of sortedKeys) { const value = param[key]; if (value == null ) continue ; if ( Array . isArray (value)) { urlSearchParams. append (key, value. join ( ',' )); } else { urlSearchParams. append (key, String (value)); } } return urlSearchParams. toString (); } URLSearchParamsに修正後の最大イベントループ遅延 この変更によって高速化できた理由は、主に「ネイティブ実装との速度差」と「処理のオーバーヘッド削減」にあります。 まず、URLSearchParamsはNode.jsにC++等で実装されたネイティブAPIであり、最適化されたマシンコードで極めて高速に動作します。対照的にqsはJavaScriptで実装されているため、実行速度に根本的な差が生まれます。さらに、qsはネストされたオブジェクトなど複雑なケースに対応する汎用的なライブラリであり、その分、内部には多くの条件分岐といったオーバーヘッドが含まれます。今回の実装は、必要な処理に特化してネイティブAPIを直接呼び出すため、こうしたオーバーヘッドが一切ありません。 これらの要因が組み合わさり、CPUを占有する同期処理の時間が劇的に短縮され、イベントループのブロッキングが解消されたと考えます。 成果 上記のURLエンコード処理の高速化のリリースによって、p99を60%改善することができました。 サーバーサイド処理時間（p99）の改善 終わりに 今回のパフォーマンス改善は、可観測性の向上を目指すところから始まりました。メトリクスや継続的プロファイリングツールの導入だけではなく、必要に応じて手動でスパンやメトリクスを追加することで、p99の高さを生み出す根本原因をデータから特定しました。 また、既存ライブラリが自分たちのユースケースにマッチしているか検証する重要性も再認識しました。汎用的なライブラリがパフォーマンスのボトルネックとなる場合があり、ネイティブAPIのような特化した代替手段を検討することで、劇的な改善につながることがあります。 ウェブアプリケーションの速度改善は、まるで謎解きのようです。メトリクス、トレースデータ、ログといった手がかりを丹念に観察し、パフォーマンスのボトルネックを特定していく作業は、個人的にとても楽しい時間です。そして、改善策を適用した結果、システムのレスポンスタイムが向上したり、プロファイルデータが変化したりするのを直接データで確認できるのは、何よりも魅力的だと感じています。 これからも、ユーザーの皆さんにより快適な体験を提供できるよう、システムのパフォーマンス改善に情熱を持って取り組んでいきたいです。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co *1 : https://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html *2 : 応答時間の分布において、観測された応答時間の99%がこの値以下に収まる点を指します。

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにてマネジメントをしています。 みなさんは業務の中でスライドを作る場面ってどのくらいありますでしょうか？ 私は管理職になってから業務上ビジョンシェアリングの機会や総会等での発表の機会が増えました。 それに伴い以前にも増して圧倒的にスライドを作成する作業の時間が増えました。 私の場合、話したいことは思い付くし、文章に起こすこともできるのですが、それをスライドにするのが手間がかかる上スライドを作るセンスにも自信がありません。 これが回り回ってかなりストレスになっていました。 そんな課題感から、この作業をどうにか簡略化できないかを検討し、弊社で主に使われているAmazon Q Developerを使ってスライド作成を自動化するしくみを検討しました。 結果として、 従来数時間かかっていた作業が数分で完了 するようになり、生産性が大幅に向上しました。 今回は、その具体的な手法と実装について詳しく紹介します。 背景：管理職のスライド作成問題 管理職になると、ビジョンシェアリング、プロジェクトキックオフ、経営陣向け戦略発表など、さまざまな場面でスライドを作成する機会が増えます。 しかし、以下のような課題がありました。 時間がかかりすぎる : 1つのスライドセットに数時間程度必要 デザインセンスの不足 : 見栄えの良いスライドが作れない 構成の悩み : 伝えたいことをどう整理すればよいかわからない 繰り返し作業 : 似たような構成のスライドを何度も作成 これらの課題を解決するため、Amazon Q Developerを活用した自動化システムを構築することにしました。 解決アプローチ：LLMにHTMLを書かせる 今回採用したアプローチの核心は、 LLMにパワポのスライドのように動作するHTMLを生成させることで、擬似的なスライドを作成する ことです。PowerPointやKeynoteではなく、HTMLベースのスライドにすることで以下のメリットがあります。 自由度の高いデザイン : CSSを使った柔軟なレイアウト 一瞬での生成 : テンプレートに縛られない迅速な作成 簡単なデプロイ : 静的ファイルとして簡単にホスティング可能 バージョン管理 : Gitでの管理が容易 HTML故の自由度 : HTMLなのでスクローラブルなデザインにすることも可能 テキストのコピーのしやすさ : コードブロックをスライドに落とし込んだ場合テキストのコピーが容易 パワポライクな画面にも適用 : 普段のスライドアプリケーションと同様にキーボードでスライドを捲るデザインにもできる Amazon Q DeveloperはモデルとしてClaude Sonnet4を利用しているのでコードを作成することが得意です。 そのためスライドを作成するよりもスライドのように機能するHTMLを書かせる方がかなえたい要求を満たしやすいです。 実際に生成されたスライド風HTML 実装手順 1. Amazon Q CLI プロファイルの作成 まず、スライド作成専用のプロファイルを作成します。 /profile create slide 2. コンテキストファイルの設定 .aws/amazonq/rules/slide/ ディレクトリを作成し、コンテキストを紐づけます。 /context add "~/.aws/amazonq/rules/slide/*.md" 3. ガイドラインファイルの作成 最も重要なのが GUIDELINE.md の作成です。このファイルにスライド作成のルールやデザイン指針を詳細に記載します。 この名前に特に縛りはありませんが、私の場合GUIDELINE.mdとしています。 GUIDELINE.mdの主要な内容 私が実際に作成したコンテキストは以下の内容で設定して使っています。 # スライド作成用のコンテキスト ## 目的 - このコンテキストは、ビジョンシェアリングや発表資料に適したスライドを作成するために必要な情報と手順を提供します。 ## 作業の進め方 1. ユーザーから与えられた文章やREADMEの内容やURLの内容を読み解いた上で、発表資料としてわかりやすくシンプルな形になるようにアウトラインを生成します。 2. アウトラインを生成する場合には必ず、"##アウトラインの作成手順"に沿ってOUTLINE.mdを作成してください。 3. OUTLINE.mdの作成とブラッシュアップが完了した後で、OUTLINE.mdの内容を元にパワーポイントのスライドのような挙動をするHTMLファイルでスライドを生成します。 ## デザイン - #ed6103のカラーをメインの色として、その色を利用する上で違和感のないよう作成をお願いします。 - 主張したい文字や情報については文字を大きくしたり色を変更したりなど見た目でわかりやすくしてください。 - 背景は可能な限り白にして欲しい - 全体の配置として余白はあまりないように作ってください。 - 一枚目のスライドのタイトルは大きい文字でわかりやすく作ってください。 ## スライドで注意するポイント - 1スライド1メッセージもしくはシンプルな見た目のデザイン - 一枚目にはタイトルと発表者指名を記載(渡邉陸斗) - 読み上げないで説明できる内容 - 視覚効果（アイコン、グラフ）を効果的に使用 - 数字でアピールできるものに関しては必ず取り入れる - 堅い文章になりすぎないようにしつつも社会人として問題のない内容で記載 - フォントはできるだけ画面共有しても見やすいように大きめに作成する24px以上 - 必ずキーボード操作もできるように作成して欲しい - スクローラブルなブロックがある場合にはスクロールできることも記載して欲しい - スクローラブルなブロックがコードブロックの場合にはコピーボタンを記載して欲しい。 実際の使用フロー ステップ1: 伝えたいことを文章化 まず、README.mdやドキュメントに伝えたいメッセージや思い、数字を文章としてまとめます。たとえば、今回の記事の元となったREADME.mdは以下のような内容でした。 # 概要 AmazonQを使ってスライドを簡単に生成できるようにしたのでその方法の共有 ## 背景 管理職になって圧倒的にスライドを作成する時間が増えた。 話したいことは思いつくし、文章に起こせるけどそれをスライドにするのは時間がかかる。 あと絶望的にスライドを作るセンスがない。 そんな課題感からスライドの作成だけを楽にしたかった。 ## 成果 かなり雑に文章を書いてもちゃんとしたスライドに起こしてくれてビジョンシェアリング用の資料や発表用資料として生成してくれます。 普段なら4時間くらいかかっていた作業が数分で完了するので、生産性が上がっています。 ステップ2: アウトライン生成 Amazon Q Developerに文章を読み込ませ、スライドごとの構成要素をまとめた OUTLINE.md を生成してもらいます。 この段階で、スライドの全体構成と各スライドで説明したいことを整理します。 修正が必要であれば手を加えて情報の過不足をチェックしてください。 ステップ3: HTML生成 OUTLINE.md の内容に沿って、パワーポイントのようにキーボードで操作できるHTMLスライドを生成します。 生成されるHTMLには以下の特徴があります。 レスポンシブデザイン : さまざまな画面サイズに対応 キーボード操作 : 矢印キーでスライド切り替え可能 統一されたデザイン : ブランドカラー（#ed6103）を使用 読みやすいフォント : 24px以上の大きなフォントサイズ ステップ4: デプロイ 生成されたHTMLファイルをS3などの静的ホスティングサービスにアップロードします。 これによって周りの人にも資料を提供できます。 LIFULLではHTMLをホスティングするためのサービスを内製していますので、それを利用することで簡単にデプロイできます。 実際のプロンプト例 スライドを作成する場合に 実際に使用しているプロンプトの例を紹介します。 このREADME.mdの内容を元に、Amazon Q Developerを使ったスライド作成自動化について の発表用スライドを作成してください。 重要なポイント： - LLMにHTMLを書かせることで自由度の高いスライドが作れること - 4時間の作業が数分になったこと - 実際のプロンプトやコンテキストの内容も含めること まずはOUTLINE.mdを作成してください。 成果と効果 このしくみを導入した結果、以下の成果を得ることができました。 時間短縮効果 従来 : 3~4時間程度 現在 : 数分程度 短縮率 : 約90% 品質向上 統一されたデザインテンプレート 読みやすいフォントサイズとレイアウト 一貫したブランディング 柔軟性の向上 HTMLベースなので細かいカスタマイズが可能 CSSで自由なデザイン調整 JavaScriptでインタラクティブな要素も追加可能 まとめ Amazon Q Developerを活用したスライド作成自動化により、 数時間の作業を数分に短縮 できました。 特に、LLMにHTMLを直接生成させるアプローチにより、従来のプレゼンテーションツールでは実現困難な自由度の高いスライドを短時間で作成できるようになりました。 このしくみの成功要因は以下の3点です。 詳細なコンテキスト設計 : GUIDELINE.mdでの明確な指針 段階的な生成プロセス : アウトライン → HTML の2段階アプローチ HTMLベースの選択 : 柔軟性とデプロイの簡単さ 管理職として、限られた時間の中で質の高いプレゼンテーション資料を作成する必要がある方には、ぜひこのアプローチを試していただきたいと思います。 他にも報告レポートやブログ執筆用のプロファイルを生成することで作業を効率化することも可能だと思います。 Amazon Q Developerの可能性を最大限に活用することで、創造的な業務により多くの時間を割くことができるようになるでしょう。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントをしています。好きなCI/CDツールはGitHub Actionsです。 以前、こちらの記事で、私たちのリリースフロー改善への取り組みをお話しました。 www.lifull.blog あれから数ヵ月が経ち、私たちのGitHub Actions集約型リリースフローは想像以上に進化を遂げました。今回は、その変化と新しく追加された機能について、実際の開発現場での体験を交えながらお伝えします。 🚀 何が変わったのか？主要なアップデート 1. セットアップが驚くほど簡単になりました 2. Chrome拡張機能で承認作業が格段に楽になりました 3. 企画担当者の方でも迷わず使えるガイドを作りました 4. リリース忘れを防ぐ機能を追加しました 5. 開発タスクの管理が自動化されました 6. 🎯 自動リリース機能でリリーサーの負荷がほぼゼロに 7.使いやすさへのこだわり 見た目でわかる設計 自動化されたリリースプロセスにおける課題を解決するためのしくみ グローバルチームにも対応 実際の開発現場での変化 導入前の悩み 導入後の声 🎉 実際の導入効果：数字で見る劇的な改善 リリース頻度の大幅向上 承認からリリースまでの時間短縮 企画担当者にもわかりやすい 自動マージ機能の効果 通知システムの効果 あらゆるリポジトリ形態に対応 柔軟な導入アプローチ ユースケースに合わせた導入方法の提供 自動リリースがもたらした革命的変化 リリーサーの役割の変化 組織全体への影響 これからの展望 まとめ 🚀 何が変わったのか？主要なアップデート 1. セットアップが驚くほど簡単になりました 以前は手動での設定が必要でしたが、今では対話形式の inquirer を用いたCLIツールを用意しました。 npm install npm run setup これだけで、チームに必要なワークフローを選択しながら自動生成できます。「どの機能を組み合わせればよいかわからない」という悩みから解放されます。 CLIを実行した様子 2. Chrome拡張機能で承認作業が格段に楽になりました リリース承認の煩雑さを解決するChrome拡張機能を開発しました。 ボタン一つで承認完了 : /G長承認OK や /PJ承認OK のコメントがワンクリック 新リリースフローの対象リポジトリにて、承認に必要なドキュメントのリンクを表示 拡張機能により提供されるもの もう「承認コメントってどう書くんだっけ？」と悩む必要はありません。 具体例 : /G長承認OK というコメントを手動で入力する代わりに、PR画面に表示される「G長承認」ボタンをクリックするだけで承認が完了します。 3. 企画担当者の方でも迷わず使えるガイドを作りました 技術に詳しくない方でも安心してリリース承認ができるよう、専用ガイドを整備しました。 確認すべきポイントを4つに絞った分かりやすい説明 豊富なスクリーンショットで視覚的にサポート 「ここだけ見れば大丈夫！」という安心感を提供 具体例 : 「Epic Issueの確認」「ビジネス観点のチェック」「PJ承認コメント」「承認状況確認」の4ステップで、技術的な知識がなくても確実に承認作業を完了できます。 4. リリース忘れを防ぐ機能を追加しました 新しく追加したRelease PR Reminder機能で、リリース日にPRが長時間未マージの場合、自動でSlack通知が送られます。 Google Calendarと連携してリリース日を自動判定 通知タイミングは調整可能（デフォルト1日） リリーサーへの確実な通知でリリース漏れを防止 5. 開発タスクの管理が自動化されました Sub-Issue自動管理システムにより、開発タスクの進捗管理が飛躍的に向上しました。 自動でタスク分解 : PRに紐づく開発作業を自動で細分化 進捗の可視化 : 全タスク完了時に自動でラベル付与 承認者も安心 : 開発作業の完了状況が一目でわかる 具体例 : PRを作成すると「QA仕様書作成」「デザインチェック」「開発チェックシート」などのSub-Issueが自動生成され、各タスクの完了に応じてPR上の進捗バーが更新されます。 subissueによるタスク分解 開発タスクの進捗状況の確認 6. 🎯 自動リリース機能でリリーサーの負荷がほぼゼロに 今回の最大の進化は、 完全自動リリース機能 の実装です。これにより、リリーサーの作業負荷が劇的に軽減されました。 自動リリースのしくみ : リリース条件がすべて満たされた場合、自動的にmasterブランチへのマージ ステージング環境テスト・プロダクション環境テストが完了したPRのみが対象 ステージング環境テスト、プロダクション環境テストが終了していない場合には開発者への訴求をGitHub上で自動通知 リリース後の開発者への通知も自動化 1日経っても未マージのリリースPRの自動検出と通知 リリーサーのタスク変化 : 従来 : 手動でのPRマージ、リリースしたことを開発者へ通知、確認作業の管理 現在 : 例外的なケースのみの対応（通常時はほぼ作業なし） メリット : 人的ミスの排除 : 手動操作によるミスが完全になくなりました リリース時間の短縮 : 条件が整い次第、即座にリリースが実行されます リリーサーの負荷軽減 : 定型作業から解放され、より重要な業務に集中できます 24時間対応 : 人の都合に関係なく、いつでもリリースが可能です 7.使いやすさへのこだわり 見た目でわかる設計 ラベルによる可視化 : 承認状況がPRのラベルで即座にわかる 進捗バー : タスク完了率を視覚的に表示 ステータスアイコン : 一目で状況を把握できる 自動化されたリリースプロセスにおける課題を解決するためのしくみ 自動導入 : リリースフローのワークフローを導入する際にCLIを利用して導入することで、手続的にリポジトリナイズされた設定を施したうえで導入が可能 権限管理 : 承認、マージする際には適切な権限を持つ人のみが実施可能 自動チェック : リリースに必要な開発タスクや、リリースチェックなど実施すべき項目が適切に行われていることをワークフローにより自動的にチェック 通知の強化 : あらゆるリリースに関する通知を自動化し、人間による通達漏れを排除 リリース依存性の担保 : リリース順序が決まっているマイクロサービスにおけるリリース順序が逆転しないようにするための依存先のリリースストップ機能 強行リリース : 何らかの理由によりワークフローが失敗し続ける際や、承認をまたずリリースしたいものがある場合のための承認者による強制リリースの実行方法の確立 グローバルチームにも対応 日本語・英語両対応のドキュメント 国際的なチームでも安心して利用可能 実際の開発現場での変化 導入前の悩み 「承認コメントの書き方がわからない...」 「どのタスクが終わっているか把握できない...」 「リリース日なのにPRがマージされてない！」 「企画の人にGitHubの使い方を説明するのがたいへん...」 「リリーサーが忙しくてリリースが遅れる...」 導入後の声 「ボタン一つで承認が終わるなんて！」 「タスクの進捗が自動で更新されるから楽」 「リリース忘れがなくなった」 「企画の人も迷わず承認してくれる」 「リリーサーを待つ必要がなくなった！」 🎉 実際の導入効果：数字で見る劇的な改善 リリース頻度の大幅向上 導入後、 1日に2回のリリース が可能になりました。従来は承認プロセスの複雑さから週1-2回程度だったリリースが、自動化により大幅に増加。これにより、ユーザーへの価値提供スピードが格段に向上しています。 リリース数の変化 承認からリリースまでの時間短縮 承認からリリースまでの時間が劇的に短縮 されました。従来は承認後数日かかっていたリリースが、現在では承認と同日、場合によっては数時間以内にリリースが完了するケースも増えています。 リリースまでのリードタイムの変化 企画担当者にもわかりやすい 専用ガイドとChrome拡張機能により、 技術的な知識がなくても確実に承認作業を完了 できるようになりました。 自動マージ機能の効果 開発チームでは 自動マージ機能 が特に高く評価されています。 自動マージには、承認が完了したPRが自動的にステージング環境でマージされる機能と自動的にリリースを行う機能の2つが用意されています。 条件の整ったPRが自動的にマージされることで、リリーサー、開発者の待ち時間が大幅に削減され、より重要な開発作業に集中できます。 通知システムの効果 リアルタイム通知システム により、リリース状況の把握が格段に向上しました。関係者全員がリリースのタイミングを正確に把握できるようになり、連携ミスが大幅に減少しています。 あらゆるリポジトリ形態に対応 私たちが特に重視したのは、 どのような形態のリポジトリでも問題なく使える汎用性 です。 モノリスアプリケーション : 単一リポジトリでの大規模開発 マイクロサービス : 複数の小さなサービスに分かれた構成 フロントエンド・バックエンド分離 : 異なる技術スタックでの開発 ライブラリ・SDK : ほかのプロジェクトから利用されるコンポーネント どのような開発スタイルでも、チームが同じ操作感でリリース管理を行えるよう設計しています。 柔軟な導入アプローチ 私たちが特に意識したのは、「チームの状況に合わせて必要な機能だけを選んで導入できる」ということです。 ユースケースに合わせた導入方法の提供 承認フローの改善 : G長・PJ承認をGitHub上で完結 開発タスク管理 : Issue駆動開発でタスク管理を自動化 リリースチェック : 本番・検証環境での確認作業を体系化 完全自動化 : リリーサー不要の自動リリースを実現 メンテナンス性 : 自動バージョンアップ機能の提供 どの段階でも確実に開発体験が向上するよう設計しています。 自動リリースがもたらした革命的変化 リリーサーの役割の変化 従来のリリーサーの1日 : 午前中: リリース予定PRの確認 昼ごろ: リリースの実施と開発者への通知 夕方: リリースチェック作業の確認 現在のリリーサーの1日 : 午前、午後: システムからの自動通知を確認（必要時のみ） 例外ケース発生時のみ対応 通常時はほかの業務を行い、リリース作業は実施せず 組織全体への影響 開発速度の向上 : リリーサーの都合を待つ必要がなくなり、定刻にリリースできるようになりました 品質の安定 : 人的ミスが排除され、リリース品質が向上しました コスト削減 : リリース作業にかかる人的コストが大幅に削減されました ストレス軽減 : リリース日の緊張感が大幅に軽減されました これからの展望 私たちの目標は変わりません。 リリース関連作業の一元管理 自動チェックによる作業負荷軽減 最終的なリリーサー不要の実現 今回のアップデートで、この目標の大部分を達成できたと感じています。特に自動リリース機能により、「リリーサー不要」という最終目標にかなり近付きました。残りの部分も、社内のプロダクト運用チームからのフィードバックを元に継続的に改善していきます。 まとめ 今回のアップデートにより、私たちのGitHubリリースフロー自動化は、単なる「効率化ツール」から「開発体験を根本から変えるシステム」へと進化しました。 特に自動リリース機能の導入により、 リリーサーの作業負荷がほぼゼロになった ことは、私たちの想像を超える効果をもたらしました。実際の導入現場では、 1日2回のリリース が可能になり、 承認からリリースまでの時間が劇的に短縮 されるなど、具体的な成果が現れています。 技術者も、企画者も、リリーサーも、全員が「使っていて気持ちよい」と感じられるシステム。それが私たちの目指した姿であり、今回のアップデートで大きく近付けたと確信しています。 もしチームでリリース作業に課題を感じているなら、ぜひ一度試してみてください。きっと、リリース作業に対する考え方が変わるはずです。 私たちは今後も、実際のユーザーフィードバックをもとにした継続的な改善を続けていきます。より多くのチームが、この「未来のリリース体験」を享受できるよう、取り組みを続けてまいります。 今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。 最後に、LIFULL ではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、テクノロジー本部コーポレートエンジニアリングユニットの籔田綾一です。今回は、情シス部門におけるKGI・KPIマネジメントの導入と実践について、その経緯と成果を共有します。私たちの試みが、同じ課題を抱える皆さんの参考になれば幸いです。 はじめに：情シス部門の成果を定量的に計測するには 「情報システム部門で、成果を定量的に示すことができるのだろうか？」 これは、多くの情シス部門が抱える課題ではないでしょうか。日々のインフラ運用、ヘルプデスク対応、セキュリティ対策、そして数々のプロジェクト推進など、情シス業務は多岐にわたります。その貢献を経営層や他部門に示す際、定性的な説明に終始してしまうケースも少なくありません。売上のような明確な指標がないため、部門の価値をどのように証明すれば良いのかという悩みがあるかと思います。 このような経緯から、 「情シス全体で採用できる定量的指標を自分で作ってみよう」 と考えました。 はじめに：情シス部門の成果を定量的に計測するには 「情報システム部門で、成果を定量的に示すことができるのだろうか？」 最初のステップ：指標の「物差し」を統一するアイデア 戦略と連動させるための工夫：ウェイト付けの導入 とにかく1以上を目指そう！：具体的な行動変化 固定費削減への意識と行動の変化 開発タスク進捗向上への意識と行動の変化 振り返り：やってみて分かったこと、そして今後の課題 まとめ：情シス部門の成果は定量的に計測できる まず、数十社もの大手有名企業の情シス責任者の方々にヒアリングを実施しました。その結果、多くの企業で 「部門全体の成果を定量的に測る指標があれば良いとは思うものの、実際には作れていない」という共通認識 があることが分かりました。個別の指標は存在するものの、それらを統合して部門全体の成果として示す仕組みは確立されておらず、正直なところ、私自身も半ば諦めかけていました。 しかし、それでも何か方法はないかと1年ほど模索する中で、ふと解決の糸口を思いつきました。 最初のステップ：指標の「物差し」を統一するアイデア 私が最初に直面したのは、「異なる性質の指標をどう統合し、定量的に評価するか？」という壁でした。固定費、従業員満足度、プロジェクト進捗率、問い合わせ対応時間。これらは単位も性質も全く異なります。 そこで考えたのは、 「物差しが違うなら、統一してしまえ」 という思い付きです。つまり、単位が異なる指標であっても、基準となる数値を設けて比較できるようにすれば良い、という発想です。 例えば、固定費削減であれば、年間予算ならば「1」を基準値とし、10%削減なら「1.1」、逆に10%オーバーなら「0.9」といった具合に表現します。開発進捗率も同様に、完了すべきタスク数（目標値）を分母、完了済みのタスク数を分子とし、「1」以上であれば目標達成とみなしました。これらを個々のKPIとみなし、その平均を部門全体のKGIとして捉えてみました。 戦略と連動させるための工夫：ウェイト付けの導入 設定したKPIが常に全社戦略と整合しているとは限りません。そこで、各KPIにウェイト設定を取り入れてみました。全社戦略における各項目の重要度に応じて、個々のKPIに重み付けを行うイメージです。 部門全体の目標達成度合い（仮に「戦略スコア」とします）をKGIとして、個々のKPIスコアにそれぞれのウェイトを掛けて算出されるようなイメージを表形式で示します。 KPI の種類 KPI名 予算/実績 KPI 重要度 ウェイト KGI コスト関連 固定費削減率 1億/9000万 1.1 高 0.4 0.44 開発進捗 開発タスク消化率 100件/90件 0.9 中 0.3 0.27 業務効率化 工数削減時間 110時間/100時間 1.1 中 0.2 0.22 その他（必要に応じて） システム安定稼働率 100%/100% 1 低 0.1 0.1 KGI（戦略スコア） 1.03 このように、各KPIに戦略上の重要度に応じたウェイトを設定し、それぞれの達成度を考慮することで、部門全体の戦略的な貢献度を評価することができます。そして、このウェイト付けにより、情シス部門の活動が、単なる日々の業務遂行ではなく、企業の戦略目標達成にどのていど貢献できているか定量的に示せます。 とにかく1以上を目指そう！：具体的な行動変化 KPIを評価にも組み込み、KPIマネジメントを半年間運用してみたところ、メンバーの行動に明らかな変化が現れました。 固定費削減への意識と行動の変化 これまで、具体的な数値目標として意識されていなかったコストに対して、「自分たちのKPI」という意識が芽生え、コスト削減に向けた具体的な行動が自発的に生まれるようになりました。 不要アカウントの削減： 無駄なコストを減らすため、各メンバーが主体的に利用状況を調査し、不要なアカウントの削除を提案・実行。 通信料の見直し： モバイル通信料の利用状況について、高額な利用をしているユーザーに対して利用状況の確認や改善提案を行う。 不要なサービスの見直し： 契約しているサービスの利用状況を調査し、利用頻度の低いサービスや重複しているサービスがないか積極的に洗い出し、解約に向けた検討を始める。 PC調達方法の再検討： PCのライフサイクルコストを意識するようになり、リースという選択肢を検討し始めました。コスト削減への意識がなければ、そもそもリースを検討することはなかった。 開発タスク進捗向上への意識と行動の変化 開発タスク消化率をKPIに設定したことで、「期日までにタスクを完了させる」という意識がより向上し、チーム内の協力体制が強化されました。 タスク管理の意識向上： 各メンバーが自身のタスクの進捗状況をより意識的に管理 積極的な協力体制： チーム内で互いに助け合い、タスクの遅延を防ぐための協力体制が生まれる あと一歩を頑張る： あと0.1で達成といった状況が見えるため、リスケよりもゴールしようと頑張る 振り返り：やってみて分かったこと、そして今後の課題 今回のKPIマネジメント導入を通じて、異なる指標を統一化し定量的に評価する難しさ、適切なウェイト付けの重要性、そして何よりも、目標を「見える化」することによる組織の変化の大きさを実感しました。 一方で、KPIの設定やウェイトのつけ方、目標値の妥当性、そして部門全体への浸透には、まだ改善の余地があると感じます。今後も定期的にKPIを見直し、より実効性の高いマネジメントサイクルを確立していく必要があると感じました。 まとめ：情シス部門の成果は定量的に計測できる 情シス部門は、決して「成果が測れない部門」ではありません。 「情シス部門の成果を定量的に計測する」という課題に対し、KPIマネジメントという試みを通じて、数字の裏にあるメンバー一人ひとりの意識と行動のポジティブ変化こそが、KPIマネジメントの成果であると強く感じています。 最後に、LIFULL ではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co 籔田綾一 LIFULLテクノロジー本部 コーポレートエンジニアリングユニット ユニット長 2010年入社、技術マネージャーとして商品開発を多数手掛けたのち、 Salesforce(CommunityCloud)を用いたB向けポータルサイト立ち上げ、オンライン受注システム構築。 社内のSaleforce組織を統合、機関システムとSalesforceを連携しマーケティング、CRM、販売管理と一気通貫のシステム構築。 現在は情報システム部門の責任者として社内システム刷新に取り組んでいます。

こんにちは、テクノロジー本部コーポレートエンジニアリングユニットの籔田綾一です。 LIFULLのエンジニアマネージャーの取り組みの一つ「 エンジニアキャリアクリニック 」について紹介します。 組織マネジメントの一環として、参考になれば幸いです。 「最高のチームをつくる」ために エンジニアキャリアクリニックの流れ リピーターも増加中！ 参加者の声 まとめ 「最高のチームをつくる」ために それにはメンバー同士の相互理解と、一人ひとりの成長をサポートする環境が不可欠です。 そこで私たちは、メンバーがマネージャーの人となりを知り、気軽に相談できる場として「エンジニアキャリアクリニック」を開設しました。 この「クリニック」では、エンジニアマネージャーが「先生」となり、キャリアパス、技術的な課題、チームでの悩みなど、様々な相談に親身に対応します。 単なる自己紹介ページでは堅苦しく、話しづらい雰囲気になってしまうため、「クリニック」という形式を採用することで、より親しみやすく、相談しやすい環境を目指しました。 最初は数名の有志で始めました。今では、様々な経験を持つ全マネージャーが「先生」として登録し、活発に利用されています。もちろん、弊社のCTOも「先生」として参加し、メンバーの相談に乗っています。 「エンジニアキャリアクリニック」では、キャリアパスの相談だけでなく、日々の業務で直面する技術的な課題や、チームでのコミュニケーションに関する悩みなど、幅広い相談を受け付けています。 オンラインで簡単に予約ができ、それぞれのマネージャーの専門分野や経験に応じて、自分に合った「先生」を選ぶことができます。相談後には、必要に応じて具体的なアクションプランを検討し、フォローアップも行っています。 実際に、「クリニック」を利用したメンバーからは、「CTOと直接話せて刺激になった」「普段聞けない話が聞けて有益だった」「先生の経験談が参考になりモチベーションが上がった」といった声が寄せられています。 エンジニアキャリアクリニックの流れ 「先生」の顔写真と得意分野や相談にのれそうなこと（業務外も含め）を紹介するページを用意 メンバーは「先生」を選んで「予約」 当日中に返信、スケジュール調整 オンラインもしくは対面で30〜1時間ほど1on1を実施 事後に簡単なアンケート実施 予約が入ったら断らない、というスタンスで運営しており、業務であまり関わらないマネージャーにも相談しやすくなっています。 飲みながら、、といった予約も可能です！ リピーターも増加中！ 定期的な案内の際、はじめは「悩んでる人は相談しよう」のようなニュアンスで促していました。しかし、メンバーからは「いろんな人の考えや経験を聞くことで、キャリア形成のヒントが得られる」「人脈を広げることができる」といったポジティブな意見が多く聞かれるようになりました。そこで、最近はこれらのポジティブなメッセージを強調して案内するようにしています。 その結果、利用者は徐々に増え、今では月に4名ほどが「クリニック」を利用しています。 また、実施後のアンケートも高評価で、毎回同じ「先生」ではなくいろんな先生に予約するクリニックのリピーターも多くなってきました。全利用者の半数以上が2回以上利用しています。 先日は「キャリアを語る会」として、マネージャーが自身の経歴や経験を語る会も開催しました。今後もQに一度開催することで、特に若いメンバーがより利用しやすい雰囲気づくりを目指していきます。 参加者の声 「CTOとサシで話ができていい刺激になった」という声や、 「普段聞けないお話を聞けて非常に有益でした。★５つ」 「先生の考えや経験談がとても参考になりモチベが上がりました！」 「予約したらすぐに調整連絡が来てビックリです。次回も利用しようと思います。」 といった声をいただいてます。 まとめ 「エンジニアキャリアクリニック」では、メンバーが活躍するためのキャリア形成における一助となることを目指しています。 みんなが自分らしく成長出来るように、といった気持ちで「先生」が話を聞いて、語ってもくれます。 そして、困ったときだけでなく日常的に「クリニック」として活用してもらいつつ「最高のチーム」へ近づければと思います。 LIFULL ではともに挑戦・成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co 籔田綾一 LIFULLテクノロジー本部 コーポレートエンジニアリングユニット ユニット長 2010年入社、技術マネージャーとして商品開発を多数手掛けたのち、 Salesforce(CommunityCloud)を用いたB向けポータルサイト立ち上げ、オンライン受注システム構築。 社内のSaleforce組織を統合、機関システムとSalesforceを連携しマーケティング、CRM、販売管理と一気通貫のシステム構築。 現在は情報システム部門の責任者として社内システム刷新に取り組んでいます。

こんにちは！クオリティアーキテクトグループ(以下、QAG)でQAエンジニアをしている片野です。 好きなテスト技法はデシジョンテーブルテストです。 QAGでは横断組織として自動テストやツール開発、プロセス改善などの仕組みの構築に取り組んでいます。 今回は、テストの情報を用いた課題発見の取り組みについて紹介します。 QA組織の紹介 背景 やったこと 具体的な効果 品質ダッシュボードの概要 概要: 品質ダッシュボードを使う理由 活用の仕方 システム構成 今後の展望 まとめ QA組織の紹介 LIFULLでは、設計・実装を行う開発エンジニアがテストも担当しています。 QAエンジニアはプロジェクトを横断してテストの支援をしています。 背景 横断QA組織の立場からは、以下の状況により社内全体の状況把握が難しく、プロジェクトへのプロアクティブな支援が困難になっています。 社内には、さまざまな開発や保守のプロジェクトが同時に動いており、QAGがすべてのプロジェクトへ均等な支援を行えない 各プロジェクト・組織の品質面での課題や改善点がQAGから見えにくい 各プロジェクトの課題は相談を受けてから気付くことが多く、QAGは受動的な対応になりがち やったこと QAGでは、品質課題の解決に向け、品質ダッシュボードを作成しました。 このダッシュボードは、GoogleのLooker Studioを活用していて、様々なデータソースと連携してデータの可視化や分析ができます。 今回は特に、テストケースが格納されているQUBEのデータをLooker Studioに接続し、グラフや表を作成することで、テストの状況を可視化しました。 ※QUBEとはLIFULL独自のテスト設計書全社共通フォーマット。 www.lifull.blog QUBEのサンプル画像 具体的な効果 テストの状況を可視化することにより、冗長なテストケースの削減に効果がありました。 例えば、開発環境やステージング環境など、テストで見るべき観点が異なる環境でも、同じ内容のテストを実施しているケースが見受けられました（特に、テストケース数が多い（テストケース数が上位20%の）プロジェクトにおいて多く見られました）。 それらのテストケースの削減を実施した結果、最大で35%程度の削減をすることができました。 品質ダッシュボードの概要 概要: 品質ダッシュボードは、開発サイクルにおけるテスト関連アクティビティに関する指標を可視化します。 品質ダッシュボードを使う理由 データを可視化することにより、メトリクスベースのフィードバックループ（品質目標の設定→計測→改善）を運用できます。 フィードバックループを回すことで、品質目標（QCD）に近づけたり、品質目標が満たされている状態を保持できます。 活用の仕方 経験や勘ではなく、データに基づいた合理的な意思決定によって、以下のような活用を納得感を持って実現できます。 品質課題の特定 プロセス改善の効果測定 システム構成 今後の展望 今回はテストの効率化に焦点を当てていますが、効率化しすぎるとバグの見逃しにつながる可能性があります。 そのため、開発規模に対してテストケース数が適切かを判断するため、従来型（ウォーターフォール開発でよく使われるメトリクス）のテストケース密度やバグ密度の活用も検討しています。 また、開発生産性についてはアジャイルメトリクスを活用し、QCDの総合的な判断に役立てたいと考えています。 まとめ メトリクスの活用は始まったばかりですが、今回の取り組みを通して、新たな発見もありました。 それは、開発環境やステージング環境など、テストで見るべき観点が異なる環境でも、同じ量のテストを実施しているケースが見受けられたことです。 これは、テストが効率的に行われていないことを示唆しています。 このように、テストのメトリクスを分析することで、ソフトウェア開発の効率や品質を高められると考えています。 最後まで読んでいただきありがとうございました。 LIFULL ではともに挑戦・成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、グループデータ本部データサイエンスグループの清田です。 昨年の DEIM 2024 に引き続き、「 第17回データ工学と情報マネジメントに関するフォーラム（通称DEIM 2025） 」に参加・登壇してきましたので、その様子を報告いたします。 www.lifull.blog 過去最大の開催規模 生成AI・大規模言語モデル研究の盛況 DEIMの参入障壁を下げる取り組み LIFULLのスポンサー活動とデータセット提供 今後の展開：新たなデータセット提供に向けて おわりに 過去最大の開催規模 DEIM 2025は、2025年2月27日（木）から3月4日（火）にかけて開催されました。昨年に引き続き「直列ハイブリッド」形式を採用し、2月27日（木）から3月1日（土）までがZoom Eventsを用いたオンライン開催、3月3日（月）と4日（火）は福岡国際会議場でのオンサイト開催となりました。 現地会場の福岡国際会議場（福岡市博多区） 今回のDEIMは過去最大規模となる840名もの参加者を集め、データ工学および情報マネジメントに関する研究コミュニティの活況を示しました。429件の一般発表が行われ、そのうち口頭発表とポスターによるインタラクティブ発表の両方が行われたものが386件（うちデモ発表46件）、口頭発表のみが43件という構成でした。 生成AI・大規模言語モデル研究の盛況 昨年に引き続き、今年のDEIMでも生成AI、特に大規模言語モデル（LLM）の利用に関する多数の研究発表が行われていました。5つのトラック（「自然言語処理・機械学習基礎」、「ビッグデータ基盤技術・データセキュリティ・プライバシ」、「情報検索・情報推薦・ソーシャルメディア」、「メディア処理・HCI・人間中心情報マネジメント」、「高度なデータ利活用・ドメイン応用」）すべてにおいて、生成AIの活用事例や研究成果が報告されていました。 特に印象的だったのは、従来の自然言語処理や情報検索の技術がLLMによってどのように変革されつつあるかについての議論です。単にLLMを使うだけでなく、その特性を理解した上で従来技術と組み合わせる研究アプローチが多く見られました。 DEIMの参入障壁を下げる取り組み 今回私が参加して特に印象に残ったのは、兵庫県立大学の大島裕明先生が企画された「DEIMの参入障壁を下げるBoF」です。BoF（Birds of a Feather）セッションとは、同じ興味や関心を持つ参加者が集まって自由に議論する場で、今回はDEIMをより多くの人にとって参加しやすい学会にするためのアイデアが活発に交換されました。特に初めての参加者が楽しく参加できる仕掛けについてのディスカッションが非常に参考になりました。例えば、「初心者向けのオリエンテーションセッション」など、具体的かつ実現可能なアイデアが多く提案されていました。 学会は研究発表の場であると同時に、研究者同士のネットワーキングの場でもあります。特に学生や若手研究者にとって、参入障壁を下げる取り組みは非常に重要であり、DEIMコミュニティの今後の発展につながる貴重な議論だったと感じました。 LIFULLのスポンサー活動とデータセット提供 LIFULLは今回も、前回に引き続きゴールドスポンサーとして出展しました。DEIM 2025には、プラチナスポンサー7件、ゴールドスポンサー15件、シルバースポンサー2件という多くの企業・団体からの支援があり、産学連携の場としても機能していました。 私たちLIFULLからは、 LIFULL HOME'Sデータセット の2015年11月の提供開始からの利用実績の分析結果を技術報告として発表しました。現在までに170件を超える研究成果が発表されており、学術研究コミュニティへの貢献が着実に実を結んでいることを報告できました。 また、新たなデータセットの提供を予定していることについても告知しました。AIや情報処理に関する研究は、多くの研究者がアクセスできる共有データ資源の存在に支えられて発展してきました。生成AI技術の隆盛により、「データを独占的に保有すること自体が巨大な利益につながる」という状況も生まれている中で、オープンなデータ資源の提供は今後も重要な役割を担っていくと考えています。 今後の展開：新たなデータセット提供に向けて 現在、私たちLIFULLでは新たなデータセットの提供開始に向けて準備を進めています。このデータセットは、これまでの不動産情報に加えて、より多様な分野の研究に活用できる内容となる予定です。 生成AIの発展や社会実装が急速に進む中、高品質なデータセットの価値はますます高まっています。LIFULLは今後も、研究コミュニティへの貢献を通じて、社会課題の解決に向けた技術開発を支援してまいります。 来年のDEIM 2026でも、より多くの研究者との交流を深め、データ工学や情報マネジメントの分野の発展に寄与していきたいと考えています。 おわりに DEIM 2025は、オンラインとオンサイト、それぞれの利点を活かした運営により、全国各地からの参加が可能となり、多様な立場の参加者による有意義な議論が展開されました。 LIFULLでは、今後も学会イベントのサポートを継続するとともに、データサイエンスやAI技術を活用した社会課題解決に取り組む仲間を募集しています。豊富な研究開発資源を活かしながら、多様な社会課題の解決に向けた研究開発やプロダクト創出に一緒に取り組んでみませんか？ データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速してくださるデータサイエンティスト（R&D）を募集しています。 興味を持っていただけた方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは、テクノロジー本部の布川です。 普段は社内のシステム基盤の運用を担当しています。 先日の記事にありましたように、社内でモノづくりイベント『創民祭』が開催されました。 www.lifull.blog 今回は参加してみて感じたことなどを共有させていただきます！ 創民祭参加のきっかけ 創民祭参加につながるアプリ開発のモチベーションが高まったのは、入社2年目のSET研修がきっかけでした。 SET研修とは、新卒2年目のエンジニアを対象に、3人程度のチームでプロダクトをスクラッチ開発しながら、それぞれの技術課題を克服していく研修プログラムです。 業務で基盤運用に関するサービスの設計や実装に携わりつつも、基本的な設計思想やアプリを拡張性高く保って開発する方法などに関して知識と経験の不足を感じていたところ、SET研修で多くを学ぶことができました。 今年度のSET研修参加者からの記事もよろしければ読んでみてください。 www.lifull.blog その後は業務中や、同期の仲間がプライベートで制作しているアプリの開発を手伝ったりする中でSET研修で学んだことの有用性を感じたことが、創民祭に出展するアプリの開発に繋がりました。 アプリの着想と作品概要 今回創民祭で出展したアプリは、一日の満足感を高めることがコンセプトになっています。 生活の中でその日の気分の記録を取っていたところ、行った方が良いと感じていることを行い、行わない方が良いと感じていることを行わなかった時ほど、良い一日だったと感じる傾向が高いことが分かりました。 そのため、良い習慣を継続しつつ、良くない習慣（スマホの見過ぎ）を防ぐことをサポートするアプリを作ることにしました。 特定のスマホアプリの利用時間を目標以内に抑えつつ、良い習慣を一定以上実行できた日を「良い一日」としてカウントし、その達成状況と日々のムードログや日記を比較して効果を測定することを目的としています。 制作したアプリ 開発プロセス 業務外の時間で、半年ほどかけてアプリのコンセプト作りから機能要件決め、システムや画面の設計を少しずつ行いました。 画面の設計が終わった頃、試しにChatGPTに画面のスクリーンショットを渡してみたところ、想像以上に高いクオリティのSwiftコードが出力されたので、これは創民祭に間に合うかもとそこから一ヶ月弱でViewやロジックの実装を行いました。（この時はまだAIエージェントの存在を知らず、ChatGPTからエディタへコピペを繰り返すことに・・・） その後、完成を急ぐあまりシステムの設計が十分に反映されていなかったため、創民祭が終わってから数ヶ月かけて実装をクリーンな形に改善しました。 成長と普段の業務への影響 今回の開発を通して、最初の段階で拡張しやすい基礎となる設計を、時間を掛けて用意しておくことの大切さを改めて学びました。 昔の個人開発では行き当たりばったりの実装で行き詰まることが多く、それが原因で開発を諦めてしまう経験もありましたが、今はAIエージェントによる拡張を繰り返しても分かりやすさや変更のしやすさがほとんど失われず、その学びの成果が出ていると感じます。 普段の業務でも、設計段階で複雑さを排除しシンプルさを追求することで、その後の開発効率が向上することを実感しています。 また、創民祭を通して色々な方にフィードバックを頂けたおかげで、アプリのコンセプトに対する思索が深まったり、UI/UXに関する課題が明らかになり、とても良い機会となりました。 今後の目標 色々な方に頂いたFBをもとにアプリの形を整えた上で、使ってもらえるようにリリースすることを目指しています。 創民祭への参加は、業務外の技術習得に関してFBを受けられたり、社内でのコミュニケーションや新たな発見につながる取り組みです。LIFULLには、技術やものづくりに対する想いが強いメンバーが集まっているからこそ、こうした場が活発に機能していると感じます。 今回の参加でも色々な発表に触れることができ、業務の質の向上とより良いプロダクト開発につながる貴重な経験となりました。これからも職種を問わず社内の方々とさらに盛り上げていければと思います。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

KEELチーム の相原です。 前回のエントリは「小さい経路最適化ミドルウェアを実装してあらゆるAZ間通信を削減する」でした。 www.lifull.blog 今回は、MCPサーバを比較的安全に動かすために色々やってた話を書きたいと思います。 MCPについて MCPサーバのリスク なるべくローカルで動かさない ローカルではせめてDockerで動かす 無理やりHTTP Transportに対応する セッションの開始 コマンドの起動 ペイロードを受け取るためのエンドポイントの実装 まとめ MCPについて MCPはModel Context Protocolの略で、Anthropicが標準化を主導するLLMとその外部を繋ぐプロトコルです。 github.com これによりGitHubやPlaywrightといった外部のツールをLLMが自律的に利用できるようになり、OpenAIもサポートを表明したことから大きな注目を集めています。 要は標準化されたFunction Callingということになるでしょう。 我々KEELチームでは2年ほど前から無限にスケールする汎用AI(仮)を開発してきており、これは内部でFunction Callingするエージェントを複数協調させて動かすことであらゆるタスクを解決することを狙っています。 www.lifull.blog Function Calling(MCPサーバ)を横に大量に並べて使おうとするとトークン消費が無視できなくなるはずで、当時我々はそれを解決するためにマルチエージェントとして複数のエージェントを協調させることを選びました。 (最近の A2A の動きを見ていても、まだこの設計でやっていけそうだなと感じています) また、エージェントを簡単に開発できるフレームワークも提供することで、社内のContributorが自由に社内システムとの連携を実装できるようにもなっています。 ということもあり、我々目線ではMCPの登場は「コミュニティが成熟すればFunction Calling実装の手間が省けるな～」くらいの受け止め方だったわけですが、今となっては職種問わず多くの人がローカルでMCPサーバを動かそうとし、社内システムのMCPサーバも開発されるようになってきました。 そろそろMCPが無視できなくなってきており、(本業はマルチテナントなKubernetesクラスタの開発ではありつつ)プラットフォーマーとして動くことにしました。 MCPサーバのリスク 2025年5月現在のよくあるMCPサーバの実行方法は npx や docker run 経由のものだと理解しています。 Docker for Desktop有償化とかCPU Virtualizationが必要であることを考えると、職種問わず利用者が多いのは npx でしょうか。 多くの場合どちらも素朴に最新のMCPサーバの実装を取得してきて、実行ユーザの権限でstdio Transport経由でMCPホストが利用します。 そしてその場合、 悪意のあるMCPサーバを誤って実行してしまうと、踏み台として利用されたり npx 経由での実行では環境変数やファイルを奪われてしまうというリスクがあります。 最近ではMCPホストのUIからは見えない形でLLMに対して悪意のある指示をする攻撃手法が発見されるなど、MCPサーバを対象にした攻撃は巧妙化しつつあり注意が必要です。(それでも私たちはAuto-approveを使ってしまうわけですが) invariantlabs.ai とりあえずバージョンは固定したいですし、バージョンがプログラムの中身を一意に識別するものでないことを考えると、最低限 docker run ではDigestでの参照や、他もChecksumまでやれると理想でしょう。 ただそれだけではまだ不十分だと感じていて、欲を言えばWebAssemblyやDenoのようなサンドボックス上で明示的にCapabilityを与えた上で実行したいところです。 一方でこれらはMCPサーバの実装に依存する部分が多くあり、その中で比較的安全にMCPサーバを運用できないかと色々やってきました。 なるべくローカルで動かさない そもそも各々がローカルで大量のMCPサーバを実行することが会社的には少し厳しさがあると感じています。 もちろんPlaywrightのMCPサーバのように手元のデスクトップ環境を操作したい場合はローカルで動かす必要がありますが、社内システム用のMCPサーバやOrganizationレベルで権限を持ったGitHubなどのMCPサーバは、社内共通で一つ動かしておいてそれを各々が参照するだけでよい可能性があります。 MCPにはいくつかのTransport実装があり、よく使われる(?)stdio TransportはMCPホストが直接コマンドとしてMCPサーバを実行し、その名の通りstdioを介してMCPサーバとやり取りをします。 一方で、Server Sent Eventsを利用したTransport実装やそれを改良した Streamable HTTP Transport と呼ばれるHTTPに載ったものもあり、これらはリモートにあるMCPサーバを利用可能です。 そのため、LIFULLではこれらのTransportを実装したMCPサーバはまとめて前述のマルチテナントなKubernetesクラスタで運用して提供するようにしています。 apiVersion : apps/v1 kind : Deployment spec : template : spec : automountServiceAccountToken : false securityContext : fsGroup : 65532 seccompProfile : type : RuntimeDefault containers : - name : mcp securityContext : privileged : false allowPrivilegeEscalation : false capabilities : drop : - ALL readOnlyRootFilesystem : true runAsUser : 65532 runAsNonRoot : true seccompProfile : type : RuntimeDefault <snip> Kubernetesのベストプラクティス(Pod Security Standards)に沿って厳格な権限で動かしています。 明示的に許可しない限り、MCPサーバはrootfsへの書き込み権限すら与えられません。 また、LIFULLではすべてのコンテナにIstioのプロキシを入れることを義務付けており、MCPサーバにも同様にIstioのプロキシを入れて、許可した接続先以外にはリクエストできないようにしています。 apiVersion : networking.istio.io/v1beta1 kind : Sidecar spec : egress : - captureMode : DEFAULT hosts : - istio-system/istiod.istio-system.svc.cluster.local - istio-system/otel-agent.istio-system.svc.cluster.local outboundTrafficPolicy : mode : REGISTRY_ONLY <snip> www.lifull.blog これにより、ローカルで動かす必要がないMCPサーバをプラットフォームから提供することで、リソースの効率化とともに比較的安全に運用することができました。 ローカルではせめてDockerで動かす とはいえ全てのMCPサーバをリモートで動かせるわけではありません。 前述のようにデスクトップ環境に依存するようなMCPサーバはローカルで動かす必要がありますし、Personal Access Tokenを利用せざるを得ないものも同様です。 その際は、Kubernetesで実現していたものと似たような隔離空間をDocker Composeを使って実現することを推奨しています。 # docker-compose.yaml services : tcp-proxy : image : ghcr.io/lifull/keel/proxy:latest command : - https://example.com - --mode - tcp - --address - 0.0.0.0:443 networks : default : {} internal : ipv4_address : 172.16.255.1 my-mcp-server : image : ghcr.io/lifull/keel/my-mcp-server:latest cap_drop : - ALL environment : - PERSONAL_ACCESS_TOKEN=${PERSONAL_ACCESS_TOKEN} extra_hosts : - "example.com:172.16.255.1" networks : internal : {} networks : internal : internal : true ipam : driver : default config : - subnet : 172.16.0.0/16 default : driver : bridge Dockerはデフォルトでbridgeネットワーク上でコンテナを動かし、bridgeを介してホストのネットワークからインターネットに出ていきます。 そのため、悪意のあるMCPサーバをDockerコンテナとして動かしてしまうとそのまま外にリクエストされてしまうわけです。 そこで、この例ではDocker Compose内に閉じたネットワーク internal を作成し、MCPサーバにはその internal のみを割り当てることでインターネットに疎通できないようにしています。 しかし、ものによってはGitHubのAPIを叩くなどインターネットに疎通する必要があるものもあります。 その際はTCP Proxyを同じく internal ネットワーク内に用意したうえで、そのTCP Proxyのみをbridgeネットワークにも割り当てることで、許可した接続先にのみリクエストできるようにしています。 extra_hosts を利用することでMCPサーバのプログラムを一切変更することなく、安全にTCP Proxyを経由させることが可能です。 いちいち解説するまでもないと思いますが、TCP Proxyの実装はこんな感じです。 TCP Proxy func runTCPServer(listener net.Listener, target *url.URL, a *Args) error { shutdown := make ( chan struct {}, 1 ) semaphore := make ( chan struct {}, a.MaxConnections) wg := sync.WaitGroup{} go func () { for { local, err := listener.(*net.TCPListener).AcceptTCP() if err != nil { select { case <-shutdown: return default : continue } } semaphore <- struct {}{} wg.Add( 1 ) go func () { defer func () { <-semaphore wg.Done() }() defer local.Close() remoteAddress := target.Host if target.Port() == "" { switch target.Scheme { case "http" : remoteAddress = net.JoinHostPort(target.Hostname(), "80" ) case "https" : remoteAddress = net.JoinHostPort(target.Hostname(), "443" ) } } remote, err := net.DialTimeout( "tcp" , remoteAddress, 10 *time.Second) if err != nil { return } defer remote.Close() c := make ( chan struct {}, 2 ) f := func (c chan struct {}, dst io.Writer , src io.Reader ) { _, _ = io.Copy(dst, src) c <- struct {}{} } go f(c, remote, local) go f(c, local, remote) select { case <-c: case <-shutdown: local.CloseWrite() } }() } }() quit := make ( chan os.Signal, 1 ) signal.Notify(quit, syscall.SIGTERM) <-quit time.Sleep(time.Duration(a.Lameduck) * time.Second) close (shutdown) listener.Close() wg.Wait() return nil } docker-compose.yaml を配布するだけで便利なMCPサーバを社員に行き届かせることができるので一石二鳥ですね。 一つトレードオフとして、この場合MCPサーバは docker compose up でまとめて起動するため、必然的にMCPクライアントからはstdio TransportではなくHTTP Transportを利用することになります。(JetBrainsのJunieはHTTP Transportに未対応だったりします) 無理やりHTTP Transportに対応する 一方で、一つ目のリモートで動かすにせよ二つ目のDocker Composeで動かすにせよ、MCPサーバがHTTP Transportに対応していることが前提となります。 しかし野良のMCPサーバの中にはstdio Transportしか実装していないものがそれなりにあります。 そういったMCPサーバでは上記のアプローチが取れないので工夫が必要です。 そこで、我々KEELチームはstdio Transportにのみ対応しているMCPサーバを無理やりSSE Transportに対応する小さいプロキシを開発しました。 バイナリとして簡単に配布できるようにGoで書いています。 mcp-stdio-proxy package main import ( "bufio" "context" "encoding/json" "errors" "flag" "fmt" "log" "net" "net/http" "os" "os/exec" "os/signal" "runtime/debug" "sync" "syscall" "time" "github.com/google/uuid" ) type MCPMethod string // https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-03-26/schema.ts const ( CancelledNotification MCPMethod = "notifications/cancelled" InitializeRequest = "initialize" InitializedNotification = "notifications/initialized" PingRequest = "ping" ProgressNotification = "notifications/progress" ListResourcesRequest = "resources/list" ListResourceTemplatesRequest = "resources/templates/list" ReadResourceRequest = "resources/read" ResourceListChangedNotification = "notifications/resource/list/changed" SubscribeRequest = "resources/subscribe" UnsubscribeRequest = "resources/unsubscribe" ResourceUpdatedNotification = "notifications/resource/updated" ListPromptsRequest = "prompts/list" GetPromptRequest = "prompts/get" PromptListChangedNotification = "notifications/prompt/list/changed" ListToolsRequest = "tools/list" CallToolRequest = "tools/call" ToolListChangedNotification = "notifications/tool/list/changed" ) type MCPMessage struct { JSONRPC string `json:"jsonrpc"` Method MCPMethod `json:"method"` ID any `json:"id,omitempty"` } type session struct { id string responseQueue chan [] byte requestQueue chan [] byte } func main() { var address string var terminationGracePeriodSeconds int var lameduck int var keepAlive bool var verbose bool flag.StringVar(&address, "address" , "0.0.0.0:8080" , "" ) flag.IntVar(&terminationGracePeriodSeconds, "termination-grace-period-seconds" , 10 , "The duration in seconds the application needs to terminate gracefully" ) flag.IntVar(&lameduck, "lameduck" , 1 , "A period that explicitly asks clients to stop sending requests, although the backend task is listening on that port and can provide the service" ) flag.BoolVar(&keepAlive, "http-keepalive" , true , "" ) flag.BoolVar(&verbose, "verbose" , false , "" ) flag.Parse() args := flag.Args() if len (args) == 0 { log.Fatalf( "command not specified" ) } name := args[ 0 ] var arg [] string if len (args) > 1 { arg = args[ 1 :] } sessions := &sync.Map{} mux := http.NewServeMux() mux.HandleFunc( "GET /sse" , func (w http.ResponseWriter, r *http.Request) { w.Header().Set( "Content-Type" , "text/event-stream" ) w.Header().Set( "Cache-Control" , "no-cache" ) w.Header().Set( "Connection" , "keep-alive" ) flusher, ok := w.(http.Flusher) if !ok { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } cmd := exec.Command(name, arg...) stdin, err := cmd.StdinPipe() if err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } stdout, err := cmd.StdoutPipe() if err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } if err := cmd.Start(); err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } s := &session{ id: uuid.New().String(), requestQueue: make ( chan [] byte , 65536 ), responseQueue: make ( chan [] byte , 65536 ), } sessions.Store(s.id, s) go func () { scanner := bufio.NewScanner(stdout) for scanner.Scan() { s.responseQueue <- scanner.Bytes() } }() defer func () { sessions.Delete(s.id) _ = cmd.Process.Kill() _ = cmd.Wait() close (s.requestQueue) close (s.responseQueue) }() _, _ = fmt.Fprintf(w, "event: endpoint \n data: %s \n\n " , fmt.Sprintf( "http://%s/messages?sessionId=%s" , r.Host, s.id)) flusher.Flush() for { select { case data := <-s.requestQueue: _, _ = stdin.Write(data) case data := <-s.responseQueue: _, _ = fmt.Fprint(w, fmt.Sprintf( "event: message \n data: %s \n\n " , data)) flusher.Flush() case <-r.Context().Done(): return } } }) mux.HandleFunc( "POST /messages" , func (w http.ResponseWriter, r *http.Request) { id := r.URL.Query().Get( "sessionId" ) if id == "" { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } sany, ok := sessions.Load(id) if !ok { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } s := sany.(*session) var rawMessage json.RawMessage if err := json.NewDecoder(r.Body).Decode(&rawMessage); err != nil { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } var mcpMessage MCPMessage if err := json.Unmarshal(rawMessage, &mcpMessage); err != nil { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } if verbose { log.Printf( "%s: %s" , id, mcpMessage.Method) } s.requestQueue <- rawMessage s.requestQueue <- [] byte ( " \n " ) w.Header().Set( "Content-Type" , "application/json" ) w.WriteHeader(http.StatusAccepted) _, _ = w.Write([] byte (http.StatusText(http.StatusAccepted))) }) mux.HandleFunc( "GET /healthz" , func (w http.ResponseWriter, r *http.Request) { w.Header().Set( "Content-Type" , "text/plain; charset=utf-8" ) w.WriteHeader(http.StatusOK) _, _ = w.Write([] byte (http.StatusText(http.StatusOK))) }) listener, err := net.Listen( "tcp" , address) if err != nil { log.Fatalf( "failed to listen: %+v" , err) } server := &http.Server{ Handler: mux, } server.SetKeepAlivesEnabled(keepAlive) go func () { defer func () { if err := recover (); err != nil { log.Printf( "panic: %+v \n %s" , err, debug.Stack()) } }() if err := server.Serve(listener); err != nil && !errors.Is(err, http.ErrServerClosed) { log.Fatalf( "failed to listen: %+v" , err) } }() quit := make ( chan os.Signal, 1 ) signal.Notify(quit, syscall.SIGTERM) <-quit time.Sleep(time.Duration(lameduck) * time.Second) ctx, cancel := context.WithTimeout(context.Background(), time.Duration(terminationGracePeriodSeconds)*time.Second) defer cancel() if err := server.Shutdown(ctx); err != nil { log.Fatalf( "failed to shutdown: %+v" , err) } } 開発当時はStreamable HTTP TransportがなかったのでSSE Transportにのみ対応しています。 それでは実装を軽く解説していきます。 セッションの開始 SSE Transportはこちらの仕様の通り、 /sse のようなSSEのエンドポイントで初回のリクエストを受けると、ペイロードを受け取るための別のエンドポイントを event: endpoint として返す必要があります。 github.com mux.HandleFunc( "GET /sse" , func (w http.ResponseWriter, r *http.Request) { w.Header().Set( "Content-Type" , "text/event-stream" ) w.Header().Set( "Cache-Control" , "no-cache" ) w.Header().Set( "Connection" , "keep-alive" ) flusher, ok := w.(http.Flusher) if !ok { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } <snip> _, _ = fmt.Fprintf(w, "event: endpoint \n data: %s \n\n " , fmt.Sprintf( "http://%s/messages?sessionId=%s" , r.Host, s.id)) flusher.Flush() <snip> } これはSSEがサーバからクライアントにメッセージを送信するための一方向の仕組みであるためです。 developer.mozilla.org そのためSSE Transportでは2つのHTTPエンドポイントを実装することで、MCPクライアントとの双方向通信を実現しています。 もう一つのエンドポイントの実装は後述するため、ここではSSEのエンドポイントのみ解説します。 sessions := &sync.Map{} mux.HandleFunc( "GET /sse" , func (w http.ResponseWriter, r *http.Request) { <snip> s := &session{ id: uuid.New().String(), requestQueue: make ( chan [] byte , 65536 ), responseQueue: make ( chan [] byte , 65536 ), } sessions.Store(s.id, s) <snip> defer func () { sessions.Delete(s.id) <snip> close (s.requestQueue) close (s.responseQueue) }() <snip> } UUIDを発行してセッションを開始しています。 ここで開始されたセッションはMCPクライアントに通知したペイロードを受け取るためのエンドポイントからも利用するため、一つ上のスコープで sessions として保持します。 コマンドの起動 セッションの開始と同時にstdio Transportを実装したMCPサーバの起動もしましょう。 注意点として、stdio Transportで実装されたMCPサーバは内部で状態を持つため、多くの場合セッションごとにMCPサーバを起動する必要があります。 sessions := &sync.Map{} mux.HandleFunc( "GET /sse" , func (w http.ResponseWriter, r *http.Request) { <snip> cmd := exec.Command(name, arg...) stdin, err := cmd.StdinPipe() if err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } stdout, err := cmd.StdoutPipe() if err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } if err := cmd.Start(); err != nil { http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError) return } go func () { scanner := bufio.NewScanner(stdout) for scanner.Scan() { s.responseQueue <- scanner.Bytes() } }() defer func () { _ = cmd.Process.Kill() _ = cmd.Wait() <snip> }() <snip> for { select { case data := <-s.requestQueue: _, _ = stdin.Write(data) case data := <-s.responseQueue: _, _ = fmt.Fprint(w, fmt.Sprintf( "event: message \n data: %s \n\n " , data)) flusher.Flush() case <-r.Context().Done(): return } } } stdio TransportのMCPサーバの標準出力を s.responseQueue を介してMCPクライアントに通知し、セッション開始時にMCPクライアントに通知したペイロードを受け取るためのエンドポイントから送信される s.requestQueue から受け取ったリクエストは stdin.Write(data) で標準入力に書き込んでいます。 セッション終了時にコマンドを終了することも忘れないようにしましょう。 ペイロードを受け取るためのエンドポイントの実装 mux.HandleFunc( "POST /messages" , func (w http.ResponseWriter, r *http.Request) { id := r.URL.Query().Get( "sessionId" ) if id == "" { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } sany, ok := sessions.Load(id) if !ok { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } s := sany.(*session) var rawMessage json.RawMessage if err := json.NewDecoder(r.Body).Decode(&rawMessage); err != nil { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } var mcpMessage MCPMessage if err := json.Unmarshal(rawMessage, &mcpMessage); err != nil { http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } if verbose { log.Printf( "%s: %s" , id, mcpMessage.Method) } s.requestQueue <- rawMessage s.requestQueue <- [] byte ( " \n " ) w.Header().Set( "Content-Type" , "application/json" ) w.WriteHeader(http.StatusAccepted) _, _ = w.Write([] byte (http.StatusText(http.StatusAccepted))) }) こちらはシンプルで、クライアントに通知したメッセージをもとに sessionId が送られてくるため、そこからセッションを取得し、送られてきたペイロードをそのまま s.requestQueue に流しています。 前述の通り s.requestQueue に送信されたペイロードはセッションごとに起動しているコマンドの標準入力に書き込まれます。 ここまでのシンプルな実装で、stdio Transportのみに対応したMCPサーバを無理やりSSE Transportに対応させることができました。 後はこんな感じで使えばよさそうです。 FROM ghcr.io/lifull/keel/mcp-stdio-proxy:main AS mcp-stdio-proxy FROM ghcr.io/github/github-mcp-server@sha256:fdf04e33b437c523d2f091b7bf8dc3724c88dbf9913d6568f12f0fcf48aaff95 COPY --link --from=mcp-stdio-proxy /usr/local/bin/mcp-stdio-proxy /usr/local/bin/mcp-stdio-proxy ENTRYPOINT ["/usr/local/bin/mcp-stdio-proxy", "/server/github-mcp-server", "stdio"] まとめ このようにLIFULLでは比較的安全にMCPサーバを動かしています。 過渡期ゆえの混沌のような気もしますが、ほどほどのハックで秩序を手に入れられた気がします。 SSE Transportには負荷分散がしづらいという問題があり、それを受けてStreamable HTTP Transportが開発されるなど、MCPはまだ進化の途上です。 セキュリティに気を配りながらこれからもMCPを使っていきたいです。 コミュニティの実装も大分増えてきていて、我々が開発する無限にスケールする汎用AI(仮)にもMCPクライアントを実装して、Function CallingとMCPのエコシステムを統合したマルチエージェントで真の汎用AIを目指しています。 プラットフォーマーとしてのLLMにまつわる活動に興味がある方がいれば、是非カジュアル面談させてください！ hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 今回は、弊社が運営する不動産・住宅情報サービス「LIFULL HOME'S」において、 数理最適化技術を適用 して事業指標の向上に挑んだプロジェクトについて紹介します。どのようにプロジェクトを推進したのかや、推進する過程で得た知見についても、お伝えしたいと思います。 プロジェクトの概要 フェーズ1「企画段階」での取り組み フェーズ2「データ準備段階」での取り組み フェーズ3「モデル開発段階」での取り組み フェーズ4「効果検証段階」での取り組み おわりに プロジェクトの概要 LIFULL HOME'Sでは、不動産会社から物件広告をお預かりし、物件を探すエンドユーザへ届けるサービスを展開しております。不動産会社は自社の物件広告を多くのユーザに閲覧してもらいたいと希望する一方、エンドユーザは自分にぴったりでより魅力的な物件を見つけたいという双方の要望があります。そこで双方の視点を考慮し、 全体として最適な広告表示の制御を実現 するべく、数理最適化モデルを適用するという挑戦をしました。 本プロジェクトでは 事業部と研究開発組織であるデータサイエンスグループが連携する取り組み となり、私はプロジェクトマネージャとして全体を推進する役割を担いました。プロジェクトの進め方として、 データサイエンティスト協会 および 情報処理推進機構（IPA） が公開しているデータサイエンス領域に関するタスク構造図（プロジェクトフロー）を参考にしました。以下の図はそのタスク構造図をベースに自分なりに解釈して作成した AIプロジェクトフロー になります。 プロジェクトを推進する上では、取り組むべきことが多岐にわたり、関係者の数も多いことが、難しさの一つでもありました。特に、社内でAI関係のプロジェクトに関する知見やノウハウが豊富に蓄積されている訳ではないため、どのようにプロジェクトを進めれば良いのかの 進め方のイメージが関係者でバラバラ でもありました。そのため、誰がどのような役割をどの段階で遂行すれば成功するのかを共有するために、下記に示すように チーム体制図や期待する役割を図で可視化 をして関係者に共有をしました。 ここからは4つの各フェーズでの取り組みについて、どのように進めたのか、どのような難しさがあったのか、どのように乗り越えたのか、をご紹介していきます。なお、本来はフェーズ1から順番にフェーズ4まで進めるのが想定の流れではありますが、プロジェクトの目標期日の関係で各フェーズで独立に進められるところを見つけ、可能な限り並行して進める工夫をしました。 フェーズ1「企画段階」での取り組み まず、最適化対象となった箇所において、 どのような課題感があるのか事業部へのヒアリング から始まりました。ここでは過去データからの事実や考察（推察）など客観的な情報と主観的な情報が混ざるため、それらを整理していきました。そして、ヒアリングした情報から実際にデータを確認して、どのような状況になっており、どのような課題があるのか特定をしていきました。 そして、課題に関連する指標を向上させるために、何が必要なのか要素を分解していきました。最適化をしたとして、 どのようなメカニズム で指標が向上するのか、といったモデル化をしました。ここでのモデル化は、フェーズ4における評価方法にも関係しますし、そもそもフェーズ3でどのような最適化モデルを作成するのか、そのためにフェーズ2でどのようなデータが必要なのか、と全てのフェーズに関連するため、 非常に重要なプロセス と捉えています。 次に、どのような最適化であれば許容されるのか、最大化したい目的関数や制約条件に関して合意形成に取り組みました。なお、この段階ではあまり専門用語を使うと会話のハードルを引き上げてしまうため、可能な限り数理最適化を意識させるような 専門用語は使わないように留意 しました。本プロジェクトは関係者が多く、色々な思惑があるため、この部分が かなり苦労したプロセス になりました。また、掘り下げてヒアリングをしていくと、時には具体的な要望を引き出せる一方で強い制約にもなってしまうため、本当に気にしているポイントはどこなのか、どのような世界観を実現したいのかを重視してヒアリングするように努めました。その意志を尊重し、最適化問題として定式化した上で、その目指したい方向性に近づけるための最適化であることを 丁寧に粘り強く説明 を重ねました。 最後に、どのように最適化を適用するのか、 データフローやシステム全体の概要を整理 しました。下図はその一例です。なお、プロジェクトを推進するにあたって作成した図は、関係者とのコミュニケーションをする上で終始使うことが多かったです。関係者が多い中で、一丸となって推進するためには、全員で共通のゴールイメージを持ち、そのゴールに辿り着くために何が必要か共通のイメージを持てることが重要です。図を描くということは、時間を要する一方で、自分自身の思考整理に役立ちますし、共通認識を醸成するのにすごく有効な手段であると考えており、私は重要視しています。 フェーズ2「データ準備段階」での取り組み フェーズ1で検討した施策内容に基づき、フェーズ2では後段のフェーズで必要なデータを準備します。単に「データ」と呼ぶだけだと何を指すのか、 人それぞれ「データ」の解釈が異なる こともあるため、どのような種類のデータがあるのかという整理が重要なプロセスでした。下図に整理した結果を示しておりますが、大別すると4種類のデータがあり、それぞれ誰が作るのか、誰が扱うのか、が異なります。これらを意識せず「データ」とだけ表現してしまうと混乱を招くため、この整理をしたことで認識齟齬の発生を防ぐことができました。 フェーズ2では、主にデータソースからデータマートを作成しました。まず、データマートとして何が必要なのか要件を整理した上で、データソースとして何を使うのか調査検討をしていきました。そして、データマートとして加工していくためのパイプライン処理を実装していきました。様々なデータソースからデータマートが作成されるため、タイムスケジューリングも重要でした。最適化の実行タイミングは早ければ早いほど良かったため、何時にどのデータが揃い、どの時点でデータ作成ジョブを実行すれば、何時にデータマートが完成するのか、関係部署との調整をしていきました。 また、データソースの特徴を理解していくにつれて、 イレギュラーなデータが存在 することもわかってきました。たとえば、欠損値や、暫定的に入力された仮の値が入っている、人間が見ると解釈できるものの意図しない箇所に値が入っている、などがありました。しかし、そのままでは最適化ができなくなってしまうため、どのような値で補完すれば最適化をする上で問題がないか、最適化側の要件を踏まえて対応策を練りました。 結果的に、フェーズ2はプロジェクト全体の中でも 時間を要したフェーズ となりました。改めて、データを活用しやすい形かつ正しく形で維持するための、データ整備の重要性を実感しました。 フェーズ3「モデル開発段階」での取り組み フェーズ3では、フェーズ1で決定した目的や要件、フェーズ2で準備したデータをもとに、 数理最適化モデルの作成 に取り組みました。下図は数理最適化処理の全体の流れを表しており、大別すると4段階の処理がありました。 この流れの中で、③の数理最適化はもちろん重要なのですが、その 成否を分けるのは①の定数推定 でした。①の定数推定が誤っていると、どのように最適化をしたとしても、結果的に誤った制御になってしまうためです。①では、推定に用いるデータはどのような特性があるのか、探索的データ分析（EDA）から始めました。何をするにしても「 まずはデータの特性を理解する 」というのは基本中の基本です。その上で、どのような特徴量を作り、どの程度の推定精度になるのか、評価実験を重ねました。また、時系列で見た時に値が0が多いが突発的に値が上昇する指標については、値自体を推定が難しく、0か非0なのかを推定する問題にするなど工夫も重ねました。 ②の前処理は現実時間で③の数理最適化を実行するための工夫になります。愚直に解こうとすると、 現実的な時間で求解 できず、最適化結果を制御に使うことができない状況でした。そのため、問題の分割や、数理最適化を適用しなくても良い領域を定義するなど、 計算量を削減する工夫 をしました。 ③の数理最適化では、ビジネス的な制約（要望）を考慮した上で、定式化に取り組みました。定式化をする上では、非線形性をどのようになくしていくか、求解可能性をどう担保するのか、という観点で苦労をしました。さらに、事業構造を理解した上で、どのように定式化するか、 数理モデリングの難しさ を特に感じました。数理モデリングというのは 具体的な事象を抽象的に単純化して表現 するので、「本当にこれで適しているだろうか」という不安がつきまといました。定式化の検討をしては、事業部側の意向を考慮できているか、意図した最適化になるかの確認をし、 喧々諤々と議論 を重ねました。 ④のオフライン評価では、 フェーズ4で本番適用をして良いのかを判断 するための重要な段階でした。仮定を設定し、過去実績を用いたシミュレーションにより、オフライン評価をしました。どの程度の効果があるのかを事前検証するために、 従来手法と今回の最適化手法の比較評価 をしました。オフライン評価を通じて、想定通りの制御になっているか、どの程度の機会効果が見込めそうかを改めて確認しました。③で定式化をした時と想定通りの評価結果になった時はとても心地良さを感じ、チーム内で喜びを分かち合い、これで本番のオンライン評価でもいけると確信を得ました。 フェーズ4「効果検証段階」での取り組み フェーズ4では効果検証をするために、まずは 数理最適化システムのプロトタイプ実装 をし、その上で 評価実験 をしました。 フェーズ3で作成したのは数理最適化処理のコアな部分だったため、それをシステムとして動作させるための環境整備や運用体制の整備をしました。また、どのような異常が発生しうるか、その際にどのように対処するかも、整理していきました。 弊社では施策評価をA/Bテストで評価しており、今回もA/Bテストをしました。向上させたい指標（Goal metrics）と、低下を防ぎたい指標（Guardrail metrics）を決め、さらに意図した制御をしているか確認するための指標（Other metrics）を定義しました。今回の評価実験では下図に示すように、既存手法であるAと最適化手法であるBで干渉し合うという性質がありました。そのため、 A/Bテストだけでは判断がつかない可能性 があったため、Other metricsを注視すると事業部側と事前に合意形成をしました。 A/Bテストを通じて、 意図通りの制御になっていることが確認 でき、数理最適化システムは本番適用されることになりました。一方、当初の想定通り、A/Bテストでは明確にGoal metricsで差が出ず、「良さそうだが本当に効果があったのか」と はっきりしない状態 でもありました。 そこで、 A/Bテスト適用前と適用後の前後比較 をすることで、効果の推計に挑みました。A/Bテスト適用前と適用後では、外部環境も異なることになるため、単純な比較では正しく推計ができません。そのため、過去の実績データがA/Bテスト適用前と並行トレンドであることを仮定した上で、 差分の差分法を用いて効果推計 をしました。 前後比較による効果推計の結果、上図のイメージ図のように、向上させたい指標で明確な差が生じることを示すことができました。 おわりに 今回の記事では、 数理最適化 というアプローチを用いて、多くの関係者の要望や運用上の制約を考慮した 全体最適制御に挑戦 した取り組みを紹介しました。多様なニーズに応えることができる画期的な数理最適化システムを実現できたと自負しております。数理最適化は今後のLIFULL HOME'Sにおけるサービス改善の基盤となる技術であることを示すことができ、データサイエンスを活用した 新たな技術応用の可能性を示唆 する結果となりました。 また、プロジェクトを成功に導くにあたり、どのようなプロセスでプロジェクトを推進してきたのか、についても紹介をしました。各フェーズでどのように 創意工夫 をしてきたのか、少しでも読者のみなさまの参考になると嬉しいです。 引き続き、数理最適化をはじめとする有用な技術の開発や活用をしていき、より魅力的なLIFULL HOME'Sの実現に向けて邁進していきたいです。今後の取り組みも発信していきたいと思いますので、是非楽しみにしていて下さい。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速して下さる シニアデータサイエンティスト（R&D） を募集しています。 興味を持っていただけた方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

エンジニアの志賀と申します。 LIFULL HOME'S の新築分譲マンション領域の開発を担当しています。 私の所属している開発チームでは、LIFULLのベトナム海外拠点であるLIFULL Tech Vietnam(以下LFTV)と協力しながら開発を行っています。 過去LFTVのエンジニアメンバーと仕事を進める中で、ブリッジエンジニアを通していました。 そのため開発者どうしはお互いをほとんど知らず、コミュニケーションもレビューのやりとり程度で、コミュニケーション量が不足していると感じていました。 相手のことを知る、理解しようとすることは円滑に業務を進めるための第一歩だと考えていたので、この課題を解消するために行った取り組みを2点紹介します。 英語での自己紹介会の実施 まず実施した取り組みは、開発メンバーどうしの英語による自己紹介会です。 あらかじめフォーマットを用意し、英語で事前に記入したシートを用い各自に発表してもらいました。 フォーマットとして、私たちのチームでは以下の項目を取り入れました。 自分の顔がわかる写真とアイコン ニックネーム、呼んでほしい呼称 趣味 経歴 得意なこと 仕事のやり方 大切にしている価値観 チームメンバーは自分にどんな成果を期待していると思うか？ 自由記述 内容はチームによってカスタマイズして良いと思いますが、取り入れて特に良かった内容を紹介します。 お勧めの自己紹介項目 自分の顔がわかる写真とアイコン 直接会う機会がない場合、チャットツール等のアイコンと実際の顔が一致しないということは、よくあることだと思います。 顔がわかることで、コミュニケーションを取る際の安心感が変わってくると考えているので、この情報は可能であれば必ず入れたいポイントになります。 ニックネーム、呼んでほしい呼称 ニックネームで呼び合えると距離がぐっと近くなりますし、自己紹介中にもコメント等でニックネームを投稿することで話しやすい空気を作りやすかったため、この項目はとてもお勧めです。 大切にしている価値観 仕事を進めていく上で相手が大事にしているものを知ることは、コミュニケーションを取る際にも非常に重要だと思います。 この項目があることで、今後のやりとりを円滑に進める手助けになるかと思います。 また自己紹介会の進め方とお勧めの2つのTipsがあるので、そちらも紹介します。 自己紹介会のTips 画面共有時に一工夫する 自己紹介会をする上でちょっとしたTipsとして、自己紹介をする人は必ず自己紹介用のフォーマットを画面共有し、今話している部分を選択等でハイライトすることをお勧めします。 英語が得意ではないメンバーが多い場合話し手、聞き手両方とも慣れていないため、今話している部分が追いやすいようにしてあげるだけでも内容に集中できるかと思います。 相手の母国語を使ってみる 自己紹介中に、挨拶等相手の母国語を含めてコミュニケーションをとると、お互いの距離感が縮まりやすかったです。 私たちのチームではベトナム後を母国語としているメンバーだったので、以下のような単語を織り交ぜることができます。 おはよう：Chào buổi sáng（チャーオブオイサーン） こんにちは：Chào buổi trưa（チャーオブオイチューア） こんばんは：Chào buổi tối（チャーオブオイトーイ） お元気ですか：Bạn khỏe không（バン コエ コンプ） ありがとう：Cảm ơn（カムゥン） 朝会用のスプレッドシート改善 私の所属している開発チームの朝会では、以下のような流れで実施しています。 アイスブレ−ク タスクの共有 目標の数値の確認 共有事項 上記の中でタスクの共有をメインに実施しているのですが、これまではLFTV側のメンバーはブリッジエンジニアのみが参加し、LFTV側のエンジニアの状況を共有する形で進めていました。 そこでブリッジエンジニアなしでも、LFTV側のエンジニアが朝会に参加できるように、朝会でタスク共有する際に利用していた、Googleスプレッドシートに一工夫することで実現しました。 GOOGLETRANSLATEの利用 やったことはシンプルで、「GOOGLETRANSLATE」を導入したことです。 今までは事前に日本語でスプレッドシートに各自タスクを記入していたのですが、その隣のセルに「GOOGLETRANSLATE」を利用して日本語を英語とベトナム語で翻訳したものを表示するように変更しました。 そうすることで、記入自体は今までと同様のコストでブリッジエンジニアの助けなしでタスク共有が可能になりました。 具体的に私のチームでは以下のように関数を利用しています。 = if ( セル番号 ="" , " ※左の列をベトナム語と英語に翻訳する数式アリ " ,GOOGLETRANSLATE ( GOOGLETRANSLATE ( セル番号, " ja " , " en " ) , " en " , " vi " ) & CHAR ( 10 ) & " --------------------- " & CHAR ( 10 ) & GOOGLETRANSLATE ( S50, " ja " , " en " )) 上記以外に工夫した点として、アイスブレークの内容やシートに記載されているタイトル等にも、同様に「GOOGLETRANSLATE」を適用されるようにしたことです。 アイスブレークの内容自体は必ず伝えなければいけない内容ではないと思います。 ただ、逆の立場で考えた時に不慣れな言語で会話が成り立っていると疎外感につながってしまうと考え、少しでも話題を共有できるようにアイスブレークの内容も極力共有できるようにしています。 また、細かい部分ではありますがシート内のタイトル等も翻訳されるようになっており、どこを見ても複数の言語で確認できる状態になっていることで言語の壁を感じないような環境を目指しています。 実施したことは非常にシンプルですが、ツールをうまく活用することで、以前よりも言語の壁を感じることなくコミュニケーションをとることができるようになりました。 最後に 私たちの開発チームで上記を実施することで、海外拠点のメンバーと毎朝顔を合わせてコミュニケーションをとることができています。 まだまだコミュニケーションをとる上での課題はありますが、第一歩は踏み出せていると思うので、引き続き改善をしていこうしています。 最後に、LIFULL ではともに成長していける仲間を募集しています。 海外拠点のメンバーと仕事ができる、貴重な環境でもありますので、興味がある方はよろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 「 Qiita Night～企業における生成AI活用～ 」というオンラインイベントで、LIFULLの軽量化GAIチームとして、 リーダーの廣瀬さん と登壇させていただきました。 YouTubeも公開されているので、ぜひご覧ください！ www.youtube.com 私は「LIFULLの内製生成AI基盤keelaiと普及戦略」というLT発表を担当しました。 www.docswell.com 個人的には、パネルディスカッションの中のみずほフィナンシャルグループのWiz Chatお悩み相談所の取り組みが気になりました。本部ビル内の食堂やカフェの中にプロンプトの悩みを相談をしているということで、自分たちも似た取り組みをした際に盛り上げ方を難しく感じていたので、細かいノウハウもお聞きしたかったなと思ってます。 その後の発展 実は発表の後にもいろいろと進展しています。発表前後に完成した機能で、発表できずに悔しい思いをしたものを書き残します。詳細な内容は、いつか各開発者から投稿してくれるはずです。 1つ目は小林さんの書いた記事の中の「今後の展望と課題」の部分にある内容です。ファイルごとにコーディングガイドラインを読み込んでレビューできるようになりました。これはコーディングエージェントと共通した設定ができ、一気通貫した開発体験が実現できています。「コアドメインでない部分はガイドラインを整備してAIエージェントに任せ、自分たちはコアドメインの開発に専念する」という未来を目指しての布石を打っています。 www.lifull.blog また2つ目として、まだ現時点で生成AIを利用しているわけではないのですが、browser-runnerというE2Eテスト機能も実装されています。これはChrome DevTools Recorder等で誰でも作れるテストケースが、リリースフローの各タイミングで自動で高速に実行されるというものです。将来的には自然言語でのテストケースの自動作成機能や、テスト失敗時の自動修復PRなどを構想しています。 LIFULLでは戦略DAYという、全体戦略や各部署の戦略を共有するイベントがあります。その中で、ほぼ全部署が生成AIを使った何かしらの取り組みを行おうとしていて、「もうこんなに時代は進んだのか」と驚きました。また、スライドの中の参考画像で、GPT-4oの画像生成も自然に使われるようになっていました。 最後に 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、プロダクトエンジニアリング部の鈴木です。普段はLIFULL HOME'Sの不動産会社向けプロダクト開発エンジニアのマネジメントを担当しています。 先日、社内ゼミ（勉強会）にて、障害対応時の心構えと障害対応訓練について共有しました。 このゼミは、プロダクトの開発・運用に関わるメンバーが抱える「もしシステム障害が起きたら、どのように対処すればよいのだろう？」という不安を解消し、適切な対応方法を学ぶ機会として開催したものです。 長年稼働しているシステムで有識者が少ない中、いくつかの障害を乗り越えてきた私たちチームの経験に基づいた障害対応について紹介します。 前編では障害対応についての基礎知識や心得について触れました。 www.lifull.blog 後編では、それらのスキルを実際にどのように身につけていくかに焦点を当て、チームで実施した障害対応訓練について話した内容をお届けします。 障害対応をどのように学んでいけば良いのか LIFULLでは様々な障害対応のマニュアルが用意されています。私たちのチームではこれらのマニュアルの読み合わせを行ってきましたが、実際の障害対応ではスムーズに動けないという課題がありました。これには主に3つの理由が考えられます。 障害対応のプロセスを頭で理解していても、実際に行動できるようになるには多くの課題があります。これらのスキルは実践を通じて習得できますが、実際のところ障害対応の場から学ぶことは簡単ではありません。 障害対応はあくまで問題を解決することが目的であり、学習の場ではないからです。さらに、緊迫した状況下での経験のみで全てのメンバーが成長できるとは限らず、全ての人が一定のレベルで障害対応ができるようになることは難しいと言えます。 実際にメンバーからも、「障害発生時にマニュアルを確認しようとは思い至らなかった」、「経験のない自分が役にたつと思えなかった」という声があがっていました。 それでは、障害対応はどのように学んでいけば良いのでしょうか。 障害対応訓練をやってみた 障害対応訓練とは『SRE サイトリライトアビリティエンジニアリング』では次のように説明されています。 新人は、ドキュメンテーションやポストモーテムを読んだり、トレーニングを受けることによってSREに関する多くのことを学べます。 本物のプロダクションシステムを実際に壊したり直したりすることで得られる経験はそれらに勝ります 私たちのチームでは、実践的なシナリオを通じて知識だけでなく、現場での対応力を高めることを目指し、障害対応訓練を実施しました。 障害対応訓練の流れ 事前準備 事前準備では訓練の目的、シナリオ、体制を決めます。 訓練の目的・概要： チームの課題に基づいて設定します シナリオ：発生する事象とその対応方法を事前に設定します 体制：障害対応メンバーと訓練運営メンバーに分け、役割を明確にします 訓練の目的は、日頃の障害対応や振り返りを観察し、チームが直面している課題に焦点を当てることをおすすめします。チームメンバーから何を課題に感じているかをヒアリングすることも効果的です。 例えば、私たちのチームでは以下のように目的を設定しました。 目的を設定した後は、訓練の概要を決めます。発生する事象の原因や影響範囲、訓練で対応をカバーする範囲を明確にします。私たちのチームが担当するプロダクトでは、障害対応時にはデータのリカバリが必要になることが多いため、それらを訓練に含めるかなどを検討していきました。 シナリオでは、発生し得る事象とそれに対して期待される対応を設定します。リアリティを出すために、実際と同等の開発環境で障害を起こし、訓練を行いました。 本番に近い流れができるように準備することで、実践的な訓練を実施することができます。 当日の実施 当日は、運営側からの不具合報告をきっかけとして、対応メンバーには普段どおりに、事象の確認・調査から対応を進めてもらいました。 訓練終了時間は先に決めておき、時間内にできるところまでとしたのもポイントのひとつです。 営業や広報部署なども社内ステークホルダー役は運営側で疑似役を担いました。 上長への報告・相談はもちろんですが、対応メンバーは社内ステークホルダーへの報告も行い、本番さながらの条件で訓練を実施しました。 また、記録係りは当日は休日をとっているという設定のもと、記録に徹するようにしました。 訓練中は、メンバーの様子をみながら、必要に応じて訓練運営側からサポートを行いました。 事後振り返り 訓練当日に記録した内容を元に、事実に基づいて振り返りを行いました。振り返りはKPTの形式で、障害対応と訓練自体とで振り返りの観点を分けて実施しました。 障害対応自体の振り返りの観点 いつ、なにが起きて、だれにどのような影響があったか チームの体制は適切だったか 適切に影響と原因の調査ができていたか 情報のキャッチアップ・共有・相談・報告は適切にできていたか ステークホルダーへの共有・連絡・相談は適切にできていたか 訓練のやり方・体制の振り返りの観点 役割の振り分けは適正だったか 記録係の動き方はどうだったか 障害対応の基本フローは体験できたと感じるか 振り返りを通じて改善点を明確にし、次回の訓練や実際の障害対応に役立てていきます。 まとめ 今回の社内ゼミ（勉強会）では、全体を通して障害対応時に重要なポイントとそれらをチームで実践できるようになるための訓練方法について共有しました。 訓練に参加したメンバーからは、「一度実施したことで自信になり、いざという時の対応力が向上した」「有事の際に自主性と積極性が高まった」などのポジティブなフィードバックがありました。 実際に、訓練以降に起きた障害対応でメンバーの対応スピードや自主性がアップしたことを私も実感しました。障害対応訓練を通じて、個人のスキルだけでなくチーム全体の結束も強化することができたと感じています。 障害対応の目的は、システムを直すことではなく、顧客への影響の低減・早期回復をすることです。特にエンジニアの場合、まずシステムを直すことに目が向きがちになると思いますが、大事なのは顧客のビジネスやユーザーに与える影響を軽減することです。 そのためには、企画とエンジニアが協力して対応していく必要があります。チームとして安定した障害対応を進めるために、ぜひ障害対応訓練を活用してみてください。 最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発とスポーツ関連の新規事業開発に携わっています。 今回、2024年度の人間中心設計専門資格認定制度に挑戦し無事にスペシャリスト資格を取得しました。 ここでは、試験のための事前準備とエンジニアとしてこの試験に挑戦した理由および人間中心設計（Human Centered Design＝HCD）に取り組む意義について考えを整理しました。 人間中心設計専門資格認定制度とは？ HCD-Net（人間中心設計推進機構）が人間中心設計に関して一定水準の能力を有する人材を専門家、スペシャリストとして認定する制度です。 その中で、HCDスペシャリストの受験資格は下記を想定されています。 人間中心設計の基本的な実務能力を持つ実務担当者 人間中心設計・ユーザビリティ関連の実務経験が2年以上 人間中心設計が主業務で5年未満の方や、デザイナーやエンジニアなどで兼務の方 このように、私のようなエンジニアも対象とされた認定資格であり、人間中心設計はエンジニアにとって必要なスキルの一つであることがわかります。 なぜ受験したのか 以前、 RESEARCH Conference 2024に登壇しました - LIFULL Creators Blog でも述べたように、UXエンジニアとして数年間にわたってHCDの取り組みを実践してきました。 この経験を第三者に評価されることにより、自分の知識とスキルの客観的な位置を確認し、キャリアの指針として信頼性を築きたいという思いから受験を決めました。 やっておくべきこと HCDスペシャリストの試験については公に多くの情報が出回っているため詳細は省きますが、私が試験準備として特に役立ったことを紹介します。 それは過去のプロジェクトの取り組みを「詳細に」記録しておくことです。受験時に提出するコンピタンスシートには、各大項目のコンピタンスを、3つの観点に分けて具体的かつ体系的に記述する必要があります。 目的と調査・評価設計の対象 体制と実施内容 工夫とアウトプット これまで参加してきたプロジェクトでは、HCDの目的や設計、その成果や課題を具体的な手法と関連付けて整理していました。具体的には以下の観点でドキュメント化し、管理していました。 調査設計（調査背景・目的、検証手法、検証対象、検証人数、検証期間） 分析設計（採用した分析手法、分析結果） ユーザー定義（採用したモデル化手法、活用したフレームワーク） デザイン設計（プロトタイプ・情報設計の考え方） 詳細にドキュメントを残していた理由は2点あります。   1. HCDの取り組みを正確に伝える 私たちの開発チームは多くのプロジェクト関係者が携わり、時にはメンバーが入れ替わることもあるため、情報共有が非常に重要です。   各種検証や分析プロセスを整理することで、チーム全体が一貫した一次情報を共有し、統一した理解を持つことを目指しました。   これにより、プロジェクト進行におけるコミュニケーションギャップを減らし、効率的な協力体制を築けるようになります。   2. 他チームへのHCDプロセスの伝達 具体的な手法や成果を整理しドキュメント化することで、他のプロジェクトや組織がこれを学び、参考にできることを期待しました。   私たちの開発チームはHCDプロセスにおいてまだ未熟な部分もあるため、基本的なステップも省略せず詳細に整理することを心がけました。   こうしたオープンな情報共有が、HCDプロセスの促進に少しでも寄与できればと考えています。   このようにドキュメントは他者への情報共有目的で作成しましたが、結果的に自身にとっても貴重な資産であることを改めて実感しました。 受けてよかったこと 受験を通して一番良かったことは、過去のプロジェクトでの経験を振り返ることで習得してきたスキルの確認と不足している知識の棚卸しができた点です。 具体的には、A6・A13のコンピタンスについて過去のプロジェクトでは十分に実践できず経験不足を実感しました。 A6. 新製品・新規事業の企画提案力（基本コンピタンス） ユーザー理解から生まれた視点、価値から生まれた新たなコンセプトを、関係者に提案し実現に向けて合意をとれる企画提案能力のこと アウトプットの例：ビジネスモデルキャンバス、ビジョン提案型デザイン手法、ピッチ資料、事業企画書、リサーチ分析結果 今回、ユーザーリサーチの結果を用いて企画提案する力もHCDの一部であることを初めて認識しました。直近の3ヶ月で実施した新規機能開発に向けたユーザーリサーチでは、このコンピタンスを意識し、ユーザーリサーチの結果を活用して提案を行うことに注力しました。 A13.　専門知識に基づく評価実施能力（基本コンピタンス） 人間中心設計（HCD）および関連する専門知識を用いて、製品・システム・サービスのユーザビリティ、ユーザーエクスペリエンス、ユーザーインタフェースなどの良し悪しの判断・指摘ができる能力のこと アウトプットの例：ヒューリスティック法、ウォークスルー法、タスク分析 A13に関しては、過去にユーザビリティ検証を何度も行ってきましたが、ヒューリスティック法やタスク分析などの体系的な方法論に基づいた分析には不十分であったと認識しました。今後は、ユーザーリサーチを進める際に最適な評価手法を事前に考慮し、実践していきたいと考えています。 エンジニアが取り組む意義 最後に、エンジニアとしてHCDに関する知識を持ちプロダクト開発に参加することの意義を考えてみました。 エンジニアは「どうやって作るか」という役割を担う上で、「なぜそれが必要なのか」という点を深く理解することが重要だと考えます。 ただ指示されたものを形にするのではなく、機能要件の本質を理解し、適切に足し算・引き算の提案を行うべきです。 足し算の提案：他にどのような実現方法があるかを提示する 引き算の提案：特定の機能が過剰な開発である可能性を示す そして、「なぜそれが必要なのか」という根拠を示すプロセスとしてHCDが存在すると考えています。「人間にとって使いやすいシステムとは何か」と考えていくプロセスに寄り添うことで、エンジニアはその過程で最適な解決手段を提案することができます。 結果として、ユーザー中心のプロダクト開発においてエンジニアが真の価値を創造する重要な役割を果たすことができるのではないでしょうか。 最後に LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

はじめまして、情報審査グループの山崎です。 今回は私たち情報審査グループが「データ」を仲介役として、エンジニア部門とともに協働したことをお伝えできればと考えています。 本記事ではコミュニケーションについてを軸にお伝えしますが、一般的な見解では無く私の個人的な感覚だけな点もあるのでご容赦ください。 エンジニアの方々に、私たちのような非エンジニアとのより良いコミュニケーションについて少しでも参考になれば嬉しいです。 関連して、エンジニア視点からの取り組み事例として以下の記事も併せてご覧ください。 情報審査グループの役割 取り組みの背景 情報審査におけるデータ活用 部門間連携での紆余曲折 認識のずれ タスク管理手法の違い チーム内での共通言語化 役割分担の明確化の重要性 他職種とのコミュニケーションでの学び 終わりに 情報審査グループの役割 情報審査グループでは「圧倒的な「安心」を提供する。」というビジョンのもと、以下のような業務を行っています。 ユーザーに向けて：掲載されている物件広告を正確に届ける 物件広告を掲載している不動産会社に向けて：正確な物件広告を掲載できるようチェックし問題があれば修正依頼をさせていただく 「募集が終了した物件広告を非掲載にする」という、いわゆる「おとり広告」対策に注力しており、2024年には第三者機関による調査では 物件鮮度No.1 を獲得しました。 取り組みの背景 LIFULL HOME’Sは「広告を掲載する”場”」を提供する不動産・住宅情報のポータルサイトであり、実際の物件を管理しているわけではないため募集中かどうかの情報を持ち合わせていません。 ユーザー等から「この物件は募集が終了している」という連絡を受けて、情報審査グループが電話で当該物件の管理会社に募集状況の確認をしていました。。 つまり、募集が終了した物件広告は、不動産会社が非掲載にする必要があります。 ですが毎日数百万もある物件に対して、人手のみでは対応できる件数が限られます。 そこで私たちは『データを活用して募集終了した物件を検知できれば、自動非掲載できるのでは！』とデータ活用に取り組むことになりました。 情報審査におけるデータ活用 とはいえ、当初は統一されたデータが無く、まずは物件毎に集計・分析できるデータ作りをゼロベースで始めました。 実際に物件を調査するメンバーと履歴の残し方から試行錯誤し、通報による調査や能動的な調査の結果等をデータ化することに成功した後、 より効率的に募集終了物件を非掲載にしようとエンジニアに協力をお願いする運びになりました。 以下、私たちがこれまでに実施してきた施策となります。 ・ 【ホームズ】管理会社との情報連携によるおとり物件対策 　LIFULLが直接不動産の管理会社と物件データを連携することにより、LIFULL HOME'S上の募集終了物件を速やかに非掲載にする仕組みです。 ・ 【LIFULL HOME'S会員さま限定】メンテナンス見える化ツールの詳細 | LIFULL HOME’S Business 仲介・管理 　特定の条件により募集終了物件を検知し、物件広告を掲載している不動産会社に確認を促すツールとなります。このメンテナンス見える化ツールを進化させ、募集終了物件をLIFULLが自動で非掲載にするシステムを開発しました。 ・ LIFULL HOME'S、自社開発AIによる「おとり物件」の検知・自動非掲載を開始 | 株式会社LIFULL(ライフル) 　蓄積されている物件広告のデータや、独自に行っている調査結果のデータを自社開発したAIに学習させることで、募集終了物件を検知し自動で非掲載にするシステムを開発しました。 こちらも併せてご覧いただけますと幸いです。 不動産広告におけるDX化とLIFULL HOME’Sの取り組み このように私たちは以下のような大量のデータを活用し、日々募集終了物件を検知できるようになりました。 過去のデータ 現時点のデータ LIFULLに無いデータは協力会社から入手 部門間連携での紆余曲折 募集終了した物件の検知・自動非掲載を開始するまで、部門間でのさまざまな違いに戸惑いながら歩み続けてきました。 認識のずれ 当初はこんな会話から始まりました。 ■例１ 開発メンバー：「SQLでデータ出しますね、クエリ教えてもらえますか？」 私たち：「（SQLとは何？）（クエリとは何？）」 ■例２ 私たち：「これって不具合ですか！？（大変だ！）」 開発メンバー：「●●で■■な事象で起きている不具合ですね・・・！」 私たち：「（意外と落ち着いている！）」 例１の会話は「言葉（専門用語）の違い」、例２の会話は「温度感の違い」になります。 例１のように、システムについての会話では誰もがわかりやすい表現が使われる場合もありますが、専門用語が使われる場合もあります。 システムの専門用語を別の言葉に置き換えたりすると、エンジニアがデータを扱う際に何のことか迷い、かえって工数がかかったり、誤ったデータ処理を行ったりすることも考えられます。 ただ私たちは開発に不慣れなメンバーであったため、当初は認識を合わせるのに苦労しました。 例２についてのポイントは”視点”でしょうか？ （私だけが感じているのかも知れませんが）大量のデータを中心に見ているエンジニアにとっては、私たちが思う以上にバグやエラーといったものに接していると思います。 逆に、私たちは『不具合なんてあり得ない！すぐ解決しないと！』と焦りがちで、エンジニアは『そう慌てないで』と見極める冷静さがあり、温度感の違いを感じることがありました。 タスク管理手法の違い エンジニア部門に何かお願いする際、簡単な内容でもJIRA等のタスク管理ツールを使ってチケット（証跡）で管理できる形で依頼していますが、私たちは『都度文章書いて、ステータス変更して面倒だな、、、』と思うことも正直いうとありました。 私たちの部署では口頭等でパパっと頼んで、サッと対応して解決ということもあります。 全てをチケット管理することに当初は手間を感じていましたが、この一見面倒なチケット管理が、やってみるとチームで物事を進めるのにいいことが分かりました。 いつ誰が何をどのように等の情報が人によって様々だったり、ずれやすい個々の意図を一致させる意思疎通を、フォーマット化されたチケット（データ管理）で行うことで明確になり、誰がみても同じ認識になるメリットを再認識しました。 記録に残れば言った言わないも防げます。 ■チケット管理するメリット 1. 情報の可視化 2. 工数管理がしやすい 3. 進捗確認がしやすい 4. 優先順位を付けやすい 5. 過去案件や類似案件を検索しやすい 6. 担当者が分かりやすい 等々 チーム内での共通言語化 あるエンジニアがチーム内の認識がずれないよう「言葉」について定義付けを行い表にまとめてくれたことがありました。 同様に、私たちもできる限りエンジニアと同じ視点でコミュニケーションできるよう、使う言葉や対応を揃えていくようにしました。 たとえば「賃料」や「面積」といったデータの列を指すとき、わたしたちは「項目」と呼んでいましたがエンジニア部門では ・BigQueryでテーブルのデータ構造を話す時には「カラム名」 ・AIモデル開発においては「変数」や「特徴量」 のように文脈に応じて言葉を使い分けていました。 お互いに齟齬が起きないよう、部門間で会話するときは「カラム名」で統一することにしました。 他にも「登録日」という言葉だけですと「物件の登録日」なのか？「データの登録日」なのか？分かりにくくなることがありますが、カラム名では「○○date」や「△△date」という言葉で明確に区別されているため、そちらの言葉を使うことにしました。 役割分担の明確化の重要性 また、私たちも簡単なクエリを書いたり、Excelで集計や分析ができるようスキルアップをしてきました。 そこで私たちは、エンジニアの手間を少しでも少なくするため「そのクエリなら私たちでも大丈夫です」とか「この集計はこちらでやっておきます」としたところ、逆に認識のずれが起こることもありました。 エンジニアが『この人たちは基本的な部分は大丈夫そうだな』と捉えてしまい、私たちが対応できなかったり理解できない部分までも「この点は皆さんであれば大丈夫だと思いますが」と説明を省かれてしまうことがあったのです。 『明確に分担した方がスムーズだったかも』と振り返った次第です。 他職種とのコミュニケーションでの学び 前述のような出来事を経て、あらためて私たちは以下の点について意識するようになりました。 専門分野の任せられるところは任せ、ゼロベースで話す 正確に伝えるため、使う言葉等の認識を合わせる システムやツール等の仕様をできる限り理解する 私は当初、良かれと思ってシステム等について把握している知識をエンジニアに伝えようとしたところ、逆に話がややこしくなってしまうことがありました。 今では専門家に任せられるところは任せ、私自身はゴール（やりたいこと、期日）をしっかり伝えた上で協力していくことが重要と考えるようになりました。 使う言葉については、何を指すか明確になっているシステムの専門用語に揃えるなど、言葉の認識を合わせることにより物事がスムーズにいくことが多かったです。 自分たちが使ってきた言葉の表現を変えることは、慣れないうちは戸惑うこともありましたが、今や「クエリ」という言葉を使わない日は無くなりましたし、慣れればなんてことはありません。 私たちがシステム等の仕様を理解することについては、細かい点まではともかく、システムが「できること」、「できないこと」といったポイントだけは理解すべきと考えています。 私たちのような非エンジニアは『人ができることはシステムもきっとできるはず！』『人ができないからシステムに期待している！』などと勝手な考えを持ちがちではないでしょうか？ そのため私たちは、まずゴール（やりたいこと、期日）を曖昧にせず「しっかり伝え」、 専門外だから理解できないのではと考えるのではなく、お互いに認識が合うように「説明すること」が重要だと思います。 たとえばデータ抽出において「AのテーブルとBのテーブルから必要なデータ自体は結びつけることができます。ただしBのテーブルが膨大な量のため、時間と費用が大幅にかかってしまうんです。」といったエンジニアからの説明を聞いて、私は「技術的には可能だが、事実上できないこと」を理解した場面もありました。 その後チームで次善の策を考え解決させ、お互いできること（それが”説明力”だったり”聞く力”だったりすると思いますが）を丁寧に実行していくことができたと思います。 LIFULL HOME'S、自社開発AIによる「おとり物件」の検知・自動非掲載を開始 では、外部ベンダーとして 株式会社リーン・ニシカタ 様にお力添えいただきました。 その際もコミュニケーションロスが起きた場面がありましたが、使っているテーブルやカラム名を双方が理解できるようリスト化したり、コミュニケーションがうまくいくよう臨機応変に工夫しました。 おかげでリスト化後のミーティングやトラブルが発生した時はスムーズに対応することができるようになりました。 終わりに このようにチーム内で紆余曲折しながらプロジェクトを進め、前述のような施策を行えるようになりました。 こちらの理解力が至らない場面でも毎回「わかりにくく申し訳ありません」という言葉と共に根気よく説明してくれた方々は、神のように感じました！ 「言葉の違い」や「温度感の違い」はそれこそ友人同士でも起き得るものだと思います。 大切なのは双方が歩み寄り、相手が何を伝えようとしているのか？を理解し合うことだと感じています！ 最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の千葉です。 LIFULL HOME'S不動産査定 と ホームズマンション売却 の開発に携わっています。 この記事では、売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介していきます。 売却査定サービスにおけるE2Eテストについて 環境 テスト観点 高速化の取り組み 背景 取り組み1 - 項目の精査と方法の最適化 取り組み2 - 処理の共通化 取り組み3 - ジョブの最適化 取り組み4 - 実行の並列化 取り組み5 - タイムアウト設定 結果 全体 Botでページを開いた際のHTTPステータスコード200の検証 モバイル端末でページを開いた際のHTTPステータスコード200の検証 PC端末での主要導線の確認 モバイル端末での主要導線の確認 まとめ 売却査定サービスにおけるE2Eテストについて 環境 売却査定サービスではE2Eテストを自動化するためのフレームワークであるTestCafeを使用したテストがデプロイ時と毎朝定時に実行され、実行結果がSlackに通知されます。 詳細については、こちらの記事をご覧ください。 www.lifull.blog テスト観点 以下の4項目についてテストを行っています。 Botでページを開いた際のHTTPステータスコード200の検証 モバイル端末でページを開いた際のHTTPステータスコード200の検証 PC端末での主要導線の確認 モバイル端末での主要導線の確認 高速化の取り組み 背景 E2Eテストの課題として、デプロイからテスト終了までの待ち時間の長さが挙げられました。 通常、テストの実行には30分以上かかり、場合によっては60分を要することもありました。 取り組み1 - 項目の精査と方法の最適化 主要導線の確認では通常、物件種別と所在地の入力から入力画面、会社選択画面、確認画面を経て、完了画面までの一連の流れをテストし、完了画面に遷移できることでテストの成功としていました。 この一連のフローで、各ステップにおいて次の項目を確認していることになります。 物件種別と所在地の入力を行うことで入力画面に遷移できること 入力画面で入力を行うことで会社選択画面に遷移できること 会社選択画面で会社選択を行うことで確認画面に遷移できること 確認画面から完了画面に遷移できること 物件種別や所在地に応じて入力画面の入力項目が変わるため、それに応じたテストをそれぞれ実施していました。 しかし、会社選択画面以降のプロセスは同じにもかかわらず、それぞれ完了画面までのテストを行っていたため、同様のテストを繰り返すことになっていました。 また、プロダクトコードの不備や画面読み込みの遅延で、必須項目が入力できず会社選択画面に進めない場合、以降のテストが実行できないという問題がありました。 さらに、TestCafeではユーザーの操作を模倣し、カーソルの移動、クリック、文字入力といった動作を通じてテストを行います。 そのため、1つのフォームの入力にも時間がかかります。 この問題を解決するために、以下のようにテストの役割を分割しました。 入力画面のテスト 入力画面で入力を行うことで会社選択画面に遷移できることを確認 会社選択画面のテスト 会社選択画面で会社選択を行うことで確認画面に遷移できることを確認 また、 会社選択画面のテストでは、入力画面での入力はDOM操作で行い、核心的なテストプロセスである会社選択画面ではUIテストを行うことで実行時間を削減しました。 各観点を独立したUIテストで実行することにより、物件種別と所在地の入力から完了画面に至る一連のフローテストはDOM操作を活用することにしました。 これにより、不必要なテストを排除するとともに、ユーザー操作のステップを省略し直接変更を行うことで、テスト実行時間の大幅な削減を実現しました。 取り組み2 - 処理の共通化 物件種別と所在地の入力では、たとえば「査定可能な会社が1社しか存在しないエリアにおいて、会社を選択しなくても確認画面に進める」というテストを実施したい場合、査定可能な会社が1社のみの所在地を入力する必要があります。 LIFULL HOME'Sをご利用の会員様（不動産会社様）の状況に応じて、各エリアの会社数は常に変動します。 このテストを実行するため、所在地の入力時には東京都⚪︎⚪︎区を入力し、会社数が2社以上の場合は次のエリア（東京都△△区）を入力し、さらに2社以上であればほかのエリア（東京都♢♢区）へと、期待した結果が得られるまで繰り返していました。 その結果、核心的なテストプロセス開始前の段階で削減可能な不要なコストがかかっていました。 さらに、この方法を複数のテストケースで同様に行っていたため、時間とリソースが無駄に消費されていました。 そこで、テスト開始前に会社が1社のエリアを特定し、そのうえでテストを行う処理を追加することでこの問題を解決しました。 取り組み3 - ジョブの最適化 4項目のテスト観点に対して、それぞれ1ジョブずつ合計4ジョブで実行していました。 ページを開いた際のHTTPステータスコード200の検証については、各3ジョブに分割し、主要な導線の確認は、UIテストとDOM操作によるテストの各2ジョブに分割しました。 これにより、全体で10ジョブとすることで1ジョブあたりの実行時間が削減され、全体の実行時間を削減しました。 一方で、ジョブが増えることでSlack通知が増えるという懸念もありました。 ジョブ1つにつき1つのメッセージがSlackチャンネルに投稿されていたため、自動テスト実行1回につき4つのメッセージが投稿されていましたが、これが10個になると情報を見逃してしまうリスクもありました。 そこで通知を改善しました。方法は以下の通りです。 CodeBuildのDOWNLOAD_SOURCEビルドフェーズ（テスト開始前にソースコードを取得するフェーズ）開始時に親メッセージを投稿する 各ジョブ終了時にそのメッセージのスレッドに返信を行う 失敗の場合はSlackの機能を用いて返信をチャンネルにも投稿する すべてのジョブが終了したら親メッセージを完了を示した文言で上書きする これにより、Slackチャンネルに流れるメッセージの数は減りつつも、自動テストの終了と失敗を見逃さないようなしくみにしました。 取り組み4 - 実行の並列化 1ジョブあたりの実行時間をさらに削減するために実行の並列化を行いました。 TestCafeの並列機能を使用して、複数のインスタンスを起動し、これらのインスタンス間でテストの作業負荷を分担することで実行時間を削減しました。 取り組み5 - タイムアウト設定 予期しない理由でビルドが途中停止してしまった際に60分経過するまで失敗通知が送信されないという問題がありました。 これはCodeBuildのタイムアウト設定を行っていなかったためです。 CodeBuildには設定した時間内にビルドが完了していない場合にビルドを停止する機能がありますが、何も設定していない場合はデフォルトで60分に設定されます。 タイムアウトを20分に設定することで、失敗が発生した場合でも迅速に結果を把握できるようにしました。 これにより、CodeBuildの実行にかかった時間に基づいた課金が軽減され、コストカットにもつながりました。 結果 取り組みの結果は以下の通りです。 実行時間には多少のばらつきがありますが、おおむね一定の時間で完了します。 実行時間を大幅に削減でき、高速化を実現しました。 また、E2EテストにかかるCodeBuildの月々のコストも約100ドルから約50ドルへと削減できました。 全体 改善前：31分0秒 改善後：11分45秒 Botでページを開いた際のHTTPステータスコード200の検証 改善前：13分23秒 改善後：7分59秒 モバイル端末でページを開いた際のHTTPステータスコード200の検証 改善前：13分53秒 改善後：8分2秒 PC端末での主要導線の確認 改善前：29分56秒 改善後：5分53秒 モバイル端末での主要導線の確認 改善前：20分6秒 改善後：5分39秒 まとめ 売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介しました。 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの小林です。 LIFULLで社内ABテスト基盤を開発しています。その開発の中で社内の生成AI基盤「keelai」を活用した取り組みを紹介します。 www.lifull.blog LIFULLではkeelaiという社内向けの生成AI基盤プロジェクトを運用しており、今回はこのkeelaiを利用したコードレビュー用のGitHub Actionsを実装した事例を紹介します。 www.lifull.blog 内製AI Agentによるコードレビュー GitHub Actionsを活用して実現したAIレビューのワークフローは以下の通りです。 コードレビューの概要 GPTやClaudeなどのAPIを利用せず、内製AI Agent「keelai」を活用した理由は以下のとおりです。 社内固有の知識を活用可能 - 社内ドメイン知識を持ったレビューが可能です 継続的な改善サイクル - レビューActionsとAI基盤の両方を社内で改良できます 柔軟なモデル選択 - 用途に応じて複数のAIモデルを使い分けるなど高度なカスタマイズが可能です 以上の点から、内製のAI Agentを利用することに価値があると思っています。 keelaiは社内向けアプリケーションとしてSlack botとしての利用と各システムからAPIとして呼び出せる2つのインタフェースを提供しています。 今回の記事では、GitHub ActionsからAPIとして呼び出して活用する方法に焦点を当てています。 弊社ではkeelaiを中心にして、社内ドキュメント参照機能や営業支援など幅広い活用を進めています。 この社内エコシステムと各種モデルの進化を組み合わせることで、LIFULLの技術スタックやドメイン知識に最適化されたレビューを期待しています。 keelaiについての詳細は以下を御覧ください。 www.lifull.blog 開発の背景 端的に述べると「 人が足りなかった 」からです。 当時所属しているチームの開発を行いながら、サブタスクとしてABテスト基盤のデモ実装を行っていました。 同期エンジニア3名でフロントエンド、バックエンド、集計バッチの3領域を得意分野で分担実装していましたが、以下の課題がありました。 本業務の合間を縫っての開発作業 チームメンバーの得意分野が異なるため、不得意分野のレビューに時間を要する すべての変更を人間が詳細にレビューする時間的余裕がない そこで、生成AIを使って最低限の品質維持のヒントになるようなレビューをできないかと考えました。 2024年秋ごろから話題になっていたCode Rabbitという生成AIレビューのSaaSを個人開発で利用していたこともあり、技術的な好奇心からも実装に踏み切りました。 実装プロセス 2024年3月時点でGitHub ActionsからkeelaiのAPIを呼び出せる環境が整備されていました。 当時所属していたチームで簡単な実験を行いました。 サンプルコードのレビュー実験 しかし先述した通り、個人的にCodeRabbitを利用していたため物足りなさを感じていました。 CodeRabbitの特徴としては以下の点が挙げられます。 日本語によるレビューコメント コード内インラインコメント機能 ただのコメントで複数のレビューが並べられてしまうと、どのファイル・どの行に対するレビューコメントなのかが追いづらくなってしまいます。 そのため、インラインコメントでレビューが返ってくることは被レビュー者にとって大きなメリットです。 そこでOSSを利用して手早く高機能なレビュー機能を用意することにしました。 Code Rabbitが旧バージョンのAIレビューシステムを ai-pr-revewer としてMITライセンスで公開していたため、これをフォークしてkeelai対応版として再構築しました。 keelaiは社内からの利用を前提とした認証になっています。 そのため、エンドポイントとAPI Keyの組み合わせでは利用できず、認証を含むクライアントを自作して差し替え、社内リポジトリで利用できるActionsとしてリリースしました。 社内普及まで 2024年8月にリリースを行い、ABテスト基盤チームの中で利用を開始しましたが、この時はまだgpt-4oがリリースされたばかりのころでした。 micro serviceが大量に存在する弊社全体での利用はコスト面でまだ現実的ではないとして数個のリポジトリで利用されるにとどまりました。 しかし、2025年2月にgpt-o3-miniがリリースされ、安い！賢い！早い！の3拍子であったため、弊社のkubernetes基盤KEEL用CLIであるkeelctlで全社配布することになりました。 keelctlについては以下を参照ください。 www.lifull.blog 機能 現状 PR要約 PRの内容を要約することで、レビュー者の認知負荷を下げます。 PRの要約 インラインレビューコメント コード内の該当箇所に直接コメントを付与し、メンションを付けて返信するとチャット形式で対話可能です。 インラインレビューコメント 社内の評価 実際の運用から得られた評価をいくつか紹介します。 指摘内容：タイムアウト実装の漏れ 「リリース後の運用中に発生した障害で気付くことが多いものなので助かりました」 指摘内容：200レスポンス処理の重複 「人間が指摘するときは手間な気分になるので機械的に指摘してもらえた方が楽」 指摘内容：Goの型キャスト 「Goでinterface型の変数をキャストして利用する際の注意点を指摘してくれました。Goに慣れてない人でも危険なコードに気付けるのが良いと思いました！」 今後の展望と課題 LIFULLにおけるAIコードレビューの実装までの流れと、現状の機能について紹介しました。 現在のシステムをさらに発展させるため、以下の機能拡張を計画しています。 リポジトリ固有のコーディング規約対応 各チームのスタイルガイドに沿ったレビューの実現 リポジトリごとの設定ファイルによるカスタマイズ 言語・フレームワークに特化したレビュー 各技術スタック特有の「ベストプラクティス」に基づく指摘 新しいバージョンのAPIや推奨パターンの提案 クロスファイル分析 複数ファイル間の整合性チェック アーキテクチャレベルの設計レビュー この記事ではAIによるコードレビューについて触れましたが、keelaiや関連プロダクトは社内コードがオープンであるため、新機能を思いついたらすばやく拡張できる環境にあります。 KEELチーム（プラットフォーム）、keelaiチーム、プロダクトチームの有志が一緒になって自分たちのニーズを考え、既存コードを活かして最小限の修正で対応可能な環境が整っています。 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

2024 年中途入社の福原です。 私の所属しているグループでは、毎週チーム全員で時間を設けて、メインとなるページのサイトパフォーマンスを監視・改善する活動を行っています。 今回はその活動の一環で、新築分譲戸建の物件詳細ページの LCP について、改善を行った結果を共有します。 LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間 課題特定 まずは Chrome の Lighthouse を使って計測し、数値の劣化原因を探りました。 指摘の中で最も影響が大きそうだったのは「適切なサイズの画像を使用していない」という点でした。 今回のページでは、カルーセル内に比較的大きい画像とサムネイル用の小さい画像を表示しています。 適切な画像サイズに修正することで、大きな効果が得られると考えました。 改善内容 適切な画像サイズの指定 LIFULL HOME'S には画像を適切なサイズに圧縮したり、WebP 形式に自動変換するしくみがありますが、 今回の対象ページでは使用されていませんでした。 www.LIFULL.blog 修正内容としては変数名の変更だけでしたが、それぞれに適切なサイズの画像を読み込むようになりました。 preload の削減 LCP の改善策として頻出する「 preload 」ですが、カルーセル内のすべての画像を優先的に読み込んでいたため、逆にページの初期表示が遅くなるケースがありました。 preload は 要素の rel 属性の値で、その HTML の の中で読み取りリクエストを宣言し、ページのライフサイクルの早期の、ブラウザーの主なレンダリング機構が起動する前に読み取りを始めたい、すぐに必要なリソースを指定することができます。 物件によっては 30 ～ 40 枚という大量の画像が表示されることもあるため、 優先して読み込むのは LCP の対象となる画像のみに絞ることにしました。 結果 今回の対応により、LCP が約 42%改善しました。 データ可視化ツールの Grafana で LCP を確認すると、ガクッと下がっていることがわかります www.LIFULL.blog 実際の画面を見ても画像の表示が速くなったと体感できるレベルでした。 まとめ 今回紹介した事例は、すでに提供されていた画像最適化に合わせたことが大きな改善要因のため、負債解消の意味合いが強いと感じています。 サイトパフォーマンスの改善はまだまだ継続していく予定のため、 次回は再現性のある事例を紹介できるよう、日々の業務に努めてまいります。 LIFULL ではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの高詰です。 LIFULLでは新卒入社2年目のエンジニアを対象にしたSET研修が開催されます。 SET研修は2年目の若手エンジニアが中心となりプロダクトをスクラッチから自分の手で開発することでWebエンジニアとしてステップアップすることを目的としています。 この記事では、研修での取り組みや研修中に直面した問題や学びについて紹介します。 SET研修とは 個人の目標設定 作成するサービスの検討 サービスの設計および実装 アプリケーション インフラ デプロイ 実装期間中のプロジェクト進行 実装期間を終えての反省点 学び 終わりに SET研修とは SET(Sophomore Engineers Training)は新卒2年目のエンジニア3〜4人チームでAWSや外部サービスを利用し、16営業日内に1つのプロダクトを作る研修です。期間及び予算は決まっていますが、それ以外はすべてチーム内で決める必要があります。 研修中のサポートは先輩エンジニアがメンターとなり開発相談やコードレビューを行います。他にも社内に数人いるベテランのスペシャリストエンジニアにいつでも相談できるようになっています。 SETは下記を目的として毎年行われています。 プロダクトを作る全段階を経験することでwebサービスの全体像を把握し、エンジニアとしての引き出しを増やす 業務では携わる機会がなかった分野に触れて幅広い能力を身につける 自分の苦手分野を正しく認識し、スキルセットのバランスを整える サポートメンバーのフォローを受けつつ、プロのエンジニアとしての知識を効率よく得る 研修の全体の流れは下記になっています。また、第一実装期間および第二実装期間は通常業務から外してもらえるので開発に集中できます。 個人の目標設定 作成するサービスの検討 サービスの全体設計 第一実装期間（8営業日） 第二実装期間（8営業日） 研修成果の社内発表 個人の目標設定 SET研修ではまず最初にメンバーそれぞれが研修を通して覚えたいことの目標を決めます。研修の目的に書いてある通り、通常業務では携わる機会がない分野や苦手な分野を中心に目標を設定することが推奨されています。 私の場合、通常バックエンドエンジニアとして既存のHOME'Sのプロダクトの改修や機能追加をメイン業務として行なっているので、個人目標には開発のベースとなる技術選定やインフラ部分に力を入れるような以下の項目を目標として設定しました。 技術選定及びインフラ設計の経験を積む デプロイの設定ができる サーバーの仕組みと設定が理解できる ミドルウェアを正しく実装できる 作成するサービスの検討 私たちのチームは交換日記サービスを選びました。 このテーマを選んだ理由としてはCRUDが満たせること、認証機能が必要であること、設計が複雑すぎないこと、メンバー全員の目標を満たせるテーマだったことです。 チームメンバーが3人いたので開発はそれぞれの個人目標を考慮し、インフラ及びサーバー担当、インフラ及びアプリケーション担当、アプリケーション担当の3つに分けました。私はインフラ及びサーバーを担当したので、開発期間前からサービス全体の設計の検討を行なっていました。 サービスの設計および実装 アプリケーション 今回開発したアプリケーションはMVC2パターンを採用しており、Expressを使用したモノリシックアーキテクチャで動作しています。 URLのルーティングに関してはDHH流のルーティングを参考にし、Controllerもそれに合わせて設計しました。 ModelはActiveRecordの考え方を参考にして開発しています。 View周りはPreactを採用しています。 今回はフロントエンド部分の開発を個人目標に入れているメンバーはいなかったので、View周りの設計やライブラリは最小限に抑えて他部分の開発により多くのリソースを割けるように調整しました。 データベースへのアクセスはTypeORMを利用することで型安全なデータ操作できるようにし、認証・認可には AWS Cognitoを活用してユーザー管理と認証を実装しました。また頻繁に必要になるデータはRedisを使ってアクセスすることでレスポンス速度を上げるように心がけてプロダクトを作りました。 インフラ AWS構成 インスタンスはシステム全体の管理のしやすさ及び再現性を担保するためCloudFormationを用いてリソースを構築しました。 サポートチームへ相談する際もgithub上でのコードを確認してもらうだけで済んだので効率よく開発を進めることができました。 設計面ではウェブサーバとアプリケーションサーバを分けることで、ウェブサーバのキャッシュ機能やプロキシ機能を使って効率よくリクエストをさばき、アプリケーションサーバに不要な負荷がかからないように注意しました。 静的ファイルはS3を使ってクライアントに返すことで高速化も図っています。 AWS CloudFrontを使う案もありましたが、時間の関係で今回は実装していません。 アプリケーションはDockerを使って開発していますが、勉強のためあえて便利なECSは使っていません。 ログ周りやインスタンスが落ちた際の設定、セキュアな環境変数の渡し方などの工夫が必要なEC2を用いてデプロイしました。 EC2で実行されているDockerが何らかの原因で止まってしまった時に再実行できるような設定や、CodeDeployなどのAWSサービスに対応できるように設定したAMIを作成し、インスタンスが落ちてしまった際も自動で早く立ち上がるための工夫もしています。 デプロイ 研修期間が短いので効率よく開発サイクルを回せるようにAWSのCode Pipelineを用いて自動デプロイを実現しました。 EC2を使っているためデプロイは以下の手順で進行します。 研修用に立ち上げたリポジトリにmainへのpushを検知すると自動的にコードをビルド ビルドに問題がなければECRへDockerイメージをプッシュ EC2インスタンスを新しく立ち上げ、Dockerイメージ及びAWS Secret Manager環境変数を取得し、イメージを実行 Blue/Greenデプロイで旧インスタンスと新インスタンスを入れ替える 上記手順に何か問題があった場合はデプロイ開始前のバージョンに切り戻す デプロイ結果はSlackに通知が届くように設定したので、研修中はコードの実装に集中できるようなりました。 実装期間中のプロジェクト進行 Github Projectの画面 プロジェクト進行のマネジメントはGithub Projectでやるべきことをissue化し、ガントを引いて管理しました。 実装期間前にひとり一人が担当する実装箇所や設計のすり合わせを行うことでスムーズに研修開始時と同時に開発を始めることができました。 実装期間中は毎日チームメンバーで10分ほどの朝礼を行いました。 前日の進捗及び当日やることについて報告を行うことで、何か困っているメンバーがいないかを確認し、期間中に終わらなさそうなものがあれば優先順位の変更を行い、メンバー全員の目標を満たしつつ最低限動くものを提出できるようにタスク調整しました。 また、第一実装期間と第二実装期間の間にメンバー内で振り返り会を行うことで開発中に起こった問題点を洗い出し、改善策を一緒に考えることで第二実装期間のタスクマネジメントをより良い方法で行えたと思います。 実装期間を終えての反省点 個人的な反省点は大まかに以下の3つです。 要件定義や画面構成の認識合わせが足りていなかった点があったので、詳細なところまで文章化するべきだった 何を決めるにしても明確な数字を出すべきだった タスク見積もりが甘く、思ったより時間がかかることが多かった ①に対しては口頭で話し合っていても各自のイメージが違っている可能性を考慮していなかったことです。 忘れることや記憶違い、認識違いが発生していたので実装開始前のサービスの検討のフェーズでメモだけではなく詳細にプロダクトのイメージを文章化すれば避けられた問題だと思いました。 ②については①の問題と関わってくるのですが、何か依頼する際には明確な数字を示さなかったことが原因でチーム内で問題が起きました。 「多め」や「なるはや」などの曖昧な言葉の解釈は人によって違うので、定量や日時を明確にした上で進めるべきでした。 ③に関してはお互いに初めて使うツールや設計で開発したので、開発期間で実際手を動かしてみると想定した以上に時間がかかることが多発しました。 タスク分割が大きいということに気づけないまま実装期間に進んでしまったので、極端に負担がかかり過ぎているメンバーが生じたり、期間内に終わらせることができないことが途中で発覚するなどの問題が起きました。 この問題についてはプロダクトマネジメントを経験しないとわからない部分だと思うので今回は大変貴重な勉強機会でした。 研修で問題点に気がつけたことで本業務ではもっと精度が高いスケジュールの見積もりができるようになると思います。 学び 本業務ではあまり携わる機会のなかったAWSの各種サービスを活用し、インフラ構築やデプロイフローの設計を経験することができました。 これによりWEBシステム全体の管理や運用、プロジェクト進行の経験と知識を身につけることができました。 また、普段の業務ではどれだけ整備された環境で開発しているのかを体感することができました。 結果としては最初に目標で設定していたことは研修を通してすべて達成できました。 開発のベースとなる部分の設計と実装を担っていたので、他のメンバーの実装に支障が出ないように速度と正確さを求められるポジションだったと感じました。 特に技術選定に関しては最後まで悩むことが多く、自身のアプリケーションの特性を深く理解した上で各技術のメリット・デメリットを考慮し、選択する必要があることを痛感しました。どんな技術を選んでもデメリットは必ずついてくるものなので、与えるインパクトを十分に理解した上で許容するのか、対策を考えるかなどのアクションが必要になってくると思います。 AIが発達し、自動でコードを生成してくれる今ではエンジニアは自分が作っているアプリケーションが持ちうるリスクを想定し、考慮した上で対処方法の設計できるかが大切なんだろうなと思った次第です。 終わりに この記事ではSET研修で取り組んだことや反省点と学びについて振り返りました。 周りについて行くことに必死だった1年目が終わり、ようやく自分が好きなことや興味があることが明確になってきた2年目のタイミングでSET研修に参加できたのは大変貴重な経験でした。 メンターとサポートチームに幾度も助けられながら大幅に成長できた２週間超でした。個人的には設計や実装に悩む時間を思う存分に楽しめたのでSETに参加して本当に良かったです。 一人前のエンジニアとして活躍できるようにこれからもインプットとアウトプットを重ねてスキルアップしていきたいです。 最後になりますが、LIFULLでは一緒に働く仲間を募集しております。よろしければぜひこちらのページもご覧ください。 hrmos.co hrmos.co