はじめに こんにちは、エス・エム・エスでエンジニアインターンをしている、佐藤墾です。 半年間インターンをして、この会社についてわかったこと、感じたことを書き残します。 エス・エム・エスに興味を持っているけど、どういう組織かイメージがわかない。そんな方に向けて、この会社が大切にしていること、何を重要視しているかをインターン生の目線で書いてみます。あくまで僕のチームでの話ですが、雰囲気が伝われば嬉しいです。 そもそも私がいたチームは？ 私はカイポケコネクトの開発推進チームに参加しました。カイポケコネクトは介護/障害福祉事業者向けの経営支援サービスで、開発推進はカイポケコネクトの開発基盤やツール整備を担当するチームです。 そこで私はツールの導入提案や不要なコードの整理など、開発体験の改善に関わる仕事をしていました。 働き方について 大学の研究と両立する必要があったので、融通のきくシフトで勤務していました。 私は地方に住んでいたので基本はフルリモートでした。出社しても社員さんもリモートなので人が集まることは少ないですが、もちろん呼んだら来てくれます。 受け入れ体制について チームではレトロスペクティブで振り返りを行っていましたが、自分から気軽に相談するのがまだ得意ではありませんでした。フルリモートだと特にそうで、話しかければ答えてくれる環境ではあるものの、オフィスなら「ちょっといいですか」と相手の様子を見て声をかけられるのに対して、リモートだと相手の状態がわかりません。メンションすると通知が飛ぶので集中を削いでしまいそうで申し訳なく感じたり、返信がいつ来るかわからなかったり。これは自分がリモートでの立ち回りに慣れていなかったのもあると思います。 そこでメンターと週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を積極的に使いながら、同時に安全性や運用もちゃんと考える。そんなチームに関心があれば、ぜひカジュアルに話しましょう。

はじめに 初めまして、キャリア事業の人材紹介サービスでプロダクト開発をしている松尾です。 新卒6年目の2025年10月頃から、PdM（プロダクトマネージャー）としてのキャリアにチャレンジしています。 成果を出すどころか、思った以上にうまくいかないことの方が多く、四苦八苦している毎日です。 それでもこの経験を通して、 PdMとして価値を届けるとはどういうことなのか チームの共通理解を作ることの重要性 プロジェクトの方向性を示すことの難しさ など、多くの学びを得ることができました。 この記事では、エンジニアがPdMにチャレンジする中で感じた 「プロダクトを通してユーザーに価値を届ける難しさ」 について、自分なりの学びを整理してみたいと思います。 PdMに挑戦することになったきっかけ PdMに挑戦したいと思ったきっかけは、昨年度に参加した Web履歴書プロジェクト でした。 tech.bm-sms.co.jp 弊社人材紹介サービスは、キャリアパートナー（CP）が求職者との対話を通してより最適な事業所とのマッチングができるようにサポートしています。 それまで私が担当していたのは、求職者がサービスに登録するための入り口となる 集客チャネルとしてのWebアプリケーション でした。 求職者をCPに送客するのがメインの役割です。 一方、このプロジェクトで開発したのは、求職者がCPと接点を持ち、実際に転職活動を進めてから利用される 履歴書作成のWebアプリケーション です。 この2つの開発経験を通して、人材紹介サービスの見え方が少し変わりました。 それまでは 集客のためのプロダクト 履歴書作成のプロダクト のように、それぞれを独立したプロダクトとして捉えていました。 しかし実際には、 集客 → 求職者と事業所のマッチング → 入職 → 入職後のフォロー までが一連の体験としてつながっています。 つまり、人材紹介サービス全体が1つのプロダクトであり、私たちが作っているWebアプリケーションはその中の一機能に過ぎない、という見え方に変わったのです。 この視点の変化が、PdMとしてプロダクト全体の価値を考えてみたいと思ったきっかけでした。 そうした中で、 求職者体験の向上をテーマにした新規プロダクト を立ち上げる話をいただき、PdMとしてチャレンジさせてもらうことになりました。 エンジニアとPdM の視座の違い PdMに挑戦して最初に気づいたのは、 エンジニアとPdMでは価値を思考する上での視点が違う ということでした。 PdMとしての最初の提案は、 「求職者の入力データを一元管理する仕組み」 でした。 この提案に対するPO（プロジェクトオーナー=このプロジェクトの最終責任者）やチームメンバーからのフィードバックはシンプルでした。 『点の話すぎて、結局何を実現したいのかわからない』 最初は何がダメなのかわかりませんでした。 上司やシニアPdMと会話する中で、自分の思考が Howに寄っている ことに気づきました。 エンジニアとしての仕事を振り返ると、 その課題をどう解くか どう実装するか というように、 How（どう作るか） を考えることが価値でした。 一方でPdMの仕事は、 ユーザーのどんな課題を解くのか その課題を解くために、何を作るのか を定義し、 プロダクトの価値を最大化 することが求められます。 そのために、 Why（なぜそれを作るのか）とWhat（何を作るべきなのか） という問いを立て続けることが重要なのだと学びました。 目的やゴールの重要性 もう1つ強く感じたのが、 目的やゴールを定義することの重要性 です。 PdMとしての最初のミッションは、求職者体験の向上をテーマにした新規プロダクトの構想でした。 私たちが改善したい事業課題や、それを解消するためにどのような体験設計ができると良さそうか、こういった点の整理はある程度できました。 しかし、実際のユーザーの解像度が低かったため、ここまで整理してきた内容が本当に価値のあるものなのかがわかりませんでした。 そこで、私たちが価値提供したい層の求職者に対して実際に案内されているアンケートをweb化し、web上の動向やアンケートの回答結果などを踏まえて価値探索を行おうと考えました。 CP組織やマーケ組織と協力しながらwebアンケートを実装し、一部エリアでのトライアルも良好で正式リリースまで漕ぎ着けました。 しかし、この活動を振り返ると出発点に課題がありました。 具体的にどんな価値を検証したいのか この施策で何を明らかにしたいのか この取り組みは何をもって成功とするのか といった、プロジェクトの目的やゴールを十分に整理しないまま動いてしまっていたのです。 その結果、新規プロダクトの構想とアンケートweb化の取り組みの関係が曖昧になり、最終的にプロジェクトの方向性を見失ってしまいました。 目的やゴールが明確でないプロジェクトでは、 メンバーごとに解釈が変わる 優先順位がズレる 進めば進むほど方向性がブレる といったことが起こります。 目的やゴールを定義することは、プロダクトを作っていく上で 迷った時に立ち返れる拠り所となる場所を作ること なのだと学びました。 自分の意思を強く持つ 今回のチャレンジを通して一番強く感じたことは、 PdMは言われたことを実行する役割ではない ということです。 プロダクト開発では、 事業側の要望 ユーザーの要望 チームの要望 など、様々な意見が出てきます。 その中でPdMは、 「このプロダクトではこの価値を実現する」 という方向性を示し、チームを導いてプロダクトを牽引していく必要があると考えています。 つまりPdMは、単に開発の管理をしたり各部署との調整役を担当するのではなく、 自分の意思で人を動かし、プロダクトを作っていくファシリテーターとしての役割 なのだと実感しました。 今回の私は、課題整理や各所との調整まではできても、「自分はこういう価値を実現したいんだ！」と強い意思を持って方向性を示すことができませんでした。 その結果チームが迷走し、結果的にプロジェクトの軸が定まらないまま進んでしまったのだと振り返っています。 おわりに 今回の経験を通して、エンジニアとして価値を作ることと、PdMとして価値を作ることの違いを強く感じました。 エンジニアとして価値を作るときは How（どう作るか） を考えることが中心になります。 一方でPdMとして価値を作るときは Why（なぜ作るのか） What（何を作るのか） という問いを解き、チームを導いていく必要があります。 そこには、想像していた以上の難しさがありました。 まだまだ試行錯誤の途中ですが、この経験を糧に、 「プロダクトを通してユーザーにどんな価値を届けたいのか？」 を追求し、実際に価値を届けられるよう挑戦を続けていきたいと思います。

