はじめに こんにちは。2026年4月に新卒で入社したエンジニアの尾形です。 入社してからの半年間は、新卒研修の一環として、最初の3か月と次の3か月でそれぞれ別のチームに入って開発をしてきました。9月末でその研修期間が終わり、ひと区切りついたこのタイミングで半年を振り返ってみることにしました。 この半年でやってきたこと 大学院を修了して入社し、介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発組織に所属しています。カイポケは、長く提供してきたカイポケクラウドから、新しく作り直したカイポケコネクトへの移行を進めています（リニューアルの背景は こちらの記事 にまとめられています）。私はこの半年で、その両方のチームを経験しました。 4〜6月はカイポケコネクトのチームで、小さな修正から始めてモブプログラミングで少しずつ機能開発に入り、帳票の一覧・出力機能をバックエンドからフロントエンドまで通して実装しました。7〜9月はカイポケクラウドのチームに移り、長く運用されてきたコードベースで、不具合修正の施策や画面のパフォーマンス改善を担当しました。9月は次の制度改正への対応準備に加えて、カイポケコネクトのチームの開発にも一部関わり、9月末からは本配属先としてカイポケコネクトのチームで活動しています。 この半年で印象に残ったこと 現場やユーザーに触れた 最初のカイポケコネクトのチームでは、入社1か月目からユーザーインタビューに参加し、現場の声を直接聞きました。入社直後の研修で介護業界の全体像を学んでいたので、業務の大まかな流れは追いながら聞くことができ、研修で学んだ制度が実際の業務で使われているのを感じました。 7月には、デイサービスでの事業所体験にも参加しています。その日は送迎に同行し、レクリエーションの補助をしながら、主に記録業務を手伝いました。印象に残ったのは、利用者さん一人ひとりの状況に合わせた運用があることです。たとえば送迎では、耳の不自由な方の場合はインターホンを鳴らさず、決まった時刻より前から玄関前で待っていました。まだ準備をしていないだろうと予想できる方へは先に声だけかけておき、ほかの方を迎えている間に支度をしてもらうといった工夫も見られました。 記録は、ご家族に渡す連絡帳のもとにもなり、ご家族とのコミュニケーションに欠かせないものです。ただ、ケアに追われると記録は後回しになり、数字では表しづらいけれど連絡帳に書きたい、利用者さんのちょっとした様子ほど残すのが難しいというお話も職員の方から聞きました。 一方で、ドメインの理解には今も苦戦しています。入社直後は、帳票の種類も、それに絡む制度も、ほとんどわかっていませんでした。リファインメントで何の話をしているのかわからず、「何を聞けばわかる状態になるのか」すらわからない時期もありました。カイポケクラウドのチームに移ってからも、次の制度改正に向けた勉強会で介護報酬の単位数計算に初めて取り組み、その複雑さを痛感しました。 ただ、研修や事業所体験など学ぶ機会は多く、知っていることは少しずつ増えています。9月に受けた業界団体の介護請求システムの入門講座では、すでに聞いたことのある内容も多く、ゆっくりではありますが学んできた知識が定着してきたと実感しました。 わからないことをチームに頼った カイポケコネクトのチームでは、入社直後から夕会でタスクと関係ない雑談や相談ができたので、チームに声をかけやすかったです。モブにも気軽に誘ってもらえ、はじめは質問すること自体にハードルを感じていた私も、回数を重ねるうちに慣れていきました。担当した機能は、ほぼモブで実装するところから始めて詰まったときだけ相談する形に移り、最後は1人で実装するという段階を踏ませてもらえたので、自分の手で作りきれました。 カイポケクラウドのチームでは、自分から方針を出して見てもらう、という頼り方へ変わりました。最初の施策はデータ取り込みの不具合の修正です。局所的なバグに見えていたものが、実は仕様上の考慮漏れでした。そこで一通り調べたうえで、根拠を添えて「この方針で直します」とチームに伝え、方針を見てもらってから実装を始めました。先に見てもらえていたので、その後は安心して手を動かせたと感じています。 8月に担当したのは、利用者さんの介護サービスの予定を事業所へ送るときの、送信対象を一覧で表示する画面が重いという問題の改善です。SQLを書き換えると別の箇所で全件を読みにいってしまうなど、すんなりとは進みませんでした。手元で再現しながら原因を詰め、変更が複雑だったので、最後はチームでモブレビューをして一緒に確認してもらいました。5分以上かかってタイムアウトしていた画面は、今は8秒ほどで表示されます。 社内のいろんな人と話した 入社してから、チーム外の人とも1on1を重ねてきました。最初に申し込むときは「何を話そう」「勝手に予定を入れていいのか」と緊張していましたが、話してみるとどの方も快く時間をくださいました。半年で話した相手は20人以上で、職種もさまざまです。 カスタマーサポートの方からはサポートの仕事の様子を、事業部側の方からは事業としての判断の考え方を聞きました。開発チームの中だけでは聞く機会の少ない話で、カイポケという組織やプロダクトを別の角度から見るきっかけになりました。 入社前に心配していたのは、フルリモートの環境では一緒に働く人の顔が見えにくく、コミュニケーションを取りにくいのではないかということです。5月の社外カンファレンスでのブース運営やオフラインのイベント、1on1などで言葉を交わすうちに、Slackのアイコンを見て顔が浮かぶ人も増えてきました。今はリモートでも特に苦労することなく働けていて、心配は杞憂でした。 自分の動き方を自分で決めた 7月にカイポケクラウドのチームに着任したときは、着任から4週目までの過ごし方や、施策担当に期待することを言葉にして共有してもらえました。期待されていることがわかっていたので、自分から動き方を提案しやすかったです。 実際に8月末には、9月の動き方を提案しました。示されていた選択肢は、8月末でカイポケコネクトのチームに移るか、9月までカイポケクラウドのチームに残るかの2つでした。ただ、制度改正は数年に一度しかなく、改正の中身が固まる前の段階から関われる時期は限られています。研修期間中のこのタイミングだからこそ、どのような改正になりうるかを見立てる経験ができると考えました。一方で、カイポケコネクトのチームでは新しい案件が始まるところで、そちらにも早くから関わりたいと思っていました。 そこで、カイポケクラウドのチームで制度改正への対応準備を主に担当しつつ、カイポケコネクトのチームの開発にもサブとして関わる案を、3つ目の選択肢として伝えました。提案は受け入れられ、9月は両方のチームで動く形になりました。 カイポケクラウドのチームで9月に取り組んだのは、次の制度改正に向けて、何に備える必要があるのかを洗い出すことです。その時点でわかっていた厚生労働省の発表や過去の似た制度改正を調べました。そのうえで小さいチームに分かれて、ユーザーの業務やカイポケにどのような影響があるのかを検討し、関係するメンバーに発表しました。並行して、カイポケコネクトのチームでは、開発に向けた業務の流れの整理や調査を担当しました。 2つのチームのことを同時に考えるのは大変でしたが、制度改正への備えを通じて、ドメインのもっと深いところまで学ぶことができました。何より、自分で提案して納得感のある状態で動けたことが良かったと感じています。 2つのチームの違い 同じカイポケの開発でも、2つのチームが向き合っている課題はかなり違いました。 カイポケコネクトのチームは、モダンな技術スタックで新しいプロダクトを作っていて、課題の探索から実装・提供までをチームで一貫して行っています。私が関わったのはデリバリーの側で、ドメイン知識をキャッチアップしながらスクラムで開発を進めました。 一方のカイポケクラウドのチームは、すでに多くのユーザーに使われているサービスを運用しています。制度改正への対応、長く運用されてきたシステムの制約、お客様からの問い合わせなど、チームの内外から課題が次々と持ち込まれます。それらを事業としての優先度と見比べながら、何にどこまで対応するかを決めていきます。私が担当したデータ取り込みの不具合修正や一覧画面の改善も、すでに使われているサービスだからこそ出てきた課題でした。 2つのチームを経験したことで、プロダクトがどう作られ、どう使われ続けているのかを、少し立体的に捉えられるようになったと感じています。 これから 今はカイポケコネクトのチームで、新しい案件に本格的に取り組んでいます。 カイポケクラウドのチームで学んだ、資料を読み解いて調べる力や、チームで不確実なものを形にしていく進め方を、今のチームでも使えると考えています。 半年の研修では、任された範囲の中では自分で考えて動けていたものの、その範囲は1つの機能や施策といった小さな単位で、チームとして動くというよりは個として動く場面のほうが多くありました。これからは本配属となったチームで、周りの人を巻き込みながらプロジェクトを牽引できるようになることが目標です。 おわりに 半年を振り返ると、リファインメントで何の話をしているのかもわからなかったところから、制度改正の資料を読んで議論に加われるところまでは来ました。 入社前に制度やドメインに詳しくなっておく必要はないと思います。私も、研修や事業所体験、チームでのモブを通して、入社してから学んできました。半年経った今、自らの成長を実感しながら働くことができています。 この記事が、エス・エム・エスに入ろうと思っている方の参考になれば幸いです。

こちらは、カイポケのPdMが日々の考えや仕事の様子をリレー形式で発信する カイポケPdMブログリレー #1の記事です。今後もメンバーが順番に記事を公開していく予定ですので、あわせて読んでいただければ幸いです。 はじめに はじめまして。エス・エム・エスで「カイポケコネクト」のプロダクトマネージャー（PdM）をしている平松です。 2026年8月24日〜26日の3日間、AWS主催の「合同AI-DLC Unicorn Gym」に参加しました。複数の企業がチーム単位で参加し、それぞれ自社の実際のテーマを持ち込んで開発を進めるワークショップ形式の研修です。 本記事では、この研修で感じたことをPdMの立場から書いてみようと思います。 AI-DLCとは AI-DLC（AI-Driven Development Lifecycle）は、AWSが提唱しているソフトウェア開発の方法論です。AIが作業計画を立て、不明点を人間に質問し、重要な判断は人間に委ねる、という進め方を前提にしています。 https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ 開発はInception（構想）、Construction（実装）、Operations（運用）の3フェーズで進みます。 研修の冒頭では、AIに開発を任せきる「AI-Managed」と、人間の開発をAIが補助する「AI-Assisted」と対比して、AI-DLCは「人間が検証・意思決定・監督の責任を持ったままAIを開発の主体にする」アプローチだと教えてもらいました。 AWS公式ブログ「AI-Driven Development Life Cycle」をもとに作成 3日間でやったこと 私たちのチームは、介護事業所の請求業務を支援する社内ツールをテーマにしました。チームにはエンジニアとPdMに加えて、このビジネスのオーナーである事業部のメンバーも参加してもらいました。 1日目 ：午前中は導入となるハンズオン形式で、本格的な研修は午後から。目的と最低限の要件を伝えるところから始め、PRDを読ませてInceptionを開始しました。AIから質問リストが届き、それに回答していくことで仕様が決まっていきます。 2日目 ：引き続きInception。対象業務の流れを言語化してチームの認識をそろえ、ユーザーストーリーの作成まで質疑を続けました。並行してプロトタイプを実装し、社内ユーザーへのインタビューを行いフィードバックまで得られました。 3日目 ：Inceptionを終え、1つのUnitをConstructionまで進めました。発表の直前になんとか実装が完成しましたが、期待どおりに動くかの検証までは充分にできませんでした。 学んだこと 1. モブエラボレーションで、事業部メンバーと同じ目線で曖昧な要求を明確にできた 普段は曖昧に使っていた業務用語について、AIの質問をきっかけにその場で認識のずれを確認し、定義することができました。1日目には、業務上のステータス更新の判断根拠を大きく見直しています。当初は、ある書類の情報だけで判断する想定でした。しかし、AIから「判断材料になるフィールドはどれか」と問われて見直したところ、その情報だけでは特定しきれないことがわかり、複数の情報を組み合わせて判断する方針へ変えました。当初の想定から最も大きな変更でしたが、利用者であり事業責任者でもある事業部メンバーと、背景の理由まで含めてその場で合意できました。 重要な要求とそうでもない要求の区別が、ニュアンスを含めすぐに確認できたことも良かったです。最終的にスコープから外したアイデアもいくつかありますが、「そのペインがどれくらい深刻か」と「どう解決できそうか」を同じ場で議論できたので、外す判断にも納得感がありました。 3日目には、AIにConstructionを進めてもらっている間に、事業部メンバーと将来構想や次に解決したいイシューについても認識をそろえられました。 ただ正直なところ、この恩恵の多くはAIの質問そのものより、事業部メンバーも同じ場にいてすぐ合意できるモブの形式によるものだったと感じます。また、ドライバー役の画面を全員で追いかける形式なので、進行中の内容をチーム全員で把握し続けるのが難しい場面もありました。 2. 早い段階でコンテキストを渡すと、いちから考えずに済む AI-DLCでは、AIがコンテキストをもとに質問を投げてきます。最初に渡す情報が多いほど、いちから考える時間が減り、AIからの質問も具体的になりました。プロトタイプを短時間で用意できたことで、2日目のインタビューでは画面を見てもらいながら業務の実態や反応を聞くことができ、その作業の中で何を達成したいのかが明確になりました。 一方でうまくいかなかったこともあります。開始時、AIが既存コードをリバースエンジニアリングして得られた情報は具体的かつ大量でした。それにひきかえ、1日目にインプットしたコンテキストがテーマに関するPRDのみで比較的少量だったため、この差を埋める作業に時間を費やしました。コンテキストを補うため、2日目にツールの全体像を表す上位のPRDや請求データに関するインターフェイス仕様書一式を途中追加したところ、1日目に決めた内容との矛盾指摘や追加質問が次々出てきて手戻りが発生してしまいました。 また、Inceptionの段階でもフィールド名定義のような詳細な質問が混ざってくるため、「今はその段階ではない」と後回しにする判断を都度求められ、神経を使いました。 3. プロセスをそのまま使うより、部分的に取り入れるほうが現実的 3日間体験して、日々の業務との違いを身をもって実感することができました。 AIの出力はシンプルに文章量が多く、AI独特の言い回し（強引な比喩やカテゴライズ）もあって読み下すのに時間がかかります。国語の文章問題を延々と解いている感覚で、知的負荷が高く疲れました。 普段ならディスカバリーに時間をかけて判断していることを、その場にいるメンバーの判断で進めていく形になります。その場で答えを出せる問いならよいのですが、不確実性が高い問いに向き合う場合は作り直しが増えそうです。 ユーザーへの提供価値やイシューがある程度明確でコンテキストとして渡せる情報が充分にある場合や、ミッションクリティカルではない試行錯誤を許容できるような場合など、ある程度テーマを選ぶ必要があると思いました。 また、運用面では研修のように全工程をモブで進めるより、非同期の作業を中心にして必要なときにモブで集まる形のほうが現実的だと感じました。 業務への影響 研修を終えてしばらく経ちますが、日々の業務で変わってきたことがいくつかあります。 イシューの大きさに合わせて、渡すコンテキストの量を考えるようになった 研修のように大きなイシューに取り組む場合は、最初に渡す情報が多いほどうまく進めやすいように思います。一方で日々の業務でAIに頼む作業には、もっと小さな問いも多くあります。そこで、解きたいイシューの大きさに応じて、どこまでの情報を渡すかを意識するようになりました。小さな問いに大量の前提を渡すと論点がぼやけ、大きな問いに前提が足りないと的外れな提案が返ってくると感じたためです。 機械も人も読みやすいドキュメントを残すようになった AIに読ませる前提でドキュメントを書くと、用語定義や問題の構造整理などを言語化する場面が多々あります。これらは、今まで口頭などで無意識的に共有されていた情報も多く、AIに限らず人間にとっても読みやすいものでした。AI-DLCを使うかどうかに関係なく、参照される情報を体系立てて整理しておけば、関係者の前提がそろい議論しやすくなります。 相性が良さそうな案件で、今後も試行錯誤し続ける AI-DLCはすでに新しいバージョンが公開されていて、Inceptionのフェーズが細分化されたり、ハーネスやスキルによる学習のステップが加わるなど、プロセス自体が変わり続けています。研修中にAWSの方と新バージョンについて話した印象では、こちらもまだ発展途上です。手法をそのまま導入するのではなく、自分たちの開発プロセスのどこにどの程度適用できるかを引き続き探っていきたいと思います。 まとめ：AI時代のPdMに大切なこと 今回の研修を通じて、AIを前提とした開発でPdMに求められることは次の2つだと考えるようになりました。 1. フェーズに合わせて、適切なコンテキストを用意すること AIは渡されたコンテキストの量と質に応じて動きます。構想の段階では「なぜやるのか」や「どんなジョブを解決したいのか」といった顧客の声を、要件を詰める段階ではモデリング結果の言語化やシステム上の制約を、というようにフェーズに合わせて渡す情報を選別することが効率的に開発を進めるポイントだと感じました。 これはAIとの対話に限った話ではなくチームメンバーと業務を行う上でも同じことが言えて、相手のバックグラウンドをふまえた情報提示が肝要といえます。 特に、判断の根拠として情報源を明確にすることや、顧客のVoCやインタビューの発話などの一次情報に触れることを、今後も意識していきたいですね。 2. 不確実性と向き合い、イシューを立てること AIは与えられた情報をもとに、高速に大量のアウトプットを提示してくれます。逆に言えば、前提となるイシューが外れていれば、外れた成果物が簡単にでき上がってしまいます。だからこそ、どんなイシューを解くのか、ユーザーの得られる価値は何か、といった上流工程がより重要になります。 今回の研修中は、普段ならディスカバリーに時間をかけて判断する事柄も、その場のプロトタイプと議論で決めながら進めました。即答できる問いは一気に進む一方、不確実性の高い問いまで同じスピード感で進めてしまえば、作り直しが増えそうだと感じました。 また、生成AIのおかげで、エンジニアやデザイナーはたまたビジネス職のメンバーでも、WhyやWhatを組み立てることが比較的容易になりました。 各ロールが自律的に動けるようになる中で、PdMに求められていることは何でしょうか？ それは、中長期的なビジョンを見据えつつも、いま限りあるリソースでどんな価値を提供すべきか、といったより複雑でより不確実なイシューに向き合うことだと考えます。私自身、立てたイシューや提供価値について、意思決定するための材料がそろっているかを以前より意識するようになりました。 余計なものまで作り込まないよう、自戒として 蛇足のダソくん を頭の片隅に。（わかりやすくて重宝してます） おわりに 貴重な機会をいただいたAWSの皆さん、ありがとうございました！麻布台ヒルズの社食ランチに、カフェのコーヒー、安くて美味しくて、素晴らしい福利厚生だなと思いました。 弊社ビルも右下あたりに確認できます 最後になりますが、学んだことを日々の業務ですぐに実践できる環境（事業部との距離の近さ、頼もしい開発メンバー）で仕事ができるというのはありがたいなぁと改めて感じました。 エス・エム・エスでは共に働くメンバーを積極募集中です。少しでも記事に興味を持っていただいた方は、一度カジュアル面談でもいかがでしょうか？

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。 今年の夏頃、所属チームで立ち上がった「4スプリント限定のAI実験チーム」にQAとして参加しました。本記事では、QAの作業をどこまでAIに任せ、どこから人間が見るべきかという線引きを、チームの判断基準として言語化してみた試みを紹介します。 まだまだ試行錯誤中の内容も含まれていますが、同じように悩んでいる方の参考になれば嬉しいです！ AI実験チームってどんなもの？ AIでコードを書く速さが上がる一方で、レビューやQAがボトルネックになる可能性も見えてきた、という課題感から、既存プロセスに縛られずに試せる場として実験チームが立ち上がりました。 期間 ：2週間スプリント × 4本のタイムボックス 体制 ：開発2名＋QA1名の最小構成 テーマ ：既存チームのベロシティに影響しにくいよう、ロードマップに寄与しつつもクリティカルパス上にはないもの（扱った機能の具体例としては請求画面の改善など） 「失敗してもいい範囲」が最初から決まっているので、本番品質に直結するQAプロセスの実験にも思い切って踏み込めたのがありがたかったです。 どんな仮説を立てた？ 実験を始めるにあたって、チームでは次のような仮説を立てました。 全てのPBIを既存プロセスでQAせず、可能な限りAIに任せることで、低リスクで価値が高まる部分があるのではないか？ どこを「省略していい」かを決めることは、裏を返せばどこで「慎重であるべき」かを決めることでもあります。ただ、その判断はこれまで個人の感覚に頼りがちでした。リスクの濃淡はストーリーポイントとも一致せず、小さなPBI（プロダクトバックログアイテム）でも品質を落とせない領域に触れることがあります。 そこでPBIごとに最初に「Tier判定」をおこない、通るテストプロセスの重さを「軽量プロセス」と「重量プロセス」に分岐させてみることにしました。Tierはテストの厳格さを表す3段階の区分で、Tier1が最も厳格、数字が大きくなるほど軽いテストになります。 プロセス 対象 人間（QA）がやること 軽量プロセス Tier1以外 AIが作ったテスト計画・テストコードのレビュー、探索的テスト 重量プロセス Tier1 上記に加えて、詳細なテスト設計・テスト実装・スクリプトテスト実行 判断基準をどう言語化した？ きっかけになった2つの実例 実験チームでAIと一緒にテスト計画やテスト設計を進める中で、判断基準が必要だと強く感じた出来事が2つありました。AIに任せてうまくいったケースと、うまくいかなかったケースです。 うまくいったケース ：小粒なPBIで、AIが出したテスト観点をレビューして品質リスクは低いと判断し、網羅的なテストなしでGo判断。問題なくリリースできました。 うまくいかなかったケース ：AIが「内部処理ではグルーピングされるはず」という期待値を出してきましたが、外部仕様ではグルーピングされないのが正しい挙動でした。AIはコードから振る舞いを推測するのは得意でも、「今のビジネスルールとして何が正か」までの判断は難しく、業務知識を持つ人間だからこそ気づけたズレでした。 この2つから、「AIを信じてよい場面」と「立ち止まるべき場面」を基準で分けたいと考え、判定基準をClaude Codeのスキルにしてチームで試しています。 スキルには後述するTier判定の質問や再判定の観点をそのまま書き込んであり、チケットを渡すと次のような決まったフォーマットで判定結果を返してくれます。 ## <チケットキー>: <タイトル> **判定: Tier<N>（<厳格/標準/軽量>）** - 根拠: <どの質問でどう判定したか> - テストボリューム: <網羅/正常系＋探索/なし> - 実施者: <誰がテストするか> - 確認してほしい点: <要確認の場合のみ> - AIテスト適性: <AI向き/ハイブリッド/人間向き>（3観点それぞれの判定つき） 「テスト設計して」と頼んだ場合は、この判定結果に続けて観点別のテストケース表と、仕様が曖昧な点の確認リストまでまとめて出力します。 軸1：Tier判定（どれくらい厳格にテストするか） 3つの質問に上から答え、最初に「はい」になったところでTierが決まります。 上の図のQ2で「はい」になった「Tier1候補」は、副作用はあるものの、本当に厳格なテストが必要かはまだ分からない状態です。そこで、次の4つの観点でもう一段階チェックします。 外部に出る成果物に影響するか ：帳票のPDFや請求書、介護報酬を請求するための提出データなど、お客様や外部機関に渡るものの中身が変わるか 不可逆か ：重複登録や実績確定のように、一度実行すると後から取り消したり直したりしにくい操作か 必須業務が止まるか ：エラーによって、実績確定や請求といった毎月必ずおこなう業務が完了できなくなるか 値そのものが違うか ：見た目の崩れではなく、金額や件数などの値自体が正しくなくなるか 1つでも当てはまればTier1として重量プロセスへ、どれにも当てはまらなければTier2として軽量プロセスに進みます。判断しきれない場合は無理に決めず「要確認」とします。 「要確認」の場合は、「プレビュー表示だけの問題か、PDFに出力される値自体も違うのか」のように確認すべき観点もあわせて出力し、チームでも確認したうえでプロセスを確定させています。誤ってTier2に倒してしまうより、確認を挟む方が安全だと考えているためです。 実験期間中に「要確認」になったケースは、そこまで多くありません。ほとんどの場合は3つの質問でそのままTierが決まり、迷うのは4観点の詳細確認が必要なTier1候補が中心です。 Tier テストボリューム 実施者 Tier1（厳格） 網羅 QAがケース設計、チームで受け入れレビュー Tier2（標準） 正常系＋探索 エンジニアがユニット・E2E、QAが探索的テスト Tier3（軽量） 既存の自動回帰のみ エンジニアのみ 軸2：AIテスト適性（AIに任せやすいか） Tierとは別に、「依存関係が薄いか」「一般的な技術知識で判断できるか」「仕様が変わりにくいか」の3観点で、AI向き／ハイブリッド／人間向きを判定します。Tier1でも計算ロジックが明文化されていればAI寄りになるなど、重さとAIへの任せやすさは別物、というのがポイントです。 どちらの判定も出力はあくまで一次案で、最終判断はチーム（QA・エンジニア・PO）でおこなっています。 実験を終えてどうだった？ 使う人と使い方が広がった 4スプリントの実験期間を終えた現在もスキルは使われ続けています。 Tier判定とテスト設計のたたき台を蓄積するesaのカテゴリを用意したところ、実験チーム以外のメンバーも使い始めてくれて、判定結果がどんどん増えてきました。 使い方も少しずつ広がっています。当初はTier判定とテスト設計のたたき台が中心でしたが、最近では探索的テストの計画づくりや、既存のE2Eテストでどこまで画面遷移をカバーできているかの棚卸しにも応用されています。 「判定の型」が決まっていることで、人が変わっても同じフォーマットで議論できるようになったのは、思っていた以上に大きかったです。 難しかったこと 一方で、実際に運用してみて見えてきた難しさもありました。 判定がキーワードに引っ張られる 表示崩れを直すだけの修正でも、対象画面に金額に関わる言葉が含まれているとTier1と判定されることがありました。逆に、金額に関わる機能でも、トーストの文言修正だけであれば正しくTier2と判定できたケースもあります。 「何に触れるか」と「何を変えるか」を分けて見る必要があり、ここは判定ロジックの改善ポイントとして残っています。 判定の前提になる事実が足りない 「ボタン押下後に選択を変えても、実際に出力される内容は変わらない」といった事実が確認できて初めて、Tier2と自信を持って言えるケースがありました。判定の精度は、チケットにどれだけ事実が書かれているかに大きく左右されます。 結局のところ、「要確認」をどれだけ素早く解消できるかが、軽量パスに乗せられるかどうかの分かれ目になっていると感じています。 設計が固まるタイミング自体はあまり早くならない 表示方針がPOとのすり合わせで確定するまで、テスト設計を暫定版として置いておき、決定後に作り直すこともありました。AIのおかげでたたき台を作るコストは下がりましたが、「何が正か」が決まっていないものは、どれだけ速く作っても手戻りは発生します。 ただ、これはテスト計画を早い段階で出せるようになったぶん、仕様の曖昧さに早く気づけるようになった、と前向きに捉えています。 QAの役割はどう変わりそう？ QAの役割は「自分の手でテストを実行する人」から、「AIの出力のどこを信じ、どこを疑うかを判断し、その基準をチームに広める人」へ変わりつつあると感じています。 とはいえ、仕事が減るわけではないと考えています。今回の実験を通して改めて意識したのは、軽量パスで生まれた余力の使い道です。その余力は、重量パスに残る「人間にしかできない仕事」に再配分されていくと感じています。たとえば、ビジネスやドメイン理解に基づくテスト設計や、まだ言語化されていない違和感を探しにいく探索的テストです。 これからQAが主導すべきアクションとして、次の4つを考えています。 判断基準をつくり、広める ：AIに任せる／任せないの判断を、チーム全体が使える基準にする 危険信号の勘所を伝える ：AIでは現状カバーが難しいポイントを共有し、同じ勘所を持てる人を増やす 失敗を学びに変える ：間違いを個人の反省で終わらせず、判断ロジックの改善につなげる 「なぜ」を残す ：仕様判断や運用リスクの背景を、人間もAIも参照できる形で残す どれも「リスクを言語化する」仕事で、QA組織の行動指針に掲げている「チームで品質保証」にもつながる取り組みだと感じています。 tech.bm-sms.co.jp まとめ AIに任せる範囲を決めることは、QAの仕事を手放すことではなく、リスクの言語化という本来の仕事そのものでした。 判定基準の精度向上は今も続けていて、実験チーム以外の現場でも検証や利用を進めています。判定がずれたケースこそ基準を磨くヒントになるので、引き続きみんなで育てていきたいと考えています。 一緒に取り組んでくれたメンバーをはじめ、いつもサポートしてくださるみなさん、ありがとうございます！ エス・エム・エスのプロダクト組織やQA組織に少しでも興味を持ってくださった方は、ぜひカジュアル面談でお話しさせてください！

