こんにちは！夏ですね。 @kimukei です。 今回は、弊プロジェクトの カイポケリニューアル で ADR を導入しましたというお話です。 ADRとは、「Architecture Decision Record」または、「Architectural Decision Records」の略でアーキテクチャ上で重要な決定を記録するドキュメントです。 詳しくは「 DOCUMENTING ARCHITECTURE DECISIONS 」 や「 Architectural Decision Records 」をご覧ください。 また ADR については、以前弊社の酒井が登壇したイベントでも触れられておりますので、こちらの記事もあわせて読んでみてください。 tech.bm-sms.co.jp ADR を導入しましたってエントリは巷には溢れかえっているので、今回はちょっと趣向を変えて実際に私たちが運用している ADR の形式にそって 「ADR を導入する」という意思決定に至った流れを書いてみようと思います。 以下に ADR の実例を示します。 ADR を導入する ステータス 2024年5月14日 Proposed 2024年5月17日 Accepted コンテキスト カイポケリニューアル は、プロジェクトが発足して3年以上経過している。 それゆえにすでにコンテキストは分厚いのだが、技術スタックの選定理由や当時の検討のログは散らばり、中には当時の在籍者に聞かないと詳細は不明なものがあり、疑問に思っても疑問が完全に消化しきれないことがある。 また、今後新しい技術の採用を考慮する際に、過去の選定理由やトレードオフスライダーを参照できないために、新しい技術の善し悪しの判断が曖昧になる懸念がある。 今後近いうちに、カイポケリニューアルにおいて非同期処理やイベント駆動処理の技術選定が必要になってくることが考えられる。その際の技術選定の議論やコンテキストをまとめておく必要性を感じている。 これらの課題を解消するため ADR を導入することが有効である。また、過去の情報を集めて ADR として再生成することで必要に応じて過去の意思決定も記録しておける。 決定 ADR を導入する。 ADR の目的は、他のチームや新メンバーに技術的な決定の経緯を共有すること。 つまり検討内容が完璧である必要はなく経緯を知ることで未検討な部分を後から追加検討したりできる。 アーキテクチャ上重要なものは、なるべく ADR を書く。 構造、非機能特性、依存関係、インターフェイス、構築手法の5つの観点で意思決定するものはなるべく ADR に書き起こす。 もし書くべきかどうか迷ったり気になった場合は相談相手としてADR 運用チームを指定できるようにする。 運用に慣れてきたらそれぞれのチームに相談やレビューなどを移譲する。 また、過去の意思決定について ADR があったほうがいいんじゃないかというものは GitHub Discussions ページを用意したので、そこにコメントして投票式で得票数の高いものから作っていく。 影響 新しいアーキテクチャや技術の導入の際には、議論の叩き台や決定したことの記録として ADR を書くようになることが想定される。 アーキテクチャ上のコンテキストや遵守方法が ADR に集中される。これにより参照性が高まり、新しく Join したメンバーのオンボーディングなどにも利用できる。 遵守方法 (Compliance) 構造、非機能特性、依存関係、インターフェイス、構築手法の5つの観点で意思決定するものはなるべく ADR に書き起こす。 新しいアーキテクチャや技術要素だったりを導入する際は ADR を書くことまでをなるべくタスクに含める。 ADR にはゆるめなテクニカルライティングのルールで textlint をかけているのでそのライティングスタイルに沿う。 備考 オリジナルの著者: @kimukei 承認日: 2024/05/17 承認者: ADR運用チーム、開発チーム 置き換え日: n/a 最終更新日: 2024/07/05 こんな感じです！ 参考にした ADR テンプレートは『 ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 』の第Ⅲ部 19.3 「アーキテクチャデシジョンレコード」や、 joelparkerhenderson/architecture-decision-record などです。 管理場所は GitHub 上でモノレポ化 1 したリポジトリで docs/adr/ を切ってそこで行っています。 Pull Request に discussion 履歴などが残ることや GitHub Actions があることによるCI/CDの自由度の高さ（フォーマットの遵守もそうだが、GitHub Pages に出力するなど）が便利ですし、最近だと AI の学習のためにこの手のドキュメントとコードをあまり離さないほうが良いかもしれません。 ちょうど最近弊社は GitHub Enterprise 化したので GitHub Copilot Enterprise がこの辺のドキュメントを読んでレスポンスをくれるようになりました。 運用してみて ADR のドラフトを叩き台にしてチームを跨いだ技術選定の議論が行われた たとえば、最近 SRE チームと開発の1チームでバッチ処理基盤が欲しいので作ろうという話をしていたのですが、その中で議論の叩き台として ADR のドラフトが活用されていました。 そして関係者が合意してドキュメントがまとまったら ADR の Pull Request を Ready for review にして ADR 運用チームからレビューをもらうという流れがとても自然でした。 過去の歴史を紡ぐ動きが出てきた カイポケリニューアルでは、通信に GraphQL を採用しているのですが、当時在籍していたメンバーがその経緯や考えていたことを ADR に書いてきてくれたりしました。 また、マイクロサービスアーキテクチャのトポロジーを組んでいる理由や、そもそものカイポケリニューアルに至った背景や決定が再言語化され ADR となりました。 大元の「なぜ」の部分がかなり明確になり、開発の意思決定もよりしやすくなったと感じます！ エンジニア以外の職種でもこのような決定を記録するやり方が広まった ADR は 「Architectural」な顔をしていますが、実際は Decision Record つまり決定の記録フォーマットとしても有用です。 PO や PdM でもProduct Decision Record(PDR) として、似たような決定事項やコンテキストを記録するフォーマットが使われるようになりました。 同じようなフォーマットが使われていると職種を横断してドキュメントを見にいく時も認知負荷を減らしてスッと入ってくるのでいいですね！ さいごに ADR、いい感じです！ フォーマット自体が決定の記録として有用なので汎用性があり、かなり組織文化にも影響をもたらすものだと感じます。 エス・エム・エスではともに試行錯誤しながらよいサービスを作ってくれる仲間を募集しています！ カジュアル面談も実施していますので、ぜひお気軽にご連絡ください！ カイポケリニューアルでモノレポにした話: https://zenn.dev/kimuchan/articles/f5ba954ca4fbf8 ↩

