この記事は株式会社エス・エム・エス Advent Calendar 2024の12月12日の記事です。 エス・エム・エスで人材紹介の社内基盤開発をしている熊谷です。 今回はそんな社内システムの1つで、Honoを使って開発している事例をご紹介します。 なぜ私たちはHonoを採用したのか？ 人材紹介事業では、CP（キャリアパートナー）と呼ばれる、従事者様の転職のお手伝いをサポートする人員がいます。 従事者様とCPとのコミュニケーションは一般的に電話やメールなどで行われますが、LINEもよくコミュニケーションによく使われる手段の1つです。 従事者様がエス・エム・エスが展開している公式LINEに登録すると、公式LINE上で従事者様専任に割り振られたCPと従事者様との1to1のコミュニケーションが可能になります。 これらを実現するために、LINE Messaging APIを使った中間のWebサーバを社内で管理しています。 元々これらの仕組みは、EC2 + PHPという組み合わせで作られていたのですが、 コミュニケーション量が増えるに伴って費用も増えてきた 処理としては簡易で、EC2で稼働させる必要性がない 時間帯や曜日によって負荷に増減があるため、スケールしやすい基盤が向いている という事情から、Lambda + Node.jsで書き換える企画がスタートしました。 このWebサーバの要件をざっくり伝えると シンプルだけど10ページ分のWebページ（フォーム画面）が必要 Cookieを使う（サーバサイド処理が必要） というもので、色々なフレームワークを比較検討した結果、Honoが良さげだぞという結論に至りました。 決定打としては「jsxがテンプレートとして使えること」「Ryan Dahl氏がDeno FestでHonoを推してたこと」の2つでした。 採用してみてどうだったか？ 非常に良い！！！ というのが感想です、私たちが開発していて実際に良かった点を列挙していきます。 テストが書きやすい Web Standard APIのRequest/Responseを利用しているからこそ、リクエスト/レスポンスのテストの書きやすさが素晴らしいです /** * index.ts */ import { Hono } from "hono" ; const app = new Hono(); app. get ( "/hello/:name" , ( c ) => { const name = c.req.param( "name" ); return c.text( `Hello, ${ name } ` ); } ); export default app; /** * indx.test.ts */ import app from "./index" ; test ( "GET /hello/:name すると、'Hello, ${name}' が返ってくる" , async () => { const path = "kumagai" ; // app.request()で定義済みルートへアクセスでき、Responseオブジェクトが返却される const res = await app.request( `/hello ${ path } ` ); expect (res. status ).toBe( 200 ); expect (res.text()).toBe( `Hello, ${ path } ` ); } ); zod + reuqest parameter validation zodを使ったランタイムバリデーションがリクエストパラメータ等の検証に簡単に適合できるのが良いです const schema = z.object( { id : z.string().uuid(), } ); app.post( "/entry" , zValidator( "form" , schema), ( c ) => { c. status ( 201 ); return c.text( "Created" ); } ); test ( "POST /entry は、FormDataでid = uuidのみ受け付ける" , async () => { const body = new FormData (); // UUID以外はBadRequest body. append ( "id" , "abc12345" ); const res1 = await app.request( "/entry" , { method : "POST" , body } ); expect (res1. status ).toBe( 400 ); // UUIDは201 body. append ( "id" , "fc56abe1-d352-691e-bd8e-13102bf17549" ); const res2 = await app.request( "/entry" , { method : "POST" , body } ); expect (res2. status ).toBe( 201 ); expect ( await res2.text()).toBe( "Created" ); } ); jsxテンプレート jsxで直感的にフロントエンドが書けるのが素晴らしすぎる /** * todo.tsx */ import { Hono } from "hono" ; import { jsxRenderer } from "hono/jsx-renderer" ; import type { FC } from "hono/jsx" ; const app = new Hono(); app.use( "/todo/*" , jsxRenderer(( { children } ) => { return ( < html lang = "ja" > < title > My ToDo </ title > < body > { children } </ body > </ html > ); } ), ); const ToDoList: FC < { items : string [] } > = ( { items } ) => { return ( < ul > { items. map (( item ) => ( < li > { item } </ li > )) } </ ul > ); } ; app. get ( "/" , ( c ) => { return c.render( <> < h1 > 今日のToDoは？ </ h1 > < ToDoList items = { [ "掃除" , "昼寝" , "歯磨き" ] } /> </> , ); } ); export default app; 最後に 私たちがHonoを使っていて、とても感じるのは 「Honoって楽しい！！！」 です。チームとして迷わず開発できている点や、開発生産性も高く、何より 使っていて気持ちが良い というのが大きいと思います。 社内のプロダクトで使い始めたHonoですが、個人開発でも何かとHonoをベースに開発する機会が増えました。個人的には Bun + Honoで作ることが多く、TypeScriptやテストの取り回しも楽だし、Cloudflare Workerなどどこでも動くのは本当に魅力だと思っています。 この記事が、皆さんのHono採用きっかけの一助になればと思っています。

こんにちは。 エス・エム・エスでプロダクト組織の人事をしているふかしろ( @fkc_hr )です。 株式会社エス・エム・エス Advent Calendar 2024 vol.2 と 技術広報 Advent Calendar 2024 シリーズ3 の12月12日の記事です。自社のAdvent Calendarは埋まるかな〜ワクワク、とSlackのtimesチャンネルで呟いたら、人事も書くんだよ！と煽ってもらって(？)ここに至りました。 エス・エム・エスは例年さまざまなカンファレンスに協賛をしているのですが、今年はありがたいことにブース出展もさせていただく機会が多かったため、そちらの内容を振り返っていきます。 カンファレンスでエス・エム・エスを見かけてくれた方に思い出しながら読んでいただいたり、これからカンファレンス協賛・ブース出展するぞという方の参考になったりしたらいいなと思っています。 どのカンファレンスに協賛をしたのか 以下の通りです そのうちブースを出展したカンファレンスを主に振り返っていきます。私は該当する5つのカンファレンスを皆勤賞ですべて参加させていただきました。楽しかった〜 すこし裏話をすると、2024年12月現在では、モバイルアプリエンジニアはチームもなければ採用も積極的にしているわけではないものの、 DroidKaigi は弊社社員がスタッフとして参加しているので協賛をしていたり、はじめての JAWS Festa への協賛はSREの一人が、コミュニティ活動として協賛したいといってくれたおかげで協賛に至ったり、というコミュニティ貢献のためにも協賛という形で社として応援しているなと思ったエピソードもありました。 どんな準備をしたのか 今年は広報がんばるぞと決意していたこともあり、素振り的にブースがある協賛イベント用のキックオフ資料のたたきを作ったり、その他のノベルティやチラシの資料を一つのドライブにまとめたりしていました。 エス・エム・エスは複数事業を展開していて、プロダクト数も多いので、各カンファレンスごとにフォーカスして紹介したいプロダクト・チームが変わります。そのため全体感を把握できないまま役割分担などが進んでいく傾向があるので、全体感やスケジュールが分かるものにしました。 関係者や興味を持ってくれている人をあつめてキックオフと役割分担をしたら、あとは皆さんの応援をする…という形で進むのが理想なのですが、初めて関わる方も多くいるので、社内調整含めてフォローしながら、Slackで該当イベント用のpublicチャンネルを作成し定例で進捗を確認し…と進めています。 特に社内関係者でPR/IR/リスクマネジメントの部門への相談が必要だったり、支払い関係で経理/総務部門も巻き込みながら進むような内容は普段のエンジニアが業務上かかわらないことが多いため、各部門の判断材料となるような情報が不足なく伝わるようなフォローをしていました。 その中でも今後の持続性を考えて、ノベルティは他のイベントでもつかえるデザインにする、チラシの会社紹介のページは共通で活用する、メインの缶バッジ企画を固めておく、などをしていたので直近のKaigi on Rails はかなりスムーズに用意できたように感じます。 当日どう過ごしたのか 各社あまり差異はないと思いますが、シフトを組んで、できるだけ聞きたいセッションは聞き、カンファレンス自体を楽しんでもらいたいというのがベースの思考です。 ※シフトを抜粋したもの 企画として特に良かったなと思うものを2つ紹介します。 缶バッジ(現地生産) EMのふるぽんの企画で、「あなたのXアイコンを缶バッジにしてプレゼントします」という企画を行いました。 合わせてお渡しするネタ缶バッジもイベントごとに作成しました。デザインは絵文字ジェネレータで作ります。 特に現地生産もモバイルプリンター、缶バッジメーカーを活用して行えたイベントは非常にインパクトがあったのではないかなと思います。だんだんカンファレンス中で缶バッジをつけている人が増えていくのは不思議体験でした。 また、印刷や作成はバッチ処理的に作業していく仕組みだったので、申し込み・完成品の回収と2回ブースに足を運んでいただくことができたのも思わぬ良ポイントでした。 SNSフォローもお願いしたい、ノベルティも渡したい、会社やプロダクトの紹介もしたい、ソースコード公開をしてたら見てほしい、とコンテンツが多かったのですが、タイミング次第で長くブースに滞在していただくこともできました。 おみくじ デザイナーがコンセプトワークから行ったストーリー性がある企画でした。 「デザイナーと介護・障害福祉を『社会課題』で結ぶ」というコンセプトで、おみくじをきっかけとして提供し、介護を含めた未来を想像してもらい、該当する項目に「結」んでもらう。ここまでつながる体験設計をできるのはデザイナーだからこそなせるワザだなと思いました。 おみくじを結んでもらっている様子 コンテンツとしても、「おみくじ引いてみませんか」と声をかけることができるハードルの低さや、意外と結ぶという行動に手間取るのでその間に会社やプロダクトについて話すことが出来たことは収穫でした。 ここまで一貫した体験設計が出来なくてもハードルが低く興味を持っていただくきっかけを作る。なにか足を止めていただけるような、深い話をできる機会を創出するという点は今後のブース企画にも活かせそうです。 結果としてどうだったのか コミュニティ貢献が目的ですが、副次的な効果として得られたことを紹介します。 プロダクト組織の公式X( @BM_SMS_Tech )のフォロワーが1000人を突破した ノベルティをお渡しするためにフォローをお願いしたこともあり、Xのフォロワーが先日1000人を突破しました。実は今年度の始まりは300名弱だったため、カンファレンスが繋いでくれた縁だなと感じています。 継続的に情報発信をしていきたいと思っています！ エス・エム・エスよく見かけますと言ってもらえるようになった これはカンファレンスブースだけではなく、登壇やブログなどの発信の効果でもありますが、よく見かけると言っていただけるようになりました。嬉しいですね。 エンジニアも嬉しい、誇らしいと思ってもらえるように、これからも良い組織づくり、発信を行っていきたいです。 面談・面接でカンファレンスで社員と話して興味を持ったと言ってもらえるようになった 最高ですね。カンファレンス”だけ”が理由で採用に至ることはありませんが、応募のきっかけになる機会なのだなと感じました。 これからも継続的にコミュニティへ貢献するモチベーションになりました。 社内エンジニアやデザイナーの交流の足がかりになった 普段基本的にはフルリモートで開発をしているため、対面で会うのははじめて、というメンバーもいました。同じ技術スタックを別のチームで使っている場合でもカンファレンスの準備から感想戦など含めて交流するきっかけになったと感じています。 おわりに 広報施策に銀の弾丸はなく、なにごとも継続が大事だと感じています。エス・エム・エスのプロダクト組織がカンファレンス参加や学習を推奨しているからこそ、カンファレンス協賛を継続的に行えているのだと改めて感じる一年でした。 カンファレンスを実施してくださる運営の皆さん、参加していてエス・エム・エスのブースに来てくださった方、ありがとうございました。またお会いしましょう！

この記事は「株式会社エス・エム・エス Advent Calendar 2024」シリーズ1の12/17の記事です。 はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。気づけば入社して3年が経ちました。現在は複数のQAチームに横断的に関わりつつ、チームのサポートや改善活動の推進など、幅広い業務を担当しています。 弊社では以前から、ノーコードのテスト自動化ツール「 MagicPod 」を使用し、E2Eテスト自動化を推進しています。今回の記事では今年取り組んだ「ローカルPC実行で定期実行を実現したこと」をテーマにお話ししていきます。 昨年のAdvent Calendarでも、E2Eテスト自動化のことを記事にしているので、ぜひそちらもご覧ください 🙏 tech.bm-sms.co.jp 取り組みのお話 １．前提 カイポケにおける自動テストの状況を簡単に説明します。 開発環境がプライベートネットワークなのでMagicPodのクラウド実行機能を使えない リモートワーク主体でプライベートネットワーク内で安定した通信が求められるので、自動テストの実行環境は仮想環境を使用している カイポケの推奨環境に準拠して自動テストの実行環境はWindowsとしている これらの制約がある中で開発環境に対して定期実行を可能にする方法を検討していきました。 ２．構成 仮想環境にPowerShellを配置し、それをWindowsのタスクスケジューラで定期実行する構成としました。JenkinsなどのCIツールを利用する選択肢も検討したのですが、以下の理由から今回の構成を採用しました。 CIツールの保守にコストをかけたくない テスト実行環境を軽量で運用したい 2-1. 構成イメージ 2-2. 実行フロー スケジューラにタイマーをセットする スケジューラでセットした時刻にPowerShellを実行する MagicPodDesktopを起動し自動テストを実行する ３．テスト実行スクリプト（PowerShell） PowerShellでは、MagicPod公式のヘルプ「 コマンドライン一括テスト実行（ローカルPC環境） 」も参考にしながら、主に以下の処理を行っています。 Proxy設定の更新 MagicPodDesktop設定ファイルの更新 テスト実行 次に、コードを交えながら各処理内容を簡単に紹介していきます。なお、説明のために処理を分割していますが、実際には1つのスクリプトで完結するように構成しています。 3-1. Proxy設定の更新 ## テスト環境を指定（実際には引数で取得） $targetProxy = "XXX" ## テスト環境向けのProxyServerを定義 $proxyList = @{ "STG" = "<STG_URL>:<STG_PortNumber>" ; "DEV" = "<DEV_URL>:<DEV_PortNumber>" ; } Function changeProxy { param ( $targetProxy ) try { # 接続先のProxyServerを設定 New-ItemProperty -LiteralPath "HKCU:Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name "ProxyServer" -PropertyType "String" -Value " $targetProxy " -Force # Proxy設定をon Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 1 Write-Host "Proxyが設定されました: $Proxy " -ForegroundColor Green } catch { # Proxy設定をOff Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 0 Write-Output "Proxy設定でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-2. MagicPodDesktop設定ファイルの更新 ## テスト実行用のパラメータを指定（実際には引数で取得） $testNumber = "XXX" $testPattern = "XXX" ## ファイルパスを指定 $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" Function updateConfig { try { # MagicPodConfig.jsonを読み込んで更新する $jsonContent = Get-Content -Path $magicPodConfig -Encoding UTF8 -Raw | ConvertFrom-Json # テストケースを指定 $jsonContent .testSettingsNumber = $testNumber $jsonContent .testSettingsPatternName = $testPattern # JSONに変換 $updatedJson = ConvertTo-Json $jsonContent # UTF-8(BOMなし)で出力 [IO.File] :: WriteAllLines( $magicPodConfig , $updatedJson ) Write-Host "設定ファイルが正常に更新されました。" -ForegroundColor Green } catch { Write-Output "configファイルの更新でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-3. テスト実行 ## ファイルパスを指定 $magicPod = ls $HOME \AppData\Local\magic_pod_desktop\app- * \MagicPodDesktop.exe $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" ## 実行コマンドオプションを指定 $argConfig = "run --magic_pod_config= `" $magicPodConfig `" " Function startMagicPod { Start-Process -FilePath " $magicPod " -ArgumentList $argConfig } さいごに 今回紹介した方法により、本番環境だけでなく開発環境でも定期実行を実現することができました。定期実行を導入することで、何か問題があった際にすぐに気づける安心感を得られたことは、大きな成果だと感じています。また、テストに問題が発生した時もすぐに改修できるため、テストケースの保守性向上にも役立っています。 ただし、現時点では定期実行の実現にとどまっています。今後はCI/CD連携を進めて、リリースプロセスに密接に関わる形に発展させることで、さらなる開発サイクルの高速化や品質向上を目指していきたいと考えています。 エス・エム・エスでのテスト自動化の取り組みは着実に進んでいますが、まだ発展途上であり、さまざまなチャレンジができる環境です。（常に「より良く」を目指しているので、終わりはないかもしれませんが…😅） 現在、QAエンジニアを積極採用中です！少しでも興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！！

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。2020年1月に入社し、チーム活動やQA組織づくりを通じて品質保証の体制強化や施策推進をしています。 2024年も残すところあと半月ほど・・ということで、今回の記事では今年一年であった変化、その中で取り組んでみた活動の内の一つを振り返ってみたいと思います！ 組織、私個人としても沢山のチャレンジをさせてもらった一年ですが、印象深い活動をピックアップして書いてみています。 どんな変化があった？ カイポケのリニューアルプロジェクトでは今年からLeSS（Large Scale Scrum：大規模スクラム）の導入にチャレンジしています。 tech.bm-sms.co.jp このプロジェクトでは以前よりスクラムをベースとした開発プロセスを導入しており、各チームに所属しているメンバーが日々試行錯誤をしながら開発や品質保証を進めてきました。 その中でスクラムマスターの参画もあり、LeSSのフレームワークへと最適化していく過程で、よりチームとして目線を合わせやすい状態、サポートが受けやすい状態となりました。 同時に、そういった変化の中でQAエンジニアが持つ専門性をどう活用し、成長しながら貢献していけるのかということを改めて考える機会が訪れているとも感じました。 この変化や機会の中で実際の動きを通じ、QAエンジニアとしてどう貢献していくべきかを改めて考えてみたい・・・！ 私自身はQA組織内の横断的な活動も担当させてもらっているため、入社時と比べるとチーム活動からは少し離れがちにはなっていたのですが、そういった思いのもとで今年はチーム活動にも積極的に参加させていただく一年となりました。 前提 カイポケ開発の各アプリにおけるチームはプロダクトオーナー、開発者、デザイナー、QAと異なる専門性を持った多数のメンバーにて構成されているケースが多くあります。 現在私が主に関わっているチームでも同様で、それぞれが得意な領域の技術を持って開発を進めるスタイルになっています。 関わらせてもらうタイミングでちょうどチームの再編があり、ワーキングアグリーメント（チームの約束事）の作成等、チームビルディングにも参加することができました。 一部抜粋にはなりますが、現状のワーキングアグリーメントには以下のような記載をしています。 スプリントゴール達成に向けて、ロールを越えて得意な武器（領域）で援護してほしい こちらも一部ですが、QAと呼ばれる活動に専門性を持ったメンバーが期待されていることとして以下記載がされています。 検証するシナリオやパターン知見から、要求に関する不確実性を評価してもらう事に期待している 作るものの「不確実性」（要求の変化や開発における変数等）は一定発生します。 私が所属するチームでは技術と要求の不確実性の切り口でPBI（プロダクトバックログアイテム）の評価、見積もりをしています。 QAと呼ばれるメンバーはこの中で、検証シナリオやパターンの知見を用いた要求の不確実性の具体化、それに対するフィードバックをしていくことを期待されています。 そこに対して貢献ができるポイントはないか考えながら活動していきました。 どんな感じでやっているか 上記にて書かれている「要求に関する不確実性の評価」、そこからスプリントを通じて「要求の不確実性を減らしていくためのアプローチ」として、一例として以下のような活動を通じてトライアルをおこなっています。 ディスカバリーフェーズから他チーム影響も考慮したテストパターンを考えていく PRD作成までの各ステップに参加、早期からテストプランニングやパターン検討を開始 プロダクトオーナーや開発者とのテストすり合わせ（インクリメントの共通認識化）をスプリント開始後の早い時期に実施する リファインメントにて受け入れ基準をチームで確認・最適化し、ストーリーポイントを用いて不確実性に対する会話をする こういった活動の中で適宜フィードバック、デイリースクラムでの透明性確保を通じ、不確実性を下げていくことをスクラムチームにおけるQAの活動の一部として取り組んでいます。 やってみてどう？ 活動の元になっているもの自体はスクラムの基本的な考え方に基づいているため、特に目新しいものではないのかもしれません。 また、これがベストプラクティスではないと思っていますし、アウトプットの精度やフィードバックの数を増やす等、より良くなっていけるように考えていく楽しみがあると感じています。 テストプロセスの更なる最適化、自動テストを駆使したリードタイムの短縮、ワーキングアグリーメントの「ロールを越えて」という部分でできることもまだ多くあり、より一層チームとして、個人として成長していける可能性を感じています。 個人的なこれよかったポイント 長々と経緯や現状を語ってしまいましたが、エス・エム・エスのQA組織では大切にしたいものの一つに「チームで品質保証」という行動指針を掲げています。 その実現に近づいている実感を持てたことが、私個人としてとてもよかったと思っています。 QA組織の行動指針とは？ 以前テックブログにQA組織の行動指針を言語化した記事を投稿しました。 tech.bm-sms.co.jp この中の一つに「チームで品質保証」というものがあり、「職種の壁を越えて協力することで複雑な問題を解消できる組織を目指したい」という思いのもと、この項目を設計していました。 私の中でこの指針とリンクした活動に携われたという実感があり、今回のテーマで書いてみようと思ったモチベーションにもなっています！ ※ちなみにこの記事内の行動指針は昨年初稿として書いたもので、絶賛ブラッシュアップ中です。詳細は追って発信したいと考えています。 （方向性の見直しではなく、組織スケールの中でもより伝わりやすいものにしていきたいと思っています） 1点補足として、本記事の活動や考え方のみが「チームで品質保証」を体現するものではないと考えています。 チームの特色によって構築していきたい開発スタイルは異なると思っており、その自由度が高いのもエス・エム・エス開発組織の良いところだと捉えています。 まとめ ということで、組織作りにおいて今回のような活動にトライしていきたいという思いが前提としてあり、実際の動きとしてコミットしていくことも微力ながら出来たため、非常に充実した一年になったと感じています。 もちろん全て私が提案・推進・実践したわけでないですし、関係する沢山のメンバーの多大なるサポートがあってこそなので、この場を借りてお礼申し上げます！ いつもありがとうございます！ 私自身、スクラム開発やアジャイルテスティングの経験が豊富なわけではなく、ましてLeSSとなってくると日々勉強だなぁと思う毎日です。 今年は会社の支援を受けて外部研修にも参加させてもらい、とても良い刺激になりました。 tech.bm-sms.co.jp 今回の取り組みに関してもチームプロセスとしてより明確化したり、洗練していくことは必要不可欠だと思っています。 スケールしていくプロダクトに対して取り組みをどのように適用し、どう貢献していくか考え続けたいという思いもあり、ここも継続してチャレンジしていきます。 また、冒頭でも少し触れましたが今回の取り組みはあくまでも一例で、QA組織では他にも多くのTryを進めています。 今回のようにチームで一緒に走っていく活動だけでなく、横断的な関わり方を模索し、品質の維持・向上とともに不確実性を下げていく活動がプロダクトや組織のスケールによって必要になると思っています。 そういった点も組織一丸となって引き続きチャレンジしていきたいと考えています。 来年もがんばるぞ！ 様々な活動にチャレンジできるエス・エム・エスのQA組織に少しでも興味を持ってくださった方は是非カジュアル面談よろしくお願いいたします！

この記事は 株式会社エス・エム・エス Advent Calendar 2024 vol.2 12月9日の記事です。 介護/障害福祉事業者向け経営支援サービス「カイポケ」のソフトウェア開発者の 空中清高( @soranakk ) です。 本記事では、毎月開催しているチーム交流のボードゲーム会について書きます。 はじめに カイポケにはたくさんの開発チームがあります。 普段はリモートワークが中心だけど、「たまには他チームとの交流会がしたいな」ということで橋口( @gusagi ) さんがボードゲーム会を企画してくれました。 チーム交流のボードゲーム会は任意参加の会で、月に1回、だいたい月末の金曜日の夕方に開催しています。本記事ではこれまで開催したボードゲーム会でこんなゲームをやったよ〜っていうのをできるだけ思い出して紹介したいと思います。 これまでに遊んだボードゲーム ロストレガシー 宝物がどこにあるのかを探すゲーム。 1ゲームの時間が短く、毎回展開が異なるためリプレイ性があり、テンポよくできるゲーム。 他の人にアクションすることが結構あり、コミュニケーションが取りやすいゲームです。 「〇〇さん、さっき 4 のカード持ってましたよね？」 ボブジテン カタカナ語をカタカナを使わないで説明するゲーム。 説明の仕方など、個性が出て面白いです。 「 インストール をカタカナを使わないで説明してください。」 ボーナンザ 豆畑で豆を育てるゲーム。 豆を交換する交渉が必要なゲームで、各々の性格が出てとても面白い。 「この赤い豆を緑の豆と交換して欲しいなぁ、Win-Winですよ、ね？」 もっとホイップを！ 見た目は甘いケーキだけど、ゲーム内容はかなりシビア。 他の人がどのケーキを食べて、どのケーキを残しているのかを見ながら真剣にケーキを選ぶゲームです。 「どのケーキを切ったらいいかな〜。(人の顔を見ながら)ここかな〜〜？」 確定申告ゲーム 確定申告をテーマとした双六型のゲーム。 確定申告にまつわる質問に答えたり、ホテルやカメラ、スーパーカーの領収書の使用目的を聞かれたり、ロールプレイが楽しいゲームです。 「〇〇さん、この経費の領収書でカメラを買ったってあるのですが、何に使ったんですか？」 ごきぶりポーカー ゴキブリやコウモリなどを押し付け合うゲーム。 押し付けられたカードが本当に指定されたカードなのかを当てないと、押し付けられちゃう。 「これはコウモリです。いえいえ、本当ですよ？本当にコウモリです。」 ブロックス ブロックを順番に置いていく陣取りゲーム。 ルールはシンプルだけど、奥深い戦略があるゲームです。 あれ？もう置ける場所がないかも？陣取り、むずかし〜〜 Not My Fault! 俺のせいじゃない! 順番にプロジェクト進捗を報告していく、ダウト系のゲーム。 納期は守らないといけないけど、すでに報告されている進捗も実は・・・？ 案外 徹夜で頑張りました が本当だったりして、面白かったです。 センチュリー: スパイスロード センチュリー三部作の一作目。 4種類のスパイスを交換しながら、自分だけの最大効率フローを作り出して勝利する！ 目指せスパイスマスター！ マフィア・デ・クーバ 正体秘匿の人狼系のゲーム。 役職を自分で選べるのと、マフィアのボス役とのロールプレイや掛け合いが楽しいゲーム。 「ダイヤは何個あった？」 「私が見た時にはもうダイヤは一つもなかったんです！私は忠実なる部下です！」 「役職は聞いてないよ。」 インサイダーゲーム 一人だけ答えを知っているインサイダーを含めて、お題を当てるゲーム。 参加者はマスターに質問し、マスターは Yes/No/わからない で答えるだけを繰り返して推理していき、お題を当てる。 お題を当てた後にインサイダーは誰だったのかを推理するゲーム。 お題を当てるパートとインサイダーを探すパートがあって、誰が正解に誘導したんだ？というのを推理するのが楽しいゲーム。 A「それは食べられますか？」 B「それは自宅にありますか？」 C「昨日食べましたか？」 D「調味料ですか？」 E「鼻にかけたらクシャミしますか？」 インサイダーは誰だ？ ボードゲーム会の意義 ボードゲームには様々な種類のゲームがあって、強制的に嘘をつく必要があったり、ロールプレイする必要があったり、様々なシチュエーションを共有できます。 またゲームで求められるものも、純粋な論理的思考みたいなものだけじゃなく、会話や表情など様々です。 こういったゲームを通じて、人となりを知れたり、あのゲーム面白かったですね、という共通の体験が出来たりして、チームビルディングに良いと思います。 また来年もいろんなボードゲームやるぞー！

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.1の12月9日の記事です。 エス・エム・エスで全社SREというロールで活動している Security Hub芸人 1 の山口（ @yamaguchi_tk ）です。 おすすめのAWSサービスは営業です（いつもお世話になっています）。 はじめに SRE（Site Reliability Engineering）は、運用の効率化とシステムの信頼性向上を目指すアプローチです。 私たち全社SREチームでは、組織横断的にSRE活動を開発チームにEnablingしていく取り組みを開始します。本記事では、その背景や目的、具体的に活動を予定している内容をご紹介します。 背景 現在、事業部に専属のSRE（Embedded SRE的な立ち位置のSRE）がいないサービスでは、主に全社SREがインフラの構築・運用を担っています。しかし、システムの運用については受動的な対応が多く、 「組織の信頼性のマインドセット:Google SRE の知見」 に記載のある組織の信頼性のマインドセットでは Absent な段階でした。 そのため運用負荷が集中し、信頼性向上や運用の効率化のための活動になかなか手が回らない状況でした。 エス・エム・エスは事業活動の性質としてサービスの数が多く、事業部に専属のSREがいない全てのサービスの運用の効率化、信頼性の向上を全社SREチームだけで行うことは現実的ではないため、新たなアプローチを策定しました。 SRE活動を開発チームにEnablingしていく目的 私たちのチームが目指すのは以下です。 開発チームの自律性を高める 開発チームがSRE活動を主体的に実施し、信頼性のあるシステムを構築・運用できる体制になることを支援します。 運用の効率化と信頼性の向上 運用負荷を軽減し、システムがより高い信頼性を保つ状態を維持します。 具体的な活動内容 以下のような手順で活動内容を決定しました。 全社SREチームが開発チームにEnablingするSRE活動を定義 定義した活動を開発チームに委譲する目標レベルを定義 定義した活動で成熟度レベルを評価するものを決定 開発チームにEnablingする活動は以下のようになりました。 活動 Enable対象 目指す委譲レベル 成熟度評価 SLI/SLO ⭕️ 尋ねる ⭕️ 監視 ⭕️ 尋ねる ⭕️ インシデント対応 ⭕️ 尋ねる ⭕️ ポストモーテム ⭕️ 尋ねる ⭕️ ドキュメント管理 ⭕️ 尋ねる トイルの撲滅 ⭕️ 尋ねる ⭕️ コスト管理 ⭕️ 尋ねる ⭕️ 脆弱性対応 ⭕️ 尋ねる ⭕️ インフラ設計 ⭕️ 同意する 開発効率の向上 ⭕️ 尋ねる ⭕️ セキュリティ対応 伝える Admin業務 伝える 知識共有とトレーニング 伝える ログの管理 伝える 委譲レベルはManegement3.0 2 を採用しました。 伝える：私が決定し、チームに伝える 説得する：私が決定し、チームを納得させる 相談する：チームに相談してから、私が決定する 同意する：チームと一緒に決定する 助言する：助言はするが、チームが決定をする 尋ねる：チームが決定し、後で私を納得させてもらう 委ねる：チームが決定し、私は気にしない 成熟度評価 サイバーエージェントさんの資料 3 を参考にさせていただきLevel1からLevel3までの成熟度を設定しました。 SLI/SLO Level1 SLI/SLOが設定されていない Level2 SLOが計測され、信頼性の数値としてチーム内で認知されている Level3 ベストプラクティスに基づいたSLO運用ができている 監視 Level1 監視についてのルールや要件がなく、場当たり的な監視になっている Level2 監視ルールが整備され、プロダクトの異常が適切に検知できる状態になっている Level3 ベストプラクティスに基づいた監視項目の設定、通知が行われている インシデント対応 Level1 対応フローが定義されておらず、対応が属人化している Level2 対応フローが定義され、チーム全体で反復可能な状態になっている Level3 ベストプラクティスに基づいた対応フローが行われている ポストモーテム Level1 障害報告書は書いているが、障害から学習できる状況になっていない Level2 障害をふりかえり、対応プロセスやプロダクトの改善につながっている Level3 ベストプラクティスに基づいてポストモーテムの導入、ふりかえりが行われている ドキュメント管理 Level1 必要なドキュメントが整備されていない Level2 必要なドキュメントが整備されている Level3 ベストプラクティスに基づいてドキュメントの維持や整備が行われている トイルの撲滅 Level1 運用作業と開発タスクが分断しており、運用作業の改善は場当たり的に行われている Level2 運用作業の見直しや改善が計画性を持って行われている Level3 ベストプラクティスに基づいてトイルの計測や改善が行われている コスト管理 Level1 コストの削減は場当たり的に行われている Level2 コストの評価や削減が計画性を持って行われている Level3 ベストプラクティスに基づいてコストの評価や対応が行われている 脆弱性対応 Level1 脆弱性対応は場当たり的に行われている Level2 脆弱性対応が計画性を持って行われている Level3 ベストプラクティスに基づいて脆弱性の評価や対応が行われている 開発効率の向上 Level1 プロセスは定義されているが自動化は行われていない Level2 CI/CDが構築され、一部で自動化が行われている Level3 ベストプラクティスに基づいて開発効率の評価や向上への対応が行われている 開発チームとのコラボレーション 開発チームとのコラボレーションについても、「開発チームが自律的に全てのフェーズを実施できている状態」を理想形と定義し、以下のように役割分担を整理しました。 フェーズ 事業部 開発チーム 全社SRE 備考 企画・要件定義 ⭕️ ⭕️ 設計 ⭕️ ▲ 全社SREが可用性、セキュリティの観点でレビューを行う インフラ初期構築 ⭕️ ▲ admin的な業務は全社SREが実施 その他は開発チームで構築 開発 ⭕️ インフラ変更等 ⭕️ ▲ 全て開発チームで実施 必要に応じて全社SREが支援、レビューを行う アラート対応 ⭕️ 営業時間内外問わず開発チームが実施 インフラ作業 ⭕️ ▲ Admin業務以外は開発チームが実施 メンテナンス対応 ⭕️ 開発チームが通知を確認して開発チームが実施 脆弱性対応 ⭕️ ⭕️ 基本的に開発チームが自律的に実施 緊急性の高いものに関しては全社SREが脆弱性を確認し開発チームに対応を依頼 今後の展望 全社SREチームでは、この取り組みを通じて「組織全体で信頼性を高める文化」を醸成していきます。 開発チームと密に連携しながら、組織横断的なSRE活動の推進に取り組んでいきます。 本取り組みに関する最新情報や進捗は、随時Blogで共有していく予定です。 SRE界隈でもAWS界隈でも「山口」だとレピュテーションがなかなか上がらないので、レピュテーションは「Security Hub芸人」で確保しています ↩ 「Management 3.0 デレゲーションと エンパワーメント」 ↩ 「SRE Technology Map 2023」 ↩

この記事は株式会社エス・エム・エス Advent Calendar 2024の4日目の記事です。 エス・エム・エス BPR推進部 データ基盤チームの橘と申します。 私は「ナース専科 転職」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 はじめに キャリア事業のデータ基盤は、Google Cloud 上に、BigQuery を中心に構築しています。 近年、データ活用の需要はますます拡大し、事業部門がTableauやQuickSightなどのBIツールを介してデータ基盤を利用したり、Google スプレッドシートや BigQuery Studio からSQLを実行しての分析等が進んでいます。 データ基盤の活用を推進する中で、以下を目指し日々運用をしています。 必要なデータがどこにあるかがわかる(Discoverable) 必要な人が必要なデータにすぐにアクセスできる(Addressable) セキュリティやガバナンスが守られている(Secure) 昨年のAdvent Calendar の記事は、上記のDiscoverable、Addressableを達成するための手段の1つでした。 tech.bm-sms.co.jp 今回は、AddressableとSecureを実現する、権限管理について触れたいと思います。 キャリア事業は複数のサービスを抱え、サービス内に複数の活用できるデータが眠っています。データ基盤の拡大とともに、Google Cloud のプロジェクトも複数となり、BigQuery のデータセットだけを見ても、多数に分割して管理されています。 煩雑化と属人化が進みつつある権限管理を昨年見直し、運用をしてきましたので、その事例をご紹介します。 データ基盤における権限管理 私たちのデータ基盤は、Google Cloud のプロジェクトのIAM、BigQuery やCloud Storage などのデータへの読み書きのアクセス権限、App Engine アプリケーションへのアクセス権限など、複数個所での権限設定を運用しています。キャリア事業にかかわる社内のあらゆるデータを蓄積しているため、ユーザー側の見れるデータ、編集できるデータを最小限にするためにポリシーを設けて、データ基盤管理者がポリシーに沿って適切な権限を設定していく運用を続けています。 従来は、データ基盤管理者数名で、依頼ベースでGoogle Cloud のコンソール上から手動での権限設定の対応を行ってきました。権限設定自体はGUI上でも簡単にできますが、以下の問題がありました。 変更履歴を管理できない 複数人複数個所の設定が手動での運用だと大変 権限設定を依頼する人は権限を操作する権限を持たないため、変更箇所の指定をしにくい 上記を解消するために、構成管理ツール、Terraform を昨年度に導入しました。 元々データ基盤では管理するリソースが多くもなかったのでTerraformを導入していなかったという背景がありました。Cloud Storage のバケット毎、BigQuery のデータセット毎の権限設定等を目的にTerraformの導入をし、付帯的にインフラの構成管理としての導入も進めました。 導入から1年ほど経ったので具体的な構成や導入後のメリットをご紹介します。 Terraformの構成 まず、Terraformのディレクトリ構成としては以下になります。 . ├── modules/ │ └── 共通モジュールなど └── projects/ ├── プロジェクト1 │ ├── resources/ │ │ ├── bigquery.tf │ │ ├── cloud_storage.tf │ │ ├── iam.tf │ │ ├── members.tf │ │ ├── service_account.tf │ │ └...他リソースごとのtfファイル │ ├── .terraform.lock.hcl │ ├── main.tf │ └── variables.tf ├── プロジェクト2/ └...以降プロジェクト毎のディレクトリ/ キャリア事業のデータ基盤として複数のGoogle Cloud のプロジェクトがあるため、複数プロジェクトを一元管理できる構成としています。 projects/[実際のプロジェクトID]/resources 配下には、 biguery.tf 、 cloud_storage.tf などのリソース毎の定義ファイルを置いてます。例えば、 bigquery.tf は、BigQuery のデータセットごとのリソース管理と、データセットのReaderやWriterの定義を管理しています。 Google Cloud の権限は、GoogleグループやGoogleアカウント毎に定義が可能ですが、権限管理の目的内でのグルーピングができるように、 member.tf を作成しています。この中でlocal変数として、GoogleグループやGoogleアカウントをリストで定義して、各リソースに設定できるようにしています。 運用フロー まず、ユーザー部門がデータ基盤チーム宛に、権限設定の依頼をします。具体的に見たいBigQueryのデータセットを書いて依頼をしたり、業務上どういうデータを分析したいかなどの抽象的な相談をしたりします。 その要求をデータ基盤チームの開発者が受け取り、必要であればユーザー部門に業務のヒアリングを行い、Terraformのコードを書いてGitHubのプルリクエストを作成していきます。 プルリクエストをデータ基盤管理者がレビュー・承認することで、権限設定ができる仕組みとしています。 導入してから変わったこと いつ、誰に、どういう目的で、何の権限設定をしたかを把握できるようになった 複数プロジェクトまとめての権限の棚卸しがしやすくなった テキストエディタ上で設定を記述するため、AIによる自動入力の支援を得られるようになった ユーザー側の要求によってどの権限が必要かのレビューがしやすくなった 今まではデータ基盤管理者のみが権限を把握していたが、Terraformのコードを書く開発メンバーも、データ基盤の権限構成を理解できるようになった など複数のメリットがありました。 特に後者の2つはデータ基盤の管理の属人化を避けるためにも効果的で、データ基盤”チーム”として運用をしていく体制が確立したと思います。 まとめと今後の展望 以上、データ基盤における権限管理についてご紹介しました。BIや生成AIの発展とともに、ますますデータ基盤の利用機会も増えてきました。データのAddressableとSecureを加味した適切な運用はこれからも継続して見直していきたいと考えています。 エス・エム・エスは新しいメンバーを募集しています。 私達データ基盤チームでは、今回ご紹介したデータ基盤の運用から、データパイプラインの開発、データマートやダッシュボードの開発、AIを用いたソリューションの提供など様々な業務を通して事業を支援しています。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。 careers.bm-sms.co.jp open.talentio.com

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.2の4日目の記事です。 エス・エム・エス Engineering Manager 兼 Hiring Managerの @emfurupon777 です。 はじめに 入社してからずっと関わってきている社内外交流の観点でも継続することの重要さを改めて実感じているので、継続を意識して取り組んでいることについてポエムってみようと筆をとっています。 とはいえ、全部書いてもなーというところで、社内・社外向けの取り組み一つずつ取り上げてみます。社内はLT会、社外は協賛カンファレンスでのノベルティ提供(アイコン缶バッジ)についてです。 ちなみにエス・エム・エスの経営理念は『永続する企業グループとして成長し続け、社会に貢献し続ける』で、設立当初から永続性、継続性が強く意識されているので、継続性について意識を高く持っておくのは自然な話だったりします。仲間は常に積極募集中ですのでこの継続性について興味持っていただいた方はカジュアル面談からぜひお話ししましょう。 社内LT会 1. 観測 エス・エム・エスに入社して社内でどんな取り組みがあるのかなーと思って調べてみるとテックトークという記載が見つかりました。(おお、あるじゃん。まずは参加してみるだけで良いかな？と一瞬思いました) ところが、開催が散発的になっていてしばらく開催されていなそう・・・わかります。やろうぜってなって数回やるとネタが尽きて一旦下火になったりするんですよね。よーし、再起動やってやろうじゃないの。と自分で進めることにしました。 2. 下ごしらえ LT会やるならという感じで世に知見は転がっていて、必要なものは明確。 よし。青島、確保だ！(古い) 会場 エス・エム・エス本社ラウンジ確保！ (100名くらい集まれる広さのラウンジがあったので社内規定みつつ、ガッとおさえる) 経費(軽食、ドリンク等) カルチャー醸成&採用広報文脈で確保！ 登壇者 初回を納会じたてにして確保！ 実績解除しつつ少し先の開催まで少しずつ確保！ ハイブリッド開催の手段 本社に来れるなら寿司でもつまみながらワイワイしたい とはいえ、遠方の人にも参加してほしいからハイブリッドでやりたい とはいえ、ちゃんと配信しようと思うとスイッチャー類とか買ったり運用したりが大変 社内の取り組みだし大丈夫やろ、ということでラウンジにある現地のマイクとZoomを組み合わせるアナログな運営方法を確保！ 3. 当日の仕切り 原則クロコに徹します。軌道に乗せて形式化できるまでは我慢の子。(これ大事ですね) 飲食の手配＆受取 司会 帰る前に経費精算(忘れるとめんどうなので) 4. 継続できているか？ 正直まだまだ続けてやっているとはいえない状況かなというのが正直なところで、まずは100回くらいやってみるのが大事かなと思ってます。それくらい続けていれば一緒に運営してくれる人も多くなってくるし、定期的に開催時期がやってくるのがわかるようになるのではないかと思ってます。 登壇者が集まらないという話を時々耳にしますが、エス・エム・エスの場合は開催スケジュール決めちゃって声をかけてみると意外と？なんとかなります。(といいつつ、私の経験上ではどこの会社でも実は声かけて相談すればなんとかなる) 自発的な登壇は基本にしたいし、もちろんそれも面白いのですが、少し前に入社してきたあの人、Slackで気になることを言ってたあの人、みたいな他薦での登壇依頼もしてみると、普段業務で関わっているのとはまた違ったキャラクターが出てたりして面白いです。内容もあまりこだわりすぎずに好き勝手に話してもらうくらいでやってます。 ノベルティ提供(アイコン缶バッジ) 1. 観測 エス・エム・エスは私の入社前からRubyKaigiをはじめとする技術カンファレンスでブース出展してきたようだというのがesaやSlack検索などで見えました。ブースで提供してきたのは・・・どら焼きとか？ エスエムエス様のスポンサーブースでどら焼きが大量に残って困っているとのこと。Rubyistのみんな助けて！！！ #rubykaigi #dorayaki #sos #sms pic.twitter.com/sC2VYzSyrJ — はたけやまたかし (@htkymtks) 2018年6月1日 私も食べるのが好きなのでいいなーと思うものの、カンファレンスによっては飲食の提供は禁止なんですよね。そして、各カンファレンスに沿った企画はそれぞれの領域のエンジニア仲間にお任せしたほうが刺さるはず。 そうなると、私のメインミッションが採用ということもあり、できれば幅広いイベントに一貫して適用できる、飲食以外のもの、がいいなーという思いが芽生えてきて、これに合致するネタを捻り出す必要がある、というところに至りました。 2. 下ごしらえ さてノベルティのアイデアを考えます。ステッカーとか定番ものやノベルティ制作サービスなどを探索に行って・・・決まりません。(みなさん経験ありますよね？) 周囲に相談しつつ、カンファレンスなどで話が盛り上がるのは誰かなーとペルソナを考えていくと、結局エス・エム・エスの社員に似た人かも？という話になります。 ならばということで皆の言動をSlackなどのコミュニケーションで観測しにいく期間に入ります。(大体3ヶ月くらい。Slackで検索かけたり、リアルで話してるのを横からみてたりします。怪しいw) 基本的なニーズを社員観察で探りつつ、具体的な物品をプライベートで出かけた先で集客状況と合わせてチェックを続けます(社員観察から遅れて初めて1-2ヶ月くらい)。 そんな中で下記の組み合わせでの実現に辿り着きました。 前述の社内LT会でオフィスで顔合わせても、リアルで会うのが初めてで誰かわからない（Slackアイコンとナマの同僚が結びつかない) 普段目にしているアイコンを缶バッジにして身につけてもらおう 区民祭りでやっていた、缶バッチを自分でガシャコンと作れる企画がちびっ子たち(私の子供含む)にウケていた ちびっ子が楽しいと思うならエンジニアにも受けるに違いない（偏見） 何人かのエンジニアに共有してみたところそこそこウケが良かったのでこれで進めることに決定！(残り時間が少なかったというのもあります) もちろんこういう素朴な疑問も頂きますが、いいんです。やってみて反省するんです、ということで突き進みました。 やるからには一定のクオリティは担保したいということで、缶バッジメーカーは業務用のを選びました。安定して生産できています。 3. 当日の仕切り 下記のようなものを用意しておいて、協賛ブースで現地生産を頑張るだけです。 独りでも完遂するぞ！という感じでやっていましたが、一緒に採用をやっている人事さんたちが妖精さんの如く一緒にやってくれましたありがとう。 応募フォーム (アイコン画像を間違いなくいただき、その利用に同意いただくため) モバイルプリンター 缶バッジ用切り抜きカッター 缶バッジメーカー 缶バッジパーツ 4. 継続できているのか？ 今年はありがたいことに協賛ブースを多く出すことができたので、下記カンファレンスにて缶バッジを提供することができました。 RubyKaigi 2024 (現地生産は無し) Kotlin Fest 2024 SRE NEXT 2024 Kaigi on Rails 2024 1年続けてきたので、来年も少しアレンジを加えて企画を継続するのか、新たな企画に起こし直すのかは検討中です。 最後に 今回の記事が同じような取り組みをしている方に読んでいただければ嬉しいです。 そして、LT会を複数の会社合同で開催したり、ブース企画を複数社で連動したりできると面白いかもなーと思っていますので、お気軽に公式Xなどにご連絡ください。 おまけ プライベートの話なんですが、今年は生まれて初めて庭に芝生をはりました。 まずはーということで庭の半分くらいに高麗芝。やってみてはじめて知ることが多く、日々学んでる感が半端ないです。夏芝と冬芝という気温の違いでの植生のギャップも面白い。来年から綺麗に芝生を維持継続できるように頑張ります。 冬枯れの夏芝(左上)と元気に生え始めた冬芝(右下)の様子比較はこちら。

この記事は株式会社エス・エム・エス Advent Calendar 2024 および Datadog Advent Calendar 2024の4日目の記事です。 qiita.com qiita.com こんにちは、介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する全般を担当しています。 エス・エム・エスでは複数のプロダクトを開発・運用しており、オブザーバビリティに関するサービスの選定についてはプロダクトの規模感や特性、ユースケースなどを考慮し最適なものを導入しています。私が携わっているカイポケのリニューアルではDatadogを採用しており、サービス全体のオブザーバビリティの設計だったりSLI/SLO周りの設計などをみんなで考えつつ開発を進めている状況です。 会社やプロダクトにより導入しているオブザーバビリティSaaSは様々だと思いますが、私が直近で利用していたものは下記のように推移しています。 前々職 : Mackerel, Datadog 前職 : New Relic 現職 : Datadog 前職ではNew Relicの使い方を学び活用方法を考えるのに多くの時間を費やしていたため、自然とDatadogの知識や成功体験をリセットするUnlearnに至りました。そして改めてDatadogを利用するにあたり、Datadogを再学習 (Relearn) するにはどうすればいいかを考えこの記事を書いています。 オブザーバビリティSaaSの違いについて DatadogやNew Relic、SplunkといったオブザーバビリティSaaSは「システムが生成するテレメトリーデータを収集し分析し可視化する」といった機能の点においては概ね似たようなことが実現できると言えます。 Full Stack Monitoring より引用 インテリジェントオブサーバビリティプラットフォーム より引用 Splunk Observability Cloud より引用 一方で対応しているテレメトリーデータの種類や生成AIの活用、セキュリティへの対応といった機能観点での違いがあったり、テレメトリーデータを操作するためのUIが大きく異なっていたり、取り込むデータの単価や有償のアカウントの有無といったコスト観点での違いもあります。 Relearn Datadog ここからは私がエス・エム・エスに入社してからDatadogをRelearnするに至った経緯や実際に取り組んでみたことについて紹介します。 1. 理想と現実のギャップ 実を言うと入社直後の私は「New RelicもDatadogもやれること・やることは一緒だし、以前利用していたからすぐに思い出せるだろう」と過信していました。しかし、実際にはDatadogのWeb UIの階層構造の変化に戸惑ったり、Datadogの各種設定方法を思い出すのにそれなりの時間を要するという有様でした。 特に前職で利用していたNew RelicのNRQL (New Relic Query Language) があまりにも便利で多用していたため、DatadogにおけるSQLライク “ではない” テレメトリーデータの分析やアラートの設定方法を思い出すのに躓いてしまったことは否めません。 補足 : Previewというステータスですが、DDSQLというSQLライクなクエリ言語がDatadogにもあります。 https://docs.datadoghq.com/ddsql_editor/ というわけで、前々職でDatadogを利用していた頃から今に至るまで多くの機能やWeb UIにアップデートがあり、それにあわせて私の知識をアップデートする必要があることを痛感しました。それほどクラウドサービスの進化は早いのだと驚かされます。 基礎を固めるのは非常に重要であり、特にSaaSにおいては設計思想を学ぶことでより良い活用に繋がるというのは過去に得られた多くの学びのうちの1つです。Unlearn and Relearnということで改めてDatadogを学んでいきます。 2. ドキュメントや書籍による学習 Datadogの使い方を学ぶにあたり、公式のドキュメントやeBookを読みつつ、当時私が購入した書籍が手元にあることを思い出し読み返してみました。 Datadog Cloud Monitoring Quick Start Guide: Proactively create dashboards, write scripts, manage alerts, and monitor containers using Datadog (English Edition) 作者: Theakanath, Thomas Kurian Packt Publishing Amazon この本は洋書であるため、英語が得意ではない私にとっては読み進めるのに若干の負担があります。また、ところどころ現在のWeb UIや機能からビハインドがあります。しかし、Datadogの基本となる考え方や操作を思い出すのには全く問題ありませんでした。300ページという若干厚めの本ではありますが、覚えていた箇所を適度に読み飛ばしてDatadogの知識と記憶を少し取り戻すことに成功しました。 3. Datadog Learning Centerとの出会い さて、ここからが本記事のメインです。 私は技術に関しては書籍で学ぶことが多く、過去にはNew Relicを学ぶために下記の書籍を何度も読み返すことで設計思想を理解し活用してきました。 New Relic実践入門 第2版 オブザーバビリティの基礎と実現 作者: 松本 大樹 , 会澤 康二 , 松川 晋士 , 古垣 智裕 , 梅津 寛子 , 章 俊 , 竹澤 拡子 , 三井 翔太 , 大森 俊秀 , 大川 嘉一 , 中島 良樹 , 山口 公浩 , 齊藤 雅幸 , 小林 良太郎 , 髙木 憲弥 , 板谷 郷司 , 長島 謙吾 , 伊藤 基靖 翔泳社 Amazon Datadogにも入門書的なものがあると嬉しいといった旨の話をDatadogでSales Engineerを務めている Taka2さん に相談してみたところ「書籍についてはすぐに回答はできないが、Datadog Learning Centerというeラーニングがあるのでそこで学ぶことができる」という回答を頂けたのを思い出しました。 Datadogを気軽に試せる環境があればいいのに... というお声もいただいていたかと思いますが、 無料で何度でも環境払い出して使えるlearning centerがありますので、よろしければこちらも活用してみてください 監視対象のDemoアプリも立ち上がります https://t.co/RHHX3cafmC #datadog_japan_meetup https://t.co/RTGWICBLxt — Taka2 (@taka2noda) 2023年10月27日 実際にDatadog Learning Centerを触ってみようと思い下調べをしていたところ、詳細に書かれた下記のブログから有益な情報を得ることができました。 zenn.dev 今の自分にはちょうど良さそうだと考え、実際にDatadog Learning Centerのアカウントを作成していくつかのコースを受講してみました。 Datadog Learning Center Datadog Learning Centerの活用 まずは利用するためのアカウントを作成する必要があります。下記のページにアクセスし必要情報を入力してアカウントを作成しましょう。 アカウントの作成 アカウント作成後、ログインするとコースの受講具合・進捗具合を確かめることができます。途中でサイトから離脱した場合も進捗をカウントしてくれるので「続きは明日やろう」というのも問題ありません。 My Dashboard ということで、試しに基本となる3つのコースを受講してみることにしました。受講する順番はこの流れが個人的にオススメです。まずはオブザーバビリティについて学び、次にDatadogのWeb UIを触りながら全体像を掴む、そしてDatadogの基本的な機能の実践的な使い方を学ぶという流れです。 1. Introduction to Observability Introduction to Observability このコースではDatadogを使い始める前に「オブザーバビリティとはなにか」について学びます。オブザーバビリティとモニタリングの世界を初めて学ぶ人のために設計されており、Datadogやそれ以外のモニタリングサービス・ツールに関する予備知識は不要となっています。 このコースは動画を見て学ぶ座学形式となっており、オブザーバビリティの主要なテレメトリーデータであるメトリクス・トレース・ログについて理解し、モニタリングとアラートについて学ぶことができます。言語は英語ですが、日本語字幕のON/OFFや再生速度の変更などの設定が可能です。ちなみに日本語字幕は比較的良好な精度でした。 私はSREとしてテレメトリーデータに慣れ親しんでいるという自負はありますが、それぞれのテレメトリーデータの定義、構成要素、収集する必要性については言語化が苦手でした。曖昧な理解にとどまっていたのでしょう。しかし、このコースを受講することで各テレメトリーデータの定義についての理解が進み、言語化も前に比べて改善したと思っています。 仮に各テレメトリーデータの定義を忘れてしまってもこのコースに戻って来ることで何度も復習できます。このコースはDatadogの利用の有無に関わらず多くのエンジニアにオススメです。 2. Datadog Quick Start Datadog Quick Start 「あなたはマイクロサービスで構成されたEコマースアプリの健全性とパフォーマンス監視のためにDatadogを使い始めました」というストーリーで始まるこのコースでは、下記4つの項目についてDatadogの検証環境 (ラボ環境) を使用して学ぶハンズオン形式となっています。画面は検証環境のアカウント情報が記載されているコンソールと、レッスンのテキストで構成されています。 ダッシュボードの操作 ログデータの検索と可視化 サービスカタログによるサービス詳細の確認 モニターの管理 このコースはDatadogのWeb UIから各機能へのアクセス方法や、データを調査する際にどういった流れで行うのかといった基本的なDatadogの操作方法や考え方を学ぶことができます。私がDatadogをRelearnするにあたって必要だったのはまさしくこのコースであり、入社後すぐに取り組めば良かったと後悔する程度には得られるものが多かったです。 3. Datadog Foundation Datadog Foundation 最後に紹介するのはDatadog Foundationというコースです。このコースは下記の5つの機能を学ぶためのレッスンで構成されており、それぞれのレッスンは前後半2つのパートで構成されています。前半のパートでは座学で機能とコンセプトを学び、後半のパートではハンズオン形式でDatadogの検証環境を使用して設定変更などを行います。 Universal Service Monitoring (USM) and Service Catalog Logs Metrics Integrations Dashboars まずは動画を見て機能とコンセプトを知り、実際に検証環境でWeb UIを操作してみて理解するという構成がいい感じです。同じハンズオン形式であるDatadog Quick Startのコースに比べてそれぞれの機能をより深く学ぶことができるため、より実践的なコースであるという印象を受けました。特に後半のハンズオンパートは意外とボリュームがあり驚きました。コンソールにIDEのメニューが増えており、docker-compose.ymlファイルを見つつDatadogの検証環境の表示を比較するといったものがあります。 Datadogでのログ周りの集計やビジュアライズの方法をすっかり忘れてしまったこともあり、こちらのコースでしっかりと復習することができました。簡単な確認テストがいくつかあるので復習もできます。 まとめ Datadog Learning Centerを活用することでDatadogの知識をRelearnした話を書いてみました。 Datadog Learning Centerは無料で利用でき、実際にDatadogの検証環境が利用できる期限付きのアカウントが払い出されるため、書籍やドキュメントなどに比べて学習効率が高いと感じました。これからDatadogを触る人や、私のように久しぶりに触る人にとっては最適なコンテンツのように思えます。チーム共通の知識としてエンジニアの入社後のオンボーディングに組み込んでみたり、あまりDatadogを使いこなせていないチームに受講して貰って活用のきっかけにしてもらうというのも良さそうです。 Datadog Learning CenterにはDatadogの機能を学ぶためのコースだけではなく、前述のオブザーバビリティへの理解を深めるコースやSite Reliability Engineerについて学べるコース、OpenTelemetryを学べるコースなどもあります。先日のJAWS FESTA 2024では「オブザーバビリティはツールを導入するだけでは実現できない」という話をしましたが、オブザーバビリティの意義を正しく理解することでHowとしてのDatadogがプロダクトの課題を解決する手助けになるでしょう。 また、Datadogの認定試験ではDatadog Learning Centerの一部のコースを学ぶことが推奨されており、学習 → 認定 → 活用という一連の流れが上手く設計されているという印象を受けました。 www.datadoghq.com 私も来年こそはDatadog認定資格を取得しようと考えているため、まずは全てのコースを制覇しつつDatadogへの理解を深めていこうと思います。みなさまもDatadog Learning CenterでLearn・Relearnに挑戦してみてください。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月4日の記事です。 qiita.com 保育士人材バンク のサービスを担当しておりますエンジニアの田実と申します。 保育士人材バンクは保育業界で働く方と事業所のための就職・転職マッチングサービスです。 本記事では2024年の保育人材バンクの技術基盤改善の取り組みを振り返っていきます！ コンテナ化 今年一番大きかった基盤改善は何と言ってもコンテナ化です！コンテナ化前はEC2上にアプリケーションがホスティングされており、デプロイはrsync、ログはSSHでサーバーに入って直接ログファイルを確認、といった運用を行っていました。 EC2でホスティングされているためミドルウェアのアップグレードが気軽にできなかったり、デプロイ方法もアトミックな変更ではないためデプロイ中のアクセスがエラーになることもありました。ログの確認はログファイルを直接awk、sort、uniqコマンドを使って走査していく方法になるため手軽に確認できない課題がありました。開発環境に関しても１人１環境といった形で運用していたため、複数の施策を並行して開発する場合、対応内容がバッティングする問題もありました。 これらの課題を解決するためアプリケーションをコンテナでホスティングするよう改善を行いました。コンテナ化により、 ミドルウェアの変更が簡単に行えるようになった デプロイがコンテナベースになりアトミックな変更になった ログがCloudWatch Logsに連携され、簡単に確認・集計できるようになった プルリクエストごとの環境（Edge環境）が作成できるようになった など開発体験が大幅に向上しました。取り組みの詳細はSREチーム伊藤のPHPカンファレンス小田原2024での登壇資料にも書かれておりますので是非ご参照ください！ speakerdeck.com PHPとLaravelのアップグレード 保育士人材バンクのサイトはPHP・Laravelで実装されており、これらのアップグレードを行いました。アップグレードガイドの確認をしつつ、手動テスト・自動テスト・PHPStanによる静的解析・Rectorによる自動リファクタリングを行い、不具合を検知したりアプリケーションコードを修正しました。社内でも同バージョンへのアップグレードを行ったアプリケーションがあったため、知見を聞いて回ったりしました。 前日に急いで聞き回っている図 Cookieの暗号化・復号化のロジックが変わる変更で一部影響がありましたが、特に大きな不具合なくリリースができました。アップグレードにより、PHPやLaravelの新しい機能を利用できるようになり開発体験が向上しました。特にmatch式、Enum、Constructor Property Promotion、readonly の機能は積極的に活用しており、より保守性の高いコードを書けるようになりました。 GitHub ActionsによるCI/CD導入 コンテナ化に伴い、GitHub Actionsで ecspresso を使って自動デプロイを行っています。 また、GitHub ActionsによるCIも導入し、プッシュ時に以下の処理を動かしています。 Laravel Pint , Biome を使ったフォーマットチェック PHPStanによる静的解析 PHPUnitによる自動テスト・カバレッジ集計 technote-space/assign-author を使ったプルリクエストの自動アサイン 以前は手動テストやレビューで品質保証することが多かったのですが、CI導入によりデグレ防止やコード整形など一定の品質水準を保つことができています。 Laravel Pint導入に伴い既存ファイルを一括変更した図 Datadog APMの導入 以前はアプリケーションのパフォーマンス計測ツールを導入していなかったため、ボトルネックがどこにあるのかがわからず、パフォーマンス改善戦略を立てることができませんでした。また、パフォーマンスチューニング後の効果測定も難しい状況でした。これらの課題を解決するため、Datadog APMを導入しました。 Datadog APMによりN+1クエリやindexが効いていないクエリなどのボトルネックがわかっただけではなく、アクセス数が多いエンドポイントや、メルマガなどの施策によりスパイクしやすいエンドポイントなどアクセス傾向を把握することができました。 リリース前後のレイテンシ変動が可視化されたため、効果測定も容易になりました。 N+1対策の例。7.5s => 180msと40倍の改善！ 自動テスト拡充 PHP・Laravelのアップグレードやリファクタリングを安全に行うため、自動テストを拡充しました。4〜5ファイルほどしか無かったテストコードが、今では100ファイル以上、カバレッジも70%を越えました。PHP・Laravelアップグレードなど大規模な変更を行うときも自動テストにより不具合を検知するなど、自動テストの効果を実感しています。 octocovでカバレッジ集計しています。Code To Test Ratioはこれから頑張る！ PHPStanの導入 前述の通り、静的解析ツールとしてPHPStanを導入しています。未定義変数の参照、use漏れ、クラス名・メソッド名間違い、引数の過不足・型間違いなどの不具合を検知してくれるため、堅牢なコードを書くのにとても便利です。 現在はPHPStanをレベル6で運用しています。レベル6は引数や戻り値の型付けが必須なため ignoreErrors で対応しているのが現状なのですが、一部Rectorを使った自動型付けを行い型エラーを解消していたりします。 OPcacheの有効化 OPcacheが無効だったため有効にし、全体で200〜300ms程度のレスポンス改善を行いました。 16:00ごろに適用して全ページでレスポンス改善した図 パフォーマンス向上だけではなく、CPU・メモリ負荷も下がりインフラコストも抑えられています。ちなみに、PHPのバージョンによってはJITを有効化するとセグメンテーションフォルトが発生する事象があったため、安全のためJITは無効化しています。 アプリケーションログの改善 コンテナ化に伴い、ログをCloudWatch Logsに連携するようになったので検索性を向上するために構造化ログ（JSONL）にしました。具体的には以下のようにMonoLogのフォーマッタ・プロセッサーを設定しています。 <?php class CustomSettingApply { public function __invoke ( Logger $ logger ) : void { $ introspectionProcessor = new IntrospectionProcessor ( Level :: Debug, [ 'Illuminate \\ ' ]) ; $ webProcessor = new WebProcessor () ; $ logger -> pushProcessor ( new UidProcessor ()) ; $ logger -> pushProcessor ( $ introspectionProcessor ) ; $ logger -> pushProcessor ( $ webProcessor ) ; $ logger -> pushProcessor ( function ( LogRecord $ record ) : LogRecord { $ record [ 'extra' ][ 'platform' ] = 'laravel' ; return $ record ; }) ; foreach ( $ logger -> getHandlers () as $ handler ) { if ( $ handler instanceof StreamHandler ) { $ handler -> setFormatter ( new JsonFormatter ()) ; } } } } JSONLのフォーマット以外の処理だと以下のような情報も入れ、検索性やオブザーバビリティを上げる試みも行っています。 UidProcessorでリクエストIDを払い出し IntrospectionProcessorでログが吐かれたファイル名・クラス名・行番号などを記録 WebProcessorでwebリクエスト関連の情報を付与 Viteを導入 以前はSCSSのビルドを各自ローカルで実行し、ビルド物であるCSSをgitにコミットしてrsyncでリリースしていました。この方法だと、元のSCSSだけでなくビルド物をコミットする必要があるため、ビルド物のコンフリクトが多発していました。そのため、ビルドツールである Vite を導入し、開発時のHotReloadやデプロイ時の自動ビルドができるようにしました。これにより手動ビルドやコミット、コンフリクト解消の手間がなくなりました。 また、SCSSだけではなく一部のJavaScriptもViteでビルドしています。ビルドツールを入れることでライブラリのバージョン管理やキャッシュバスティングもやりやすくなりました。 不要コード・パッケージの削除 保守性を上げるために不要なコードは随時削除していきました。結果、40万行のコードを削除しました。 4400ファイル、30万行の大削除の図 CSS、JS、IMGの不要ファイルがほとんどで、grepしたりアクセスログを見て泥臭く削除していきました。PHPに関してはPHPStan、Rectorなどのツールを使って削除対象を特定したり、明らかに使って無さそうなwebエンドポイント・コマンドを逐次ヒアリングして削除していきました。PHPの削除に関しては、前述の静的解析や自動テスト拡充により誤って削除することもほとんど無かったです。 Renovateによる定期アップグレード 依存ライブラリのアップグレードを定期的に行うと、ライブラリの変更量が減り影響範囲が読みやすくなったり、最新機能を利用できるようになるなど開発体験を上げることができます。そのため、アップグレードを定期的に行う仕組みとして Renovate を導入しました。Renovateはアップグレードのプルリクエストを１つにまとめてくれるなど小回りの効く設定を入れられるのが運用上のメリットです。今は週次の当番制にしてRenovateが作ったPRを担当者がリリースするようにしています。 振り返り（スプリントレビュー）の実施 ２週に１回、振り返り会を実施するようにしました。エンジニアだけではなくマーケティングチームの方にも参加いただき よかったこと・続けたいこと Thank you！！感謝！！ やってわかったこと・気付き これどうする？これは変えていきたい の４つに分けて付箋を貼っていき発表しています。 個人的には「Thank you！！感謝！！」のところが良いと思っていて、エンジニア間だけではなくマーケティングチーム・エンジニア間で改めて感謝を伝える場として、とても良い振り返り会になっていると感じています。 まとめ 保育士人材バンクでの技術基盤改善の取り組みについて紹介しました。本記事では技術基盤の改善を中心に紹介しましたが、攻めの施策開発もそれ以上にたくさん行っています。これまで攻めの施策をしっかりやってきた、やっているからこそ守りの施策の意義が出ると思っています。改めて保育士人材バンクに携わっている、携わってきたすべての方々に感謝しつつ、今後もこれまで以上にエンジニアリングで事業を加速させていき、より社会貢献ができていければと考えています。

この記事は株式会社エス・エム・エス Advent Calendar 2024の3日目の記事です。 qiita.com 介護・障害福祉事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの神谷です。先日、AWS GameDayに参加し、セキュリティ・インシデント調査の疑似体験をしてきましたのでその様子をレポートします。 AWS GameDayについて AWS GameDay はAWSが主催する、仮想的に用意された環境の中で、課題を解いて参加チーム間で成績を競うゲーム形式のセミナーです。 今回参加したGame Dayは、「セキュリティインシデント疑似体験」がテーマとなっており、典型的なセキュリティインシデントを再現させたログを分析し、チーム対抗のクイズ形式で調査していくものでした。 私は、情報処理技術者試験で机上のセキュリティインシデント分析する問題を解いたことはありましたが、実際の業務で触れる機会はこれまでなかったので、体験できる貴重な機会だと思い参加を決めました。 おことわり: 問題の詳細な内容については公開が禁止されておりますので、このエントリーでは触れません。 演習内容 始めに、ログ分析に使用する、SIEM on Amazon OpenSearch ServiceのDashboard（以下OpenSearch Dashboardと表記） の使い方と、調査するシステムの構成の説明を受けました。 GameDayの大まかな流れは次のようなものでした。 疑似的な攻撃を受けたシステムのログがOpenSearch Dashboardで検索できる状態で問題が与えられ、参加者はログからインシデントを分析し問題に解答していきます。 問題では、どのシステムがどのように侵入されたのか、どのような影響を受けたのか、影響を受けたのはいつか、被害範囲はどこまでなのかといった分析能力が問われました。 問題に回答することでスコアを獲得、ヒントを使用したり間違った回答をするとスコアが減点されるため、スピードと正確性の両方が求められました。 エス・エム・エスチームは次のような作戦で課題にチャレンジしました。 ハイスコアを狙いつつも、参加メンバーが別々の問題を解くのではなく、全員で画面共有をしながらモブ作業をすることにしました。 参加したメンバー間にログ調査の経験やAWSのセキュリティなどの知識に差があったため、今回のモブ作業を通してお互いのスキルが高められるようにこのような問題の解き方にしました。 それでは、問題の内容について、ネタバレにならない範囲で紹介します。 序盤の問題は、問題文自体がヒントとなっており、かつログからも読み取りやすい典型的な攻撃手法だったため順調に回答を進めていきました。 中盤の問題は、少しログやヒントを読むだけでは攻撃者の意図が読み取りづらく、複数のログから絞っていくスキルが求められてきました。またTCP/IPやWebアプリケーションの知識も求められました。 残念ながら今回は最終問題に到達したところで時間切れとなりました。 今回私たちのチームでは、モブ作業で課題にあたったことで、 ログ解析に慣れていないメンバーがOpenSearch Dashboardの操作で困った時には有識者にナビゲーションしてもらい、スタックしてしまうことを回避できました。 また、難問にあたった際には、関連するログがここにあるのではないか、こんな条件で探してみてはどうか、互いの持つ知識でカバーができました。 結果的に、回答できた問題数は限られていましたが、限られた時間の中で無駄なくログ調査の経験を積むことができたと感じています。 演習終了後に今回の演習で扱われたセキュリティインシデントのシナリオの解説が行われました。 最終問題のシナリオには、調査を難しくする手法も使われており、前提知識がない状態でこのようなログを元にインシデント分析をするとなると解決まで骨が折れそうだなという印象を受けました。 得られた知見 最後に、今回のAWS GameDayを通して得られた知見についてまとめます。 今回 GameDayの課題としてOpenSearch Dashboardに用意されていたログは、複数のログを組み合わせて検索しやすいよう、あらかじめ正規化されたログになっていました。そのため、初見のシステムでも違和感なく調査を進めることができました。 一方で、ログが適切に正規化されていなかったり、素早く検索できる仕組みが整えられてない環境では、調査が難航することが想像できます。 セキュリティインシデント対策に限られた話ではありませんが、システムを設計する段階から、どのようなログがあれば万一の際にどこまで調べることができるのかを考えるきっかけになりました。 AWS GameDayは他のテーマでも開催されているようですので、見識を広めるために今後も参加してみようと思います。

スクラムマスターの貝瀬です。2024年6月から業務委託として、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。 支援先の部門では、私が参画する以前よりカイポケリニューアルプロジェクトにスクラムをベースとした開発プロセスを導入していましたが、2024年8月にLeSS（Large Scale Scrum：大規模スクラム）を導入しました。今回はLeSSを導入することになった経緯と、導入の最初のステップを紹介したいと思います。 はじめに 本題に入る前に、私の略歴と、エス・エム・エスを支援することになったきっかけを紹介します。 私の経歴 現職の「 合同会社makigai （マキガイ）」を創業する前は、IT系の事業会社を中心に活動していました。キャリア3社目となる株式会社ディー・エヌ・エー時代に、開発部門におけるマネジメント上の課題を解決するために導入したのが私とスクラムとの出会いです。 以降、マネージャー・スクラムマスター・プロダクトオーナーなどの様々な役割で、既存事業・新規事業・オフショア開発・営業部門・人事領域などの様々なプロジェクト・組織にスクラムを導入・活用して、10年以上が経ちました。大小さまざまな経験（成功も失敗も）を含めると、3桁を超える程度のスクラム活用経験はあるかと思います。 そうして積んだ経験を体系的に整理し様々な企業にも共有してみたかったのと、スクラムの師匠であり友人でもある江端さんと一緒に働いてみたくて、プロダクト開発のコーチ集団Odd-e（オッドイー）の日本法人である Odd-e Japan （オッドイー・ジャパン）にも4年ほど在籍しました。 カイポケのプロダクト開発におけるLeSSの導入事例は、私の経験の中でも広く知っていただく価値があると感じ、こうしてブログを書くことになりました。 エス・エム・エスとの接点 ディー・エヌ・エー時代の同僚である田辺さん（ @sunaot ）の紹介で、2023年秋ごろプロダクトマネージャー向けの研修を開催したことが最初のエス・エム・エスとの接点でした。その後しばらくして、再び声をかけていただき、カイポケの開発関係者に向けて、スクラムの基礎から応用まで、実践できるようにしてもらえないかという相談を受けました。通常私は、スクラムマスターの方を育成する立場（いわゆるアジャイルコーチ）で参画することが多いのですが、カイポケには専任のスクラムマスターがいないということだったので、私がその役を引き受けることになり、現在に至ります。 LeSS導入の背景 LeSSを導入する前の組織構造は、1つのプロダクトに対して、複数のプロダクトオーナー、複数のプロダクトバックログ、複数のチームという構造でした。開発に携わる人数としては約50人程度だったかと思います。当時は、2チーム以上の協力が必要な開発を行う際に、以下のような問題が発生していました。 他チームに依存するPBI（プロダクトバックログアイテム）がある場合、着手したスプリント中に完成しない。 過去に完成させたはずのPBIに対して、突然他チームからの問い合わせや修正依頼が発生する。 私がスクラムマスターとして参画してしばらくの間は、問題の発生頻度が少なかったため、プロダクトオーナーやチーム、マネージャーやステークホルダーたちもさほど困っていないようでしたが、これは上記で述べた組織構造に起因する問題の一つです。いつか（おそらく半年以内に）必ず問題の優先順位が上がると予想していたので、チームレベルの改善を支援しながら、LeSS導入の準備を進めることにしました。 LeSS導入の戦略 LeSSはカイポケのように数十名規模の組織で1つのプロダクトを開発する際に有効なフレームワークです。LeSSの大雑把な構造としては、1つのプロダクトに対して、1人のプロダクトオーナー、1つのプロダクトバックログ、複数のチームが紐付きます。 公式サイト より引用 LeSSは守破離の学習モデルに沿って考えられており、「守（基礎となる部分）」は、LeSSの原理・原則と、ルールとして定義されています。カイポケへのLeSS導入にあたって最も重要視したのは以下のルールです。 単一のプロダクトグループへの導入では、最初から教科書的なLeSSの体制を作るようにします。これはLeSSの導入にとって不可欠です。 さらに大きなプロダクトグループを超えて大規模な組織に導入する場合は、現地現物を用いて、実験と改善が当たり前であるような組織をつくり、段階的にLeSSを導入します。 （出典：Craig Larman・Bas Vodde（著）、榎本明仁（監訳）、荒瀬中人・木村卓央・高江洲睦・水野正隆・守田憲司（訳）『大規模スクラム Large-Scale Scrum(LeSS)』、丸善出版、2019年、52頁） 上記を踏まえ、LeSS導入までの間に意識していたことは以下の3つです。 チームレベルのスクラム理解度・実践力をあげること 複数チームが関わる問題を観察し原因に対して仮説を立てること スプリントレトロスペクティブ等におけるチーム・組織に対する改善アクションが、部分最適になりすぎないよう選択肢の幅を広げること 取り組みの具体例についてはこの後紹介します。 勉強会を活用したスクラム理解度・実践力向上の土台作り スクラムのルールとLeSSのルールと自分たちのやり方との違いを知り、改善につながるネクストアクションを考えていただくことを目的に勉強会を開催しました。 過去にプロダクトマネージャー向けの研修を実施したことは冒頭で述べたとおりですが、熱心に参加されている方が多くいらっしゃったことを鮮明に覚えています。実際にスクラムマスターとして参画してみると、当時学んだことを現場で実践されている方が多いことにも衝撃を受けました。こうした経緯から、スクラムやLeSSに関する学習の機会を設ければ、自主的に現場の業務に活かしていただけるのではないかという期待があったためです。 実際に開催告知をした時のリアクション スクラムに関するワークショップ スクラム勉強会はワークショップ中心の、参加者自身に考えていただくスタイルで行いましたが、当初の狙い以上に盛況となりました。これは、人から与えてもらうのではなく自分自身で学ぶこと・改善することが習慣化していることを表す一例だと捉えています。さらには、プロダクト開発に直接関わる方々だけでなく、マネージャーやステークホルダーも積極的に参加されていたので、全体を巻き込んだ改善活動を促進する上での土台がしっかりしている組織であると感じました。私が主催する勉強会は現在も継続していますが、それぞれのチームでも、スクラムやLeSSに関する勉強会を自主的に開催しています。 参考までに、スクラム勉強会の参加者からいただいたフィードバックの一部を紹介します。 よかった。自分のわからないこと、解決できないことが、適切に難しいことだという現在地の確認になった QAで、組織やプロダクトの状況視点ではなく「スクラム」という視点で切り離して会話ができたことが自分にとってはよいことでした。社内で話すとどうしても「現状を鑑みて」になりやすいので、まずはフラットにスクラムを行うために必要な情報が整理でき大変勉強になりました。 スクラムマスター不在の状況で今までやってきたため、そもそもスクラムマスターの役割と必要性があまり理解されていないように感じています（自分も含めて）。グループワークの中で、4グループ中2グループが、スクラムマスターについて付箋を出していることからも、スクラムマスターの役割と必要性について取り扱ってほしいです。 LeSS 勉強しようと思って手つかずだったので概要がつかめて良かったです！ LeSS導入準備のための現地現物 私が参画する以前はスクラムマスター不在でしたが、チームの中でファシリテーターを決め、スプリントプランニングやスプリントレトロスペクティブなどのスクラムイベントを実施していました。そこにオブザーバーとして参加しながら、LeSSの導入によって改善が見込まれる事象を観察していました。同様に、プロダクトバックログやスプリントバックログをはじめとするスクラムの作成物、作成物に付随するアウトプット、スクラム以外の定例会議なども観察対象です。 一方、勉強会の効果もあってかチームから自主的にフィードバックを求められるようになってきました。例えば「他チームに依存するPBIが着手したスプリント中に完成しない」といった類の問題が出てきた場合にはLeSS導入時の妨げとなるような部分最適の改善にならないように、視野や選択肢を広げるためのフィードバックやオプション提示などをしていました。問題の真因が組織構造などにありそうな場合は、考察をまとめながら、フィードバックや提案の機会を待つようにしました。 冒頭でも触れたように、その機会が訪れるのは半年くらい先になるだろうと踏んでいたのですが、驚くことに私が参画してから2ヶ月後にはLeSS導入が決定、3ヶ月後にLeSSが開始されるという意思決定の早さでした。 多くのチーム、多くの方々が課題に感じていたことへのソリューションがLeSSだったというだけの話ですが、組織全体にスクラムの5つの価値基準が浸透していることが成功の秘訣だったと思います。 スクラムを成功させるためには、5つの価値基準をより高度に実践することが求められる。 確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage） チームは継続的な改善とお互いのサポートを確約する。チームは最善の成果を上げるために、スプリントでの作業に集中する。チーム、プロダクトオーナー、そしてステークホルダーは、作業と課題を公開する。チームのメンバーはお互いを能力があり自立した人間として尊敬し、一緒に働く人たちからも尊敬される。チームメンバーは、正しいことを実行し、困難な問題に取り組む勇気を持つ。 これらの価値基準は、作業、⾏動、そして振る舞いの⽅向性を⽰している。下される決定、実⾏される手段、スクラムの使⽤⽅法は、これらの価値基準を強化するものであり、減少させたり損なったりするものであってはならない。これらの価値基準がチームや⼀緒に働く⼈たちによって体現されると、スクラムの経験主義を支える三本柱「透明性」「検査」「適応」が実際に機能し、信頼が築かれる。 （出典：「スクラムガイド(LeSS版)」 https://less.works/jp/less/scrum-guide 、参照2024年11月14日） LeSS導入直前のSlack おわりに 今回の記事ではカイポケにLeSSを導入した経緯と、最初のステップについて紹介させていただきました。カイポケではスクラムおよびLeSSによるプロダクト開発を行っており、現在も、実験と改善を積み重ねながら進化中です。機会があれば、LeSS導入後の事例も紹介したいと思います。 社会課題の解決、顧客価値の創造、スクラムによるプロダクト開発、などに興味のある方は、ぜひエス・エム・エスへの入社を検討してみてください。

介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する整備や調整を担当しています。 最近社外で登壇する機会がありまして、オブザーバビリティに関する内容の登壇をいくつかしてきました。同一テーマで複数回の登壇をするのが初めてということもあり、そこで得られたものや気付きについて振り返ってみたいと思います。 直近で登壇した / 登壇するイベント まずは直近登壇したイベントについてそれぞれ紹介していきます。 1. JAWS PANKRATION 2024 jawspankration2024.jaws-ug.jp 開催日 2024/08/24 (土) 12:00 PM 〜 2024/08/25 (日) 12:00 PM 登壇形式 プロポーザルによる採択を経てオンラインにて登壇 参加者数 約600人 JAWS PANKRATION 2024は2024年8月に開催されたAWSユーザーグループのイベントです。24時間連続でオンライン開催され、国内外のエンジニアが登壇するグローバルイベントと位置づけられていることからスライドは英語であることが必須となっています。 登壇希望者はCall for Proposalsを確認したうえでプロポーザルを提出し、運営チームの選考を経て採択されるというカンファレンスでよく見る形式となっています。私は下記の内容でプロポーザルを提出し、無事採択いただく運びとなりました。 # タイトル How to achieve full-stack Observability with AWS (フルスタックオブザーバビリティをAWSで実現する方法) # 概要 In modern distributed complex systems like microservice architectures, observability is essential for quickly identifying issues. While understanding the concept of observability as proposed by the CNCF, I will suggest methods to achieve full-stack observability utilizing AWS services. マイクロサービスアーキテクチャのような近年の複雑な分散システムでは、問題を迅速に特定するためにオブザーバビリティが不可欠です。 CNCFが提唱するオブザーバビリティの概念を理解しつつ、AWSのサービスを利用してフルスタックオブザーバビリティを実現する方法を提案します。 持ち時間は15分、オンラインイベント故に参加者とのインタラクティブなやり取りは難しいと考え、前半はCNCF (Cloud Native Computing Foundation) のWhitepaperを紹介しつつクラウドベンダーによるフルスタックオブザーバビリティの説明をし、後半ではAmazon CloudWatchでの実現方法の話をしています。 既にセッション資料とアーカイブが公開されています。 jawspankration2024.jaws-ug.jp 2. JAWS-UG函館 勉強会 vol.14 jawsug-hakodate.connpass.com 開催日 2024/10/05 (土) 登壇形式 登壇枠への応募を経てオフラインにて登壇 参加者数 19人 JAWS-UG函館はその名の通り北海道の函館市近郊で開催されているJAWS-UG (AWS User Group – Japan) の勉強会です。私は2024年6月に地元北海道 (札幌) へUターンしたということもあり、北海道つながりで登壇しませんかとのお誘いがありまして登壇する運びとなりました。 参加者の属性と登壇内容についてヒアリングしてみたところ初学者向けだと嬉しいという話があり、JAWS PANKRATION 2024の資料を一部改変して初心者でも理解しやすいよう心がけました。具体的には序盤のCNCFやフルスタックオブザーバビリティの説明を削って「オブザーバビリティとは何か」「モニタリングとは何が違うのか」といった内容に差し替えています。 3. JAWS FESTA 2024 in 広島 jawsfesta2024.jaws-ug.jp 開催日 2024/10/12 (土) 登壇形式 プロポーザルによる採択を経てオフラインにて登壇 参加者数 343人 JAWS FESTA 2024 in 広島は2024年10月に広島で開催されたJAWS-UGによる全国規模のイベントです。JAWS-UGは年に2回全国規模のイベントを開催していて、春に都内で開催されるのがJAWS DAYS、秋に地方で開催されるのがJAWS FESTAです。 登壇希望者はCall for Proposalsを確認したうえでプロポーザルを提出し、運営チームの選考を経て採択されます。JAWS PANKRATION 2024と同じ形式ですね。私は下記の内容でプロポーザルを提出し、11倍 (!!) という倍率の中で無事採択いただく運びとなりました。 # タイトル Amazon CloudWatchで小さく始めるWebサービスのオブザーバビリティ # 概要 https://jawsfesta2024.jaws-ug.jp/sessions/timetable/D-1/ 採択されたのがテクノロジートラックで持ち時間が20分ということもあり、JAWS-UG函館でお話した内容に加えて「Amazon CloudWatchの良いところ・頑張ってほしいところ」「Amazon CloudWatchとObservability SaaSの比較」を盛り込んで内容を調整しました。自分としては一連の内容の完成形のつもりで登壇に臨みました。 セッション資料は既に公開済みです。 speakerdeck.com 4. 第39回 JAWS-UG札幌 勉強会 〜JAWS FESTA 2024 in 広島 re:Cap〜 jawsug-sapporo.connpass.com 開催日 2024/11/19 (火) 登壇形式 登壇枠への応募を経てオフラインにて登壇 参加者数 20人 JAWS FESTA 2024 in 広島に参加していたJAWS-UG札幌のメンバーから「運営スタッフを担当していたのでセッションを聞けなかった」「タイムテーブルが被ってしまい聞きたかったセッションを聞けなかった」などという話があり、であれば札幌でre:Cap (振り返り) として登壇の再演をやりましょうという流れから発生したのがこちらのイベントになります。 再演ということで基本的にはJAWS FESTA 2024で話した内容をそのまま話す予定でしたが、イベント参加者と話して得られた気づきを反映したものをお話します。 登壇内容の振り返りと気付き 直近の登壇は全て同じテーマで「オブザーバビリティとは何か、Amazon CloudWatchでどのように始めるのか」です。イベントと参加者の属性に応じて若干内容を調整はしますが、ベースとなる内容はほぼ一緒です。 同じ内容での複数回の登壇には当初懐疑的でしたが、いざやってみるといくつかのメリットを感じることができました。 1. 発表内容の洗練 似た内容で複数回登壇することが過去なかったので気づかなかったのですが、繰り返してみると下記のような色々な反省点が見えてきます。 「スライドの内容が前後で微妙に繋がっていない」 「内容を補完するための図が必要」 「前提となる話があったほうがよい」 「結論がぼやけている」 資料は事前に社内でレビューしてもらい自分自身で何度もリハーサルしていますが、発表当日になってリハとは環境が変わることで違和感に気づいてしまうケースがありました。これは純粋に私自身のプレゼンスキルの未熟さだと思います。 しかし今回は一連の登壇を経て資料と発表のアップデートを行い、最終的には自分でも納得できるようなものに近づけた気がします。特にJAWS FESTA 2024では参加されていた方のブログで「20分という短い時間でしたがプレゼン内容が洗練されていた」という評価をいただくことができました。 2. 理解の深化 アクティブ・ラーニングにおいては理解度を深めるには実際に説明してみることが重要であると言われています。資料作成のために調査する → 登壇する → 参加者と話す → 気付きを得る → また調査する → 登壇するというループを経てオブザーバビリティへの理解が深まり、ようやく背景など含めて説明できるようになりました。 一連の登壇により資料をブラッシュアップする過程で話の根拠や背景を改めて調べ直してみたり、概念やサービスにアップデートがあるかを確認してみたり、他に参考となる資料がないかを探すことで知識を定着し理解が深まることに繋げられたと考えています。 発表内容に明確な間違いが無い限りは過去の登壇資料を見直すことがなかったのですが、今後は意識的に見直していくことで近いメリットを得られるかもしれません。 まとめと今後の展望 ブログタイトルにある「オブザーバビリティ登壇マラソン」のとおり、ここ数ヶ月間でオブザーバビリティに関する内容での登壇を複数回行ってきました。オブザーバビリティの考え方や実践方法、各クラウドベンダーのオブザーバビリティへの取り組みに関する発表を行い、資料のブラッシュアップを経て多くの知識を得ることができました。 今回の一連の登壇では、改めてオブザーバビリティに関する知識の継続的なアップデートは必要不可欠であること、特定のテーマでの発表を続けることで理解が深まること、興味のあるテーマを見つけたら繰り返し登壇してみることといった学びを得ることができました。 一方でサービス特有の課題、苦労、困難、失敗、解決といった他の人にはできないリアルな内容での登壇はまだできていません。オブザーバビリティやAmazon CloudWatchのような一般的な内容の登壇にも価値はあると思いますが、やはりサービスやドメイン固有の苦労話こそ面白さと価値があると私は考えています。ですので、今後はカイポケのリニューアルにおける苦労話や失敗談などを話せるようにネタ探しや挑戦をしていく次第です。 もし登壇の場や機会がありましたら、加我のTwitter (X) アカウント ( @TAKA_0411 ) まで気軽にお声がけ下さい。 おわりに 株式会社エス・エム・エスは「継続可能な日本の未来をつくる」テックカンパニーを目指し「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」をミッションに掲げて様々な事業を展開しています。 ヘルスケア・医療・介護・シニアライフ業界の課題解決やバーティカルSaaSの開発に興味のあるSREの方がいらっしゃいましたらぜひお話しましょう！

こんにちは、2024年8月にエス・エム・エスに入社した鈴木と申します。 入社エントリーかつ、現在担当しているカイゴジョブエージェントについてお話します。よろしくお願いいたします！ これまでの経歴 自社でWebサービスを提供している数社でエンジニアをやっていました。技術スタックとしては、オンプレミスサーバでPHP(Laravel、Zend、独自フレームワークなど)+jQuery+CSSといった組み合わせの時代のものから、AWS+React+Vite+TypeScript+Material UIといったものまで幅広く(浅く...とも言いますが)経験してきました。ログ調査や障害対応などの運用保守もやってきました。 入社したきっかけ カイポケでデザイナーとして働いている、元同僚からのリファラルがきっかけとなります。エス・エム・エスという会社を最初から詳しく知っていたわけではないですが、カジュアル面談、面接と進んでいくうちに「ここで働きたい！」という気持ちが強くなりました。 社会 > 会社であること 入社前にお会いした方が口を揃えて「社会のために自分たち(会社)はなにをすべきか」と話されていたのは印象的でした。入社して3ヶ月が経過しましたが、実際に社内でも同じ会話が当たり前に行われていて、建前じゃなく本当に共通の価値として認識していると感じました。 一緒に働きたい方ばかりだった わたしの仕事の都合もあり、一年以上に渡って面談・面接をしていただきました。上記のお話や、プロダクトに真摯に向き合い課題解決をしようとされている方、長期に渡り調整・ケアいただいた採用担当の方。こんな方々がいる環境で働けたら最高だなと思いました。 自分のスキルで貢献できそう 上記に加え、これまで培ったスキルや経験で貢献できそうだ、というところも大きかったです。 カイゴジョブエージェント どう貢献できそうか、という流れから、担当しているカイゴジョブエージェントの開発環境についてお話します。 カイゴジョブエージェントとは 介護職向け人材紹介サービス「カイゴジョブエージェント」は、すごく簡単に説明すると、介護職で転職を考えてらっしゃるかたに情報を登録いただき、転職支援エージェントが面談などをとおして適切な職場を紹介し、新たな職場でスムースに働いていただくためのフォローまでするサービスです。 2024年の4月にサービスとしてもリニューアルし、上記にくわえ、求人情報を探すコンテンツが追加されました。 システム構成 図にあるとおり、Next.jsとLaravel+Bladeが混在する形で構成されています。振り分けはAWSのELBで行われています。 開発環境、デプロイフロー 箇条書きにしましたが、開発を進めるにあたって、現時点でも充分な環境が揃っていると個人的には考えています。 GitHub上でブランチを切って開発 デイリーミーティングで進捗確認 プルリクエスト(PR)でレビュー依頼 レビュアーがApporove ローカルPCでの環境構築はMakefileで管理 初期設定、コンテナの上げ下げ、テストデータのinsertなど PRに特定のタグをつけると、自動で確認環境が起動 タグを検知すると、GitHub上でワークフローが走り、当該PRを確認できる環境が起動します。社内であれば誰でも確認できるため、企画職もここからチェックが可能です。 開発環境、プロダクション環境も自動デプロイ 当然、同じワークフローでプロダクションへのデプロイも自動です。万一不具合があったときも、revertするだけで1つ前の状態に戻せます。 全体の流れを表現したものが以下の図です。 コンテンツの確認やリリース作業に手作業が入らないところが非常に大きいと感じています。エンジニアにとって一番ストレスがかかり精神を消耗するところをなくし、より事業に貢献する開発に専念できる環境だな、と思っています。 開発の進め方 企画職のメンバーがバックログに施策や課題をセットし、開発メンバーと優先度を決めていきます。 開発内では別のカンバンでタスクを管理し、各々がどのタスク・レビューを担当するかを決め進捗管理、疑問点や不明点は毎日の朝会で共有するといった形です。 課題 1つ目は上述したような、アーキテクチャの見直しや改善が必要なシステム面です。 混在したフロントエンドをNext.jsに集約している途中であることや、A/Bテストをする度にあるディレクトリのファイルが横に増えていく構造が保守やレビュー効率を下げているところ、アーキテクチャ以外だとテストコードのカバレッジがまだ低いなどが挙げられます。 2つ目は、どういった意図や目的をもってこのタスク・案件が切られているのかといった事業目線と、システムがどういう作りになっていて、こういう目的ならこうしたほうが想定効果は8割になるが圧倒的にスピード感を持って開発できる、といった目線がまだ企画職含めたプロダクトに関わる全員で共有・理解しきれていないところです。 よくある話といえばそうなってしまいますが、決してネガティブということではなく、現状でもこれだけできているんだから、理解が深まればさらにいいものが速くできる環境になっていくんだろうな、という期待のほうが大きいです。 3つ目は、こういった話ができる人材が不足していることです(笑)少しでも興味を持った方は エンジニア採用情報 をご一読の上、ぜひご応募を！(PR) まとめ 「人口減少」「少子高齢」といったキーワードは、日本に在住する人間にとって他人事ではありません。大小あれど、これまで経験してこなかった社会課題に誰もが直面していくはずです。 そんな課題に対して「技術」「情報」を武器に解決していける環境・仲間がいる会社である、と入社してとても感じました。やりがいをもって日々業務に携われているなという感覚が非常に大きいです。 最後まで読んでいただき、ありがとうございました！

こんにちは、エス・エム・エス テックブログ運営の大縄です。 今回は、同時期に SRE としてエス・エム・エスに入社した加我さん、山口さんによる、コミュニティ活動に関する対談記事をお届けします。 自己紹介 —— 本日はよろしくお願いします。まずは自己紹介をお願いします。 加我さん： 私は 2024 年 4 月にエス・エム・エスに中途で入社しました。新卒では Java プログラマーとして中小の SIer に入社したんですが、色々と社内での調整があり、 QA エンジニアとしてキャリアをスタートしました。その中で、サーバーのミドルウェアの検証や評価計画を行う過程で OS のインストールやハードウェアの構成変更を経験しました。QA 業務自体は楽しかったのですが、でもやっぱりプログラミングをしたいという気持ちがあったので、PHP のバックエンドエンジニアとして 2 年間ほど活動しました。当時サーバー障害でレンタルサーバーのデータが消えるという問題が発生し、それをきっかけにインフラに興味を持つ様になりました。その後、インフラエンジニアに転身し、現在は SRE として働いています。元々はユーザーとの距離が近い toC のエンタメ事業が好きだったのですが、技術コミュニティ繋がりで弊社の空中さんと話す機会があり、エス・エム・エスの事業内容や技術的な課題、社会課題の解決というスケールの大きな話を聞いて興味が湧き入社を決めました。 山口さん： 私は加我さんの 1 ヶ月後にエス・エム・エスに中途で入社しました。最初は通信系の会社で公衆回線系の仕事をしていたのですが、もっと IT エンジニア的な仕事をやりたいと思って転職しました。ただ、転職後もサーバーやネットワークの構築の仕事が多く、再度プログラマーになるべく転職して生産管理系のシステムを担当することになりました。そこで Java や Oracle Database に触れるうちにデータベースに興味を持ち、DB チューニングをするようになりました。それがインフラへの関心へと繋がっていきました。その後フリーランスに転向し、インフラエンジニアとしての仕事に振り切りました。現在はエス・エム・エスで SRE として働いています。 —— 共に SRE として働かれているということですが、現在の業務内容を教えていただけますか？ 加我さん： 私はカイポケリニューアルの SRE を担当しています。まだリリース前なので SRE 的な活動はそこまでできていないのですが、トラフィックが増えたり障害が発生したときにどうするかなど、正式リリースに向けて土台を固めている最中です。現在は主にモニタリング周りの運用設計を進めています。チームごとにオブザーバビリティのレベル感が違うので、各チームにヒアリングを行いながら全体の運用レベルを合わせていくような活動をしています。今後は SLI、SLO についても考えていく予定です。 山口さん： 私は全社 SRE として活動しており、専任の SRE がいないプロダクトを横断的にサポートしています。今は Reliability に関わる業務よりオペレーションやインフラ面での業務が多く、全社統制の役割もあるので、インフラエンジニアや CCoE が近いかもしれません。最近はセキュリティに力を入れてるのですが、全体的な業務量が多いということもあり、トイルの削減にも力をいれてます。 コミュニティ運営のキッカケ・活動内容 —— お二人はコミュティ運営にも積極的に関わられていますが、どのような経緯で始められたのですか？ 加我さん： 2014 年頃、AWS を使ったサービスの構築・運用をしていたのですが、当時は AWS を学ぶ環境があまりなく、どうしようか悩んでいたところ、目黒で受けた AWS のハンズオンでJAWS DAYS というイベントを知り、そこからコミュニティというものを知り参加するようになりました。当初はコミュニティの参加者として活動していましたが、2015 年頃からPHP カンファレンス、PHPerKaigi、iOSDC などのイベント撮影スタッフを経て、2022 年に Media-JAWS というメディア系の AWS 活用事例や知見を共有するユーザーグループの運営メンバーに誘われ、運営に関わるようになりました。 山口さん： 私は 5 年前（2019 年）くらいから AWS に関わり始め、Control Tower や Security Hub などの全社統制の仕事をしていたときに参加した Security-JAWS の勉強会で、AWS のサポートの方の発表を聞いたのがキッカケです。そこで自分からも何か発表できることがあると伝えたところ、発表の機会をもらえることになりました。2022 年末ごろに JAWS-UG 千葉支部を紹介され、そこから本格的にコミュニティに関わるようになり、2024 年からは SRE NEXT のコアスタッフとして運営に関わっています。なのでコミュニティの運営歴という意味では加我さんと同じくらいですね。 —— コミュニティ運営では実際にどのような活動をするのでしょうか？ 加我さん： コミュニティのイベントは大きく分けて 2 つあって、「勉強会」と「カンファレンス」があります。勉強会はよく connpass などのイベントサイトに立ち上がるようなやつで、数週間〜数ヶ月に 1 回程度開催されています。テーマはその時々で、登壇者は身近な人から探したり、広く募ったりもします。私が運営に携わっている Media-JAWS だと関東近郊だけでなく、大阪、岩手、名古屋などでの開催もあるので、各地方で会場を貸してくれる方や現地で旗振りしてくれる方を探したりすることも重要だったりします。一方カンファレンスは基本的に年に 1 回開催される大きなイベントです。勉強会との違いは、規模はもちろんのこと、企業から協賛を募ったり、登壇希望者から提出されたプロポーザルを運営メンバーが確認し審査する、といった違いもあります。 山口さん： JAWS-UG 千葉支部もやることはほとんど同じです。JAWS-UG は年に 1 回以上のイベント開催が支部としての必要な条件になっているのですが、それだけだと支部としての活気がないので年に数回開催しています。千葉支部は支部の都市以外の方々にも届けたいという思いがあり、東京開催が多いです。カンファレンス運営は規模も関わる人も多いので、半年くらいのプロジェクトのようなイメージで準備を進めています。チーム分けして、ガントチャート引いて、定例会を開催して、みたいな感じです。 コミュニティ活動も業務の一環 —— 色々とやることがあるんですね！仕事との両立は大変ではないですか？ 山口さん： 主にカンファレンスについてですが、準備は業務後や土日に活動することがメインで、他の運営メンバー含めコミュニケーションもそのあたりの時間帯が活発です。なので、業務が忙しい時期に波があると準備に時間が割けなくなってしまうので辛い面はあります。自分がボールを持った状態で業務負荷が上がってしまうと他の運営メンバーの準備作業にも影響しまうので、作業を誰かにお願いするなど、ある意味マネージメント力も必要になってきますし、なるべく個人に依存する準備作業を作らない、業務の波を作らない、といったことも重要です。ただ、一番大変なのは自分が登壇する場合の登壇資料を作成することですね。 加我さん： 登壇資料作り、大変ですよね。私もそこそこ登壇の機会をいただいており、Interop Tokyo で Medis-JAWS の話をしたり、最近では山口さんも登壇された JAWS PANKRATION 2024 にも登壇しました。JAWS PANKRATION 2024では英語での資料作成が必要ということもあり結構大変でして、業務的にも期限が迫ったタスクがあったので業務時間を資料作成に充てられず、業務後に夜中まで資料を作成していたりもしました。ただ、本来は資料作成も業務の一環と捉えるべきという話は EM ともしていて、今後はあらかじめ計画に組み込むなど業務と登壇資料作成のバランスをとっていくのが健全だと考えています。 山口さん： コミュニティの運営活動を業務の一環として捉えてもらえるのは嬉しいことですよね。登壇資料作成もそうですが、制作物（パンフレット、ノベルティ、スタンプラリーの景品、アンケートパネル、バナーなど）の作成のように時間がかかる作業について業務時間を使えるので助かります。プライベート時間を全部使う必要がない、ということがコミュニティの運営活動の継続につながっていますよね。 加我さん： そうですね、あとはカンファレンス当日の運営を業務として扱えることも嬉しいですね。カンファレンスは土日祝開催が多かったり、前夜祭、Day1、Day2 みたいな感じで複数日開催する場合もあって体力的な厳しさがあるので、翌日に代休が取れて助かっています。 —— 業務の一環としてコミュニティやカンファレンスに関する活動を行いたいと思ったときにどのようなコミュニケーションをとっていますか？ 加我さん： 私は EM にイベントの運営や登壇について業務・出張扱いで良いかを確認しながら進めています。例えば登壇であれば、こういうイベントがあって、こういう内容で登壇するとこういう方々にリーチできると思うので業務として参加したいです、といった感じです。 山口さん： こういうイベントがあるから業務として参加してきて良いですか？くらいフランクなコミュニケーションをとるケースもありますよね。 加我さん： はい、ただ私の場合は札幌からの参加になるので、飛行機や宿泊の費用が多くかかってくることから、ある程度の参加意義を伝えることが必要だと考えています。フランクに確認しても問題ないとは思うのですが、Slack などオープンなところでこういったコミュニケーションをとることで今後参加したい方の参考になればと思っています。 山口さん： そうですね、現状は勉強会やカンファレンスに飛行機に乗ってでも参加したいという人がそこまで多くないのである程度融通がききやすい面はあると思うのですが、今後増えてきたときにコミュニケーションの内容が残っていることは重要だと思います。 協賛の提案にも積極的に支援 —— オープンな場でのコミュニケーションというと、山口さんがカンファレンスへの協賛に関するコミュニケーションを取られているのを見かけたのですが、そのときのお話を聞かせていただけますか？ 山口さん： はい。JAWS Festa 2024 in 広島に参加するときに協賛してはどうかという提案をしました。Kotlin Fest、RubyKaigi、SRE NEXT など、組織として例年協賛してきているイベントだけでなく、社員それぞれが意思を持って協賛したいといったものについても会社としては積極的に応援していて、費用面の支援を含めた社内稟議のプロセスも整備されています。 加我さん： イベントへの協賛については採用広報の観点もあるとは思いますが、私達は「その技術やコミュニティへのリスペクト」が前提としてあります。このような考え方や背景があるので会社として勉強会やカンファレンス参加など、業務につながるような学習に対して投資は惜しまないのだと理解しています。 コミュニティ活動が業務に活きる —— コミュニティやカンファレンスに関する活動がどのような面で業務に活きていますか？ 加我さん： コミュニティには様々な人がいるので、バックグラウンドが異なる人たちとコンテキストを合わせながらコミュニケーションをとっていくスキルを向上させられたと思います。特に SRE は社内に関わる人が多く、その時々で相手の目線に合わせた表現をしながら物事を進めていく必要があるので、コミュニティ活動の経験が役立っています。 山口さん： コミュニティ活動でいろんな人とコミュニケーションをとることで、人の輪が広がり、輪の中の方々の情報発信を拾いやすくなるといった側面もあると思います。そこで得た情報は、今の自分にとってすぐには役立たないけどちょっと先に役立つかもしれないといったものがたくさんあり、業務中にポンとやってきたボールを返すときに、そういえばこういう情報があったなぁという記憶があると調査しやすく、非常に役立っています。カンファレンス開催に着目していうと、プロジェクトみたいな感じで準備が進んでいくので、ファシリテーション、チームマネジメント、プロジェクトマネジメントなどの業務でも使うスキルが必要です。さらに、イベントを運営していく中でもそれらのスキル自体が磨かれていくので、うまくフィードバックループが回っているような感じがします。 加我さん： カンファレンスなどで登壇することも業務に活きている実感があります。登壇資料に記載する内容については、ざっくりとした理解ではなくしっかり定義を調べることが必要なので、資料を作る中で、意味を調べて、理解して、整理して、まとめる、ということがスキルアップにも繋がりますし、業務にも役立っています。 今後やっていきたいこと —— 最後に、お二人が今後やっていきたいことを教えてください。 加我さん： 会社として社外への発信や協賛を応援している状況なので、私自身が登壇することは続けていきたいですし、他の人やアウトプットが苦手な人にも発信してもらうにはどうすれば良いかなども考えていきたいと思っています。ですので、社外発信やコミュニティ支援について興味のある人が入社してくれたら嬉しいなぁと思っています。 山口さん： 改善してきたこと、逆にできなかったこと、苦労したことなど、一般解というよりも実業務でやってきたことを発信していきたいです。それが事業会社にいる強みだとも思っています。また、社外に発信したいといった人が増えた時に JAWS-UG のコミュニティの場を提供できるなど、何かあれば場を用意できるという状態を保っていきたいと思っています。 まとめ 今回はコミュニティ活動の話を中心に対談形式でお届けしました。対談内で出てきましたが、エス・エム・エスはコミュニティ活動、勉強会・カンファレンスへの参加や協賛を積極的に支援しています。その根底にある考え方について『 なぜ学習することへ投資するのか 』にも詳しく書かれていますので、こちらも是非ご覧いただければと思います！

10月29日（火）～31日（木）に北海道札幌市で開催される「第83回 日本公衆衛生学会総会」にて、筑波大学と弊社Analytics & Innovation推進部が共同で行っている研究の成果が発表されます。 学会の概要 日本公衆衛生学会は1947年（昭和22年）に設立された、公衆衛生分野での主要学会の1つです。会員数は9,000人を超え、社会医学分野でも最大規模となっています。 会員は行政､ 大学等の研究・教育機関、保健・医療・介護・福祉や職域の現場実践者、企業など多岐にわたり、毎年開催される学術大会（総会）には4,000人ほどが集まります。 大会名：第83回 日本公衆衛生学会総会 会期：2024年10月29日(火)～31日(木) 会場：札幌コンベンションセンター、札幌市産業振興センター 大会の公式サイト： https://plaza.umin.ac.jp/jsph83/index.html 発表の概要 筑波大学との共同研究では、弊社が提供する介護/障害福祉事業者向け経営支援サービス「カイポケ」の匿名化データをもとに、医療と介護を取り巻く現状と課題を複数のテーマで分析しています。 今回の総会では、以下3つの演題が発表されます。 【発表1】 演題名 訪問看護事業所の保険収入における利用者の性・年齢・要介護度の割合による差 発表者名 伊藤智子1) 2)、長谷川正彦3)、富田眞紀子3)、小林秀3)、田宮菜奈子1) 2) 発表形式 ポスター発表 日時 10月30日（水）13:40～17:00 会場 札幌市産業振興センター 体育実習室（位置番号 089） 1)筑波大学医学医療系 2)筑波大学ヘルスサ–ビス開発研究センター 3)株式会社エス・エム・エスAnalytics & Innovation推進部 【発表2】 演題名 要介護高齢者に対する訪問リハビリテーションの実施時間と日常生活活動の関連 発表者名 樽見隼人1)、宇田和晃2) 3)、小宮山潤2) 3)、長谷川正彦4)、富田眞紀子4)、
小林秀4)、田宮菜奈子2) 3) 発表形式 一般演題口演 日時 10月30日（水） 14:50～15:50 会場 札幌市産業振興センター セミナールームB（第23分科会1） 1)筑波大学大学院 2)筑波大学医学医療系ヘルスサービスリサーチ分野 3)筑波大学ヘルスサービス開発研究センター 4)株式会社エス・エム・エスAnalytics & Innovation推進部 【発表3】 演題名 精神科訪問看護を利用する高齢者の3年間の要介護度推移に関連する要因の分析 発表者名 青柳沙佳1)、伊藤智子2)、長谷川正彦4)、富田眞紀子4)、小林秀4)、 
山海知子2)、田宮菜奈子2) 3) 発表形式 ポスター発表 日時 10月30日（水） 13:40～17:00 会場 札幌市産業振興センター 体育実習室（位置番号 196） 1)筑波大学大学院看護科学学位プログラム 2)筑波大学医学医療系 3)筑波大学ヘルスサービス開発研究センター 4)株式会社エス・エム・エスAnalytics & Innovation推進部