こんにちは。株式会社エス・エム・エスの人材紹介開発グループの藤井と申します。 以前、看護師向け人材紹介サービス「ナース専科　転職」のWEBエンジニアとして取り組んだスクラムの改善についてご紹介しました。 現在は、複数のWEB開発チームを横断して伴走する「イネイブリングチーム」の立ち上げと推進を担っています。 本稿でご紹介するのは、このイネイブリングチームの立ち上げから現在までの半年間です。この半年で、私たちは自分たちのスコープを一度大きく変えました。何を考えて始め、何をきっかけに、どう変えたのか。まだ道半ばの取り組みですが、考えたことを残しておきたいと思います。 ※本稿では、WEB開発を担当するエンジニアのチームを「開発チーム」、主には集客に責任を持ちつつ事業成長をミッションとするマーケティング組織を「マーケ」と呼ばせていただきます。 イネイブリングチームを立ち上げるまで 当社には、医療・介護などの分野で職種ごとに複数の人材紹介サービスがあり、それぞれにWEB開発のチームがあります。 各チームは、担当するサービスの事情に合わせて運用を磨き込んできました。マーケが施策を立案し、開発がそれを確実に形にする。役割が明確なぶん速く回せる進め方で、これまでの成果はその積み重ねの上にあります。 受け取って作る、から、一緒に事業を伸ばす へ 一方で、依頼を受けて実装するところに軸足が置かれていると、開発側が施策の「なぜやるのか（Why）」に踏み込む機会は限られていきます。見方を変えれば、次のような伸びしろがありました。 施策の背景や期待する成果を、着手する前にもっと深く握れる 作ったあとの効果を見届け、そこで得た学びを次の施策に活かせる 各チームが積み上げた工夫を、他のチームへ流していける 長く取り組んできた開発基盤の整備が一段落し、これまでより速いペースで改善を重ねられる土台が整ってきたタイミングでもありました。そこで次の段階として、 開発組織も事業責任を担い、マーケと一緒にサービスを改善して事業を成長させる状態 を目指すことにしました。 進め方の言葉にすると、変えたいのはここです。 これまで これから Why（なぜやるのか） マーケが定め、開発は依頼として受け取る マーケと開発で一緒に考える What（何を作る・試すか） 依頼の内容として決まっている 優先度も成果指標も一緒に決める How（どう作るか） 開発が担う 開発がリードする（ここは変わらない） WhyとWhatに開発が入っていくぶん、マーケにとっても技術観点からの提案を受け取りやすくなり、結果を一緒にふりかえりやすくなります。どちらか一方のための変更ではなく、双方に利のある形にしたいと考えていました。 立ち上げ時に置いた2つの方向性 以上を踏まえ、立ち上げ時の方向性は大きく2つとしました。 各 WEBチームの接続を強める — 違いを整理して見える状態にし、学びを橋渡しする マーケと一緒に Why から考えていける組織をつくる — 開発も事業成果に責任を持つ前提で、Whyから並走する 「イネイブリングチーム」という名前はどこから来たか この2つを進める役割として立ち上げたのが、イネイブリングチームです。名前も考え方も、 『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター） をもとにしています。 同書では、組織のチームを4つの基本タイプで捉えます。私たちの状況に当てはめると、各サービスのWEB開発チームは、ユーザーとビジネスへの価値提供に責任を持つ ストリームアラインドチーム にあたります。そして イネイブリングチーム は、ストリームアラインドチームが自律的に動けるよう、特定の領域で能力のギャップを埋める役割を担うチームです。 ここで最初に握っておいたのは、 代わりにやってあげるチームではない ということでした。同書でも、イネイブリングチームは支援する相手の作業を肩代わりするのではなく、相手が自分でできるようになることを目的とし、その関わり方も恒久的なものではないとされています。 この前提を先に置いたことが、後々まで判断の支えになりました。実際、チーム指針には「やらないことリスト」を用意し、その先頭に「各チームの代わりに、要件定義やバックログ整理を全部代行する」を置いています。成果は「自分たちで作った量」ではなく「各チームが自走できるようになったか」で測る、とも決めました。 こうして、決める立場ではなく各チームの隣で一緒に走る存在として、少人数のチームで活動を始めました。 なお、このあとご紹介するスコープの変更を経て、現在の私たちの実態は同書の定義そのままではなくなっています。その点は後半で改めて触れます。 最初の半年でやったこと ここからは、各チームへの働きかけとして実際に手を動かしたことを3つご紹介します。 1. まず「知ること」から始める いきなり共通化に進まず、各チームのリーダーへのヒアリングと定例への参加から始めました。あわせて、開発メンバー向けの説明会とマーケの皆さんとの対話会も実施し、目標・運用・強み・困っていることをフラットに聞かせてもらいました。 ヒアリングを重ねて分かったのは、チームごとに置かれた状況がかなり違うということでした。連携が成熟しているチーム、短期の目標がきびしいチーム、組織の再編が進行中のチーム。同じ型を同じ速度で当てはめてもうまくいかないことは明らかでした。 そこで、進め方の原則を3つ決めました。 どこまで踏み込むかの線は、暫定版から磨く — 机上で書き切らず、現場を見ながら更新していく前提で置く 抽象的な線引きより、1件の事例を先につくる — 実際にうまくいった例のほうが、話が早い 対象を絞って厚く入る — 全チーム同時展開はしない。成功確率の高いところに集中する 型から入らず、まず聞くことに時間を使ったからこそ、どこにどう入っていくかを、机上の想定ではなく各チームの実態に合わせて決められました。 2. 課題管理のフォーマットを揃える チームごとに起票の粒度や指標の定義が異なると、他チームの取り組みから学ぶことが難しくなります。そこで、管理のためではなく「お互いの工夫から学べるようにするため」という目的で、課題管理のフォーマットを共通化しました。 課題種別（機能開発／仮説検証／技術改善／調査／保守運用／不具合対応）を定義する サイズ・ターゲット・期待される効果の大きさ・緊急度などを、数値型ではなく選択リストで持つ 起票時にWhyを必ず言語化する運用に揃える 「そもそも何を課題として起票するか」の基準も言語化する（1行の修正まで起票するのか、など） 全チーム一斉ではなく、準備の整ったチームで先行導入して検証する 自由入力ではなく選択リストにしたのは、あとから比べられるようにするためです。自由に書けるほど記述は豊かになりますが、その代わり集計の段階で揃わなくなります。 もうひとつ、フォーマットを配っただけでは良い課題が自然に起票されるわけではない、という指摘がチーム内から出ました。起票の質は、書き手の慣れやそのときの時間の余裕に左右されます。そこで、導入したチームのリファインメントへ一緒に入って伴走しつつ、初稿づくりや一次レビューへAIを組み込む運用も試しています。人の指摘に頼らず一定の水準へ引き上げられれば、書き手の負担も、指摘する側の気疲れも減らせると考えました。 「比べられる状態」ができたことで、他チームの施策や学びを参照しやすくなりました。共通化するのは土台だけで、各サービスの戦略や専門性はそのまま維持しています。 3. 登録した先まで、ユーザーの体験を通して見られるようにする 私たちが担当している人材紹介サービスは、求職者がWEBサイトから登録したあと、キャリアパートナーが求人のご紹介や選考のサポートを行い、入職して働き始めるところまでがひと続きの体験になっています。WEBサイトはその入り口であり、登録は通過点にすぎません。ユーザーにとって本当に大事なのは、納得できる職場と出会えたか、入職して働き続けられているかです。 ところがデータの上では、登録の前と後が分かれていました。WEB側で見えるのは登録までの動きで、その先で何が起きたのかは別の場所にあります。これでは施策の評価が「登録がいくつ増えたか」に寄り、良い出会いにつながったのかどうかは見えません。 そこで取り組んでいるのが、 登録の前後を串刺しにして、ひと続きの体験として分析できる状態をつくること です。これが一本の線でつながると、「登録を増やす」ではなく「良い出会いにつながる登録を増やす」ほうに目標を置き直せます。あわせて、サービスごとに数え方の異なる指標の定義を揃えることも進めています。 この取り組みで大きかったのは、 データ基盤を担当するチームと組んで進められたこと です。同じ時期に近い領域の設計が両側で進んでおり、そのままではつながらないものが2つできるところでした。早い段階で合流し、こちらから叩き台を持ち込む形で、受け持つ範囲とデータの受け渡し方を一緒に決めていきました。 現在は、まず1つのチームで実装を進めているところです。ここが終わった段階で狙いどおりの状態になったかを検証し、他サービスへの横展開を検討します。 1つの基盤を一緒に設計したことで、データ基盤チームとの間に、細かいことでも聞き合える関係ができました。横断で取りにいく価値は、成果物そのものだけではありませんでした。 転機：『TRANSFORMED』の読書会 こうした取り組みを進めていた頃、プロダクト開発に関わる組織が向かう先として、 プロダクトオペレーティングモデルへの転換 という方向性が示されました。その考え方のもとになっているのが、 『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（マーティ・ケーガン 著／横道稔 訳、日本能率協会マネジメントセンター） です。 そこで、人材紹介開発グループでも『TRANSFORMED』の読書会を行いました。 読書会を通じて私たちが受け止めたのは、 エンパワーされたチームは「文脈 × 能力」で成り立つ という考え方です。能力だけを引き上げても、向かう先が共有されていなければ「上手に、けれど違う方向へ進むチーム」になりかねません。逆に言えば、「なぜこの課題を解くのか」が届いて初めて、現場は「何をやらないか」を自分で判断できるようになります。 この観点で自分たちの半年をふりかえると、私たちが手厚く支援していたのは 能力の側 でした。フォーマットを揃える、リファインメントに伴走する、分析の土台を整える。どれも必要なことですが、文脈の側には十分に手が届いていませんでした。 スコープを、より上位レイヤーへ この半年で変わったことのひとつに、入ってくる情報があります。 横断で動くようになったことで、各チームのリーダーやマーケ、データ基盤のチームと話す機会が増えました。それに加えて事業やプロダクトの方針を決める意思決定者とのやりとりの頻度も上がり、これまで自分たちのところまで届いていなかった、より上のレイヤーで何が議論されているのかが見えるようになりました。 両側が見えるようになって、はっきりしてきたことがあります。 戦略は確かに存在している。ただ、それがメンバーの手元に届いて、日々の判断の材料になっているとは言いにくい状態だった ということです。 意思決定者が持っている検討の背景や根拠は、現場には決まった結論の形で届きます。その手前にある「なぜこれを選んだのか」までは共有されにくく、メンバーが自分の言葉で語れるところまでは届きません。 半年の活動を通して見えてきたボトルネックは、ここでした。 上位レイヤーで考えた戦略がメンバーの手元まで適切に降り、メンバー自身で成果へコミットできる体制になっていないこと 。いくら進め方の型を整えても、ここが埋まらないかぎりは近づきません。私たちが最初に置いた「各チームの進め方を支える」というスコープは、このつなぎ目そのものには届いていませんでした。 そこで、イネイブリングチームのスコープをより上位レイヤーへ変えることにしました。「翻訳」の役割を強め、意思決定者との方針すり合わせを密に行いながら、組織にとっての最善を判断して行動する、という立ち位置です。 これまで これから 主に見る層 各チームの進め方・運用 戦略と現場の意思決定のつなぎ目 果たす役割 型と仕組みを整えて伴走する 戦略を翻訳し、現場の意思決定に接続する 意思決定者との関わり 決まった方針を現場に届ける 方針そのものをすり合わせ、組織にとっての最善を判断する 方向を変えたというより、 どのレイヤーに手を入れるかを変えた という感覚に近いです。能力側の支援をやめたわけではなく、まだ誰も手をつけていなかった文脈側を、空白として引き受けることにしました。 「イネイブリングチーム」の定義から離れている点について 前半でご紹介したとおり、私たちのチーム名と出発点は『チームトポロジー』のイネイブリングチームにあります。ただ、スコープを上位レイヤーへ変えたことで、 同書の定義をそのまま当てはめると、実態はかなり違うものになってきています 。 同書のイネイブリングチームは、特定の領域における能力のギャップを埋めることに焦点があり、支援する相手や期間を区切って関わり、役目を終えたら離れていくことが前提とされています。一方で今の私たちは、戦略の翻訳や意思決定者との方針すり合わせ、プロダクトビジョンの言語化、体制の設計といったより上位の層に軸足を移しています。特定の能力を一定期間で引き上げて離れる、という形からは離れ、担い手のいない役割を恒常的に引き受けている状態に近いです。 そのため、本稿を「『チームトポロジー』のイネイブリングチームの実践例」としてお読みいただくと、定義とのずれを感じる部分があるかもしれません。 一方で、同書から受け取った核の部分 — 代わりにやってあげない 、成果は 各チームが自走できるようになったかで測る — は、スコープが変わっても変えていません。名前に実態を合わせにいくのではなく、組織にとって今必要なことに形を合わせた結果として、こうなっています。このこと自体が、この半年の学びの1つでもありました。 今、取り組んでいること プロダクトビジョン・プロダクト戦略を言葉にする 「なぜこの課題を解くのか」という文脈が開発メンバーに届き、各メンバーが根拠を理解した上で意思決定できる状態をつくることを狙っています。個別のサービスやWEBサイトの最適化に視点が閉じないよう、事業全体を1つのプロダクトと捉えるところから始めました。 ただし、実際に着手してみて、進め方そのものを組み替えることにしました。決め手になったのは、ビジョンは書けば届くというものではない、ということでした。どれだけ言葉を磨いても、受け取る側との間に「一緒に事業の成果に責任を持つ」関係ができていなければ、掲げただけで終わってしまいます。 だとすれば、先に必要なのはそちらです。そう考えて、ビジョンの言語化よりもパイロットを先行させることにしました。 パイロットチームで、マーケとの協業の形を探る どこまでを誰が持つのか。その線を抽象的に引こうとすると議論はいくらでも続けられてしまうので、取り組みやすい1チームを選び、 課題を決めるところから成果を見届けるところまでを一緒に一周する パイロットを準備しています。 ここで置いている見立ては、 戦略を言語化して共有し計測するだけでは、「背景をよく理解したうえで、渡されたものを作るチーム」で止まってしまう ということです。関係を変えるには、解く課題を決めるところから一緒にいる必要があります。 そのため、作るものを決める前に、次のようなことを先に置いてから始めるつもりです。 どんな課題を扱い、ユーザーのどんな行動が変われば前進と言えるのか 何を優先するかを、誰がどこまで決めるのか どのタイミングで、何を見て、続ける・変える・やめるを判断するのか ユーザーの実際の声や行動を、どこから確かめにいくのか ふりかえりで見たいのは、次のようなことです。 ユーザーの行動が実際に変わったか それが事業の成果につながると説明できるか それはこの進め方だからこそ出せた結果と言えるか もっとも、どういう形が私たちにとって良い協業なのかは、やってみて分かることのほうが多いはずです。今はその最初の一周を回そうとしているところです。 ふりかえって思うこと 半年やってみて、強く感じていることが3つあります。 1. 横断で動くと、入ってくる情報が変わる 横断で動くことの価値は、チーム間で学びを橋渡しすることだと思って始めました。ただ実際に効いたのは、整えた仕組みや型よりも、 事業の方針がどういう背景で決まっているのかを知れるようになったこと でした。 1つのチームの中にいると、方針は結論の形で受け取ることになります。横断の立場になると、その結論に至る前の議論や判断の材料にも触れる機会が増えます。そうなると、「たぶんこちらのほうが良さそうだ」ではなく「この背景があるから、いまはこちらを取る」と言えるようになる。今の状況で取れる最善を自分たちで考えられるようになったのは、始める前には見えていなかった変化でした。 2. 自分たちのスコープ自体も、検査と適応の対象だった スクラムでいう「検査と適応」は、個々のチームの進め方だけでなく、横断チームの存在意義そのものにも当てはまります。机上で正しい形を決めてから動き出していたら、戦略と現場のつなぎ目がボトルネックだとは特定できなかったはずです。動いたからこそ、手を打つべき場所が見えてきました。 半年でスコープを変えられたのは、仕組みよりもメンバーのマインドによるところが大きいと思っています。一度決めた形に固執せず、今の状態に合う形へ変えていこうとする姿勢があったからこそ、「自分たちのやってきたことは、本当に効くところに当たっているのか」と率直に問い合えました。当初思い描いた形からは変わりましたが、遠回りだったとは考えていません。課題を特定し、そこに手を打てる状態になったこと自体が、この半年の成果です。 3. 横断チームこそ、広げる前に1つ通す 横断で動く立場だと、全チームに同時に手を入れたくなります。ただ、少人数でそれをやると、どこも中途半端になります。 実際にやってみると、課題管理のフォーマットも、データを串刺しにする取り組みも、マーケとの協業もすべて「準備の整った1つ」から始める形になりました。1つ通すと、型が手に入るだけでなく、「これはうまくいった」という実例が残ります。他のチームに広げていく場面で効いてくるのは、正しさの説明よりも、その実例のほうだと思っています。 最後に 最後までご覧いただきありがとうございました。 イネイブリングチームの立ち上げから、スコープを上位レイヤーへ変えるまでの半年をご紹介しました。取り組みはどれもまだ途中ですが、「戦略と現場の間にある翻訳の余白は、誰かが引き受けるべきだ」という手応えを確かに得ています。 引き続き、各チームやマーケの皆さんと一緒に、プロダクトの力で事業の成果に貢献できる組織づくりを進めていきたいと思います。 参考文献 マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター、2021年） マーティ・ケーガン 著／横道稔 訳『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（日本能率協会マネジメントセンター、2024年）

