こんにちは、エス・エム・エスで人事をしているふかしろ( @fkc_hr )です。 今回、X Mileさんにお声がけいただき、アンドパッドさんと3社合同で「 バーティカル SaaSで拓く未来：社会課題に立ち向かう開発の舞台裏 )」というイベントを開催いたしました。 エス・エム・エスからはカイポケ開発部の酒井( @_atsushisakai )が登壇し「大規模 SaaS の技術的意思決定を支える三要素」についてお話しました。 当日はアンドパッドさんのコミュニティスペースでのオフライン実施と、YouTubeのオンライン配信のハイブリッド型で実施し、各社の執行役員や開発責任者 のLTとオフライン懇親会を実施しました。 バーティカルSaaSとは業界・業種に特化しているSaaSのことです。エス・エム・エスではカイポケが該当します。 各社向き合っている業界やプロダクトのフェーズは様々であるものの共通点の多さに懇親会も非常に盛り上がりました。 主催企業以外の方もいらっしゃったのですが、ドメインを深掘りしていくこと、法律などの制約の中でも最適な設計をしていくことなど様々な観点で興味を持っていただきました。 普段、介護・医療といった切り口で会話させていただくことは多いのですが、バーティカルSaaSという切り口は初めてだったので、改めて新しいきっかけを提供いただいたX Mileさんには感謝の気持ちでいっぱいです。 現在エス・エム・エスでは開発組織のXアカウント ( @BM_SMS_Tech )で以下の様な内容を発信しています。 テックブログ Podcast デザイナーnote イベント協賛や登壇情報 今年から Podcast や note なども開設していたり、外部イベントも増えておりますので、ぜひフォローのほどよろしくお願いいたします。 では、改めて今回のイベントに興味があったけれども参加しそびれちゃった方や、カジュアル面談でバーティカルSaaSについて話したい方は以下のフォームからご応募お待ちしております！

はじめまして 2024年にエス・エム・エスに入社した まゆゆ です。プロダクト推進本部の人事として @fkc_hr と一緒に日々 プロダクト推進本部の採用活動をしています。 エス・エム・エスに入社してこのブログが公開される頃には4ヶ月が経ったくらいのタイミングかと思います。 私は気がついたらなんだかんだ干支一周分くらいの年数をこのIT・Web業界で過ごしていて、いつのまにか半分近く採用領域に関わっていました。 ただ、その間にライフステージに変化があり、産休・育休を経て、途中で採用に関わるのはほんの少しだったりしたこともあったので、経験年数としては正味5年行かないくらいになるかなと思います。 今回、子育てをしながら日々仕事をされている方、弊社で子育てをしながら働くことに関心がある方に興味を持っていただけたら幸いです。 育休からの仕事復帰やコロナ禍を経て抱えた葛藤 今年の春に息子もめでたく小学校1年生になり、私自身としても2019年に育休から仕事に復帰して、ワーママとしても5年生になりました。 ワーママも5年やっていればベテランだねという声も聞こえてきそうですが、 振り返ってみれば、正解のないことに向かって、常に試行錯誤をしてきたような気がします。多分それはこれから先も変わらないと思っています。 特に2020年以降はコロナ禍で社会情勢も大きく変化があったりして、「子育て」という未知数な人生の一大プロジェクトを走らせている中で、さらに自分の意志だけでは変えられないものを抱えざえるを得ない感覚を持っていたのはきっと私だけではないはずです。 これは全ての方に言えることかもしれませんが、これまで抱えることのなかった不安な気持ちやモヤモヤが急に降ってきた時期だったかと思います。 この時期に子育てをされていた方々は、安心して子どもたちが保育園に行ける日は来るのだろうか？自宅保育と仕事の両立を続けることができるのだろうか？常にそんなことを気にしながら日々過ごしていた時期かと思います。 振り返ってみるとこの5年は、常に生活と子どもの状況と、それを取り巻く環境を見ながら変化をし続けてきたような気がします。それは今も同じです。 変化してきたものと変わらなかったこと コロナ禍でリモートワークを余儀なくされた企業も多く、混乱の中で働き方が大きく変わりました。 当初、自宅保育をしながらのリモートワークを我が家でもしており、当初はバランスの取り方にも大変苦労しました。 時が経つにつれ、制限がある中でも保育園に行けるようになりました。親としても、子どもが保育園に行っている間に仕事に集中でき、送り迎えも通勤がないことで時間的コストがそこまでかからずに済む環境でした。 育休からフルタイムで復帰後、時短の派遣に働き方を変えた時期もありましたが、リモートワークのおかげでエンジニア採用領域でのキャリアを積み上げることができたのだと、今振り返ると強く感じています。 コロナ禍がなければ、今でも働き方をかなりセーブをしているか全く異なる仕事をしていたのではないかと思います。 子どもの状況や社会情勢で働き方などは変わってきたものの、ずっとここ数年変わらなかったことがあります。 それはキャリアを通して社会貢献に関わっていくことです。 この考えは子どもが生まれてから明確に持つようになったのですが、自分は何かすごいことはできないけれど、健康に生まれて、健康上なんの不自由もなく生活や仕事ができる、この恵まれた状態を活かして少しだけでもいいから社会に貢献できることに関わっていきたいという思いが根底にあり、これまでも企業を選ぶときにはその軸を大切にしてきました。 そんな中、出会ったのがエス・エム・エスです。 エス・エム・エスのミッションへの共感 エス・エム・エスは「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」というミッションを掲げています。 健康でいるとなかなか高齢社会についてあまりピンとこなかったりするかもしれませんが、今の高齢社会に合わせたサービスやプロダクトを社会に提供することで、子どもたちが社会に出た時に彼らの時間だったり将来に投資できるような状態を作り出すことができるのではないか？と思っています。 私の好きな音声配信番組で「我が子は社会からの預かり物だと考えている」という発言があったのですが、この考え方が私もしっくりきていて、それを立派に育てて社会に還してくことが今の親としての役目。 voicy.jp その役目の一つとして、子どもたちが少しでも生きやすい環境を作り出していくことが大事で、高齢社会の課題を解決することはつまり高齢世代だけではなく、子どもたちの未来に還元されていくものだと私は考えていて、エス・エム・エスのミッションにとても共感しました。 入社を決めた理由はたくさんあるのですが、これまでやってきたエンジニアの採用活動を活かして、少しでも多くの方にエス・エム・エスに興味を持ってもらい、一緒に課題解決を進めていく仲間を集めることができたらと思ったのが入社を決めた理由の一つです。 ちなみに、5月に公開したエス・エム・エスのPodcast「Hello!SMS」でもエンジニアリングマネージャーの ぐっち が入社理由について、エス・エム・エスのミッションと絡めて話しているので是非聞いてみてください！ open.spotify.com 実際に働いてみてどうか 実は初回のカジュアル面談から実際に入社するまでは1年近くのタイムラグがあったのですが、その中でカジュアル面談から選考を含め何度もお話しをさせていただいていて、働くイメージが湧いてきました。 リモートワークができる環境であることはもちろんのこと、単に子を持つ親世代が多いというだけでなく、父親母親関係なく、親として子育てをしているメンバーが多いことが面談や選考から伝わってきました。 実際に入社した後もイメージとのギャップはなく、環境とカルチャーのおかげでキャリアを継続することができています。 エス・エム・エスのSlackには#kidsという子育てメンバーが集まるチャンネルがあり、たまにこういったエピソードなんかをシェアしたりして、ほっこりしています。 とてもいい環境で働けているなという点で本当に感謝しても仕切れないのですが、今年の4月から小学校に入学してから保育園時代とは全く質の異なる大変さが降りかかってきていて、正直てんやわんやです。 一つ前のセクションで、「子どもたちの未来が・・・！」みたいな大きなことを言っていますが、実際は毎朝寝起きのまま髪の毛振り乱しながらお弁当を作ったり、まだ1人で通学ができないという子どもを自転車→電車→バス→徒歩でトライアスロンのように送り迎えする日もあったりして毎日をなんとか安全に送っていくのに必死です（笑） ただそういう日常の積み重ねこそが、大きな未来を作ることもあると信じてやっています。 終わりに このブログはいわゆる入社エントリなので、エス・エム・エスになぜワーママの私が入社したのかをお伝えできればと思い書き進めてみました。 しかし、それだけではなく、激動のコロナ禍を経ながら、ワーママ5年生になりやっと見えてきたことや、大変なこともあって、もちろんこれからも大変なことがたくさん待っているけど、なんとかやれているしやろうと思っている様子なども伝えて、ふとした瞬間にこのブログを読んでくださった全ての働く親御さんたちにちょっとでも共感してもらえたり、気持ちが軽くなってくれたら嬉しいです。 その上で是非エス・エム・エスにも興味を持ってもらえればと思います！

はじめまして。ひろき（ @pirotyyy23 ）です！ 先日、株式会社エス・エム・エスのご支援を受け、RubyKaigi 2024に参加してきました。 この記事では、Ruby未経験かつRubyKaigi初参加の目線で、RubyKaigiに関する記録を残したいと思います！ RubyKaigi2024に参加した経緯 私は昨年の今頃から学生エンジニアとしてソフトウェア開発に取り組んでいます。 ある日、友人から「RubyKaigiは最高だから絶対参加した方が良い！」とおすすめされたのがきっかけでした。 そこでエス・エム・エスの学生支援企画の募集ページを発見し、「こんなチャンス二度とない！」と思い応募しました。選考を経て、無事にRubyKaigi 2024に参加することになりました。 tech.bm-sms.co.jp 会場の様子 「めんそ〜れ！！」ということで、今回の開催地は沖縄県那覇市でした！ 会場は「那覇文化芸術劇場 なはーと」という建物で、「広い・綺麗・国際通りが近い」という控えめに言って最高のロケーションでした。 印象に残ったセッション 前々から伺っていたように、各セッションの内容はかなりハイレベルでした。 ただ、懇親会などでSpeakerの方々と直接お話しすることで、内容について理解を深めることができました！ Writing Weird Code ぺん！（ @tompng ）さんによるKeyNoteです。 このセッションでは、TRICK 2022で受賞した作品や、Rubyならではの特徴を活かしたWeirdなコードが紹介されました。 先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。 全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。 魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of — ぺん！ (@tompng) 2022年10月18日 その中でもSelf TRICK 2024で紹介された「floral」という作品はとても印象に残っています。 selftrick2024/floral at main · tompng/selftrick2024 · GitHub 「floral」は、一見すると単なるbmpファイルですが、実行するとRubyのコードとして解釈されるという非常に興味深い作品です。bmpファイルのバイト値を解析すると、Rubyのコードとして解釈され、以下のような出力を得ることができます。 Rubyに関わらず、奇妙なコードを書くことでその言語に対する理解が深まると思うので、個人的にチャレンジしてみようと思いました！ The grand strategy of Ruby Parser Yuichiro Kaneko（ @spikeolaf ）さんによるParserのお話でした。 Kanekoさんとは、Day0のイベントでお会いし、そこでParserについて熱いお話を伺いました。 お話の中で、「LR構文解析」や「オートマトン」など、大学で学んだ言葉が多く出てきました。このことをきっかけに、「これは大学で学んだことを生かせるチャンスだ！」と思い、多くのセッションがある中で特にこのセッションに参加することにしました。 セッションでは、Kanekoさんが開発されたParser Generator「Lrama」についての詳細な説明がありました。（ちなみに、「リャマ」の正式な綴りは「Llama」ですが、内部で使用されているのがLRパーサであるため、「Lrama」と名付けられたそうです。） これまで主に言語やフレームワークの使い方に焦点を当てて学んできましたが、プログラミング言語の基礎となる部分について学ぶのも非常に興味深いと感じました。 セッションの終盤では、真のUniversal Parserとして言語に依存しないParser Generatorに関する話題も取り上げられました。 開催期間中の過ごし方 企業ブース RubyKaigi には、さまざまな面で支援を行うスポンサー企業が多数参加しています。 気になるセッションを見た後は、企業ブースにて多くの企業の方々と交流しました。 企業の方々とお話しすることで、各社のサービスについての理解を深めることができました。 「このサービスの中身が全てRubyで作られているんだ!」といった発見もあり、非常に興味深く楽しい経験でした。 また、将来のキャリアについても相談することができ、自分のスキルや経験に基づいて、どのようなポジションが適切かについてアドバイスを受けることができました。 エス・エム・エス社員との交流 Day1のランチとDay2のディナーを、エス・エム・エス社員の方々と行きました！ 沖縄のグルメを堪能しながら、おすすめのセッションやイベントについて伺ったり、普段の業務についてお話を伺ったりすることができました。 ディナーでは、Rubyを学ぶのにぴったりな本として、｢チェリー本｣をおすすめしてもらいました。 プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus) 作者: 伊藤 淳一 技術評論社 Amazon かなり文量のある本ですが、来年のRubyKaigi の内容を少しでも理解できるようにするために、少しずつ進めていこうと思います！ RubyKaigi に参加してみて RubyKaigi 2024 に参加し、たくさんの方々と交流する中で、Rubyistの熱意を肌で感じることができました。 私は、RubyKaigi に参加するまで全くRubyを書いたことがなかった者でしたが、Day2あたりから気づいたらRubyMineを入れて、Rubyを書いていました。 それほどRubyistの方々がRubyを作ること・使うことを全力で楽しんでいる姿に魅了され、「私も書いてみたい！」と思うようになりました。 改めて、RubyKaigi の期間は最高に楽しく、学びの多い時間でした。 このような機会を提供いただいたエス・エム・エスの方々には感謝してもしきれません！ 本当にありがとうございました。