はじめに こんにちは、エス・エム・エスの小笠原です。以前 2つのカイポケSREチームを兼務している話 を紹介しましたが、現在はカイポケリニューアル側のSREを担当しています。 今回は介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発におけるSREの活動事例として、基盤の構成管理を抜本的に見直した話を紹介します。 リニューアルプロジェクトの概要 最初に私が関わっている カイポケリニューアルプロジェクト について簡単に紹介します。 このプロジェクトは継続的な事業成長を目的としてサービスの安定性やプロダクトの優位性を高めることを目的とした「新カイポケ」の開発プロジェクトで、2021年に始動しました。 アーキテクチャから見直し、「拡張性」・「スケーラビリティ」・「開発並列性」をキーワードにした「新アーキテクチャ」を設計し、開発を進めています。 私もこのプロジェクトに2022年の年末ごろからSREとして開発に携わってきました。 プロジェクト開始時の基盤開発の方針 最初にプロジェクト開始時の基盤開発の方針について説明します。プロジェクト開始当初、開発メンバーの中でインフラを専門として動くメンバーは1人だけでありかつ、他部署の業務を一部兼任している都合もあり、SREとして一般的に期待される仕事をすべて担うにはリソース不足でした。 一方、アプリケーション開発を主に行うチーム（以降、アプリ開発チーム）には元インフラチームのメンバーや基盤開発に知見のあるエンジニアが複数人いたこともあり、基盤の開発・管理をアプリ開発チームとSREの間で以下のように担当分けする方針が敷かれました。 プロジェクト開始時点の管理範囲 土台となるAWSアカウントを始め、全体のネットワーク設計（VPCやsubnetなど）や横断で利用されるリソースをSREが管理し、それ以外のリソースはすべてアプリ開発チームで面倒を見るという役割分担です。 この役割分担を前提として、技術スタックについて開発チームの管理範囲は AWS CDK （以降、CDK）を、SREチームの管理範囲はTerraformを採用することになりました。 技術選定の背景 アプリ開発チームでCDKを採用したのには大きく３つ理由があります。１つ目はアプリ開発チームで基盤開発を主導していたメンバーがCDKに習熟していたこと。２つ目は使い慣れているプログラミング言語であるTypeScriptで開発できること。３つ目はSecurityGroupの設定など基盤の詳細について抽象化されていて基盤に詳しくないエンジニアにとって扱いやすいことです。これらは開発速度を上げるうえで大きな優位性になると考えていました。 一方、SREチームでTerraformを採用した理由は運用時の細かな取り回しの良さと規模の拡張に対応しやすいと判断したためです。特にSREが担当するレイヤ（AWSアカウントやネットワーク基盤など）の運用ではこの性質と相性が良いと考えました。 AWS CDKとTerraformの連携と拡張方針について CDKとTerraformは以下のようにParameter Storeを介してそれぞれの世界を接続させる形で連携することにしました。 CDKとTerraformの連携 リソース間に依存関係があるため、以下の順番で構築を進めることになりました。 SREがTerraformでネットワークリソースを作成する CDKで参照したい定数をTerraformを使ってParameter Storeに作成する 開発チームで定数を参照してサービスごとのAWSリソースをCDKで作成する 両者の責任分界点は明確なため、あとは各チームがそれぞれの担当するCDKのstackやTerraformのroot moduleを適切な粒度に分割・管理していけば将来的なシステムのスケールに対応できると考えていました。 開発初期は見立て通りうまく開発できた 開発初期からしばらくの間は基盤開発の状況は良かったことを覚えています。特にアプリ開発チームにおけるCDKを利用した基盤開発は以下の点でよく機能していました。 開発者が抵抗なく基盤開発に貢献できる TypeScriptで書かれた豊富な実装例 コードの書き味の良さ 試行錯誤のしやすさ cdk deploy → cdk destroy で片付けが簡単 個別のAWSリソースの詳細について深く考えなくて済む 詳細が抽象化された構成セット（ construct ）が公式から多数提供されており、それを少し修正するだけで基盤構築ができる アプリ開発者だけで開発を進められる レビューをすべてアプリ開発チーム内で済ませられる 当時は基盤の構成や設定をレビューできるメンバーが限られており、レビュー待ちが発生することが多かったのですが、アプリ開発チーム内でレビューを完結させることでスムーズに開発を進められることが大きなメリットと認識されていました この点についてはアプリ開発チームでは当初期待していたCDKのメリットを享受できていたと言えそうです。SREとしてもアプリ開発チームが自立して基盤の構築・管理のタスクを進めてくれるため負担が少なく助かっていました。 開発中盤からCDK開発に暗雲が立ち込めた 一方で、開発が中盤に差し掛かる段階でCDK開発に暗雲が立ち込めます。具体的には本番環境を作り始める頃に様々な課題が見えてきました。特に大きかったものは以下です。 デプロイが一大イベントになった 一回のcdk deployにすべての変更を押し込めた結果、アプリのデプロイと構成変更が同時に実行されるデプロイフローになってしまいました アプリの変更と構成変更が同時に行われることでデプロイ時の事故が起きやすくなったりstack更新のオーバーヘッドでデプロイ時間が全体的に長くなりました CDKで状態を持つリソースの管理がうまくできなかった 状態を持つリソースに関してstackの更新処理が途中でコケた際にエラー原因が特定できず、困ったらcdk destroyして作り直すという対処をしていました これは本番系では許容できない解決方法ですが、CloudFormationのトラブルシューティングが難しく、一つ一つ適切に対処することができませんでした CDKで作られるAWSリソースの品質が本番に持って行くには不安があった 例えばSecurityGroupの作り方に不備があり、意図した通りのアクセス制限が行えてないといった不備が見つかることがありました PRのレビューでは正常系の確認が主で、作成される実リソースの詳細に関するレビューはおざなりになっていました 多くの課題はCDK開発の知見を深める施策（技術的な投資）を増やせば解決できる可能性はあったものの、プロジェクトのボトルネックがアプリケーションの機能開発にあったこともあり、なかなかそちらにリソースを振ることも難しい状況が続いていました。 また、この問題に拍車を掛ける形で、アプリ開発チームでの基盤開発を主導していたメンバーの離脱があり、CDKの技術課題解決の推進力が大きく損なわれる事態になりました。 長期のプロジェクトなのでメンバーの入れ替わりがあることは仕方のないことなのですが、抜けた穴を補填できない状況ができたことは特に大きな問題でした。 基盤の開発・管理の立て直しを行うことになった 多くの課題が認識されるなかで基盤の開発・管理に関して抜本的な改善を図ることにしました。 愚直なアプローチとしては基盤開発の責務を現状維持しつつ、SREチームがCDK開発の課題解決に助力するという方法が考えられました。当時のSREチームは私が参加して二人になっていたこともあり、その選択肢もあり得たと思います。 しかし、SREチームには（開発の中で知見はある程度溜まっていたものの）本番系でのCDKの運用知見が少なく、またCDKのバックエンドであるCloudFormationをうまく扱っていくには相応の学習コストが必要なことが見えていました。 そして、今後基盤開発の課題の多くをSREチームが担っていくことを考えると、CDKとTerraformの２つの技術スタックを無理に維持していくよりは、SREが運用知見を多く持ち合わせていて既に基盤も整っているTerraformに統一していく方が効率的で、かつ将来のスケールにも対応しやすくなると考えました。 そこで、基本的に基盤の運用管理の責務をSREチームに全面的に移譲して、かつ技術スタックも統一していく方針で立て直すことが決まりました。 基盤の開発・管理の責務を全面的にSREに移した 役割としては以下のように基盤管理のほとんどをSREが担う形に変更しました。構成管理ツールはTerraformを主体に据えました。 プロジェクト中期の管理範囲 ただし、アプリケーションのデプロイについては構成変更と分離するために ecspresso を利用し、一部のAWSリソースはアプリ開発チームが手を入れやすいようTerraformのroot moduleを分ける工夫を行いました。 当時、サービスリリース前ではあったものの、多くのAWSリソースがCDKで構築・管理されていたため、CDK stackを段階に分けて少しずつTerraform化する対応を行いました。 結果 ツールの移行は開発に支障が出ないように段階的に行ったこともあり、全体で数ヶ月かかってしまいました。 移行期間中は基盤リソースが一時的に多重化されてコストがかかったり、デプロイ時間が遅くなったり過渡期の問題はある程度発生しましたが、移行を終えることによりそれまで抱えてきたCDKの技術課題を一気に解消することができたのはプロジェクトにとって中長期的な目線で大きなメリットを与えることができたと考えています。 移行後、顕著に改善できた点は以下です。 デプロイを高速化できた デプロイ時間を当初の約半分程度に削減できました デプロイ時の事故が減った 構成変更とアプリのデプロイを分離することで事故が少なくなりました 基盤構成のガバナンスを高めることができた Terraform管理時のプラクティスをそのまま横展開することでガバナンスを強化できました 大きな変更を入れる際にSRE（有識者）のレビューを入れることで品質の底上げがなされるようになりました 基盤に手を加えるオペレーションがしやすくなった CDK（開発チーム管理のリソース）への影響を考えながらオペレーションを組む必要がなくなり、Terraformで構成管理する際のオペレーションを考えるだけでよくなりました SREの動きやすさが大きく改善したことに加えて、デプロイの苦痛を減らすことができたことはプロダクト開発にとって地味ですが効果の大きな施策だったのではないかと考えています。 まとめと振り返り 大規模プロジェクトにおいてアプリ開発チームに基盤開発を任せる開発スタイルを試してみましたが、開発中盤でアプリ開発チーム単体での対応が難しい技術課題が増えたためSREに管理を任せる形に切り替えました。 この事例から得られる学びとしては、開発人員が多く期間の長いプロジェクトでは技術選定が当時の見立て通りにうまく進むとは限らないということです。 「最初からTerraformですべて管理していればよかったのではないか」という意見もあり、個人的にそれも一理あるなとは思います。しかし一方で、開発側にCDKの技術課題に取り組める人員を増やしたり、アプリ開発チームの中でCDK開発に関する知見を増やす取り組みに投資できていれば状況が大きく変わっていた可能性もありましたし、プロジェクト開始当初は基盤構成についてどのような形が良いかを開発チーム主体で機動的に模索したいという要望もあったりするなかで、Terraformからはじめる意思決定を最初から選択することは合理的ではなく難しかったと思います。 開発が進み、徐々に体制の変化や開発のボトルネックなどがわかってくる中で初めてこれまでの技術選定について振り返りや比較検討ができ、今後どうしていくのが良いかという確度の高い議論や意思決定ができたと考えています。 今回の事例を通して、先が読みにくい不確実性の高いプロジェクトでは完璧な技術選定よりは技術の評価や振り返りをしっかり行って、開発状況に応じて柔軟に技術の切り替えをすることが大切ではないかと感じました。 補足: CDKに関する技術的な所見 CDKに関して今回の事例を通して気付いた技術的な所見としては、小規模でシンプルな構成の基盤開発にCDKはよく向いているということです。 立ち上げまでの初速が非常に早く、スクラップ＆ビルドしたいときにはうってつけだと感じました。TypeScriptの型情報にAWSのベストプラクティスが書かれていたり、強力な型補完の恩恵があるため非常に楽しく基盤開発に取り組めることができました。これはTerraformにはない開発体験でした。 一方で、規模が大きく複雑な要件の求められる基盤開発で使っていくには相応の技術的投資が求められるため、構成変更を頻繁にいれたくなるようなメインのサービス・システムの管理には入れたくないと感じました。 特にCDKで細かくスタック分割したくなるときに運用・メンテコストが跳ね上がるように見受けられました。スタック分割をうまく行うにはL1 constructをはじめとしてCDKやCloudFormationの独特の設計や扱い方に習熟する必要があるのですが、これが非常に厄介なためです。 もちろん、ツールに深く習熟してさえいればどちらを使っても構わないのでしょうが、そうではない開発メンバーが多いプロジェクトの場合はツールの特性を理解して導入していくことが大切だと思いました。