はじめに こんにちは。職種横断ダイレクトリクルーティングサイト「ウェルミージョブ（旧カイゴジョブ）」でQAを担当している林です。 アジャイルな開発チームメンバーの一員として、よりよいQAを目指して日々トライを楽しんでいます。 エス・エム・エスではAIエージェントを積極的に業務へ活用しています。 ウェルミージョブの開発チームではGitHub Copilot、Claude Code、Codex、Devin、Geminiなど、用途にあわせて様々なAIエージェントやAIアシスタントを使っており、その中でも私はDevinというAIエージェントを主にQA業務に活用しています。 私はDevinを Slackのオープンチャンネル で使い、その経験を QAの事例共有会 で発表することで、活用方法を日々ブラッシュアップしています。 今日は、AIエージェントDevinをこっそり使わずオープンに利用することで得られたメリット、さらには職域を超えたDevinの活用方法についてもお話しします！ 0. Who is Devin？ Devinは、自律的にコードの作成・実行・テストまで達成するAIソフトウェアエンジニアです。（※参考： Devin公式ドキュメント ） プロダクトのソースコードを読み込んで調査やドキュメント作成を行ってくれるほか、プルリクエストの作成まで一手に引き受けてくれます。 AIエージェントを導入する際、真っ先に壁となるのが「機密情報やコードが外部に漏れるのでは？」という不安ですよね。その点、Devinは入力情報やソースコードの漏洩対策が徹底されています。オプトアウト設定を行えばデータ学習を停止できるため、情報流出を心配することなく安心して活用できます。 ※参考： Devin公式ドキュメント Devin を改善するために、どのようにデータが利用されますか？ 既定では、サービスの改善および強化を目的として、お客様のデータをモデル学習に利用する場合があります。有料プランをご利用の場合は、Data Controls 設定ページでいつでもオプトアウトできます。 また、個人のPC上で動かすだけでなく、SlackやTeamsなどのチャットツールのスレッドにメンションするだけでチームの会話へシームレスに参加させられる点も特筆すべき特徴です。 1. DevinをSlackのオープンチャンネルで使っています！ ウェルミージョブ開発チームでは、Slackに専用チャンネルを設けて「オープンにDevinを使える環境」を整えています。 このチャンネルには、開発やQAはもちろんデザイナー・インフラ担当・PdM・マーケター・データアナリストといったプロダクトに関わる多様なドメインのメンバーが参加し、それぞれの業務パートナーとして以下のように日々Devinを活用しています。 現行仕様や振る舞いの調査、フロー図やユーザーシナリオの作成 データ抽出用SQLクエリの作成（DBは直接参照せずにソースコードとスキーマ情報をベースにクエリを作成） テストケースやテスト手順書の作成、テストデータスクリプトの作成 障害の原因調査、障害修正プルリクエストの作成 インフラ関連の現状の設定の確認、修正やバージョンアップ対応用のプルリクエストの作成 新しい仕様についての相談、ユーザー要望をコードベースで整理・要約 ユーザー向け説明書の作成、ユーザー問合せを想定したご案内文面の作成 データアナリストが正しくデータを可視化・分析するためにDB情報を起点としたモデル挙動を調査 プロダクト関係者にも広く開かれたオープンな場所でDevinを使って実感した、 3つの大きなメリット をご紹介します。 1)「AIの使い方の知見」がチームに自然と伝播する。失敗も財産になる プロンプト作成やタスク設計に悩むメンバーであっても、オープンチャンネルでのやり取りをウォッチするだけで「適切な依頼の粒度」や「実践的な活用アイデア」を自走して学習できます。 さらに、失敗した際のリカバリー手順までオープンになっている点もポイントです。他メンバーの試行錯誤のプロセスまでも見られることにより、エラーへの抵抗感が薄れ、チーム全体の「Devin利用への心理的ハードル」を大きく下げる結果につながっています。 2)ブラックボックス化を防ぎ、周囲がフォローしあえる Devinとのやりとりはすべてオープンにしているため、Devinがもし見当違いな方向へ進みそうになっても周囲のメンバーがすかさずスレッドでフォローしてくれます。 実際にもらったアドバイスは多岐にわたります。 Devinの調査結果の抜け漏れの指摘 Devinが作成したテストデータスクリプトの不備をフォロー 『こう聞くとQAに役立つかも』といったプロンプトの提案 最近の大きな変化は、QAメンバーがDevinを活用して軽微なバグ修正のプルリクエスト作成を行うようになったことです。 QAとDevinのやりとりを開発エンジニアが温かく見守り、必要に応じてスレッドでフォローしてくれるおかげで、普段コードを書かないQAでも軽やかかつ安全にバグ修正ができています。 もちろん助けてもらうばかりではなく、私自身も他メンバーのスレッドに入ってハルシネーションを指摘したりよりよいプロンプトを提案するなど、自分の強みを活かして貢献しています。 3)フルリモートでも、周囲のメンバーの困り事や興味関心がわかる 現在私たちはフルリモートで業務を行っています。朝会・夕会や1on1などでコミュニケーションの機会は多いものの「廊下で会ったついでに軽くおしゃべりする」ような偶発的なコミュニケーションは生まれにくいのが現状です。 そんな中、Slackに流れるDevinへのプロンプトが予期せぬ架け橋になっています。他メンバーのプロンプトから「今どんな困り事に直面しているか」「何に興味があるのか」が自然と見えてくるのです。 そこから技術的な情報交換や課題解決に繋がるのはもちろん、興味関心から会話が広がったり、困っている仲間を労われたりと、メンバー間の心理的距離がより縮まる良いきっかけになっています。 また、Slackというオープンな場にDevinを招き入れた効果は、マーケターやPdMのコメントにも色濃く表れています。 マーケターの声: 「些細な疑問でもDevinに気軽に問いかけられるため、仕事のスピード感や精度、プロダクトそのものへの理解が大きく深まった」 「たまにスレッドの中でエンジニアの方がコメントしてくれたり、リアクションしてくれるのもSlackならではのポイント」 PdMの声: 「Devinは仕様特化エージェントと思っていて、コミュニケーションの中心であるSlackでやり取りできるというのは、活用や運用するという上では非常に相性がいい」 「ちょっとしたアイデアや壁打ちを常に開いてるSlackで思いついたら会話できるという体験は、イノベーションを生む」 気軽に使えるSlackでDevinをオープン運用する価値は、まさに想像以上です。 2. 社内コミュニティ「AI4QA事例共有会」で体験談を発表しました！ カイポケQA中村さんのテックブログ『QAエンジニアがAI活用事例を「全力でパクる」ための会をはじめました』でご紹介の通り、弊社ではプロダクト横断の社内QAコミュニティにおいて「AI4QA事例共有会」が開催されていました。 tech.bm-sms.co.jp 私は「Devinをオープンに活用する価値」を他のQAメンバーにも知ってもらいたいと強く思い、今まで2回にわたり活用事例を発表しました。 この発表を通じて、私は知見を広めるだけでなく、自分自身も 2つの大きなメリット を得ることができました。 1)QA視点のフィードバックを得て、活用方法をブラッシュアップできた 共有会では、1回目に『Devinの紹介とGOODな体験談』、2回目に『失敗談と新たなTRY』をテーマに発表しました。 視聴していたQAメンバーから現場ならではのフィードバックを受け取れたことは大きな収穫でした。作業に没頭していると見落としがちな視点や、次なる挑戦へのヒントを数多く獲得でき、フィードバックはすぐに取り入れて自身のDevin活用方法を即座にアップデートしました。 「コードを見る特性上、Devinのテスト観点はホワイトボックステストに偏りがちかも？」 💡言われてみれば確かにそう。「コード構造ベースではなく、ユーザー操作の視点でテスト観点を出して」と明示的に指示してみよう！ 「Devinが提案したテスト観点の中で『この発想はなかった！』というものはどれくらいある？」 💡Devinと自分の得意・不得意を常に意識し、お互いの弱点を相互補完していかなきゃ！ 「Devinに機能仕様書を作らせたり、テスト設計のレビューをやってもらったりできる？」 💡「そのうちやろう」と後回しにしていたレビュータスク。さっそく実践に移す！ 「Devinって使えば使うほど自動で賢くなるの？」 💡調べてみるとセッションは独立しており、単に会話を重ねるだけでは学習されないと判明。調査の過程でナレッジ機能や「DeepWiki」に出会ったので、こちらを活用してみよう！ 2)発表する前提でプロンプトを丁寧に言語化したら、いろいろな人が読みやすくなった AIエージェント利用時はどうしても「どう書けば思い通りの結果が得られるか」という目先のテクニックに意識が向きがちです。 しかし私は「共有会でDevinとのやりとりを紹介する」という前提を持つようになってから、プロンプトの記述を丁寧に言語化し、指示の背景やコンテキストまでしっかり補足する癖がつきました。 その結果、周囲のメンバーにとって理解しやすいだけでなく、Devinにとっても迷いのない高精度な指示が出せるようになりました。さらに、後から自分の過去プロンプトを見返す際も意図がひと目で分かり、次なるプロンプト改善の土台になるなど、巡り巡って自分自身の財産になっています。 番外編：開発・QAだけじゃない！職域を超えたDevinの活用方法 ウェルミージョブにおけるDevinの活用は、単なる『作業の効率化』だけに留まりません。開発・QA・デザイナー・PdM・マーケター・データアナリスト・社内システム管理者など職種の壁を越えたコラボレーションを生み、プロダクト開発全体の動きを加速させるポテンシャルを秘めています。ここからは、魅力的なDevinの活用事例を3つご紹介します。 1)DeepWiki Devinには、リポジトリ全体のアーキテクチャ図やドキュメント、ソースコードへのリンクを自動生成してくれる「DeepWiki」という機能があります。（※参考： Devin公式ドキュメント ） ドキュメントのメンテナンスは不要で、Wikiの再生成を実行するだけでDevinが最新のコードを読み解いて「システムの最新説明書」を自動で立ち上げてくれます。設定で日本語化も可能です。 AIがコードから読み取った説明書なので正式な仕様書そのものではありませんが、システム・機能の全体像やインフラ周りの情報を短時間でつかむ分には十分です。開発・QAだけでなく、プロダクトや機能をざっくり知りたいPdMなどのメンバーにとっても大いに役立っています。 2)リリースノート Devinに過去1週間で本番デプロイされたプルリクエストを抽出してもらい、その内容を要約してもらうことで『自動リリースノート』を生成させています。 単にプルリクエストを収集するだけでなく、要約のプロンプトを「コードを読まない非エンジニア向け」にチューニングしているのがポイントです。開発者以外のステークホルダーにとっても「何がどう変わったのか」が直感的に伝わる情報に整うため、プロダクトに関わる人へ幅広く重宝されるアウトプットになります。 3)社内ユーザー向けの仕様質問アプリ Devinの優れた『コード・仕様の調査能力』に目をつけたPdMが、その力を全社で還元すべく、Devinを用いた『仕様質問アプリ』を内製し社内リリースしてくれました。 Slack上でも仕様調査は可能でしたが、あえて「質問専用のインターフェース」を用意して用途を限定。これにより、Slackの操作に不慣れなメンバーでも直感的に使いこなせるようになり、以下のような大きな成果と可能性が生まれています。 双方ハッピーな体験：質問者はエンジニアの手を止めずに「即時回答」が得られ、エンジニア側は回答対応の割り込み工数を削減 ナレッジ化によるコスト削減：FAQとして過去の回答を蓄積・再利用することで、重複する質問への対応コストをカット プロダクト改善への還元：寄せられた質問ログを分析し、ユーザーが躓きやすいポイントを今後のプロダクト改善へと繋げていく予定 まとめ：オープン活用とアウトプットが生むナレッジの循環 今回ご紹介したように、Devinをオープンな場で運用・共有することには多くのメリットがあります。 チームへの波及効果: プロンプトや試行錯誤が可視化され、利用ハードルの低下と相互フォローの文化が醸成される 自身への還元: 共有を前提とした言語化により、プロンプト精度向上とナレッジの資産化が実現する 組織への広がり: 開発・QAにとどまらず、PdMやステークホルダー巻き込み型の活用へと発展する セキュリティ対策を整えた上で「みんなの見える場所でAIを使う」環境を作ることが、個人と組織双方のプロダクト開発能力を加速させる強力な基盤になります。 本記事が、みなさまのチームにおけるAIエージェント活用のヒントとなれば幸いです。 告知！ ウェルミージョブの開発をリードする @moro が、「 Kaigi on Rails 2026 」に登壇いたします。トークのタイトルは「 Event is what happens 」！過去3回のKaigi on Railsでも好評を博した@moroの講演にどうぞご期待ください！ 昨年までの発表 Simplicity on Rails - RDB, REST and Ruby / MOROHASHI Kyosuke - Kaigi on Rails 2023 Identifying User Identity / MOROHASHI Kyosuke - Kaigi on Rails 2024 Kaigi on Rails 2025 Keynote: dynamic!

はじめに こんにちは。カイポケコネクトの開発推進チームでエンジニアをしている @_kimuson です。 普段は生産性向上のための基盤構築などをフロントエンド領域中心に行っています。 弊社では中途入社が中心だった状況から新卒採用にトライしており、私自身も新卒の面接に出たり、インターンの学生を受け入れ、一緒に開発を進めたりといった機会がありました。 彼らの考えを聞いたり、インターン生の相談に乗ったりする中で感じたのが、生成AIが当たり前に存在する時代にキャリアを始めるエンジニアは、以前とは異なる難しさに直面しているということです。これは誰か個人の資質やふるまいの話ではなく、環境が変わったことで構造的に生まれやすくなっている傾向の話で、程度の差こそあれ我々既存のエンジニアにも同じことが起きていると思っています。 エンジニア本人も勿論、受け入れる側の難しさも非常に高くなっていると感じており、この問題について考えてみようと思います。 生成AI時代に、キャリア初期の学習が難しくなる理由 生成AIはエンジニアの生産性を大きく向上させてくれる一方、エンジニアの学習機会を奪いやすいツールでもあると思っています 一般にもよく言われている話もあるかなと思いつつ、構造を整理してみようと思います この記事では便宜上、新しくエンジニアとしてのキャリアを開始する人のことを「新人」と表記します。 質問するまでの摩擦が、思考を訓練していた 以前は、分からないことや困ったことがあった際には人間のメンターに質問をするという前提がありました。 メンターという人間の時間を借りて質問をすることになるので、メンター側からの要望あるいはメンティー側の気遣いの両輪から「調べてわかることは自分で調べ、わからないところはどこがわからないか整理して質問する」という引力が自然に発生していたと思います。組織によっては悩んでいることをIssue Up出来ずにずっと悩んでしまう問題を解消したいこととセットで、「15分ルール」などをルールとして敷くケースもあったと思います。 そしてこの質問のための準備段階で自然と 何を実現したいのか 現在は何が起きているのか 期待していた結果は何か どの時点から予想と異なったのか すでに何を試したのか 自分は何を分かっていないのか といった点を言葉にして整理をします。結果として物事を構造化して整理する・理解するという能力を育てていた側面があったと思っています。 実際、質問内容をまとめていたら情報が整理できて答えが分かってしまった！という話はよく聞きますし、私も経験があります。 ところが現代は生成AIという「手間を取らせること」をまったく気遣わなくて良い専属のメンターが登場しました。 相談がカジュアルにできてかつ人の時間も取らないということで良い面ももちろんありますが 時間を取らせること 質問の仕方（調べればわかるじゃん？とか結局なにが聞きたいの？とか） といったことに一切気を使わなくて良い相談相手ができてしまったことになります。論点が曖昧なまま質問してもAIがよしなに補ってくれますし、前提や知識が不足していれば調査して補完してくれます。 結果、（もちろん個々人の使い方に差異はありますが）、新人から「質問前に自分で調べる・調べた情報を整理/言語化する」というプロセスが奪われやすくなっています。 こういった物事の構造化・言語化・整理といったスキルは、エンジニアリングで課題を解決していくための根幹となる重要な能力だと思っていますが、これを培う場が1つ失われてしまっていると考えられます。 「分かった気にさせてしまう」AIが狂わすメタ認知 問題を自分で整理しなくても回答へ到達できることには、もう1つ学習に関する難しさがあります。 生成AIは、わからないことに対して「答え」を教えてしまうだけでなく、利用者に「分かった気にさせる」ことが本当に上手です。 適切に情報を取捨選択して分かりやすく整理して並べてくれる 言葉の意味や、論理の繋がりで分からなかったところがあれば気兼ねなく聞くことができ、自分に最適化された補足を提示してくれる 具体例や比較表、場合によってはVisual化して説明をしてもらえる 一方、LLMの説明と質疑を通して分かった気になっている状態と、実際に使える（正しさを適切に判断したり、注意すべき観点を見つけられる）状態とでは乖離があります。 自分がすでに「できている」と思っている対象を改めて調べたり、手を動かして解像度を高める必要性は感じづらいでしょう。 にも関わらずアウトプット・成果は出ていくので「能力が適切に拡張されていること」と「成果が出ていること」が乖離しやすいと感じます。 AI に任せて良い範囲を見つけることの難しさ 生成AIを使うことで学習機会を奪われるのであれば、素朴に対策を考えると生成AIの利用を適切に制限するのが良いという発想になります。 単純作業は生成AIを使いたいとして、「自分がイチからやってできないことは学習を目的に生成Agentの利用を制限する」が一見良さそうに思えます。 しかし問題は、何を生成AIへ任せて/なにを自力でやるべきなのかを、本人が判断しなければならないことです。 1つの開発タスクには、複数の工程があります。 チケットや要求を理解する 既存の仕様とコードを調べる 問題を分解する 実装方針を決める コードを書く 動作を確認する 問題があればデバッグする レビューを受けて修正する こういった工程を包括的にAgentに任せている場合、先ほど説明した「分かった気にさせてくれるAI」の特性と相まってどの工程はできていて、どの工程はできていないのかをきちんと認知することが難しいでしょう。 つまり「AIに任せて良い範囲」を決めるには、その前提として自分の現在地を正確に把握できている必要があります。ところが前述のとおり、その現在地の把握こそが生成AIによって最も狂わされやすく、非常に厄介です。 学習機会の喪失にどう向き合うか ここまでAgent活用による弊害として学習機会の減少があるという話を構造的に整理してきました。 単純にコードを書く機会が減る（かつその経験も少ない）という要素に加えて 気を使わない相談役が言語化能力の成長機会を奪う 学習のために重要な「できていないこと」のメタ認知が狂わされやすい という要素を説明しました。 ここからはこれらを踏まえつつ、私も明確な答えは持っていないのですがどうやって受け入れをしてくのが良いのかを考えてみようと思います 生産性と学習機会はトレードオフであることを認識する まずちゃんと認識すべき重要な要素として「生産性と学習機会はトレードオフである」ということがあると思います t-wadaさんの有名なスライド、「質とスピード」では、メンバーの成長や学習機会がスピードとのトレードオフになっているのではないか、ということが示唆されています 生成AIは色々な目的で利用できますが、特にエンジニアリングの現場でこれだけ活用が進められているのは既存のエンジニアのコーディング業務を移譲して生産性をかなり高められるということが最も大きいと思います。 一方、速度（生産性）が学習機会とトレードオフになるのであれば、生成AIをゴリゴリ使って生産性をN倍にしよう！という営みの裏には学習機会の喪失がセットになっているとも考えられます。 もちろん定型的でその業務からもう学習することはほぼない工程というのは存在し、そのエンジニアの経験値やAIへ移譲する業務に応じて失っている学習機会の大小は明確にあると思います。そして特に新人の場合は様々な工程、それこそ開発ツールの調査1つとっても学びになる要素が多分に含まれており、非常に多くの学習機会が失われやすいのだと思います。 生成AI登場以後で、「自分ができないことはできない」という当たり前の前提が崩れ、自分ができないこともそれっぽいアウトプットが出せるようになった結果、このトレードオフ関係がより明確になったと感じています。 「生産性を上げる」というのは一般にポジティブに捉えられると思いますが、学習とのトレードオフであり、「学習をしたいなら生産性を敢えて捨てる」ということを文化として受容していくことも大事になるのではないかなと思います。 新人の教育では特にそうですし、既存のエンジニアでも新しい技術領域へのチャレンジや、職能を跨ぐ（Ex. プロダクト方向・デザイン、 ...etc）チャレンジにおいても同じことが言えると思います。 生産性をあげるためではなく、学習を支援するための AI活用 ここまでの話から結論を出すと、生成AIを使う=気づかないうちに学習機会を奪われるかつ、どこで奪われているかの判断も難しいので学習期間では一律で生成AI自体を禁止する、ということになります。 これ自体は一定ワークすると思いますし、実際弊チームでもこういった課題感がレトロスペクティブで共有され、実際に一定期間生成AIを禁止するといったことも試しています。 実際にこの取り組みをしていたインターン生の佐藤さんが、AI禁止で開発に取り組んだ半年間について記事を書いています。受け入れる側ではなくインターン生側の視点で書かれているので、こちらも読んでいただけると嬉しいです。 とはいえ、せっかく生成AIという便利なツールがあるのに一律禁止して単純作業もすべて自分で行い、原始的な学習プロセスを使うのもベターではあるがベストではないんだろうなと思っており、「生産性をあげることではなく学習を支援すること」を目的に生成AIやAgentを活用できると良いのではないかなと思っています。 grilling skill 学習を支援するAIの利用方法として、私が開発の計画段階でよく利用しているgrillingというスキルのアプローチが教育と相性が良いと感じているので紹介させてください。 grillingはおもにAgentを使った開発における「実装計画を立てる」フェーズで利用されるスキルです。 種々のAgentツールに組み込まれているPlan Modeの親戚だと思ってください。 両者の違いですが、Plan ModeはAgentが立てた実装計画を人間が承認する構造なのに対して、grillingではAgentがInterviewerになり、人間側が考えている実装方針などとの共通理解が得られるまで質問を繰り返す構造になっています。 私がgrillingを気に入っているのは、計画を立てることの主体を生成AIから人間側に取り戻した点です。 結局計画で大事なのは「自分が求めているものをいかに齟齬無くAIに伝えるか」なので、私の中ではこの形がベストだなと思っています。 そしてこの「主体を人間側に取り戻す」grillingのアプローチが学習に目的を置いたAI利用にもかなり効くんじゃないかなと思っています。 grillingの場合は主体が人間側になるので、AIが提示したそれっぽい方針をなんとなくの理解で進めることができません。「こういうことをやりたい」と伝えた後に タスクのスコープはどこからどこまでですか？別の箇所にも影響しますよね、そこはどうしますか？ やり方としてA/B/Cがありますよね、どの方針でやりますか？ Aで実施する場合、α が問題になりますよね。これはどうやって対策しますか？ といったように様々な方向から、曖昧になっている箇所をAgentから質疑されます。これにちゃんと自分で考えて答えるようにしていくと 様々な観点が曖昧なまま成果物だけが出てくることを避けられる 判断自体の是非は置いておいて、Agentから提示された自分の中になかった観点においてもすべて自分で判断をしていくことになる 成功したらそれで良いですし、特に失敗（人間のReviewプロセスで棄却される、Releaseしてみてから問題に気づく）をしたときにも、自己判断をしたうえでのフィードバックになるので学びに繋がりやすい という良い学習サイクルを効果的に回しやすいのではないかなと思っています。 Coaching をする AGENTS.md / Skill を用意する grilling自体はあくまで認識を齟齬無く伝えるためのスキルで教育にも活きやすいと思うものの、教育用途に最適化されているわけではありません。例えば意思決定自体は委ねられますが想定回答を出すように指示されているので、教育目的なら想定回答もない方が良いのでは？といった具合です。 なので、この辺りのアプローチを参考に教育のために指向性を絞るための指示をAgentに与えると良いかなと思っています。 あくまで一例ですが例えばAGENTS.mdや専用のスキルに 利用者は学習フェーズであり、作業を請け負うのではなく利用者へのコーチングに徹すること 答えやその示唆になる提案を禁止し、代わりにInterviewを行うことで、利用者の能力拡張を阻害せずに学習を支援する 利用者が発見できていない論点の提示を行うことで学習を支援するが、その論点において「どうすべきか」は提示しない 学習機会にならない単純作業（=工程が複雑でなく、言語化されていない判断を必要とするプロセスも存在しないほど明確）は、本質的な内容に時間を使うため請け負ってSubagentに実行させて良い。ただし、この単純作業かの判断は利用者ではなくAgentが判断に責任を持つ ※ ここの判断基準については受け入れ側がある程度言語化しておけるとなお良い といった内容を記載しておき、Agentの動きを制限した上で利用してもらうことで 生成AIによる学習機会の喪失を最小限にする 生成AIによる学習の支援を行い効果的に能力拡張を行う 単純作業は、Agent側の判断により一部実施することで非効率な時間は最小化する というようなことができるのではないかなと思っています。 上記の例はあくまで1案でしかないので、むしろAI Nativeな世代の側からこういった問題点を解消した良いアプローチが出てくると良いなと思ったりしています 終わりに 生成AI時代にキャリアを始めるエンジニアの学習の難しさと、それを受けてどういう風にエンジニア側/受け入れ側が学習をしていけると良いのかについて考えてみました。 正直結論や成果が出ていると言うより課題感の共有がメインで、こういうアプローチもあるんだなくらいで受け取ってもらえると幸いです。願わくば世間的にもこういった生成AI時代を前提にした受け入れのプラクティスについて固まってくると嬉しいなと思っています。 また、今回は主に新卒だったり新しくキャリアを開始するエンジニアをスコープに書きました。ただ、こういった話はわれわれ既存のエンジニアの写し鏡でもあると思っていて、より影響が大きいのは彼らというだけで、同じ問題を持っているんだと思っています。自分にできないことを移譲しているつもりはなくても暗黙的にそういう要素はあり、学習が阻害されている側面は少なからずありそこに向き合っていく必要があるんだろうなと感じています。 生産性を追い求めた結果、課題を解くエンジニアリングの能力自体が衰えてしまっては本末転倒なので 学ぶことのない（少ない）状態になっている作業をAgentに寄せていって速度を高める・他の時間に当てやすくする 学ぶことの多い・それ自体がトレーニングになる課題解決の本質に集中する・割く時間を増やす この2軸のバランスを両立させながら、Agentと付き合っていけると良いなと思っています。

