サントリーウエルネスサービス事業部の相川です。自社アプリComadoへのレコメンド機能の導入を目的とした、パーソナライズプロジェクトの推進を担当しました。プロジェクトの立ち上げ〜推進していく上で、個人的に気をつけたことや肝になったと思うことについて記したいと思います。1. はじめに 今回の記事の位置付け タイトルにもありますが、入社3年目ではじめてPLというプロジェクト推進を担当する立場になり、諸々試行錯誤しながら頑張ってみたというお話になります。そのため、推進ガチ勢の皆様からすると当然すぎることや的外れなことも散見されるかと思います。ご容赦ください。 逆に似たような状況の方にとっては何か参考となる情報があれば幸いです。宣伝 私はサントリーホールディングスのデジタルテクノロジーコースに新卒で入社し、今年で3年目になります。 基本的なデジタル研修を経た後にサービス事業部に配属され、Comadoの集客施策担当や簡単なデータ分析等の業務経験を積んできました。ザ・エンジニア以外にもこういうサービスに関わる仕事があるんだ〜という仕事紹介にもなるかなと思うので、本記事でご興味を持ってくださった方は是非ご検討ください。サントリー新卒採用_デジタル＆テクノロジー部門Comadoにあるお仕事については他記事でも触れられているので、気になる方はそちらも見てみてください。2. プロジェクト基本情報 ①背景〜目的 Comadoには健康行動を促進するための健康習慣・フィットネス・健康記事といった、ユーザーの心身の健康をサポートする多種多様なコンテンツがあります。しかし検索機能やレコメンド機能が乏しいことにより、自分に合ったコンテンツに出会いづらいという課題がありました。これを解消するため、レコメンド機能の導入を目指したプロジェクトが始まりました。②初期方針 当時のComadoのレコメンドと目指す姿について 当時Comadoのレコメンドは手動の運用で行われており、週に一度更新する7個のコンテンツを全員に提示する形でした。※TOPおすすめ枠に横カルーセルで表示 (下図赤枠)。もちろんこちらの運用でも、編集部の皆さんがユーザーに見られそうなコンテンツを毎週考えて選定してくださっており、改善が重ねられていました。しかし手動では、日次やリアルタイムなどの更新頻度の増加や、ユーザーセグメントごとの振り分

サントリーウエルネス DX推進部の齋藤です。Comadoのネイティブアプリ開発を担当しております。今回の記事では、以前執筆したアジリティを向上させるために、開発チームをカイゼンした話の続編です。チームのアジリティを高めるために、チームのマインドセットを変えていった話になります。マインドセットの変革 従来、各タスクに対して各メンバーが担当して作業を進めていました。これにより、以下のような状態になっていました。メンバー間のコミュニケーションが少ない 各メンバーが担当タスクにフォーカスしているため、チームで活動するという意識が希薄 チームが一つの有機体のように作用し、変化に素早く順応するチームにするためには、メンバー間がスキルセットや特性を相互に理解し、一定の目標や決まりごとに基づいてチームワークを発揮することが重要だと考えています。 そこで以下のように取り組みました。相互理解のための対話 アジャイル界隈のチームビルディングでよく用いられるプラクティスであるドラッカー風エクササイズ(参考：ドラッカー風エクササイズ)を実施しました。これは、以下のような質問に答えてチームに共有することで、メンバーの価値観や強みを理解し、個々のパフォーマンスを最大限に発揮することを目的としています。質問 自分は何が得意なのか？ 自分はどうやってチームの成果に貢献するつもりか？ 自分が大切に思う価値は何か？ 自分は何が苦手なのか？(今回導入したオリジナル質問) ここで意識したのは、オフラインで実施することでした。ネイティブアプリチームは、メンバーが東京、石川、北海道に分散しており、普段はフルリモートで作業しています。しかし、チームビルディングは、Face to Faceで実施しなければチームの一体感を醸成するのは難しいと感じています。そこで、東京でネイティブチームギャザリングを開催し、2日間に渡って相互理解のための対話と後述のWorking Agreementの作成を実施しました。Working Agreement Working Agreementとは、その名の通り、チームの約束事です(参考：ワーキングアグリーメント)。チームやメンバーに対する暗黙の期待ではなく、こうして明文化することで、一定の価値観のもとでチーム活動を行えるようになります。決めていく中で工夫したことは、チームメンバー全員の総

サントリーウエルネスDX推進部の武田です。フルスタックエンジニアとしてコンタクトセンターで使うシステムが抱える課題に日々取り組んでいます。2023年10月に対話要約プロジェクトを立ち上げ、GPTで業務適用レベルの要約が得られること、GPTで業務時間が削減されることを短期間で実証しました。ここで、プロジェクトを成功に導くために色々試行錯誤して孝動したことについて振り返ります。対話要約プロジェクトについてはこちらの記事にて活動内容を詳しく記載していますので、ぜひご覧ください。ChatGPTを活用した対話要約機能の実証実験 【顧客応対業務効率化】お客様との対話要約をChatGPTで自動化する 振り返り 様々な切り口から振り返ります。プロジェクト構想 プロジェクト発足前の構想段階での考動について振り返ります。人で実施する部分とシステムで実施する部分を見極める 対話要約では、お問い合わせ内容（以降、リーズン）を判断し、リーズンに応じた要約を作成する必要があります。仮にリーズン判断、要約の精度がそれぞれ80%としたとき、全体を通して見ると精度は64%になってしまいます。現時点ではリーズン判断、要約ともに人で実施しており、リーズン判断については人で実施してもそこまで負担にならないかつ、精度もAIより高いため、リーズン判断を人で実施し、要約をGPTで実施する方針としました。そうすることで、プロンプトとしては要約に注力でき、短期間で現場適用レベルのプロンプトの作成に至りました。何でも生成AIで実現しようとせず、対象業務を俯瞰して成果を最大化するために、人で実施する部分とシステムで実施する部分を見極めるという視点も重要だと考えています。タスクを分解し簡単にする 商品の注文をはじめ、配送日の変更、キャンペーンなどリーズンは様々です。また、リーズンごとに要約に含めたい内容も異なります。リーズンごとに要件が異なる中で、全てのリーズンの要約を1個のプロンプトで実現するのは非常に難しいのではないかと考えました。そこで、全てのリーズンを要約できるプロンプトを作るのではなく、リーズンごとにプロンプトを用意する方針にしました。結果、リーズンごとに必要な情報、不要な情報を定義し、そのリーズンに特化したプロンプトを作り上げ、精度の向上に至りました。ここで言いたいことは、複雑で実現困難に見えるタスクも、分解