こんにちは、プロダクト推進本部人事のふかしろ( @fkc_hr )です。今年のSRE NEXTでGOLDスポンサーをし、当日はブースも出す予定です。 sre-next.dev エス・エム・エスには複数のSREチームがあり、様々な方とお話をできればと楽しみにしています。 今回は事前に一部メンバーから気になるセッションの紹介とブースでプレゼントできる缶バッジのご案内をいたします。 気になるセッション共有 大きな組織にSLOを導入し運用するということ、その難しさ カイポケSREチームの 加我 です。 サービスの信頼性の計測においてSLI/SLOを利用するというプラクティスはSREであれば多くの人が知っているかと思います。しかし、いざSLI/SLOを導入・実践しようとしても正しい運用ができず形骸化してしまい、頓挫してしまったという経験が私にはあります。DMM様のような大きな組織でSLI/SLOをどのように策定し運用しているのか興味があり、気になるセッションとして挙げさせていただきました。 医療キャリアチームSREの 伊藤 です。 医療キャリア事業には複数のプロダクトがあり、それぞれのプロダクト開発を複数のチームが担当しています。各チームの文化やSRE活動に対する習熟度にはばらつきがあります。DMM様の抱える課題感と似た問題を感じており、どのようにアプローチされているのか非常に興味があります！ Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織 全社SREの 髙橋 です。 エス・エム・エスにおいても全社SREと事業部毎のSREのハイブリッド体制を敷いています。組織としてより良いパフォーマンスに繋げるためにどのように関わっていくべきか、個人的にも日々試行錯誤しています。完璧な正解があるわけではないのですが、他社がどのようにしているか非常に気になります！ Becoming SRE - SREって何から始めればいいの？ ハピすむSREの上山です。 私自身SREという職種をあまり意識することなくエンジニア活動をしていましたが、結果的に技術スタックがSREと一致して今の環境があるので、SREを目指すとき何をしたら良いのかという観点が気になりました。 缶バッジプレゼントのご案内 事前申込みを頂いた方にはブースにてご自身のSNSアイコン *1 の缶バッジをプレゼントさせていただきます。 ※サンプル(直径57mmです) SRE NEXT 期間にエス・エム・エスのブースに取りに来ていただける方は以下のフォームよりご応募ください！ https://careers.bm-sms.co.jp/engineer/event-srenext2024 ※応募者数により、抽選とさせて頂く可能性がございます。 終わりに SRE NEXTにてみなさまとお話させていただくことを楽しみにしております！ また、SRE NEXTには参加できないが、エス・エム・エスに興味を持ってくださって、もっと話したいよと思っていただいた方は以下からカジュアル面談にお申し込みください。 *1 : 申込フォームに指定していただいたXアカウントで設定しているプロフィール画像