はじめに こんにちは、エス・エム・エスでエンジニアインターンをしている、佐藤墾です。 半年間インターンをして、この会社についてわかったこと、感じたことを書き残します。 エス・エム・エスに興味を持っているけど、どういう組織かイメージがわかない。そんな方に向けて、この会社が大切にしていること、何を重要視しているかをインターン生の目線で書いてみます。あくまで僕のチームでの話ですが、雰囲気が伝われば嬉しいです。 そもそも私がいたチームは？ 私はカイポケコネクトの開発推進チームに参加しました。カイポケコネクトは介護/障害福祉事業者向けの経営支援サービスで、開発推進はカイポケコネクトの開発基盤やツール整備を担当するチームです。 そこで私はツールの導入提案や不要なコードの整理など、開発体験の改善に関わる仕事をしていました。 働き方について 大学の研究と両立する必要があったので、融通のきくシフトで勤務していました。 私は地方に住んでいたので基本はフルリモートでした。出社しても社員さんもリモートなので人が集まることは少ないですが、もちろん呼んだら来てくれます。 受け入れ体制について チームではレトロスペクティブで振り返りを行っていましたが、自分から気軽に相談するのがまだ得意ではありませんでした。フルリモートだと特にそうで、話しかければ答えてくれる環境ではあるものの、オフィスなら「ちょっといいですか」と相手の様子を見て声をかけられるのに対して、リモートだと相手の状態がわかりません。メンションすると通知が飛ぶので集中を削いでしまいそうで申し訳なく感じたり、返信がいつ来るかわからなかったり。これは自分がリモートでの立ち回りに慣れていなかったのもあると思います。 そこでメンターと週1回の1on1を設けてもらいました。決まった時間に必ず話せる場ができたので、仕事がかなり進めやすくなりました。他のチームでも雑談する時間が専用で設けられていたり、コミュニケーションに対するいろいろな取り組みがありました。 チームの文化 導入したいツールなどはバンバン提案できる環境です。実際に自分も、環境構築が少し複雑で対応に手間がかかっていたので、既存のツールと組み合わせて簡単にできるようにしたいと提案しました。 結局、費用対効果や保守運用の面から見送りにはなりました。ただ、自分の提案に親身に寄り添ってくれて、実際に運用する工程など自分がイメージできていないところの指摘ももらい、この提案に向き合ってくれました。 「便利になるから入れよう」だけでは通らない。それが組織のために、ユーザーのためになっているのかをしっかり考えるチームでした。 また、このチームはインターン生の成長に対して本気で向き合ってくれました。成果を早く出すことよりも、1つ1つのタスクを通じてしっかり学んでほしいという姿勢がありました。その具体的な話は次のセクションで書きます。 自分の成長と変化 プロジェクトに慣れるまで 初めはプロジェクトに慣れるためにも小さな修正から始めました。学生から見るととても大きなリポジトリなので、何がどうなってるのかわかりませんでした。AIを用いてインプットして構造を掴むところから始めました。その後少しずつ慣れていき、いくつかのチケットをこなしていきました。 AIを禁止にしてみた話 インターンを始めた頃は少しでも多く成果を出すために、タスクを並列で回して効率を求めていました。 でもチームから求められていたのはそうではありませんでした。AIが出せるアウトプットのためでなく、自分自身の成長に投資したいのだと。タスクを終わらせることがゴールでなく、そのタスクを通じて学び、今後より大きな課題に対応できる実力をつけてほしいという期待がありました。 色々取り組んできましたが、成果を出すべきと焦りすぎて学習へのリソースを割けていませんでした。フィードバックとして、1つ1つのタスクにより時間をかけて良いから深く理解してみることを提案されました。 そこで実施することになったのが、AIを禁止して開発することでした。自分はこれまで常にAIを使って開発を回してきました。アウトプット自体は出ていてももっと細部まで見る必要があったことを指摘され、一度立ち止まって進めることにしました。 AIを使っていると自然言語でやり取りするので、コード自体をぼんやりとしか見ていませんでした。雰囲気はわかるけど、見るべき細部が見えていない状態です。 でもAIをやめたら、構造体を1つずつ見て繋げるという理解の仕方に変わりました。システムでは多数の関数や変数が複雑に絡み合っていて、境界線がしっかりしているものです。それを自然言語で曖昧にぼかして理解していたから、理解の解像度が低かったのだとわかりました。別に全てを理解する必要はありませんが、輪郭はしっかり見えていないとそれぞれのつながりや作用するものを見つけることができません。 そして仕事の進め方も変わりました。AIを使っていると「〜という方針で実装しますか？」というように結論を早く作ってくれて、承認して速攻で作る、みたいなことはないでしょうか。これをやってしまうと、本当は考えるべきことがたくさんあるのに、検討しないままそれっぽく進めることができてしまいます。 実際にやめてメモに書き出すようにして開発し始めてから、考慮すべきことがたくさんあることを改めて認識しました。今まで気づかないうちに考慮漏れをたくさんしていたんだと思います。たくさんの問題がある中、1on1で相談しながら考えるべき問題と順序を整理しました。そうすることで物事を確実に一歩ずつ進められるようになりました。 いくらAIが書いても責任は自分にあります。AIのスピードに振り回されて自分自身が責任を持てない状況になってしまっては本末転倒です。 だからこそ、AIを活用するのは前提として、その上で自分がどう動いているのか、どういう構造なのかをしっかり理解しておくことが重要だと気づきました。AIをやめたことでその輪郭が見えるようになり、この状態になって初めて責任を持てるようになり、PRも出せるようになったんだと自覚しました。 なぜ、なに、どうやって チケットをもらったときに何が目的かわからない状態では、正しいPRを出せないことを改めて自覚しました。今まではなんとなくで理解して、すぐ「何を作るか」に意識が向いていました。結果、実現しても社員の方から「いや、それじゃなくて」という手戻りが起きていました。 チケットの段階では「何をする」が細部まで決まっていないことも多いです。だからこそ、その背景にある「なぜ」を理解しないと、適切な「何を」を自分で組み立てられないことを痛感しました。 自分は今までの経験で「何を作るか」をすり合わせる大切さを学びました。完全な個人開発ならこれは全て自分の中に答えがあるから必要ありません。しかしハッカソンやインターンで、「何を」を揃えないと正しいものが作れないと実感しました。 今回のエス・エム・エスのインターンでは、そこに加えて「なぜ」が入ってきました。物事の背景や相手の立場に立って初めて、本当に欲しいものがなんなのかを考えることができました。 今までは何かを作れる、Howを実現できるエンジニアが優秀なんだと思っていました。しかしそれだけでは足りず、そこからWhyを理解し適切なWhatを返せる、ここまでできて本当に優秀なエンジニアなんだと学びました。 特にAIの進歩でHowの部分はかなり強力なサポートを得られるようになりました。しかし、まだWhyやWhatをきっちり汲み取ることはAIには難しいと考えています。それを的確に言語化できる人はAIを組み合わせることで、より強力なバフを得られるのだろうと思います。 ただし、全員がそれをできるとは限りません。そこで自分たちエンジニアが正しくWhyを理解し、Whatを組み立てることが今後より重要になってくるのではと感じました。 導入だけでなく運用まで考える 先ほどチームの文化として紹介したツール提案の話ですが、自分自身にとっても大きな学びでした。 自分はここで、導入して便利になる以外にも組織でどう運用するかなど、保守の部分への意識が芽生えました。導入するときにどうやって継続的に負担を減らしつつも効果を出すのかを考える癖がつきました。 半年間のインターンを振り返って エス・エム・エスでの半年間はとても濃い時間で、とても学びが多かったです。何より会社として学習へのコストを惜しまず、成長を喜んでくれる組織でした。 1on1やチームでの振り返りなど適切なレビューをもらえて、新たな気づきや観点がかなり増えたと感じています。 ただ、基本的に受け身ではその気づきを増やすことはできません。手段は人それぞれですが、環境は整っているので自ら動いてその環境の恩恵を受けられるよう、さまざまな気づきが得られるような立ち回りをしてほしいと思います。 そういうカルチャーだったと、半年間いて感じました。 興味を持ってくださった方へ このレポートを読んで、少しでもエス・エム・エスが気になっている方の背中を押せたら幸いです。まずは気軽に応募やカジュアル面談から、私の感じた雰囲気を実際に感じてもらえたらと思います。

こんにちは、エス・エム・エスでカイポケの報酬算定開発を担当しているエンジニアの宮坂です。 以前、カイポケリニューアルに向けた介護報酬算定ロジックの再実装について紹介しました。 この算定ロジックを組み込み、事業者が提供した介護サービスの内容をもとに、介護保険制度のルールに沿って金額を計算するのが報酬算定エンジンです。以前の記事では、難解な算定ロジックと向き合うための取り組みとして、専門家によるテストケースの作成やテスト実行の自動化について触れました。 この記事ではその続編として、QA観点のテストケースを算定結果のテストとしてどのように整備していったのかを紹介します。特にエンジニアだけで完結しない複雑なドメインにおいて、QA担当者や専門的な知識を持つ人の知見を継続的に実行できるテストとしてどう活かしていくか、という観点で書いていきます。 報酬算定エンジンの開発で不安だったこと 報酬算定エンジンの開発で最も不安だったのは、複雑で多くのルールを持つ介護報酬算定の正確性を、継続的に担保できるかという点でした。介護報酬算定には多くの条件や例外があり、制度の理解そのものが簡単ではありません。正しく制度を理解し、それを計算処理として実装し、さらにその結果が正しいことを確認する必要があります。 また、報酬算定エンジンは少しずつ機能を追加しながら開発を進めていました。その過程では、新しい機能の実装だけでなく、既存コードの修正も発生します。そのときに怖いのは、以前実装した計算が意図せず壊れてしまう、いわゆるデグレードです。デグレードの検知が遅れると、原因調査や修正に時間がかかります。そうなると、本来進めたい新規実装に使える時間も減ってしまいます。 なぜ QA 観点の確認を自動化したかったのか ここでいうQA観点の確認とは、報酬算定エンジンの内部でどの処理が呼ばれたかではなく、「この条件を入力したとき、期待通りの算定結果が得られるか」を確かめることです。 計算結果が壊れていないことは、手動のテストでも確認できます。しかし、手動のテストは人手がかかるため、実行できるタイミングがどうしても限られます。たとえば、大きな機能を実装したあとにまとめて確認するような形になりがちです。その場合、問題が見つかったときにはすでに変更範囲が広くなっており、どの変更が原因なのかを特定するのに時間がかかります。 なので、もっと小さく実装し、そのたびにテストを実行して、早い段階で不具合を見つけられる状態にしたいと考えていました。QA観点の確認を自動化することで、そのタイミングを大きな節目だけに限定せず、日々の開発の中で繰り返し実行できるようにすることを目指しました。 なぜ算定結果のテストとして実装したのか 個々の計算ロジックが正しいだけでは不十分です。それらが組み合わさった結果として、報酬算定エンジンへの入力から期待通りの出力を得られることが重要です。そのため、このテストでは内部のクラスや関数を直接呼び出すのではなく、報酬算定エンジンへの入力から出力までを検証対象にしました。 技術的には、報酬算定エンジンに対する入力から出力までを確認する結合テストです。ただしこの記事では、テストの分類よりも「何を確認するテストなのか」が伝わるように、算定結果のテストと呼ぶことにします。 この形にしたもうひとつの理由は、リファクタリングしやすい状態を作りたかったためです。報酬算定エンジンは新規に開発している最中のものでもありました。実装を進める中で新たな事実が分かり、それに合わせて設計や実装を大きく見直したくなる場面があります。そのようなときに、内部実装の細部に強く依存したテストだけでは、大きなリファクタリングを進めづらくなります。個々の関数やクラスを確認する単体テストも重要ですが、内部構造を見直すたびに多くのテストを書き換える状態にはしたくありませんでした。 入力と出力という外側の振る舞いを算定結果のテストで守っておけば、内部実装を変更しても、報酬算定エンジンとしての振る舞いが変わっていないことを確認できます。算定結果のテストは、正しさを確認するためだけでなく、リファクタリングしながら前に進むための足場でもありました。 専門知識をテストケースに落とし込むまでの流れ テストケース自体はQA担当者が作成しています。ただし、QA担当者だけが制度を読み解いてテストケースを作るわけではありません。まずはエンジニア、QA、POなどの関係者全員で制度を理解するところから始めます。 介護報酬算定の制度は複雑なため、制度の文章をそのまま実装やテストに落とし込むことは難しいです。そのため、まず制度の内容を読み解き、計算処理としてどのように表現できるかを整理します。その過程で、処理の流れや条件分岐を図に起こし、チーム全体で認識を合わせます。 その共通理解をもとに、エンジニアは実装を進め、QA担当者はテストケースを作成します。同じ理解から実装とテストケース作成が分岐することで、エンジニアとQAが別々の前提で作業してしまうことを避けられます。 流れとしては、以下のような形です。 QA 担当者が扱いやすい形式にする 算定結果のテストの仕組みを作るうえで意識したのは、QA担当者がテストケースを作成しやすい形にすることでした。QA担当者は制度や業務観点には詳しい一方で、必ずしも開発している報酬算定エンジンの技術スタックに精通しているとは限りません。そのため、テストケースをコードで書く形にしてしまうと、テストケースを追加・修正するたびにエンジニアの手を介する必要が出てしまいます。 そこで、テストケースはGoogleスプレッドシートで作成してもらう形にしました。Googleスプレッドシートであれば、QA担当者が普段の業務の延長で扱いやすく、報酬算定エンジンの内部実装やテストフレームワークを詳しく知らなくてもテストケースを作成できます。 また、スプレッドシートの形式は、介護保険の実務で使われるサービス提供票別表や、その他様式2などの様式を参考にして設計しました。これは、専門知識を持っている人がテストケースを直感的に理解できるようにするためです。機械的に扱いやすい形式だけを優先すると、テストケースを作成する人にとって読みにくくなってしまいます。エンジニアにとって書きやすい形式ではなく、テストケースを作る人にとって扱いやすい形式を入口にすることを重視しました。 作成されたテストケースはCSVとしてエクスポートし、テスト実行時に読み込んで報酬算定エンジンへの入力に変換します。この変換処理自体は地道な実装になりましたが、QA担当者が扱う入口をシンプルに保つことを優先しました。 CI でスプレッドシートからテスト実行までつなぐ 一方で、Googleスプレッドシートで作成したテストケースを、毎回手作業でCSVにエクスポートする運用にはしたくありませんでした。手動エクスポートが必要になると、実行前のひと手間が増えます。また、エクスポート漏れや古いCSVを使ってしまう可能性もあります。 そこでGitHub Actions上で、対象のスプレッドシートをCSVとしてエクスポートし、そのCSVをGitにコミットしたうえで算定結果のテストを実行する仕組みにしました。このワークフローはworkflow_dispatchによる手動実行にしており、QA担当者自身が任意のタイミングで実行できます。これにより、QA担当者がテストケースを作成したタイミングを起点に、最新のテストケースで算定結果のテストを実行できるようになりました。 流れとしては以下のようになります。 QA担当者がテストケースを作成し、自分で算定結果のテストを実行できるところまでを仕組みにしました。これにより、QA観点の確認をエンジニアだけに閉じない形にできました。 導入して良かったこと 導入して特に良かったのは、QA担当者の知見を継続的に使える資産にできたことです。報酬算定エンジンでは、QA担当者が作成したテストケースを蓄積しています。これにより、現在の仕様だけでなく、過去の制度に基づく計算もテストとして残せるようになりました。 介護報酬算定では、報酬改定によって計算ルールが変わります。しかし、報酬算定エンジンとしては改定後の計算だけができればよいわけではありません。過去に提供した介護サービス分については、改定前のルールに基づいた計算が必要になる場面もあります。そのため、過去の計算ルールに対するテストケースを残しておけることは大きなメリットでした。法改正によって現在の計算ロジックが変わったとしても、過去分の計算が意図せず壊れていないかを繰り返し確認できます。 また、報酬改定のような大きな変更時にも安心感があります。報酬改定では、新しい計算ルールを追加・変更するだけでなく、既存の処理にも手を入れる必要があります。その際に怖いのは、修正対象ではない計算まで意図せず変えてしまうことです。 算定結果のテストとしてQA観点のテストケースを蓄積しておくことで、変更によって想定外の影響が出ていないかを早い段階で検知できます。実際に、修正内容が誤っていた場合には過去のテストが落ちるため、本番環境で不具合を出す前に気づけます。 大きな障害を防いだという派手なエピソードがあるわけではありませんが、こうした小さな検知の積み重ねによって大きな問題が起きていないこと自体が、この仕組みが効果を発揮していることの表れかもしれません。 難しかったこと 一方で、運用していく中で難しさも出てきました。 報酬算定エンジンは開発が進むにつれて機能が増え、それに伴って入力値や出力値も増えていきます。しかし、過去に作成したテストケースは、その時点の入力値・出力値を前提にしています。そのため、最新の入出力項目が存在しない古い形式のテストケースも扱う必要があります。現在は、変換処理の側に「このバージョンの形式のテストケースにはこの入力値が存在しない」といった形式ごとの差分を吸収する分岐を持たせて対応しています。 入力値や出力値が増えるたびに変換処理側で考慮することが増え、コード管理が煩雑になっている部分はあります。テストケースを資産として残すほど、過去のフォーマットとの互換性をどう扱うかが課題になります。 ただし、それでもQA担当者の知見を長く使える資産として残せること、報酬改定やリファクタリング時に想定外の変更を検知できることの価値は大きいと感じています。 まとめ 報酬算定エンジンでは、複雑な介護報酬算定の正しさを継続的に確認するために、QA観点のテストケースを算定結果のテストとして整備しました。この取り組みで大事だったのは、専門知識を持つ人がテストケースを作りやすい入口を用意し、その知見を繰り返し実行できる形にすることでした。 Googleスプレッドシートでテストケースを作成し、それをCSVとして取り込み、報酬算定エンジンへの入力に変換して算定結果のテストとして実行する。さらにCIによって、QA担当者を起点に最新のテストケースで検証できるようにする。この仕組みによって、QA担当者の知見を一度きりの確認作業で終わらせず、継続的に使える資産として残せるようになりました。 複雑なドメインの開発では、エンジニアだけで正しさを判断しきれない場面があります。だからこそ、専門知識を持つ人の知見をどうテストに落とし込み、継続的に実行できる形にするかが重要だと感じています。

こんにちは、エス・エム・エスでカイポケコネクトのエンジニアをしている加我 ( @TAKA_0411 ) です。 私事ではありますが、日本のDatadogコミュニティの活動や社外での登壇の実績を評価されまして、2026年度の Datadog Ambassadors に選出いただきました。 もともと好きが高じて続けてきた活動ではありますが、それらがオフィシャルに評価されたというのは感慨深いものです。今後も積極的なDatadog活用や知見の共有、仲間集めのためのコミュニティ運営を続けていきます。 そういえば、3月に開催されたJAWS DAYS 2026では私も登壇者・ブース担当者として参加していたのですが、Datadog社のブースにて非常に気になるデモを拝見しました。 DatadogのWeb UIから生成AIと会話し、データの調査や分析を行う機能……それが私とBits Chat（当時はBits Assistant）との初めての出会いでした。直感的にこの機能に可能性を感じ、担当営業の方を通じてPreviewにおけるBits Assistantの利用について相談しました。相談から少し時間が経ったタイミングで利用が可能になったので使ってみたところ、非常に便利でした。これは自分だけではなく開発組織全体に知ってもらいたい。そう思ったのがこの記事を書いたきっかけです。 面白いものを見つけたぞのノリで社内共有します Bits Chatについて Bits ChatはDatadogのWeb UIからチャット形式でやり取りすることにより様々な支援を受けられる、生成AIを活用したサービスです。Datadogに蓄積されているデータに対し、下記の機能を提供しています。 問題の調査と対処 テレメトリデータの探索と分析 Datadogの概念や使い方の学習 オブザーバビリティの設定と最適化 docs.datadoghq.com 画面右上のAsk Bitsから呼び出すことができます Bits Chatが活躍するユースケースとして、Monitorのエラー通知からの原因調査、ダッシュボードにおける特定期間のデータ分析、用途を伝えるだけで最適なダッシュボードを作成してもらうといったことが可能になります。つまり、これまで私たちが手動で行ってきた多くの作業をBits Chatがこなせるようになります。 余談ですが、Bits ChatはPreviewによるサービス提供当初はBits Assistantと呼ばれていました。2026年6月に開催されたDASH 2026にてBits Chatと名称変更がされ、BitsというAI機能群のうちの1つとなりました。Datadogには多くの機能があり、新機能も次々と追加されますが、Bits Chatをハブにして活用方法を学んだり実際に設定してみたりすることが可能になります。 www.datadoghq.com さて、私はPreviewでの機能利用が可能になった段階から社内でもりもりBits Chatを使い込んできました。そんな私が得られた知見や開発チームの変化についてご紹介します。 Datadog民主化の鍵はBits Chatである 使ってみて気づいた1つめの大きなメリットがこちらです。Bits Chatを活用することにより社内のDatadog推進者 / Datadogチャンピオン *1 への依存が軽減され、開発者が自発的にDatadogを利用する文化の醸成に貢献してくれます。 Bits ChatはDatadogについて熟知しています。ユーザーが実現したいことや抱えている問題、テレメトリデータの分析方法、ダッシュボードの作成など、様々なテーマについてアドバイスを得ることが可能です。このような動きをするBits Chatを私は「Bits Chat as an Internal Datadog Champion」と表現しています。そうです、Bits Chatは社内で一番Datadogに詳しいチャンピオンなのです。 自社もしくは自分が担当しているプロダクトへのDatadog導入を推進したことがある方はご理解いただけるかと思いますが、Datadogを導入してから安定した運用に至るまでには下記のような多くの問題が発生します。挙げ始めたらキリがありません。しかし導入を推進する人は強い推進力とオーナーシップを持っているため、これらの問題を1つずつ解決し、社内のドキュメントに残し、設定をコード化することで安定したDatadog活用に導くわけです。 そもそもDatadogの使い方がわからない（学習コスト） Datadogがあっても別のツールを使おうとする（ツールのサイロ化） UIが複雑で機能がどこにあるかわからない データの表示切り替え方法がわからない いい感じのダッシュボードを作るのが困難 意図したアラートを設定できない Datadog推進者のSPOF問題 社内のDatadog推進者が色々な問題を解決し、運用を安定させていくにつれて発生する別の問題があります。それは「Datadogの社内活用の拡大が推進者に依存してしまう」「Datadog推進者がSPOFになってしまう」という問題です。 皮肉にもDatadog推進者が強いオーナーシップを発揮するほど「Datadog推進者の人がやってくれる」「Datadog推進者の人にお願いすれば良い」という空気感が出来上がってしまい、Datadogの民主化、ひいてはオブザーバビリティの民主化からどんどん離れていってしまうのです。解像度の高い話をしているなと思った読者のあなた、鋭いですね。これは過去の私自身への自戒です。 Datadog活用のあるべき姿 Datadogは開発組織全体で使うことにメリットがあると私は考えています。特定の誰かが使えるだけではDatadogを活用できている状態とは言えないのです。過去にDatadog推進者のSPOFという原因の一端を担ってしまった私がBits Chatを見て感じた可能性が「Bits ChatこそがDatadog民主化の鍵」でした。 開発者が自発的・自律的にBits Chatへ現在発生している問題や実現したいことを相談すれば、開発組織全体でDatadogを活用でき、結果としてサービスのオブザーバビリティが高まると私は信じています。 ちなみに、Datadogの民主化を促すために最近私が力を入れているのがBits Chat誘導員という役割です。以前はBits Assistantのアシスタントなどと言っていた時期もありました。開発者がDatadogの活用で困ったらすぐさまフォローに入りつつBits Chatへ誘導し、本人にBits Chatとの会話を通じて自身で課題を解決する体験をしてもらうことを率先してやっています。また、アラートが発生した場合は自分が積極的に調査に参加してBits Chatの活用事例を知ってもらう機会も作っています。 こうした取り組みの結果、開発者がBits Chatを活用して自発的に課題を解決したエピソードも生まれています。とある非同期処理をバックエンドで実装するにあたり、処理が別スレッドに移ったこと、そしてスレッドプールが溢れないことをテレメトリデータから確認したいというニーズがありました。これに対し、社内のエンジニアはBits Chatと対話することでSpanの計装とスレッドプールの監視を自力で完遂していました。ご本人曰くDatadogに特別詳しいわけではないそうですが、対話を重ねることで無理なく実装できたと言っていました。 私というDatadogチャンピオンの出番がないまま解決してしまったわけで、これは民主化の一歩と呼べる出来事でした。 Bits Chatとの会話ログの一部を見せてもらいました テレメトリデータ分析会の活性化 私が所属しているチームでは定期的にサービスのCUJ (Critical User Journey) のデータをまとめたダッシュボードの分析会を行っています。しかし、以前はダッシュボードを見てもデータの分析方法がよくわからなかったり、どのデータを見たら問題発見や改善アクションに繋げられるのか迷うことも多く、価値のある時間であるとは言い難いものでした。テレメトリデータはDatadogに蓄積されているため、ダッシュボードを作り直そうかなどと考えていたのですが、このデータ分析自体をBits Chatにやらせてみようという取り組みを始めました。 分析するなら意味のある会にしたいという議論もありました 分析の方法として、CUJのデータをまとめたダッシュボードに対してBits Chatから「ダッシュボードのデータの分析をしてください。分析するための条件は〜〜です。分析したデータはNotebookにまとめておいてください」といった形で分析を依頼していました。数回やっているうちにNotebookのCustom Templates機能を使えばある程度再現性のある形で実行・保存できるのでは？と気づき、最近では専用のNotebookテンプレートを用意し、そのフォーマットに沿って分析依頼を行っています。 分析用のプロンプト例 (クリックすると展開されます) Custom Templatesの例 # 分析用のプロンプト例 CUJに関するデータについて下記の観点を中心に比較・分析し、Notebookとして保存してください。 Notebookのテンプレートは「CUJ分析レポート - {mm-1}月 vs {mm}月比較 」を使用し、テンプレート中の{mm}には当月の数字を、{mm-1}には前月の数字を、{対象サービス}には"sample-app" を入れて置き換えてください。 また、Notebookへのデータ追加時にはテンプレートのフォーマットを必ず遵守してください。 以下は分析対象です。 ■ 分析対象 ・CUJサービス: service:sample-app (GraphQL Operation別に集計) ・重点分析サービス: service:sample2-app ・RUM: sample-frontend ■ 条件 ・分析対象の期間: 前月1日〜前月11日 vs 当月1日〜当月11日 ・環境: production ・Operation: ◯◯関連のOperationName呼び出し回数Top10 + △△関連のOperationName呼び出し回数Top10 ■ 比較観点 ・GraphQL Operationの呼び出し回数の変化 ・レイテンシ(P95)の変化 ・エラー数の変化（エラー率も算出） ・CUJのLatencyのP95で500msecを超えるGraphQL Operationの有無 ・sample2-appの新規Operation出現有無 ■ RUM分析 ・全体: ビュー数/セッション数/P95ロード時間/エラー合計 ・遅延ページ: P95 > 1秒のCUJページ抽出 ・XHRボトルネック: 最も遅い外部リクエストの特定 ・エラー分類: Top10エラーの分類と対応要否判定 ■ 計測単位 ・呼び出し回数: リクエスト単位（@_top_level:1） ・エラー: 子スパン単位とリクエスト単位を併記 ■ P95 > 1秒判定のデータソース ・custom.sample-app.graphql.request.duration メトリクス （スパン保持期間を超える場合に対応） ■ 追加分析（可能であれば） ・アクティブユーザー数との相関 （データソース: Sheets「ユーザー数管理」） ■ 出力形式 ・サマリー（全体評価テーブル + キーインサイト）を冒頭に ・推奨アクション（優先度高/中/ポジティブな変化）を末尾に ■ 関連リソース ・ダッシュボード: /dashboard/aaa-bbb-ccc/cuj-dashboard この分析方法に変えてからダッシュボードの分析会に変化が見られました。Bits Chatがまとめてくれたデータを見つつ、データに対する疑問だったりデータの見せ方の工夫に関する意見が積極的に出るようになりました。 なぜこのエンドポイントでのエラーがこんなに発生しているのか エラー数はリクエスト単位とスパン単位でデータを出し分けた方がいいのではないか（Next Actionへ） このエラーは原因を調べて対処したほうがいいのではないか（Next Actionへ） ユーザー数の増加とGraphQL Operationの実行回数に相関はあるのか フロントエンドのボトルネックは◯◯が原因そうなので調べてみてもいいのではないか ユーザーの利用増加を数字から感じられて良い 実際私もダッシュボードの分析会で発見したエラーの原因を調査し、バックエンドのエラーハンドリングを改善するといった対応を行うことができました。Bits Chatは具体的なソースコードの改善方法も提案してくれるので、私のような開発経験が少ない人間でも積極的にサービスの改善に繋げることができます。 突出しているエラーの改善をやったりしてます 最高のデバッガーを支えるBits Chat とある日の午後、1つのアラートが発生しました。レスポンスタイムが基準値を上回っていました。私も調査に入りつつBits Chatにアラート原因の分析を依頼し、別のエンジニアはログの分析をしてくれていました。 Bits Chatを使いつつトレース・ログ・メトリクスのデータを分析してみます。どうやら別のチームがオーナーとなっているシステムが関連していそうです。そして私はあまりそのシステムの中身を知りません。Bits Chatがまとめたデータを見てみると該当の時間帯にECSのCPU使用率が高まっていることがわかりました。じゃあなぜこのタイミングで使用率が高まるのかを調べてみます。自分も実際に関係しそうなソースコードを見て、微力ながら議論に参加していたわけですが、結論としてはデプロイ中にリクエストを受けるとタイミング次第でリソース消費量が高まってしまうという現象であることがわかりました。 私はデータの拡充という観点からDatadog Continuous Profilerを有効化し、オーナーであるチームはリソース消費量を抑えるための具体的な施策について議論していました。また、デプロイ完了のタイミングも改善が可能では？という議論が続きます。 今回のアラート対応を経て、私が開発であまり携わっていないシステムのことについても少しだけ詳しくなり議論に加わることができました。自分がよく知らないシステムの調査は大変です。しかしBits Chatの助けを借りることで仕様の理解と現象の理解を無理なく行えるのがよくわかりました。 そしてこれは、私だからできたという話ではありません。書籍『オブザーバビリティ・エンジニアリング』では、オブザーバビリティを実践しているチームにおける最高のデバッガーは好奇心が強いエンジニアであると述べられていました。裏を返せば、デバッグに必要なのは深いシステム知識ではなく好奇心ということになります。その知識の差はBits Chatが埋めてくれます。開発経験が少ない私でも越境して調査に加われました。好奇心さえあれば、多くの開発者が同じように動けるはずです。Bits Chatの力と好奇心を武器に、どんどんアラート対応して学んでいきたい所存です。 www.oreilly.co.jp まとめ Bits Chatのユースケースや社内での活用例、その結果もたらされたものについて書いてみました。改めてBits Chatが私たちの開発組織にもたらしたものを3つ挙げます。 社内のDatadogチャンピオン（例えば私）を頼ることなく、開発者が自発的にBits Chatと対話し、エラーの原因分析や計装の改善を進めるようになりました。社内で一番Datadogに詳しいのはもう私ではなくBits Chatです。 ダッシュボードの分析会が「データを眺めるだけの会」から「Next Actionが生まれる会」に変わりました。分析そのものをBits Chatに任せることで、私たちはデータへの疑問や改善アクションの議論、ひいてはユーザーへの価値提供に時間を使えるようになりました。 開発経験の多寡を問わず、担当していないシステムの調査にも越境して加われるようになりました。よく知らないシステムであっても仕様の理解と現象の理解を無理なく進められます。 Bits Chatは便利です。開発組織にとても多くのメリットをもたらしてくれます。Datadogを使っているけど上手く使い切れていないという課題を感じている方は導入をオススメします。一見コストが高いと感じられるかもしれませんが、利用することで得られるものは少なくないはずです。 今後の課題 一方でBits Chatはトークンを消費してアクションを行うので、どのように運用すればトークンが最適化されるのかを考えなければなりません。複数人でアラート対応をしている際、各自がばらばらにBits Chatへ質問をするとトークンが無駄になる可能性があるため、この場合の最適な運用フローを今後整備していく必要性を感じています。また、Bits Chatへ頼りきってしまい、ダッシュボードの整備が全くできていないという状況を招かないよう気をつけていきたいと思います。 私個人としましては、エンジニアが自分の言葉でBits Chatとやり取りして問題を解決する（もしくは解決の糸口を見つける）というのは大事な体験であると思っているので、あまり制限せずに効率的な運用ができたらなーと考えています。Bits Chat愛好家のみなさま、コスト最適化についてぜひディスカッションしましょう！ *1 : 強いモチベーションと推進力で導入を牽引する人。公式のDatadog Championsではありません