サントリーウエルネス DX推進部の青木です。今回ご縁がありまして、第2回 JTCX勉強会に私と同じプロジェクトに携わっている齋藤で参加・登壇してきましたのでイベントレポートとしてまとめてみたいと思います。JTCX勉強会とは JTCX勉強会とは、JTC、エンタープライズ組織で様々な取り組みをしている方々のそれぞれのユースケースを学び合いながら、取り組み事例や内部での努力を共通の知にして行く場として、Mutureさんによって主催・企画されている会になります。この「X」はTransformationに準えられています。伝統的、保守的な企業は"JTC"として揶揄されがちですが、そのJTCを内側から前向きに変えていこうという想いが込められています。この会は2回目となるのですが、前回も参加してとても有意義な会でしたので、今回もぜひ！と希望して参加させていただきました。また、せっかく参加するならどこかで私たちが取り組んできたことの振り返りも兼ねて登壇してみたいと思っていたので、機会をいただきまして登壇もしてみました。前回の開催レポートはこちら（イオンスマートテクノロジー社もりはやさんの記事です。）※本会はセミクローズドで開催しているため、一般公開しているイベントではありません。イベントレポート イベント会場 会場は丸井グループさんに協力をいただき、丸井グループ本社ビル2Fにある「tamaru」をお借りしました。とても開放的な空間で居心地が良く、LTやクリエイティブな作業をする空間として最適で、緊張はしていたものの空間の作用もあってリラックスして会に参加できました。軽いお菓子やドリンク、ビールを片手にLTをしました！こういう些細な雰囲気作りもとても良かったです。LT：DXを進める上での内製開発 LTのテーマは「DXを進める上での内製開発」でして、弊社からは青木と齋藤で登壇しました。 LTには弊社と合わせて2社が参加し、質疑応答合わせて30-40分程度でした。詳しい内容は別記事で執筆予定ですが、プロダクトが抱えていた課題 課題に対応するための手段としての内製開発 内製開発によって目指す姿 開発チームの具体的な取り組み 他チームへの越境 などについて振り返り、発表しました。質疑では、皆さんやはり同じような境遇の中で現場に向き合われていることもあり、 鋭い質問の連続で「こういう観点で普段

はじめに サントリーウエルネスDX推進部エンジニアリングGに所属する浅井です。私は2023年にデジタル＆テクノロジー部門採用で新卒社員として入社し、今年で入社2年目になります。現在、健康行動アプリ「Comado」のサーバーサイドの開発業務を行っています。その中で、1年目の頃に行っていた業務と、仕事を進める中でぶつかった壁についてご紹介しようと思います。Comadoとは Comadoは2022年10月からサービスの提供を開始した、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリです。健康行動アプリ「Comado」内でユーザーは様々な事が行えます。フィットネス Zoomや動画を視聴することで、ヨガやエクササイズなどをオンラインで受けることができる 記事の閲覧 落語やレシピなど、多くの記事や動画を視聴できる (定期契約者のみ視聴可能な記事も存在 例：雑誌の読み放題) 健康習慣 さまざまな健康習慣を記録し、振り返ることができる チャレンジ 健康行動によって、ポイントを貯めることができる(定期契約者のみ) SuntoryWellnessClubについてはこちら 入社してからの業務 入社前の私はプログラミングの経験がほとんどありませんでした。 そのため、Comadoのサーバーサイドの開発チームに加入した当初、多くの知識とスキルを吸収しようと業務に向き合うことから始めました。 与えられた業務を期限内に終わらせることは前提として、先輩方に納得できるまで質問し知識の理解を深めることに集中することで、業務の中でどれだけ自分が成長できるかに重点を置きました。知識をつけながらComadoをシステムとして安定稼働させるための細かい運用業務に向き合い続けていくと、徐々に成果も出てきました。 成果が出ると振っていただける業務も幅が増え、企画の実現のために仕様の整理・実装・テスト・調整・リリースまで一気通貫して行うことも増えていきました。新たな業務でぶつかった壁 業務に取り組み続け、少しずつ慣れてきた頃、1つの業務を新たに任されました。 それはComadoの健康習慣に対しての「健康習慣のメタデータ管理について考える」という業務です。壁①：何をすればいいのか分からない 「Comadoの健康習慣のメタデータ管理について考える」という業務を任されたものの、当初は何をすればいいのか分から

サントリーウエルネス DX推進部エンジニアリングGの坂元です。 プロダクト開発マネジメントを担当しております。現在Comadoというシニア向けのプロダクトを担当しており、 この記事では「仮説検証を素早く実施する取り組み」を紹介したいと思います。背景 Comadoは、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリとして、2022年10月からサービスの提供を開始しました。 リリースから約2年が立ち、アプリ利用者の行動パターンやよく使われる機能が見えてくる中で、顧客体験を更に向上させる施策を日々考え実現しています。 出来るだけ効果の高い施策を実現したいと考える一方で、せっかく開発した機能がまったく使われないことは避けたいです。効果の高い施策とはなにか？ 最小コストで最大の価値提供が行える施策と考えています。価値提供とは顧客課題を解決できていることを意味しており、顧客課題を見極めることがとても重要となります。施策実現の流れ 顧客課題を分析し、課題を解決する打ち手を実行した後に効果検証するサイクルを回していきます。顧客課題の見極めが正しくできていない場合、いくら施策をしても効果はでないです。 一方で顧客課題の見極めはとてつもなく難しいです。 アンケートやインタビューを通じて得られる顧客の声や、顧客行動を分析した上で、 仮説検証を繰り返しながら効果の高い課題・解決策を見つけだすことが必要となります。Comadoでは、KARTEを活用して仮説検証を素早く行えるようにしています。顧客課題の見極め 顧客の解像度が低い状態で、施策を実現しても高い効果は期待できません。顧客を面で捉える KARTEのユーザータイプ分析を活用し、 顧客のライフサイクル（新規、継続、離脱）を利用頻度からおおまかに分類し、状態遷移を追えるようにしています。プロダクトの利用状況を大まかに把握できますが、これだけで顧客像は見えてこないです。顧客特性を分類する 顧客特性を分類し定量化していくことで、顧客像が徐々に見えてきます。 ユーザータイプ分析のユーザー指標を作成し、顧客の特性を分類しています。顧客特性の分類方法 顧客の行動をKARTE Insightのカスタムイベントにて収集し、セグメントを活用して行動特性を分類する 外部で保管している顧客属性をKARTE Insightの紐づけテーブルにイン