こんにちは。人材紹介開発グループに所属している大上です。私は2023年12月にWEBエンジニアとしてエス・エム・エスに入社し、現在は福岡県から完全リモートワークで業務を行っています。 フルリモートワークが普及する中、新しいチーム環境へのスムーズな適応は、多くの企業にとって共通の課題となっています。本記事ではこの課題に対して、私のチームではどのように取り組んでいるか、そして私自身がどのようにキャッチアップを行ってきたかについてご紹介します。 オリエンテーション 新たな職場での初日をいかにスムーズに迎えるかが大切です。PCや必要な機材は、入社日までに自宅に配送され、初日から準備万端で業務を開始できるようになっていました。入社当日は、1日かけてオリエンテーションを受け、会社の理念や制度などを詳しく学ぶことができました。このオリエンテーションでは、必要な情報を一通り把握でき、業務開始に向けてスムーズな移行が可能です。また、よくある質問や手続きの流れも事前にまとめられており、事務手続きで迷うことはありませんでした。 オリエンテーション後も、サポート体制は十分に整っており、チャットツールを通じて気軽に質問ができる環境が用意されていました。これにより、新しい環境でも安心して業務に取り組むことができます。 2日目には、配属されたチームメンバーと初めての顔合わせを行いました。この顔合わせでは、各メンバーが自己紹介ページを用いて自己紹介を行い、名前や役職だけでなく、趣味や得意なことなども共有されました。これにより初対面でも共通の話題を見つけやすく、リモートワーク環境でのコミュニケーションを円滑に進めるための良い工夫だと感じました。また、チームメンバーはリモートワークに慣れており、コミュニケーションもスムーズに取れるため新しい環境でもすぐに活動を始めることができます。 キャッチアップにおけるチームの環境 チーム内では定期的なミーティングが開催されています。ミーティングでは進捗状況や課題を共有し、これにより、メンバー間で情報が透明に交換され、全員がプロジェクトの最新状況を理解できるようになっています。ミーティングはエンジニアに限らず、他職種のメンバーも参加し、プロジェクト全体の進行状況を把握することができるため、一体感を持って取り組むことが可能です。 また、ミーティングで設定される具体的な数値目標や開発すべき機能の背景、そしてビジネスの目的を共有することで、チーム全員がより質の高いアプリケーション開発に向けて同じ方向を向いて努力できます。どの職種からも質問ができるオープンな環境が、業務の理解を深めるための良い機会を提供しています。 さらに、 esa などの情報共有ツールを活用することで、必要な情報をいつでも迅速に入手でき、同時に他のチームのエンジニアがどのような取り組みをしているかを知ることができます。これは、知識の共有とチーム間の協力を促進し、より効率的に業務を進めることに寄与しています。 このような環境が整っているため、リモートでもスムーズにキャッチアップを進めることが可能でした。 入社時に私が行ったキャッチアップ方法 私が特に意識したキャッチアップの方法として、２つのポイントがあります。 まず、学んだ内容を資料として残し、暗黙の了解をドキュメントとして明記することを心がけました。これにより、新たにチームに加わるメンバーが同じポイントでつまずくことを防ぎ、チーム全体の共通認識を揃えることができます。 次に、疑問に思った点や、形式ばったりしているルールについては、チーム全体で議論しルールを整備することを重視しました。これにより、より効率的な開発が行えるようになると共に、良好なチーム運営を実現できると考えています。 これらは新しく参加した際に気づきやすい事項でもあるため、積極的に提案を行うことが重要です。 加えて、私がジョインしたチームでは、メンバーがオープンに意見を出し合う文化が根付いており、議論の場がしっかり設けられていたため、積極的に提案を行うことができました。このような環境の重要性を実感し、将来的に自身が新メンバーを受け入れる立場になったときには、提案しやすい環境を整えることを心がけたいと考えています。 今後新しいメンバーをどのようにチームが受け入れていくのか ジョイン時に感じた課題や改善点を踏まえ、今後はさらに良い受け入れ体制を築いていくことを目指しています。この目標に向けて、チームとして最近取り組んでいるのがペアプログラミングです。新しく加わるメンバーと共にペアプログラミングを行うことで、彼らがシステムのアーキテクチャを理解しやすくなり、同時にコードの品質も向上します。 さらに、このアプローチを通じて直接コミュニケーションを取ることで、新メンバーとの距離が縮まり、チーム全体のコミュニケーションが向上していることが感じられます。この取り組みにより、私たちは持続可能な成長と革新を支える強固なチームワークを築いていくことを期待しています。 まとめ オリエンテーションから始まり、日々の業務、チーム内コミュニケーションの強化に至るまで、私たちはリモートワークの環境下で効率的かつ生産的に業務を進めるための戦略を継続的に改善し続けています。特にペアプログラミングのようなコラボレーティブなアプローチは、新メンバーがチームに溶け込む手助けをし、同時に全員が目指す品質と効率を高めることができる重要な手段です。 これらの経験を基に、私たちは新たにチームに加わるメンバーが直面するであろう障壁を低減し、より迅速かつスムーズに業務に取り組めるようにするための体制を整えています。積極的なコミュニケーション、透明性の高い情報共有、そしてオープンなフィードバック文化が、これを実現するための鍵となっています。 最終的に私たちの目標はリモートワークでも効果的に機能する協力的で結束力のあるチームを築くことです。そして、このような取り組みを通じてチームとしての成長だけでなく、個々のメンバーも成長を続けていける環境を提供していきたいと考えています。

はじめに 初めまして。人材紹介開発グループにて、介護職向け人材紹介サービス カイゴジョブエージェントの開発を担当している和田です。 本記事では、「プロダクションレディな品質」を目指すための取り組みについて紹介させていただきます。 同様の取り組みをしている方や、興味のある方の目に留まり少しでもお役に立てたら幸いです。 取り組みの背景 ある障害が発生した際に、原因の一つとして「リリース可能な品質水準について共通認識を持てていない」事が挙げられたのが発端でした。 「本番にリリースしていい状態 = プロダクションレディな状態」に対して、まず前段として開発のフローが一定の水準で確立されていることが最低限の品質担保に寄与すると考え、相互学習の場も兼ねて「構成管理」「テスト」「自動化」の観点で議論がスタートしました。 プロセス ここでは実際にどのようなプロセスで進行していくか紹介していきます。 テーマによって若干の差異はあるものの、大枠以下のようなプロセスで進めていきます。 議論フェーズ 一定期間議論するテーマを決め、参加メンバーでディスカッションを行う 参加メンバーはそのテーマに対して気になる事を意見していく 議論が発散しないよう留意しつつ、そのテーマにおける「プロダクションレディ」について共通認識を揃えていく オーナー(旗振り役)とサポート役の選定 オーナーの役割 進捗把握、課題整理、実行手順の取りまとめなど、必要な事を適宜行いプロジェクト実行を推進する サポート役の役割 基本的にはオーナーが行う各作業においての補助的な立ち位置で一緒に考え作業する 実行フェーズ オーナーとサポート役が、実行するにあたって流れをまとめる 各プロダクト毎に作業を進め、毎週オーナー役が進捗を確認し、全プロダクトの対応が完了するまでテーマの実行を推進していく 実際のテーマとそこから得た学び 取り組み自体がまだ浅いので現時点で完了したテーマがまだ存在せず、基本的に全て進行中のステータスにはなりますが、ここでは実際に今動いている以下のテーマについて自身の学びを交えて簡単に紹介させて頂きます。 データベースの構成管理 テストに対する認識を揃える データベースの構成管理 このテーマは、構成管理の一つとしてデータベースの管理を見直す取り組みです。 テーブルの変更履歴が正しく管理されていない、複数のプロダクトで同じテーブルをメンテナンスしている、などの問題があります。解決策について議論を重ねた結果、既存のモノリシックなデータベースをプロダクトごとに分割してプロダクト単位でデータベース定義の管理からデプロイまで行えるようにする、という方向でステップを踏んで作業を進めています。 学び 私自身データベースを分割することに対する知見が少なかったのもあり、O’Reillyの『 モノリスからマイクロサービスへ 』を参考に基本的な部分から学びました。 参加メンバー内でも同書籍を用いた勉強会も開催され、「うちのプロダクトだとこういうことなのか？」といった会話がなされて学びが多いです。 全てのテーマで共通していますが、各議論の中で他のプロダクトを担当するメンバーの意見、担当外のプロダクトで既に行っている取り組みなども知れるので参考になります。 テストに対する認識を揃える このテーマは、どのフェーズでどのようなテストが行われるべきか、また、それぞれのテストをどのように書くのか、などを整理し、プロダクト間で共通認識を持った上で各プロダクトのテストを作成していくための取り組みです。 学び 私自身、そもそもこのテストはどの開発サイクルで行われるべきで、それに必要なデータは何でどういったデータがあるべきか？といったことを深く考える機会は初めてでした。 この取り組みを通じてモブプロ的にテスト内容の検討やテストコードの追加なども実施され、学びを得る機会が多いです。 プロセスを通じて得られたこと 私の場合、データベースの構成管理の部分でオーナーとして活動していました。 上でも書いていますが、この領域に関する知見が少なかったので、他メンバーの考えや書籍を参考にしつつ解決までのロードマップを引くといった感じでした。 単に自己学習をした場合よりも、業務内でアウトプットを並行して行う必要があったので、より理解も深まる機会になったと思います。 加えて、オーナーの役割を担うことで、リーダーシップを取りプロジェクトを推進する経験が出来たこともよかったと思います。 ゴールはどうあるべきでどう進めるのか、ロードマップは納得できるもので行動に移せるのかなど、リーダーシップを取り、人を巻き込みながら共通の目標に向かっていく事は思っていたよりもプレッシャーを感じましたが、自身の成長に繋がっています。 最後に プロダクションレディな品質を担保する為に実施している取り組みについて事例を交え紹介させて頂きました。 私自身感じているのは、個別のタスクレベルで発生する課題だけでなくプロダクト横断レベルの複雑な課題に取り組む機会が多く、開発者として成長につながる場面にも恵まれている環境だということです。 もしこの記事を読んで少しでもエス・エム・エスに興味を持ってくださった方がいたら嬉しいです。

はじめに エス・エム・エスでエンジニアをしている @koma_koma_d です。みなさん、オブザーバビリティ、やってますか？今回の記事では、OpenTelemetryのSpan Linkについて紹介します。 そもそも、トレース、スパンとは？ オブザーバビリティにおける主要なシグナルとして、「ログ」「トレース」「メトリクス」の3つが挙げられます。その一つであるトレースは、システムの処理の流れをエンドツーエンドで追跡するための仕組みです。1つのリクエストが処理される流れを、部分に分割して可視化することができます。 トレースは、以下のような「スパン」のツリー構造として表現されます。スパンは、処理中の特定の操作を表現します。データベースへのクエリ、外部サービスのAPIコール、あるいはアプリケーション中の特定の処理ブロックなど、様々なものをこのスパンとして表現することができます。 この構造は、あるスパンを開始するときに、そのスパンが子としてぶら下がることになる「親」のスパンを指定することで作られます（「親」のないスパンが、1つのトレースのルートスパンとなります）。たとえば、Webアプリケーションのサーバ側のコントローラーがリクエストを受け付けたところでルートスパンを開始し、何らかの業務上の処理のまとまりをその子スパンにし、その中で行われるデータベースへのアクセスを更に子スパン（ルートスパンから見た孫スパン）にする、といった形です。 1つのトレースを構成するスパンは、システム内の単一コンポーネントから発行される場合もあれば、システム内の複数のコンポーネントから発行される場合もあります（後者の場合のトレースを特に「分散トレース」と呼びます）。トレースを活用することで、一続きの処理の中での個々の処理同士の依存関係を可視化することができ、たとえばどこの処理の遅延が全体の処理時間にインパクトを与えているか、どの部分でのエラーが起きたか、などを簡単に見ることができるようになります。 なお、分散トレースを実現するためには、サーバ間の通信時にスパンの情報を伝播させ、受信側で新しくスパンを開始する際にそれを親スパンとして指定する必要があります。この際に用いられるのがSpanContextで、これにはトレースID・スパンIDなどのスパンを特定する情報と、追加的な情報が含まれます。このSpanContextはシリアライズして送信されるのですが、後述するSpan Linkの場合にもこれを用いることになります。 opentelemetry.io 親子関係ではない関係を示すものとしてのSpan Link トレースは親子関係を持つスパンの集まりでした。しかし、ある一連の処理の流れについて、全てのスパンを親子関係で繋ぐことが常に最適であるとは限りません。親子関係とするには適さないが、関連があることは表現したいという場合に用いるのが「Span Link」です。 Span Linkについては、OpenTelemetryのドキュメントにも説明があります。 概念の説明 https://opentelemetry.io/docs/concepts/signals/traces/#span-links 仕様の概要 https://opentelemetry.io/docs/specs/otel/overview/#links-between-spans 仕様の詳細 https://opentelemetry.io/docs/specs/otel/trace/api/#link Span Linkによる関係が親子関係と異なるのは、 同じトレースに属さなくてもよい（親子関係の場合、子は親の属するトレースに属することになる） 1つのスパンから、複数のスパンに対して関係を持つことができる（親子関係の場合、親は1つしか持てない） の2点です。すなわち、これらの特徴が活きるシーンが、親子関係ではなくSpan Linkを用いる場面ということになります。上記のドキュメントのうち、 仕様の概要を記した資料 に、Span Linkが使いやすい場面が紹介されています。 1つ目は、前段の処理とは別のトレースとして新たに開始したい場面です。親子関係ではなくSpan Linkを使うことで、別のトレースでありながら前段のトレース（のうちのリンク先のスパン）との関連があることを示すことができます。 2つ目は、scatter/gatherと言われている、処理が一度複数に分岐して実行され、後から合流して続きの処理が行われるようなパターンです。スパンには親スパンは1つしか設定できないので、合流する際に直前の（別々に実行された）複数の処理のスパンを親とすることはできませんが、Span Linkであればそれら全てに対して関係を持たせることができます。 Span Linkを設定する方法：C#の場合 Span Linkを設定するのは簡単です。C#の場合は、System.Diagnostics名前空間のクラス群を使って実現できます。たとえば、SQS経由で起動される非同期処理のコンシューマ側のスパンから、プロデューサ側のスパンへリンクを作る場合には以下のようになります。なお、SpanContextの情報をSQSのメッセージに載せたり抽出したりする部分は、親子関係を作る場合でも共通です（自動計装の場合は、コードを書かなくてもライブラリ側でやってくれているかもしれません）。 /* プロデューサ側 */ // SpanContext情報を載せる Propagators.DefaultTextMapPropagator.Inject( new PropagationContext(activity.Context, Baggage.Current), message.MessageAttributes, (attributes, key, value ) => attributes[key] = new MessageAttributeValue {DataType = "String" , StringValue = value }); /* コンシューマ側 */ // SpanContext情報を抽出 var context = Propagators.DefaultTextMapPropagator.Extract( default , message.MessageAttributes, (attributes, key) => attributes.TryGetValue(key, out var value ) ? [ value .StringValue] : []); // Span Linkを指定してアクティビティを開始 using var activity = activitySource.StartActivity( "ConsumeMessage" , ActivityKind.Consumer, default ( string ? ), tags, [ new ActivityLink(context.ActivityContext)]); これでOpenTelemetry上のSpan Linkを作ることができます。 ※ちなみに、 DefaultTextMapPropagator を使った場合、トレースID・スパンIDなどの情報は traceparent という名前の属性として登録されます（TraceStateの情報も載せた場合は tracestate に載ります）。これは traceparent という名前のヘッダーをつけるのがW3CのTrace Contextの仕様だからです。 www.w3.org Span Linkはどのように可視化できるか？：Datadogの場合 さて、以上のようにして作ったSpan Linkは、オブザーバビリティツールの上ではどのように可視化されるのでしょうか。ここでは、Datadogの例を紹介します。Datadogでは、エージェントのv7.45.0でSpan Linkがサポートされるようになり、Web UI上は現時点でベータ版でSpan Linkがサポートされています。 https://github.com/DataDog/datadog-agent/releases/tag/7.45.0 https://github.com/DataDog/datadog-agent/pull/15767 https://docs.datadoghq.com/tracing/trace_explorer/trace_view/?tab=spanlinksbeta#more-information 先述の例のように、キューのコンシューマ側のスパンからプロデューサ側のスパンに対してリンクを作った場合、Datadogのコンシューマ側のトレースの画面で、中段の一番右に「Span Links BETA」のタブが現れます。そのタブを選択すると以下のように表示されます。 画面は説明がほとんど不要なほどにシンプルで、下段にSpan Linkの一覧（今回の例では1つだけ設定しているので1つだけ）が表示されます。どのスパンからどのスパンにリンクされているかが表示され、リンク先のスパンの画面にクリック一発で遷移することができます。便利ですね！ おわりに 以上、OpenTelemetryのSpan Linkについて、実際のコード例も交えて紹介しました。何かの参考になれば幸いですが、私自身まだまだOpenTelemetryの仕様を把握しきれておらず、有効活用できていないところがあります。 特に、今回ドキュメントに即してSpan Linkを使う場面の1つとして紹介した「1トレースとするのが適当ではない場面」については、正直ピンときていないところがあります。基本的には1トレースとして扱った方がオブザーバビリティツール上で一覧しやすいなどの点でメリットがあるように思うので、別トレースとして扱う方が好ましい場面というのがあまりピンときていません。ドキュメントでは、「サービスの信頼できる境界の内側に入って、サービスのポリシーが新しくトレースを始めることを要求する場合」と書かれているのですが、あまり具体的にイメージできていません。また、このようなポリシー上の事情以外にも、別トレースとして扱う方が好ましい場合があるのだろうか、というのもよくわかっていません。もしこのあたり知見や「うちはこうしてるよ」というのがある方がいたらぜひ教えていただきたいです。 私の運用しているアプリケーションでは、OpenTelemetryを使うことで、かなりエラー発生時などの調査がやりやすくなったと感じています。とはいえ、まだまだOpenTelemetryをフル活用できているとは言い難い状態ですので、これからも勉強しながら活用していきたいと思います。 もし記事中に誤った記述や技術活用上の改善点などがありましたら、筆者のXアカウント @koma_koma_d までぜひお気軽にご連絡ください！