はじめに 2024年4月にエス・エム・エスに入社した泉澤です。現在、介護事業者向け経営支援サービス「カイポケ」のフルリニューアルプロジェクトに携わり、フロントエンドエンジニアとして機能開発を行っています。 careers.bm-sms.co.jp まだ入社して3ヶ月ではありますが、今までの経歴や転職した背景などに触れ、入社して感じた前職との違いや、この3ヶ月をどのように過ごしてきたかを振り返っていこうと思います。現在転職を考えている方や、エス・エム・エスに興味を持っている方の参考になれば幸いです。 今までの経歴と転職した背景 新卒でITメーカーに入社し、1年間法人営業を担当していました。当時は2020年でコロナ禍の最中だったため、入社早々に働き方がテレワーク中心へ切り替わる、学生時代の想像とは違う社会人生活のスタートとなりました。出社が不要になり可処分時間が増えた反面、オンライン商談やリモート飲み会など、画面越しでのやりとりに四苦八苦したことを今でも覚えています。 その後、縁あって未経験で前職の受託開発企業に転職しました。フロントエンドエンジニアとしてVue.js（Nuxt）やReact（Next.js）を用いた開発を担当し、教育、冠婚葬祭、不動産、官公庁など様々なドメインの案件に携わりました。入社して間もない頃から、慢性的なフロントエンドエンジニアの不足で開発リーダーを任せていただく機会があったのですが、エンジニアの層や案件の開始時期によっては経験できないこともあるため、早期にリーダーとしての経験を積めたことは幸運だったと思います。実装方針や技術選定の裁量権があり、環境構築からリリースまでの一連の工程に携わることができた経験は今でも代えがたいものです。フロントエンド開発の責任を背負うポジションだったため、開発に対して当事者意識が芽生え、エンジニアとして大きく成長するターニングポイントとなりました。 転職を決意したきっかけは、副業で自社開発企業の開発に携わっていた経験が挙げられます。小さなベンチャー企業でしたが、本業の受託開発企業のように納品して終わる関係性ではなく、継続して事業を成長させる働き方に魅力を感じました。副業メンバーでありながら経営会議に出席させていただいた際、チーム一丸となって何かをやり遂げる熱量に触れたことも大きな要因となっています。この経験から「継続して事業を成長させる働き方」に強い興味を抱き、転職活動を始めました。特に注視していたのは、携わる事業内容です。受託会社で様々なドメインの案件に携わってきた経験から自分の興味のある分野や自分ごととして捉えられる分野に対しては、モチベーション高く開発に取り組むことができると実感していたからです。 転職活動をする中で、様々な企業様と面談・面接をしてきましたが「自分自身が一番熱量を持って、当事者意識を持って働くならここしかない」と感じたのがエス・エム・エスでした。面談・面接の際に介護の将来についてお話を伺い、将来に対して強い危機感を覚えました。選考が進むにつれて自分がその課題の当事者となることを想像した時に、既に顕在化している問題に対して何もせずにいたことに後悔したくない。自分もその課題に取り組み、そして数十年後を振り返った時に「課題解決に貢献したんだ」と胸を張れる自分でいたいと思いエス・エム・エスへ入社することを決めました。 入社3ヶ月を振り返る 事業ドメインのキャッチアップ 入社後はカイポケリニューアルプロジェクトのケアマネジメントチームに配属されました。まず開発に関わって一番驚かされたのは、介護ドメインの複雑さです。3年ごとに見直される介護保険制度の改正も相まって、常に情報のキャッチアップが欠かせません。この背景があるため、新しい開発エピックに取り組む際の勉強会や、法改正による新しい情報の共有会などが都度、実施されているのが印象的でした。 最初の1ヶ月ほどはチームでのオンボーディングがあり、1日の中で疑問に思った用語や仕様について質問する時間を設けていただきました。社内情報ツール（esa、Notion、Miro）にある議事録も交えながら説明していただきましたが、質問した内容には大体まとまった資料が既にあることが多く、カイポケリニューアルプロジェクトでは全体的にドキュメントを残す文化が強いと感じました。また、説明を通じて必要な情報にどうアクセスするか、社内情報ツールのハウツーも学ぶこともできました。 個人的な事業ドメインのキャッチアップとしては、書籍購入制度を利用し、書籍からも学びを得るようにしています。全社向けに事業ドメインに関するおすすめ書籍が紹介されているので、迷わず優良な書籍を手に取ることができました。書籍購入制度ではもちろん技術書も購入できるので、その用途で利用している方も多く見受けられます。 フルリモートでスクラム開発に取り組む 私が所属しているケアマネジメントチームでは、開発手法としてスクラム開発を取り入れており、隔週でスプリントを回しています。複雑な開発エピックに取り組む際は、積極的にペアプログラミングやモブプログラミングの機会を設け、チームで認識を揃えながらスプリントゴールを達成できるように開発を進めています。開発チケットに関しての担当の割り振りは特になく、プルリクエストについても気づいたメンバーが対応する、自主性が重んじられる文化が根付いています。エンジニアに限らず、Slackでメンションが飛んでいなくてもスレッドに参加して意見を述べる方も多く見受けられ、当事者意識の強い方が多く在籍している印象があります。主体性の範囲が広いのは前職との大きな違いだと感じました。 スクラムイベントを含め、定期的に開催されるミーティングでは当番制でファシリテーターを回しています。質問をする前に背景情報を提示したり、枕詞を加えて言葉の意味合いを和らげたり、時には強調したりと、ソフトスキル面で多くの気づきを得ています。また、日々のミーティングの中には雑談系のミーティングも含まれているため、フルリモートで働くことが初めての私にとっては関わるメンバーの人間性を理解できる場として、逆に自分を知ってもらう場として非常に助かっています。 話が脱線してしまいますが技術的な発散の場としてはpotatotipsという週次で開催されている社内勉強会や、同じく週次ではありますが、フロントエンド技術雑談が設けられているのでフルリモートで働いていても様々な方と繋がりを持てている印象が強いです。 tech.bm-sms.co.jp 最後に 一概には言えませんが、面接官が違う職種の方や入社してから既に数年が経っている方だったりすると、入社後〜半年くらいのイメージを掬い取ることが難しく、実際に入社してみないとわからないケースがあると思います。私自身、企業に興味を持っても入社後どのような働き方になるのか想像が膨らまず見送ったことがあるので、それが少しでも解消できればと思いこの記事を執筆しました。 また、「スクラム開発が初めて」「フルリモート稼働が初めて」「介護ドメインが初めて」と不安要素が多めの状態で入社したのですが、それらを払拭する環境がエス・エム・エスには備わっていることが分かったので、同じく不安に思っている方やエス・エム・エスに少しでも興味を持っている方に伝われば良いなと思いました。 エス・エム・エスでは開発メンバーを募集しています。介護事業者向け経営支援サービス「カイポケ」のフルリニューアルプロジェクトに興味を持ったり、高齢社会や少子化という社会課題に対して挑戦してみたいという方がいらっしゃいましたら、ぜひこちらも覗いてみてください。改めて、この記事を通してエス・エム・エスに興味を持っていただけましたら幸いです。最後までご覧いただきありがとうございました。