はじめまして。2025年11月にエス・エム・エスへ入社した岡本です。入社後は、カイゴジョブエージェントの開発チームでエンジニアとして働いています。 この記事では、これまでやってきたことを少し振り返りつつ、入社してから見えてきたことを書いてみます。 あわせて、今チームで進めていることや、これから目指したいことにも触れます。 同じように新しくチームに入る方や、課題の多い環境でプロダクトやチームを少しずつ良くしていくことに面白さを感じる方に、読んでもらえたらうれしいです。 これまでの経験 前職では、EC領域でカートや決済まわりを担当するチームにいました。 扱うドメインは、今の人材紹介領域とはかなり違います。ただ、ユーザーがどんな課題を抱えていて、それを解消するにはどんな価値を届けるべきかを、職能に関係なく議論できる雰囲気がありました。 エンジニア、デザイナー、PdMがそれぞれの立場から意見を出し合いながら、どうすればプロダクトをもっとよくできるかを前向きに考えていく。自分にとっては、とてもいい環境だったし、エンジニアとしてだけでなく、人としても成長できた時間だったと思います。 自分自身も、ただ実装するだけでなく、チームで改善を積み重ねながら価値を届けていくことにずっと関心がありました。カイゴジョブエージェント開発チームに入ってからも、その延長線上にいる感覚があります。 エス・エム・エスを選んだ理由 エス・エム・エスへの入社を考えたとき、いちばん大きかったのは全社ミッションへの納得感でした。 高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける。これは誰かが取り組むべき課題であり、しかも短期的に答えが出るものではありません。 だからこそ、仕事として腰を据えて長く向き合う意味があると思えました。解決する意義のある大きな社会課題に、プロダクト開発を通じて関われること。それが、エス・エム・エスに入りたいと思った一番の理由でした。 入社して感じたこと 入社してすぐに感じたのは、カイゴジョブエージェントが単なる機能開発ではなく、チームの進め方そのものを改善していくフェーズにあるということでした。 前職にも課題はありましたが、エス・エム・エスに入社した当初は、特に組織やチームの進め方に関する課題を強く感じました。担当するプロダクトが明確に分かれていないことで認知負荷が高くなっていたことに加えて、マーケティング部門と開発が、ユーザーへの価値提供を同じ目線で最速最大化していくための関係性や進め方にも、これから整えていく余地があるように見えていました。 ただ、それをネガティブには捉えていませんでした。課題が多いからこそ変えていける余地があるし、自分たちで少しずつ良くしていける面白さがあると思えたからです。 実際、エス・エム・エスには、良い変化なら前向きに取り入れていこうとするカルチャーがあると感じています。完成された仕組みに乗るというより、よりよい形を模索しながらチームで前に進んでいける感覚がありました。 チームの変化と、今感じている手応え この数か月で、カイゴジョブエージェント開発チームの体制や進め方にはいくつか変化がありました。 その中でも特に大きかったのが、担当するプロダクトごとにチームを分けたことです。将来的な統合を見据えて1チーム体制を取っていた一方で、実際にはアーキテクチャやフェーズの違いが大きく、認知負荷の高さが改善スピードに影響していました。 そこで、まずはプロダクトごとに集中しやすい状態をつくった方が良いと考え、自分から必要性を提案し、メンバーや上長と話しながら進めていきました。 分割後にいちばん変わったのは、やはり認知負荷の低さです。スイッチングコストが減って、「今どの課題に向き合うべきか」がかなりクリアになりました。技術的な負債や開発基盤の改善も、以前より進めやすくなったと感じています。 もうひとつ大きかったのが、マーケティング部門との関係です。もともとやりとりは多いチームですが、入社当初は開発とのあいだに少し距離があるようにも見えていました。 ただ、最近はユーザー起点で改善を考える流れが少しずつでき、そのための場も整ってきました。以前よりずっと前向きに議論しやすくなってきた印象があります。 入社後に自分が取り組んできたこと ここまではチーム全体に起きていた変化について書いてきました。ここからは、その変化の中で自分がどんな形で関わってきたかを振り返ってみます。 入社してから今までのあいだで、自分が関わってきたことは大きく3つあります。 開発を前に進めるためのキャッチアップ まずは、チームやプロダクトの状況を理解することから始めました。新しく入った立場だからこそ、どこに認知負荷があり、何が進みやすさを阻害しているのかを丁寧に掴もうとしていました。 特に最初は、外部サービスであるSalesforceに依存している部分の理解に苦労しました。自分にはSalesforceの経験がなかったので、前提知識のないところから全体像を掴む必要があったからです。 もうひとつ大きかったのは、チーム内のナレッジ共有がまだ十分ではなく、知識が属人化している部分があったことです。たとえば同じエラーに見えても、どれくらい緊急性があるのかを判断しづらく、最初のうちは感覚を掴むのに手間取りました。 ただ、チーム内のコミュニケーションが増えていく中で、そうした知識も少しずつ聞きやすくなっていきました。2025年12月上旬にはオフラインのチームビルディングも実施し、お互いの強みや価値観、理想のチーム像を共有する時間も持ちました。 この場をきっかけに、プロダクトをよりよくしていきたいという思いをチームであらためて共有できましたし、メンバー同士の距離も縮まったと感じています。少しずつですが、気軽に聞ける空気感もできてきたのだと思います。 2025年12月のチームビルディングで使用したボード 改善活動や開発プロセスへの関わり カイゴジョブエージェント開発チームでは、機能開発だけでなく、よりよく開発できる状態をつくることも重要なテーマでした。 その中で自分も、レビューしやすい粒度を意識したPRの出し方をしたり、AIを活用した開発の進め方を試したりしながら、技術的な負債の整理や開発基盤の改善に関わってきました。 特に印象に残っているのは、チーム分割で生まれた変化を一時的なものにせず、実際の運用や開発の進め方に落とし込んでいったことです。 入社してまだ間もないタイミングでも、いろいろ挑戦させてもらえる雰囲気があったのは印象的でした。上長やメンバーも提案を前向きに受け止めてくれて、どうすれば現実的に試せるかを一緒に考えてくれました。 また、レビュー文化づくりにも取り組んできました。デイリーでレビューを優先することのメリットを伝え、レビューしやすい粒度でPRを出すことをチームの共通認識にしていきました。 その結果、レビュー待ちで作業が止まりにくくなり、PRを小さく出す意識も浸透してきたと感じています。PRマージのリードタイムが改善してきたことも、その変化が少しずつ形になってきた表れだと思っています。 ユーザー理解を起点に考える動きへの参加 自分が入社後に特に面白さを感じているのが、マーケティングと開発が一緒にユーザー理解から優先順位を考える流れに参加できていることです。 今カイゴジョブエージェントで進めていることのひとつが、求職者像を具体化し、カスタマージャーニーを整理しながら、今どこに取り組むべきかを考えることです。 ユーザーストーリーマッピングのような形も使いながら、ユーザー起点でプロダクトについて考え、改善につなげていこうとしています。 特に、マーケティング部門と開発の合同で行っているプロダクト戦略会議を通じて、以前より同じ方向を向いて議論できる感覚が強くなってきました。入社当初に感じていた距離も、こうした場を重ねる中で少しずつ縮まってきているように思います。 戦略会議の中で面白いのは、エンジニア視点とは違うマーケティング部門の見方に触れられることです。ユーザーの感情や意思決定の流れ、ペルソナの解像度の高さには学ぶことが多く、同じプロダクトを見ていても着眼点がかなり違います。 開発チームが単に要件を受け取るだけでなく、ユーザーにどんな価値を届けたいのかまで踏み込んで考える。その大切さを、ここであらためて実感しました。こうしたコミュニケーションの積み重ねが、よりユーザー理解の解像度を上げながらプロダクト改善に向かっていける土壌をつくってくれているのだと思います。 これから目指したいこと カイゴジョブエージェントが目指しているのは、単に求人を紹介するサービスであり続けることではありません。 求職者にとって、 今の不満を整理する 本当に転職すべきかを考える 働く現場を高い解像度で理解する 納得して意思決定する 入社後も前向きに働き続けられる ところまで一貫して支えられるプロダクトに近づけていきたいと考えています。 そのためには、まず継続的に改善を広げていくための共通基盤の整備が必要ですし、求人紹介の前後も含めてユーザーを支えられる体験づくりも必要です。 自分自身も、引き続き開発を進めやすくするための改善にも関わっていきたいと思っています。 そのうえで、これから特に力を入れていきたいのは、ユーザー理解を起点にした開発です。チーム内の改善や技術的な負債の解消は、プロダクトをよくしていくための土台です。その土台の上で、ユーザーが本当に感じている課題に向き合い、よりよい体験として届けていきたいです。 おわりに 2025年11月に入社してからの数か月は、カイゴジョブエージェント開発チームの変化の中に飛び込みながら、プロダクトとチームの両方に向き合ってきた時間でした。 課題はまだたくさんあります。でも、それを悲観的には見ていません。課題があるからこそ変えていける余地があるし、その変化をチームでつくっていけることにやりがいを感じています。 エス・エム・エスには、良い変化に対して前向きに協力していけるカルチャーがあると思っています。だからこそこれからも、ユーザー理解を起点にしながら、プロダクトをもっと良くしていきたいです。 その先で、エス・エム・エスのプロダクトや事業が大きな社会課題の解決に寄与していくことに、大きな面白さを感じています。 こうした課題や向き合い方に少しでも興味を持ってもらえたら、うれしいです。いつか一緒に働けたら、なおうれしいです。