こんにちは、プロダクト開発部人事のふかしろ( @fkc_hr )です。先日、 医療キャリア事業 に携わる開発組織についてのページを公開し、ブログでも紹介しました。こちらの記事および採用情報サイトのページでは、開発組織からの視点で医療キャリア事業について説明しています。 今回は、医療キャリア事業の事業責任者を務める 山本健 さんに事業の詳細や、開発組織との関わりについて伺いました。ぜひ最後までお読みください！ tech.bm-sms.co.jp careers.bm-sms.co.jp はじめに エス・エム・エスで医療キャリア領域の事業責任者を務めている山本です。製造業のベンチャー企業や結婚式場の運営会社で働いたあと、「残りの仕事人生は自分の興味のあるヘルスケアの領域で勝負しよう！」と考え、2012年にエス・エム・エスに入社しました。 この記事を読んでいるのはエンジニアの方が多いと思いますが、エンジニアの皆さんにも私たちのやっている事業の重要性や面白さが伝わるようにお話しできればと思います。よろしくお願いします。 医療キャリア事業について なぜこの事業が必要なのか 弊社のキャリア事業では、「 医療・介護従事者の不足と偏在を解消し、質の高い医療・介護サービスの継続提供に貢献する 」をミッションに掲げており、医療キャリア事業はその中の医療従事者向けの領域として、様々な医療従事者向けの 人材紹介サービス を運営しています。 エンジニア採用サイト の内容とも重複しますが、改めてこの医療キャリア事業の目的を説明しましょう。私たちの事業は、求人を出す医療機関と、求職者である看護師などの医療従事者との間を取り持つことで成り立っています。 一方の当事者である医療機関の直接の課題が人材の確保であることは当然ですが、医療機関というのは地域の医療を支える存在ですから、 医療機関の人材の需要というのは地域医療の人材の需要であり、その背後には地域の患者の医療サービスへの需要があります。「求人の裏には未来の患者がいる」のです。 地域の患者の需要は一定ではなく、変化するものです。これは需要が全体として増減するだけでなく、複数の医療の機能（病院、クリニック、訪問看護、介護施設など）の間での需要の移動もありますし、地域の間での需要の移動もあります。したがって、患者が必要とする医療が変化するのに対応して、人材の移動を促していくことが地域医療を支えるためには必要になります。 もう一方の当事者である医療従事者については、 それぞれの人がその人らしく医療従事者として働き続けられるようなキャリアの選択肢を提案 し、可能性を広げることを支援することが私たちの事業の課題になります。これはもちろん本人のキャリアのためでもありますし、資格やスキル、経験を持っている方に長く働いてもらって労働参加率を高めることはやはり地域医療のためにも重要なことです。 地域医療・医療機関について 医療機関の事情についてもう少し詳しくお話ししましょう。改めて言うまでもなく、高齢化の進行は医療においても大きな課題を生み出しています。高齢化が進めば医療への需要が増加しますから、その需要に応えるだけの医療機関の生産性の向上は重要な課題です。ベッドの回転率や平均在院日数を改善するためには、スタッフの充実が欠かせません。2006年の診療報酬改定で導入された7対1看護の基準も、このような高齢化社会の課題への対応の先駆的なもので、この時期から医療の領域における有料の人材紹介サービスというものもビジネスとして求められるようになってきたのです。 医療機関としては、人材を確保するため、本来であれば求職者に向けて自分たちの働く場としての魅力を発信していきたいわけですが、多忙な医療機関が自らそれを行うのは大きな負担になります。そのため、私たちのような人材紹介サービスが代わりに母集団形成や一次スクリーニングの部分を担う余地があるわけです。これは単にビジネスチャンスであるというだけでなく、大きな社会的責任を伴うものだと考えています。 医療機関のニーズにマッチしている求職者の方を適切に面接にまでお連れすることが、多忙な医療機関の負担を減らし、ひいては地域医療に貢献することになる わけです。そのためには、職場としての医療機関の状況、そこで求められる人材像に深い理解を持ったキャリアパートナー（転職・採用支援担当）の存在が重要です。このような専門性の高いサービスを届けられる存在になるために、医療現場で臨床経験を積んだ医療従事者のキャリアパートナーが全国に100名以上在籍しています *1 。こうした医療従事者のキャリアパートナーが果たしている役割については、2024年3月に発表した以下のプレスリリースでもご紹介していますので、興味のある方はぜひご覧ください。 www.bm-sms.co.jp 求職者について 求職者である医療従事者についても補足します。この業界では、高校生の時点でキャリア選択をしている人が多いことが特徴です。医療従事者としてのキャリアを選択する理由はもちろん人それぞれですが、看護師資格のような国家資格を取るためにたくさん勉強をして医療業界に入ってきます。多くの人は、せっかく得た資格とスキルを活用して、目の前の患者に適切な医療処置をしたい、患者に寄り添って良い看護サービスを届けたいと思って仕事をされていると思います。しかし、職場や家庭での ちょっとしたボタンの掛け違いで、今の職場だと自分らしく、患者に寄り添って働き続けられない、となってしまう人も多い です。患者中心ではなく医療機関中心の医療に違和感を覚えてしまったり、プライベートとの折り合いが付かなくなってしまったり、ですね。特に若手の方は、最初に働き始めた医療機関で上司との関係が悪くなって働き続けられなくなってしまうということもしばしば見られます。 そういう状況に陥ってしまったときに、もちろん別の業界に転職することも大切な選択肢の一つですが、せっかく努力してきて、医療という仕事に対する思いも持っているのに、業界を去るしかなくなってしまうのは、とても勿体ないことです。私たちとしては、そういった状況に追い込まれたとき、いや追い込まれる前の段階で、 「今の職場以外にも医療業界で働き続ける選択肢は常にある」という状態をインフラとして用意する ことがそれぞれの人の人生にとって大事なことなのではないかと考えています。 今後のプロダクト開発で実現したいこと 私たちが医療キャリア事業を通じて解決したい課題や果たしたい役割をお分かりいただけたでしょうか。ここからは、以上のような背景を踏まえて、プロダクトの開発を通じて実現したいことをより具体的にお話ししましょう。 医療機関にとって人材確保が重要な課題で、私たちのような有料人材紹介サービスはそれを一部肩代わりしているという話をしました。私たちのサービスの従来の建て付けは、医療機関から求人が出てきたときに、そこに対して求職者をなるべくたくさん集めよう、という形になっていました。しかし、これでは他のサービスとの差別化は困難です。広告やメールマガジンなどを活用して応募者を獲得すれば成長する、というのはある程度まではそうですが、 広告宣伝費をたくさん使ったところが勝つというマーケットとして扱ってしまっては早晩頭打ち になります。これまでとは違う考え方でサービス運営をする必要があります。 広告宣伝費勝負にならないためには、お客様である求職者に「このサービスがいい」と思って選んで使ってもらえるようにすることが必要です。「お客様が私たちを選ぶ理由」を作る必要があります。CM等で認知を取るのは一時的には有効ですが、使ってみてもらったあとに「他と変わらないね」となってしまっては元の木阿弥です。そうではなく、 使ってもらえばわかる「私たちを選ぶ理由」を作った上で、認知施策を打って使ってもらう のです。この「私たちを選ぶ理由」こそ、プロダクトの魅力ということになります。 こういった考え方から、まずは顧客接点のさまざまなところを、お客様の体験にとって望ましい形になっているか点検していっているところです。顧客接点となるのは、Webサービスとしてのユーザーインタフェースに加え、電話や対面、メールなどの人が関わる部分など多様です。キャリア事業というのはITだけで完結するものではなく、生身の人が介在する場面が出てくるわけですが、人とITとが一体化した、顧客体験のよいプロダクトにしたいのです。 顧客体験ということを考えたときに大事なのは、 医療キャリア事業が対象としている職種の多様性があります。それぞれの職種にはそれぞれ固有の専門性があるので、求職者向けの体験としては職種ごとに独自のものを追求したいという側面があります。一方で、医療機関の立場に立ってみると、1つの医療機関が様々な職種の方を採用しようとするので、医療機関向けの体験としては職種を横断して扱えるようになっていた方が望ましいです 。また、どの職種にも適用可能な裏側の仕組みというものもあります。現状は、職種ごとにバラバラにプロダクトが構築されてきているため、本来は1つのものに蓄積されていくべき情報がバラバラになってしまっていたり、仕組みが別々になってしまっていたりします。こうした点をシステムの内部構造含めて改善していきたいというのが実現したいことの一つです。技術者の視点からも「こうあるべき」というものを提示して、リードしてもらいたいと考えています。 プロダクト開発組織に期待したいこと この記事を読んでくださっているのはプロダクト開発職の方が多いと思うので、プロダクト開発の話をもう少ししましょう。 プロダクト開発組織の人たちとの関係の変化 私はエス・エム・エスに入社してからもう10年以上経っているのですが、入社当初はプロダクト開発組織の方々とはあまりしっかり話ができていませんでした。 以前は、開発組織と事業側との関係が密でなく、事業側から刹那刹那で断片的な情報だけで「こういうのが作りたい」「こういう機能が欲しい」と開発組織に依頼するというのを繰り返してきました。開発組織の方々との良い関わり方がわからず、理由などをあまり伝えずに作りたいものだけを伝えていたんです。前回依頼して作ってもらったものと今回依頼しているものとの間に一貫性がない、ということしばしばで、プロダクトとしての明確な方向性もない状態でした。 しかし、数年前に技術責任者の田辺さんがキャリア事業にも関わるようになってから、 「プロダクト開発の人たちも事業の前提や根幹を理解した上でより良いサービスづくりをしたいんだな」という印象を持つようになりました 。そして昨年、リーダーとして鈴木健二さんが参画されてからは、実際に「どういうふうにしたいから、今これを作るんだ」といった会話ができるようになってきました。今は開発もオーナーシップを持ってくれていると確信できているので、細部をどういうふうに作っていきたいかなどは信頼して任せられるようになっています。スケジュールなどについても、事業側が一方的に納期を設定して急かすということもなく、相談しながら進めています。 ものづくりはものづくりの人にリードしてほしい 先ほどプロダクトの顧客体験のところでもお話ししましたが、 プロダクトがどうあるべきかという点については、技術者の方にぜひリードしてもらいたい と考えています。ソフトウェアの内部の設計についてはもちろんですが、顧客にとって利便性の高いサービスの設計という観点でもエンジニアとしての知見を活かしてもらいたいです。 個人的な話になりますが、私はエス・エム・エスに入社する前に製造業の会社にいたことがあります。私は自動車の開発プロセスに関わっていたのですが、その時に出会った自動車のプロダクトマネージャーは、エンジニア出身の方ばかりでした。おそらく1台3万点の部品で構成される自動車というプロダクトの複雑さゆえという側面もあったとは思いますが、 エンジニアがビジネスと顧客についての知見を習得してプロダクトマネージャーになっていることで、売れて儲かる自動車作りができていた と感じています。当社の複数職種の人材マッチングビジネスを支えるITシステムも複雑な要件が多いと思っており、その複雑な要件を実現するためのアーキテクチャを決める能力のあるエンジニアが（ビジネスや顧客についての理解を身につけた上で）プロダクト作りをリードした方がよいと考えています。 そのような関係性を実現するためにも、エンジニアのリーダーには関わる事業の週次進捗に主体的に参加してもらうなど、社会や顧客からの要請・競合環境・それに対する自社の取り組みの変化の文脈をタイムリーに理解できる環境作りを心がけています。 エンジニアの皆さんへのメッセージ 私は趣味でヨットを長年やっているのですが、同じヨットに乗っている人たちは運命共同体で、各々が別の役割を持ちつつも、皆で支え合いながら安全に航海しゴールに辿り着かなければなりません。会社もこれに似ていて、 立場や職種が違ったとしても、互いに尊重しながら、運命共同体として協働し、同じビジョンに向かって進んでいく ことが大切だと思っています。 当社の事業に興味関心があり、エンジニアの立場でこの社会課題の解決に共に挑みたいと思って頂ける方と出会えたら嬉しいです。 （終） *1 : 2024年3月28日付弊社プレスリリース より。