こんにちは。プロダクト開発部介護キャリア開発グループの髙木です。 直近で新しいチームに移ったのですが、新しいチームで仕事をしやすくするために仕事の雑談というものを主導してやってみました。2か月ほどやってみたところ思っていたよりも感触が良かったので紹介させてください。 前提として、今のチームのプロダクト開発はリモートワークで進められており、同期的なコミュニケーションを取る頻度は朝会のみとなっています。それ以外は必要に応じて会を設定するような形になっています。 どういう課題を感じていたか 新しいチームに移った際、基本的にわからないことを埋める作業から始まると思います。 このプロダクトで解決したいことはなにか どういうビジネスモデルなのか どういうアーキテクチャなのか どういうチームの体制なのか これらのプロダクト周辺のことを解消しつつ、少しずつ開発に入っていくと思います。そして理解度が高まる中でいろいろな疑問が出てくると思います。 そもそもこのプロダクトって〇〇と同じでは？ 将来的にこういうビジネスモデルは保たなさそう？ 先に解決するべき課題ってないんだっけ？ などなど。 加えてそれらの疑問は、新しく入ってきたメンバーだけでなく既存のメンバーの中にも自分なりに蓄積されています。それらの疑問や不安、アイディアを発散させる場として「仕事の雑談」という場を作ろうと思いました。 どういう場を作ろうとして何をしたか 1. 特定の人だけが話す場にしない 基本的にどういう会議でも話す人と話さない人に分かれ、話す人が偏りがちな問題はよく起こると思います。そのような偏りを許容するかどうかはさておき、この場においては偏りは極力減らしたいと思っていました。話す人が偏るとどうしても結論やテーマなど含めて偏りが出てきて、新しい観点や課題を持つことが難しくなると思っていました。あとはみんながどういう課題や考え方をしているかを知りたいという側面もありました。 そのために、話す人は場において2人としました。最初は3人で運用してみたんですが、3人にしてもひとりは話すタイミングが難しくなったので2人に減らしました。話す人はルーレットで決めて、ランダムにします。テーマ的に話してもらったほうがいい人がいればその人を指名しています。 2. 他の参加者が同じ情報を得られるようにする 話す人を固定すると、それ以外の人は話すことができません。それだと参加しないという選択肢もあるのですが、どう考えているかを聞いてもらったほうがいいと思っていました。録画があっても多分見ないし、そうなるなら1on1で良くなってしまいます。なので終わったあとに情報共有を受けるのではなく、ポッドキャスト的に聞いてもらうことを目指しました。 会議に参加しているのに何も発信しないことは良くないとされることがありますが、明示的に話さないことを良しとすることで会話を聞くことのみに集中できます。ポッドキャストやオーディオブックなどを聞いていると、頭の中でその話題について別途考えてしまうと思います。話せないがゆえに自分の中でテーマに対して別の考えを持てるようにもなるので、話す人・話さない人を決めるというのは有意義だと思いました。また話す人は決めるものの、差し込みたい話題が出てくることもあります。その場に参加しているがゆえに話題を深ぼる事もできるので、その場に参加している意味が出てくると思いました。 やってみてわかったこと この取り組みの情報を整理します。 実施頻度：週1回 実施時間：30分 参加者：だいたい6人ぐらい 参加者のロール：開発者、プロダクトマネージャ、マーケティング担当 話す人：テーマを決めた人 + ルーレットでもう一人 正解を出さなくてもよい 自分の考えていることを双方ともに話していくことで、考え方の広がりや自分が持っている偏りを認識することができました。自分の考えの正しさを話すというわけではなく、正解のないものに対して考えを深掘るきっかけになりました。 想定していたよりもみんな話せる 話す人が2人しかいないので会が成立するか少し不安ではありましたが、実際にやってみると指名された人はそれぞれ自分なりの考えを持っていて、思っていた以上に話がはずみました。特定のテーマについて話す場合でも、それぞれの業務的な視点が違うと出てくる着眼点も変わるように感じました。 テーマを出すのが難しい これらの取り組みにおいて毎回話題になるのがテーマ選びだと思います。ちなみにこの取り組みにおいてもテーマを出すことには苦戦しています。今のところだいたいは僕がなんとか工面しています。普段の業務からこのテーマがいいなーというものをピックしています。 実際に話したテーマを列挙してみます。ちょっと具体的すぎるものはぼかしています。 このプロダクトでつくる価値と今の課題 競合プロダクトと弊社プロダクトの差 弊社プロダクトのターゲットとその理由 ATSとは何？ プロダクト開発部総会の深堀り 求職者がLLMを軸に活動する未来について たぶん早々にテーマ切れが起こるので、業務の中での疑問を溜め込むための工夫などをしないと破綻しそうです。 テーマを出した人は話したほうがいい テーマを出す人は、そのテーマについて何かしら思うところがあって出しているはずです。その人が感じている話題を掘り下げることで、他の人がその話題に対して発信しやすくなると思いました。事前に話題が決まっているケース以外では基本的にテーマを出した人ともうひとりを無作為に選出というのが良さそうでした。 続ける？ or やめる？ 確実にやる価値があると思ったので続ける予定です。 プロダクトを開発していると視野が狭まっていく感覚があります。その視野を狭めずにプロダクトの方向性を決めていくのがプロダクトマネージャの役割だと思いますが、開発メンバーはどうしても目先の機能やプロダクトに対してのみ目線がいきがちになります。開発メンバーの視野を改めて広げつつ、今やるべきものにフォーカスを揃えるということは、なぜ今やるのかを見直すきっかけになり開発の質を上げることにもつながると思います。 またプロダクトを主導する側の視点に立つと、開発メンバーの持っているプロダクトへの解像度や将来性について考えていることをインプットできる機会はそう多くありません（もちろん1on1などを実施することで解消することもできるとは思います）。各々がどう考えているかを聞くこともできますし、自分が足らない知識を得ることもできます。 加えて職種を越境して会話を行えるため、マーケティングの観点や開発者の双方の課題感を1つのテーマについて話し合えるので、課題に対して一方向からの議論にならないのも良いと思いました。これは当初想定していた効果でしたが想定通りよかったです。 いろいろ書きましたが、僕が想定していたよりもかなり価値の高い取り組みになりそうだと思いました。 最後に チームで開発をしているといろいろと課題が出てくると思います。課題を直接的に解決するのか間接的に解決するのかによって、とれるアクションは変わってくると思います。今回の施策は間接的な施策によってチーム全体の練度を高めていく施策だと思います。こういう施策を考えられるか・実践できるかによってチームでのプロダクト開発のしやすさは変わっていくと思うので、今後ともこういうことは試していきたいと思います。

こんにちは、エス・エム・エスでカイポケコネクトのSREをしている 小笠原翔太 です。 2026年7月10日に開催された SRE NEXT 2026 のスポンサーセッションで、「 PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用 」というタイトルで発表しました。 発表スライドも公開していますが、せっかく取り組みについて文章をまとめたのでテックブログにも展開しようと思い、まとめ直したものがこちらの記事となります。発表内容に加えて、ブースで展示していた現在のpreview環境のアーキテクチャについての補足説明も加筆しているので、そちらは発表との差分となっています。 はじめに 全体の話はひとことでいうと、 既存プロダクトにPR単位で使い捨てられるpreview環境を導入し、1年間運用してきた話 です。 目次 はじめに 目次 カイポケコネクトと開発フェーズ カイポケコネクトとは システムアーキテクチャ 開発フェーズ 当時のリリースフロー リリーストレインの課題 1. リリース周期が長い 2. QA環境の利用が詰まる 3. 担当者の負担が大きい 解決策： 検証作業を分離して並列化する preview環境をどう設計したか 必須要件 インターフェース設計 アーキテクチャ デプロイフロー サービス構成 設計時に考えたこと 運用してどうだったか 狙いどおりリリース頻度を高められた 段階的に改善しながら育てた 結果的に利用が伸びた 運用してわかったこと 1. 複製機構の利用技術についてわかったこと 2. 複製「できない」外部サービスとの付き合い方が難しい 3. preview環境の想定外な需要が見えた まとめ 付録: 現在のアーキテクチャの紹介 カイポケコネクトと開発フェーズ カイポケコネクトとは 最初に、私たちが扱っているシステム「カイポケコネクト」は、介護/障害福祉事業者向け経営支援を行うSaaSプロダクトです。 システムアーキテクチャ カイポケコネクトのシステムアーキテクチャは、拡張性と独立性を保つためドメインごとにアプリとDBを分割して設計しています。 利用されている技術スタックと本番系の基盤構成は次のとおりです。 レイヤー 技術スタック 本番系の基盤構成 フロントエンド React / Next.jsによるSPA CloudFront + S3 バックエンド Kotlin / Spring Boot / GraphQL ECS Fargateでホスティング。5つのタスクでGraphQL APIを構成 DB PostgreSQL RDS Aurora PostgreSQL また、本体サービスとは別の複数の社内サービスとも連携しており、バックエンドのコンテナ数から考えると中規模サイズのシステムと捉えてもらうと良さそうです。 開発フェーズ プロダクトは初期の開発フェーズが完了し、プロダクトの価値を拡大する「機能追加・サービス拡大フェーズ」へ移行しようとしているタイミングでした。 そのため、 プロダクト開発の生産性を支えるために機能開発を加速させる必要があった というのが背景です。 当時のリリースフロー そのような開発の事情があるなかで、当時のリリースフローは以下のようになっていました。 当時のリリースフロー デプロイ先のAWS環境はDev, QA, Staging, Productionの4つ用意してそれぞれ使い分けていました。 まず開発フェーズでは、開発者がPRを用意してテストが通ればmainにマージしてDev環境にデプロイしていました。Dev環境は開発者が最初にデプロイするAWS環境で、少し壊れやすいのですがアプリの動作検証や基盤の構成変更の検証を行う用途で利用されていました。 一方で、本番系へのリリースフェーズでは、それとは別で リリース担当やリリースマネジャーが主導してデプロイする方式 を取っていました。 具体的には以下の流れでリリースが行われていました。 リリース担当がリリースするrevisionを決めてコードフリーズを行い、そのrevisionでQA環境へデプロイする 全QAメンバーがQA環境を占有して検証作業を実施 リリース担当がリリースタグを作成し、Staging環境へデプロイする リリース担当がテストランナーでE2Eテストを実行する リリース担当がリリースタグを作成し、Production環境へデプロイする QA環境はバージョンを固定して検証を行うための専用環境、Staging環境はE2Eテストを実行して意図しないデグレが発生しないことを保証するための環境という建付けでした。 つまり、いわゆる リリーストレイン方式でリリース していました。 リリーストレインの課題 このプロジェクトにおけるリリーストレインには大きく以下3つの課題がありました。 1. リリース周期が長い 最も大きな課題はリリース周期が長いこと です。このプロジェクトのリリースサイクルは2週間に一度でした。 開発スピードに対してリリースサイクルが長いため、価値提供の大きなボトルネックになっていました。またリリース時には2週間分の差分がまとめて本番へ反映されます。そのためリリースのタイミングで事故が起きやすく、問題発生時の切り分けも難しい状態でした。 2. QA環境の利用が詰まる 次の課題としてはQA環境の利用が詰まるという問題がありました。QA環境は検証用の占有環境として利用され、かつ 全QAメンバーが直列に検証作業を行うためどうしても長期間ロックされてしまいます 。結果的に検証期間が長引き、当時は1週間ほど環境を確保するようになっていました。 検証作業を効率的に実施できず、その間は新しいリリースもブロックされる構造になっていました。 そのため、 今後開発を加速させようとしたときに、ここの詰まりによってスケールできなくなることが容易に想像できました 。 3. 担当者の負担が大きい リリーストレインのもう1つの問題として、取りまとめを行う人の負担が大きいという人的な問題もありました。リリース担当やリリースマネージャーがリリースを主導する必要があるのですが、そこに 運用作業とリスク管理の負荷が集中 していました。 ミスを防ぐための手動プロセスや手順も増えがちで、運用が重厚になっていました。さらに、リリースされる差分のすべてを把握することが困難でした。そのため、問題発生時の対応に手間取ったり、チームをまたいだ調整コストが増えたりして、担当者を疲弊させていました。 解決策： 検証作業を分離して並列化する 解決策として考えたのは「 リリースフローから検証作業を分離して並列化する 」ことです。 以下の図は検証作業を分離・並列化したときのリリースフローの概念図です。 検証作業を分離・並列化したリリースフロー これまでリリースフェーズで行っていた QA環境での検証作業をすべて開発フェーズに移行 しています。 開発フェーズで開発者がPRを作成したあとに専用の検証環境を立ち上げ、QAメンバーがPRごとに検証作業を並列で実施できるようにします。 そして、リリースフェーズでは、Dev環境にデプロイした後は毎日定時にGitHub Actionsのscheduled workflowを起動します。このジョブはStaging環境へのデプロイからE2Eテストの実行、production環境へのデプロイまでを連続して実行する軽量なワークフローです。 また、リリースフラグを導入することで、PO（プロダクトオーナー）が任意のタイミングで新機能をリリースできるようにします。 この方式に変更することで次の効果を狙います。 リリースが毎日できる ：隔週から毎日へと頻度が上がり、価値提供が高速化。デプロイごとの変更差分が小さくなり、原因特定も容易になる QAのシフトレフトと並列化 ：検証作業を開発フェーズに移すことでリリースを安定化させ、チームや機能ごとに検証作業を並列化することで詰まりを解消する プロセスの軽量化 ：重厚なリリース手順を廃止し、リリースフローを自動化・軽量化する。リリースフラグを導入することでデプロイと新機能の有効化（機能リリース）を分離する 先ほど紹介したリリーストレインの主要課題をすべて解決できるようになっています。 preview環境をどう設計したか 先ほど述べた、リリース改善施策実現に必要な構成要素の1つが、検証作業を行うための環境（私たちはこれをpreview環境と命名）でした。 この章ではそのpreview環境をどう設計したかについて説明します。 必須要件 まずQAプロセスで必要な要件は以下3つでした。 十分な数の環境を 容易に 作れること 利用チームが 任意のバージョンをデプロイできる こと DBを使い捨てできること ーデータが汚れることを気にせず占有して使えること インターフェース設計 次に利用者のインターフェースの設計についてですが、こちらはVercel等のSaaSの開発者体験を参考にして以下のように設計しました。 GitHubのイベントをトリガー に、preview環境を自動で構築・更新・破棄する PRのコメントに自動で 各種アクセス情報を付与 する 以下はpreview環境を立てたPRのサンプルです。 preview環境を立てるPRのサンプル PRにラベルを付けると環境構築が始まり、完了するとbotがコメントでアクセス方法を案内する、という開発者体験になっています。 このようにインターフェースを作った理由は、以下を狙ったためです。 開発者とQAのスムーズな連携 ：開発者がPRに実装をまとめ、それをQA担当者へ渡すことでスムーズに検証作業に移ることができる ライフサイクル管理のしやすさ ：環境がPRに紐づくため、不要な環境の消し忘れを防いだり、クリーンな環境管理が可能になる アーキテクチャ 次にpreview環境のアーキテクチャを紹介します。全体像は以下のようになっています。 preview環境のアーキテクチャ全体図 デプロイフロー まず、preview環境のライフサイクルはGitHub Actionsのワークフローで以下のように管理します。 PRにpreviewラベルを付与 : PRの先頭のコミットハッシュを利用して環境を構築する PRにコミットをプッシュ : 差分が入ったコンポーネント（FE/BE/DB）のみ更新処理を行う PRをマージ、クローズまたはpreviewラベルを外す : 環境を削除する サービス構成 次にサービス構成ですが、 preview環境ごとにフロントエンド/API/DBを1セットずつ用意する ようになっています。 ドメインは https://preview-N.kaipoke.com （NはPR番号）を環境ごとに払い出しており、そこからアクセスできます。 フロントエンドはSPAなので、シンプルにCloudFrontとS3で配信しています。リクエストのホスト名に応じてアセットを出し分けるようにLambda（CloudFunction）を挟んでいます。 APIへのアクセスはCloudFrontとALBを介してmirage-ecsコンテナのproxy機能でハンドリングされ、ホスト名ごとにリクエストを各環境に振り分けています。環境ごとにバックエンドとDBが1セットずつ用意されており、バックエンドのECSタスクは mirage-ecs で、DBはSaaSの Neon でそれぞれ構築・管理しています。 なお、バックエンドは一環境あたりECSタスクが全部で5個動いており、内部でGraphQLのfederationを組む構成です。 モニタリングは本番系と同じくDataDogを利用して、トレースやログ、基盤のメトリクスを確認できるようにしています。 このような仕組みによって、 PRごとの環境をAPIやDBまで独立した形で複数個準備できるように作っています 。 参考情報ですが、環境の初期構築にかかる時間は2026/07/14時点で 10分程度 です。 設計時に考えたこと 設計にあたっては、以下3つの原則を守るようにしていました。 要件が不明確なうちから作り込まない ：初期段階での過剰な設計や実装を避けるため 運用・開発の負担が少ない技術を選ぶ ：当時は アプリ開発者のリソースが逼迫 しており、開発者の負担を極力抑える必要がありました 最初から完璧を目指すのではなく継続的に提供価値を高めていく ： 仕組み作りに使えるSREのリソースが当時少なかった ため、小さく作って継続的に提供価値を高めていく方針を採用 運用してどうだったか 実際に1年ほど運用してどうだったか、振り返っていきます。 狙いどおりリリース頻度を高められた まず 当初の狙いにしていたリリース頻度を高めることには成功 しました。 以下は月別のデプロイ回数の推移を表したグラフです。 月別デプロイ回数の推移 リリース方式を切り替えた2025年10月ごろから、 月2回だったデプロイが月20回前後まで増えました 。営業日は毎日リリースできるようになったことがわかります。 これはpreview環境以外の施策との合わせ技による成果ではありますが、 サービス拡大期の開発効率の向上に貢献できた と考えています。 段階的に改善しながら育てた そして、設計方針に従ってpreview環境は導入後に要件を適宜見直しながら改善しました。 以下のグラフはpreview環境に関するPRの月別件数推移を表しています。 preview環境に関するPRの月別件数 全体のタスク量は多く、PR総数も結果的に 200件超となっていた のですが、対応を段階的に行うことで少人数（設計から導入初期までは担当一人）でも早期に仕組みを開発に展開でき、その後の改善も継続することができました。 設計時に置いた「小さく作って継続的に改善する」という原則が、うまく機能した と感じています。 結果的に利用が伸びた 結果的にpreview環境の利用数は順調に伸びました。以下は月別のpreview環境を利用したPRの件数推移のグラフです。 preview環境を利用したPRの月別件数 導入当初は80件ほどだった利用件数が2026年6月は160件程度まで利用が伸びている ことがわかります。 あとでも触れますがこれは当初想定の用途以外の利用が増えたことも理由となっています。 運用してわかったこと 次に運用してわかったことや気付きについて大きく3つ紹介します。 1. 複製機構の利用技術についてわかったこと 今回、バックエンドの複製には mirage-ecs というコンテナ管理の軽量なOSS、DBの複製にはSaaSの Neon を使いました。 まずmirage-ecsは、既存のECS Fargate構成とデプロイの仕組み（ecspresso）にアドオンする形で導入できました。ecspressoの作者が作ったツールのため、 親和性が高くデプロイの仕組みをそのまま維持することができました 。 ツール導入で学習すべき新しい概念が少なく、メンテナンスも簡単で、開発チームへの負担を最小限に抑えながら導入できたのは非常によかったです。現在まで、他ソリューションへの置き換え検討が必要となる問題も出ておらず、安定して運用できています。 次にNeonですが、直感的で扱いやすいWeb UIや高速なブランチ機能、各種管理機能が充実しており、 DB複製機能の初期導入にかかる工数を大幅に削減できた のは良かったです。 一方で、サーバ配置先の制約による性能課題がありました。DBの配置先は最寄りでもSingaporeリージョンのため、SQL実行時のレイテンシーが大きくなり、 結果として一部のページで表示に時間を要する点が課題として残ってしまいました 。 機能検証においては無視しても問題ないということでしばらくはそのまま利用していましたが、動作がもっさりするのでなんとかしたいという声が多く出る状況でした。 そのため、現在はtokyoリージョンに立てたAurora Serverless v2（RDS）を利用する方式をメインに運用しています。付録にてそちらのアーキテクチャについては補足します。 2. 複製「できない」外部サービスとの付き合い方が難しい 2つ目の気づきですが運用してみて実感したのは、 プロダクト本体の複製よりも、複製できない外部サービスの扱いが難しい 、ということです。 本体の複製は開発チームでコントロールできるのですが、利用している外部サービス（連携する社内サービス含む）には様々な制約があり、それぞれ妥協案を作って運用していく必要がありました。 例えば認証基盤については契約プランの制約でテナントを新規作成できなかったため、既存テナントに相乗りする形で対応しました。 結果的に（特に不便なく運用できているものの）Dev環境のDBをコピーする方式を選択せざるを得なくなりました 。 ある社内サービスではアーキテクチャ上の制約により、環境複製の難易度が高くすぐには実現できませんでした。 結果的に既存環境に相乗りし、preview環境向けのデータを識別できるようにアプリを改修してもらい、運用でカバーする形になりました 。 また他の社内サービスでは、契約プランや予算管理上の制約があるため環境の複製ができないため、特定のpreview環境にのみ期間限定で連携するというような運用になりました。 これらの外部サービスに共通する課題は2つあります。1つは、 連携が増えるたびに運用の取り決めや調整を個別に行う必要があり、対応コストの増加につながる 点です。もう1つは、 自チームだけではコントロール・解決できない他部署・他チームの仕様や予算制約が絡むケースも多く、難易度を引き上げている点 です。 preview環境を有用な状態で維持するためには外部のサービスをうまく検証用途で動かし続けるための工夫という、技術以外の課題をクリアしていく必要がある点に注意が必要だと強く感じました。 3. preview環境の想定外な需要が見えた 3つ目の気づきはpreview環境の想定外な需要が見えたことです。 当初はQAプロセスでの利用を想定していたのですが、実際は 全体の8割が開発チームの自主的な動作確認・検証目的で利用 されていました。QA引き渡しでの利用は予想に反して全体の20%にとどまっていたのです。 開発者のユースケースには例えば以下がありました。 リスク回避 ：Dev環境へのデプロイ前の早期リスク検知 DB migrationの確認 ：DB migrationの簡単で安全な検証に利用 AIを活用した並列開発 ：複数PRを互いに影響させず同時に検証 ローカル代替 ：一時的にローカルがうまく起動できない場合などに代替の検証環境に利用 つまり 「容易に立てられる検証環境」の存在自体が、開発体験（DX）にとって実は大きな価値になっている ことが運用してから初めてわかりました。設計時は実際にどのくらい使われるか見えておらず、これは運用後の一番大きな気付きでした。 まとめ 既存プロダクトにpreview環境を導入・運用して見えてきたことは、次の3点です。 環境運用の実現性 ：今回の技術スタックでも、中規模システムのpreview環境は十分に運用できることがわかりました。少人数で運用でき、開発負担も小さく抑えることができました 外部連携の課題 ：本体の複製以上に、複製できない外部サービスとの連携設計が重要になることがわかりました 導入後の進化が大切 ：今回のように導入してから改善していくアプローチでは、運用に乗ってからの継続的な改善こそが本番となります。プロダクトの成長に合わせて育てていくことが重要です preview環境というコンセプト自体は目新しくありませんが、既存プロダクトへ導入して1年間運用してきた知見が、読んでいただいた方の参考になれば嬉しいです。 なお、発表資料は Speaker Deck で公開していますのでそちらも適宜参照してください。 付録: 現在のアーキテクチャの紹介 当日の発表スライドではお見せできなかったのですが、ブースで展示・紹介していた現在のアーキテクチャは以下のようになっています。 現在のアーキテクチャ全体図 先に紹介したアーキテクチャとの違いは DBの複製機構がNeonからAurora Serverless v2（RDS）を利用した形に変わっている ところです。 サービスごとに1つインスタンスを用意し、preview環境ごとに内部的にPostgreSQLのデータベースを作り、dump/restoreでDev環境のデータを流し込んで作っています。 Neonで利用者によく使われていたWeb UIについては、自作して提供しています。 Web UIの画面サンプル（接続ページ） Web UIの画面サンプル（テーブルビュー） データベースの中身を気軽に閲覧したり、テーブルの値をGUIで編集する、SQLを実行するなどの機能を持った軽量なDBのwrapperツールとなっています。以前は自力でこのようなツールを作るのは工数的に難しかったのですが、生成AIの力を借りることで要件の緩い社内ツールであれば数日で作成できるようになっていて大変ありがたい限りです。 なお、RDS方式はNeonと比較すると新しいデータベースを作るのにかかる時間は少し大きくなっています。これはdump/restoreで複製を行っているためで、現状は最大4分程度かかっています。データ量が増えるとCopy on Write方式でクローンするNeonに優位性が出る可能性もあり、このあたりは利用実体を確認しながら都度調整していく必要があると考えています。