サントリーウエルネス DX推進部の青木です。以前、JiraとGithubをシームレスに連携する記事を執筆しました。ただそこでは設定しているAutomationルール一覧についての具体は記載していなかったので、改めてこちらでまとめてみようと思います。Jira Automationとはなにか Jira Automationとは、Jiraが用意しているあらゆるトリガーから柔軟にワークフローを組むことができる機能です。テンプレートも多数用意されていますので簡単に組むことができますし、割と自由度が効くので幅広い処理をJiraに任せることが可能です。ソースコードが不要なのも非エンジニアからしたら嬉しいポイントだとは思います。個人的には結局やってることはあまりかわらないのでソース化されていない恩恵はそこまで感じませんが、ビジュアライズされている部分は嬉しいポイントかなと思います。詳しくはこちら最初から下記のようにテンプレートが用意されているので、テンプレートからカスタマイズすることもそのままつかうことも可能です。便利ですね。設定しているルール ここではJiraとGithubをシームレスに連携するで紹介したルールを中心に実際にプロジェクトで利用しているルールについていくつか紹介したいと思います。全体のステータス遷移図はこんなイメージです。Branchが作成されたらチケットを「進行中」に移動 前提としてJiraにはGitHub for Jiraというアプリがあり、これを利用することでGithubとの連携が可能になります。その場合はJiraのステータスとGithubのBranchを同期させるような動きをJira Automationを使って組むことが可能です。※連携時は管理者権限が必要になりますので、ICT担当者と相談の上導入するようにしてください。その中でBranchが作成されたらチケットを進行中に移動するワークフローが下記です。Branchの作成時をトリガーにしてStatusを移動させます。BranchはJiraのチケットの画面からでも作成可能ですし、ローカルで作成したブランチをあとで紐づけることも可能なので、お好きな方で進めると良いと思います。最終的にはチケットとBranchが紐づいて管理されていれば何でもよいと思います。Pull Requestが作成されたらチケットを「レビュー

サントリーウエルネスDX推進部エンジニアリングGの武田です。フルスタックエンジニアとしてコンタクトセンターで使うシステムが抱える課題に日々取り組んでいます。先日、コンタクトセンターにてGPTを活用した対話要約機能の実証実験を行いました。対話要約機能のコンセプトや実証実験に至るまでの過程について触れた後、実証実験の結果について記載したいと思います。プロンプトチューニングについてはこちらの記事にもう少し詳しく記載していますので、ぜひご覧ください。【顧客応対業務効率化】お客様との対話要約をChatGPTで自動化する対話要約機能について まず初めに、顧客応対業務でどういった問題があり、それに対してどのように解決しようとしているのかについて記載します。お問い合わせ対応 弊社のコンタクトセンターではお電話にてお客様からの様々なお問い合わせにお応えしています。お電話が終了したあと、次にお客様からお電話いただいた際に、過去にどういったお問い合わせをいただいたのかを短時間で確認するため、お電話の内容を要約（対話要約）して社内システムに登録しています。対話要約が抱える問題 対話要約はお客様から過去にどういったお問い合わせをいただいたのかを記録し、次に応対する人に繋ぐ重要な役割を果たします。これまで運用してきた中で以下のような問題がありました。対話内容の要約に時間がかかる 要約に記載される内容の粒度が応対した人によって異なる 要約に記録したい内容が欠けてしまう場合がある これらの問題を解決するために、GPTの活用を検討しました。GPTを活用した対話要約 対話要約の生成を以下の流れで自動化しようと検討しています。お客様との通話を音声認識ツールでテキスト化する APIでテキストからプロンプトを生成する GPTでプロンプトを実行し、対話を要約する 実証実験に至るまで プロジェクトの立ち上げ、業務に適用できるレベルの要約を生成するプロンプトの作成、GPTを組み込んだ機能の開発など実証実験に至るまで様々な取り組みを行ってきました。プロジェクト発足 体制としては会社、組織を横断し、サントリーグループのITサービス会社であるサントリーシステムテクノロジー（SST）、弊社のコンタクトセンター、DX推進部で体制を組み、内製化することにしました。SSTが生成AIのプロンプトのチューニングを、コンタクトセンタ

サントリーウエルネス DX推進部の齋藤です。Comadoのネイティブアプリ開発チームのリーダーを担当しております。参加してからだいぶ経ってしまいましたが、2024年4月16日(火)〜4月17日(水)に開催されたDevOpsDays Tokyo 2024の参加レポートを書いていきます。DevOpsDaysとは 世界中で開催されているDevOpsのカンファレンスです 1週間に1回は世界中のどこかで開催されている計算なんだそうです 海外のDevOpsの有識者も招聘されています 国内のトレンドだけではなく、海外のトレンドも抑えられます 今回の注目は、DevOpsDaysの発起人、そしてDevOpsの父であるPatrick Debois氏がDevOpsDay Tokyoに初登壇！ 会場の様子は以下です。外国籍の方が多かったです(体感3割程度)。「歩いていける国際カンファレンス」 を目指しているという話があったのですが、あながち間違いじゃないです。参加のモチベーション アジリティを高めるために内製化やカイゼン活動に取り組んでいます(この活動内容は、こちらの記事をご覧ください)。 これらの活動のベースとなるDevOpsのトレンドと実践を学びたいというモチベーションで参加しました。キーワード DevOpsに関して、前提として知っておいた方がいい5つのキーワードを紹介します。① DORA Google Cloud のDevOps Research and Assessment（DORA）チーム(以下：DORA) 約10年にわたり36,000 人以上の専門家に対してDevOpsのサーベイを実施。この調査により、ソフトウェアデリバリー、組織のパフォーマンスを向上させる技術、プロセス、文化が明らかにされてきました ② Four Keys DORAが実施した6年間の研究から導き出した、ソフトウェア開発チームのパフォーマンスを示す4つの指標 デプロイの頻度：組織による正常な本番環境へのリリースの頻度 変更のリードタイム：commit から本番環境稼働までの所要時間 変更障害率：デプロイが原因となり本番環境で障害が発生する割合（%） サービス復元時間：組織が本番環境での障害から回復するのにかかる時間 詳しく知りたい方はこちら エリート DevOps チームであることを Four Keys プロジ