キャリア事業でSREをしている @st_1t です。 先日、 PHPカンファレンス小田原 にスピーカーとして参加させていただきました。 実はほぼ初めてのカンファレンスでのスピーカー体験 今までずっとパブリックな場でスピーカーとして登壇することは実は避けてきていました。 話すネタがなかったり、内容に自信が持てなかったり、色々な理由があるのですが、一番は言葉や表現を間違えることへのプレッシャーがあります。 自分にとってそういうプレッシャーがある中でプロポーザルに応募したのは、運営スタッフに顔見知りのメンバーがいたことにあります。 初登壇を終えた今となっては他のイベントでも登壇に挑戦してみよう・・・！！と感じていますが、そう感じさせてくれたのはPHPカンファレンス小田原のおかげなので感謝の気持ちでいっぱいです。 小田原良かった〜〜〜！！！ 実は前日も当日も登壇準備であまり満喫はできなかったのですが、ホテルで撮影した朝日に照らされる小田原城はテンション上がりました！ もし来年も小田原でPHPカンファレンスがあったら次こそは魚や小田原城を楽しみたいと思います・・・！！ 発表内容 弊社の医療キャリア事業における開発者体験向上施策について発表させていただきました。 fortee.jp Ask the speaker楽しかった スピーカーが話を終えると、別室のAsk the speakerブースで興味を持っていただけた方々と交流が出来る仕組みになっており、めちゃくちゃ楽しかったです！ 最初から5、6名の方々が集まってくださって、各社で同じようなことをやっていたり、私が考える最強のローカル環境をコードを交えてわいわい出来たのは新鮮でした。 Makefileではなくて Task を使ったり、Reverse proxyとして Caddy を使ったりしているというのも逆に教えてもらって良かったです！ ※誰か来てくれるのか最初は不安でしたが最終的には時間いっぱいまでみんなで盛り上がれて杞憂に終わってほっとしています笑 ※Ask the speakerでコードをオープンにする許可をくれた @kenjiszk には大感謝です🙏 感想ﾒﾁｬｳﾚｼ 知人からめちゃくちゃ良い感想のブログがでてるよ！！！！と教えてもらいました。しょまさんのブログです。 www.hal40n.com これを拝見して、改めて勇気を持って登壇して良かった・・・とめちゃくちゃ噛み締めていました。 こういうのはモチベーションがめちゃくちゃ上がるので本当にありがとうございます🙏 持参して良かったもの 缶バッジ 前日に会社に寄ってから小田原に向かったのですが、その際に会社にある缶バッジメーカーで缶バッジを作成しました。 今回持参した缶バッジの柄はXのアイコンと、XのURLをQRコード化したものなのですが、Ask the speakerや懇親会の時に大活躍してくれてめちゃくちゃ良かったです。 なお、こちらの缶バッジメーカーは今後弊社がカンファレンス等のスポンサーを行う際にも活用していくそうです！直近の RubyKaigi 2024 でのスポンサーブースでの配布企画 は本日5月7日締切ですのでまだ申し込んでいない方はぜひお申し込みください！（申込者全員にお渡しできる予定です） 無印の吊るして使える洗面用具ケース 介護キャリア事業の同僚の @tatsunori_ta のXで流れて来てめっちゃ良さそう！！と感じて買いに行きました。 結論は、めっちゃよかったので洗面用具入れと電化製品入れ用に2個買いました笑 今回は間に合わなかったのですが、Anker Prime Charging Stationも買ったのでRubyKaigiではこっちも持参して万全の体制で参加します！ 最後に 改めて、セッションに聞きに来てくださった方々、PHPカンファレンスの運営してくださった方々、社内の登壇準備をお手伝いしてくださった方々には本当に感謝です。 また、実際にはPHPカンファレンス小田原に行ってないけどこのブログを見て興味を持ってくださった方は引き続きエンジニアを募集しているのでこちらも見ていただけたら幸いです。 careers.bm-sms.co.jp

こんにちは、プロダクト推進本部人事のふかしろ( @fkc_hr )です。 わたしは2022年にエス・エム・エスに入社して、ついに3回目の現地参加となります。 本日は RubyKaigi 2024 の協賛についてのご案内です。 rubykaigi.org カンファレンスの右も左もわからない状態で最初に参加したのが三重で行われた RubyKaigi で、エンジニアの後ろをついて行きつつ、シャトルバスの案内をしていました (笑)。エンジニアの方や人事・広報の方とお話をしている中で、共通の悩みを相談できたことが新鮮で、2日目からもっと積極的に伺えるようになりました。複数年参加してみて、顔見知りの状態で最近どうよ？と会話させていただくのも醍醐味だなと感じています。知り合いが増えていくのもまさにコミュニティという感じですね。 セッションやLT、Rubyコミッターの方のお話など、技術面での知識がなくても試行錯誤されてる過程を知ることも好きなので、今年のプラン的にはブースチケットも頂いているのですが、普通のスポンサーチケットを使わせてもらうことになりました。 さて、こんな振り返りやイベントの準備をしている楽しさが溢れ出してしまったことと、ブースでたくさんの人にお会いしたい気持ちから、こちらの記事で告知やメッセージをお届けします！ Platinum Sponsor として協賛し、今年はブースを出します RubyKaigi は2016年から毎年協賛しており、2024年はついに Platinum Sponsor として協賛することが出来ました。ブースも設営予定のため、皆さんと会場の様々な場所でお話できることを楽しみにしています。 ブースでは、エス・エム・エスの事業の中でも Ruby や Ruby on Rails を利用しているカイゴジョブの実際のソースコードなども公開予定です！ また、事前申込みを頂いた方にはブースにてご自身のSNSアイコン *1 の缶バッジをプレゼントさせていただきます。 サンプル RubyKaigi 期間にエス・エム・エスのブースに取りに来ていただける方は以下のフォームよりご応募ください！ careers.bm-sms.co.jp ※応募者数により、抽選とさせて頂く可能性がございます。 ※5月6日頃を目安に一次受付を終了とさせていただきます。 エス・エム・エス社員も10名以上参加します エス・エム・エスはカンファレンスへの参加も奨励されており、弊社技術責任者の @sunaot や登壇を予定している @coe401_ 、その他にもRubyistの @moro , @shinkuFencer , @katorie を含めた社員が合計10名以上参加予定です。 5月15日〜17日に沖縄にて開催される RubyKaigi 2024 にて、弊社所属の @coe401_ が「An adventure of Happy Eyeballs」のタイトルで発表を行います！Day1（15日）16:40よりSmall Hall にて！ #rubykaigiB #rubykaigi https://t.co/sLSevMBM8h — SMS Tech | 株式会社エス・エム・エス (@BM_SMS_Tech) 2024年4月26日 また、今年初の試みである 学生支援 も無事に決定し、一緒に沖縄に行く予定です。 当日はすこし目立ちそうな格好をしたいなと思っているので乞うご期待です。 社内メンバーの推し記事紹介 ブースやフライヤー、当日の会話を含めてエス・エム・エスのどんなことを皆さんにお届けしたいかを社内で議論していたところ、伝えたいことがどんどん出てきて、ブースの会話だけでは時間が足りなくなりそうになりました。「このテックブログの内容がいいんだよね」というコメントが多くあったため、各メンバーの「推し記事」をコメントと併せてこちらでご紹介します！ １. @coe401_ の推し記事（その１） tech.bm-sms.co.jp エス・エム・エスでは、カンファレンス参加や専門書籍・コンテンツによるメンバーの学習を広く支援しています。福利厚生が充実しているように思えるかもしれませんが、実はそうではありません。 十分なクオリティの仕事をするため、我々プロダクト組織で共有する価値観について技術責任者の @sunaot が綴り、公開当時大きな反響をいただいた記事です。 ２. @moro の推し記事 tech.bm-sms.co.jp Day1に登壇する塩井 @coe401_ の入社エントリーです。「やっぱり世の中が良くなるような仕事がしたい」「今よりももっと技術力を高めたい」「Rubyが好きな人々と一緒に働きたい」という考えで入社し、いまも活躍中です。 ３. @fkc_hr の推し記事（その１） tech.bm-sms.co.jp ブースにて紹介予定のカイゴジョブのデザインリニューアルについてのブログです。日々ユーザーに提供できる価値はないのか？とマーケットと向き合っているからこそリニューアルの意思決定も出来ています。 ４. @fkc_hr の推し記事（その２） tech.bm-sms.co.jp スナップショットでサービスにとって今必要な設計をするのではなく、サービスに継続して関わり、成長段階に合わせて必要な設計をし続ける、アーキテクトという役割についての説明をしています。2021年に公開している記事ですが、今でも社内で大事にされている考え方です。 ５. @katorie の推し記事 tech.bm-sms.co.jp この記事の元ネタは、技術責任者である @sunaot が社内向けに2日にわたって行った『プロダクト開発組織のバリュー説明会』の一部文字起こしです。全社の経営理念・バリューの説明からはじまって、プロダクト開発組織としてのバリューにおちていくのですが、私にとってこの説明会はエス・エム・エスの一員としてどんなふうに仕事をしていくべきか、あらためて考えるいい機会となりました。弊社に興味をもってくださった方には是非ご一読いただきたい記事です！ ６. @coe401_ の推し記事（その２） tech.bm-sms.co.jp 現在エス・エム・エスで働くメンバーは皆、エス・エム・エスが事業を行う業界への興味や理解を抱いて入社したのでしょうか？ 実際に社内でアンケートを取ってみると、意外な？結果が返ってきました。業界への興味やミッションへの共感だけではない、エス・エム・エスで働く魅力をお伝えします。 他にもいくつも記事が上がったのですが、このあたりで終了にしておきます。ぜひ社員の推し記事も直接聞いてみてください！ 最後に つらつらと告知をしていましたが、とにかく伝えたいのは今年の RubyKaigi も非常に楽しみですし、みなさんと楽しみたい！ということです。 すこしでもエス・エム・エスに興味を持ってくださって、もっと話したいよと思っていただいた方は以下からカジュアル面談にお申し込みください。 *1 : 申込フォームに指定していただいたXアカウントで設定しているプロフィール画像。

初めまして。株式会社エス・エム・エスBPR推進部の新沼元樹（にいぬま もとき）です。 3月14日、15日の2日間に渡り開催されたアマゾンウェブサービスジャパン合同会社主催のワークショップAWS JumpStart 2024に参加してきました。 以下では、AWS JumpStart 2024の内容とその中で得た学びについて皆さんに共有していきたいと思います。 aws.amazon.com AWS JumpStart 2024に参加した理由 私はAWSを使い始めてまだ3か月程の初心者でした。日々の業務で分からないことがある時には近くのメンバーに聞いたり、AWS公式のドキュメントを参考にしてきましたが、どうしても断片的な知識になってしまい全体像がつかめずにいました。 今回参加したAWS JumpStart 2024のターゲットは、 AWS について話を聞いたことはあるが使ったことはない EC2 等の単体サービスは触ったことあるが、システム全体の設計経験はない クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい とまさに私のようなAWS初学者を対象とした内容であることを知り、これを機にシステムアーキテクチャ設計やAWSの理解度を引き上げたいと思い、参加することに決めました。 AWS JumpStart 2024のアジェンダ AWS JumpStart 2024のアジェンダは以下の通りです。 AWSやアーキテクチャ設計に関する講義 チームに分かれてのWebアプリケーションのアーキテクチャ検討 ハンズオンワークショップ day1では、AWSサービスやアーキテクチャに関する講義やハンズオン形式によるAWS体験とインプット中心の内容となっており、day2では、day1で学習した内容を踏まえてアーキテクチャ図を作成するといった内容になっていました。 設計に関する講義による学び AWSのコアサービスの概要の理解 これまでAWSが提供している様々なサービスの紹介動画を見て学習してきましたが、私自身エンジニアとしての経験が浅いこともあり、断片的な理解に留まっていました。しかし、今回は講義中に分からないところがあればすぐにAWSの社員の方々に質問し理解へと繋げる事が出来ました。また、参加者の多様な視点からの質問もあり、それが全体の理解を深めることに役立ったと感じています。 サービスを安定させるための仕組みの理解 AWSでWebサービスを構築するには、それぞれの段階に応じたAWSサービスの組み合わせが重要です。このワークショップでは、プロトタイプの段階から一般公開、そしてユーザーが数十万人まで増加した場合に適したサービスの組み合わせについて学ぶことができました。 例えば、プロトタイプの段階では、ユーザー数が少なく、できるだけシンプルな構成が求められます。この段階では、EC2とRDSを使用した構成で一般的には問題ありません。しかし、ユーザー数が増えて一般公開する段階では、可用性や拡張性が重要となります。そのため、ALBを使用したロードバランシングやAuto Scalingを利用したサーバーのスケーリングなど、より堅牢なアーキテクチャを構築する必要があります。さらに、ユーザー数が増加しても安定したサービスを提供するためには、静的コンテンツの配信やデータベースへの負荷軽減が重要です。この場合、CDNやS3を活用して静的コンテンツを配信し、RDSのリードレプリカを設置することで、スケーラビリティとパフォーマンスを向上させることができます。 この具体例は、実際に講義の中で取り上げられたものであり、異なる段階でのAWSサービスの組み合わせを包括的に理解できる有益な経験でした。重要なのは、各段階における適したアプローチが存在し、実際には例で取り上げられた組み合わせ以外にも、プロジェクトの状況や性質によって選択するサービスや組み合わせが変わることです。AWSには200を超えるサービスが存在し、プロジェクトのニーズに合わせて柔軟なアーキテクチャを検討することの重要性を理解すると同時に、今後さらにAWSサービスの知識を深めていきたいと思いました。 アプリケーションのアーキテクチャ検討による学び アーキテクチャ設計に関する講義を受けた後にアーキテクチャ図の作成に取り組みました。まず、1チーム3〜4名に分かれて、当日に与えられた規模やシステム要件、機能に基づいてアーキテクチャを設計しました。最適なアーキテクチャ図を作成するために、チーム内で様々なアイデアを出し合い、方針を決めていくプロセスはとても貴重な体験でした。AWSのさまざまなサービスを活用して1つのサービスを設計し、具体的な構成図を作成するプロセスの中で私が重要だと感じたポイントは次の通りです。 要件の徹底的な理解と分割 アーキテクチャを設計する前に、要件を十分に理解し、細かく分割して考えることで必要な機能やリソースが見えやすくなると感じました。 シンプルな設計からのスタート 最初から過度にアーキテクチャを作りこむのではなく、シンプルな設計からスタートすることで必要最低限の機能やリソースを備えたシンプルな設計を基礎として、徐々に機能やリソースを追加しやすいと感じました。 これらのポイントを意識しながらアーキテクチャを設計することで、より信頼性の高いシステムを構築することが可能になると全体を通して感じました。 終わりに AWS JumpStart 2024への参加を通じて、AWSにおける知識や洞察を深めることができました。今回のワークショップは初学者の私にとって、日々の業務に活かすための基礎を築くことができました。ワークショップでは、AWSのコアサービスやアーキテクチャ設計に関する理解を深めるとともに、実践的な経験を積むことができました。一般的なリファレンスアーキテクチャの理解や、要件の徹底的な理解と分割、シンプルな設計からのスタートというポイントは、今後のシステム設計において必ず活きてくると思います。今回得た学びを踏まえ、より効率的かつ信頼性の高いシステムを構築していきたいと考えています。

