コネヒト開発者ブログ

コネヒト開発者ブログ

LLMを用いた機能を "見せること" にこだわり実装する中で工夫したこと

みなさんこんにちは。 MLエンジニアのたかぱいです。

本日は、LLMを用いた機能をリリースするにあたり、どのように実装を進めていったのかをお話したいと思います。
完璧でなくとも実際に動くものを見せることで「触ってもらう→フィードバックをもらう→改善する」といったループを素早く回しながら実装していったよ、という内容になっています。

プロジェクト推進の話に関しては先日公開したブログに書いているので、興味がある方はこちらも見てみてください!

tech.connehito.com


目次


今回実装した機能

一言で言うと「自動で文章の要約を作成してタイトルとして挿入できる」という機能です(以降、タイトル生成と呼びます)

先日のブログ記事でも紹介しましたが、実際にユーザーさんからも反応があり、今後も改善しながらより良いものを作っていきたいと思っています💪

自動で要約を作成して挿入できる、って… ママリ機能すごい✨ たしかにめちゃくちゃ長文で、途中で読むの断念することよくあるから 助かる😂

要約機能が面白くて遊んでしまう!

ママリの要約を挿入するを使ってみました!

AI搭載なんかな??今すごいよね。

以降、バックエンド(ML側の処理)とアプリケーション(iOS側の処理)に分けて、実装プロセスの裏側を紹介していこうと思います。

ML

タイトル生成の裏側の処理には、Open AI APIとLangChainを利用しました。

概要図

プロンプト周りの検証

今回はどのようなプロンプトを作成するか?が肝になってきます。

そこで、まずは過去ママリに投稿されている文章を使い、様々なプロンプトを検証していきました。

ある程度良いプロンプトができたタイミングで、検証用アプリを社内メンバーに配布して、実際にスマホから触ってもらいフィードバックをもらいつつ、プロンプトの微修正を行っていきました。

社内メンバーに協力を仰いでいる図

今回はiOS端末限定で検証していたこともあり、検証用アプリがインストールできない人も何人かいたため、Redash上で同じ機能が触れるようにすることで、なるべく多くの人に使ってもらう工夫もしました。

以下のようなPythonコードをRedashで記述することにより、特定のエンドポイントからのリクエストを取得し、Redashで扱える形式で表示することができます。

import json
import requests

url = 'URL'
payload = {
    'user_id': 9999999,
    'content': "{{content}}"
}

headers = {
    'Content-Type': 'application/json',
    'User-Agent': 'sample-UA'
}

    
response = requests.post(url, json=payload, headers=headers, timeout=(10.0, 17.5))
title = json.loads(response.text)['title']

result = {}
add_result_row(result, {'title': title, 'content': "{{content}}"})
add_result_column(result, 'title', '', 'string')
add_result_column(result, 'content', '', 'string')

redashで検証した時の図

LangChainを用いた実装

LangChain とはGPT-3のようなLLMを利用したサービス開発を支援してくれるライブラリです。

複数のモジュールを組み合わせることで、複雑なLLMアプリケーションを作成するプロセスを簡易化してくれます。

今回は以下のような要約クラスを作成し、ユーザーがママリ上で入力したテキストを要約しています。

import openai
from dotenv import load_dotenv
from langchain.chains import LLMChain
from langchain.chat_models import ChatOpenAI
from langchain.prompts.chat import (
    ChatPromptTemplate,
    SystemMessagePromptTemplate,
    HumanMessagePromptTemplate,
)

load_dotenv()
openai.api_key = os.environ["OPENAI_API_KEY"]

class OpenAISummarizer:
    def __init__(self, human_message: str) -> None:
        self.llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0.2)
        self.delimiter = "####"
        self.system_template = """
            ここにプロンプトを挿入
                      以下のように記述することで、どこからどこまでがユーザー入力文(質問文)かを明確にしている
            The questions are separated by {delimiter} characters.
        """
        self.human_message = human_message

    def _create_prompt_template(self) -> ChatPromptTemplate:

        # systemメッセージプロンプトテンプレートの準備
        system_message_prompt = SystemMessagePromptTemplate.from_template(self.system_template)

        # humanメッセージプロンプトテンプレートの準備
        human_template = """{delimiter}\{human_message}\{delimiter}"""
        human_message_prompt = HumanMessagePromptTemplate.from_template(human_template)

        # chatプロンプトテンプレートの準備
        prompt = ChatPromptTemplate.from_messages([system_message_prompt, human_message_prompt])

        return prompt

    def run(self):
        # プロンプトの定義
        chat_prompt = self._create_prompt_template()

        # LLMチェーンの準備
        summary_chain = LLMChain(llm=self.llm, prompt=chat_prompt)
        result = summary_chain.run(delimiter=self.delimiter, human_message=self.human_message)

        return result

# 〜リクエストを受け取る部分は省略〜

# 要約の実行
summarizer = OpenAISummarizer(human_message=text)
response = summarizer.run()

LangChainの具体的な使い方などは以下のブログにも書いているので、興味のある方は見てみてください。

tech.connehito.com

以降のiOSパートはiOSエンジニアのゆりこにバトンタッチしてご紹介していきます。

iOS

タイトル生成機能のiOSアプリ実装を担当したゆりこです。

実装の進め方で工夫した点を挙げたいと思います。

全体スケジュール

施策具体化された6月1週目の打ち合わせでPdMより3週間後の4週目のリリースを目標にすることが伝えられました。この段階では仕様・デザインのFixがまだできていない状態。Miroでワイヤーを作りながらディスカッションを行なっていたので大まかな仕様とざっくりデザインはありました。

Miroに書かれた大まかな仕様とざっくりデザイン

アプリ実装担当として、まずは仮実装のものが開発環境で動かせる状態を早く作りたいと思いました。

理由は以下の通りです。

  • 3週間後にリリースするイメージをチームで共有したい
  • 仕様・デザインのFixで時間がかからないようにしたい