介護・障害福祉事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの神谷です。中途入社してから5年たった今、これまでの活動を振り返ってみようと思います。 入社以来、顧客への価値提供を素早くできるようにするため、開発環境のモダン化や技術的負債の解消にトライし続けてきました。 最初は小さなサブシステムのリプレースにチャレンジし、リプレースの大まかな流れやカイポケで抱えていた技術的負債の解消パターンなどを獲得していきました。 tech.bm-sms.co.jp 直近ではカイポケ障害児支援領域の大規模リプレースに関わってきました。今回この大規模リプレースでチャレンジしたことについて、技術的な面にフォーカスして振り返ってみます。 カイポケ障害児支援領域の大規模リプレースに関してはこちらもご覧ください。 tech.bm-sms.co.jp tech.bm-sms.co.jp カイポケ障害児支援領域リプレースで意識したこと 今回の大規模リプレースを通して、業務知識のキャッチアップが最初の課題となりました。幸い、私がチームにJoinしたタイミングで、チームではドメインモデリングが進んでおり、ソースコードにまで落とされたドメインモデルを通して、業務知識の全体像を把握していくことができました。 また、実際に障害児通所支援事業所を訪問させていただき、カイポケを利用されている現場での課題を伺ったり、法改正に向けて現場の声を聞いたりすることで、理解度を高めていくこともトライしていました。 その他に、特に意識していたのは、以前のリプレースを通して得た知識をもとに テスト、運用フェーズを意識した設計をする レイヤーを跨いで、自動テスト可能な状態を維持し続ける ミドルウェアのアップデートを継続的に実施可能な体制を作る ことでした。次に具体的な例を挙げます。 テスト・運用フェーズを意識した設計 法制度が関係するカイポケのシステムテストを行う際には、法が施行される4月1日からは新しい法制度に対応しているが、3月31日以前は法改正前の振る舞いであること、といったシナリオのテストをすることがあります。 以前の法改正ではシステムや言語処理系の現在時刻を調整することで対応していましたが、これらは予期しない副作用を引き起こしたり、そもそもコンテナランタイムの上では使えない方法などもあり、避けるべきだという議論がチームでされていました。 そこで、リプレースにおいては現在時刻を扱う箇所は、現在時刻を外部からインジェクション可能な設計としています。 また、コンテナの環境変数から現在時刻を変更可能とし、テストチームから「法改正後の環境をテストしたい。法改正後の請求を行う5月の状態をテストしたい。」と要望があった場合でも、再デプロイのみですぐにテスト環境が用意できるようになっています。これは令和6年4月および6月の法改正対応で絶大な威力を発揮しました。 レイヤーを跨いで、自動テスト可能な状態を維持し続ける ソフトウェアのレイヤーを跨いでの結合テストを充実させるため、自動テストでは動かしにくいコードをリファクタリングしていきました。 実際のデータベースやクラウドストレージにアクセスするレイヤーもコンテナを活用することで「テストダブルで理想的にセットアップされている環境では動くが、リアルな環境では動かない」といった手戻りが極力起こらないようにしています。 具体的には TestContainers を活用することでデータアクセスレイヤを含む自動テストを拡充していきました。 テスト前にコンテナをたて、テストケースごとにコンテナを破棄することで毎回クリーンな状況からテストを開始し、不安定なテストとなることを避けています。 もっとも全てのテストを実際のストレージに接続して実施していてはテスト実行に時間がかかりすぎてしまうため、代表的なケース以外はテストダブルを使用するなどバランスを考慮しています。 ミドルウェアのアップデートを継続的に実施できるようにしておく カイポケの共通機能は社内でメンテナンスされているSpring Bootをベースとした薄いフレームワークに寄せられています。 リプレースにおいてもこのフレームワークを利用しているのですが、フレームワークをメンテナンスできる人が少なくなってきてしまっていたため、ソースコードのリーディング会や社内LT会でフレームワークの紹介、ドキュメントの整備などを行い、メンテナンスがされている状態へのリカバリーを行いました。 また、一度実験的に実装をしたものの、後に不要となった機能を断捨離することで、認知的負荷を減らし、メンテナンスが継続的に行えることを優先しました。 さらに、フレームワークの自動テストカバレッジを維持し、ミドルウェアのアップデート時に自信を持ってアップデートできるようにしています。 フレームワークはSpring Boot 2時代に社内で初回リリースされたものですが、大きな破壊的変更が入ったSpring Boot 3への対応を終え、現在3.X系の最新バージョンまで対応できています。 取り組みの結果と今後の展望 最初に取り組んだリプレースと比べ、今回は規模やステークホルダーも多く難易度は相対的に高かったものの、学習したことを生かし、もう1段階大きなリプレースを乗り越えることができました。 一方、今後トライしていきたいこともまだたくさんあります。 今回のリプレースのファーストリリースでは、フロントエンドからバックエンドまでを通したE2Eの自動テストや、フロントエンドの複数コンポーネントを跨いだ自動テストなどはスコープ調整や技術的背景から見送りました。 今後これらの自動テストを充実させ、開発速度と品質の両立を目指して探求していきたいと思っています。