サントリーウエルネス DX推進部エンジニアリングGの青木です。私が担当しているプロダクトではCodeBuildを利用しdocker imageのBuildを行っています。MavenのversionがBuild環境でどうなっているかを確認したい場面があったので、ナレッジとして残しておこうと思います。確認方法 検索してもでてこない、公式サイトを見ても載ってない…。そういうときはコンテナを立ち上げて直接確認してしまうのが一番早くて確実だと思います。① CodeBuildで使っているimage tagを確認する IaCを使っている場合はTerraformやCloudFormationの設定からどのCodeBuildのimageを使っているかを確認してください。今回は執筆時点のECRにあるイメージcodebuild/amazonlinux2-x86_64-standard、タグ5.0を使って確認してみようと思います。② ECRに該当のimage tagがあることを確認する AWSが提供しているPublicのECRから確認できます。③ docker pull $ docker pull public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:5.0 5.0: Pulling from codebuild/amazonlinux2-x86_64-standard (省略) Status: Downloaded newer image for public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:5.0 public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:5.0 ④ docker run & mvn -version $ docker run --rm -it --entrypoint /bin/sh public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:5.0 sh-5.2# mvn -version Apache Maven 3.9.5 Maven home: /opt/maven Java version: 17.0.10, vendor: Amazon.com

サントリーウエルネス DX推進部ディレクションGの大洞です。サントリーウエルネス公式ECサイト「サントリーウエルネスオンライン」の企画・開発の統括を担当しています。サントリーウエルネスオンラインは2023年8月に大規模なリニューアルを実施しました。大分時間がたってしまったのですが、改めてリニューアルまでの道のりを振り返ってみようと思います。また、一口にリニューアルと言ってもシステム最適化の手法としてはリファクタリング・リアーキなど様々あると思いますが、サントリーウエルネスオンラインはリビルドという選択肢を取りました（以後、リビルドという表記に統一します）。リビルド完了まではとてつもなく、長く険しく、甘酸っぱい道のりだったため、何回かに分けて書いていこうと思います。リビルドに至った経緯 まず何故サントリーウエルネスオンラインのリビルドが必要だったのかということを簡単に説明します。私がサントリーウエルネスに入社した2021年は、サントリーウエルネスでは従来の「モノ」から「モノ＋サービス」へと事業戦略が大きく舵を切ったタイミングでした。その中でサントリーウエルネスオンラインの担当となった私は今後サービスを軸に運営していくうえで、顧客とのデジタル接点の強化は真っ先に取り組まなければいけないテーマだと思いました。ただ、顧客とのデジタル接点の要になるべきサントリーウエルネスオンラインは様々な課題を抱えており(後述参照)、既存のシステムの延長戦ではその責務を全うできないと判断し、リビルドを実施することを決めました。既存システムが抱えていた課題 従来のサントリーウエルネスオンラインは約20年間、老舗うなぎ屋のたれのように継ぎ足し継ぎ足しをされたようなシステムでした。以下に代表的な課題を書きます。システム品質が著しく低い私が着任した際にJIRAでの障害管理を導入したところ、1年間で400件以上のシステム障害が起票されました。デザイン崩れのような軽微なものから、商品を購入できない、サイトが停止するなど重篤なものまで、毎日が障害との格闘でした。 機能拡張性がない各画面や機能が共通化されておらずコピペで増殖されており、ちょっとした機能を追加しようとすると100画面以上の改修が必要、というような状態でした。 リビルドを始める前に 着任して早々に上記の課題感を断片的に捉え始め、リビルドの必要性

サントリーウエルネス DX推進部の齋藤です。2024年1月に入社し、Comadoのネイティブアプリ開発チームのリーダーを担当しております。今回の記事では、アジリティ向上を目指して、Comadoのネイティブアプリ開発チームをカイゼンしている話をします。Comadoとは 私が担当しているComadoは、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリとして、2022年10月からサービスの提供を開始しました。ファーストリリースから2024年5月現在までのおよそ1年半は、機能のエンハンス、UI/UXのブラッシュアップ、不具合対応を継続的に実施しています。アジリティ向上の必要性 はじめに、Comadoの開発戦略を説明します。(抜粋)目の前の事業を実現しながらも将来の事業成長に合わせ、開発チームとしてのアジリティ向上やシステムの進化も実現します。今回フォーカスするキーワードは、アジリティ向上です。アジリティとは「俊敏性」を意味します。VUCAの時代、ビジネス環境は急速に変化しており、企業はこの変化に迅速に対応する必要があります。プロダクト開発においても、アジリティの高さが求められます。プロダクト開発Aと比較すると、プロダクト開発Bは同じ期間で複数回検査と適応のループを回しています。これにより、ユーザーからの要望やニーズを短い期間で取り込むことができ、ユーザーが本当に求めていた価値に近づくことができます。つまり、アジリティの高いプロダクト開発は、プロダクトの本質的な価値に迅速に辿り着くことができます。さらには、ユーザーの要望の変化にも素早く適応できます。サントリーウエルネスおよびComadoチームはアジリティ向上を目指しています。理由は2点あります。弊社が他社にない新たなウエルネス体験を提供しているため 弊社は、従来の健康食品だけを売るビジネスから脱却し、顧客接点を増やしLTVを最大化するためにDXを積極的に進めています。特にComadoは、新しいウエルネス体験を提供するプラットフォームとして位置づけられており、ユーザーのニーズに迅速に対応することを目指しています 健康行動アプリは多くの企業や個人がリリースしているため Comadoは健康行動アプリに分類されますが、多くの企業や個人デベロッパーが健康行動アプリをリリースしています。経済産業省の調査によると、ヘルス