( ※ コネヒトではFirebaseのAppDistributionを使いリリース前のバージョンを検証端末として登録しているデバイスに配布することができるようになっています)

実際のところ、3週間後にMiroの大まかな仕様とざっくりとしたデザインが形になりユーザーが使っている状態をチームとしてはまだ想像しきれていなかったと思います。

また、デザイナーもこれまで打ち合わせには参加していないため、デザイン相談するにしてもキャッチアップに時間がかかりそうでした。

このあたりの課題を早い段階に仮実装アプリを配布することで一部解決できるのではと考えました。

当然、機能として動かすにはML側のAPIとの接続も必要でしたが、仮実装ではスピード重視でモックを使いAPI接続なしで動かしました。

最初に配布した仮実装は粗々なものでしたが、PdM・デザイナーに手元のデバイスで動かしてもらったことにより、仕様やデザイン観点ですぐにフィードバックがもらえ、最終的な「良さそう!」がもらえるまでスピード感を持ちながら進めることができました。

結果的に目標通りの期日に機能リリースできた点を踏まえると、粗々なものでも早い段階で仮実装を配布する動き方は施策をスピード感持って進める上で効果的であったと思います。

また開発環境への仮実装配布はチーム外の人も触れる状態になるので、この施策が閉じた環境で動いてないことをアピールする形にもなったと感じます。

この経験を他の施策にも活かしてアプリの機能改善をスピード感持ちながら進めていきたいです!

最後に

コネヒトでは一緒に働く仲間を募集しています! そして興味持っていただけた方は気軽にご連絡ください!

www.wantedly.com

第1回 リーン開発の現場輪読会 技術課題についてワイワイ編

こんにちは。Androidエンジニアのkatsutomuです。 前回に引き続き、狩野英孝さんのマイクラ配信にハマっています。 #12の家の地下が怪しいぞ!の巻のスポナーのくだりには驚愕しました!

さて本日は、社内で実施している輪読会の様子を、紹介したいと思います。 リーン開発の現場を3回に分けて輪読会を実施していく予定です。

コネヒトでは輪読会をはじめとして、共に学び合うカルチャーがあるので、少しでも社内の雰囲気を感じて貰えば嬉しいです。

輪読会の進め方

今回はリーン開発の現場という本を輪読しています。アジャイルソフトウェア開発手法のひとつであるリーンソフトウェア開発手法を、スウェーデンの警察機関のシステム開発で事例をもとに解説した本で、カンバンシステムを中心に書かれています。

リーン開発の現場 カンバンによる大規模プロジェクトの運営 | Henrik Kniberg, 角谷 信太郎, 市谷 聡啓, 藤原 大 |本 | 通販 | Amazon

コネヒトでもGithub ProjectsやZenhubで、カンバンを活用して開発を進めているので、業務のヒントを見つけるべく、有志を募って輪読会の開催に至りました。

そこそこボリュームのある本なのでそれぞれが個別で読み、事前に付箋を書く方法ですすめています。初回は第1章から第8章までが対象として、「思ったこと」「あるある」「やってみたい」の3つの観点で事前に付箋を書いてくるようにしました。

参加メンバーのお声

最初に、参加メンバーから感想を紹介します。

ささしゅう

技術課題の話で盛り上がる場面があったが、自身が所属しているプラットフォームグループのミッションとしても知りたい内容だったのでよかった。また、技術課題とは別の内容に比重をおいて本書を読み解くメンバーもいて、色々な視点を養えてよかった。

ほみちゃん

YuyaAboの話を聞いて捉え方が変わった。技術課題を解決することで、事業にどのような影響があるかは考えられていなかったので、いいきっかけになった。

otukutun

編成が違うプロジェクトのチームの事例が色々知れたので、今後の引き出しになると思った。 今のチームにどれぐらい当てはめられるかは、状況も違うのでしっかりと考えたい。

YuyaAbo

ボトルネックが可視化される一つの物理看板がすごい良いと思って読んでいた。 技術課題もボトルネックを解消するための一つの要素として扱うなど新鮮だった。今後も楽しみ。

それぞれ、何かしら学びを得られたと思いますし、今後の期待についてのコメントもあり、嬉しい限りです。この感想だけで満足せず、開発フローの改善もトライしていきたいと思います。

輪読会でワイワイと話したこと

当日は上げられた付箋から、いくつか「特に話したいこと」をピックアップし、社内の課題と合わせて1時間程度ワイワイと話しました。

今回は「第8章 技術課題をさばく」の内容が多くふれられ、

  • 技術課題をどう可視化するか
  • チームや組織で、どう管理するか
  • そもそも、どのように技術課題は捉えているか

というようなことが主題になりました。

この本には、技術課題の取捨選択のエピソードとして、開発フローのボトルネックになっている課題や、管理不能なクラスのリファクタリングの必要性を示すために、クラス全体を紙にプリントアウトした長さを元に、技術課題として対処すべきことを決める様子が書かれています。

それらエピソードから、開発のリードタイムを下げるなど事業的な価値と関連づけることが重要なのではないかという話に落ち着きました。

記入された付箋の数々

せっかくなので、今回の輪読会で上がった付箋を紹介します。

第1章 プロジェクトについて

第2章 チーム編成

第3章 デイリーカクテルパーティに参加しよう

第4章 プロジェクトボード

第5章 看板ボードをスケールさせる

第6章 プロジェクトのゴールを追え!

第7章 準備OKを定義する

第8章 技術課題を捌く

個人的な推し付箋は以下の2つです。

それぞれ4章プロジェクトボードと、8章技術課題を捌くで上げられた付箋です。 この2つを推している理由は、、今回、筆者が輪読会を開催した理由の一つに、開発フローのブロッキング要素可視化や技術課題の扱い方の事例を学び、チーム改善の種にしたいというモチベーションがあり、それが叶ったと感じた為です。

最後に

今回は、開発フローの改善のきっかけとして輪読会を実施した様子をお伝えしました。 今後は輪読会をきっかけに、どんな変化が起きたかもお伝えする機会を作れればと考えています。まずは、第2部 9~ 16章の内容を輪読会する予定です!