お疲れ様です、SREの西田 ( @k_bigwheel ) です。 最近、バッチ処理を実行するための新しい基盤を構築したので、この記事ではそれの紹介をしたいと思います。 少々前提の説明を丁寧にやりすぎてしまったので、作ったものをまず見たいという方は「 構築したバッチ実行基盤のアーキテクチャ図と概要 」の項目へジャンプしてください。 バッチ実行基盤とは バッチジョブ、バッチ処理のための仕組みは、多くのWebサービスで設けられていると思います。 とてもプリミティブなものであれば、Webアプリが動いているEC2インスタンス/コンテナにログインして rake task ... などを実行するパターンが典型でしょう。 もう少し複雑になってくるとAWS CodeBuildとEventBridgeを組み合わせてサーバレスに定期実行したり、更に複雑な例ではApache AirflowやArgo Workflowで依存関係や実行順序・再実行の制御などを行う場合があります。 これらのうちどれを使うべきかはそのサービスのバッチ処理に求められる要求によります。基本的に高機能なものほど環境の維持や学習にコストがかかります。 GitHub Actions GitHub ActionsはGitHub公式のCIサービスです。GitHubリポジトリとの親和性が高く、今日では多くのエンジニアが使っているCIサービスです。 私は直近5年間このGitHub Actionsを非常に重用しており、正式リリース後はCIサービスとして最初の選択肢として常に使ってきました。 *1 GitHub Actionsをバッチ実行基盤として使うときのイメージ GitHub Actionsをバッチ実行基盤に据える、という考え方はあんまり聞かない手法だと思いますが、私は直近2社のバッチ実行基盤はそのように構築してきました。 典型的な実行イメージは以下です: GitHub ActionsのSelf Hosted Runner機能を使用してVPC内に実行箇所を確保 バッチ処理をWebアプリケーションと同じバイナリで実装し、DockerイメージをECRへpush GitHub Actionsのジョブ内でECRからdockerイメージをpull docker container run に適切なパラメーターを与えてバッチ処理を起動 GitHub Actionsをバッチ実行基盤に採用したときのメリット 次の様なメリットがあります。 1. バッチ処理を書くために追加の学習がほぼいらない GitHub Actionsは前述の通りすでに多くのエンジニアが使い方を知っているため、追加の学習コストがいりません。 Apache Airflowなどのワークフローエンジンを使う場合はその概念だけでなく、Pythonでの書き方やDAGの概念など多くを学ぶ必要があります。 2. GitHub Actions用の各種ノウハウが活用できる GitHub Actionsはシンプルな使い方もできますが、 workflow_run や on などで依存関係を表現することにより、その実行順序の制御は柔軟にできます。 また、reusable workflowやcustom actions、公開されたOSSアクションの利用など、車輪の再発明を避けるための各種手法も使うことができます。 3. 実行結果の確認やエラー通知・モニタリングなどが楽 実行の成否やそのログもGitHub Actionsの画面を使うことができるため、エラーの原因調査やエラー時の通知・実行回数やログのトラッキングなどもすべてGitHub Actionsのプラクティスを適用できます。 Apache Airflowなどのバッチ実行基盤を使うと書くと、実行結果の把握も不慣れで経験が必要なため、そこをスキップできることもメリットです。 これらのメリット1,2,3は開発チームが自信を持って自分たちの力のみでバッチ処理を管理運用することを支援します。これは、 チームトポロジー やスクラムの言う、1チーム完結で仕事ができるという理想へ近づくことができます。 4. 運用コスト(TCO: Total Cost of Ownership)が低い GitHubとGitHub Actionsをすでに使用している組織では、GitHub Actionsをバッチ処理基盤に採用することで増えるインフラ・SaaSはありません。また、後ほど説明しますが最近発表された「Self-hosted GitHub Actions runners in AWS CodeBuild」という機能を使えばAWSサイドのリソースの構築運用やコンピューティングコストもかなり低く抑えられます。 インフラを構築運用するSREの目線からすると、扱うものの種類が増えると認知負荷が増え、結局TCOも増えるため、この点も大きいです。 GitHub Actionsをバッチ実行基盤に採用したときのデメリット 逆に明確なデメリットもいくつかあります。 1. GitHub Actionsのダウンに影響される GitHub Actionsは、結構不安定なサービスです。 直近3ヶ月 の障害記録を確認してみましたが、2回ほど障害が発生しています。ここに記録されない軽微なものを含めるともう少し発生している体感で、だいたい毎月なにか起こっています。 そのため、その時間に必ず一度だけ実行してほしいジョブや、再実行でリカバーできない(=冪等性のない)処理などには向いていません。ここは処理側でGitHub Actionsの性質を考慮して冪等性があるように書いたり、最悪遅延しても大丈夫な仕組みにしたりする必要があります。 2. 起動が少し遅い GitHub Actionsのワークフローの実行は、実際にステップ1が実行されるまで30秒 ~ 2分程度の遅延があります。これはDockerイメージのpullや実行環境の用意などに時間がかかっているようです(後述するSelf-hosted GitHub Actions runners in AWS CodeBuildを使うとCodeBuildが実行環境を準備する時間もかかるため、全体で2~4分程度最初のステップの実行までかかります)。 例えば踏み台サーバー経由でコマンドを実行する場合、長くても数秒で実行に移れるので、ここは明確なデメリットです。一方で、実際にバッチ処理が運用に入った場合、この立ち上がりの遅さが問題になることはほとんどないです。問題になるのは主に処理のデバッグ・開発中で、1度実行して結果を確認するのに時間がかかるため開発効率が落ちます。この点は、 Debugging with ssh · Actions · GitHub Marketplace などのアクションを活用することで軽減するなどの工夫が必要かもしれません。 3. VPCの壁がデフォルトでは超えられない GitHub Actionsのデフォルトの実行環境である GitHub Hosted Runner は、AWSの外にあるサービスです。 バッチジョブからプライベートサブネット内のDBやインターナルALBへアクセスさせたい場合、当然そのままではアクセスできません。 これを解決するには方法については続けて詳しく書きます。 VPCの壁を超えるための手法について AWSでバッチ処理を行う場合、多くの人が頭を悩ますのがDBへのアクセスです。 バッチ処理はその多くでDBへのアクセスを行うため、DBへのアクセス経路を確保する必要があります。一方でAWS環境のDBはプライベートサブネットに置くことが多く、GitHub Actionsのデフォルトの実行方法( GitHub Hosted Runner )を使う場合、実行箇所がAWS内ではないためDBへアクセスすることはできません。 この解決策は僕が知っている限り以下の種類があります。 1. DBをパブリックサブネットに配置し、DBのpublicly accessibleオプションを有効にする DBをパブリックサブネットに配置し、DBのpublicly accessibleオプションを有効にするとDBの各インスタンスへグローバルIPが割り当てられます。そうすればインターネットのどこからでもアクセス可能になるため、GitHub Hosted Runnerからもアクセスできる寸法です。 RDSのサブネット間の移動は手間はかかるものの可能であるため( rds プライベートサブネット パブリックサブネット 移動 - Google 検索 )、後からこうすることもできます。 この方法の欠点はセキュリティ観点で比較的弱いことです。GitHub Hosted Runnerは使用するIPを固定したり専有したりすることはできないため(※ はてなブックマークのコメントで、Larger Runnerを利用すればIP帯を限定できると教えていただきました。Enterprise Cloud契約が必要でコストも変わりますが、有力な選択肢になりえます)、セキュリティグループで接続元を制限することもできません。ですのでDBのセキュリティはネットワークトポロジーで担保することはできずDB自体の認証機構のみに頼ることになります。それもあってAWSの設計としては一般にはバッドプラクティスとして考えられているようです。 蛇足ですが、私はこの手法は場合によっては有用と考えており一概に切り捨てるべきではないと思っていたりします( bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言 - kbigwheelのプログラミング・ソフトウェア技術系ブログ )。 2. 踏み台サーバーの利用 パブリックサブネットに踏み台サーバーを置き、DBへのアクセスを中継させる手法です。 比較的取りやすい構成ではありますが、 先述のブログ にも書いている通り、実はこれはDBのpublicly accessibleを使うこととセキュリティ水準的にはそれほど変わりません。また、踏み台サーバー内にファイルが置かれてインフラが状態を持ってしまい、踏み台サーバーの置き換え・アップグレードができないなどの問題がよく発生します。なので、この方法はおすすめしません。これでよい要件であれば、先程のpublicly accessibleのほうがセキュリティ水準は同じで運用コストはより低くて済みます。 3. Self Hosted Runnerの利用 GitHubにはデフォルトの実行環境(GitHub Hosted Runner)の他に、自分たちで実行環境を用意する Self Hosted Runner という仕組みがあります。AWSのVPCの壁を突破する方法としてはこれを使うことが一般的です。 ただし、このSelf Hosted Runner、結構TCO(Total Cost of Ownership)が高いです。 素朴なEC2インスタンスとして立てた場合、中のOSレイヤー以上のメンテナンスを自分たちで行う必要があり、また実行中以外もインスタンスが起動しっぱなしであるためコンピューティングコストが高くつきます。 Fargate でサーバレスに実行時のみ起動するアイデアは数年前からありますが、先行例はたくさんあるもののOSSの形で公開された定評のあるソリューションはありません。 Kubernetes上で動かすソリューションはOSSかつ公式に認められたものとしてありますが( Actions Runner Controller )、Kubernetes自体の運用コストが低くない上、EKS上のFargateはECSのFargateよりかなり立ち上がり時間が遅い(2022年時点で4~7分程度かかった)などの欠点もあります。 そんな中で、2024年4月に満を持して出たのがSelf-hosted GitHub Actions runners in AWS CodeBuildでした。 Self-hosted GitHub Actions runners in AWS CodeBuildについて 2024年4月のリリースが以下です: AWS CodeBuild がマネージド型の GitHub Action ランナーのサポートを開始 平たく説明すると、Self Hosted Runnerの実行箇所としてCodeBuildを選べるようになったというものです。 これによりSelf Hosted RunnerとしてEC2インスタンスを使った場合のようにOSレイヤーを管理する手間や利用時以外のコンピューティングコストを払う必要もなく、ECS Fargateのパターンのように自分たちで構築・運用する必要もなく、Kubernetesを使う場合のようにKubernetes自体とControllerの高い管理コストを払う必要もなくなりました。 前職ではEKSを使ってインフラを構築していたことと、まだSelf-hosted GitHub Actions runners in AWS CodeBuildが登場していなかったこともあって前述のActions Runner Controllerを使っていたのですが、現職ではECSベースかつCodeBuildを使用していることも後押しして、こちらを採用することにしました。 構築したバッチ実行基盤のアーキテクチャ図と概要 アーキテクチャはざっくりですが以下です。 キーポイントとしては Self-hosted GitHub Actions runners in AWS CodeBuildを使うことでシームレスに実行箇所をVPC内へ移す AWS - GitHub OIDC を使うことでIAM権限の取得をノンパスで行う IAMデータベース認証を使うことでDBへの接続も同じくノンパスで行う などです。これらにより、バッチ処理を書く方としてはCodeBuildの存在を一切意識する必要なく、またIAMユーザーやDBのパスワードについても別途GitHub Secretsなどへ保存する必要がなくなります。 GitHub Actionsのワークフローファイルの例 name : workflow-a on : workflow_dispatch : {} jobs : job1 : environment : dev # configure-aws-credentials アクションのためにid-tokenとcontentsの権限は必須 permissions : id-token : write contents : read runs-on : codebuild-batch_jobs_dev-${{ github.run_id }}-${{ github.run_attempt }} steps : # GitHub AWS間のOIDCを使ってノンパスでIAM権限を取得する - name : configure aws credentials uses : aws-actions/configure-aws-credentials@v3 with : role-to-assume : arn:aws:iam::1234567890:role/batch-jobs - run : aws sts get-caller-identity # IAM権限を正常に取得できていることの確認 # 次の2ステップは、取得したIAM権限でECRからdockerイメージを取得できることの確認 - uses : aws-actions/amazon-ecr-login@v2 id : login-ecr - run : | docker pull ${{ steps.login-ecr.outputs.registry }}/github/bm-sms/project-a/project-a:sha-aaaaa1215bb084e9ad3d6abf30b91348043bbbbb # 最後にIAMデーベース認証の動作確認 # GitHub SecretsやParameter Storeにパスワードを保存することなく、IAM権限からFederatedな一時DBパスワードを取得し、それを持って接続する # 通常、Publicly AccessibleではないDBにはGitHub Actionsからはアクセスできないが、 # self-hosted GitHub Actions runners in AWS CodeBuild を使用しているため接続が可能になっている - run : sudo apt update && sudo apt install postgresql -y - run : | # https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.html export RDSHOST="db-cluster.cluster-aaaaylxtbbbb.ap-northeast-1.rds.amazonaws.com" export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region ap-northeast-1 --username batch_job)" psql "host=$RDSHOST port=5432 dbname=hogehoge user=batch_job password=$PGPASSWORD" -c "SELECT CURRENT_SCHEMA, CURRENT_SCHEMA()" セキュリティ・証跡関連で気をつけたこと 補足的ですが、セキュリティ関連で気をつけたことについていくつか書いておきます。 本番環境でのバッチ実行への制限 上記の仕組みを素朴に作ると、本番環境でのジョブ実行が危険なほど容易にできます。 具体的にはGitHub - AWS OIDC連携をしているリポジトリへWrite権限を持っているユーザーは任意の処理を書けます。個人情報へのアクセスもできてしまうでしょう。一方でジョブ実行に必ず人力のApproveを求めるのは現実的ではありません。それは、バッチ処理の中には一日1回など定期的に実行するものがあるからです。 そこで、その辺りを解決するために次のように設定しました(詳細は後ほど説明します): Environment リポジトリの設定から次の Environment を作成する prod-with-review prod-without-review dev-with-review dev-without-review prod-with-review prod-without-review についれそれぞれ画像のように設定する 　 GitHub - AWS OIDC AWS側のOIDC設定を次のように行い、AWSの本番環境アカウントは prod-with-review prod-without-review環境 、 開発環境アカウントは dev-with-review dev-without-review の環境の権限があるときのみ使えるようにする resource "aws_iam_role" "batch_job" { name = "batch_job" assume_role_policy = data.aws_iam_policy_document.batch_job.json } data "aws_iam_policy_document" "batch_job" { statement { actions = [ "sts:AssumeRoleWithWebIdentity" ] effect = "Allow" condition { test = "StringLike" values = [ "repo:bm-sms/repo-a:environment:$ { var.environment } -with-review" , "repo:bm-sms/repo-a:environment:$ { var.environment } -without-review" , ] variable = "token.actions.githubusercontent.com:sub" } principals { identifiers = [ data.aws_iam_openid_connect_provider.this.arn ] type = "Federated" } } } data "aws_iam_openid_connect_provider" "this" { url = "https://token.actions.githubusercontent.com" } 3.(ブランチプロテクション)ルールセット 画像のように設定することでレビューなしで main ブランチを変更できないようにする 全体の意図を説明します。 まず、本番環境での実行は原則承認のステップを挟みたいため、AWSの本番環境アカウントへの接続には prod-with-review Environmentを要求し、Deployment *2 にはレビューを要求しています。 一方で、定期実行など仕組み上レビューを挟めない実行方式もあります。その場合は prod-without-review Environmentを使用しますが、その際でも実行ブランチは main に限定されており、同時にブランチプロテクションルールセットで main ブランチの変更には常にレビューと承認を必要とするため、レビューなしに本番環境で任意の処理を行うことはできません。 (補足: dev環境などは毎回の承認は冗長なため with / without の両方のEnvironmentを用意する必要は原則ないですが、環境差異を小さくしたいためあえて本番環境と同様に作り dev-with-review でのReviewのチェックだけ外しています) 証跡としての実行ログについて Self-hosted GitHub Actions runners in AWS CodeBuildを使った場合、バッチ実行のログはCodeBuild側にはまったく残らず、GitHub Actions側に残ります。そして、GitHub Actionsの実行ログはリポジトリへのwrite権限という比較的弱い権限で削除できます。そのため、悪意のあるユーザーがあるジョブを実行してすぐにログを消すことができます。 これの対策として、エス・エム・エスでは Datadog CI VisibilityのLog Collection を使うことにしました。これであればログを削除することはできません。 ジョブ自体の実行の証跡について ジョブ自体の実行の証跡については、 GitHub OrganizationのAudit log 機能を使用しています。 IAMデータベース認証のなりすまし可能問題について IAMデータベース認証を素朴に使うと実行ログの証跡としての価値が非常に下がってしまう問題については次のように対処しました。 AWS Identity Center下のIAMデータベース認証でも、トレーサビリティのある監査ログを記録する方法 クエリログへのアクセスを制限したい クエリに個人情報が含まれている可能性があり、クエリログへアクセスできる人を制限したい件については次のように対処しました。 AWS Identity Center下で個人情報を含んだCloudWatch Logsへのアクセスをスマートに制限したい 終わりに 本記事ではここ数ヶ月作っていた、CodeBuildとGitHub Actionsを使ったバッチ実行基盤について紹介しました。 この方式はまだ主流ではなく、GitHub Actions自体の稼働率に引っ張られるなど明確な欠点もありながら、GitHub Actions自体の普及率が爆発的に増えたことにより、大きなメリットが出てきた手法かなと思います。 個人的には、TCOがかなり低いにもかかわらずバッチ処理を書く側・実行する側のDeveloper Experienceがかなり良いこと、この記事に書いたような概要の説明とアーキテクチャ図があればSRE(構築側)への問い合わせをあまりしなくてもバッチを書ける (= スクラムチームやストリームアラインドチームの独立実行能力を担保しやすい)ことの2点で非常に気に入っています。 *1 : Github Actions 2年使ってみてわかったことまとめ #GitHubActions - Qiita *2 : Environmentを使ったGitHub Actions実行