こんにちは、エス・エム・エスでカイポケコネクトのSREをしている 小笠原翔太 です。 2026年7月10日（金）・11日（土）の2日間にわたって開催された SRE NEXT 2026 に、エス・エム・エスは Goldスポンサー として協賛し、ブース出展とスポンサーセッションの登壇を行いました。ご来場いただいたみなさま、運営スタッフのみなさま、本当にありがとうございました！ この記事では、当日のブースの様子やアンケート結果、スポンサーセッションの内容、そして現地で感じたことを参加メンバーの視点からレポートします。 SRE NEXT 2026とは SRE NEXT は、SRE（Site Reliability Engineering）をテーマに、信頼性に関わるエンジニアたちが一堂に会する国内最大級のカンファレンスです。今回はTOC有明を会場に、2日間にわたって開催されました。オンライン・オフラインを合わせると延べ1,000名を超える参加者が集まる、大盛況のイベントとなりました。 エス・エム・エスがスポンサーとして参加したのは、私たちが日々向き合っている信頼性の取り組みや、それを支える技術・チームのあり方をSREコミュニティのみなさんと共有し、対話したいという想いからです。介護・医療・ヘルスケア領域という社会性の高いドメインで、どのようにプロダクトの信頼性を作っているのか。その一端を知ってもらえる場にしたいと考えていました。 ブースのコンセプト 今回はエス・エム・エスから総勢6名が参加し、ブースの企画はみんなで考えました。 ブースに立つエス・エム・エスの参加メンバー ブースづくりで意識したのは、カイポケコネクトの取り組みを紹介しつつ、訪れた方々とインタラクティブに交流できる場をつくる、ということでした。私たちがどんなチームで、どんな技術でプロダクト開発と向き合っているのかを、来場者のみなさんと 対話しながら伝える ことをコンセプトに据えています。 具体的には、大きく2つの展示を用意しました。 アンケートパネル ：SREに取り組むうえで「どの領域に課題・関心があるか」を来場者に投票してもらうパネルを設置し、それをきっかけに会話が生まれるようにしました。 preview環境の紹介とソースコードの公開 ：スポンサーセッションで発表するカイポケコネクトのpreview環境の構成図やデプロイフローをパネルで掲示し、合わせてソースコードの公開を行い、リアルな開発の中身に踏み込んで話せるようにしました。 ノベルティとして、思わずクスッとしてしまうようなネタ缶バッジを何種類も用意しました。SREらしい「SREをはじめよう」「オブザーバビリティ」から、インフラならぬ「イソフラ」まで種類はさまざまで、来場者のみなさんにそれぞれお気に入りを選んでいただきました。 ブースで配布したネタ缶バッジをつける開発推進チームのEM アンケート結果 ブースで実施したアンケートには、2日間で 261票 の投票をいただきました。「今の開発組織で“モヤッとしている”のはどこ？」という問いに対する結果がこちらです。 ブースで実施したアンケートの集計結果 アンケート集計結果 領域 票数 コスト 49 セキュリティ 39 開発者体験 36 ビルド・デプロイ 35 モニタリング 35 ビジネスとの距離感 28 テスト 20 その他 19 もっとも票を集めたのは 「コスト」 でした。話を聞くと、 生成AI導入による開発コストの増加 やその管理方法に課題を感じている方が多くいました。続く 「セキュリティ」 については、昨今頻発している サプライチェーン攻撃 や 生成AIに関する脆弱性 が話題に上がることが多かった印象です。3番目に多かった 「開発者体験」 は、まさに今回のスポンサーセッションで扱ったテーマでもあり、多くの方が関心を寄せていることを肌で感じました。 また、票が特定の領域に偏らず、8つの選択肢に幅広く分散したことも印象的でした。SREに求められる役割の広さと、それぞれの現場が抱える課題の多様さが、この結果によく表れているように思います。 投票のあとには「うちのチームはこの領域で困っていて……」といった具体的な会話が自然と生まれ、パネルが対話のきっかけとしてうまく機能してくれました。 スポンサーセッション 今回はスポンサーセッションにも登壇し、私（小笠原）が 「PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用」 というタイトルで発表しました。 スポンサーセッションで発表する様子 もともとカイポケコネクトの開発では、隔週のリリーストレイン方式を採用していましたが、そこにはいくつかの課題がありました。 リリース周期が長い ：隔週リリースのため、価値提供までに時間がかかる QA環境の占有 ：検証で環境を長期間ふさいでしまい、ほかの機能のテストがブロックされる 差分の肥大化 ：2週間分の変更が一度に本番へ入るため、問題が起きたときの切り分けが難しい リリース担当者への属人的な負荷 これらを解決するために取り組んだ施策の1つが、 PR単位で自動的に構築・破棄される「使い捨てのpreview環境」 です。GitHubのラベルをトリガーに、PRごとの環境を自動で立ち上げ・更新・破棄し、アクセス情報はPRに自動で書き込まれます。こうした仕組みで、リリーストレイン脱却に向けて取り組みました。 技術的には、フロントエンドをCloudFront + S3、バックエンドを mirage-ecs （既存のECS構成に手を入れずに追加できる）で構成しました。DBは当初 Neon から始め、その後Aurora Serverless v2へ移行しています。いずれも、 リソースが逼迫する中でも運用負担を最小限に抑える技術選定 を意識しました。 発表では、実際に1年間運用してみて得られた気づきや知見についてお話しさせていただきました。当初はQAメンバー向けを想定していた環境でしたが、蓋を開けてみると、 開発者自身の自主的な動作確認 に多く使われていました。具体的には、DB migrationの検証、複数PRの並行開発時の環境分離、ローカル起動が失敗したときの代替手段などです。 「気軽に立てられる検証環境」が想定を超えてDXに大きな価値をもたらしていた 、ということがわかりました。一方で、 複製できない外部サービスとの付き合い方が実は難しい ということも正直にお話ししました。 preview環境というコンセプト自体は以前から存在し、取り組み事例もオンライン上にいくつかあります。そのため当初は、 あまり新鮮味のない発表になってしまうかもしれない と考えていました。ただ、セッション終了後にブースへ足を運んでくださった方々からは、様々なフィードバックをいただきました。 「実はうちでもリリーストレインで困っているんです」「preview環境を導入したいので、もう少し詳しく構成を教えてください」「DBまで複製するのはよいアイデアですね」 といった声です。こうした反応から、 まだまだ関心の高いトピックである ことがわかりました。 今回の事例が少しでも当日ブースに足を運んでくださった方や、この記事を読んでくださっている方の参考になれば嬉しい限りです。 発表資料は Speaker Deck で公開しています。ぜひご覧ください。 参加を通じて感じたこと 今回のSRE NEXTには、カイポケコネクトの 開発推進チーム を中心に、人事・広報のメンバー、SRE NEXT自体の運営に関わっているメンバーが参加しました。参加者は全員で6名です。ブースの設営や運営を一緒に進めたり、セッションの感想を語り合ったりする中で、リモートワーク中心の日常業務では生まれにくいコミュニケーションが自然とできたのは、 現地参加ならではの価値だった と感じています。 また、来場者のみなさんと直接お話しする中で、改めて実感したことがあります。 「エス・エム・エス」という社名は知っていても、私たちが実際にどんなプロダクトをどんな技術で作っているのかは、あまり知られていない ということです。だからこそ、こうした場で技術やチームのリアルを伝えていくことの意味は大きいと感じています。 「このプロダクトに関わってみたい」「このチームで働いてみたい」と思ってもらえる発信を続けていくことの大切さを、改めて感じる2日間でした。 まとめ Goldスポンサーとしてのブース出展とスポンサーセッション登壇を通じて、SREコミュニティのみなさんとたくさんの対話ができ、私たち自身も多くの学びと刺激をいただきました。 引き続き、技術コミュニティへの貢献と、エンジニアとの接点づくりを大切にしていきたいと思います。ブースに立ち寄ってくださったみなさま、運営スタッフのみなさま、そして一緒に準備・運営を進めたメンバーへ、改めて感謝します。ありがとうございました！

テックブログの編集を担当している髙木です。 テックブログにおける編集という役割はあまり一般的ではないかもしれませんが、記事の質の担保と安定的な投稿を目的に活動していると思っていただくのが良いと思います。以前出した記事がありますので興味のある方はこちらを参照ください。 突然ではありますが、弊社のテックブログがネタ切れ状態です。というのは半分冗談なのですが、これまでよりも記事が出にくくなっている気がしております。そのことについて考えるというのが今回の記事の主題となります。 そもそもテックブログをなぜ書くのか テックブログだけではなく文章を書くということは、外向きの意味と内向きの意味があると思います。 外向きの意味：情報や成果を伝える 個人と企業ではテックブログで扱うテーマは多少異なると思いますが、経験やナレッジの共有が主としてあり、副産物としてブランディングがあると思います。ブランディングを主としてテックブログを運営することもあると思いますが、テックブログと名乗る以上はブランディングが主ではないほうが好ましいとは思っています（これは個人の意見です）。いずれにせよ外向きの意味とは、受け取る人がいることを前提に、情報を受け取りやすい形で提供することだと考えています。 内向きの意味：思考や情報を整理する 内向きの意味として、思考の整理があると思っています。この記事を書くこと自体が「どうしてテックブログを書くんだろうか？」というテーマを見つめ直すきっかけとなっています。つまり書き上げるまでの過程の中でなぜを考え直すことができ、結果としてアウトプットが整っていくと思います。テックブログに出た記事は最終的なアウトプットでありますが、この記事が出るまでにも何度も書き直して推敲している箇所もあります。いろいろ考えて紆余曲折しながら記事が出来上がっていくことで、自分の中の意見がまとまっていく体験自体に価値があります。 情報を読むだけでなく情報を出力しようとすることで、初めて整理できることがあると思います。 なぜテックブログを書くきっかけが減ってきたのか 個人的な考えとして、LLMの登場によるところが大きいと思っています。本当はここでデータを出せると良かったのですが、そのようなデータを取得できなかったので経験をベースに話させてください。 開発で詰まった際の課題の解消が容易になった 以前の記事でもお伝えしましたが、業務の開発はもちろん個人の開発でもLLMに頼って開発を行っています。 課題の解決が容易になるということは、悩むということがそもそも減ります。これまでは技術的な課題に直面した際、GitHub Issueを探したりコードを探索したりして整理しつつ、その整理の結果がテックブログに書き起こされていたと思います。しかしLLMの普及により、課題の解消をLLMとの対話によって行えるようになりました。 課題が見つかる → LLMと対話する → 解決策を選択する → 課題が解消する という流れになります。この体験をブログで共有したいかというと、そういう課題に出会えることはこれまでと比べるとかなり減ったように思います。 記事を書かなくなる大きな理由は、課題を解決するためにかけた努力を「これはわざわざ共有するほどのことではない」と自分で判断することが増えたことだと考えています。「LLMではなく自分が解決の中心になったものを出したい」と考えると、その課題の難易度はより高いものになり、ハードルを超えるものはそれほど書けないようになると思います。もうLLMが絡まない体験を書くことは現実的に難しいと思えるほど、LLMというものは開発の中心になったと感じています。昔、GitHubが落ちれば今日の仕事は終わりというネタがありましたが、今やその対象はLLMになったのですから。 ブログを書くまでもなく深掘れるようになった ブログのような文章を書く整理ではなく、LLMとの対話によって状態を整理できるケースは増えたように思います。これは僕自身の体験ですが、電気における交流というものの考え方が全く理解できませんでした。問題を解くことはできたけどもどういうものなのかがわからず大人になりました。ある日気になってLLMに交流について尋ねました。自分のこれまでの疑問に答えてくれて、交流がどういうものなのかを理解することできました。 これはただの一例ですが、自分のわからないや疑問について対話で回答が得られるようになったとすると、ブログを書くことで整理していた思考は書くまでもなく整理することができます。またLLMの普及により、人との対話も増えたように思います。LLMによって開発のスピードが上がったことで、それをどう処理するべきかやどういうチームを作っていくべきなのかを人を中心に考える傾向が強くなったように思います。これらについては個人ではなくチームで考えることが多いため、ベースになるのは対話が多いと思います。 LLMとの対話だけでなく人との対話を通していろいろな物事が整理され、その結果として文章を書くという整理が不要になった面もあると思います。 このテックブログをどうしていきたいか いろいろ書いたのですが、このテックブログに関して言えば2つです。 1. 会社の雰囲気が伝わる内容が展開される このテックブログは、テックそのものにフォーカスを当てたものは少なく、どちらかというとプロダクト開発にフォーカスを当てたものが多いです。その過程で考え方やプロジェクトの進め方について解像度の高い記事がこれまでたくさん出されてきました。これはエス・エム・エスの雰囲気を象徴する事象の1つだと思います。誤解されたくないのであえて書きますが、技術について想いを持っている人はたくさんいます。そのうえで技術以上にプロセスにフォーカスを当てる人が多いというのがこの組織の特徴だと思います。 なのでテックブログの姿を変えたいというよりは、この雰囲気が続けばよいと思っています。プロダクト開発を通して得られた経験をまとめ、それがこのブログを読んでいる方々に伝わればそれで良いと思っています。 2. 個人の思考が整理される これは僕がブログを書く目的として先ほど挙げたものですが、社員の皆さんにはこのブログを利用して考え方を整理してほしいと思っています。このブログは数名の有志によって運営されております。記事のアイディアや依頼、編集などを実施しています。この記事で何を伝えたいかを執筆者と相談することで書きたいものを一緒に考えて作っています。 思考を整理する方法はたくさんあります。先ほど紹介したようにLLMや人と対話することでも実施できると思います。しかし他の人に伝えたいものがあるならブログというものを通して一緒に作っていければと思っています。僕たちもいろいろなものを読みたいと思っていますし、記事を通して疑似体験できることを楽しませてもらっています。 ここからは社内の皆さんへの呼びかけになりますが、もし書きたいものがあるなら、1on1を依頼するぐらいの軽い気持ちで相談してください。いつでもお待ちしております。 このブログの未来のために何をするか 記事が出にくくなっていることは事実としてあります。だからこそ、それを知ってもらうためにこの記事を書くことから始めました。まずは現状を知ってもらうことが大事だと思ったからです。 このような記事は基本的に社内Wikiに書かれることが多いと思います。今回もそれで良かったのですが僕たちと同じように記事が少なくて困っている人たちもたくさんいると思います。テックブログが更新されなくなってネガティブな印象を持たれないようにしたいと頑張っているはずです。そういう人たちの代弁ができるといいなと思い、この記事をエス・エム・エスのテックブログに載せようと思いました。 もしかすると将来的にこのブログが不要になることもあるかもしれません。でもまだその時ではないと思うので、これからも記事を出せるように頑張っていこうと思います。

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。現在は複数のQAチームに横断的に関わりつつ、チームのサポートや改善活動の推進、組織マネジメントなど幅広い業務を担当しています。 今回は、2026年の春先に立ち上げたQAチームの社内勉強会「AI4QA事例共有会」についてご紹介します。 なぜはじめたのか エス・エム・エスでは全社員が生成AIを利用できる環境が整っており、QAエンジニアもテスト活動や業務効率化へ積極的に取り入れていますが、その使いこなし方はチームや個人に依存しているのが実情でした。 カイポケのQAはフルリモート体制で、普段異なるサービスを担当するチームがそれぞれ独立して動いています。生成AIを駆使しているメンバーがいる一方で、「隣のチームがどんな使い方をしているか」は互いに見えにくい状態でした。チームをまたいでナレッジが共有される仕組みもなかったため、「知っていたら自分も使えたのに」という機会損失が、静かに積み重なっている感覚がありました。 AI活用を組織全体に広げていくために必要なのは、ツールの導入や制度整備だけではなく、「こういう使い方があるんだ」と気づける場だと考えました。そこで、実践的な使い方を横展開しあえる場を作ろうと、今回の「AI4QA事例共有会」を立ち上げました。 会のコンセプト 一言で言うと、 「AI活用術を全力でパクるための会」 です。 ※ここでの「パクる」は、他チームの優れた取り組みを積極的に吸収・横展開するというポジティブな意味合いを込めた言葉として使用しています。 あえて「パクる」という強い言葉を使っているのには理由があります。「参考にする」ではどこか他人事のようですし、「真似する」だと少し受け身な印象を受けます。しかし「全力でパクる」という温度感こそが、この会のスタンスを的確に表しています。 発表者も「参加者に全力でパクってもらうこと」を前提に登壇してくれるため、自然と再現性の高い具体的なツールやプロンプトの紹介が飛び交う場になっています。 難しい理論や綺麗にまとまった導入事例ではなく、「自分の業務で今こう使っている」というリアルな生の話を共有し、参加者が明日から使えるヒントを持ち帰ることをゴールにしています。 会は基本的に発表者＋聴講というスタイルですが、決して一方通行の講義にならないよう、いくつかの工夫を取り入れています。 運営の工夫：Miroで双方向に 発表を聞くだけの場にしたくなかったので、Miroのボードを使って双方向性を持たせています。 🟨 黄色の付箋：感想（すごい！便利！など） 🟦 青色の付箋：質問（これってどうやってるの？） ⬜ グレーの付箋：コメント・気づき 聴講者は発表を聞きながら随時付箋を貼り、質疑タイムではそこから優先的にトピックを拾っていきます。 オンラインの挙手制だと発言のハードルが上がりがちですが、付箋なら「思ったこと」をその場で気軽に書き留められます。そのため、場が温まる前から参加者の反応がどんどん可視化され、盛り上がりを生み出しています。時間切れで拾えなかったものも文字として残るため、後から非同期で確認できる点にも役立っています。 これまでの発表テーマ 実際にどのような話が共有されているのか、発表テーマを一部ご紹介します。 テーマ 概要 生成AIを活用してバグ対応を効率化してみた Slackのバグ報告スレッドを自動でJiraチケット化するツールを作成。試行錯誤の末、うまくいったこと・いかなかったことを正直に共有 シナリオベースのAPIテストをClaude Skillsで実装 テストシナリオの記述・実行をAIで効率化しようとしている取り組みの紹介 Devinを使ったQA業務の効率化 AIコーディングエージェント「Devin」を日常的なQA業務に活用している事例集 QAプロセスにおけるAI活用 実務でのAI利用の具体的な場面と活用方法を紹介 Claude Code Desktopの使用感紹介 実際に使ってみてのリアルな感想と、QA業務での活用可能性を共有 参加者の反応から見えてきたこと 付箋に書かれたコメントを読んでいると、場の雰囲気がよく伝わってきます。 失敗談が歓迎される 「生成AIを活用してバグ対応を効率化してみた」で発表されたSlack→Jira自動起票ツールは、「開発した後にSlack側がAI要約機能をリリースしてしまい、結局あまり使われなくなった」という結末も正直に共有されました。これに対して寄せられた付箋が「実際使ってみての『うまく使えなさそう』って感想、たすかる」という声です。 成功事例だけでなく、試行錯誤や失敗の過程もオープンに話せる雰囲気ができているのは大きな収穫でした。「うまくいかなかった」と言える場であることが聴講者の安心感を生み、実はそういう泥臭い話のほうがリアルで参考になることが多いと実感しています。 「さっさと使わないと」という温度感 「AIの発展で使わなくなるのはよくあるので、さっさと使わないとなと思った」というコメントには「それな」という付箋がすかさず貼られていました。ツールの移り変わりの速さへの共感が、参加者の間で自然と生まれていました。 完璧な使い方を探してから動き出すより、とりあえず試してみてフィードバックを得る、そういうサイクルを回すことへの意識が参加者の間で少しずつ浸透してきている気がします。 「自分もやってみたい」につながる 「自前ツール、ClaudeCode使えばQAでも作れるかな。積極チャレンジしたい！」といったコメントも見られました。発表を聞いて終わりではなく、「自分でも試してみよう」という気持ちに自然とつながっているのは、この会の目的にぴったりな反応でした。 さいごに この会を「ずっと続けること」自体は目的にしていません。目指しているのは、 AIを活用するという文化の醸成 です。発表された内容をきっかけに、各自が自分のチームで掘り下げ、実際の業務へ還元していける、そういうポジティブな循環が生まれることが本当のゴールだと考えています。 私たちのQA組織における生成AIの活用は、まだ始まったばかりです。こうした「QA組織への生成AIの適用」や「新しいテスト文化の醸成」に興味を持ってくださった方、一緒にこれからのQAのあり方を模索していきたいという方がいれば、ぜひカジュアル面談でお話ししましょう！