はじめまして、介護事業者向け経営支援サービス「カイポケ」 のエンジニアの大縄です。 本記事では、カイポケの障害児支援領域のリプレースで実施したドメインモデリングについて、実際のドメインを題材にどのように実施したかを紹介させていただきます。 ドメイン駆動設計を参考に実施しているところもありますので、ご興味のある方の参考になれば幸いです。 リプレースの背景 障害福祉の制度は概ね 3 年に 1 度改定されます。プロダクトも新制度に追従していく必要があるのですが、制度が複雑であり開発日程もタイトであることから、プロダクトの仕様やコードベースを最適化することを犠牲にした結果、仕様が複雑化し、それに引きづられてコードベースも複雑度が高く肥大化した状態となっていました。 リファクタリングなどの改善は行なってきたものの、「複雑化した仕様」「肥大化したコードベース」に対して変更を入れることは容易ではなく、ユーザーへの価値提供を増やしたくても増やせない状況が続きました。 このままではまずいと感じつつもなかなか根本解決に踏み切ることができなかったのですが、次回の制度改定まで期間があり、ドメインやプロダクトに関する知識も蓄積できてきた、というタイミングが巡ってきたことから、根本的な解決としてリプレースを行うことになりました。 リプレースでは大きく以下の 3 つを行いました。 既存の仕様を参考にしつつも、複雑さを排除した新たなドメインモデルを設計・構築する 言語の表現力も借りて、基本に沿って秩序あるコードベースを再構築する ドメインモデルとコードベースに対し、変更容易性を維持する仕組み作りや取り組みをする 本記事では、「1. 既存の仕様を参考にしつつも、複雑さを排除した新たなドメインモデルを設計・構築する」に対する取り組みの一例を紹介させていただきます。 より詳細なリプレースの背景については「 ユーザーへの価値提供機会を増やすためにリプレースを決意した話 」で説明されていますので、是非ご覧いただければと思います。 題材とするドメインは「学校休業日」 リプレース対象であるいくつかのドメインのうち、「学校休業日」というドメインを題材に説明していきたいと思いますが、まずは題材の前提知識として「学校休業日」をモデリングした背景について説明します。 障害児支援領域には、学校に就学している児童に対して授業終了後または学校が休みの日に生活能力の向上のために必要な訓練や社会との交流促進などの支援を行う「放課後等デイサービス」というサービスがあります。 このサービスの利用料金の一部は自治体に請求するのですが、「授業終了後にサービスを提供した場合」と「学校が休みの日にサービスを提供した場合」で料金設定が異なり、また、サービス内容によっても料金が細かく分かれています。 カイポケには、日々のサービス提供の内容から利用料金を算出できるよう、あらかじめ学校の休業日を設定するための機能があり、この機能もリプレース対象の一つとしていたため、「学校休業日」をモデリングすることになりました。 2 つのステップで実施するドメインモデリング ドメインモデリングの定義は様々あると思いますが、以下 2 つのステップをドメインモデリングと捉えて実施しました。 【ステップ１】ドメインの理解 対象のドメインについて調べ、関係性や決まり事を整理する 【ステップ２】ドメインのアプリケーション設計 対象のドメインをアプリケーションで実現するための設計を行う 以降にそれぞれの詳細を説明します。 【ステップ１】ドメインの理解 このステップでは、対象のドメインについて調べ、関係性や決まり事を整理します。 まずは、放課後等デイサービスにおける休業日がどのように定義されているのかを調べました。 厚生労働省の資料（ 平成27年度障害福祉サービス等制度改正に関するＱ＆Ａ（平成27年3月31日） ）によると、以下のように定義されています。 ・学校教育法施行規則第 61 条及び第 62 条の規定に基づく休業日（公立学校においては、国民の祝日、日曜日及び土曜日、教育委員会が定める日、私立学校においては、当該学校の学則で定める日） ・学校教育法施行規則第 63 条等の規定に基づく授業が行われない日（例えば、台風等により臨時休校となる日）又は臨時休校の日（例えば、インフルエンザ等により臨時休校の日） なお、学校が休業日ではない日に、放課後等デイサービスを午前から利用した場合であっても、休業日の取扱いとはしない。 上記を入り口に、 学校教育法施行規則 を調べて「教育委員会が定める日」とはどんな日があるのかを把握したり、国民の祝日はどのように定められるのかを調べたりすることでさらなる理解を深めていきました。 また、今回の対象機能が「あらかじめ学校の休業日を設定するための機能」なので、事業所がいつどのように休業日を知るのかを実際の事業所にヒアリングさせていただいたりもしました。 そして、これらの内容を調査しながら整理し、以下のように図示していきました。 クラス図に近い図ではありますが、ステップ１では実装を意識せずにまとめていきました。（ドメインを理解できる形であればどのような形式でも良いと思っています。） 【ステップ２】ドメインのアプリケーション設計 このステップでは、ドメイン理解の図をもとにドメインをアプリケーションで実現するための設計を行います。 設計する際には『 エリック・エヴァンスのドメイン駆動設計 』で紹介されている "集約（Aggregates）" というパターンを参考にしました。 集約とは、関連するオブジェクトの集まりであり、以下のように実現されると理解しています。 集約の中からルートとなるオブジェクトを決め、変更は必ず集約ルートを経由する 集約ルートが集約内の不変条件（データが変更されるときに維持されなければならない一貫性のルール）をチェックする最終的な責務を負う 集約単位でデータの取得・永続化を行う 永続化の入り口には集約ルートしか渡せないし、集約ルートしか返せない 集約を利用した処理の流れを簡単に図示すると以下のようになると考えています。 カイポケ障害児支援領域のリプレース前のコードは、同一テーブルに対する処理が色々な場所で実装され、不変条件のチェックもそれぞれ実装されているケースが多々ありました。よって、集約の概念を取り入れ、関連する情報に対する不変条件のチェックや永続化処理を一箇所に集めることで重複を排除し、秩序あるコードベースを構築しようと考えました。 「学校休業日」の集約を定義する ここから実際に「学校休業日」をアプリケーションで実現するための設計をしていくのですが、まずは以下のように、アプリケーションとしてどのように学校休業日が設定できれば良いかを考えました。 公立の学校は市町村・または都道府県の教育委員会によって休業日が決まるが、私立の学校は学校ごとに校則で定められることから、学校ごとに休業日が設定できればどちらもカバーできると考える 学年ごとに休業日が異なるケースや臨時休業日があることから、利用者個別に休業日を設定できるようにもする 土日、国民の祝日はユーザーが設定できるものではないため、学校休業日を設定する際のデフォルト値として利用する（国民の祝日はシステムのマスタデータとして管理されているものを使う） 上記をもとに集約を定義し図示していきました。 集約を定義する際に考慮しなければならないこととして、「集約は小さくする」ということが挙げられます。なぜなら、データの取得・永続化やロック（楽観的排他など）が集約単位で行われるためです。集約が大きすぎると、パフォーマンスの悪化や複数ユーザーで作業ができないといった問題が発生してしまいます。そのため、「不変条件は何か」だけでなく「どのようなユースケースがあるか」ということも考えながら大きくなりすぎないように定義していきました。 「学校休業日」の場合、ドメイン理解の図に記載されているように、基本的には年度単位で休業日が決まるが月初や当日に初めて休業日を知るケースもある、ということから、何度も更新が発生することが予想され、また、利用者に対するサービス提供の業務が月単位のサイクルである、などの理由から月単位の集約としました。 また、名前付けについてもチームで合意をとりながら進めていきました。ここで定義した集約はそのまま実装に反映されるため、和名だけでなく英名も決め、アプリケーションで一貫して同じ名前を使えるようにしました。 ここでひとまず「学校休業日」の集約が定義できたわけですが、定義した集約をを使用して実際に利用者に対するサービス提供を登録することを考えると、現状のままでは利用者と学校が関連づいていないため月間学校休業日を特定できないという問題があります。 よって、ステップ１のドメイン理解に戻り利用者と学校の関連付けについて理解を深め、ドメイン理解の図を更新していきました。（利用者と学校の関連付けを「所属学校」として追記） そして、ドメイン理解の図をもとに同じように集約を定義していきました。加えて、利用者に対するサービス提供を登録するときに集約がどのように使われるかについても記載し、最終的には以下の集約定義となりました。 このように、必要に応じてステップ１とステップ２を繰り返しブラッシュアップしていきました。 ドメインモデリングは今後も続く 今回の成果物である「ドメイン理解の図」と「集約設計の図」は一度限りの図ではなく、メンテナンスし続けていくドキュメントの 1 つとしており、実際の改修の際にもまずはドメインモデリングをしてからバックエンド、フロントエンドの開発を行っています。 おわりに カイポケの障害児支援領域のリプレースで実施したドメインモデリングについて、実際のドメインを題材にどのように実施したかを紹介させていただきました。 モデリングの対象となったドメインは他にもいくつかあるのですが、振り返ってみると、チームで議論しながら進めていくことの難しさを感じることもあったように思います。しかし、ドメインに対する理解が深められ、また、チームでの意思決定が形として残ることが後の開発の助けにもなりましたので、やって良かったなぁ、と改めて思いました。 今回紹介させていただいた活動が少しでも参考になれば幸いです。