カンバンの運用に課題感を感じている方がいたら、ぜひ一度お手に取っていただくと良いかと思います。

リーン開発の現場 カンバンによる大規模プロジェクトの運営 | Henrik Kniberg, 角谷 信太郎, 市谷 聡啓, 藤原 大 |本 | 通販 | Amazon

そして、コネヒトでは一緒に働く仲間を募集しています! 興味持っていただけた方は気軽にご連絡ください!

www.wantedly.com

開発体験向上のためのプラットフォームエンジニアリング事例 - カナリアリリースをアプリケーションエンジニアだけで完結できるように改善した話

こんにちは。コネヒトの開発部プラットフォームグループでインフラエンジニアをしている @sasashuuu です。本日は私の所属するチームが最近興味・関心を持って取り組んでいるプラットフォームエンジニアリングの話題について取り上げたいと思います。弊社で行っていたカナリアリリースの運用改善の話になります。

はじめに

はじめに本記事の中心となるプラットフォームエンジニアリングとカナリアリリースの概要について簡単に触れておきます。

プラットフォームエンジニアリングとは、誤解を恐れずに端的に言えばアプリケーション開発者のためのプラットフォームの開発と提供を行うアプローチのことで、Gartner 社の プラットフォーム・エンジニアリングとは何か? の記事では下記のように解説されています。

「プラットフォーム・エンジニアリング」とは、アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプローチです。

  • プラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、インフラストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させる
  • 新たなテクノロジのアプローチであるプラットフォーム・エンジニアリングは、アプリケーションの再利用可能で構成可能なコンポーネントとサービスを活用する
  • ユーザーにとっては、標準化されたツールとコンポーネント、そして自動化されたプロセスを利用できるというメリットがある

カナリアリリースとは、アプリケーションをユーザー全体に公開するのではなく、配信対象者を一部に絞った形で公開する手法の1つです。

なぜ今プラットフォームエンジニアリングなのか

弊社では会社設立とサービスの公開から10周年の節目を迎え、プロダクトの成長を考える上でも重要な局面を迎えています。 そのような中、プロダクト開発の前線で働く社内のエンジニアのボトルネックになっている部分を解消し、開発体験を上げることで、開発力の向上を図りたいと考え、この領域に力を入れていきたいと考えています。その取り組みの一環として、開発体験を下げる要因の1つであった弊社のカナリアリリースの運用課題に向き合いました。

前提となる環境

今回の事例では主に下記の技術スタックなどから構成される内容がメインとなっております。

  • インフラ環境
    • AWS
    • Docker
  • アプリケーション環境
    • PHP
    • CakePHP
  • CI/CD
    • GitHub Actions

改善の全体像

ざっくりと改善内容のイメージを掴んでいただくために、改善前の状態と改善後の状態を図で表したものを紹介します。詳細は追って解説していきます。

背景・課題感

弊社でもランタイムやフレームワークのバージョンアップ作業など、アプリケーションにおいて影響度の大きいリリースに関しては、カナリアリリースを用いてリリース作業を行なっています。しかし、運用面で抱える課題感がありました。

元々行なっていたカナリアリリースの流れは下記のようなものです。

上記のフローにはそれぞれ課題感がありました。

チームを跨いだ調整コストや反映漏れのリスク

最初にアプリケーションエンジニアからインフラエンジニアへカナリアリリースの対応依頼が来ます。互いにスケジュールなどを調整し、リリースの日時などを決めていましたが、チームを跨いだ調整コストなどがかかっていました。

さらに、アプリケーションエンジニアからコードフリーズ の確認や連絡を受けてからインフラエンジニアが手動で ECR 用の Docker イメージを build し、 push していたので、調整コストの発生や反映漏れ発生のリスクなどがありました。

作業時の人的リソースやコミュニケーションコスト

リリース当日は、基本的に上記のような作業をインフラエンジニアが行い、アプリケーションエンジニアがアプリケーションの状況を監視しつつトラフィック割合の変更に関する意思決定を行い、インフラエンジニアがトラフィック割合を調整していくというような連携を取っていました。リリース作業ではアプリケーションエンジニアとインフラエンジニア数名が同期的に集まり作業を行なっていましたが、作業内容に対する人的リソースやコミュニケーションコストが少なくない印象でした。またリリース作業自体のオペレーションに関しては、高度なインフラ技術が求められるものではなく、権限さえあれば手順に沿ってインフラエンジニア以外も行えるような内容でした。

改善によりもたらされた効果

改善後は下記のようになりました。改善前のフローも再度併せて並べておきます。

before

after

上記のような運用に改善したことで抱えていた課題感などが解消されました。

手動作業の自動化を図り作業をインフラエンジニアから手離れ

GitHub Actions のワークフローを実行するとカナリアリリース用 Docker イメージの ECR への push から ECS のタスク定義およびサービスの更新を一貫して行なってくれるため、カナリア環境の立ち上げにインフラエンジニアが干渉することなく、アプリケーションエンジニアに独力でやってもらえるようになりました。 Manually running a workflow に記載のように、ブランチ指定をしワークフローを手動実行できるようにしたことで、アプリケーションエンジニアの任意のタイミングでカナリア環境を立ち上げられるようにしました。 ワークフローでは ECR 用のイメージの build ~ push を自動化した他、デプロイツールに kayac/ecspresso を使用することで、カナリア環境へのデプロイを簡素化しました。

また、GNU Make とシェルスクリプトで実装したタスクランナーを導入しました。 カナリア環境へのトラフィックを ALB の加重ルーティングで調整するツールとなっており、実装内容は AWS CLI のコマンドを make コマンドのインターフェースで実行するというものです。

こちらはイメージがつきにくいかもしれないので、サンプルコードの一部を載せておきます。

Makefile

.PHONY: {カナリアリリース対象のプロダクト名}_modify_weighted_routing
{カナリアリリース対象のプロダクト名}_modify_weighted_routing:
    bash utils/modify_weighted_routing.sh {カナリアリリース対象のプロダクト名}