こんにちは、カイポケのリニューアルプロジェクトを担当しているプロダクトマネージャーの田村恵( @megumu_tamura )です。今回は、介護事業者向け経営支援サービス「カイポケ」のユーザーである、ケアマネジャーの松本さんに1日密着させていただいた活動について紹介します。この活動は、「ユーザー訪問のすゝめ: BtoB SaaS開発組織におけるユーザー理解のための取り組み」の記事でも触れたコンセプトに沿ったものです。 tech.bm-sms.co.jp ユーザー訪問の目的 私たちの目的は、カイポケをどのように活用しているか、及びカイポケの使用に限らずケアマネジャーが直面している課題を把握することです。現場の実情を深く理解し、それを機能開発の基にすることが、優れたプロダクトを生み出す上で欠かせません。従来から実施しているユーザー訪問に加え、今回は課題に対する理解を一層深めるために1日密着というアプローチを採りました。 ケアマネジャーって何をしている人？ ケアマネジャーは、在宅介護が必要な利用者及びその家族に対し、適切なケアプランの作成と実施を支援する専門家です。彼らは利用者の生活状況や健康状態を評価し、適切な介護サービスを提供するための調整を行い、利用者が自宅で安心して生活できるようサポートします。さらに、ケアプランの進行状況を定期的に確認し、利用者の状態に合わせてプランの調整を行います。 このプロセスを通じて、ケアマネジャーは利用者と家族の生活品質の向上を目指し、多様な職種と連携しながら役割を果たしています。今回は、ケアマネジャー松本さんが担当する利用者宅への月1回のモニタリング訪問に同行させていただくことになりました。 現場での学び 9:30に駅で松本さんと合流し、そこから私たちの1日密着がスタートしました。 合流直後、松本さんが車内で利用者のケアプランと利用票の更新作業に慌ただしく取り掛かりました。さらに、日程の途中でコンビニに立ち寄り、急遽更新が必要になったケアプランを印刷する場面も目撃しました。これは、朝一番で訪問する予定の利用者のサービスが変更になり、新たに計画したケアプランに同意を得る必要があったためです。 この瞬間を通して、松本さんが毎日向き合っている事務作業の現状とその膨大な量を直接感じ取ることができました。車内での利用者情報の更新から、予期せぬケアプランのコンビニでの印刷に至るまで、ケアマネジャーの業務はオフィス内でのデスクワークだけにとどまらず、移動中を含む多様な状況で進行するという実態に直面しました。我々が想像していたケアマネジャーの仕事（事務所での書類作成や計画の立案、そして利用者宅を訪問する際に準備された資料を携えてのモニタリング）は、実際にはもっと多岐にわたり、状況に応じた迅速な対応が求められていることを学びました。松本さんの日常業務を垣間見ることで、ケアマネジャーが直面する課題の複雑さや、それらに対処するための取り組みが、より明確に理解できました。 そこからも、30分の訪問と30分の移動を繰り返し、6件のご利用者宅訪問と社内会議に同席させていただきました。 訪問の際、松本さんは利用者の状況を確認し、ヒアリングを行いながらタブレット上で現在のケアプランを参照してモニタリングを実施していました。カイポケを活用することで、松本さんが効率的に情報を管理し、ケアマネジメントの質を向上させる一助となっている様子がうかがえました。 また、ある訪問先では、急に状態が悪化した利用者さんに対して、松本さんがプランの変更や福祉用具の追加提案を行っている場面がありました。利用者さんは、松本さんの提案に対し、「松本さんが言うなら、それが一番いいんだろうね」と信頼を込めて返答していました。このエピソードからは、松本さんと利用者との間に築かれた深い信頼関係の存在が伺え、その信頼がケアプランの適切な遂行を可能にしていることがわかりました。 実際に松本さんの日常業務に同行したことで、介護現場のリアルな声や、カイポケの使用状況やニーズについて深く理解することができました。 訪問に参加できなかったチームメンバーには、Slackを通じてリアルタイムで報告を行い、全員が一体感を持って1日密着のプロジェクトに取り組めるようにしました。また、この体験をもとにした資料（下記画像参照）をまとめることで、具体的な問題解決に向けた議論を深める土台となりました。 当日のタイムライン コミュニケーションの実態 特に印象的だったのは、電話が依然として重要なコミュニケーション手段であったことです。松本さんは、コミュニケーションツールの導入によって電話対応が8割程度削減されたと感じているとおっしゃっていたのですが、実際には1日に17件の架電と3件の入電がありました。この数字は決して少ないとは言えない数字でしょう。このギャップは、実際の現場を訪れ、日々の業務を観察することの重要性を浮き彫りにしました。 ケアマネジャーにとって、電話がなぜ依然として重要なコミュニケーション手段であり続けるのか、その理由は多岐にわたります。例えば、緊急の連絡や高齢者との対話など、直接的なやり取りを求める場面が多いためです。コミュニケーションツールは効率を大幅に向上させることができますが、ケアマネジャーの業務の性質上、完全に電話を置き換えることは困難だと再認識することができました。 プロダクト改善への洞察 この体験を通して、ケアマネジャーの仕事の全体像や、彼らが直面している具体的な課題を深く理解することができました。また、日常業務の中でカイポケがどのように利用されているか、どのようなサポートがさらに必要なのかについても、新たなインサイトを得ることができました。これらの学びは、今後のプロダクト開発において非常に貴重なものとなり、ユーザーにとってより価値の高いサービスを提供していくための重要な指針となります。 コミュニケーションの実態に関しても、電話対応の削減という初期の期待とは異なり、ケアマネジャーにとって電話が依然重要である理由を理解することができました。この点は、カイポケの機能改善や新機能の開発において、重要な考慮事項となります。 今回の訪問では、カイポケのプロダクトマネージャーであるキム ダソムも同行してくれました。私たちは、松本さんの日常業務を観察し、実際の使用状況やニーズについて深く理解することができただけではなく、共通の経験を共有することで、プロジェクト内でのコミュニケーションがよりスムーズになり、「あの時のあのケースのこと」を話題に出すだけで、具体的な状況を思い出し、解決策について話し合えるようになりました。 おわりに 今回のような現場密着の体験は、プロダクト開発を行う上で不可欠なプロセスであり、ユーザーのリアルな声を直接聞き、そのニーズに応えることができるサービスを提供するための基盤となります。今後もこのような活動を継続し、介護業界全体の課題解決に貢献していく所存です。 私自身、元々介護業界に10年在籍していたので、業界への想いは強く、介護業界にある課題を解決したいと常々思っているのですが、改めて、松本さんのようなケアマネジャーの皆さんに役立つプロダクトを作っていきたい！という強い意欲を持ちました。 最後に、この取り組みやブログとして掲載することを快諾してくれた松本さん、および訪問させていただいた全ての方々に心からの感謝を申し上げます。ありがとうございました！

はじめに カイポケリニューアルのフロントエンドエンジニアの原野です。2023年10月より入社し、前職ではiOS/Webのエンジニアをしていました。 カイポケリニューアルプロジェクトでは、データ取得に GraphQL を採用しており、クライアントのライブラリとして Apollo Client を使用しています。 GraphQLは、データの要求と取得をより効率的に行うことができる技術です。しかし、その機能を直接fetchメソッドで扱う場合、複雑な状態管理やキャッシュ戦略を自前で実装する必要があります。 ここでApollo Clientの出番です。 Apollo Clientは、これらの課題を解決するための強力なライブラリであり、開発者がデータの取得、管理、キャッシュの最適化を容易に行えるよう支援します。 今回、開発の中でApollo Clientのキャッシュの仕組みを理解するタイミングがあったため、その内容を共有したいと思います。 想定読者 想定読者として、Apollo ClientやGraphQLについて概要を理解しており、実際に利用したことがある、もしくは利用を検討している人などを想定しています。 Apollo Clientのキャッシュ機能の理解 Apollo Clientの魅力の一つは、フェッチしたデータを効率的にキャッシュする機能にあります。Apollo Clientは、取得したデータをオブジェクト単位で正規化し、それをキャッシュに保存します。 例を挙げると、以下のGraphQLのスキーマがあるとします。 type Team { id: ID ! name: String ! members: [ Member ! ] ! } type Member { id: ID ! name: String } このスキーマで、TeamオブジェクトとそのMemberオブジェクトがフェッチされると、Apollo Clientはそれぞれを独立したエンティティとしてキャッシュします。キャッシュのキーは、エンティティのtype名とIDを連結して生成されます。（例：Team:cGVvcGxlOjE=） 正規化をすることにより、もし複数のコンポーネントが同じデータを要求する場合でも、Apollo Clientは既にキャッシュされたデータを再利用することで、不要なネットワークリクエストを削減できます。 例えばプロジェクト内で、チーム情報とメンバー情報を表示するページが複数ある場合、Apollo Clientのキャッシュは自動的にこれらの情報を管理し、ページ間でのデータの一貫性を保ちながらリクエストの数を減らすことができます。 発生した問題とその解析 Apollo Clientのキャッシュ機能を使用する中で、期待と異なるデータ取得の問題に直面しました。 この問題は、クエリ（A）を実行するとその結果がキャッシュされ、その後クエリ（B）を実行すると、（B）の結果に（A）のキャッシュ結果が影響を与えてしまうというものです。 上の例で言うと、クエリ（A）では「Teamのmembersにはチーム全員」が含まれ、クエリ（B）には「membersに特定期間所属している、membersをフィルタした結果」が入っているケースなどです。 この場合、Team自体が同じIDを持っていて、子要素のmembersの値が異なっていた場合でも、親であるTeamのIDが一致している為、Apollo Clientはキャッシュの値を利用し、サーバーへの再取得を行いません。 初期の解決策とその限界 この問題に対処するために、最初に試した解決策はfetchPolicyをno-cacheに設定してキャッシュを完全に無視することでした。これにより、常に最新のデータをサーバーから取得することができます。しかし、この方法ではrefetchQueryを使用したときにデータが更新されないという新たな問題が発生しました。 refetchQueryの仕様の深掘り バックエンドのデータを更新した後、フロントエンドでその変更を即座に反映させたい場面でApollo ClientにはrefetchQuery機能が用意されています。 mutationの際にrefetchQueryを指定すると、完了後にrefetchQueryで取得したQueryが再取得されます。 以下の例だと、update実行時にQueryAで取得したデータが再取得されます。 const [ update , { loading , error }] = useMutation ( MUTATION_QUERY , { refetchQueries: [ 'QueryA' , ] , } ); しかし、fetchPolicyの設定によっては、期待したようにデータの更新がトリガされないことが判明しました。Apollo Clientのソースコードを詳細に調べた結果、特定のfetchPolicy設定下ではshouldNotifyがfalseに設定され、結果として更新が行われないことが明らかになりました。 この挙動は、当時自分が探した中ではApolloの公式ドキュメントに明確には説明されておらず、遭遇した当初は原因の把握に時間がかかりました。 github.com 採用した解決策: 新たな型の導入 最終的に、期間でフィルタされたMemberを含むTeamオブジェクトをTeamWithFilteredMemberとして新たな型で定義することで、この問題を解決しました。 Apollo Clientはこの新しい型を別のエンティティとして扱い、期間フィルタされたクエリと全メンバーを含むクエリの結果を適切に区別してキャッシュします。 学び Apollo Clientのキャッシュ機能は非常に強力ですが、その内部動作を理解せずに使用すると予期せぬ挙動に直面することがあります。特に、同じオブジェクトの異なる表現を扱う場合、キャッシュ戦略を慎重に考える必要があり、場合によっては似た情報でも別のオブジェクトとして定義する必要もあります。 まとめ Apollo Clientは便利ですが、機能も複雑化しており問題に遭遇した際の解決が難しい場合もあります。この記事が似たような問題に遭遇した方の解決に役立てば嬉しいです。 参考文献 https://www.apollographql.com/docs/react/caching/overview/ https://github.com/apollographql/apollo-client

3月7日から3月9日に開催されたPHPerKaigi 2024に、エス・エム・エスのメンバーが参加してきました&弊社もGOLDスポンサーとして協賛いたしました！ この記事では、メンバーの印象に残ったセッションの紹介・感想をお届けします！ phperkaigi.jp 1. NE株式会社 やまもとひろやさん 「パフォーマンスを改善するには仕様変更が1番はやい」 fortee.jp パフォーマンス改善の選択肢として仕様変更を含める発想がなかったので学びの多いトークでした。 "パフォーマンス改善"が"元の挙動を必ず保つ必要がある"かどうか、またユーザーが本質的に求めているものは何かを考えることは、フォーマンス改善以外でも重要だと感じたので、今後はこれらの視点を常に意識していきたいと思います。 （執筆：宮部） 2. 合同会社テンマド 山岡広幸さん「CSRF対策のやり方、そろそろアップデートしませんか」 fortee.jp CSRFについてはWebアプリケーションの脆弱性としては定番であり対策方法も広く知られていますが、10年以上前の書籍にも対策が書かれているくらいなので「現在のWebアプリケーションとして」を意識したアップデートということで興味を惹かれました。 広く知られているトークン方式以外にもSameSite属性Cookie、Originヘッダー、Sec-Fetch-*ヘッダーなど複数の手法が紹介されていましたが、「フレームワークが用意している方法を使う」というまとめと、「使っているフレームワークのことをよく知ろう」というメッセージも印象に残りました。 （執筆：橋口 @gusagi ） 3. そーだいさん「キャッシュと向き合う キャッシュと共に生きる」 fortee.jp 「キャッシュは麻薬」は確かにその通りだなと思いつつ、ある程度のサービス拡大を見越してアーキテクチャを設計する場合はキャッシュと向き合うことは避けられないので悩ましいテーマだと思います。 また、キャッシュを使う上で大事なこととして紹介されていた内容はどれも大事なことで、すごく納得感のある内容でした。アーキテクチャ設計を行う際は、改めて資料を読み直してみたいと思います。 （執筆：橋口 @gusagi ） おわりに カンファレンス開催に尽力された運営のみなさま、スピーカーのみなさま、ありがとうございました！