エス・エム・エスで開発を担当している髙木です。 今回は社内向けの書籍レビューサイトをClaude Codeで作った話と、運用してみてわかったことを率直に共有します。技術書の購入制度は世の中に広く受け入れられており、社内にあった形で運用されていると思います。よりよい活用を目指すためにレビューサイトを作ってみたという内容になっているため、同じ関心事を持っている方に読んでいただければと思います。 書籍購入制度について 弊社には書籍購入制度があります。 tech.bm-sms.co.jp これは福利厚生ではなく業務に必要な投資という位置づけで、かなり頻繁に利用されています。 tech.bm-sms.co.jp この制度を使っている身としては、以下の感覚がありました。 誰がどの本を買っているかが見えにくい よく買われている本がわからない 購入した本からどういうインプットが得られたかを聞く機会がない 誰がどの本を購入したかをスプレッドシートで管理されていたため、この情報を活用しようと考えました。記載されていた情報は、以下の6つでした。 No. 購入日 購入者の氏名 書籍タイトル 購入先のURL 購入サイト 最初考えていたのは統計を取ることでした。それだとどういう本が買われているという傾向だけがわかり、情報を活かせるイメージが湧きませんでした。それならば本の情報を投稿できる機能としてレビューサイトのような機能をもたせたら面白くなりそうと思い、社内用のレビューサイトを作ろうと思いました。 社内用のレビューサイトに価値はあるのか？ 価値はあると考えていました。技術書の評価は、個人だけでなくチームの状況やコンテキストに大きく依存します。もちろん一般的なレビューサイトも参考になると思いますが、「自社の開発環境で役立つか」という観点では情報が不足しがちです。クローズドな環境であれば、企業内のコンテキストを前提としたレビューが投稿できます。「うちのプロジェクトではこう活用できた」といった実用性の高いレビューが集まるのではと考えました。またレビューの投稿のハードルも一般的なレビューサイトに比べると低く、投稿したことがない人も投稿できるような環境が作れるのではと考えていました。 もともと私が持っていた課題感を解消する面もあったため、レビューサイトの価値は高そう！という感覚がありました。 スプレッドシートに登録されたデータによる技術的な制約 冒頭でスプレッドシートがつかえそうという話をしましたが、実はこのデータをそのまま使うことにはいくつか課題がありました。 課題1：利用者の情報が氏名しかない このスプレッドシートにはユーザーの情報に関して氏名の情報しかありません。基本的にユーザーをユニークにする際、IDを付与したりメールアドレスを付与することが多いと思います。今回登録されている情報が氏名しかないため、氏名をベースにシステム設計を考える必要がありました。登録される情報自体を調整するという話もあるのですが、他部署が絡むことと今回のアプリケーションの価値が確認できていない中で運用の変更を依頼することに抵抗感があったため現状のスプレッドシートで進めることにしました。 さすがに氏名の入力自体は信頼性の高いものを使用したいため、Google認証を利用してアプリケーションを作ろうと考えました。弊社の社員はGoogleアカウントを持っているため、認証周りはすべてGoogleアカウントによせれば棚卸しなどの管理業務からも解放されるので一石二鳥でした。 課題2：本の情報がユニークではない このスプレッドシートに書かれている情報はタイトルと購入先のURLです。レビューサイトとしては書影などを使用したいため、これらをGoogle Books APIから本の画像や著者名を取得しようとしたとき、本のタイトルで検索をかけると異なる本を取得してしまうケースがあります。また記録されたタイトルに誤字があったりするため、それらの本が別の本として登録されてしまいます。 これらを回避するか許容するかはアプリケーションに求める品質次第ですが、今回は重複登録されることを許容しています。それぐらい本をユニークにするというのは面倒だったため、重複されることを前提としてアプリケーション設計をしました。 これらを踏まえたときに、認証方式とアプリケーションとしての設計が決まりました。商用サービスだったら絶対に許容できない設計ですが、社内限定だったら許容できるラインで設計を考えました。厳密にやろうとすると大変なところも、許容できるラインで作れば手がからなさそうでした。 Claude Codeでの実装 実装にはNext.jsを採用し、コードはすべてClaude Codeに書いてもらいました。実装期間は約2か月です。ただし業務の合間に進めていたので、注力すればもっと短期間で作れたと思います。体感的には1週間ちょっとぐらいだと思います。今だともっと早くできるかもしれないです。アイディアを形にするまでの期間が圧倒的に短いのは、LLMを活用する大きなメリットです。ひとりでプロダクトを作りつつ、情報の整理と実装の担当を分けられるのも良さだと思いました。 Google Cloudでインフラを組んだ経験がなく不安な面もありましたが、AWSを例に上げつつプロンプトを組むことで着実に組み上げられていきました。もともとある知識を別のインフラにも適用しつつ、構成管理もスムーズにできました。 一方で、生成されるコード量が多すぎてレビューがどんどん大変になっていきました。人間がボトルネックになりますが、同時にストッパーでもあります。このバランスを取っていかないと、Claude Codeを主体とした開発は難しいと感じました。最終的に説明責任を果たすのは人になるため、すべてを理解した状態を作るのか一定の信頼をおいてレビューの頻度を減らすのか、そのあたりのバランスを考え続けていく必要があると思いました。 作ってみたもののレビューが少ない… 構築したレビューサイト自体はよくできたと思っています。しかしほとんどレビューは投稿されませんでした。 悲しい気持ちは全くなく、やっぱりそうだよなぁという感覚が強いです。なぜなら僕自身もレビューを投稿できていないからです。 レビューを投稿するのは難しい レビューとして文章を書くとなったとき、本をどの程度読んだら投稿して良いものでしょうか？ 目次だけ読んで書く 特定の章だけ読んで書く 全体を流し読みして書く 最後までしっかり読んで書く 人によってその本に期待するものは大きく違います。そのため本からの学び方も人によって異なり、その結果としてレビューの内容やタイミングも変わります。 つまり人によって書きたい内容やタイミングは異なります。この辺りがアプリケーションから提示されないと、自然と「最後までしっかり読んで書く」が前提となり、書くほどではないという感想になり書かなくなってしまうと思われます。したがってレビューの投稿タイミングを制御できていなかったことは、アプリケーションの思惑と実態がずれてしまってよくなかったと思っています。 改善するなら 今回うまく軌道に乗らなかったことを受けて、どういった改善をするのかをいい機会なのでこのタイミングで検討してみます。 改善案1:ステータスを追加する 「読み始めた」「読んでいる」「読み終えた」だけでなく、「途中でやめた」「積んでいる」といったステータスも含められると良いと思います。やめてしまった理由や、途中まで読んだ感想も立派なレビューになります。ステータスに応じて投稿できる内容を変えることで、完読しないと投稿できないという心理的なハードルを下げられると思っています。 たとえば「途中でやめた」ステータスでは、「どこまで読んだか」「なぜやめたか」だけを書けるシンプルな入力欄にする。「読んでいる」ステータスでは、気になったフレーズや章ごとのメモを気軽に残せるようにする。こうした設計であれば、本を読む過程そのものがレビューの素材になり、読み終えてからまとめなければという義務感が薄れると思います。 改善案2:もっと存在を知らせる そもそも社内における認知度が低く、書くハードル以前に認識されていないことで利用されていない可能性もあります。Slackで一度宣伝した程度なのでもっと存在をアピールするなどの活動は必要かもしれません。社内Wikiに使い方を書いたり、このサービスの思想を伝えたりすることは必要だと思いました。 個人的には付加価値を高めていったあとにしないと二の舞いになってしまうと思うので、利用者が少ないことを活かして改善活動を優先させようとは思っています。 レビューが投稿されればそれで良いのか？ ここはなんとも言えないポイントだと思いました。ハードルを下げるということで質が下がっては意味がないと思います。とはいえ、何も価値のないサイトに人が訪れるほど暇ではないですし、訪れたからには価値を提供する必要があると思います。そういう場だからこそ自分でも価値を提供したいと思えると僕は考えています。 でも何もない状態のところに「レビューを投稿してください」というのは、ハードルが高く難しいのは事実です。なのでそこのハードルを下げつつも、投稿されているものに意味がある・価値がある状態を目指していくのが良いと思いました。 レビューサイトのもうひとつの目的 実はこのサイトにはもうひとつの目的がありました。 以前の記事で書いた「自発的に書きたい人が出てくる仕組みづくり」の一環として考えていました。 tech.bm-sms.co.jp テックブログで記事を書くには、文章を外部の人にもわかる形で構成する必要があります。書籍レビューという比較的カジュアルな場で文章でのアウトプットに慣れてもらい、テックブログへの橋渡しにできればと考えていました。 今回作成したアプリケーションでは、その目的に至る前段で止まってしまったので、もっと活発に使われるようになった先で改めて考えていこうと思いました。 最後に 動くアプリケーションを作るのが簡単になった一方で、使ってもらうことの難しさは変わっていないと思いました。社内という限定的な場ですら難しいので、世の中にアプリケーションを普及させていくハードルは変わらず高いのだろうと想像しました。 まだまだ足りないアプリケーションではありますが、もう少しメンテナンスしていってどう転ぶかを見ていきたいです。またテックブログで報告すると思います。