サントリーウエルネス DX推進部エンジニアリングGの青木です。皆さんはナレッジ共有のアプリは何を利用しているでしょうか。サントリーウエルネスのDX組織ではConfluenceを使っています。私はこういうツールとは業務スピード向上のために「仲良く」するようにしています。仲良くというのは使いこなす意味で言っていますが、なんとなくツールそれぞれの使用感に慣れるというイメージで仲良くすると表現しています。今回はConfluenceと仲良くするために何をしているのかという記事をナレッジ蓄積・共有のために書いてみようと思います。また、本稿で紹介するショートカットはJiraのエディタでも使えますのでご活用ください。TL;DR Jiraのエディタも同じ仕様である ショートカットは使うものだけ使えればOK ユースケースとセットで抑えておけば尚良し 段落と改行の違いを理解しておく Confluenceのキーボードショートカットを使いこなせてますか？ 業務スピード向上のためにまず覚えないといけないのは、ショートカットですよね。新卒や新しい部署へ配属されて新しいツールに慣れないといけない人も多いと思います。とりあえず仕事を進めなきゃとなってマウスクリックで…と進めていたらせっかくの時間も有効活用できません。できるだけこういう作業系にかける時間は短縮して自分の頭で考えることに時間を費やすようにしましょう。キーボードショートカットの一覧はConfluence公式サイト及びConfluenceの任意ページ上にて?キー押下で確認できます。Confluence上のページからの表示だと以下が一覧です。※執筆時点でのショートカットです。全般 機能 ショートカット（Mac/Windows共通） コンテンツの作成 c ダッシュボードに移動する gd 通知を開く gn 現在のスペースを参照 gs ショートカットのヘルプを開く ? クイック検索 / クイック検索 gg サイドバーを切り替える [ エディターからサイドバーを切り替える Control+[ ページの追加 c ブログを追加 b 編集 e コメント m 次のインラインコメント n 以前のインラインコメント p Toggle Inline Comments ] ウォッチ w 共有 s ラベルの編集 l 添付ファイルを表示 t お気に入りページ f ページ

サントリーウエルネス DX推進部エンジニアリングGの山田です。プロダクト開発マネジメントを担当しています。今回は、サントリーウエルネスの公式ECサイト「サントリーウエルネスオンライン」の開発にまつわるお話をします。前提 サントリーウエルネスオンラインは、2023年8月に大規模リニューアルをしました。従来のシステムはASP.NETを利用し、技術的負債が溜まりに溜まっている状況でしたが、リニューアルに際してフロントエンドはReact/Next.js、バックエンドはJava/SpringBootを利用したモダンなアーキテクチャで再構築を行いました。※この大規模リニューアルにまつわるお話は別途記事化予定です。弊社のお客様の特徴としてミドル〜シニア層のお客様が多く、特にシニア層のお客様に多くご愛好いただいています。コンタクトセンターへお電話等でのご注文が多いものの、最近ではサントリーウエルネスオンラインを通じたオンライン経由で購入いただくお客様も増えてきています。顧客の声を聞く オンライン経由でご購入いただくにあたって、日々のお問い合わせも当然ながら発生しています。お問い合わせはメールだけでなくコンタクトセンターに直接お電話でいただくこともあります。そしてその問い合わせ内容は、お客様からの"生の声"として我々エンジニアにも伝わってきます。一例として、コンタクトセンターを管轄する部署からの、ログインに関する問い合わせ共有事例を紹介します。 コンタクトセンターを管轄する部署では、日々お客様からの声（VOC）を分析して、その内容を各部署の共有しています。今回の例では、ログイン時に誤ったボタンを押下してしまい、ログインできないという旨のお電話での問い合わせが7件あったという内容です。この7件を多いと見るか少ないと見るかはさておき、「本当にこのUIがユーザーフレンドリーなのだろうか？」を自らに問うには十分な件数です。また、お客様の特性を鑑みたときに、我々の感覚が正しいとは限りません。結果として、通常のログイン導線とサントリーアカウントを利用したログイン導線がわかりにくいという判断をして、すぐに修正することにしました。通常のログイン導線と、サントリーアカウントを利用した導線を分け、多く利用いただいている通常ログイン導線をUI上優先させるようにしました。我々の強み このように、コンタクトセ

サントリーウエルネス DX推進部エンジニアリングGの青木です。日々の業務でGithubを利用しているのですが、Github Actionsを使えば面倒なことを任せられることがわかり試行錯誤しながら導入しています。前回、第一弾の記事を投稿したので今回はその続きとしてMergeされなかったPRからMilestoneを外す方法について紹介したいと思います。課題感 Github Milestoneとは、そのリポジトリのバージョンに紐づく変更管理を容易にしてくれる機能です。私のチームではMilestoneを使って変更管理をしているという話をしました。GithubでPRのレビューやMergeを繰り返していく中で、とりあえずPRを作成したけどCloseしておこうといったPRも数多くあると思います。そのPRがMilestoneに紐づいていた場合、CloseされたPRとしてMilestoneに残り続けることになります。この場合、Milestoneで変更管理するにあたってMergeされていないPRまでMilestoneに紐づいている状態になるのでとても見づらくなります。実際、CloseされたPRはMilestone上で見えなくしたいので手動で外す対応を取っていました。これを自動化したいなというのが今回の課題です。そうだ、Github Actionsに任せよう このMilestone外しもGithub Actionsを使って行えます。早速作っていきましょう。構成 全体構成は下記の通りです。PRがCloseされたのをトリガーとしてGithub Actionsが発火、Closeの状態を判別してMilestoneを外す。以上です。これも簡単ですね。Workflow 作成したワークフローはこんな感じです。基本Pythonなどのスクリプトに処置を任せる系のワークフローは大体下記のような作りになると思います。ここでポイントとなるのがif: ${{ !github.event.pull_request.merged }}の分岐を入れることです。PRはCloseとMergeのステータスを持っており、CloseされたのにMergeされていない場合が今回Milestoneを外したい対象のPRとなります。本当はGithub ActionsのトリガーでPRのステータスがCloseであるものだけを検知して発火すれ

サントリーウエルネス DX推進部エンジニアリングGの青木です。日々の業務でGithubを利用しているのですが、Github Actionsを使えば面倒なことを任せられることがわかり試行錯誤しながら導入しています。今回はその第一弾として、Milestoneの期限通知をGithub Actionsで行う方法について紹介します。Github Milestoneとは Github Milestoneとは、対象リポジトリのバージョンに紐づく変更管理を容易にする機能です。Milestoneに紐づけたIssueやPull Requestの進捗をパーセンテージ表示したり、リリース時になんの変更がそのMilestoneに紐づいているかを管理したりできます。 私のチームではセマンティック・バージョニングに基づいてMilestoneを作成しており、そのバージョンに含まれる変更管理をすべてMilestoneで行っています。Milestoneは変更管理に強く、期限管理に弱い Milestoneは変更管理には強いのですが、それに特化している機能であるとも言えると思います。期限に関してはカレンダーとして出るわけでもないですし、Milestoneにちょっと記載されているレベルです。これではぱっと見たときにいつがリリース日なのかがわかりません。 そのため、他のツールでスケジュール管理しておく必要が出てくるのですが、せめて期限通知くらいはできたら楽なのにな…と思いました。そうだ、Github Actionsに任せよう この期限通知はGithub Actionsを使って行えます。Milestoneの期限を取得する必要がありますが、同じGithubなので構築が楽です。特にGithub Actionsごとに発行されるGITHUB_TOKENがあるのでわざわざPATを発行しなくていい点も気軽だと思います。構成 全体構成は下記の通りです。週次でMilestoneの期限を確認しにいき、1ヶ月以内であれば事前に用意しておいたSlackアプリにPOSTするWorkflowを用意するだけです。非常に簡単な作りですが、これだけでMilestoneの期限通知を自動化できます。Workflow 作成したWorkflowはこんな感じです。毎週水曜日の朝9時にSlackチャンネルに通知させるようにします。envに各リポジトリの情

サントリーウエルネス DX推進部エンジニアリングGの青木です。Comadoのサーバーサイド（以下SS）チームでリーダーをしています。今回はJiraとGithubを連携させる件について書いてみたいと思います。経緯 Coamdoでは現在チケット管理でJiraを利用していますが、もともとSSチームとしてはGithub IssuesとMilestoneだけを使ってタスクとリリースの管理をしていました。理由としてはGithubだけで完結できるのとIssueとMilestoneの相性が非常に良かったからです。また、どのMilestoneにどのIssueが紐づいているかを管理できたのでリリースごとに対象チケットをまとめる必要がありませんでした。加えて、Githubからリリースに何が含まれるかを確認できる点もとても魅力的でした。他にも、Issueにはキーワードを使ってPull Requestとリンクさせる機能があります。これによりPull RequestがCloseするとIssueも自動的にCloseしてくれるなど開発者体験的にも良いと思いました。ただ同時並行で色々な事が進むにつれて、Githubだけだと管理しにくくなりました。結果としてはJiraにチケット管理を寄せながらMilestoneの良いところは残す形で移行しましたので、どう移行したのか書いてみたいと思います。なにが課題だったか 1️⃣ Issue単体で期日を管理できない/プロジェクト管理ができない IssueはあくまでIssueを管理するものであり、期日まで管理するものではありません。期日まで管理したいならIssueだけではなく、Github Projectsを立ち上げ、そちらにリンクさせることで期日を管理できます。なにが言いたいかというと、プロジェクト管理とIssue管理は別物であり、多数のステークホルダーがいる環境では期日管理が必須となります。そのため、Issue単体で管理することが難しいなと思う場面が非常に多かったです。2️⃣ Milestoneはリリースの期日を管理するものであり、個別Issueの期日を管理するものではない Milestoneがあれば期日の管理ができるのでは？についていうと、できないと思います。Milestoneはその時点のリリースに紐づく変更管理が目的であり、個別Issueの管理を目的に設計され

サントリーウエルネス DX推進部エンジニアリングGの坂元です。プロダクト開発マネジメントやディレクションの業務を担当しております。現在ComadoというNativeアプリの開発を担当しており、 この記事では「思い切ってNativeアプリのリファクタリングを実施した」を紹介したいと思います。背景 Comadoは、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリとして、2022年10月からサービスの提供を開始しました。開発はアジャイル手法のスクラムを採用し、４週間のスプリント単位でリリースを行なっております。 サービス開始後も開発は継続し、ユーザ体験向上に向けた企画の実現と顕在化している不具合に蓋をする日々を送っておりました。スプリントを重ねる毎に、不具合の発生件数が増加し、同時に施策実現数が減少していくことで、徐々に開発の生産性の低下を感じるようになりました。このまま開発を継続すると、取り返しのつかない状態になるという危機感を抱くようになり、開発は継続しながらも、問題の本質がどこにあるのか分析することにしました。問題の本質は何か？ 分析結果として、初期開発時の進め方によって、コード品質が大きく低下したと判断しました。初期開発時はとにかくリリースを優先したため、ユーザーストーリー単位で開発を終わらせることを強く意識して進行しました。簡易に実装することが優先されたため、ロジックの共通化や当初のアーキテクチャの構造に従うことを諦め、その結果技術的負債が蓄積されてしまいました。当初のアーキテクチャの構造について 開発初期の頃に設計したアーキテクチャは、処理の一方通行化と依存性の脱却、テスト容易性、可読性の向上を目的とし、MVVMを基準にクリーンアーキテクチャの概念を導入しました。アプリケーションの構成（As-Is） Presenter（プレゼンテーション層）画面と画面操作について受け持つ階層です。Domain（ドメイン層）ビジネスロジックとデータ入出力を受け持つ階層です。Infrastructure（リポジトリ層）外部通信や永続化データとのやりとりを受け持つ階層です。技術的負債について ドメイン層のUseCaseがリポジトリ層からのデータの入出力を受け持つだけの状態になり、プレゼンテーション層の間で素通りするだけの存在になっていました。そのためリポジトリ層の

サントリーウエルネスDX推進部エンジニアリングGの武田です。フルスタックエンジニアとしてコンタクトセンターで使うシステムが抱える課題に日々取り組んでいます。今回はChatGPTを活用して顧客応対業務を効率化する取り組みについて紹介したいと思います。お問い合わせ対応について 弊社のコンタクトセンターではお電話にてお客様からの様々なお問い合わせにお応えしています。お電話が終了したあと、次にお客様からお電話いただいた際に、過去にどういったお問い合わせをいただいたのかを短時間で確認するため、お電話の内容を要約（対話要約）して社内システムに登録しています。対話要約が抱える問題 対話要約はお客様から過去にどういったお問い合わせをいただいたのかを記録し、次に応対する人に繋ぐ重要な役割を果たします。これまで運用してきた中で以下のような問題がありました。対話内容の要約に時間がかかる 要約に記載される内容の粒度が応対した人によって異なる 要約に記録したい内容が欠けてしまう場合がある これらの問題を解決するために、ChatGPTの活用を検討しています。ChatGPTを活用した対話要約の自動化 対話要約の生成を以下の流れで自動化しようと検討しています。お客様との通話を音声認識ツールでテキスト化します。 APIでテキストからプロンプトを生成します。 ChatGPTでプロンプトを実行し、対話を要約します。 対話要約の自動化PoC ChatGPTによって出力される要約が業務レベルで活用できるかを検証するためにPoCを実施しています。体制構築 社内にナレッジを蓄積するためにも内製で進めることを選択し、体制を構築しました。体制としては会社、組織を横断し、サントリーグループのITサービス会社であるサントリーシステムテクノロジー（SST）、弊社のコンタクトセンター、DX推進部で体制を組みました。SSTがChatGPTのプロンプトのチューニングを、コンタクトセンターにてChatGPTによる出力要約の評価を、DX推進部がシステム化の検討とプロジェクトのディレクションを担当しています。評価データ準備 まず、評価対象のデータを準備しました。お客様から新規注文や届け日変更など様々な理由でお問い合わせをいただくので、理由ごとのお問い合わせ件数を集計し、件数が多い理由を評価対象に選定しました。評価条件検討 次に評価条

サントリーウエルネス DX推進部 エンジニアリングGの山田です。プロダクト開発マネジメントや大規模システム開発プロジェクトのプロジェクトリーダーを担当しています。今回は、社内横断的な取り組みとして、2023年9月にローンチした「Suntory Wellness CLUB」というサービスについてお伝えしたいと思います。前提 サントリーウエルネスでは、長年サントリーウエルネスの健康食品・ビューティケア商品をご愛好いただいているお客様に対して、商品価値プラスアルファのものを還元できていないという積年の課題がありました。商品品質の高さやその効果効能については、多くのお客様に認めていただき、セサミンEXやVARONオールインワンセラムといったヒット商品が存在したり、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリ「Comado」を提供してはいますが、 お客様への還元という意味で、ある種競合に劣位している部分がありました。この長年ご愛好いただいているお客様、あるいは最近サントリーウエルネス商品を手に取っていただいたお客様に対して、商品価値以上のものを還元したい、その目的で立ち上がったのが今回お伝えする「Suntory Wellness CLUB」という新たなサービスですSuntory Wellness CLUBとは Suntory Wellness CLUBの特徴は大きく2つです。サントリーウエルネス商品の購入やComadoアプリ上での健康行動でポイントが貯まる 貯まったポイントはサントリーウエルネス商品を含めたサントリーグループの商品・グッズやサントリーならではの特別な体験に使える(※) ※ ポイント利用は2024年1-3月の開始予定です そのうち、「サントリーウエルネス商品の購入やComadoアプリ上での健康行動でポイントが貯まる」という仕組みを2023年9月に無事ローンチしました。ローンチまでの道のり 構想 私は入社後、このSuntory Wellness CLUBの開発プロジェクトにジョインし、現在プロジェクトリーダーを担っています。サントリーウエルネスではお客様一人ひとりのウエルネスに貢献していきたいというビジョンを掲げています。そこに向けて、健康食品やビューティーケア商品を提供して終わりではなく、一人ひとりのウエルネスを実現するためにサービスの提供

サントリーウエルネス DX推進部 エンジニアリングGの河島です。 私は、デジタル＆テクノロジー部門採用で新卒社員として入社し、今年で入社2年目になります。 この記事では、私がサントリーに入社した理由や現在の仕事内容について紹介します。 入社背景 学生時代は経営学部に所属し、デジタルマーケティングを勉強していました。デジタルを活用し、より日常生活を楽しくするようなサービス作りをしたいと漠然と考えて就活をしている時に、弊社の「デジタル採用」を知り、興味を持ちました。クラフトボスの「ちびだら飲み」やハイボール文化など、新しい飲用スタイルや生活の楽しみ方を提案し続けており、新たな体験をお客様に届ける経験ができるのではないかと思い、入社しました。入社後は、デジタル採用全体で約3ヶ月のシステム研修を受けました。その後に新人の希望と適正を相談した上で、企画やデータ活用グループに配属が決定されるのですが、私の場合は顧客体験を企画するだけでなく、企画をどう実現させていくかに関しても理解したいと思い、自らエンジニアグチームを希望して配属されました。現在のお仕事 私は現在、Comado という健康行動アプリの開発を行なっています。このアプリでは、フィットネスレッスンの配信や健康行動の記録機能など、健康行動の習慣化をサポートするコンテンツを用意しています。アプリを通して、お客様が生活習慣を変えていただけるようにサポートすることで、サプリ提供だけでは解決できなかった「お客様の体や心の悩み」を解決しようとしています。また、各コンテンツの利用状況など、ユーザーの行動データを収集し、顧客解像度を向上させることで、お客様の多様性に合わせた商品・体験を提供する仕組みを構築しようとしています。私は、サーバーサイド領域の開発チームに所属し、新規APIの開発や既存コードの改修（リファクタリング）などを行なっています。また、企画チームと開発チームの連携役として、企画内容の整理や開発の推進などを行っています。仕事の面白さ・やりがい 開発したものを多くの人に使ってもらえること Comadoは2022年10月にリリースを行い、現在数十万人の方に利用されています。まだまだ規模は小さいですが、日々のアプリ利用率やユーザーさんからの嬉しいコメントを見ると、自分の仕事が誰かの役に立っていると個人的に感じています。また、アク

はじめに こんにちは。DX推進部エンジニアリングGの今泉です。サントリーウエルネスには今年の8月に入社したばかりになります。 業務では主にビジネス基盤となるプロダクトのマネジメントやフロントエンド開発のリーディングを担当しています(が、今回はJavaがテーマです)2023/9/19に最新のLTSであるJava21がリリースされました。弊社でもバックエンド開発では主にJavaを利用しています。今回は直近の最新LTSバージョンであったJava17からの主要な変更点について紹介していきます。Java21の詳細は以下にまとまっています。リリースノートJDK 21 Release NotesAPIドキュメントJava® Platform, Standard Edition & Java Development Kit Version 21 API SpecificationJava17からの変更点 以下にJava17からJava21までに取り込まれたJEPがまとまっています。JEPs in JDK 21 integrated since JDK 17JEP400:UTF-8のデフォルト化(Java18) JEP 400: UTF-8 by DefaultJava17以前では、デフォルトの文字セットはJavaランタイムの起動時に決定されており、macOSではUTF-8が指定されるのに対し、 日本語WindowsではShift-JIS(より正確はMS932)で指定されていました。 このため文字セットの指定がない場合、これらの文字セットが利用されていました。今回の変更により、標準Java APIのデフォルト文字セットがUTF-8となりました。これにより文字セット指定がない場合のファイルがUTF-8として扱われるようになります。互換オプション今回の変更によって文字データやコメントを日本語で記載しShift-JISでファイルを保存している場合、Java18以降でコンパイルをすると文字化けすることになります。これを防ぐにはソースコードをUTF-8に変換するか、Java17以前までの処理とするため、-Dfile.encoding=COMPATをJava実行時のオプションとして追加する必要があります。 JEPよりIf an application that has been running

サントリーウエルネス DX推進部 エンジニアリングGの武田です。フルスタックエンジニアとしてコンタクトセンターで使うシステムが抱える課題に日々取り組んでいます。弊社ではお客様とお話した内容を対話要約として保存しています。お客様の声を詳しく分析するための方法の一つとして、対話要約を全文検索出来るようにすることを検討しています。この記事では「テキストデータをElasticsearchに投入して全文検索出来るようにする方法」を紹介したいと思います。この記事から分かること テキストデータをElasticseachに投入してKibanaで可視化する方法キーワード 全文検索というと転置インデックス、N-Gram、シノニム、ユーザー辞書、文字列正規化、頻出語句除去など様々な技術要素がありますが今回は触れません。キーワード 概要 Elasticsearch 全文検索エンジンです。大量の文書に対して高速で全文検索することが出来るようになります。 Kibana Elasticserach用のデータ可視化ツールです。 Docker コンテナ型の仮想環境プラットフォームです。設定ファイルから同一のアプリケーション実行環境を立ち上げることが出来るようになります。 形態素解析 文章を意味を持つ最小の単位に分割・判別することです。例：「セサミンには抗酸化作用があります」->「セサミン(名刺)」「に(格助詞)」「は(係助詞)」「抗(接続詞)」「酸化(名刺)」「作用(名刺)」「が(格助詞)」「あり(動詞)」「ます(助動詞)」 タグクラウド 件数、出現頻度、重要度を加味してタグの一覧を可視化したものです。 全文検索 複数の文書の先頭から末尾までテキスト全てを対象に特定の文字列を検索することです。 構成 将来的には以下のようにデータをElasticsearchに連携し、全文検索出来る環境を作っていきたいと考えています。※弊社ではコールセンターにて従事していただいているオペレーターをエージェントと言います。前段階として今回はDockerでElastic Stack（Elasticsearch、Kibana、Logstash、Beats）を構築しました。CSVを所定のディレクトリに置くとBeatsがファイルを検知してデータをLogstashに送り、Logstashでデータを処理してElasticsearch

サントリーウエルネス DX推進部 エンジニアリングGの青木です。Comadoというアプリを開発しており、主にサーバーサイド領域でエンジニアをしています。現在Comadoではデータ活用を見据えてデータ整備を行っています。アプリの動作をイベントログとして出力し、データ基盤に連携しようと考えていますが、Comadoとデータ基盤のAWSアカウントが別れているためクロスアカウントでの連携が必要な環境になっています。 このイベントログをリアルタイムに送信するようなアーキテクチャを考えており、FireLensを使ったシステム構成の検討を行いました。 クロスアカウントにおける設定の中でいくつかの点で苦労しましたので、その知見を共有できればと思います。目的 Comadoでは様々なコンテンツを提供しており、それに伴うログを取得できる状態です。それらの行動データをイベントログとして収集し、データを分析することでより良いサービスに繋げたい狙いがあり収集することとなりました。サントリーウエルネスではAWSにシステムごとのデータを集めて分析する環境としてデータ基盤を構築しており、そこに連携することになります。Comadoで取得できるイベントログはデータ基盤に連携が必要ですが、Comadoとデータ基盤でAWSアカウントが別れているためアカウント間での連携が必要になります。 そのため、クロスアカウント連携ができるようにシステム構成を検討・設計しなくてはなりません。今回検討した連携方式 ログの出し分けの必要性 アプリケーションログとイベントログはそれぞれ利用目的が異なるため、目的にあった連携先に出し分ける必要があります。アプリケーションログは、エラーメッセージ、スタックトレース、デバッグ情報などを記録するため、フィルタリングやアラート機能を持つログ管理システム（AWSでいうとCloudWatch）に連携する必要があります。一方でイベントログはユーザーの行動単位で記録し、大量のデータを長期間保存できるストレージに保存したいです。AWSでいうとS3、Redshiftなどになります。この出し分けの機能を提供しているのがECSではFireLensです。今回はアプリケーションログはCloudWatchへ、イベントログはリアルタイムに送信したいためデータ基盤側のKinesisFirehose+S3を使用する構成

TechBlog始めました！ はじめましてサントリーウエルネス DX推進部 エンジニアリングGの青木です。この度、TechBlogを始めることとなりました。業務を通じて得られた知識や知見を形にし、外部に公開するとともに自分たち自身の成長度合いを確認する、互いに成長する雰囲気を醸成する場にしていきたいと考えております。至らぬ点も多々あると思いますが、温かい目で見守っていただけると幸いです。 よろしくお願いいたします！Recruit また、サントリーウエルネスでは 一緒に働ける仲間を募集しています。興味があれば是非ご覧ください！https://www.suntory.co.jp/recruit/dx/