はじめに 介護事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。今回の記事は少し前の取り組みなのですが、私が導入を推進した『不具合分析』について紹介したいと思います。真新しい取り組みではないのですが、本記事を通じてエス・エム・エスのQA組織のことを少しでも知ってもらえれば幸いです。 不具合分析の導入 導入の経緯 私が入社した当初、不具合分析の導入をQA組織として目指していたのですが、日々の業務に忙殺されてそこまで手が掛けられていない状況でした。前職時代に不具合分析の経験があったのと導入へのモチベーションが高かったので、志を同じくする有志のメンバーを募って導入活動を推進していくこととしました。次項からは実際の導入フローに沿って順に説明していきます。 導入時にやったこと ① 不具合のデータ化 「カイポケ」では不具合管理システム（バグトラッキングシステム）にJira Softwareを使っているのですが、その当時は記録に残すことや開発チームとの情報のやり取りが主な使用用途でデータとしての管理ができていませんでした。そこで、まずは不具合をデータとして活用するために、以下のカスタムフィールドを追加して分類毎にデータを収集できるようにしました。 カスタムフィールド一覧） 分類 説明 テストフェーズ 不具合を検出したテストフェーズを分類 例）DEVテスト、STGテスト、本番テスト など 不具合種別 不具合の種別を分類 例）新規、既存 など 検出種別 検出した不具合の内容を分類 例）機能不備、レイアウト不備、性能、ユーザビリティ など 検出分類 不具合を検出した経路を分類 例）QA テストケース、QA テストケース外、開発 など 原因分類 不具合が混入した原因を分類 例）仕様理解不足、仕様検討不足、コミュニケーション不足、コード実装不備 など ② 不具合データ集計の仕組み化 次に収集したデータを集計&グラフ生成するためのツールとしてGoogleスプレッドシートを選定しました。Jira Softwareのダッシュボードも検討の対象にあがったのですが、2次元でのグラフ表現や期間指定が思ったようにできなかったので除外となりました。 Googleスプレッドシートでは以下の仕組みで集計&グラフ生成をしています。 Jira Softwareの不具合情報をdataシートに取得 データ更新は手動で実施すると手間がかかる部分なので、Googleのアドオンである「 Jira Cloud for Sheets 」を使って毎朝自動でデータが更新されるようにしています。もちろん最新のデータが必要な場合は手動での更新も可能です。 集計シートでdataシートのデータを集計 集計はチーム毎、案件毎、期間毎を指定できるようにして集計範囲の自由度を高めています。もちろんチーム毎＋案件毎、チーム毎＋期間毎といった複数の要素を組み合わせての指定も可能です。 グラフシートで集計シートの内容をグラフ化 カスタムフィールドの分類毎の集計はもちろん、任意のカスタムフィールドを2つ指定して自由度の高い2次元集計を可能にしたことで、より分析の精度を高められるようにしています。 改めての説明ですが不具合データ集計の全体像は以下の通りで自動で行っています。 不具合チケット作成時にカスタムフィールドを入力 毎朝8:00にデータを取得 データを集計&グラフ生成 ③ 不具合分析資料のテンプレート化 QA組織のメンバー全てが不具合分析の経験があるわけではなかったので、導入のハードルを下げる、一定品質のアウトプットが出せる、といったことを目的に不具合分析資料のテンプレートを情報共有サービスのesaを使って作成しました。テンプレートにはいくつかのグラフサンプルと分析のポイントを記載していて、テスト中のモニタリングや、テスト終了後のふりかえりでも使えるようにしてます。 テンプレート記載内容一部抜粋） 導入後のお話し どう活用している？ 現状は不具合が多く検出されたプロジェクトや案件を対象に、テスト終了後に不具合分析実施して良かった点や悪かった点がないかを確認するといった、ふりかえり目的での使用が多いです。不具合分析の結果からテストの優先度を検討する上で参考にしたり、開発/テストプロセスでの課題を可視化することができたり、といった一定の効果も見られています。 また、不具合分析として活用する以外にもデータとして可視化することで全体の傾向が把握できるなど、QA組織全体で不具合に対する意識が高まったと感じています。 優先度検討の例 重大な不具合（ユーザー影響が大きい）が検出されない機能は優先度を下げる 開発/テストプロセス課題可視化の例 単体テストで担保すべき不具合が多く単体テストの範囲や粒度に問題があった 機能仕様検討不足やコミュニケーション不足が多く情報共有に問題があった 今後の課題は？ 導入はしたものの、以下の課題は見えていて積極的な活用とフィードバックや情報発信が必要になると考えています。 一部のチームでしか活用できていないのでもっと範囲を広げたい 開発組織全体で不具合に対する意識が高まるようにしたい プロセス改善や品質改善につながるような効果を出していきたい 品質のモニタリングとしての活用をしていきたい さいごに 今回紹介した「不具合分析」は、QA組織の行動指針の中でも挙げている取り組みの一つとなります。そちらのブログも合わせて確認していただけると、QA組織の目指しているものがより鮮明に見えると思うので、お時間あれば是非ご確認ください。 tech.bm-sms.co.jp これからプロダクトもどんどん成長していき、それに伴い一緒に働く仲間もどんどん必要になってきます。少しでも興味を持っていただけましたらカジュアル面談や選考へのご応募をよろしくお願いいたします。

カイポケ・データプラットフォームチームの河本と申します。以前にSMS Tech blog では 「なぜ介護事業者向け経営支援 SaaS「カイポケ」でデータプラットフォームをこれから作るのか」 では介護を取り巻く社会環境の観点からデータプラットフォームに求められる要件について、 「「マーケットに向き合う」エンジニアと経営陣がいたからこそ爆誕したデータプラットフォームチーム」 ではデータプラットフォームチームのこれまでの進捗について、社内でのミッション設定やチーム組成について語ってきました。 tech.bm-sms.co.jp tech.bm-sms.co.jp この記事では、これらの記事に続いて、データプラットフォームのシステム構成と背景にある設計の指針や思想について解説します。 データプラットフォームの価値発揮領域 データプラットフォームの機能を通して実現したい価値は以下のように整理できると考えています。 プロダクト施策のための主要なプロダクトメトリクスのダッシュボードをつくる エンジニア/PdMがデータを障害対応に利用し、円滑かつ安全な復旧対応ができる環境 (将来的に)顧客とのコミュニケーションのためにアクションを働きかけるいわゆる“Call to Action”を実現する また、これを実現するためのチームの機能的な要件として以下のような特質についても備えておくことが効果的であると感じています。 利用者がデータを信頼して利用し、データプラットフォームチームへの気軽なフィードバックが可能な環境 組織内の用語が統一され、高いレベルの共通理解の下で開発に関わるコミュニケーションが取れる環境 データプラットフォームをめぐる制約条件 データプラットフォームの構築にあたり、制約条件として以下のような要素を検討しました。 要配慮個人情報を取り扱っていること ドメインの性質上、取り扱いに慎重な配慮を要する個人情報を含んだデータベースを扱う システムが複数のサービス・コンポーネントに分割されていること カイポケリニューアルプロジェクトではマイクロサービスアーキテクチャを採用しており、フロントエンド、バックエンド共に複数のサービス・コンポーネントに分割されている 社内のルールが規定されていない新しい領域を開拓していること データプラットフォームチーム自身が情報セキュリティや運用ルールなどに対して自ら提案、発信していくことも求められる 法律に定義された業務を支援するSaaS特有の複雑性 関連法規の改正に伴い、頻繁に変更されるシステムにデータとその活用が追従しなければならない データプラットフォームのシステム要件 セキュリティ カイポケのデータベースに格納されている情報には要配慮個人情報を含まれています。データプラットフォームには、現時点では直接エンドユーザ様が利用したり、影響を受けるサービスを提供する予定は無いですが、チーム運営に欠かせないコンポーネントとして一定以上に高い可用性を持つ必要があります。 長期間にわたって多くの利用者に安全に、安定して利用できることを目指しているデータプラットフォームにおいて情報セキュリティの三要素である「可用性」「機密性」「完全性」はいずれも重要な性質です。 以下に説明していくシステム構成には、例えば以下のようにこれらの考慮が反映されています。 可用性 現在は非常に小規模なチームで構築・運用を行っているデータプラットフォームチームの制約上、高い可用性をコストパフォーマンスよく実現するため、マネージドサービスも適宜活用して運用負担の軽減を図っています。 機密性 (PIIについて) カイポケはサービスの性質上、要配慮個人情報(個人の健康・医療情報など管理上特別な配慮を要する情報)を保有しており、これらの情報が安全に管理されることを担保する必要があります。 データプラットフォームでは要配慮個人情報に対する保護策として、BigQueryでの列レベルのアクセス制御もしくはViewへのアクセス制御などを通じて、権限設定のレイヤーで安全性を担保する予定です。 システム構成 データプラットフォームが構築するシステムの構成は以下の構成の通りとなっています。現在も構築の過程にあるので、今後もある程度は変動する可能性があります。 システム構成 カイポケではクラウドプラットフォームとしてAWSを利用していますが、データプラットフォームではGoogle Cloud Platform(以下GCP)を採用しています。選定に当たってはチーム内で様々な観点(コスト、セキュリティ、パフォーマンス、運用経験者の採用の容易さなど)から比較検討を行い、BigQueryを中心とするGCPのプロダクト群を中心に設計することに決めました。 全体構成 システム全体は3層の構成をとっています。3層構成にした意図は安全性と柔軟性を高いレベルで保つためであり、以下のそれぞれの層についての解説を読んでいただくことでその具体的な設計意図が理解いただけると思います。 セキュリティに関する前提として、インフラの構成変更に関する作業は全てIaC(Terraform)のCI/CDを通して行われ、意図した変更のみが実行されることを担保しています。 1層目 - landing層 1層目のlanding層ではカイポケのデータソース (* 現在のところスコープはRDSに限定) のコピーを保有し、BigQueryに保存します。この層でのBigQueryはデータベースの保有している情報を全てコピーすることに徹しており、原則として加工されていません。 データベースへのコピーはGCPのDatastreamサービスを使ってAWSで構築されているカイポケのデータベースの論理レプリケーションでBigQueryへの転送を実現しています。 この層のアクセス権限はデータの内容に踏み込まず、単純なコピーを行ったデータが保存されており、要配慮個人情報も格納されているためデータに直接アクセスできる権限は厳密に業務上必要最小限の範囲に限定する必要があります。 2層目 - transformation層 2層目のtransformation層では、1層目に転記されたBigQueryのデータをdbt Cloud を用いて書き換え、データマートを形成するための層です。 複雑なドメインである介護事業者向けSaaSのデータベースの生のデータは、ビジネスメトリクスの間にはデータセマンティクスのギャップが大きいです。そのままでは細かいレベルのドメイン知識がなければデータを扱いにくいため、この層でビジネスメトリクスに落とし込むための意味的な変換も行っています。 3層目 - presentation層 3層目のpresentation層では、ビジネスKPIの状況をダッシュボードで確認するための層です。現時点ではLooker Studioを利用することを想定しています。プロジェクトの進行に伴い、必要に応じてTableauや Lookerなどを比較検討することも考えています。 まとめ: 現在取り組んでいること データプラットフォーム構築のインフラ基盤と分析パイプラインの構築は現在「ワンパス通っている」状態(完成度を問わなければ必要最低限の業務の流れが全て流せる状態)に到達しています。今後もデータプラットフォーム内のサブプロジェクトとして「プロダクトメトリクスダッシュボード」「信頼されるデータ環境づくり」「開発者の調査に使えるデータ環境づくり」「ユビキタス言語の開発」「クライアントログの整備」など、各方面から信頼される高品質なデータプラットフォームに到達するまでにやりたいことがたくさん積んである状態です。 データプラットフォームチームは副業メンバーの構成比率が高く、カイポケ開発とは密接に連携しながらも独立した別のシステムを構築したり、関係部署と独自の連携をとったりなど多様な業務を少人数で行っているという意味で、やや変わった特徴のあるチームとも言えそうです。システム開発の経験はもちろんとても役に立てることができますが、システム開発そのものにどっぷり専念するよりももっと多様な活動をしてみたいというエンジニアの皆様には興味を持っていただけると思います。 この記事を最後まで読んだ読者の方の中で、こうしたデータプラットフォームの開発に興味を持った方がいらっしゃれば、ぜひカジュアルにお話しできればありがたいです。