はじめに はじめまして！株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」のQAを担当している柏尾です。 普段はQAチームで品質保証にかかわる業務を担当しています。 2025年5月ごろから品質保証の業務とは別で、カイポケ開発部内でのMonthly Win Sessionの運営をはじめました。 Win Sessionとは一般的に、メンバーそれぞれが「Win（成果や良かったこと）」を共有し、称賛し合う場です。 運営としての活動開始から約1年程度経過したので、今回はその経緯やどのような活動を実施しているかをご紹介します。 Monthly Win Sessionをはじめたきっかけ エス・エム・エスでは、過去に開発部内横断での情報共有の場や広報誌という良い取り組みをシェアするような場がありました。 いずれも非常に長く続いてきた取り組みで、取り組みが設計された時よりも組織が非常に大きくなっており、職能の多様化も進んできました。 そのため、その意義や良い点は引き継ぎつつ、現在の組織に合わせた再設計を行い、エス・エム・エスのプロダクト開発部が大切にしているバリュー「あなたがコミュニティ」（詳しくは コチラ ）をよりいっそう体現する新しい枠組みとして検討されていたのが「Win Session」という形でした。 Win Sessionのアイデアが持ち上がり、運営メンバーはマネージャー陣からの推薦で声をかけていただきました。 ただ、決して業務として強制されたわけではなく、「興味があるか」「やってみたいか」と丁寧に意思を確認してもらった上で、納得して運営チームへの参加を決めました。こうした個人の意志を尊重してくれるところは、今の組織のいいところだなと感じています。 集まったのは、開発エンジニア、デザイナー、プロダクトオーナー、そしてQAである私の6名です。所属チームもバラバラで、初対面のメンバーも多い中でのスタートでした。 Win Sessionをやろうという方向でスタートしたものの、場の設計などは全て運営チームの裁量に任されています。「やり方は自由に検討していい、予算が必要なら相談もOK」という、かなり自由度の高い状態です。 まずは「自分たちがどうしたいか」を考えるところから、運営チームの活動がはじまりました。 運営チームの熱い想い 運営チームは普段はあまり接点の無い人が多く、お互いの考え方や仕事のスタイルなど、何も知らない人もいる状態でした。 そのため、まずは全員がWin Sessionに期待することや想いを出し合い、考えのすり合わせを行いました。対話を重ねる中で、各メンバーが組織の課題解決に対して、高い当事者意識を持っていることがわかり、このチームで活動していくことへの期待感が高まりました。 この段階では、早くWin Sessionの開催までもっていったほうが良いのではないかと、焦りを感じることもありました。振り返ってみるとしっかり想いを出し合って、丁寧に目的意識をすり合わせたことはとても重要な時間だったと感じます。 1年近く運営してきて会の改善に取り組んでいる中で、意見が食い違うこともありました。しかし最初に方向性をしっかりすり合わせているため軸がぶれず、最終的にはみんなで納得しながら判断できていると感じます。 現在はWin Sessionを「お互いの理解を深め称賛し合うことで、開発部全体のパフォーマンスを高める交流の場」ととらえ、毎回の会を運営しています。 また、目指したい姿として、「取り組みと称賛のループ」「壁を薄く、重力を軽く」という2つを挙げて取り組んでおります。 称賛の場からさらに良い取り組みを呼び、称賛を受ける、そんなループを作りたいと思っています。 また、カイポケ開発部はいくつものチームに分かれ、更にいくつもの職種の人が存在しています。チームの壁、職種の壁を薄くし、お互いの交流を促すきっかけの場にしていきたいという思いがあります。 運営の進め方 運営の進め方として、現在は週1回の定例MTGを実施しています。それ以外の日は資料作成などタスクを持ち帰って進めることもあります。 メンバーの所属チーム・職種がバラバラである分、繁忙期のタイミングも異なるため、各自の業務状況を見ながら可能な人が積極的にタスクを引き受け、分担することができています。 定例MTG自体も業務状況を見て欠席してもよいというスタイルです。 メインの業務の傍らで継続的に運営するために、運営の負荷を減らすことも重要なテーマだととらえており、定例MTG自体の時間を短くできないか試行錯誤したり、テンプレ化できるものはテンプレ化するといった改善も重ねています。 Win Sessionの実際の会では、参加者からのアンケートも回収しており、そのフィードバックや会の盛り上がりをみながらより良い会にすべく模索を続けています。 例えば、Win Sessionをはじめた最初のころは、より多くの発表を聞きたいため、発表時間は5分縛りにする案が上がっていました。しかし実際にWin Sessionをやってみると、質問が盛り上がることもあり、時間を短く縛りすぎるのはかえって会を盛り下げることになるかもしれないという懸念が運営チーム内で生まれました。 そういった状況を鑑みて、現在は月に1時間の会の中で発表本数は2本のみに制限しています。発表自体は1本あたり最大20分程度で残りの時間を質疑応答や深掘りの会話の時間にあてています。 Monthly Win Sessionの発表例 現在はMonthly Win Sessionとしておよそ月に1回の頻度でオンラインで開催しております。参加者は毎回80人を超える会となっています。 様々なチーム・職種の方に登壇いただき、他の組織の活動を知るきっかけにもなることができています。 オンライン開催のため、感想や質問はSlackの実況チャンネルを用意していますが、毎回たくさんの感想や称賛のコメントで盛り上がっています。 実際の発表時のSlack 単に「すごいね」で終わるだけではなく、発表内容を他のチームで取り入れるなど、業務に役立った事例も多数あります。以下では実際の事例をいくつかご紹介します。 「スクラムチームでモブテストをやってみた」 こちらは記念すべき第1回の1発目の発表です。開発エンジニア、デザイナー、QAで集まってモブプログラミングのようなイメージでテストを実施した事例を実例とともに発表いただきました。 発表直後にはもう以下のようなSlackが流れ、他のチームに良い影響が広がっており、運営チームとしてもとてもうれしかったことを覚えています。 取り組みが波及した例 「生成AIを活用したデザイナー協業ワークフローの再構築」 AIを活用してデザイナーがVibe Codingでデザインを組むために、非エンジニアがAI活用するための環境整備を行った取り組みを発表いただきました。 AI活用は弊社内でもトレンドとなっており、他のチームでも同じような取り組みをしようとしていたと声が上がっていました。 とてもホットなトピックで、実況チャンネルがとても盛り上がっていました！ 「非エンジニアが​AIを​使って​開発環境で​開発した​話」 2例目にあげた「生成AIを活用したデザイナー協業ワークフローの再構築」のセッションをきっかけに実施された取り組みについて発表いただきました。 2例目の発表からわずか3か月後に発表までしていただいており、素晴らしい取り組みにとても驚きました。 私たちが目指している「取り組みと称賛のループ」に一歩近づいたことを実感できる事例でした。 課題とこれから目指したいこと Win Sessionは毎回アンケートでも好評をいただいており、良い影響も生み出せていますが、まだまだ課題はたくさんあります。 最も大きな課題はやはり「発表者集めの難しさ」です。 会をはじめてから1年間で、発表の立候補もいただきましたが数自体は少なく、立候補のみで継続して運営することはできていません。 そのため、現在はSlackを活用した他薦・自薦のネタ集めを中心に行っています。 Slackのリアク字チャンネラー機能 を使っており、Winだ！と思ったSlack投稿にWin Sessionスタンプを押すとWin Session用のSlackチャンネルへコピーされるようにしています。 Slackで使用しているスタンプ コピーされてきたものの中から、より関心がある人が多そうなネタを選んで運営チームから関係者に発表いただけないか声掛けを行っている現状です。 ありがたいことに発表の声掛けをして断られた事例は無く（時期が合わないため先の発表にしてほしいなどはもちろんありますが）、みなさん好意的に引き受けてくださり、運営としての心理的な負担もなく、継続していくことができています。 現在の状況でもそれほど負荷なく運営できている事実はありますが、運営から声掛けをして登壇者を募るフェーズは、あくまで自走に向けた準備期間だととらえています。 誰かに頼まれたから話すのではなく、日常の小さなWinを自然に発信したくなるような、そんな空気が醸成されて初めて、Win Sessionは組織の文化として根付いたと言えると思っています。よりカジュアルに、より気軽に参加できる場を目指して、これからも改善を重ねていく予定です。 運営チームに参加してみて ここまで運営の仕組みや課題についてお話してきましたが、最後に運営メンバーとして活動してきた感想にも触れさせてください。 運営を通して何より刺激を受けたのは、全員が常に目的意識をもって意思決定を進めている点です。ただ漫然とWin Sessionの会を開催するだけでなく、常に目的を達成するための会にできているか思考しながら運営を進めています。 私たちが日々取り組んでいるカイポケのシステム開発も同じで、業界の課題をどう解決するか、常に考えながら向き合うことが求められており、その姿勢がメンバーの習慣となっているように感じました。 本業の枠を超えた活動を通じて、「常に目的意識をもって課題解決をする」大切さを再確認できたことが私にとって大きな収穫でした。 また、チームや職能が異なる人と働く面白さも感じました。 弊社では日ごろの業務の進め方はチームの裁量に任せられているため、チームごとの特色があります。今回他のチームの方と長期間働いてみて、そのごく一端ですが知ることができました。 わかりやすい例だと、Miroの使い方ひとつとってもチームごとに特色があり、良いなと思った活用方法はチームに持ち帰って役立てています。 役割の面では、個人的にはデザイナーさんの考え方に触れることができたことが学びにつながりました。現在私が所属しているチームではすでに稼働中のシステムを担当していることもあり、デザイナーさんとお仕事する機会はほぼありませんでした。 今回デザイナーさんと何度も会話する中で、ユーザー目線、受け取り手目線の考え方がとても勉強になり、QAとしてプロダクト品質に向き合う中でも持つべき視点を学ぶことができました。運営チーム内の他のメンバーからも「Win Sessionでぜひデザイナーさんの話を聞いてみたい」という声が何度もあがっていました。 チーム、役割の異なる人と働くメリットを知ることができたので、こういった機会は今後も大切にしていきたいと感じました。 おわりに 私個人としてはこういった大きなイベント運営にかかわったことはほとんどなく、運営に参加することは大きなチャレンジでしたが、今では一歩踏み出して良かったと思っています。 自由に試行錯誤させてくれる社風や、意見を前向きに受け入れてくれるメンバーのリアクションに助けられて、楽しく活動を継続することができています。 この記事を通じて、Monthly Win Sessionの空気感や、エス・エム・エスの空気感が少しでも伝わればうれしいです。

はじめに はじめまして！エス・エム・エスでエンジニアインターンをしている小西です。私は現在情報系学部の4年生で、内定承諾後に「履歴書できるくん」チームに合流しました。 この記事では、3か月間どんなチームに加わり、どんなことを経験して、何を感じてきたかをできるだけ等身大に書いてみます。 所属チームとプロダクト 私はプロダクト開発部人材紹介開発グループに所属していて、「履歴書できるくん」というプロダクトの開発チームの一員として動いています。 このグループは、エス・エム・エスのキャリア事業を支える開発組織です。 キャリア事業領域では、高齢社会が直面する「質の高い医療・介護/障害福祉サービスの提供が困難になる」という社会課題に対し、「医療・介護/障害福祉の人手不足と偏在の解消」に貢献することで解決を目指しています。 医療・介護/障害福祉従事者の不足と偏在を解消し、質の高い医療・介護/障害福祉サービスの継続提供に貢献する キャリア事業 | エス・エム・エス このミッション実現に向けた事業の柱のひとつが人材紹介で、この領域だけで10以上のサービスを展開しています。 「履歴書できるくん」は、その人材紹介事業のなかで生まれたプロダクトのひとつです。 履歴書できるくんとは 履歴書できるくんは、求職者向けの履歴書作成ツールです。スマホのフォームに入力するだけで、レイアウトの整った履歴書・職務経歴書が自動生成されます。作成したデータは求職者と法人を繋ぐ専任担当者であるキャリアパートナー（CP）とすぐに共有でき、添削や修正のやりとりもスムーズにできます。また、完成したらそのままコンビニで印刷して面接先に持参することもできます。 履歴書できるくんができる以前は面接のたびに手書きで履歴書を作り直したり、添削の際も毎回写真を撮ってCPに送る必要があったそうです。Web上で内容を確認しながらやりとりできるようになり、双方の手間が大きく減りました。 tech.bm-sms.co.jp チームと今のフェーズ 私が所属するチームはデザイナーやCS（カスタマーサクセス）、PO（プロダクトオーナー）などを含む少人数構成です。普段のMTGから職種をまたいで意見を出し合える環境で、エンジニアとして実装に閉じず、プロダクトの方向性やUI/UXについて自然に話せる機会があります。 私がチームに加わったのは、基礎機能のリリース直後のタイミングでした。そこからUI/UXの改善にフォーカスしていくフェーズに入っていて、今もそれに取り組んでいる最中です。 また現在、「履歴書できるくん」が使われているのはまだ一部の事業部に限られていますが、これからもっと横展開していこうというフェーズでもあります。個人的には、面白いタイミングで入れたなと感じています。 インターンでの目標 インターンを始めるにあたって、3つ目標を掲げました。 求職者・CPの課題や背景を理解し、「履歴書できるくん」への理解を深める エス・エム・エスの文化への理解を深め、入社後の解像度を上げる 実際の開発業務を一通り経験する また、せっかくチームに配属されたからにはユーザー体験を向上させる機能の追加や改善に少しでも貢献したい！個人開発で経験できないようなことがしたい！という思いもありました。 3か月で経験したこと スクラムで進む開発 開発は2週間を1スプリントとするスクラムで進めています。 アジャイルやスクラムに関しては大学の授業で少し触れた程度の知識しかなかったのですが、スプリントプランニングやレビュー、デイリースクラムに参加しながら、実務の中でその考え方や手法を学ぶ機会をいただいています。 実務での開発を通じて、タスクの背景やユーザーに届けたい価値、受け入れ条件を明確にして最初に目線を揃えることの重要性を実感しました。同じ方向を向けているだけで、議論の進み方も実装の精度も全然違ってきます。 とはいえ、いまだに質問や確認が足りないまま動いてしまって修正を重ねることも多いです。まず自分が理解できていないことを自覚すること、自分の理解を整理してから伝えること、そして適切なタイミングで動くこと。このあたりが今の自分の課題で、少しずつ感覚を掴みながら、もっと丁寧に事前のすり合わせができるエンジニアになっていきたいです。 スプリントレビューでも、自分では気づけなかった視点からの指摘をいただいたり、説明しながらバグや改善点に自分で気づいたりと、毎回何かしらの発見や学びがあります。こうした体験の積み重ねを通じて、スクラム開発がどういうものか、少しずつ掴めてきたような気がします。 データを見て決める開発 日々の開発業務の仕方を学びながら、Metabaseで利用率や利用状況を調べデータをもとにチームで議論して実装につなげる経験もさせていただきました。絶対使ってほしいし、ユーザーの9割は使っているでしょう！と思っていた便利機能が実は思ったより使われていなかったり、自分では想像もできない利用方法をしているユーザーがいたりと、感覚だけに頼らず定量的に評価することの重要性を肌で感じました。 ユーザーの声に触れる 「履歴書できるくん」では、CSの方々がCPからの意見を集約して届けてくださっていて、それが改修や改善につながっています。また定期的なアンケートも実施してくれていて、そこからも意見を吸い上げています。 中には「最高のツールを作ってくれてありがとうございます！」といった温かい声もあり、まだ携わって3か月しか経っていないですが、とても嬉しく思います！！ またリリース後、自分が実装した機能についてお問い合わせが来ることも何度かありました。内心ヒヤヒヤしながら内容を見るのも実務ならではの緊張感で、自分の実装に誰かが反応しているという事実が責任感とやりがいにつながっています。「実装不備じゃなかった…！」と安堵することもあれば、「その挙動は本当に想定外で…」と悔しい思いをすることもあり、ユーザー理解が実装の質に直結するということを、こういった体験を通じて痛感しています。 エス・エム・エスで感じたこと スピード感に毎回驚かされる ちょっと相談したことやスプリントレビューで出た改善点がその場でチケットになって、翌日や次のスプリントには実装が動き出している、なんならリリースもされる、という場面が何度もありました。判断からアクションまでのラグが本当に小さく、毎回驚かされます。小さな提案も自然と開発に乗っていく空気があり、3か月でも「実装してリリースして反応を見る」というサイクルを何度も体験させていただけたのは、このスピード感あってこそだと思います。 ユーザーを起点に話すことができる どの議論にも共通しているのは、判断の起点がいつもユーザーにあることです。職種を問わず、メンバー全員が「これは本当に使う人のためになっているか」を考えながら話していて、ユーザーに真摯に向き合う姿勢がチーム全体に当たり前のように根づいているように感じます。 まさに「こういうチームで働きたかった！」と思える理想的な環境で働かせていただいているなと毎日感じています。こうした方々と日々議論を重ねながら、自分もユーザー起点で考えられるエンジニアに、少しずつ近づいていけたらと思っています。 好奇心がそのまま学びになる 自分から学びに行こうとすれば、それを支える資料や機会が用意されています。Slackで「〇〇してみたいな〜」と何気なくつぶやいただけなのに「こういう説明会がありますよ！」と教えてくださる方がいたり、メンターさんとの1on1でも、できるくんの歴史やそれ以外のプロダクトの事など気になったことを聞くと、1時間以上話し込んでいることもあります。（いつも大変お世話になっております…！）インターン生だからと話を簡略化されることもなく、毎回本気で答えていただけるのが本当にありがたいです。 3か月のなかで「これを経験してみたい」「これを学びたい」と思ったことは、ほとんど実現させていただけました。そもそも、このチームに配属していただけたこと自体がその一例です。受け入れてくださったチームのみなさん、配属に関わってくださったみなさんに、改めて感謝申し上げます。 また、エス・エム・エスは掲げるミッションが大きい分、向き合っている領域も広いです。やってみたい仕事や挑戦できる場所が次々と出てくるので、好奇心がますますくすぐられる場であるなと感じています。 好奇心旺盛で、気になったことは何でも学びに行きたい、新しいことを知ることに喜びを感じる、というタイプの人にとっては、最高の環境だと思います。 穏やかさの中に熱意を感じられるチーム 就活中からずっと感じていたのですが、エス・エム・エスのみなさんは本当に話しやすくていい方ばかりです。役職に関係なくフラットに話せる雰囲気もあり、入ってからも変わらず、日々の仕事のなかでより実感しています。色々な社員さんと1on1させていただく中で、同時期に入社した方と「エス・エム・エスっていい人しかいなくないですか！？」と盛り上がるくらい、出会う方どなたも落ち着いていて、優しい印象でした。 とはいえ、雰囲気がぬるかったり、士気が低かったり、コミュニケーションが少なかったりするわけでは決してなく、ここまで書いてきた通りみんなバシバシ意見を言い合える環境でもあります。穏やかな雰囲気の中に熱意を感じる。そんなみなさんと一緒に働きながら、自分も自然と引き上げてもらっているなと感じる毎日です。 ここまで色々書いてきましたが、この雰囲気は文章ではどうしても伝えきれないと思っているので、少しでも気になっていただけた方はぜひカジュアル面談などでみなさんに会いに来てみてください！ 3か月を振り返って 最初に掲げた3つの目標を改めて振り返ってみます。 求職者・CPの課題や背景を理解し、「履歴書できるくん」への理解を深める エス・エム・エスの文化への理解を深め、入社後の解像度を上げる 実際の開発業務を一通り経験する 1つ目と2つ目は日々のチームメンバーとの議論や社員さんとの交流から、3つ目はスクラム開発やデータ分析など日々の業務から、それぞれ学ばせていただきました。 まだ手探りな部分も多いですが、〇△×で言えば、どれも〇に近いところまで達成できたと思っています。 自己評価 インターン生として、ただタスクをこなすだけでなく、社員のみなさんとの交流を通して会社やプロダクトについて多くのことを学ばせていただけたのは、3か月での大きな収穫でした。 エンジニアとしてまだ課題は多く残っていますが、チームの一員としてユーザー体験向上のための議論に参加したり、タスクに取り組んだりと、自分なりに貢献できたかなと思っています。 働き方の面では、基本的に週3日・各日8時間、フルリモートで働かせていただいています。「学生のうちにもっと遊んだほうがいいよ」「旅行行ったほうがいいよ」と声をかけてくださる方も多く、1週間休みを取って旅行に出かけたこともありました。また、来年から社会人になることもあって、お金のことを何も知らないのはさすがにまずいなと思い、インターン期間中にFP3級の勉強を始めて先日合格通知を受け取りました。（今は2級に向けて勉強中です）こんなに自由に過ごさせていただきながらも、就業時間中はギアを上げてしっかり働くということを意識してきた3か月でした。 今後取り組みたいこと ここまでは短期集中で動く3か月だったので、今後は「長期的に働くとしたらどう動くか」というところも意識していけたらと思っています。 経験面でもやってみたいことが沢山あります。一番は、実際にサービスを使ってくださっている求職者の方の声を、ユーザーインタビューなどで直接聞いてみることです。CPを介して届く声も嬉しいですが、生の声をプロダクトや自分の開発にちゃんと反映していけるエンジニアになりたいです。 また、新しいドメインや言語に触れる機会をいただけた一方で、自分のWeb開発の知識の浅さや技術力のなさを痛感する3か月でもありました。ライブラリの使い方や構文を覚えるといった表面的な部分よりも、その背景にある仕組みや基礎的な知識こそが、これから求められていくと感じています。これからは手を動かす実装だけでなく、もう一度基礎/基本に立ち返ってじっくり学ぶ時間も取っていきたいと考えています。 おわりに 気づけばインターンを始めてから3か月が経ちました。 与えられたタスクをこなすだけで完結する3か月ではなく、コミュニケーションの仕方やプロダクトへの向き合い方まで、色々なものを吸収できた時間でした。 この経験を糧に、これからもプロダクトとチームに貢献しながら、エンジニアとして成長していきたいと思います。 最後になりますが、メンターさんやチームのみなさんをはじめ、採用でお世話になったみなさん、そしてこれまで関わってくださったすべての方々に心から感謝申し上げます。本当にありがとうございました！これからのインターン期間も、2027年4月からも、どうぞよろしくお願いします！ 興味を持ってくださった方へ このレポートを読んで、少しでもエス・エム・エスが気になった方がいたら、本当に嬉しいです。エンジニア新卒インターン（28卒）の募集も行っているので、まずは気軽に応募やカジュアル面談から、ここに書いた雰囲気を感じてみてもらえたらと思います。 エンジニア新卒インターン応募（28卒）| 株式会社エス・エム・エス エンジニア採用 | エス・エム・エス