はじめまして、プロダクト推進本部カイポケ開発部でエンジニアをしている木野と申します。 2025年1月に入社し、あっという間に1年が過ぎました。 入社して感じたこと、育児をしながら働いてみてどうだったかを中心に振り返っていこうと思います。 現在エス・エム・エスに興味をお持ちの方の参考になれば嬉しいです！ ドメイン知識の習得と現場を知る大切さ 複雑な制度をシステムに落とし込む 私は介護事業者向け経営支援プラットフォーム「カイポケ」の障害福祉分野の開発に携わっています。 介護や障害福祉の事業所は、国が定めた制度に則って運営されています。 そのため私たちが開発する際も「行政から出される資料を読み解き、正しくシステムに反映すること」が何より重要になります。 制度、特に報酬算定（お金の計算）のルールは非常に複雑で、考慮すべきパターンや例外処理の難易度がとても高いです。 私は以前歯科向けの電子カルテ開発をしていた経験があり、厚生労働省の資料を読むことには多少慣れていました。ですが実際に障害福祉の分野に入ってみると、歯科とは考え方が異なる部分も多く、1年経った今も日々試行錯誤しています。 例えば歯科は「何をやったか（診療単位）」が基本ですが、介護や福祉は「誰が、どんなことを、何時間提供したか」といった要素の組み合わせで計算が変わります。 この「算定パターン」をどうシステムに落とし込むかを考えるのは、悩む場面が多いです。 ただこの難しさは同時に面白い部分でもあります。 制度の変更は現場のニーズや社会情勢が反映されたものです。資料を読み込み、落とし込んでいく作業を通じて、社会課題に向き合い、取り組んでいる実感が持てるのはこのドメインならではのやりがいだと感じています。 現場を知る 入社して早い段階で、実際の放課後等デイサービス事業所を訪問する機会をいただきました。 現場のスタッフの方々からお話を伺い、実際の忙しさや、業務上まだまだアナログが多い現状を直接目にすることができました。 本来の業務である「利用者への支援」に集中するため、事務作業を効率化する必要がある。 それを肌で感じたことで、自分が作っているシステムが解決すべき課題が明確になり、開発に向き合うモチベーションが高まりました。 実際の現場を見た後は、画面の入力方法を検討する際も「現場の入力負荷が増えないか？」「実際の業務フローとして不自然ではないか？」と、 解像度を上げて考えられるようになりました。 現場を知ることは、業務の解像度を高めるだけではなく、エンジニアとしての視点を広げるためにとても大切だと実感しています。 こうした事業所見学や体験を通じて現場を知る機会は社内に定期的にあり、 現場の「肌感覚」を大切にできる環境は非常にありがたいなと思っています。 「なぜやるのか」という文化 入社して一番驚いたのは皆さんのスキルの高さ、開発部全体に根付いている「なぜこれをやるのか」を考える意識の高さでした。 単に「どう実装するか」という技術的な話だけでなく、「なぜこれをやるのか」「なぜこの修正が必要なのか」「それによって誰がどう幸せになるのか」という問いかけをとても大切にしています。 もし自分の考えがぼんやりしていれば、納得いくまで前提から丁寧にすり合わせをしてくれます。 このおかげで、ブレることなく進められた場面が多くありました。 最初はレビューで「なぜこの実装にしたのか？」と問われても、言語化できずに固まってしまうこともありました。 チームのメンバーは、単に正しい書き方を教えるのではなく、「どういう理由でこの形にしたのか」という意図を根気強く引き出そうとしてくれました。 そのおかげで目先のコードの書き方だけではない、開発の根底にある「考え方」の大切さに気づくことができました。 この文化はコードレビューや設計の場だけでなく、チームの運営や方針を決める際にも徹底されていると感じます。 納得できないことがあればオープンに質問でき、それに対して「なぜこれを行うのか」を納得いくまで議論しています。 「なぜやるのか」を全員が徹底していることで、「誰のどんな助けになるのか」が明確になり、より誠実にプロダクトに向き合えているのだと感じています。 日々どうすればもっと良くなるかを考え抜いている皆さんをみて、1年経った今、私も自然と「なぜやるのか」を自問自答できるようになってきたと感じます。 今後は私もそんな風に、誰かの視界をクリアにできる存在を目指していきたいです。 モダンなツールとチームの支え 実際の開発業務では、本格的なJavaの開発は初めてで戸惑いもありました。 それでも、AIツールの活用やチームメンバーによる丁寧なレビューに助けられ、無事にいくつかの案件をリリースできています。 最近は、AIを日々の実務にうまく取り入れる流れが活発です。 個人としては、テストコードの作成やセルフレビュー、ドキュメント作成など日常的な作業の各所で活用しています。 チームとしても共通で使える各種設定を作成したりと、効率化がどんどん進んでいます。 先日もチーム間でAI活用の情報交換会が行われました。 「具体的なプロンプトをどう工夫しているか」といった現場ならではの共有が多く、非常に参考になりました。最新情報の共有もSlackなどで日常的に行われており、ツールを使いこなしながら、より本質的な設計や議論に時間を割こうとする自然な雰囲気があると感じています。　　 子育てとフルリモートワーク 「家族優先」が当たり前の空気感 私は現在、未就学児2人の育児中です。 入社直後は「急な欠勤や早退で迷惑をかけるのではないか」と心理的なハードルを高く感じていました。 その不安をオファー面談でお伝えしたところ、入社前に子育て中のエンジニアの方々とお話しする「座談会」を設けていただけました。 育児している時間が減るが、技術的なキャッチアップはどうしているか 急な休みはどう調整しているのか お迎えで1度抜けたり柔軟な勤務は可能か といったリアルな話をフランクな雰囲気で聞けたことが、入社を決める大きな安心材料になりました。 実際に働いてみると、開発部全体に「家族や自分の体調を最優先にする」空気が文化として根付いているのを実感します。 例えば、子供が急に発熱して中抜けや欠勤が必要になった際も、チームの皆さんが「お大事に！」「家族優先」と、当たり前のようにフォローし合える環境があります。 入社直後、メンバー数名体調不良で不在だった時期がありました。 その際も「お互い様だから無理せず休もう」という空気感が徹底されており、新入社員としての心理的なハードルがすっと下がったのを覚えています。 フルリモートで働くこと フルリモートと聞くと、コミュニケーションや情報のキャッチアップに不安を感じる方も多いかもしれません。 実際、社内には膨大なドキュメントやアウトプットがあるため、最初は情報の多さに圧倒されることもありました。 ただ、次第にすべてを完璧に追うのはやめて、esaの検索を工夫したりAIツールで要約したりと、自分なりのハンドリング術を模索するようになっています。 この情報の取捨選択スキルは、この1年で得た意外な収穫のひとつです。 Slackでのコミュニケーションも驚くほど活発です。 子育て中のメンバーが集まるチャンネルや趣味のチャンネルなど、業務外のつながりも多いため、リモート特有の孤独感を感じることはほとんどありません。 加えて、日々の業務における連携のオープンさも、大きな安心感につながっています。 例えば、メンションをつけていない独り言のような投稿に対しても、誰かがさっと解決策を提示してくれたり、類似案件を教えてくれたりすることがあります。 困ったときはすぐに「ハドル（音声通話）しようか」と声がかかるので、自宅で一人悩んで孤立することもありません。 程よい距離感の交流会もあり、オンライン越しでもチームのつながりをしっかりと感じられています。 終わりに 1年を振り返ってみました。 改めてエス・エム・エスに入社して良かったと感じています。 業務解像度が上がってきた今、新しいことにチャレンジをしながらさらに頑張っていきたいと思います。