modify_weighted_routing.sh

#!/bin/bash

set -eu

# カナリアリリース対象のプロダクト名
TARGET_PRODUCT_NAME=$1
# カナリア・本番環境の加重ルーティング割合(%)
CANARY_PERCENTAGE=1
PRD_PERCENTAGE=99
# HTTP・HTTPSのリスナーのarn
HTTP_LISTNER_ARN=
HTTPS_LISTNER_ARN=
# カナリア・本番環境のターゲットグループのarn
CANARY_TARGET_GROUP_ARN=
PRD_TARGET_GROUP_ARN=

# メイン関数
function main () {
    echo "${TARGET_PRODUCT_NAME}の加重ルーティング割合変更開始。"
        # 対象プロダクト固有の設定情報読み込み
    source ./env/${TARGET_PRODUCT_NAME}
        # 加重ルーティング割合のセット
    set_weight_percentage
        # リスナーのデフォルトアクション変更
    modify_default_actions $HTTP_LISTNER_ARN $HTTPS_LISTNER_ARN
    echo "加重ルーティング変更完了。"
    ./utils/describe_weighted_routing.sh $TARGET_PRODUCT_NAME
}

# 加重ルーティング割合(%)のセット
function set_weight_percentage () {
    read -p "カナリア環境へdeployする割合(%)を入力してください: " P
    if [[ ! $P =~ ^([0-9]|1[0-9]|2[0-9]|30)$ ]]; then
        echo "半角数字0から30の間で設定してください。"
        set_weight_percentage
    fi
    TMP_PERCENTAGE=$P
    read -p "${TMP_PERCENTAGE}%で投入します。よろしいですか?(y/N): " YN
    if [[ $YN = y ]]; then
        CANARY_PERCENTAGE=$TMP_PERCENTAGE
        PRD_PERCENTAGE=$(( 100 - $CANARY_PERCENTAGE))
    else
        set_weight_percentage
    fi
}

# リスナーのデフォルトアクション変更
function modify_default_actions () {
    # 引数(リスナー)の数だけ変更をかける
    for i in $@
    do
# aws cli利用時の--cli-input-json指定のためのパラメータを別ファイルで作成
cat << EOF > utils/parameter.json
{
"DefaultActions": [
    {
        "Type": "forward",
        "ForwardConfig": {
            "TargetGroups": [
                {
                    "TargetGroupArn": "${PRD_TARGET_GROUP_ARN}",
                    "Weight": ${PRD_PERCENTAGE}
                },
                {
                    "TargetGroupArn": "${CANARY_TARGET_GROUP_ARN}",
                    "Weight": ${CANARY_PERCENTAGE}
                }
            ]
        }
    }
]
}
EOF
    aws elbv2 modify-listener --listener-arn $i --cli-input-json file://utils/parameter.json
    trap "rm utils/parameter.json" 0 1 2 3 15
    done
}

# 全体処理の実行
main

コマンド実行例

% make {カナリアリリース対象のプロダクト名}_modify_weighted_routing
bash utils/modify_weighted_routing.sh {カナリアリリース対象のプロダクト名}
{カナリアリリース対象のプロダクト名}の加重ルーティング変更開始。
カナリア環境へdeployする割合(%)を入力してください:

かつてインフラエンジニアが AWS コンソールから手動で調整していたカナリアリリースの割合を調整する作業をタスクランナーに落とし込みました。これにより、カナリア環境へのトラフィックの調整作業がアプリケーションエンジニアで手軽にできるようになりました。

作業時の人的リソースやコミュニケーションコスト削減

リリース作業時にアプリケーションエンジニアとインフラエンジニアが同期的に集まって行なっていたやり方を改善することができ、アプリケーションエンジニア主導のもとカナリアリリースの加重調整の判断と調整作業を一貫して行えるようになりました。これにより、作業にかかる人的リソースやコミュニケーションコストを削減することができました。アプリケーションエンジニア主導で作業を進めてもらいつつ、何か問題があった際にインフラエンジニアがフォローに入るという効率的な運用を行える体制をつくることができました。

開発体験の向上

先述していた改善効果により、チームを跨いだ調整コストや人的リソースを削減し、アプリケーションエンジニアがカナリアリリースを行うハードルを下げることで開発体験の向上をもたらせたと感じています。

おわりに

コネヒトでは現在、プラットフォームグループと呼ばれるプラットフォームエンジニアリング促進しようとするインフラエンジニアのチームが存在しており、アプリケーションの安定稼働や障害対応はもちろんのこと、プラットフォームエンジニアリングにも注力していこうという動きが盛んです。社内のエンジニアの開発体験を向上すべく日々奮闘中ですので、ご興味のある方は今後の私たちの動きなどにもぜひ注目してもらえると嬉しいです。

コネヒトはiOSDC Japan 2023に協賛いたします!

こんにちは、iOSアプリエンジニアの@yanamura_です!

本日は、iOSアプリ開発者の祭典iOSDC Japan 2023に協賛するお知らせです。

コネヒトはiOSDC Japan 2023に協賛いたします!

iOSDC Japan 2023に、シルバースポンサーとして協賛いたします。

iosdc.jp

スポンサーするにあたって、コネヒトは「人の生活になくてはならないものをつくる」というミッションを掲げているので、技術コミュニティについても同様に、サポートして一緒に盛り上げていくことができたら、と思っております。

イベント概要

  • 開催 2023年9月1日(金)~ 9月3日(日)
  • 場所 早稲田大学理工学部 西早稲田キャンパス + ニコニコ生放送
  • 対象 iOS関連技術およびすべてのソフトウェア技術者
  • タイムテーブル https://fortee.jp/iosdc-japan-2023/timetable
  • 主催 iOSDC Japan 2023 実行委員会 (実行委員長 長谷川智希)
  • 共催 早稲田大学 理工学術院, 早稲田大学グローバル科学知融合研究所
  • 協力 WASEDA-EDGE人材育成プログラム, Beyond 2020 NEXT PROJECT, NEW