こんにちは！ 5月に株式会社エス・エム・エスへ入社しました、SREの西田和史です。 今日はAmazon Web Services（以下AWS。各サービス名も一般的な略称で表記します）周りのTipsを共有します。 解決したい課題 AWSマネージメントコンソールで特定のサービスのページを開こうとすると、たくさんのサービスがあることもあり結構手間がかかります。 よく使うサービスはホーム画面にリストで表示されていますが、リストの順番は毎回変わりますし、 検索機能も使いにくく、「ECR」など妥当なキーワードでも対応するサービスが出てこないこともあります。 解決策 Google Chromeのサイト内検索機能を使います。 手順 chrome://settings/searchEngines を開きます(もしくは次の画像のメニューのクリックでもOK) サイト内検索の項目で「追加」のボタンを押す 次のように入力して「追加」ボタンを押す 名前: awsサービスを開く ショートカット: aws URL（%s=検索語句）: https://console.aws.amazon.com/%s/home 使い方 EC2の画面に行きたい場合、 Windowsであれば Ctrl-L 、Macであれば Command-L でフォーカスをGoogle Chromeのオムニバー(アドレスバー)へ移動 aws ec2 と入力 (次の画像のような表示になる) エンターを押す コツと欠点 このテクニックを使うには、飛びたいAWSサービスのURLを予め知っている必要があります。 具体的には、IAMの画面に飛びたい場合、IAMマネコンのURLは https://us-east-1.console.aws.amazon.com/iam/home ですが、この https://us-east-1.console.aws.amazon.com/ と /home の間に挟まれた文字列である iam をGoogle Chromeのオムニバーで入力する必要があります。 この文字列は iam ec2 s3 など比較的そのままのサービスもありますが、 apigateway (API gateway)のようにスペースがないものがあったり、CloudWatch LogsやELBなど、この方法で開けないページもあります。 おまけ: この方法で開けない、ELBなどのページはどうやって開くか 諦めてGoogle Chromeのオムニバー上で loadbalancer と入力しています。 ELBのURLには loadbalancer という文字列が含まれているので、Google ChromeのオムニバーによるサジェストでELBのURLが一覧に表示されます。 何度も呼び出しているとやがて一番上にサジェストされるようになるので、最小限の手間で遷移できるようになります。