こんにちは、エス・エム・エスでプロダクト推進本部人事をしている韓（ @ssket0809 ）です。 2026年3月20日〜22日に開催された PHPerKaigi 2026 に、エス・エム・エスがスポンサーとして参加しました。ブース出展もおこない、多くのエンジニアの方々と交流させていただきました。 phperkaigi.jp イベントスタッフの皆さん、参加された皆さん、そして弊社ブースでアンケートに答えてくださった皆さん、本当にありがとうございました。 この記事では、スポンサー参加の背景、ブースで取り組んだこと、当日の様子についてレポートします。 PHPerKaigi 2026とは PHPerKaigiは、PHPを愛するエンジニアたちが集まる年次カンファレンスです。2026年は中野セントラルパークカンファレンスにて開催され、44本のセッション、22本のLT（ライトニングトーク）があり、非常に密度の高い3日間でした。 エス・エム・エスとしてPHPerKaigiへの参加は2年ぶりです。今回のスポンサー参加では、PHPerKaigiを一緒に盛り上げたいのと同時に、弊社の キャリア事業 領域におけるプロダクト・技術の認知をエンジニアコミュニティに広げていきたい、という背景もありました。それもあり、そのプロダクト開発を担う 人材紹介開発グループ のメンバーが中心となってブースに立ち、PHPを使ったプロダクトの技術的な取り組みや、チームの開発スタイルについて来場者と直接対話しました。 ブースのコンセプト ブースには、Day0からDay2までエンジニア9名が参加しました。 Day1の集合写真 Day2の集合写真 弊社のキャリア事業のプロダクトは、PHPをはじめとする技術スタックで開発されています。ただ正直なところ、どういうチームでどういう開発をしているのか、外部への情報発信がまだあまりできていませんでした。そのため「エス・エム・エスにこういうプロダクトがある」「こんな技術課題に取り組んでいる」という認知が、エンジニアコミュニティにはほとんど届いていないのが現状でした。 今回のブースはキャリア事業の認知を変えていくための1つ目の施策でもあります。そこで、採用パンフレットを並べるのではなく、 アンケートパネルを用意して来場者と対話する という形をとりました。具体的には、アンケートパネルを用いて来場者にエンジニアとして大切にしているポイントを答えてもらいながら、自然な流れでエス・エム・エスのプロダクトや技術についてお伝えしていきました。 アンケート結果 当日盛り上がったアンケートの結果を振り返ってみます。 アンケートの回答で最も多かったのが、「 ビジネスと距離が近い 」という選択肢でした。ただ、会話をしていると「ビジネスと距離が近い」が意味するものは人によって少し違うのが面白くて、PdMをビジネスサイドと捉えてそことの距離感を指している人もいれば、営業やマーケ職などとの近さを指している人もいました。 生成AIが開発の現場で当たり前のように使われるようになった今、コーディングスキルだけではなくビジネスの文脈を理解して価値を生み出せるエンジニアが求められている、そういった変化を含め、来場者の生の声はいろいろと考えさせてくれるものでした。 また、会話の中で気づいたのが、「エス・エム・エス」という社名は知っていても、事業内容はほとんど知らないという方が多かったことです。医療・介護・ヘルスケア領域の人材紹介を手がけているとお伝えすると、「社会貢献性が高い事業ですね」「日本社会にとってとても重要ですね」という反応をいただくことが多く、改めて自分たちが取り組んでいる事業の意義を感じる場面でもありました。 こういった本音の声を直接聞ける場は、普段のオンライン面談では得られない貴重な機会だと感じています。 セッションの感想 どのセッションやLTも熱量が高く、弊社メンバーが参加したセッションの感想をいくつか紹介します。 接続—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 チューニングを「接続」という観点で体系的に捉え直すセッションでした。アプリケーション全体の構成を俯瞰し、どこでリクエストが発生してどこで処理されているかを把握することで、コードを書いている最中には意識しにくい「接続点」が見えてくる、そんな視点を改めて学ぶことができました。 肥大化したRepositoryクラスで責務分割で解決しようとした話 EC領域の注文情報を扱うRepositoryクラスがドメインの複雑さゆえに肥大化した問題を、「注文ステータスを更新する」といった動詞や、更新の起因（ユーザーによるものかシステムによるものか）に着目することでチーム内の共通認識を形成し、サービスクラスとして切り出すことに成功した話が印象的でした。 ビジネスがわかるエンジニアになろう：経営学とエンジニアリング、その共通点と活用法 日々のエンジニアリング業務にMBA的視点をもって臨むという話で、MBAの課題解決フレームワークが日々のエンジニアリング業務に使えるという視点で面白かったです。 参加を通じて感じたこと 人材紹介開発グループとしてカンファレンスにブース出展するのは今回が初めてでした。参加したメンバーからは「ブースを出してよかった」「来場者と直接話せて楽しかった」「自分たちの認知を広げることの大切さを実感できた」といったポジティブな感想が多く集まりました。同じグループ内でも普段は異なるチームで働いているメンバー同士が一緒にブースに立つ機会はなかなかないので、そういった意味でもお互いを知れる良い機会になったと思っています。 エンジニアとしてではなく採用・組織づくりの立場で参加していた私にとっても、「このプロダクトに関わりたい」「このチームで働きたい」と感じてもらえる組織であり続けることの大切さを、改めて実感する3日間でした。 まとめ 今回PHPerKaigiにスポンサーとして参加し、来場者の皆さんと直接対話できたことは、私たちにとって大きな収穫でした。エス・エム・エスでは引き続き、技術コミュニティへの貢献と、エンジニアとの接点づくりを大切にしていきたいと思っています。 最後に、素晴らしいイベントを作り上げてくださったイベントスタッフの皆さん、セッションやLTで場を盛り上げてくださった登壇者の皆さん、そして弊社ブースに足を運んでくださった皆さんに、心よりお礼申し上げます。ありがとうございました！