iOSDCトークンはこちら!

#mamari-swiftui

これはiOSDCチャレンジで使うトークンです!

今年もオンラインだけではなく、オフラインでも開催される予定です。私も会場に足を運びたいと思っています!会場でお会いした際にはぜひお話しましょう!

オペレーションズ・リサーチ 機関誌に弊社コネヒトの事例を寄稿しました

みなさんこんにちは。MLエンジニアのたかぱいです。

この度、OR学会(オペレーションズ・リサーチ学会)が発刊する機関誌68巻8号にて「出産育児に関する女性向けコミュニティサービスにおける機械学習の活用事例」というタイトルで、弊社の事例が掲載されました!

株式会社エルデシュ代表取締役の岩永 二郎さん、筑波大学の武井 柊悟さんとの共著になります。

オペレーションズ・リサーチ機関誌68巻8号の表紙

記事の中では、弊社が運営する「ママリ」というサービスに蓄積された行動履歴や検索履歴、投稿データに対して、機械学習を用いて課題解決をした以下二つの事例について、アプローチ方法や取り組みがもたらした結果などを解説しています。

  • Word2Vecとニューラルネットを用いたユーザへのQ&A推薦
  • BERTと勾配ブースティング決定木を用いたキーワード辞書作成

詳細な内容に関してはOR学会の機関誌をご覧ください。
会員の方は、以下よりPDFを閲覧することができます。

orsj.org

また、この度の寄稿に際して、岩永 二郎さん、武井 柊悟さんに多大なるご協力とサポートをいただきました。
この場を借りて心より感謝申し上げます。


今後も弊社は「あなたの家族像が実現できる社会をつくる」というビジョンのもと、事業活動だけにとどまらず、産学連携によるデータ活用の可能性を広げていく取り組みを続けて参ります!

産学連携の具体的な取り組みに関しましては、弊社HPのプレスリリースをご覧ください

connehito.com

コネヒトデータの活用にご興味のある大学や研究機関、研究者の方は下記からお問い合わせください。

産学連携プロジェクトお問い合わせフォーム

1児のママとして、ユーザーや仲間が喜ぶことを実現する | エンジニアインタビュー vol.2 Web エンジニア 高橋さん

こんにちは!コネヒトのプラットフォームグループでインフラエンジニアをしている @sasashuuu です。

本日の記事はコネヒトで働くエンジニアへのインタビュー企画第二弾です!