はじめに こんにちは、カイポケのリニューアルプロジェクトを担当しているプロダクトマネージャーの田村恵( @megumu_tamura )です。 カイポケが価値提供している介護業界は、日本をはじめとする多くの先進国で急速に進む高齢化社会に対応するために欠かせない分野です。しかし、介護業界に携わっていない方にとっては、まだまだ身近な存在ではないかもしれません。今回は、介護を少しでも身近に感じていただけるよう、介護業界の概要や課題についてお話ししたいと思います。 そもそも介護とは？ 少し想像してみてください。もし自分が年を重ね、日常生活の一部が難しくなったとき、誰に助けを求めますか？そして、どのような支援があると安心できるでしょうか？介護は、そんなときに必要な支援を提供するためのサービスです。 介護サービスは、ただ身体的なケアをするだけでなく、利用者の尊厳を守り、生活の質を向上させることを目指しています。たとえば、病気や怪我をしたときに医療が必要になるように、介護は日常生活を支えるための重要な存在です。利用者が自立した生活を送れるよう支援し、家族の負担も軽減します。 介護が必要になった時に、すぐに介護サービスが受けられるわけではありません。介護サービスを利用するためには、市区町村への申請が必要で、要介護認定を受けた後に、ケアマネジャーが個別のケアプランを作成します。このケアプランに基づいて、適切なサービスが提供されるのです。 ( 介護予防・日常生活支援総合事業のサービス利用の流れ | 介護保険の解説 | 介護事業所・生活関連情報検索「介護サービス情報公表システム」 より) こうしたプロセスを経て提供される介護サービスは、利用者とその家族にとって安心の源です。私たちが日々当たり前に過ごしていることを、誰かが支えてくれていると考えると、その重要性がより実感できるのではないでしょうか。 介護業界の現状と課題 高齢者の増加に伴い、介護業界ではスタッフ不足や業務の過重労働が深刻な問題となっています。そのため、効率的な介護サービスの提供とスタッフの負担軽減が急務となっています。 1. 慢性的なスタッフ不足 介護業界では、スタッフの確保が困難な状況が続いています。高齢者の増加に伴い、介護サービスの需要が増加していますが、介護サービスを提供するために必要なスタッフ(主に介護職員)を確保することができていません。有効求人倍率は施設系や通所系サービスで3.79倍、訪問系サービスでは15.53倍にも達しています。 ( 「厚生労働省老健局 社会保障審議会介護給付費分科会（220回）」資料１ より加工して作成) 厚生労働省の報告によれば、2026年度には約240万人、2040年度には約272万人の介護職員が必要とされています。このような人材不足の問題は、介護サービスの提供体制に大きな負荷をかけており、現場のスタッフは限られたリソースの中で多くの業務をこなさなければなりません。 ( 「第9期介護保険事業計画に基づく介護人材の必要数について（令和6年7月12日）」 別紙１より) 2. 業務の非効率性と情報共有の課題 介護事業所では、依然として紙ベースの記録や手作業が多く残っており、業務の効率が悪い状況が続いています。特に、事業所間の情報連携にはFAXが使われることが多く、情報の一元管理や迅速なデータアクセスが難しい状況です。こうした状況は、業務の遅延やミスの発生を招き、スタッフが本来のケアに集中できる時間が減少しています。 厚生労働省の「令和5年介護事業経営実態調査結果」では、業務効率化のためのIT導入が強く求められています。ITの導入が進むことで、紙ベースの記録やFAXによる連携がデジタル化され、業務の効率化が進むと期待されています。 介護業界の魅力 ここまで現状と課題についてお伝えしてきましたが、介護業界は、非常に意義深い業界です。多くの介護事業者が、高齢者への深い愛情と献身を持ってこの仕事に取り組んでいます。彼らはただサービスを提供するだけでなく、利用者一人ひとりに寄り添い、心からのケアを行っています。このような姿勢が、介護業界の大きな魅力の一つです。 介護業界で働く人々は、日々の業務を通じて利用者の笑顔や感謝の言葉を直接感じることができ、それが彼らの大きな励みとなっています。介護の仕事は、決して楽なものではありませんが、その分やりがいや達成感も大きいのです。 また、介護事業者の多くは、理想の介護を実現するために事業を立ち上げています。彼らは、自分たちの手で高齢者の生活をより良いものにしたいという強い意志を持っています。このような事業者たちと共に、介護業界の課題を解決し、より良い社会を作り上げていくことは、非常に価値のある取り組みです。 さらに、介護業界はICTを活用して業務を効率化し、現場の負担を軽減する余地が大きい業界でもあります。介護現場のニーズに応えるためのプロダクトやサービスを提供することで、業界全体の発展に貢献することができます。私たちが提供する価値は、介護事業者がその理想を実現するための重要なサポートとなるのです。 介護業界は、高齢化社会が進む中でますますその重要性を増しています。この業界で働く人々にとって、介護は単なる仕事ではなく、人生の大切な一部です。私たちが提供するプロダクトやサービスで、介護事業者の皆様の熱意や努力を支え、さらに大きな成果を生む手助けをしていきたいと強く思っています。 介護業界経験のないエンジニアやデザイナーのみなさんへ 「介護業界のことやカイポケのことは少しわかったけど、なんだか難しそう」と不安に感じたエンジニアやデザイナーのみなさん、安心してください！エス・エム・エスでは、介護業界の経験がない方々にも入社後に知識を習得してエンジニアやデザイナーとして活躍してもらえるように様々な仕組みや取り組みを用意しています！実際、エンジニアやデザイナーのほとんどの方は介護業界は未経験、知識もない状態で入社しています。 介護業界の知識も学べる入社時研修とワークショップ 　エス・エム・エスでは、新たに入社するエンジニアやデザイナーに対して、1日半にわたる介護ドメインの内容を含んだ研修を実施しています。この研修では、介護業界の基本的な知識から、実際の事業所での業務フロー、そしてカイポケがどのように活用されているかを学びます。講義形式だけでなく、ワークショップ形式も取り入れており、具体的なケーススタディを通じて実践的な知識を身につけることができます。これにより、新入社員は現場で直面する課題を理解し、どのように解決していくかを実践的に学ぶことができます。 入社後もいつでも業界経験者などから最新情報を教えてもらえる環境 また当社では、介護ドメインについて詳しくないエンジニアやデザイナーが安心して働けるよう、以下のサポート体制を整えています。 専門知識の共有: 社内のSlackチャンネルやバーチャルオフィスの ovice というツールなどを使って、業界経験者に気軽に質問できる環境を提供しています。これは、日々の業務の中で生じる疑問や不安を即座に解消するための重要な手段です。 定期的な介護業界勉強会の開催: 毎週水曜日の17:30から30分間、介護ドメイン経験者による勉強会を実施しています。テーマは多岐にわたり、実際の事業所での経験や介護業界のトレンドについて学ぶことができます。これにより、チーム全体が常に最新の知識を共有し、業務に活かすことができます。 これらの取り組みによって、エンジニアやデザイナーが、それぞれのスキルを活かして介護業界に貢献できるよう、安心して働ける環境を提供しています。私たちと一緒に、介護業界の未来を作り上げていきませんか？