はじめに はじめまして。介護/障害福祉事業者向け経営支援「カイポケ」の事業部でCS職（カスタマーサクセス/サポート）をしているTSUNOです。カイポケに携わって10年以上になります。 エンジニアではありません。プログラミングの経験もありませんでした。 そんな私がAIを活用して業務自動化ツールを開発した結果、 月17.7時間の工数削減 と 購買判断の適正化 を実現しました。 この記事は、非エンジニアのCS職がAIで業務自動化を進めた実践記です。AIでここまでできるんだ、という実感を持ってもらえたら嬉しいです。 なぜやろうと思ったのか カイポケのCSでは、お客様からの問い合わせ対応だけでなく、カイポケを利用するうえでの事務手続きまで、お客様の業務を幅広く支えています。 2024年11月、業務体制の変更にともない、新たに業務を引き継ぐことになりました。 この業務は完了までに多くのステップがあります（下図）。引き継いだのはそのフェーズ2の部分でした。 複雑な作業を、ひたすら繰り返す。通常業務にこれらが上乗せされる状況では、とてもではないですが手が回りません。ちょうどその頃、無料版のChatGPTで簡単なGoogle Apps Script（GAS）を書く体験をしていました。もっと本格的にプログラムで業務を改善できるのではないか——そう考え始めたのが、すべての出発点です。 AI活用のステップアップ 最初から有料ツールを使っていたわけではありません。 無料ツールで小さく始めて、成果が出たら次のステップへ。その繰り返しで、気がつけば本格的な開発環境が整っていました。 大事なのは、 最初から大きな投資をする必要はない ということです。 時期 やったこと きっかけ 2024年1月〜 無償版ChatGPTでAI活用を開始 AI活用への興味 2024年11月〜 GASで業務自動化に着手 業務効率化の必要性が高まった 2025年1月頃 Google Workspace標準搭載のGeminiを活用 会社の環境変化 2025年11月 Claude Codeで本格的な開発へ AIツールの比較・検証を経て 2025年12月 Claude MAXプランへグレードアップ ROIを上司に提示して承認 ※ 各時期は筆者が知った・使い始めたタイミングであり、サービスのリリース時期とは異なります。 AI活用の情報収集は多方面から行いました。 X YouTube Google CloudユーザーコミュニティのJagu'e'r ※ Jagu'e'r （ジャガー） とは、Google Cloudユーザー企業が企業の垣根を超えて最新技術やノウハウを共有し合い、クラウド活用の変革を推進する公式コミュニティです。 特にJagu'e'rの無料ハンズオンセミナーでVertex AIに触れたことが、「APIを通じてAIを使う」というイメージを掴むきっかけになりました。この体験が後述するデータ移行支援ツールの技術選定につながりました。こうした外部の学びの場に加え、最近では社内エンジニア主催のClaude Code活用ナレッジ共有会にも参加しました。 よくわからなくても飛び込んでみると、新しい発見があるものです。 生成AIを使った3つの取り組み ここからは、AIを活用して取り組んだ3つの事例を紹介します。 # 事例 概要 1 GAS + 業務フローの見直し 6時間→2時間に圧縮 2 介護保険請求の事務手続きRPA※ 月17.7時間の工数削減 購買判断の適正化 3 AI駆動で開発中のデータ移行支援ツール 帳票の自動解析とデータ整形 ※ RPA（Robotic Process Automation）：人がブラウザやアプリ上で行う操作をプログラムで自動化する技術 1．最初の成功体験 — GASで6時間の業務を2時間に AI活用で最初に取り組んだのは、GASによる業務自動化です。 コードは主にChatGPTで生成・修正しました。自分でゼロから書いたわけではなく、「こういう処理がしたい」とAIに伝えて、出てきたコードを実行し、うまくいかなければエラーメッセージをAIに貼って修正する——このサイクルを回すことで、コードは着実に動くものになっていきました。 結果、1日あたり約6時間かかっていた業務が約2時間に圧縮されました。ただし、これはGASによる自動化だけの効果ではなく、業務フロー全体の見直し（不要な手順の廃止や作業順序の組み替え）との合算です。GAS単体の削減効果として切り出せる数字ではありませんが、ツールを作ること自体が業務を棚卸しするきっかけになったという意味で、大きな一歩でした。 2．介護保険請求の事務手続きRPA — 業務自動化の本格展開 前述の業務見直しの過程で「GASでは解決できない業務」も浮き彫りになりました。業務の中には、介護保険の請求手続きに使う外部システム上で、ログイン・画面操作・帳票出力といったブラウザ操作を行う工程が含まれていました。 このシステムには外部からプログラムで連携するための仕組み（API）が提供されておらず、ブラウザを人の手で操作するしかありません。こうしたブラウザ操作はGASの守備範囲外であり、自動化するにはブラウザそのものを操作するRPAが必要でした。 なお、外部システムをRPAで操作するにあたっては、利用規約の確認や社内のリスクマネジメント部門への事前相談を行ったうえで開発を進めています（詳細は後述の「外部システムを操作する上での配慮」で触れます）。 介護事業所がカイポケを通じて介護保険を請求するには、このシステム上で各種手続きを行う必要があります。これらの作業は、全都道府県にわたる多数のアカウントに対して日々行われます。 以前にもこの業務を自動化するRPAツールが作られたことがありました。しかし、運用環境の変化に対応しきれなくなり、最終的に役割を終えていました。業務は再び手作業に戻っていたのです。 GASで積み重ねた成功体験が、「自分で作ろう。エラーが出ても、AIに聞きながら対処できる」という確信を支えていました。 成果①：月17.7時間の工数削減 RPAによる自動化で、月に17.7時間（稼働日20日/月換算で、1日あたり53分）の業務時間が削減されました。2026年1月時点の実績です。これらの業務はお客様の増加とともに件数が増える傾向にあり、今後さらに削減効果が拡大する見込みです。 数字には表れない変化もあります。以前はルーチン対応で手一杯でしたが、時間が生まれたことで、お客様への進捗報告をより適切な頻度で届けられるよう設計し直す余裕ができました。自動化の本当の価値は、 削減した時間そのものではなく、その時間で何ができるようになるか にあると感じています。 成果②：購買判断の適正化 工数削減以上にインパクトが大きかったのが、購買判断の適正化です。 従来の運用では、外部システムにログインして処理件数を一つひとつ確認する必要があり、全体の正確な把握が困難でした。そのため、実態より多めにアカウントを購入せざるを得ない状況が続いていました。 RPAがこのログインと件数取得を自動で行うようになったことで、実際の利用状況が正確に見えるようになり、不要なアカウント購入を回避してコスト適正化を実現しました。 こうした削減効果の見込みをROIとして上司に提示し、AIツールの上位プランの利用承認を得ました。承認後の実績データでもその効果が裏付けられています。「ツールの利用料に対して、これだけの時間が浮く」という説明は、社内で予算を取るうえで有効でした。 データが見えるようになると、正確な判断ができる と実感した出来事でした。 3．AI駆動で開発中のデータ移行支援ツール データ移行支援ツールは、RPAと並行して開発を進めてきたもう一つのプロジェクトです。現在は検証フェーズであり、RPAのような確定した成果はまだありません。ここでは「完成していなくても、非エンジニアがAIと一緒にここまで到達できる」という過程をお伝えします。 何を解決するツールか カイポケを導入いただく際、お客様がこれまで蓄積してきたデータを、カイポケに登録したいというニーズがあります。その際、帳票（PDF）を目視で読み取り、手作業で転記する。これは時間がかかるだけでなく、ミスが起きやすい作業です。 データ移行支援ツールは、この帳票をAI（Geminiをチャット画面ではなくAPI経由で利用）で自動解析し、カイポケに取り込める形式に変換する仕組みです。 Geminiアプリから始まり、Claude Codeで成長した 最初はGeminiアプリのチャット画面上で、1つのプログラムファイル（.py）にコードを書いていく形でスタートしました。「この帳票のこの項目を読み取って」「エラーが出たから直して」とやり取りしながら、少しずつコードを育てていきました。 しかし、コードが1,600行を超えたあたりで限界が来ました。チャットが一度に扱える文脈の範囲（コンテキスト）にコード全体が収まりきらなくなり、修正のたびに前後関係が途切れるようになったのです。 そこで切り替えたのが「Claude Code」という、テキスト入力で操作する開発ツールでした。プロジェクト全体のファイルを把握しながら、エージェントのように自律的にコードを編集・実行してくれます。 Claude Codeに切り替えてからは開発速度が大幅に上がり、1,600行の単一ファイルだったコードは、役割ごとにファイルを分けた9,300行超の構成にまで成長しています。 時点 規模 開発環境 初期 約1,600行・単一の.pyファイル Geminiアプリのチャット画面 現在 約9,300行 + テスト約1,800行・複数ファイル構成 Claude Code AIに任せる部分と、任せない部分 開発を進める中で、正確性の高いデータソースを優先する設計にたどり着きました。介護保険の請求データは、仕様書でCSV形式として定義されています。これらはCSVから確実に取得し、CSVでは得られない情報だけを帳票PDFからAIに読み取らせる「ハイブリッド方式」を採用しています。 CSV形式で確実に取得できるデータを、あえて精度にばらつきのあるAI読み取りに回す理由はありません。AIは帳票の読み取りで誤認識を起こすことがあるため、確実な手段があるならそちらを優先する。どのデータをどの方法で取得するかの線引きにも、ドメイン知識が活きています。 ※ 個人情報を含むデータのAI処理にあたっては、エンタープライズ向けのセキュアなサービスを利用しています。 現在地 開発環境での検証を経て、クラウド上で動くWebアプリとして構築し、ブラウザからアクセスできる状態にまで持ってきました。前述のハイブリッド方式は、実データを用いた検証でも一定の精度で動作することを確認しています。現在は様々なパターンのプロンプト（AIへの読み取り指示）を調整しながら、対応できる帳票の種類を増やしているところです。自分以外のメンバーが使える状態にすることは今後の課題です。 完成にはまだ時間がかかりますが、非エンジニアによる業務改善の新しい可能性を示せたと考えています。ここからは、3つの事例を通じて得た実践的な学びを共有します。 非エンジニアがAI駆動開発を進めるためのプラクティス 非エンジニアがAIを活用して成果を出すためには、具体的な手法の前に、まずベースとなる「心構え」からお伝えします。 まず押さえておきたい4つの心構え 1. プログラミング経験より、深い業務フロー理解 業務を深く理解し、常に改善点を模索すること。 2. 人間は「要件定義と判断」、AIは「実装担当」 「何を作るか」「どんなエラーが危険か」「どのデータをAIに任せてはいけないか」。こうした判断は人間の役割です。具体的な指示を出し、AIをコントロールすること。 3. AIの出力は「たたき台」として受け取る AIは自信満々に間違えることがあります。コードの中身をすべて理解するのは難しくても、「この修正で何が変わった？」「意図した設計になっている？」とAIに確認することはできます。複数のAIにクロスチェックさせるのも有効です。鵜呑みにせず、自分の言葉で問いかける習慣を持つこと。 4. 小さく始めて、成果を積み重ねる 小さな自動化の成功体験が、次の挑戦への自信と原動力になりました。まずは手を動かしてみること。 実践＆組織で進めるための6つのプラクティス 心構えを土台として、私が実際にやってきた中で「これは他の人にも再現できる」と感じた具体的なアクションを6つにまとめました。 カテゴリ # プラクティス ひとことポイント 実践 1 AIへの指示は「業務の言葉」でいい 専門用語より「何を・なぜ・どうしたいか」 2 エラーは壁ではなく、手がかり エラーメッセージをAIに貼るだけで前に進める 3 テストもAIに書いてもらう ただし「業務的に正しいか」は人間が考える 4 環境構築は「AIに聞く → 裏取り → セキュリティ確認」 シャドーITを避ける手順を省かない 組織 5 成果を数字で見せて、リソースを得る ROIで上司の承認を得る 6 外部システムを操作する上での配慮 利用規約・社内承認・負荷配慮 1. AIへの指示は「業務の言葉」でいい プロンプトエンジニアリングだと身構える必要はありません。大事なのは、 業務の文脈を丁寧に伝えること です。データ移行支援ツールの開発初期に私がAIに伝えたのはこんな内容でした。 専門用語は一切使っていませんが、「何を・なぜ・どうしたいか」が明確なので、AIはセキュリティ設計、並列処理、エラーハンドリング、コスト表示まで一度に提案してくれました。「個人情報はログに出ないようにして」——こうした発想は、業務で日常的に個人情報を扱い、その重みを知っているからこそ生まれるものです。AIの出力品質を左右するのは、プログラミングの知識ではなく業務の知識です。 ただし、AIに任せきりでいい部分と、人間が厳密に設計しなければならない部分はあります。外部システムの仕様書を読み込み、帳票にどのような値が入ってくるのかを整理した上で読み取りのロジックを設計する——ここは業務を知っている人間が責任を持つ領域です。 2. エラーは壁ではなく、手がかり 非エンジニアにとって最大の壁は、エラーが出たときの対処です。でもやることは簡単で、 エラーメッセージをそのままAIに貼る だけです。実際の開発では、エラー対処を段階的にレベルアップさせていきました。 まず貼る — エラーメッセージをAIに貼って「これどうすればいい？」と聞く。大抵はこれで解決策が返ってくる 戦略を作る — エラーの種類ごとの対処方針をAIと一緒に設計する 仕組み化する — エラー発生時に画面キャプチャやHTML、処理ログを自動取得し、原因特定を容易にする ひとつ注意しておきたいのは、エラーは自分のコードだけから起きるわけではないという点です。Pythonのバージョンアップをしたところ、コードを一切変えていないのに、ライブラリが未対応でツールが動かなくなった経験もあります。「動いているものを維持する」難しさも学びでした。 3. テストもAIに書いてもらう 「このコードが正しく動くか確認するテストを書いて」とAIに頼めばテストコードは生成してくれます。ただし、AIが自動生成するのは「コードが技術的に正しいか」の確認です。 「業務的に正しいか」を確認するテストは人間が考える必要があります 。 たとえば「処理が中途半端な状態のまま放置されていないか」というテストシナリオは、実際の運用リスクを知っている人間にしか発想できません。AIに「こういうケースをテストしたい」と伝えれば、コード自体は書いてくれます。 4. 環境構築は「AIに聞く → ネットで裏取り → セキュリティ部門に確認」 必要なライブラリやセットアップ手順をAIに聞き、全体像を把握します。次にライセンス形態や開発元の信頼性をネットで裏取りします。その上で、社内のセキュリティ部門に「このツールを導入してよいか」確認します。 たとえばライブラリ導入時は、ライセンスが商用利用可能であること、開発元が信頼できることを確認した上で社内の専門部署に確認を取る——この手順を省かず、シャドーIT（会社の管理部門を通さずにツールを導入すること）を避けることが、長く使える仕組みにするための土台になります。 5. 成果を数字で見せて、リソースを得る 非エンジニアが業務時間を使って開発を進めるには、上司の理解が不可欠です。前述のとおり、削減効果を数字で示すことで上位プランの承認を得ました。 段階的にスケールし、各段階で成果を見せていくことで、次のチャレンジへの許可を得やすくなります。 6. 外部システムを操作する上での配慮 RPAの開発着手前に、以下の確認・配慮を行いました。 利用規約の確認 — RPAによる自動操作が明示的に禁止されていないことを確認 robots.txtの確認 — 対象システムにrobots.txt（RPAによるアクセス範囲を示すファイル）は設置されていないことを確認 社内承認 — リスクマネジメント部門に事前相談し、問題ないとの確認を取得 負荷への配慮 — 人間が操作するのと同等の速度で動作させ、未知のエラー発生時には自動停止する設計 おわりに — 属人化しない自動化を目指して 「あなたがいなくなったらどうなるの？」 ——避けられない問いです。実際、過去に社内で作られたRPAも引き継ぎがうまくいかず使われなくなった経緯があります。だからこそ、トラブルシューティングガイドや運用手順書といったドキュメントを整備するようにしています。そして何より、 AIがメンテナンスの「通訳」になれる 可能性に期待しています。コードを読めなくても、AIにエラーメッセージを貼れば対処法が返ってくる。作った人がいなくなっても回せる仕組みを作ること——その「属人化しない自動化」を目指して、今も試行錯誤を続けています。 データ移行支援ツールはまだ完成していません。模索中のことも多くあります。でも、非エンジニアだからこそ「使う側の目線」で作れる強みがある。業務を深く理解した人間にしか書けない要件定義がある。そしてAIが、その要件定義をコードに落とし込んでくれる。 自分で作るようになって、大きな気づきがありました。先述のPythonアップデートで動かなくなった経験を通じて、社内のエンジニアがフレームワークや基盤の更新に日々取り組む大変さを、身をもって理解できました。大規模なシステムを止めずに改善し続けるエンジニアの仕事に対する解像度が上がったことで、協業の質も変わったと感じています。非エンジニアが自分で作る経験は、エンジニアとの共通言語を増やすことにもつながるのです。 この記事を読んで、「自分もやってみよう」と思ってくれる方が一人でもいたら、書いた甲斐があります。最初の一歩は、「AIで何ができるか」を考えることではありません。「こんな作業が大変なんだよね」と、AIに壁打ちしてみること。そこに、活用のヒントがあるかもしれません。 追伸： 実はこの記事自体も、大部分をAIに書いてもらっています。構成案の作成、文章の推敲、さらには実際のプログラムと記事の内容に食い違いがないかの確認まで、AIと一緒に進めました。 ただし、「何を伝えたいか」「どんなストーリーで読者に届けるか」——その核となる設計は、自分の頭で考えました。AIは優秀な道具ですが、魂を込めるのは人間の仕事です。ツール開発もブログ執筆も、そこは変わらないと思います。