(前回のインタビュー記事:エンジニアインタビュー vol.1 iOSエンジニア 田中さん

Web エンジニアとしてママリの開発に従事するほみちゃんへのインタビューした際の内容をお届けしたいと思います!

  • sasashuuu(画像右)
  • ほみちゃん(画像左)

120名の総合職採用の中から選ばれ、思わぬ形でスタートしたエンジニアのキャリア!

sasashuuu:では早速インタビューしていきたいと思いますので、ほみちゃん、今日はよろしくお願いします!まずは簡単な自己紹介をお願いできればと思うので、名前やニックネーム、簡単なキャリアなどをお願いします。

ほみちゃん:高橋奈穂美です。社内では「ほみちゃん」というあだ名をつけてもらいました。エンジニア歴は多分6年ぐらいです。途中産休・育休もあったので実質何年かは覚えてないんですけど。新卒では広告の会社に総合職で入社しました。特にエンジニアを希望していた訳ではないのですが、その年だけ120名くらいの総合職採用の新卒の中から2名だけエンジニアに配属する枠があり、それに選ばれてエンジニアになりました。大学はシステム系だったんですけど。そこから育休・産休を3年目で取り、仕事の価値観が変わることがあって、もう少しエンジニア組織で働きたいなと思うようになり、転職をしました。コネヒトに入る前に一つ会社を挟んでいるんですけど、そこでより事業会社で働きたいという気持ちが強くなり、去年の6月くらいから転職活動をし、(同年)8月頃にコネヒトに入社しました。

sasashuuu:ファーストキャリアは全然エンジニアになるつもりはなかったんですね。(社内向けのプロフィールを見ながら)プロフィールに「エンジニアは向いていないと思ったので総合職採用で入社した」とあって気になったのですが、なんでそう思ったんですか?

ほみちゃん:大学が理工学部で授業でプログラミングがあったんですね。1回生の時に C 言語とかあったんですけど、単位落としていたんですよね(笑)その時はプログラムもちんぷんかんぷんで、「プログラムなんて自分は無理だ」と思い…。周りは SE へ就職する友達とかが多いかったんですが、広告代理店を選んだという感じですね。なので、入社初日にシステム開発部への配属と言われ時は、ぽかーんという感じでした(笑)

sasashuuu:(笑)そこでいきなり告げられて、「これからどうなるんだろう…」みたいなのはあったと思うんですが、(社内向けのプロフィールを見ながら)プロフィールに「優秀なトレーナーが丁寧に教えてくれたためなんとかエンジニアになることができた」とありますね。

ほみちゃん:そうなんです、付きっきりで教えてくれて教え方も上手だったので。業務交えて開発ができるようになっていったという感じですね。

sasashuuu:なるほど、すごい。僕もぜひ会ってみたいな。その後もエンジニアとしてキャリア歩み続けられているのには何かモチベーションとかあったりしますか?

ほみちゃん:最初は苦手意識がありつつ、今までも自信があるとはいえないですが、なんだかんだで、コード書いてるのが好きで。MTG 嫌だって訳じゃないんですけど(笑)

コードを真剣に3時間4時間ぐらいずっと書いているのが好きで、2年目ぐらいから意外と合っているかもなと思うようになって、そうなったからにはちゃんと頑張らないとなと思って。モチベーションは単純に「コード書くのが楽しいから」なのかなあ。

sasashuuu:エンジニアの鑑のような回答ですね。めっちゃ良いと思いました。最初挫折したもののそこから時間をかけ、結果向いてたんじゃないかと思い、今もエンジニアの道を歩み続けているということでよかったです。

チームのメンバーがとにかく面白い!to C の開発が楽しい!

sasashuuu:所属チームや仕事内容にも触れていきたいと思います。普段どんなチームでどのような仕事をしているんですか?

ほみちゃん:所属チームは Red チームというママリアプリの開発チームでバックエンド開発をしています。

sasashuuu:まさに主力サービスの最前線の開発現場でエンジニアをしている感じですかね。所属チームの魅力や仕事の面白さについても聞かせてもらえますか?

ほみちゃん:Red チームの魅力は色々あるんですが、1つのMTGで笑わないことがないくらい誰かしらが笑いを起こして、雰囲気がすっごい良いところ。もちろんふざけてるだけではなくて議論するところは時間が押すくらい。みんなそれぞれ考えを持っていて。意見を言わない人があまりいなくて。雰囲気がいいことで新入社員の方も早い段階で意見を言ってくれます。

sasashuuu:(社内の zoom 視聴者からのコメントを見ながら)「誰が一番笑わせてくれますか?」というコメントがきてますね(笑)

それに通ずる話にもなるかもしれないのですが、どうやってそんな雰囲気づくりが生まれているのかとかって感じることはありますか?

ほみちゃん:ゆりこ *1 がきっかけになることが多いかもしれないですね。翌週からタイへワーケーションをしに行くメンバーがいたんですが、「じゃあその週は挨拶をコップンカー *2 にしましょう」といきなりぶっ込んできたり(笑)

まあでもチーム全員が面白いからじゃないですかね。

sasashuuu:(笑)

ほみちゃん:仕事の面白さは、ずっとやりたかった to C の開発をユーザーの一番近くでやれていることで、特に印象に残っているのは「ママリ抽選会」です。短期間での開発というのもあり、追われる状況だったり、シニアエンジニアの方に鬼のレビューを受けたり、やってるときはしんどかったですが、終わってみるとユーザーの声なども聞いて自分の開発したものが世に出ていくのがやっぱ楽しいなと思いました。

sasashuuu:ふむふむ、なるほど。今出てきたママリ抽選会の内容について聞かせてもらえますか?

ほみちゃん:ママリは質問とか回答をするとポイントをもらえるのですが、今まで使えるところが用意できてなかったんですね。それを PdM などと試行錯誤して、そのポイントを使って抽選を行い、抽選を回すと、1等、2等、3等で Amazon ギフト券をもらえる機能を提供し始めていて、それがママリ抽選会ですね。

sasashuuu:ポイントの有効活用として生まれた感じなんですね。そのママリ抽選会で開発目線で苦労した点や身になったこと・良かったことなどはありますか?

ほみちゃん:苦労した点は、大きな開発だったので、抽選会が何なのかというドメインをしっかり理解して、コードに落とすということが難しかったですね。ロジック自体はみんなで考えていくことが多かったのですが、設計が一番苦労したと思います。

sasashuuu:なるほど。先ほどコード書くのが好きと言ってましたが、そういった設計などコードを書く以外の部分への興味とか関心もあるんですか?

ほみちゃん:設計も好きです。いいアーキテクチャで書いていくっていうのは好きで。型にハマった時に快感があるなと思います。

まあでもこの時は時間がなく、楽しいよりは焦りの方が強かったので楽しんで開発できたかというとそうじゃないですね(笑)

sasashuuu:振り返って見れば楽しかったな、という感じですかね。

ほみちゃん:そうです、そうです。

sasashuuu:抽選会って結構イベント感が強いと思うのですが、リリースした後の反響や手応えはありましたか?

ほみちゃん:お問い合わせで「抽選会楽しい」や「当たって嬉しい」といった感想が寄せられていました。「ママリポイントって何に使うの?」という問い合わせも(以前)多かったので、そういったところ含めてよかったかなと。

sasashuuu:なるほど。ありがとうございます。いい話だ〜。

ラフで面白い&技術好きな人達が集まるコネヒト

sasashuuu:次の質問に移っていければと思うんですが、コネヒトのエンジニアの印象について(どんな人が集まる印象かみたいなところとか)あればラフに教えてもらえますか。

ほみちゃん:エンジニアも面白い人が多いなと思います。あと、昨日(社内の)飲み会してて思ったのが短パン履いてる人めっちゃ多いのででラフな環境なんだなーと(笑)

あとはやっぱ技術的なことが好きな人が多いのかなって思います。輪読会も定期的にやってるし、技術を手段として捉えるだけじゃなくて、ちゃんと楽しんでやっている人達が多い印象ですね。

sasashuuu:つまり最高ってことですね!(笑)

ほみちゃん:そうですね、最高ってことですね(笑)

sasashuuu:たしかにユニークな発想を持った方とかが多く、それで技術も好きという感じなので、エンジニアとしても強みのある方が多いかなと思ったりしています。

働くママとして感じるコネヒトへの魅力

sasashuuu:色々聞いて来たんですが、世の中のママの味方になるママリを開発しているほみちゃんですが、ほみちゃん自身もご結婚されていてお子さんもいるということなので、働きながらお仕事されているという感じかと思います。そんな中で働くママエンジニアとして感じているコネヒトの魅力みたいなものもあれば聞いてみたいなと思ったのですが、この辺ってどうでしょう?

ほみちゃん:エンジニアだからっていうのはあまり関係ないかもしれないですが、子育てしやすい環境かなと思っています。こういう会社が当たり前になるのがいいんだろうなと。チームでいろいろ話している時、ママ目線は考えつつも、ママは人によって違うので自分の目線を捨てるというのも考えながらやってますね。

sasashuuu:子育てしやすい環境の話、僕自身結婚してなくて子供もいないんですけど、(社内の)ちょっとした勤怠連絡で「子供の体調が悪くて、一旦抜けます」みたいなことがあっても、みんなの(Slackの)リアクションやスタンプの付け方・コメントをみても理解がある人達でみんなあたたく見守っているんだなと感じたりしています。あと(ママ目線の話の)俯瞰してみる、みたいなのもいいなと思いました。

AmazonインセンティブAPI を使った実装で PdM の仕事を自動化し、社内の業務改善に貢献!

sasashuuu:最近、Amazon API の導入をリード *3 されていたそうですが、どういう経緯で進めたのかや良かったこと・困ったこととかも聞いていけたらと思います。よろしくお願いします。

ほみちゃん:チームの出社日が金曜日なのですが、その際に PdM が ママリ抽選会の賞品の Amazon ギフト券を手作業でひいひい言いながらユーザーにメール送信している現場を見て…。

API とかないの?というところから調査した感じです。

あるんだなーということは確認して、できそうなのはできそうという軽い気持ちで見て、大体こういうのって(実践導入が)流れるかなーと思っていたところ、同じチームメンバーのエンジニアから背中を押されてやっていった感じです。他のタスクは巻き取るから頑張ってという感じで。

良かったことは、社内の業務改善ができたことです。ママリアプリを開発していると社内の改善みたいなのってだんだん忘れていっちゃいがちだなと思うので、そこができたのが良かったかなーと思います。

あと、1人で外部の API を調査から連携をする開発を1からやったことはなかったので、単純にいい経験でした。

困ったことは、Amazon API のドキュメントが一見分かりやすそうで、分かりにくかったのがありました。(笑)ただドキュメント読んでるだけでは実装できなさそうで、色々調べて。とにかく(出回っている)情報が少なかったので。1件だけあった Qiita の記事が役に立ち、Amazon が用意している sample コードの存在なども知り、それを使うとスムーズに上手くいって。API 利用の実装はそんなに大変ではなかったんですが、エラーハンドリングや設計の部分は時間がかかったなと思います。あと、モックのテストとかもやったことがなかったので。

sasashuuu:ありがとうございます、とても内容の濃い Amazon API を使った開発裏話を聞けました。誰かの困りごとを技術で解決するみたいなところはエンジニアの醍醐味の1つでもあると思うので、めちゃめちゃナイスな価値を生み出されたと思いました。あと情報量が少ない中、頑張って奮闘したんだなという苦労が伝わりました。何かを実現したい時に参考になる情報がない、選考事例がないみたいなのはめちゃ大変だと思うので、そんな中やり遂げたのはすごいなあと思いました。

バッチ処理成功の際の歓喜の瞬間

改善ムーブの姿勢は育休中に感じた仕事に対する価値観の変化がきっかけ

sasashuuu:(社内の zoom 視聴者からのコメントを見ながら)「ほみちゃんの改善に対する姿勢はナチュラルな振る舞いなんですか?」という質問が来ていますね。

ほみちゃん:キャリアのところでも話したかもしれないのですが、育休・産休に入ってから結構仕事の価値観が変わったところがあってその辺からかな。社会人1年目、2年目などは目の前のことに取り組んでいたのですが、子供ができて子育てが大変で…。子育てって誰も褒めてくれないですが、仕事ってお金になったりとか何かしらの形で返してくれるじゃないですか。そこが仕事やっているのが楽しいなって思って。別に子育てが嫌なわけではないんですけど。そこから業務のこととかで気になったこととか何でも言うようにになったのかなと。

sasashuuu:改善とか仕事が楽しいと思えるサイクルが回せるのは理想ですよね、めちゃ良いなと思いました。それでは時間になったので、(質問などの)駆け込みがなければ今日のインタビューはこのくらいにさせていただこうと思いますが…。

katsutomu *4:次この人のインタビュー聞きたいとかあります?

ほみちゃん:よっしー *5 とか。私がバディ *6 をしている。

katsutomu:よっしーのここが聞きたいとかあります?

ほみちゃん:よっしーさんのキャリアはもともとエンジニアじゃなかったと思うので、そこら辺何が大変だったかなとか気になります。

katsutomu:よし、じゃあ次はよっしーということでみなさんお楽しみにしておいてください!

sasashuuu:今日はインタビューありがとうございました!

ほみちゃん:ありがとうございました!

*1:前回インタビューでインタビュイーをつとめた iOS エンジニアの田中さん。記事は エンジニアインタビュー vol.1 iOSエンジニア 田中さん を参照

*2:タイ語で「ありがとう」の意味を持つ言葉

*3:詳細は過去のブログ記事 ママリ抽選会にAmazonインセンティブAPIを導入してみました を参照

*4:前回インタビュー企画 エンジニアインタビュー vol.1 iOSエンジニア 田中さん でインタビュアーを務めた Android エンジニア

*5:プラットフォームグループのインフラエンジニア(「よっしー」というニックネームで呼ばれている)

*6:コネヒトでは入社したメンバーの立ち上がりをサポートしてくれる制度があり、その担当メンバーのことを指す

エンジニア発信でLLMを用いた機能のリリースまでの工夫とユーザーの反応

こんにちは。Androidエンジニアの @katsutomuです。

最近、狩野英孝さんのマイクラ配信にハマっています。 リスナーとのやり取りや、配信時に起きるトラブルに和ませてもらっています。みなさんもオススメのマイクラ動画があれば教えてください。

さて本日は、LLM(大規模言語モデル)であるOpenAI社のChat Completion APIを用いた機能をプロダクトにリリースしたので、そこに至るまでにどのようにプロジェクトを進めていったのかを中心に、2記事に分けてお話ししていこうと思います。

今日は、導入の進め方とリリース後のユーザーさんの反応を、katsutomuとPdMのおりちゃんの共著として、お伝えできればと思います!

モチベーション

今回の施策はエンジニア発で、価値ある機能を作りたいという想いで施策の実行を進めました。 昨今、コネヒトが組織として成長する一方で、役割分担が進みエンジニアからアイデアを出して施策を進める事例が少しずつ減ってきており、歯痒さを感じておりました。

ユーザーを深掘り、アイデアの段階から技術的アプローチでの解決策を考え、課題解決をすることがプロダクト開発の面白みの1つと考えているので、小さくても事例を作ることを目指し、実行に至りました。

ユーザーの課題を元にアイデアをブレストする

とはいえ、何も制約がないと進めづらくなると思い、機械学習×ネイティブアプリで制約をつけることを決めて、iOSエンジニアのゆりこと、MLエンジニアのたかぱいに声をかけて、アイデアの検討をはじめました。最低限決めたことは以下の通りです。

  • DAU(1日あたりのアクティブユーザー)に変化がありそうなアイデアを考える
  • 30min/weekのもくもくタイムで同期する

この段階から、PdMのおりちゃんに参加してもらうことも考えましたが、まずはたたき台になるアイデアを用意した方が意思決定がしやすいと考えて、まずはエンジニアだけで進めることにしました。

おりちゃんが、プロダクトの現状のサマリーや過去のユーザーインタビューなど、ユーザーの課題感の判断材料になるドキュメントを作ってくれていたので、そこから課題をピックアップして、解決策をそれぞれが考えてくることから始め、LLMの活用やFirebase 向け ML Kitでのスマートリプライを活用する案があがりました。

回答文を書く補助機能としてあげたスマートリプライ機能のアイデアは、LLMを用いてユーザーの補助をすると良いのではないか?というフィードバックもあり、社内で活用しているチャットボットで感触を掴みながら進めました。

LangChainとOpenAI APIを組み合わせて、文脈を考慮して会話できるSlack Botを作った話 - コネヒト開発者ブログ

このように施策候補を作り、スクラムチームの開発フローに乗せるために、以下の3つの施策をリファインメントの場に持ち込むことにしました。

チームを巻き込み、より良いアイデアを具体化する

リファインメント内でチームで会話し、実験していく価値があると判断できたので、PdMにもミーティングに参加してもらい、具体的な施策化を進めていきました。

結果的には、当初のアイデアとは違う、質問本文の最初に質問内容の要約を挿入する施策を進めることにはなりましたが、LLMをユーザーの補助機能として活用するというアイデアは引き継ぎ、実現方法をより具体化することを進めていきました。

いくつか抜粋して紹介すると、以下のような議題があがりました。

  • LLMのAPIをNativeアプリから直接叩くか、社内のAPIを経由するか
  • 要約文は、どのタイミングでユーザーに使ってもらうか。その場合ボタンを押してもらうか
  • 施策分析のためには、どのようなデータが必要か

毎回、図を見ながらワイワイと意見交換して、施策を詰めていけていたと思います。

キックオフからリリースまでのスケジュールをまとめると以下の通りでした。

  • キックオフ: 2023/04/21
  • アイデア検討・実装施策の決定: 04/27 ~ 05/24
  • 実装や社内PoC:05/24 ~ 06/18
  • リリース:06/19

実装を開始してからは、約3weekでリリースまで進めることができました。新しい機能の導入事例としてはまずまずといったスピード感と思いますが、今後はもっとリリースを早めて、より早くにユーザーに使ってもらいフィードバックをもらう方法を模索していきたいと思います。

このあとは、PdMのおりちゃんからユーザーからの反応を紹介してもらいます!

リリース後のユーザーからの反応

ママリアプリのPdMをやっています、おりです。

私からは、リリース後の反応について紹介します!

ママリ内での投稿

リリースして、早速ママリ内でこの機能に対する反応のお声がありました!

※ママリアプリでは、妊娠・出産・子育てのお悩み以外でも、ママリ機能に対する率直なお声を含む雑談やつぶやき投稿も日々盛り上がっており、主にCSのメンバーがママリに対してのフィードバックやご要望の投稿を即座にキャッチしてくださるので助かっています!

例えば以下のようなお声が上がってきました。

自動で要約を作成して挿入できる、って… ママリ機能すごい✨ たしかにめちゃくちゃ長文で、途中で読むの断念することよくあるから 助かる😂

要約機能が面白くて遊んでしまう!

ママリの要約を挿入するを使ってみました!

AI搭載なんかな??今すごいよね。

実際に色々な投稿文を打ち込み、どんな要約がされるのかを楽しんでいる様子も見られました。

本機能で期待していた使用方法とは正直異なるのですが、楽しんでもらえているのは素直に嬉しいですね!

利用データ

一方で、利用するユーザーの数は期待値よりも少ない状態でした。

「質問文に要約が挿入されることで、閲覧者(回答する側)が一覧の中から自分が答えられる質問を探しやすくなるようにしたい」という本来の目的を達成するためには、利用率を上げる必要がありました。

そこで

  • そもそも気づかれていないのか?
  • 気づいているけど使わないのか?
  • 仮にこれがデフォルトで挿入された場合印象としてマイナスになることはあるか?

といったことを深ぼるためにユーザーインタビューを行いました。

ユーザーインタビューでのお声

ユーザーインタビューでは、以下のような気づきがありました。

  • 投稿に慣れていない人にとっては、そもそも気づかれづらい
  • 投稿に慣れているユーザーにとっては、自分で文章の冒頭に要約を挿入することが負担ではないため、わざわざ使わない
  • ただし、ボタンをタップせずに自動的に挿入されることに対してネガティブに思わない
  • 一覧で要約が閲覧できることは便利だと感じてもらえる

これらの気づきを踏まえ、今度は「ユーザーに能動的に動いてもらうのではなく、いかに体験の中で自然と、でも強制感はなく要約を挿入できるか?」という問いに向き合っています!

この問いに対しても早速エンジニアのみんなが動くものを作り、それを見ながら議論ができているので、最速で仮説検証を回し、ユーザーにとっての価値を高めたいと思っています!

最後に

今回は、エンジニア発信の機能をリリースした時の工夫とその後の反応について紹介させてもらいました!具体的な実装内容やその他の工夫点は、近日中にMLエンジニアのたかぱいとiOSエンジニアのゆりこからもブログで紹介してもらう予定です。ぜひお読みください!

コネヒトでは一緒に働く仲間を募集しています! そして興味持っていただけた方は気軽にご連絡ください!

www.wantedly.com