こんにちは、エス・エム・エスで人事をしているふかしろ( @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 の期間は最高に楽しく、学びの多い時間でした。 このような機会を提供いただいたエス・エム・エスの方々には感謝してもしきれません！ 本当にありがとうございました。

こんにちは。人材紹介開発グループに所属しているT・Dです。私は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などを比較検討することも考えています。 まとめ: 現在取り組んでいること データプラットフォーム構築のインフラ基盤と分析パイプラインの構築は現在「ワンパス通っている」状態(完成度を問わなければ必要最低限の業務の流れが全て流せる状態)に到達しています。今後もデータプラットフォーム内のサブプロジェクトとして「プロダクトメトリクスダッシュボード」「信頼されるデータ環境づくり」「開発者の調査に使えるデータ環境づくり」「ユビキタス言語の開発」「クライアントログの整備」など、各方面から信頼される高品質なデータプラットフォームに到達するまでにやりたいことがたくさん積んである状態です。 データプラットフォームチームは副業メンバーの構成比率が高く、カイポケ開発とは密接に連携しながらも独立した別のシステムを構築したり、関係部署と独自の連携をとったりなど多様な業務を少人数で行っているという意味で、やや変わった特徴のあるチームとも言えそうです。システム開発の経験はもちろんとても役に立てることができますが、システム開発そのものにどっぷり専念するよりももっと多様な活動をしてみたいというエンジニアの皆様には興味を持っていただけると思います。 この記事を最後まで読んだ読者の方の中で、こうしたデータプラットフォームの開発に興味を持った方がいらっしゃれば、ぜひカジュアルにお話しできればありがたいです。