こんにちは。プロダクト開発部の髙木です。 今回はAIコーディングエージェント向けのコードエディタである Superset の紹介になります。公式では『The Code Editor for AI Agents』と紹介されており、Claude CodeなどのコーディングエージェントをGUIから扱えるデスクトップアプリです。現時点ではmacOSのみの提供ですが、公式ドキュメントではWindows・Linuxも近日対応予定とされています。 僕はマウス操作によるGUIに慣れているため、自分にあっているツールを探そうとしたときにフィットするツールが見つけられませんでした。同じような悩みを持つ方の参考になればと思います。 これまでの自分の開発 これまでの開発では主にVisual Studio Code（VSCode）を使用しておりました。開発する言語にもよりますが、VSCodeは開発に必要なベースが整っており、足りないものについてはプラグインによって拡張できる優れた統合環境です。基本的にはVSCodeで完結できるため、VSCodeで開発できるように環境を整えていました。 現在の自分の開発 もう自分でコードを書く頻度は激減しClaude Codeと対話してコードを出力する毎日です。個人的にはこの開発方法は肌にあっています。コードの設計方針などを対話をしつつ進められるため、具体的な実装をClaude Codeに移譲できることで、その方向性が正しいかを常に考えながら成果物を見ることができます。自分で考えながら作っていると検討漏れが起きやすかったのですが、ドライな目で実装を眺められるので成果物の質は上がったように思います。 つまり現在は、もともと開発環境に求められていたエディタに入力するための思考や入力のしやすさではなく、出力されたものを確認したり修正を依頼するレビューベースの開発を行っている状況です。さらに複数のリポジトリを並行で作業できるような作業的な余裕も生まれ、加えて同一リポジトリ内で並行して作業するケースも増えてきました。そうなってくると1ブランチ1画面のVSCodeでは、作業したいリポジトリに対して行き来する画面が多すぎて本来の作業以外に画面の整理のような雑務が発生する状況になっていました。もしかしたらVSCodeにそういった拡張機能があるかもしれませんが、ちゃんと調査までは行えていません。 こういうときにキーボードベースの開発に慣れていればtmuxで画面分割をしつつタブで画面を変えるなどの作業ができたのかもしれません。そういう意味で cmux はそういう人には向いているツールだと思います。 cmux自体は『AIコーディングエージェント向けの縦タブと通知機能を備えたGhosttyベースのmacOSターミナル』と説明されており、CUIベースでの開発が好きな人には合うと思います。 AIによる開発で求めていた機能 GUIで操作できる 複数のリポジトリを行き来できる 同一リポジトリの複数ブランチで並行作業ができる コードのdiffが確認しやすい コードを確認できる これらができるツールを探しており、たどり着いたのがSupersetでした。 GUIで操作できる 基本的な操作はGUIをベースで実行できます。ここはあまり掘り下げるポイントがないので割愛します。 複数のリポジトリを行き来できる リポジトリを追加することができ、左側のタスクバーに追加したリポジトリが表示されます。クリックすることで簡単に切り替えることができます。これも複雑な機能ではないため割愛します。 同一リポジトリの複数ブランチで並行作業ができる 各ブランチをワークスペースという概念で扱っています。公式では、 Each workspace = one git branch. と表現しています。左側にタスクバーが表示されており、そこからマウスクリックでリポジトリやワークスペースを切り替えることができます。 公式トップの画像を引用 良きポイントとして各ワークスペースが独立しているため、AIエージェントのコンテキストが混ざらずに使用することができます。Workspace自体はGit Worktreeで管理されていますが、利用者がそれを意識する必要はなく+ボタンを押すことで追加することができます。追加時にブランチ名やプロンプトを入力することでそのまま作業を開始してくれます。 コードのdiffが確認しやすい VSCodeを使用していたこともあり、ツール内でdiffを確認したいと思っていました。 difit を使うことも考えていましたが、スキルを使ったりアプリケーションを立ち上げることに手間を感じていたのでできれば内蔵が良いと思っていました。リッチなものではありませんが、必要十分な機能だと思いました。 コードを確認できる エージェントが作ったコードを見る際に、簡素なコードをシンタックスハイライトつきで見られれば良いと思っていました。Claude Codeが表示したファイルパスをCmd+クリックで表示することができるので、簡単な確認であれば十分です。このあたりの機能はVSCodeと同様でした。 使ってみて気づいた利点 ソフトウェアのアップデートでも作業が中断しない ソフトウェアアップデートをすると大体のツールが再起動となり、これまでのコンテキストが失われます。もちろん --continue などのパラメータをつければコンテキストを復活できますが、バックグラウンドで起動していたアプリケーションなどの接続は失われるため、作業していたものを復旧することができません。しかしこのツールはアップデートをしたとしても作業を自動で復旧してくれます。具体的にどのような仕組みなのかまでは追っていませんが、アップデートが億劫にならないというのは他のツールではあまり感じたことがありませんでした。 作業のスピードが上がった 1つのリポジトリにおいて並列で調査をしたりすることが増えたことで、こなせる作業量が増えたように感じます。これまではブランチの切り替えにおいて自分で管理していたこともあり、簡単にGUIで作業できるようになったことは別ブランチでの作業の億劫さを軽減してくれました。これまではstashしたものがどこにいったかわからなかったり、作業に戻ろうと思ったときに戻れない事が多かったので、ズボラな自分にあった作業のしやすさだと思います。 Supersetだけで完結しない部分とその割り切り コードをちゃんと読もうとしたとき、僕としてはコードジャンプが必須です。VSCodeでできていたコードジャンプが、Supersetでは（おそらく）できませんでした。ちゃんと調査はしていないのでもしかしたらできるかもしれません。 困っていない理由としては、コードジャンプでコードを確認するためだけにVSCodeを開くからです。SupersetにはIDEなどで開くためのリンクが設置されているため、機能不足は普段使っているツールで解消することができます。足りない機能をいつも使っているツールに流せるため、思っていたよりもストレスも低く移行できました。最初は全てのツールをこなせるものを考えていましたが、得意なことを得意なツールにやらせたほうがストレスもたまらないと思いました。 まとめ 簡単にですがSupersetについて書きました。これまで開発に求められていた機能とは異なり、並列性や切り替えのしやすさなどが求められる時代になったと思います。作業の仕方を変える必要はありませんが、自分にあったツールを使っていくことで作業のやりやすさも変わると思いました。 個人的にはSupersetで得られた体験が非常に心地よかったので、皆さんにも一度試してもらいたいです。

はじめに はじめまして。人材紹介開発グループで管理栄養士・栄養士向け人材紹介サービス「エイチエ 転職」のWeb開発を担当している吉村です。 本記事では、私が所属する開発チームと、集客を担当する企画チームが合同で実施したサービス改善の取り組みとして、バリューストリームマッピングを紹介します。 バリューストリームマッピングとは バリューストリームマッピング（Value Stream Mapping、以下VSM）は、顧客にサービスが届くまでの業務プロセスを可視化し、ムダな待ち時間や手戻りなどの課題を見つけるための手法です。 開発チームだけでなく、企画チームなどの関連部署が一緒に可視化することで、課題に対する共通認識を持ち、改善をスムーズに進めることができます。 実施の背景 私たちのサービスでは、次のような課題がありました。 タスクの目的や背景のすり合わせに時間を要し、タスク着手までに待ち時間が発生 ユーザーレビューとコードレビューの観点が標準化されておらず、判断のばらつきによる手戻りが発生 企画からリリースまでのリードタイムを見通しづらく、施策の進捗状況を把握しにくい これらは以前から企画・開発間で漠然と認識されていましたが、どのように改善するかを明確に決めることができていませんでした。 この状態を改善するために、開発チームと企画チームで合同のVSMミーティングを実施することにしました。 進め方 今回は、事前準備と当日のVSMミーティングを次の流れで進めました。 事前準備 VSMミーティング前に、企画からリリースまでの流れを時系列で図に起こす その図を参加者に事前共有し、工程に過不足がないか確認してもらう（ほかに工程があれば追加してもらう） 参加者に、各工程の課題と改善案を事前に記載してもらう VSMミーティング当日 一連のフローを全員で確認し、各工程の所要時間、待ち時間を話し合いながら算出する 課題と改善案を確認したうえで、チームとしての改善施策を決定し、優先度付けを行う なお、各工程の所要時間や待ち時間は、厳密な時間での計測が難しいため、0.5日単位で多めに見積もって設定しました。 VSMミーティングで作成したVSM図（イメージ） 詳細な内容は伏せていますが、以下のように「フロー」「課題」「改善案」を並べて可視化しました。 結果 VSMを通じて課題に対する共通認識を持てたことで、取り組むべき改善施策を明確にできました。 以下では、改善施策の内容と、数か月運用した後に得られた結果を紹介します。 1. 各工程間の待ち時間を短縮 改善内容：各工程間の待ち時間を減らすため、半日以内に返事がない場合は担当者に個別連絡して確認を促す運用に 結果：確認待ちによる滞留が減り、工程間の流れがスムーズになった 2. タスク起票時の品質担保 改善内容：考慮漏れや対応内容の不明確さ、認識のずれを防ぐため、タスク起票時のフォーマットを用意し、起票後は企画側と開発側の担当者が確認する運用に 結果：企画・開発間での仕様確認のやり取りが減り、手戻りも減少した 3. 進行状況の可視化 改善内容：利用中のタスク管理ツールで、ユーザーレビューとコードレビューを子課題化し、開始日と期限日を明示する運用に 結果：企画側でもタスクの進行状況を把握しやすくなり、施策運用での意思決定がしやすくなった 4. レビュー観点の統一 改善内容：テスト仕様書のマスターを整備して必須確認項目を明確化し、タスクごとの確認内容を追記したうえで、ユーザーレビューとコードレビューを行う運用に 結果：レビュー観点がそろったことで、動作確認漏れや認識のずれに起因する手戻りを減らせた 継続実施で得られた変化 1回目の実施から数か月後に同様のVSMミーティングを再実施し、リードタイムをあらためて算出しました。 その結果、企画からリリースまでのリードタイムは、第1回の11日から第2回では9日となりました。2日（約18%）の改善が確認できました。 うまくいった点・難しかった点 うまくいった点 事前に各工程の課題と改善案を洗い出してもらっていたため、当日のVSMミーティングは短時間でも論点を絞って進められた これまでは改善に関する相談が個人間で完結しがちだったが、VSMミーティングの場で可視化して議論したことで、チーム全体で共通認識を持てた 個別に見えていた課題の背景に共通原因があると分かり、同じ解決策で複数工程の課題を解決できた 企画と開発それぞれの目線で課題を出し合ったことで、一方の視点だけでは見えにくかった新たな視点を得たうえで、より具体的に議論できた 難しかった点 各工程の時間を正確に把握するのは難しく、とくに実装工程はタスクの種類が多様で、所要時間のばらつきが大きかった 加えて、タスク管理ツールの運用ルールが十分に整備されておらず、ツール上のデータを十分に活用できなかったため、リードタイム算出が難しかった 最後に VSMに取り組んだことで、課題を解決するだけでなく、企画と開発が同じ前提で改善を議論できる状態をつくれました。 また、第2回の実施を通じて、工程単位の改善だけでは解消しきれない課題も改めて明確になりました。 具体的には、各工程の待ち時間や手戻りを減らす取り組みに加えて、改善対象を課題設定や施策検討の段階まで広げて考える必要があることをチームとして再認識しました。 そのため今後は、フロー構造そのものの見直しに加え、タスクの質の向上やサービスの方向性の整理にも、企画と開発で連携しながら取り組んでいきます。 最後までお読みいただきありがとうございました。

はじめに はじめまして、2025年10月に入社したエンジニアの池田です。入社してあっという間に半年が経ちました。日々の業務に追われていましたが、節目ということで一度立ち止まって振り返ってみようと思います。転職の経緯や入社後の実感について紹介していきますので、転職を検討されているエンジニアの方にとって少しでも参考になれば幸いです。 自己紹介 私はプロダクト開発部人材紹介開発グループに所属しています。エス・エム・エスが3社目で、これまでは受託開発会社でエンジニアをしていましたので初めて事業会社で勤務することになります。 1社目は新卒から約6年SIerに在籍し、バックエンドの設計・実装からプロジェクト管理まで幅広く担当していました。2社目は小規模な受託開発会社に2年半勤め、フロントエンドの開発をメインに担当しつつ、バックエンドの開発にも携わっていました。現在、エス・エム・エスでは ケア人材バンク というケアマネジャー・相談員・障がい福祉向けの転職エージェントサービスの開発に携わっています。 なぜ転職したのか 前職での経験は充実していましたが、受託開発である以上、構造的に解消しづらい課題もありました。具体的には以下の3つです。 スクラム開発ができなかった 顧客との契約や納期の都合上、開発プロセスはウォーターフォールが基本でした。アジャイル開発に近いプロセスを取り入れることもありましたが、イテレーションが1か月程度と長期になりがちで、アジャイルのメリットである柔軟性の恩恵はあまり受けられませんでした。 テストコード実装に十分な時間を割けなかった 納期とコストが優先される環境では、テストコードを充実させたくても見積もりに含まれていないため十分な時間を割けず部分的な実装にとどまる、という状況でした。テストが整備されていない既存のコードに後からテストを追加することも、工数の観点から難しい状況でした。テストがないことで機能改修やリファクタリングがしづらく、開発のしにくさを感じる場面が多くありました。 リアーキテクチャができなかった 既存システムへの制約が多く、大胆な改善に踏み出せない場面が何度もありました。「こう設計し直せばもっと良くなるのに」と思いながら、手をつけられないもどかしさを感じていました。 これらの課題を解消することは、単に開発体験を改善するだけでなく、より良いプロダクトを継続的にユーザーへ届けることにつながると考えていました。医療・介護という社会を支える領域で、それを実現できる環境として現職を選びました。転職活動の中でエス・エム・エスと出会い、技術ブログの内容や選考過程を通じて「エス・エム・エスなら3つとも実現できそうだ」という確信が高まっていきました。 実際に働いてみて 前述した3つの課題が、現職ではどのように変わったかを紹介します。 2週間スプリントで自律的に開発を進める 私が所属するチームは2週間スプリントで開発を進めており、スプリントプランニングでは関係部署とバックログの優先度を擦り合わせながら、チーム自身でそのスプリントでやることを決めていきます。レトロスペクティブも定期的に行われており、チームの課題を率直に話し合いながら改善を続けていく文化が根付いています。何をいつやるかをチーム自身で決められる裁量感は前職では味わえなかったもので、開発への主体性が自然と高まっていくのを感じています。 テストが文化として根付いている 現職では、テストコードはPRを出す際の前提条件として扱われています。コードレビューではテストの網羅性や設計も当然のようにチェックされ、テストのないPRはマージされません。こうした文化の中で開発を進めることで、テストコードに対する解像度が上がり、その恩恵をすぐに実感しました。特に大きかったのは、「テストがあるから安心してリファクタリングできる」という感覚で、前職ではコードの改善に踏み出すのが怖く、結果として負債を放置するしかありませんでした。テストという安全網があることで、リファクタリングへの心理的ハードルが大きく下がりました。 大胆な改善が当たり前に行われる 現職に入って驚いたことのひとつが、技術的負債への向き合い方です。前職では考えられなかったような大胆な改善が、ごく普通に行われています。「このままでは将来的に問題になる」という判断があれば、きちんと工数をかけて改善するという意思決定がなされます。技術的負債の解消が「やれたらいいね」ではなく「やるべきこと」として扱われている環境は、エンジニアとして非常に働きやすいです。 転職前から継続できていること 転職を経ても、前職から継続できていることもいくつかあります。 社会貢献性の高い領域への関わり 新卒でSIerを選んだ理由のひとつに、行政・インフラ・金融・医療といった社会を支える領域に携わりたいという気持ちがありました。転職にあたってもこの点は妥協したくなく、現職が医療・介護業界向けにサービスを提供している点が入社の決め手のひとつでもありました。ケアマネジャー向けの転職エージェントサービスという形で、引き続き社会的意義のある仕事に携われていることは、日々のモチベーションに直結しています。 働き方 転職にあたってフルリモートにこだわっていたわけではありませんでしたが、現職もフルリモートが基本で、結果として前職と同じ環境を継続できています。必要なときにオフラインで顔を合わせることもできますし、所属する部署では半年に一度全員が集まるオフラインイベントもあり、普段リモートで働いているメンバーと直接交流できる機会があるのも良いと感じています。 入社してから半年間でやってきたこと プロダクト開発のリード ケア人材バンクの開発チームでは、開発リードを担当しています。仕様の整理から実装方針の決定、スプリントのゴール設定など、開発全体を見渡す役割です。入社してこれほど早くリードを任せてもらえるとは思っていなかったので、最初はプレッシャーもありました。ただ、チームメンバーや周囲のサポートもあり、少しずつ自分なりのスタイルが掴めてきた気がしています。 コミュニケーション改善チームへの参加 開発業務と並行して、Communication Hubという部署内のコミュニケーション改善を目的としたチームにも参加しています。私が入社した際に感じたオンボーディングの課題を共有し、次に入社される方に向けたオンボーディングプロセスの改善に取り組みました。エンジニアとして開発だけでなく、組織をより良くするための活動にも関われる環境は、入社前には期待していなかった部分でした。技術以外の側面でも会社に貢献できる機会があるのは、個人的にとても充実感があります。 カンファレンスへの参加 社外の技術カンファレンスであるPHPerKaigiにも参加しました。会社としてブースを出展し、来場者と交流しながら自社の認知を広げる側にも関われたことは新鮮でした。普段の業務では得られない知見や刺激を受けられ、エンジニアとしての視野が広がる良い機会になりました。会社として技術コミュニティへの参加を後押ししてくれる文化があることは、エンジニアとして継続的に成長していく上でとても心強いです。 これからやっていきたいこと 開発リードとしての成長 開発リードとして任せてもらえていることはありがたい一方、まだ手探りな部分も多いのが正直なところです。仕様調整や実装方針の決定をより的確にこなせるようになることはもちろん、チームが自律的に動けるような開発プロセスの改善にも積極的に関わっていきたいと思っています。 サービスの品質向上 機能開発と並行して、パフォーマンス改善やサービスの安定性向上にも取り組んでいきたいと考えています。ユーザーが快適に使えるサービスを継続的に届けるために、技術的な改善を地道に積み重ねていくことを大切にしていきたいです。 社外への情報発信 PHPerKaigiへの参加を通じて、インプットだけでなくアウトプットも増やしていきたいという気持ちが芽生えました。カンファレンスでの登壇や技術ブログの執筆など、社外への発信にも積極的に挑戦していきたいと思っています。 おわりに 入社して半年、転職前に感じていた課題はすべて解消され、思い描いていた環境で働けていることを実感しています。これからも学び続けながら、プロダクトとチームに貢献していきたいと思います。

はじめに こんにちは。人材紹介開発グループでエンジニアをしている熊谷です。 ここ1年ほどで、AIを使うこと自体はかなり当たり前になってきました。人材紹介開発でも同じで、「使うかどうか」よりも「どう安全に、どう再現性高く使うか」のほうが重要なテーマになっています。この記事では、社内で実施したAIコーディング勉強会の内容を軸にしながら、現場での導入状況や、普段の取り組みを紹介したいと思います。 エス・エム・エスのコーディングエージェントの現状 会社として「特定のエージェントを」「どのくらい使ってよい」という縛りはなく、各々が必要と感じているサービスを申請し、それらを利用する形になっています。例えば私はもっぱらCodex（ChatGPT-5.4）を愛用しつつ、ローカルではClaude Codeと連携するようにしていますし、Pull Request上ではGitHub Copilotがレビューをします。そのほかにも社内ではCursorを利用している方もいますし、OpenCodeと特定のLLMを組み合わせて使う人もいます。 もちろん新規のサービスを利用するには事前申請・審査が必要ですが、使いたいという要望に可能な限り答えてくれるような環境が揃っているな、と感じます。 まず、現場でどれくらい使っているのか 勉強会をすることになったきっかけとして、社内でコーディングエージェントは一般的に使われていることをslack等で観測していました。一方で互いにどのように使っているかをsyncする場がなかったため、 @kenjiszk と相談し勉強会を開催することにしました。 勉強会の冒頭では、参加メンバーに簡単なアンケートを取りました。回答者は19名です。 「業務でコーディングエージェントを利用していますか？」という質問に対しては、「ほぼ全ての業務で利用している」が63%、「一部で利用している」が36.8%でした。少なくとも今回の参加者に限って言えば、まったく使っていない人はいませんでした。人材紹介開発では、すでにAIの活用が特別な試みではなく、日常的な前提になっていると言えそうです。 用途として多かったのは、設計の壁打ちとコーディングです。実装そのものを任せるだけでなく、仕様の整理や方針検討の相手として使っているメンバーが多いのも印象的でした。 普段使っているエージェントツールとしては、Claude CodeとGitHub Copilot系が多めでした。一方で利用モデルはかなり収束していて、Opus 4.6やGPT-5.4系を使っているメンバーが多い、という結果でした。 最後に現在のコーディングエージェントに対する感想です。「もうこれがないと厳しい」という声もあれば、「なくても何とかなるけれど、あるとやはり速い」という声もありました。温度差は多少あっても、AIをまったく使わない状態には戻りにくい。そんな空気感で勉強会はスタートしました。 勉強会で最初にそろえたかった前提 今回の勉強会では、いわゆる「AIがすごい」という話よりも、その性能を現場で引き出すための土台にあたる部分を中心に扱いました。 スライドではこれをHarness Engineeringの入口として紹介しています。AIそのものを賢くする話ではなく、AIを安全に、安定して使うための運用設計の話です。いま主要なコーディングエージェントは、単にモデルが優秀かどうかだけでなく、AGENTS.md、Skills、MCPやCLIといった周辺の仕組み込みで使われるようになっています。 勉強会でも、まずはこのあたりの基礎知識をそろえるところから始めました。 AGENTS.md は「最初に効かせたい前提」を置く場所 AGENTS.mdには、そのリポジトリでエージェントが最初に知っておくべき前提を書きます。 たとえば「このリポジトリはpnpmを使う」「生成ファイルは直接編集しない」「スキーマ変更時にはmigrationが必要」といった情報です。価値観やお気持ちを書くというより、次の行動が変わる事実を書くほうが効きます。 人間にとっては暗黙知になりがちなことでも、AIにとっては明示されているかどうかで挙動がかなり変わります。このあたりを雑にせず、最初の入口で分岐ルールを渡すのが大事だよね、という話をしました。 Skills と MCP は「再利用できる判断」と「実行の接続境界」 もうひとつ勉強会で触れたのが、SkillsとMCPの位置づけです。 Skillsは、特定のタスクに対してどう判断し、どう進めるかを再利用できる形にしたものです。うまく作れば、他人のベストプラクティスをかなり高い精度で再現できます。個人的には、コーディングエージェントを使いこなすうえでかなり重要な要素だと思っています。 一方でMCPは便利な反面、サーバー側が公開する仕様を読み込んでから使い方を判断する構造なので、対象によってはトークン消費が重くなりがちです。そのため、最近は公式のCLIがあればそちらを優先する、という流れも強くなっています。 このあたりはツールごとの差も大きいのですが、少なくとも「モデルの性能だけ見ていればよい時代ではない」という認識を合わせるのが今回の狙いでした。 セキュリティ 勉強会開催時点の2026年3月13日は、コーディングエージェントにおけるセキュリティの話題が特に多かったこともあり、このテーマは厚めに扱いました。セキュリティといっても話はさまざまに広がりますが、今回は特に話題の多かった「シークレットの取り扱い方」をベースにしています。 基本方針はシンプルで、 「漏れた後で止める」より「そもそも見せない」で設計する ことです。AIに安全設定を入れること自体は大事ですが、それだけで守り切れる前提には立っていません。AIから見えてしまう状態を作らないこと、見えたとしても被害が最小限になる構成にしておくことを重視しています。 たとえば、repo内に平文の .env を置くことを前提にしません。社内では1Passwordを使って秘密情報を共有するのが前提なので、平文の秘密情報を直接AIに触らせないようにする。少なくとも「普通に作業していたら見えてしまう」状態は避けるべきだ、という話をしました。実際にハンズオンも行い、CLIを介して実行時に秘密情報を外部から埋め込むやり方も確認しました。 さらに、開発環境と実行環境を分離する考え方も共有しました。AIが触る開発環境と、人間が秘密情報を扱う実行環境を分けておけば、物理的に環境変数へ触れない構成に寄せられます。devcontainerのような仕組みも、この文脈ではかなり相性がいいです。 もちろん、AIに秘密を見せないようにしても、AIが書いたコード側から秘密が出力されてしまえば意味がありません。そのため、commit前に検知する仕組みも重要です。勉強会では、lefthookやsecretlintを使って決定論的に防ぐ考え方にも触れました。 このあたりは、人材紹介開発としてかなり大事にしているところです。AIを積極的に使うからこそ、安全寄りの運用ルールやガードを先に整える。そこは候補者の方にも安心材料として伝えたいポイントです。今回の勉強会で完璧に網羅はできているとは言えませんが、それでも最低限やっておきたいことは共有できたと思います。 個人的なおすすめツールとモデルの話 勉強会の後半では、少し肩の力を抜いて、個人的な（かなり偏見の入った）おすすめも紹介しました。 参加メンバー全体で見るとClaude Code利用者はかなり多いのですが、私はCodexやGPT-5.4が結構好きです。コストと性能のバランスがよく、きちんと指示したときの手堅さもあって、普段の開発ではかなり使いやすいと感じています。 スライドでも少し冗談っぽく話したのですが、Opus 4.6とGPT-5.4は、優劣というより味付けが違う印象です。Opus 4.6はよしなに色々やってくれる一方で、GPT-5.4はシンプルに言われたことを淡々とこなしますと感じています。この違いは好みの問題でもありますし、用途によって向き不向きもあります。ただ、モデル選定も含めて「どう使うと気持ちよく働けるか」をチームで共有できるのは、勉強会の良いところだと思っています。 ※ 勉強会→記事の執筆の間でCursorではすでにComposer 2がリリースされており、情報が古くなっている点にご注意ください。 あわせて、おすすめのSkillsや、野良のMCP / Skillsを安易に入れないといった運用ルールも共有しました。便利そうに見えるものをすぐ入れるのではなく、公式のものや信頼できるものを選ぶ。判断に迷う場合は社内でレビューする。このあたりも、安全にAIを使い続けるうえでは外せないポイントです。 勉強会だけで終わらせず、日常的に相談できる場を作っている 人材紹介開発では、勉強会を単発イベントで終わらせないことも意識しています。 AIに関する雑談や相談をする時間を意識的に取り、最近気になったニュース、試してよかったツール、うまくいかなかった使い方、困りごとの相談などを持ち寄っています。きっちりした発表会というより、かなり気軽な共有の場です。 こんな感じで雑談ネタをまとめていて、話したいこと・聞きたいことをリストアップしてます。 専用のSlackチャンネルもあり、「こういうときはどう使うのがよさそうか」「この運用で危なくないか」といった話を日常的にできるようにしています。 AIの活用は、個人が一人で頑張るだけだとどうしてもムラが出ます。だからこそ、使い方をオープンにし、うまくいったことも失敗したことも共有できる場を持つことが大事だと考えています。 おわりに いまのソフトウェア開発では、AIを使うこと自体はかなり当たり前になりました。人材紹介開発でも、その前提は同じです。 一方で、私たちが本当に大事にしているのは、「とにかく速く書ける」ことだけではありません。安全に使えること、再現性高く使えること、チームで学びを共有しながら前に進めること。そのあたりまで含めて、開発の仕組みとして整えていこうとしています。 これからエス・エム・エスに興味を持ってくださる方や、選考中の方にとって、現場の雰囲気が少しでも伝わればうれしいです。AIを積極的に使いながら、同時に安全性や運用もちゃんと考える。そんなチームに関心があれば、ぜひカジュアルに話しましょう。