（2024年3月21日追記：以下の募集は締め切りました。ご応募ありがとうございました！） はじめに エス・エム・エスでエンジニアリングマネージャーをしている @emfurupon777 です。 5月15日〜17日にRubyKaigi 2024が開催されます(会場： 沖縄県那覇市 那覇文化芸術劇場なはーと)。 弊社はPlatinumスポンサーとして協賛し、ブース出展もさせていただきます。 rubykaigi.org 当日は弊社技術責任者の @sunaot や登壇を予定している @coe401_ をはじめとする弊社社員たちが参加予定です。 今回、弊社としてははじめての試みとして、学生さんのRubyKaigi参加を支援します。 チケット代や交通費・宿泊費を自己負担することなく、カンファレンスに参加することができます！ 本記事では支援の概要と、応募方法についてお知らせいたします。 支援人数 3名〜5名 支援応募条件 RubyKaigi のポリシー ( https://rubykaigi.org/2024/policies/ )に合意いただき技術を楽しんでいただけること 大学、大学院、高専、専門学校に所属する学生であること（※学校種別・学部・学科・専攻不問ですが、支援決定の方には学生証等の確認をさせていただきます） カンファレンス終了後、SMS Tech Blog ( https://tech.bm-sms.co.jp/ ) に参加体験記・ブログを書いていただけること 支援内容 RubyKaigi 2024参加チケット RubyKaigi 中の宿泊費 ご自宅最寄り空港からの往復交通費(沖縄県外在住の方) 当日のエス・エム・エス社員との交流にかかる費用（ランチ会、懇親会等） 当日のその他のサポート（楽しんでいただけるよう、必要に応じてエス・エム・エス社員がお手伝いします） 任意：エス・エム・エス社員とのカジュアル面談 支援参加フロー 書類選考 オンラインでの面接（1回） 参加決定 ※選考にあたっての必須事項 - 卒業予定年 - GitHubアカウント - RubyKaigi参加経験の有無と参加したい理由(簡単な内容で大丈夫です) - これまでの制作物やエンジニアとしてのアウトプット(URLや簡単な説明) 応募フォーム 下記リンクから遷移した先に設置されているボタンから入力フォームに遷移し、ご応募ください。 RubyKaigi 2024 学生エンジニア参加支援応募 (https://open.talentio.com/r/1/c/smsc/pages/90239) 募集期間 2024/03/20(水) 18:00まで 最後に 弊社が RubyKaigi をはじめとする技術カンファレンスに協賛や学生支援を行う理由については下記のような記事をご覧いただければと思います。 技術を楽しみ、社会に貢献し続ける組織で成長していく醍醐味を知っていただけると幸いです。 tech.bm-sms.co.jp tech.bm-sms.co.jp tech.bm-sms.co.jp すでにエンジニアとして就業している皆様へ ここまで読んでいただいてありがとうございます。 弊社では一緒に働く仲間を募集しています。ご興味が少しでもありましたらカジュアル面談をさせていただけると幸いです。

エス・エム・エスで開発者をしている @koma_koma_d です。 昨年末、弊社としては初めて、アドベントカレンダー企画を実施しました！ qiita.com tech.bm-sms.co.jp 今回の記事は、アドベントカレンダーの実施の「ブログ運営チーム視点での」ふりかえりです。 なぜアドベントカレンダーを実施したのか 直接のきっかけは「やってみたい」という声をブログ運営チームとは関係のないところで酒井さん @_atsushisakai が「やりませんか？」と提案してくれたことです。以前ブログでも紹介した「社内版potatotips」には元々知見の共有に積極的なメンバーが集まっていて、その参加者の間で複数人「アドベントカレンダーやるなら書くよ！」という人がいたことから動き出しました。 tech.bm-sms.co.jp ブログ運営チームとしては、手を挙げてくれていたメンバー中心でアドベントカレンダーが成り立ちそうというのが見えていたのに対して、執筆のサポート体制作りや、記事公開の媒体の一つとして会社のブログを使ったりするにあたって必要なプロセス作りの部分に関わることになりました。 酒井さんにアドベントカレンダー実施の声かけをなぜしたのか、というのを振り返ってみてもらったところ、 以下のように考えていたそうです。 単純にエス・エム・エス社員によるアウトプットを増やすことはもちろん、アドベントカレンダーというお祭りを理由に普段あまり記事を書く習慣がないメンバーにも執筆してもらい、それによって、記事を書くことの面白さ・難しさを体験してもらいたいと考えていました。 もちろん仕事の中で「ブログ記事を書く」ということにはハードルはあると思います。「これは大変」と思う人もいれば、一方で「意外と書ける」と思う人もいるでしょう。このような執筆者としての感覚を持つためには、まずは具体的な体験してもらうことが大事で、さらに社内外からフィードバックが発生することで「大変だけど書いてみてよかった・面白かった」というサイクルまで運良く体験できていけば、今後のブログ運営にとって、組織的に良い経験値になると思いながらも、実際はそういうことはあまり語りすぎず、勢いで声掛けをしていきました。 背景としての SMS Tech Blog の現在地 この「SMS Tech Blog」は、2021年3月に最初の記事が投稿されてから、ちょうど3年が経とうとしています。だいたい週1本ペースで投稿を続けることができていて、これまで投稿されてきた記事は130を超えました。 元々採用のことを意識して始まったブログということもあり、自発的に記事が書かれる文化を醸成するよりも先に、運営チームと採用チームが主導した記事づくりが定着していました。そのような記事は、伝えたいメッセージや情報が明確にあったり、企画しやすいコンテンツとしての「引き」が見込まれるものを記事にしていることもあって、エンジニアが日頃のエンジニアリングの延長で書く「技術ブログ」と比べて「ちゃんとしている」と感じられてしまうことが社内でも多くあったようで、会社のブログに記事を書くことへのハードルの高さを感じてしまう人も散見されるようになってしまっている側面がありました。 tech.bm-sms.co.jp tech.bm-sms.co.jp しかし、現在のブログ運営チームの意図としては、（もちろん採用にプラスの効果があれば嬉しいですが）ブログは社内のメンバーのためのアウトプットの場の一つとして、 もっと気軽に活用してもらえると嬉しい と考えています。同僚にレビューを頼みやすくて、運営メンバーの執筆サポートも受けられて、業務に関する内容も書きやすいというのが会社のブログの特徴なので、ブログを書くのに慣れていない人にもぜひ活用してもらいたいと思っています。こういった意図を定期的に伝えるとともに、気軽に書いてもらえるような工夫をすることで、最近では少しずつ自分から「書きます！」と手を挙げてくれる人も出てきましたが、まだまだ運営側で声をかけたところから始まる記事が多いのが実態で、まだまだ課題に感じているところです。 そういったなかで、今回酒井さんから提案があり、それに呼応するメンバーが複数いたということで、ぜひ一緒にやろうということで実施する運びとなりました。 アドベントカレンダーを実施するにあたってブログ運営チームとして工夫したこと 以上のような背景でアドベントカレンダーを実施するにあたり、運営チームとしていくつか工夫をしました。 まず、レビューのプロセスを執筆者にとって軽量になるように心がけました。会社の名前を掲げた企画である以上、会社としての広報という側面が出てくるので、全てノータッチというわけにはいかないのですが、統制を最低限で済ませられるようにしました。具体的には、媒体として会社のブログだけでなく個人のブログやZenn、Qiitaなども利用できるようにして、会社のブログに書かない場合はほぼ煩わしさを感じないで済むように配慮しました（普段の個人ブログでのアウトプットについては会社からの統制というのはありません）。会社のブログに書く場合も、あらかじめガイドラインを共有し、説明を行うことで、レビュー段階での手戻りの発生が減るようにしました。 また、レビュー以外の観点でも、執筆が楽になるようにしました。会社のブログに書く場合は、記事公開にまつわる内容面以外の部分（入稿やアイキャッチ作成など）を普段からそこに慣れているブログ運営チームが担うことで、執筆者には記事執筆に集中してもらえるようにしました *1 。 一方で、執筆のサポートが欲しい人が気軽にサポートを要請できるように運営チームで体制を整えておきました。また、投稿先を問わず、ピアレビューとして（運営チームの会社ブログへの投稿時のレビューとは別に）誰かに記事のレビューをしてもらえるようにしました。執筆者本人が適当な人を見つけられない場合には、運営チームがレビュワーを務めたり、適切なレビュワーを紹介するようにしました。これらの取り組みで、執筆者の負担を極力増やさずに、執筆をサポートし記事の質を向上を図りました。 アドベントカレンダーを実施してみて まず、「アドベントカレンダーやりますよ、書きたい人手を挙げてください」と案内されてから早々に25日分の枠が埋まったのが嬉しい驚きでした。特に、過去に会社/個人のブログへの執筆の経験のない人も何人か参加してくれたのが良かったです。アドベントカレンダーというものの性格ゆえという側面はあったかと思いますが、今後のブログ運営、アウトプット文化の醸成という観点でも示唆が得られました。 また、無事に25日分の記事が全て遅れなく公開され、完走することができました。「遅れなく完走した」という点については、本来実現したい自発的なアウトプットにとっては不要な圧迫を与えているという見方もできると思いますが、「書くと決めていれば書けるかも」と思ってもらえた人がいた点や、頓挫してしまわないようにハードルを下げたりサポート体制を作ったりした成果と見ることもできる点で、ポジティブに捉えています。 参加したメンバーからは以下のような感想がありました。 締切がないとなかなか書けないので良い機会でした。 ネタ思いついてなかったけど、とりあえず書くと決めて何か考えようとする過程が良いふりかえりになったし、最近考えていることを言語化できたのはよかった。 レビューをすぐやってもらえてよかった。ブログに対して、XやSlackでコメントをもらえるととても嬉しい。 一方で、改善が必要な点や課題も見つかりました。 まず、12月1日から25日まで毎日記事を公開するというフォーマットに関する問題意識です。25日連続となると当然休日も含まれるわけですが、休日は技術ブログへのアクセスやSNSでのシェアが減る傾向があるので、社外の人に読んでもらうという観点で休日公開は効率が悪いです。また、会社Slackでの紹介も休み明けにまとめてになってしまって、読んでもらいにくくなってしまうと思いました。もし今後もアドベントカレンダーをやるとしたら、 25日連続というフォーマットにこだわらず、平日に限定して記事を公開する形でやるのがよい と考えています。 また、公開した記事を社内のメンバーに読んでもらうという点でも課題を感じました。この季節は、他の会社や技術コミュニティのアドベントカレンダーもあるので、ただでさえ読みたい記事が溜まりがち（私もChromeのタブが大幅に増えていました……）ですが、自社のアドベントカレンダーの記事だけでも毎日出ていると全て目を通すのは大変です。せっかく書いてもらったのにフィードバックが少ないと勿体無いので、フィードバックが得られやすいような工夫をしたいと考えています。たとえば、事後に改めて記事を振り返るきっかけとなるような社内イベントを開くなどを検討しています。 おわりに 以上、会社として初めて行ったアドベントカレンダーについて、ブログ運営チームの立場でのふりかえりをご紹介しました！今回のアドベントカレンダーは、実装の部分ではブログ運営チームも関わりましたが、 ブログ運営チーム以外のところで話が挙がって参加者も集まっていた のが特徴でした。ブログ運営チームとしては、プロダクト開発組織のメンバーが快適に楽しくアウトプットできるような場を整えるところには当然尽力していきたいと思いますが、今回のような自発的な動きが出てくるような文化・雰囲気が更に定着・醸成されていくように、社内の色んなメンバーと一緒に取り組んでいけるとよいなと考えています。 *1 : ここは公開作業自体をGitHubなどを使って誰でもできるようにすると運営チーム含めもっと快適になる可能性もあると考えていますが、今のところは手作業でやった方がいい部分が残っているので手作業メインの運用になっています。

介護事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの宗です。２０１８年に入社し、早いものでこの春には７年目に入ります。（自分としてはまだ４年経ったくらいの気分なので、数えてみては毎回驚いてます） 今回は、エス・エム・エスに中途で入社して以降、自分がどんなことをやってきたかを振り返りつつ、一部を具体的にご紹介してみようと思います。今と状況が変わっているところもありますが、エス・エム・エスでの仕事ってどのような雰囲気だろうと気になっている方の参考になれば嬉しいです。 これまでやってきたこと 私は入社当初から、カイポケのレセプト機能周辺をメインとして担当してきました。最初の数年は現在稼働しているカイポケについて改修や改善、機能追加を行い、その後 カイポケのリニューアルプロジェクト に異動して今に至ります。異動後は介護における請求業務周りの整理やモデリングを経て、それらの結果を元に日々開発を進めています。 ここで言う「レセプト機能」とは、介護施設や事業所が、提供したサービスに応じた報酬を国に請求するための機能群です。詳しい内容は割愛しますが、簡単に言うと、利用者の方々の状態を元に毎月どのようなサービスを提供するかのスケジュールを立て、実際にサービスを提供し、その結果を元に請求する、というサイクルを楽に行えるようにするものです。 さて、この６年の間、継続的に介護保険制度の請求にまつわる部分に関わってきたのですが、その中でも印象的だったものを挙げるとすれば、制度変更に対応するためにカイポケで新しいサービスを扱えるようにしたことと、リニューアルプロジェクトにおいて、イベントストーミングを用いて請求業務のドメインを捉え直したことでしょうか。後半はこの２つについて、少し掘り下げようと思います。 法改正によるサービス追加の対応 介護報酬の文脈での「サービス」とは、事業所が介護報酬を国へ請求する際に「利用者さんへどういったケアを提供したか」「事業所の体制を健全なものとするためにどういった取り組みをしているか」といったことを表すための統一されたメニューのようなものです。基本的には「どのサービスを、いつ、誰に提供したか」という情報を元に請求が行われます。 現行のカイポケの開発を担当していた頃、法改正により新たなサービスが導入されるということがありました。法改正において、サービスの追加自体は珍しいことではないのですが、その時新たに定義されたサービスはこれまで扱われてきたものと少し異なる報酬計算が必要なものでした。そのため、既存のコードに手を加え、新しい計算方法に対応したロジックを入れることとなりました。 （介護報酬の計算については、こちらの記事を読んでいただくとイメージがつきやすいかと思います） tech.bm-sms.co.jp 一連の対応は、他のメンバーとペアになって行いました。当時の私は、介護報酬の計算についてはまだまだ初心者だったので、新たな計算方法とそこへつながる前提知識をペアの方に教えていただきつつ、既存コードで関連のありそうな場所の見当をつけていきました。請求金額を計算する箇所もそうですが、UIからユーザーが当該のサービスに関する設定を編集できるようにする必要もあったため、そういった画面やコードについてもユーザーストーリーマッピングで洗い出し、調査していきました。調査を終えて修正内容の方針を決めた後は、既存コードのリファクタをしたり可能な範囲でテストコードを書いて、見通しを良くした上で実際のロジック追加を行う……というように進めました。 また、制度が施行されるタイミングまでは、この新しいサービスは存在しないものとして扱わなければなりません。新サービスの設定周りのデータによって制度施行の前後で不具合が起きないよう、特定のタイミングでデータパッチを当てるといった対応も行いました。 思い返してみると、これがはじめて報酬計算の複雑さにしっかり向き合ったタイミングだった気がします。加えて、既存の機能に手を入れるためにはシステム、制度それぞれについての理解が不可欠であるものの、実際にはそれで十分ではなく、ユーザーがカイポケの中で計算へ至るまでの道もちゃんと把握・整備してはじめて「対応できた」と言えるんだということを実感しました。 イベントストーミングによる請求業務の整理 前節のサービス追加対応を終えてから数年後、現在も所属しているリニューアルプロジェクトへ異動しました。当時やるべきこととしては（ユーザーが事業所を運営していく中で特に重要な）請求業務のドメインの再整理がありましたが、元々複雑な領域のため、ドメイン駆動設計（domain-driven design、以下ではDDDと書きます）を使って進めていくことになりました。 とはいえ、DDDの考え方に則ってドメインを整理していくという作業は初めてのことだったので、プロジェクトの有識者に助言や並走をしてもらいながら Domain-Driven Design Starter Modelling Process に挙げられている８つのステップに沿って、チームで少しずつ取り組んでいきました。ここに挙げられているワークの一部は、当時実施するには時期尚早であまり具体的に分析できないといったものもありましたが、特に２つめのステップで推奨されていた イベントストーミング は得るものが多く、自分にとっても刺激的なものだったと記憶しています。 イベントストーミングでは、大まかに言うとユーザーの行動やそれに付随して発生する判断の内容、その際に参照される情報などを付箋に書き出し、タイムラインに沿って並べていきます。その過程でドメインへの理解を深め、DDDで言うところの集約や境界づけられたコンテキストを探っていくのですが、最終的に１枚の大きな、ドメインの地図とも言えるようなものができあがった時、それまでカイポケの開発を通して自分の中に作られてきた断片的な知識が補完され、繋がりを持って可視化されたような感覚を持ちました。また、その結果をベースとして障碍や医療分野での請求業務についてもある程度整理したところ、介護分野との差分やそれぞれに特有の困りごとがあることがわかり、その性質の違いも興味深いものでした。 イベントストーミングを実施した後には、その結果を元にしてDomain-Driven Design Starter Modelling Processの後続のワークを進めたり、ユビキタス言語の検討などを行っていきました。またプロジェクト単位でも、マイクロサービスの分け方やチーム編成を考える際に活用するということもありました。これまでの開発で作られてきたものは、イベントストーミングを通じて得られたドメイン理解が土台となって積み上げられたものだと感じています。 おわりに 今回の記事を書くにあたって、過去の業務内容を全体的に振り返るということをしたのですが、これがなかなか大変な作業でした。しかし振り返っていくにつれて、介護保険制度の、特に請求にまつわる部分にいろいろな角度から触れてきたのだなという実感も沸いてきました。請求業務や報酬計算への理解が深まるほどにその複雑さも身に染みて感じられるようになり、それが「この分野（特に報酬計算）をどうにかきれいにモデリングして、自然な形のコードに落とし込みたい」という今のモチベーションに繋がっていったように思います。嬉しいことに、現在リニューアルプロジェクトでそれを叶えられる立場にあるので、目指したところに少しでも近付けていけるよう、今後も頑張っていきたいと思います。 ここまで書いてきたことが、どなたかの参考になれば幸いです。もし記事の内容について「このあたりの話をもっと詳しく聞いてみたい」など興味を持たれた方がいましたら、カジュアル面談も実施中ですのでお気軽にお声がけください！

こんにちは。介護事業者向け経営支援サービス『 カイポケ 』でエンジニアリングマネージャー（以下EM）を担当している橋口( @gusagi )です。 今回の記事は、以前に公開した記事『システム障害対応訓練をゲームライクにやってみた』で紹介した訓練を行うまでにどんなことを考え、どんな準備をしていたのかを紹介したいと思います。 tech.bm-sms.co.jp 今回の記事は、訓練の舞台裏を紹介するものとなります。どんなことをやったのかを知ってからの方がイメージしやすくなる部分もあるかと思いますので、まだ読んでいない方がいましたら先に読んでもらえると嬉しいです。 誰と、どんな風に始めたのか まずは、システム障害対応訓練を行うことだけが決まったところから、テーブルトークRPG（TRPG） *1 の形式をとってシミュレーションを行うことを決めるまでにどんな思惑があったのかを紹介したいと思います。 システム障害対応訓練を行うことが決まってからは、一緒に訓練の準備を進めてくれるメンバーを集めるところから始めました。これには幾つかの理由があります。 一つ目は、この取り組み自体の属人化をなるべく防ぐためです。 訓練を行うきっかけはテックリード不在時の対応に関する不安からでしたが、システム障害対応訓練自体は一回やって終わりにするのではなく継続的に行った方が効果が出るものだと思います。 この考えをベースにした場合、提案をした人物が準備から実施までを担うよりは、複数人で最初から最後までやることで知見を共有し、チーム内で改善しながら取り組める状態を作った方が良いと考えました。 二つ目は、この企画に関わるメンバーに面白い経験をしてもらいたいと思ったからです。 システム障害の対応訓練はこれまでチームで取り組んだことはなく、それなりに年季の入った私のキャリアの中でもほぼ経験がないチャレンジングな取り組みでした。 この取り組みをやり切ることができたなら、企画の中心となって取り組んでくれたメンバーは貢献実感を得つつキャリア的にも面白い経験を積むことができると考えました。 三つ目は、この取り組みを私一人で成功させられるイメージが浮かばなかったからです。 当時の私はチームにJOINしてそこまで期間が経っておらず、訪問看護チームでシステム障害に対応する際の流れや、押さえておくべきポイントに対する理解が浅い状態でした。この状態で一人で抱え込んで進めても、実際の障害対応とはかけ離れた机上の空論となってしまい、参加者の時間というコストに見合わない成果しか得られない可能性が低くありません。 それよりは、メンバーに助けてもらうことで意味のある訓練にしたいと考えました。 これらの理由から、訓練そのものをどうやって作り上げるかを考えてくれるメンバーを募り、一緒になってイメージを膨らませていきました。 具体的な方法として、システム障害対応訓練のイメージを膨らませるためのテンプレートを私の方で作った上で、メンバーと一緒にテンプレートに肉付けをしていく進め方をとりました。 以下は、実際のテンプレートの一部となります。 当時は「防災訓練」と呼んでいたためテンプレートにおいてもそのように記載されていますが、ここは読み替えていただけると助かります。 以下のフォーマットは「確定している情報を記入する」というものではなく、フォーマットに従って必要な情報を記入していくことで、防災訓練に必要な情報が集約されている状態を作るためのものです。 その時点で決まっている or 仮置きできる内容を埋めていくだけでも意味のあることなので、適宜アップデートしながら情報を充実させていきましょう！ このフォーマットを元にして防災訓練の個々のページを作成していくことを想定しています。 作成するページ名は `FY2023.#1 XXXを目的とする防災訓練` として、何年度の何回目の訓練で、何を目的としているかがパッとみてわかるようにして欲しいと思っています。 仮に防災訓練が定着していった場合に、**いつ頃にどんな訓練を行ったのかが個別のページを見たり検索しなくてもわかるようにしたい**から、というのが最大の理由です。 # 防災訓練の概要 ## 目的と期待する成果 - 目的 - **xxxxx** - 期待する成果 - **xxxxx** > エンジニアだけでなく、POや運用、QA、サポートといった人が見ても「防災訓練を行なった方が良い理由」や「やることによるメリット」がわかるように書きましょう。 > ここの説得力があるかないかで、時間を割いてでも防災訓練を行うことに対して理解・協力を得られるかが変わってきます。 ## 開催時期 YYYY年MM月DD日 HH時 > いきなり日時を決めるのは難しいため、最初のうちは「YYYY年MM月くらい」のようなフワッとした情報で構いません このようなテンプレートに肉付けをした結果で決まったのが以下の方針でした。 お客さまからのお問い合わせをトリガーとして、問題の調査や解決を進める流れとする 実際にシステム障害を起こしたりはせず、チーム内でシミュレーションを行う形とする ただし、ログや各種メトリクスの調査は、ある程度まで実際にやってみる そのシーンで実行できるアクションは選択肢を提示しつつも、それ以外にも参加者が考えて何をするか決めて良い インシデント時のガイドラインに則って専用のSlackチャンネル作成なども行う チーム外に不要な混乱が起きないよう、事前の周知を徹底する他、当日のSlackチャンネル名などにもシステム障害対応訓練であることを明記する 上記を満たす方法を検討した結果、TRPGの形式を取るのが良さそうだという話になりました。 主な理由が「リモートワークで会話しながら対応を進める実際のシステム障害対応に近しい状況での訓練ができる」、「進行役としてGMが存在する方が柔軟に対応できる」、「遊び心を入れて楽しみながら取り組めるようにしたいと思った」であることは、 以前の記事 にも書いたとおりとなります。 当日までにどんな準備をしていったのか 次に、どんなことを考えてTRPG形式でのシステム障害対応訓練を準備していったのかを紹介したいと思います。 この時期、ゲームマスター（GM）役を担当してくれるエンジニアとシナリオの準備を進めていたのですが、私が考えていた方針は以下の３つでした。 準備に参加しているエンジニアや私自身も目一杯楽しみながら準備を進められること ちょっと変わった面白いと思える取り組みをやろうとしていることをチーム内外にも認知してもらうこと チーム外、特にプロダクト開発組織の外に対して不要なハレーションが発生するのを避けること せっかくやるのだから自分たちも楽しみながら取り組みたいですし、その取り組み自体になるべくポジティブな印象を持ってもらうことで、今後同じような取り組みをやりたいと思える人や応援してくれる人を増やしていきたいと考えていました。 当時の予定の件名が「防災訓練のシナリオを悪巧みする会」「悪巧み2」などとなっていたことからも、ノリノリであれこれ考えていたことが読み取れます。 一方で、訪問看護チームのPdMやテックリードにも協力してもらい、訓練を行う際のチーム外への周知をはじめとする気をつけるべき事柄を洗い出しながら、不要なハレーションが起きないように準備をしていきました。 ただ、実際に訓練のことを周知した際の反応は、懸念していたハレーションがないだけでなく、「面白そうな取り組み」「良さそうなのでがんばって」などの後押ししてくれるものでした。 こういう反応を貰えたことは、訓練の準備という実務面だけでなく心理的にも非常にありがたく、モチベーションが上がったのは言うまでもありません。 余談ですが、実施した際は「防災訓練」と呼んでいたこともあり、一番多かった反応は「防災訓練っていうから実際に避難とかするのかと思っていた」でした。 命名って大事だなと思います。。。 訓練当日を迎えて 当日については、改めて書くことはほとんどありません。 前回の記事に書いたように訓練の進め方（ルール）への質問が何度か発生したり、時間が押してしまったりと想定と異なる状況は発生しましたが、GM役のエンジニアが臨機応変に対応してくれたことで、参加者には楽しみながらも実際の障害のように緊張感を持ってもらえたと思います。 GMという大役を無事にこなしてくれたメンバーには感謝の気持ちでいっぱいです。 ふりかえりを効果的に行うためにやったこと 最後に、ふりかえりを行うまでの工夫について簡単に紹介したいと思います。 訓練に参加した人数が多かったこともあり、限られた時間の中で効果的にふりかえりを行うため、以下の工夫をしました。 感想や気付き、今後に対する意見をGoogleフォームで訓練の実施直後に書いてもらう Googleフォームの回答をふりかえりで使うmiroに画像形式で貼り付けて、ふりかえりの準備の段階で見ることができるようにする YWTベースとしつつも「Tの候補から実際のアクションを絞り込んで議論を深めること」を目的とした形に崩して実施する この工夫の軸としては「事前にできることはなるべく事前に行う」「T（次にやること）の深掘りと意見交換にフォーカスできるようにする」となります。 人数が多い状態で付箋の書き出しと読み上げを素直に実施すると、全員の思ったことの共有はできてもその次に繋げる議論をする時間が取りにくくなります。そのため、訓練を行った当日のうちにGoogleフォームで意見を出してもらうことを最初にやりました。 その上で、ふりかえりを行うmiroのボードにGoogleフォームの回答を画像として貼り付けた上で、自分の意見だけでなく他の人の意見も確認しながらY（やったこと）とW（わかったこと）を事前に記入してもらいました。 結果として、思い出しや書き出し、意見の読み上げに対する時間を短縮しつつ、フォーカスしたい項目の深掘りと意見交換に時間を割くことができ、元記事にも書いたように企画した側の想像を超えて付箋がいっぱいになり、チームが主体的に取り組んで多くの気付きを得られたと考えています。 あとがき 何を考えどう準備してシステム障害対応訓練を行ったかを紹介しました。 この記事が、この記事を読んだ人にとって「こんなやり方もあるのか」という参考になればすごく嬉しいです。 また、エス・エム・エスではカジュアル面談も実施しています。 採用という観点で興味を持ってもらえるのはもちろん嬉しいのですが、この記事に書いてあるシステム障害対応訓練の話を聞いてみたい、という興味でも大歓迎です。 もし少しでも興味を持ってもらえたなら、気軽にカジュアル面談に応募してもらえればと思います。 *1 : TRPGに興味のある人は 富士見書房さまによる紹介ページ や Wikipedia の記事もご覧ください

はじめに 介護事業者向け経営支援サービス「カイポケ」のプロダクトマネージャーを担当している 田村 恵 です。 この記事では、介護業界における複雑な業務サイクルを システム思考 （ Systems thinking ; Wikipedia ）を用いて新たな角度から捉えた試みについて紹介します。介護業界は、たくさんのステークホルダーと業務が複雑に絡みあうことにより、SaaSを提供するためのドメイン理解が非常にチャレンジングです。私たちは、ケアマネジャーの業務サイクルを視覚的に表現することで、業界(マーケット)の理解と業務に関するドメイン理解を深めることを目指しました。この記事では、その過程と成果について詳しく紹介させていただきます。 どんな方に読んでほしいか この記事は、特に介護業界に関わるサービスの開発者、さらには介護業界に関心を持つ方々にとって有益な内容です。また、複雑な業界やドメインを視覚化し、より深い理解を目指すすべての方々にも、この試みからの学びがあると思います。 ケアマネジャーの複雑な業務サイクル 居宅介護支援事業所のケアマネジャーは、利用者のニーズに応じたケアプランの作成、実行、評価といった多岐にわたる業務を担います。私たちが作成した図は、これらの複雑な業務を視覚的に表現し、ケアマネジャーの役割と業務をより明確にすることを目的としています。この図では、以下の4つのサイクルが描かれています。 経営サイクル：法人や事業所の長期的な経営戦略と日々の運営を結びつける ケアマネジメントサイクル：利用者の生活の質を高めるための計画的なケアを提供し、サービス事業所による実際のサービス提供を評価する 月次サイクル（請求サイクル）：サービス事業所によるサービスの提供から請求に至るまでの月次の流れ 日次サイクル：日々の利用者との接触、緊急時の対応など、日常業務の細部 これらのサイクルは、それぞれ独立しているように見えますが、実際には互いに影響を及ぼし合っています。そのため、この複雑性を理解し、適切に管理することは、効果的なケアマネジメントに不可欠です。 ケアマネジャーの業務サイクル 図作成のきっかけとプロセス この図の作成は、チームメンバーの三浦がシステム思考での表現に長けていたことから始まりました。三浦のラフ案を基に、ドメインエキスパートでありプロダクトマネージャーの田村が、自身の経験や数多くの調査を通じて加筆し、図を仕上げていきました。このプロセスは、チームの多様な知見とスキルを組み合わせることで、より深い理解と表現を可能にしました。また、実際にこの領域でユーザー価値を提供する目的で、それぞれのイベントにおける業界特有の課題や理想についても追記し、プロダクト開発に生かしていきました。 ユーザー訪問によるブラッシュアップ さらに、私たちはユーザー訪問を通じて介護業界の実態を掴み、図をブラッシュアップしていきました。実際の現場の声を聞くことで、図に反映された概念が実際の業務プロセスとどのように連動しているかをより深く理解することができました。このアプローチは、理論と実践のギャップを埋め、より現実に即した表現を可能にしました。 ステークホルダーの反応と機能開発への影響 ステークホルダーからのポジティブな反応は、私たちの努力が実を結んだ証です。イベント間の関連性や課題の可視化により、業界の理解が深まり、新しい機能開発に向けた具体的なアイデアが生まれました。私たちは、この図をベースに、次に開発する機能がどのイベントのペインに対する価値を提供するのかを意識しながら、よりターゲットを絞った機能開発を進めています。 また、この図はチーム内の全員がヘビーユースしていて、開発者同士の議論の場にもよく登場するほど大活躍のツールになっています。 まとめ 介護業界の複雑なサイクルをシステム思考で捉えることは、私たちに新たな視点を提供しました。チームの協働、ユーザー訪問による現場の声の反映、そしてステークホルダーとのコミュニケーションは、この取り組みを成功に導きました。 BtoB SaaSと聞くと、複雑そうだなという印象を持たれるかもしれませんが、今回の取り組みで少しでもBtoB SaaSの面白さを感じていただけたら嬉しいです。 今後もこのようなアプローチを活用し、介護業界のさらなる発展に寄与していきたいと考えています。