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分間、介護ドメイン経験者による勉強会を実施しています。テーマは多岐にわたり、実際の事業所での経験や介護業界のトレンドについて学ぶことができます。これにより、チーム全体が常に最新の知識を共有し、業務に活かすことができます。 これらの取り組みによって、エンジニアやデザイナーが、それぞれのスキルを活かして介護業界に貢献できるよう、安心して働ける環境を提供しています。私たちと一緒に、介護業界の未来を作り上げていきませんか？

みなさんこんにちは！ エス・エム・エスでキャリア事業の基盤開発に携わっている川名と申します。 こちらの記事では2024/8/29（木）に開催された Salesforce Developers Meetup にて登壇させていただいた内容をシェアしたいと思います。 発表テーマはSalesforceのCIとなります。 Salesforce導入時に技術者などがおらず、検証やデプロイ環境がレガシーな状態で運用されている環境も多いかと思います。 以前参加させて頂いた Salesforce Architect Group Osaka のMeetupで取られた参加者アンケートにおいてCIを使っているユーザはたしか2割程度という事に驚いたのを覚えています。 テストやデプロイを自動化する事でリリース作業や開発負荷を減らす事が出来ると考えています。 そこでまずはシンプルなテストの自動化についてまとめてみましたので、 ご興味のある方は是非ご覧ください。 speakerdeck.com いかがでしたでしょうか。 これらはDeveloper Editionなどで試す事が出来るものなので是非チャレンジしてみてください。 この他にも必要なApexテストのみを実行する差分検証であったり、 クイックリリースを実現する方法なども別の機会にお話出来ればと考えています。 またお会いしましょう！

こんにちは、プロダクト推進本部人事のふかしろ (@fkc_hr) です。 8月2日、3日に開催されたSRE NEXT 2024に、エス・エム・エスのメンバーが参加してきました&弊社もGOLDスポンサーとして協賛いたしました。 sre-next.dev この記事では、メンバーの印象に残ったセッションの紹介・感想とブースの振り返りをお届けします！ みんなのイベント感想 山口（全社SRE） 全社SREの山口 (@yamaguchi_tk) です。 SRE NEXT 2024のコアスタッフをしていました＆Snykさんのスポンサーセッションで登壇（DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策）しました。（2日目のイベントの撤収時という疲労がピークの時に資料をアップしたのでURL設定をミスってしまい同じ資料が2つアップされています） speakerdeck.com SRE NEXT 2024が本格的に動き出したのが今年の1月くらいで、4月くらいからエンジンがかかって6月7月は追い込みくらいのスケジュール感でした。 SRE NEXT 2024では、主にイベント関連と制作物を担当していました。参加者から誤表記等の指摘はありましたが、イベントアンケートで概ね良い評価をいただいたこと、制作物が当日までにそろっていたこと、イベントが無事終了したので自分としては大満足でした。 自分が登壇したSnykさんのスポンサーセッション「DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策」では、ツカミからの伏線回収、まとめまで話し切ったためか、缶バッジ・スポンサーブースの宣伝をしすぎたのか分かりませんが、AskTheSpeakerではなくエス・エム・エスのブースにAskしにいく方が何人かいらっしゃったようで、「エス・エム・エスのブースの前でAskしないでください　そこにSpeakerはいません　反対側でスタンプラリーの抽選係をやっています」と歌いそうになりました。 SRE NEXT 2025でも引き続きコアスタッフをやる予定ですので、参加者に楽しんでいただけるイベントを作っていきたいと思います。 小笠原（カイポケSRE） エス・エム・エスの小笠原です。スポンサーセッションのLT枠で登壇して以下の発表を行いました。 speakerdeck.com 今回LT枠は5分と短く、その中でプロダクトに少しでも関心を持ってもらうために何を話すか悩みました。限られた時間で私たちの事業について知ってもらうために、具体的な話には踏み込まずにこれまでのプロジェクトの進め方とその中でどのように考えて意思決定を行っていたかについてご紹介させていただきました。 5分枠なので話しきれば終わりと思いきや、セッション後のAskTheSpeakerの時間で参加者や他の登壇者とLTの中身について深掘る機会を得られたことが個人的に楽しく印象的でした。SREのくくりでこれほど人が集まるイベントは少なく、またSREが各社少数チームで構成されることが多いこともあり、普段社内でしない会話もできたのではないかと感じました。 聴講したセッションで個人的に気づきがあったのはTopotalさんの「組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜」に関するセッションでした。 speakerdeck.com インシデント対応をフェーズに分けて細かく成熟度評価することで改善に取り組みやすくなる、という話があり、これは自社でも適用できそうだと感じました。 TopotalさんではSlackアプリケーションを利用してインシデント対応を定型化したりポストモーテムの作成を半自動化・支援するといったサービスを展開しており、確かにインシデントが多い現場ではこのようなサービスは有用だと思いました。 インシデント発生時、担当者はプレッシャーもありなかなか手順書ベースの対応はうまくできないことが多いです。実際には周りの人がそれを補うような動きをして運用でカバーすることが多いのですが、それを運用ではなく仕組みで解決するというアプローチがあるというのが気づきでした。とてもSRE的な発想で良いなと感じました。 上山（ハピすむSRE） ハピすむSREの上山です。 事前に気になっていた「Becoming SRE - SREって何から始めればいいの？」のセッションを聞いてきました。 技術スタックの話ではなく、SREという立場でプロダクトや開発チームとどう向き合っていくのか、という話がメインだったかと思います。 早すぎる改革はエンジニアに引かれるため信頼作りが重要という話や意思決定が早すぎるが故にembeddedしていたのが分離してしまった話では、私が感覚だけでやっていた部分や言語化できていなかったチームとの関わり方が議論されていて、非常に勉強になりました。 当セッションはパネルディスカッションなのでスライド資料は無いと思いますが、深い議論が行われていたセッションの雰囲気が伝われば幸いです。 ブース対応では、アンケート等を通して幅広い分野のエンジニアの方々と技術関連のお話をすることが出来てとても楽しかったです。 加我（カイポケSRE） カイポケSREチームの 加我 です。 SRE NEXT 2024では (恐らく) 人生初となるスポンサーブース周りを担当しました。会社やサービスの紹介、缶バッジ作成のご案内、各種アンケートのご案内などを通して多くの方とコミュニケーションができました。今回初めて用意したノベルティのサプリケース (お薬ケース) も好評だったようで嬉しく思います。 先日のブログ にてDMMさんの「大きな組織にSLOを導入し運用するということ、その難しさ」を気になるセッションとして挙げさせていただきました。 speakerdeck.com 過去に私がSLI/SLOを導入しようとした時に「SLOがユーザージャーニーを表現しきれていない」という問題に直面し、実現するためには大幅な計装が必要となってしまい頓挫してしまったという経験があるからです。これに対してDMMさんのセッションでは「マイクロサービスSLO」と「プラットフォームSLO」の2軸で考えるという話があり、強く印象に残っております。私達が開発しているカイポケも今後SLI/SLOの整備が必要なのでセッションで得られたものを活かしていきたいと思います。 また、2025年もSRE NEXTが開催されること、それに合わせてRoad to SRE NEXTが開催されることが発表されました。私は現在札幌に住んでおり、Road to SRE NEXTが札幌で開催されるとのことなので、もし機会がありましたらぜひ運営メンバーとして協力したいと思っております。 ということでSRE NEXTに携わったみなさまお疲れ様でした！ 高橋（全社SRE） 全社SREの 高橋 です。 今回初めてSRE NEXT 2024に参加させていただき、多くの学びと刺激をいただくことができました。 スポンサーブースで他社の方々と交流でき、コミュニティーの活発さを感じる2日間でした。 特に印象に残ったセッションはエムスリーさんの「Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織」です。 speakerdeck.com エムスリーさんにおける「Central SRE」と「Embedded SRE」のハイブリッド体制についてや、今後の体制の展望を聞くことができました。当社もオンプレミス時代およびクラウド移行時代を経るという似た変革を辿っており、共感できる部分が多くありました。また、ハイブリッド体制をとることのメリットデメリットや、Embedded SREとの役割分担についてもどのように捉えているかを伺うことができました。現在、当社も今後のSRE体制のあり方を模索している最中ですので、今後の参考にしたいと考えています。 来年のSRE NEXTの頃には自分もSRE2年生になっているはずなので、より成長した自分で広く深くインプットできるように邁進していきたいです。 最後に、企画運営をしていただいた皆様、素敵な機会をありがとうございました！ SRE NEXT 2024に参加した皆様お疲れ様でした！ おわりに エス・エム・エスのブースでは、「あなたのXアイコン缶バッジをプレゼント」という企画を行いました。2日間で約150名の方へお渡しができ、最後は見渡すと缶バッジをつけてくれている方が多くいらっしゃったのが印象的です。 Xでの拡散や、口コミでのお繋ぎありがとうございました。 Kotlin Fest 2024でも同様の企画をしたのですが、カンファレンスでよく起こる、アイコンと顔が一致しない。という問題の解消のためにご用意していました。 いつもよりかはキャッチーだったのですが、基本的には課題解決的な思想で始まったノベルティ・ブース企画で、社風が現れているなと感じました。 実はエス・エム・エスは缶バッジ屋さんではなく、「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」というミッションのもと、継続可能な日本の未来をつくるための事業づくりをしています。どんな会社かわからないので話を聞いてみたいよという方がいたら、カジュアル面談の申込みも受け付けていますので、ご応募ください！ 楽しいSRE NEXT をありがとうございました！

はじめに 介護事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。先日、「カイポケ」に関わる開発エンジニア3名、QAエンジニア3名で「 Scrum Inc. 認定 アジャイル・テスティング研修 」に参加してきたので、その時のことを簡単にお話しします！ 参加の経緯や目的 私自身はこのイベントの存在を知っていたわけではありませんでしたが、同僚やマネージャーからの紹介と推薦により、会社の支援を受けて参加することになりました。もともとAgile Testingに関する少しの知見と強い興味を持っていたのですが、実践的なスキルを身につけることはもちろん、「組織に適用する方法を学ぶこと」や「組織が抱える課題を解決するための方法を得ること」を目的として参加しました。 ※エス・エム・エスはこのように研修への参加など学習をすることへの支援を積極的にしてくれるため、成長する機会やきっかけが得られやすい会社だと感じています。技術責任者の@sunaotが執筆した記事 があるので、詳細はそちらをご参照ください。 tech.bm-sms.co.jp ※エス・エム・エスのQA組織では「 Agile Testing Condensed 」を参考にした行動指針を作成しており、Agile Testingに関する関心は組織全体で強いものを持っていることも付け加えておきます。行動指針については、私と一緒にQA組織の運営を担当している星が執筆した記事があるので、詳細はそちらをご参照ください。 tech.bm-sms.co.jp 研修内容 ここからは研修内容をダイジェストでご紹介します。研修ではワークが多く、実際に頭と手を動かしながらチームで対話する機会がたくさんありました。そのため、丸2日間という長い日程でも、眠くなることはありませんでした（笑） その前に、会場の写真を1枚だけ撮ることができたので、雰囲気を伝えるために載せておきます。オープンなスペースでお菓子や飲み物も用意されており、リラックスして参加することができました。 DAY1 チーム決め・自己紹介 受講者30名のうち、エス・エム・エムのメンバーは6名で、全体の約2割を占める一大勢力でした。本研修ではチームでディスカッションやワークショップを実施する機会が多く、最初にチーム分けを行ったのですが、スクラムの経験や生成系AIの経験が均等になるように配慮されました。エス・エム・エスのメンバーはスクラムの経験が似通っていたため、チームはうまく分散してくれました。チームが決まった後は、それぞれが自己紹介を行い、チーム名を決めて準備は完了です。 マインドセットの転換 アジャイルではマインドセットを揃えることが非常に重要ですが、急な転換は難しいため、対話を通じて徐々に揃えていく必要があるとのことでした。重要性は理解していますが、各自のスキルや意識、社内での立場が異なるメンバーで構成されたチームだとやはり難易度が高く、じっくりと時間をかけて取り組む必要があることを再認識しました。 複雑さとアジャイル 自分たちが行っている仕事の複雑さを把握しなければ、アジリティの必要性を理解することはできないとのことです。この点についてはあまり意識していませんでしたが、日々の仕事を振り返ると、確かに多くの変数に向き合っており、事前に把握できない変数に苦労していることを実感しました。これはマインドセットの転換にもつながる部分でもあり、アジリティの必要性を関係者間で揃える必要があると思いました。 アジャイル、スクラムの起源 ワークを通じて「アジャイルマニフェストの12の原則の自己診断」や「スクラムの理解度を確認する」といったアクティビティを行いました。私を含め、すべてを完全に理解し実践できている人はおらず、スクラムのフレームワークに沿ってきちんと実施するのは難しいと感じました。これまで、専任のスクラムマスターが配置されているチームにあまり関わったことがありませんでしたが、やはりチームにはスクラムマスターが必要であり、特に成長途上のチームでは成長を促すために長期間専任で関わるのが望ましいとのことでした。 ※参考： アジャイルソフトウェアの12の原則 アジャイルテストとは この分野については元々書籍などで理解していたため、再確認の場となりましたが、テストマニフェストが2023年に更新されていることを初めて知りました。「品質に対する責任…」から「テストに対する責任…」に変わったようです。 変更点 変更前：Team responsibility for quality over tester responsibility. 変更後：Team responsible for testing over tester responsible. 実例による仕様 提示された受け入れ条件に対してGherkin形式で実例仕様を記載するというワークを実施しました。ワークの時間があまりなかったため、形式に沿って記載することで手いっぱいになってしまいましたが、書くこと自体の難易度はそれほど高くないと感じました。また、短い時間でも受け入れ条件の抜け漏れに気づくことができ、実例仕様への期待効果である「曖昧さをなくす」「共通認識を持つ」「リスクを軽減する」「開発効率の向上」を意識しながら、今後も活用していけば有用な活動になると感じました。 DAY2 受入テスト駆動開発(ATDD)、振る舞い駆動開発(BDD) ATDDもBDDも言葉としては知っていたものの、実践した経験がなかったため、楽しみにしていた部分です。Cucumber Test Frameworkを使用したデモとライブコーディングを通じて、DAY1で説明があったGherkin記法を用いたBDDの流れをなんとなくイメージできました。また、ATDDとBDDのどちらも具体的な実例を通じて要件を明確化していくことは共通しており、実際に使用する際にはどちらを選んでも良いという点にも気づきました。 CI/CDとテスト自動化を使用して、早期に、頻繁に「完成」を達成する テストピラミッドを使ったテストプランニング作成のワークを行いました。どんな機能をテストするか、どんなテストを行うか、どのテストレベル（手動テスト、E2Eテスト、統合テスト、単体テスト）で確認すべきかをチームで話し合いながら決めていきました。これは実際の現場でもエンジニアやプロダクトオーナーを巻き込んで一緒に取り組むことで、誰が、いつ、どんなテストを行うかをすり合わせをすることができ、チーム全体での品質保証活動につながると感じました。 AIでテストの有効性を高める チームごとにワーク形式でChatGPTに相談しながらテストプランニングを作成するという活動を行いました。私のチームでは、「受け入れ条件」をインプットし、「Gherkin形式」でアウトプットすることを試みました。その結果、素早くそれらしい形のアウトプットを得ることができたので、うまく活用すれば作業の効率化に大きく貢献できるという印象を持ちました。生成系AIを効果的に活用するためには、ゴール設定や作業手順を具体的に伝える、短いやり取りを繰り返し行う、などのコツがあるようです。 アジャイルテストに適した指標 アジャイルにおける品質はチームの責任なので、テスターの指標よりもチームとして品質指標を定義することが重要とされています。 指標の例 プロダクトの価値を測定するための指標 チームのイノベーション能力を測定するための指標 価値を市場に出すまでの時間を測定するための指標 これまでの経歴を振り返ると、テストケース数、テスト工数、不具合数などをよく収集していましたが、これらは主にテスター寄りの指標であり、アジャイルに適した指標には必ずしも含まれるべきというわけではなく、より多様な視点のテストを期待されていることに気づきました。 現場への導入に向けての研修まとめ 最後は「SMART」のフレームワークを使って各自目標を設定しました。目標設定だけして終わりにならないように、同じチームのメンバーとその後の状況を確認し合うようにと、講師の方から念を押されました。その後、研修受講の証として「Registered Agile Testing」の資格を取得して終了です。この資格は取得できることが急遽決まったらしく、最初に取得した30人のうちの1人になれたとのことで、地味に嬉しかったです。 さいごに 以上が、「Scrum Inc. 認定 アジャイル・テスティング研修」の紹介（かなり割愛していますが…）となります。 もともとAgile Testingについては書籍を読んだりオンラインイベントに参加してお話を聞いたりと、一定の知見を持っていたため、座学パートは学び直しの部分が多かったと感じました。ただし、講師の方への質疑を通じて新たな知見を得たり、ワークを通じて実際に考えたり手を動かしたりすることで実践的なイメージをつかんだり、また、自分が難しいと感じていたことが他の人も同様に感じていると知って少し安心できたりと、研修を通じて多くの学びを得ることができました。 今後に向けては、マインドシフトが重要なので、まずは身近な人との対話の機会を増やし、徐々に広げていくなど、じっくりと時間をかけて取り組んでいきたいと思います。また、自動テストを改善したいという意欲が高まったため、開発エンジニアと密にコミュニケーションをとりながら最適な自動テストを目指していくつもりです。何かしら成果が出てきた際には、また別の機会に紹介できればと思っています。 エス・エム・エスでは引き続きQAエンジニアを募集しています。今回参加した研修のテーマにもなっている「AgileTesting」は、冒頭で紹介したQA組織の行動指針に通ずるところがあり、積極的に取り入れていきたいと思っています。少しでも興味・モチベーションがある方は是非カジュアル面談や選考へのご応募よろしくお願いいたします！！

お疲れさまです、5月に入社しました西田 ( @k_bigwheel )です。先日、エス・エム・エスの開発組織ではZennのPublicationというサービスを導入しました。この記事では、導入の背景と導入開始から完了までの経緯を紹介したいと思います。 Zenn Publicationとは Zenn Publicationとは、Zennというエンジニア向けナレッジ共有サービスの機能の一つです。 公式の紹介ページ に「Zenn上にチームのメディアを開設しよう」とあるように、投稿した記事をPublicationという集合へ結びつけることで、企業や組織としての集まりを表現でき、ブランディングやPRに使えます。 導入活動まで 今回、Zenn Publicationの導入に動き始めたのは5/30で、導入が完了して使えるようになったのは7/18でした。なのでこの1.5ヶ月ほどで導入できたのですが、実はZenn Publicationを導入したい、導入しようという話は去年の3月時点ですでに持ち上がっていました。 社内のesaに複数のページが作られ、導入したい背景やメリデメがまとめられるなどしたのですが、このときは導入に至りませんでした。 その一つの要因は類似サービスとは異なるZenn Publicationの規約の特殊性(書いた記事がエンジニア自身に帰属するようになる)をどう扱うか、社内で整理しきれなかったことにあります。ただ、本質的に進まなかった理由は、Zenn Publicationの導入に大きなモチベーションを持つ人がいなかった点にあるかなと思います。エス・エム・エスではすでにこのテックブログや外部登壇などアウトプットの手段が複数用意されており、Zenn Publicationがなくとも代替の手段がありました。 導入活動開始 その約1年後の5/16に私(西田)が入社します。 私には技術Tipsをインターネット上へアウトプットすることに大きなモチベーションがありました。過去に Qiita や 個人ブログ へアウトプットしてきたこともありますし、業務中に得られた知見を社会へ還元することに強いモチベーションを持っていたためです。また、前職でそれを可能にするガイドライン整備をした経験もありました( 業務中に書いたことを明記することで堂々と社会へ還元する )。 入社直後はこういったTipsを同僚に共有するいい機会なのですが、それをするプラットフォームがまだなく、一方で一年前にZenn Publicationの導入を検討していたことに気づきました。そこで、エス・エム・エスでも同様のガイドライン整備を開始することにしました(5/30)。 導入する上での課題 Zenn Publicationを導入するに当たっては、大きく分けて2つの課題がありました。それが次の2つです: 開発組織外との調整(法的リスクやPR文脈でのリスクの管理) 開発組織内での調整(既存のアウトプット方法との整合性) 開発組織外との調整(法的リスクやPR文脈でのリスクの管理) 1つ目はZenn Publicationで記事を書く上でのリスクのコントロールです。 Zenn Publicationに書いた記事は社内からだけでなく、インターネットに接続している誰からも閲覧できるため、場にそぐわない内容や誤った内容を投稿すると炎上するリスクがあります。また、前述の通りZenn Publicationは一般的なテックブログなどと異なり、記事が企業ではなく書いたエンジニア本人に帰属します。この辺りを会社のルールや方針とどうすり合わせるかという点も課題でした。 まず前者の広報文脈でのリスクについては、投稿前にエンジニア最低1名のレビューを挟むことで安全装置としました。また、書く内容を純粋に技術的なものに絞ることで会社の文化やルールなどが間違って伝わってしまうリスクをなくしました。ここはもっと安全側に倒そうとすればいくらでもできるのですが(毎回PRチームのレビューを挟むなど)、良い技術Tipsが迅速に世の中で公開されることに価値があること、純粋技術的な話であればリスクはかなり低いことなどを考慮して公開までのステップは必要最低限にしています。 後者の記事の帰属の問題については、時間をかけて準備を行い、リスクマネジメントを担当する部署に理解をしてもらった上でその導入に同意してもらいました。前提として、私含め導入関係者が Zenn Publicationのコンセプト の 例えば企業のテックブログでは、多くの企業が更新を続けることに苦労しているようです。その大きな理由として、メンバーのモチベーションを維持することが難しいという点が挙げられると思います。 労力をかけて良い記事を書いても、それは会社の持ち物であり、自分ではコントロールがしづらいものです。たとえ内容の間違いに気づいても、修正することさえ難しいこともあります。 私たちは、記事は著者本人の持ち物であり、退職後も本人が管理できるべきだと考えています。 Publicationを脱退した著者は、Publicationに投稿した記事をそのまま残しておくことも、個人の記事に変更することもできます。どちらを選択しても、記事は著者の成果物としてプロフィールに残ります。 「それでは会社の資産とならない」と心配する経営者もいるかもしれませんが、この自由がメンバーが記事を書くことを促し、より会社のブランディングや採用につながるのではないかと考えています。 に共感していたことがあります。導入を主導した私自身にもこれが正しいという確信があったので、あとはちゃんと伝わる資料を用意してロジカルに説明すれば必ず同意してもらえると信じていました。実際、Slack上でのやり取りは数週間続いたものの、MTGとしては何度もすることなく1度で済んでいます。 ※ ただし、ここについては利用規約の読み取りの経験や関連する法律理解が一定ある私が担当していたこともスムーズに進んだ要因だと思います。利用規約をどう解釈してどう対応するかはまったく知識のない者にとってはかなり難しい問題ですので、経験のない人がやる場合はもっと大変だと思ったほうがよいでしょう。 開発組織内での調整(既存のアウトプット方法との整合性) 2つ目は開発組織内での調整です。 エス・エム・エスの開発組織では、これまでにすでにテックブログや外部登壇などの外部アウトプットがあり、社内用ナレッジサービスとしてesaなども導入していました。 そのため、Zenn Publication導入にあたってはテックブログと何が違うのか、社内esaに書くことと比べてのメリット、Zenn Publicationを導入し、維持していくコストとメリットが釣り合っているかなどを整理していきました。 その辺りは必要だろうと予測がついていたのですが、予想外だったのはアウトプットに対する組織の文化・考え方の点です。エス・エム・エスでは従来から業務中に得た知見であっても、個人のブログや登壇で話していい、という文化だったのですが、このZenn Publication導入によって、個人のブログへの執筆などが制限されるのではないかという不安が組織内で起こりました。これは入社1ヶ月未満だった私が知らない文化で事前に想像できておらず、Zenn Publicationのガイドライン作成の中で発覚しました。最終的に既存のアウトプットと整合するものにガイドラインを変えることで対応しました。これが、本格稼働前に発覚して修正できたのはとても良かったと思います(開始してから発覚したらゴタゴタするため)。 余談ですが、年をとって経験を重ねることで社内の法務部・PRチームとのやり取りはどんどん上手くなりましたが、こういった組織の文化・開発文化というものは組織ごとに異なるため、常に未知のものがあるなと思います。前職でも、入社後数年経ってから、アウトプットに関する考え方が組織と自分で大きく異なることに気づく、ということがありました。 導入完了 上記の課題2つが7月にクリアできたため、7/18に晴れて全体チャンネルで利用可能になったことを告知しました。 実際にできたPublicationが以下です。 zenn.dev 株式会社エス・エム・エス | Zenn 公開から1ヶ月以上経って、記事数は4とまだまだ *1 ですが、これから徐々に増えていけばいいなと思っています。 振り返り まず組織としての振り返りの観点で考えると、まずは、新たなアウトプットの手段が増えたことが単純に喜ばしいなと思います。エス・エム・エスの社内ではものによってはインターネット上にほぼない、もしくはまったくない知見や技術なども見つかっていますので、そういったものを迅速にアウトプットする手段は長期で見て社会に、そしてエス・エム・エスの開発組織としてもメリットになるでしょう。 個人として振り返ると、この一連の動きで社内の各部署とうまく連携できたこと、これをきっかけにエス・エム・エスの開発文化の理解が進んだことが大きなメリットでした。こういった開発組織の内外を跨いだ動きを苦手とする人も多いと思いますが、私はこの分野に強みがあるため、今回の導入が1.5ヶ月という短時間で大きな手戻りなく達成できたことはよい成功体験になりました。今回のZenn Publication導入のような組織規模での動きはレバレッジが効きやすく効果が高いので、チャンスがあればまたやっていきたいと思います。 *1 : この記事の公開時点では6記事。

2024年4月にエス・エム・エスに入社した田実（たじつ）と申します。 この記事ではエス・エム・エスに入社した理由を経歴を踏まえて振り返りつつ、入社して思ったこと、これからやりたいことを紹介します。 これまでの経歴 1社目はSalesforceの導入・運用支援を行う会社でSalesforceエンジニアとして働いていました。 顧客折衝・要件定義・設計・開発・テスト・リリース・保守と、様々な業界のシステム開発に一気通貫で携わることができました。SalesforceだけではなくAWSやHerokuを使ったWebアプリケーション開発や外部サービス連携などの経験もでき、システム開発エンジニアとしての下地を作ることができました。 働いていく中で、次第に技術自体への興味関心が強くなったことや、腰を据えて自身の技術力やサービスを伸ばしていきたいと思うようになり2社目の会社に転職しました。 2社目は自社サービスを開発・運用している事業開発会社で、ポイント交換やデジタルギフト、ファッションサブスクリプションの新規事業のサービスに携わりました。 GitHubを使った開発フロー、アプリケーション/DB設計、CI/CD、監視、アラート運用、インシデント対応など、自社サービスを運営していく上で必要不可欠な知識を身につけることができました。 施策系の開発以外にもPHPやライブラリのアップグレードや不要コードの削除、静的解析の導入など、大規模アプリケーションの技術的負債を解消する取り組みも行い、技術力を大きく伸ばすことができました。 このように腰を据えて技術力を伸ばしていきたいという当初の目的は満たせたのですが、次第に事業やプロダクト自体にも興味が出てきました。 3社目はノーコードのSaaSを運営する会社です。自分が魅力に思うプロダクトに携わることで、技術力・非技術力をもっと磨けるのではないか、日々の仕事の充実度も上がるのではないかと思い転職に至りました。 SaaS特有の事業的・技術的な難しさは多々ありましたが、好きなプロダクトを技術的にどう伸ばしていくかを考えることは非常に充実した時間でしたし、結果としてエンジニアリング力も上げることができました。 プロダクトの面白さを日々感じていた一方で、「プロダクト・事業が解決する課題・事業領域」に物足りなさを感じたことや、自身のライフステージの変化もあり今回の転職に至ります。 エス・エム・エスに入社を決めた理由 事業領域や課題は実際に聞いてみないと魅力がわからないなと思い、カジュアル面談は40社ほど受けました。カジュアル面談では「ビジネス・事業領域の面白さ」「自分の経験を活かせるか、伸ばせるか」を軸に見ていました。また、これまでの会社では独力で技術的改善を進める経験が多く、独力で進めることの限界を感じていました。そのため、チームで課題を解決する・チームと一緒に成長していく力を伸ばしていきたいという思いもあり、それを実現できそうな環境を探していました。 エス・エム・エスではカジュアル面談や面接を通じて、医療・介護領域における社会課題とそれにどう立ち向かっていこうとしているのかを丁寧に説明してもらいました。話を聞く中で、課題を解決したときのインパクトの大きさや課題の難しさを感じつつもビジネスや事業領域の面白さにワクワクしたのを覚えています。 人材紹介のサービスではPHP・Laravel・Salesforceが利用されていることや、技術面で改善していきたいポイントがあるということを伺い、自身の経験が十分に活かせる環境であることも入社の決め手でした。 エス・エム・エスではチーム間で技術やドメイン知識の共有を強化する動きがあり、人材紹介グループでは技術的な品質意識をチーム全体で上げていく プロダクションレディ の取り組みがあるなど、「チームで」やっていく経験やスキルを伸ばせそうなことも入社した理由の１つです。 また、自分自身もエージェント型の人材紹介サービスにお世話になった経験から、エス・エム・エスが運営している人材紹介サービス自体に対しても好印象でした。そんなこんなで今回ご縁がありエス・エム・エスに入社しました。 入社して思ったエス・エム・エスの良いところ 入社してから現在まで、 保育士人材バンク という保育士向けの人材紹介サービスのシステム開発・運営をしています。 入社前は、「エンジニアが要求・要件から主体的に関わってコーディングだけではなく本質的な課題解決ができそうな環境か」とか「開発環境も含めた改善業に対してネガティブではないか」あたりを気にしていたのですが、そのあたりは特に問題なく楽しく仕事ができています。 前者の懸念に関しては、マーケティングチームとエンジニアチームが協力して各種施策を進めているのですが、いわゆる「考える人」「作る人」といった分断は全くありません。エンジニアの意見が求められることもありますし、表面的な要求をそのまま実装するのではなく、本質的な課題を捉えないといけない場面もあります。 後者の改善に対する姿勢に関しては、前述のプロダクションレディのような技術的な改善の取り組みもあり、改善に対して前向きです。私もいくつか改善に対する相談などをSlackで投げたりしているのですが、いずれも建設的な議論ができています。強めの言葉やネガティブな発言をする人もいないので、心理的にもエンジニアとして働きやすい環境です。 esaを共有して良いリアクションをもらっている図 チーム間のエンジニア同士のつながりや技術的な共有をするような試みも多数行われています。esaで他チームが書いたドキュメントを見れたり #tech #php #ruby #golang のようなSlackの技術系チャンネルもありますし、チーム横断で交流できるようなチームビルディングのイベントも頻繁に行われています。 また、このテックブログの執筆・プロセスもかなり整備されており、編集チームが執筆のサポート・校正を行ってくれたり、公開予定の記事や日付もしっかり管理されています。こちらも継続してチームとして改善し続けている成果だと思いますし、良い感じに改善プロセスを回せている組織なんだろうなぁと思っています。 これからやりたいこと 現在担当している保育士人材バンクをもっと良くしていくためにはエンジニアリングによる施策支援が重要です。この「エンジニアリング」の部分をもっと効率的に、効果的に回していくために守りの改善もしていく必要があります。 トライしやすい環境を作り、不確実性の高いドメイン領域でエンジニアの力を活かせるようにできると良いなと思ってます。そのためにも、大小様々な課題に対して自分の能力だけではなくチームを巻き込んで良い感じな技術基盤を作っていきたいです。 そして自分が担当しているサービス以外のチームにも知見を共有し、人材紹介開発グループ全体のビジネスをより強化するような技術環境、組織を一緒に作っていければと思います。 また、人材紹介開発グループのテックブログの記事が少なめなのでそこも増やしていきたいと思っています。技術的にめちゃくちゃ良いネタをたくさん持っているので、自分も含めてチームとして書く流れを作れると最高ですね…！

はじめに カイポケリニューアルプロジェクトでQAエンジニアを担当している北村です。 今回の記事では、2024年1月に入社した後、自身の所属チームで行ってきた品質保証関連の取り組みについてお伝えできればと思います。 エス・エム・エスの品質保証活動について興味がある方は是非目を通していただければ幸いです。 エス・エム・エスのQA組織の行動指針について エス・エム・エスのQA組織は「行動指針」という形で、QAエンジニアが大切にしている考え方を言語化しています。行動指針の詳細については、以前の記事で説明しておりますので是非ご覧ください。 tech.bm-sms.co.jp 今回の記事では、行動指針の一つでもある「チームで品質保証」を実現するために行なっている施策について紹介いたします。 「チームで品質保証」実現の第一歩はテストドキュメンテーション ここでは「チームで品質保証」を実現するための第一歩として実践したテストドキュメンテーションについて説明します。「テストドキュメンテーション」は「テストに関する情報のドキュメント化」を指しています。少し紛らわしいのですが、今回の記事で言っている「品質保証」は「品質を向上するために行う作業全般」を指しており、「テスト」はQAエンジニアによる手動テストだけではなく、開発者テスト・自動テストも含めたテスト全体のことを指しています。「品質保証」と「テスト」を明確に定義して線引きをするというよりは、「テストも含めた品質を向上するために行う作業全般」の話をしているんだなという認識で読んでいただければ幸いです。 「チームで品質保証」つまり「チームメンバー全員参加の品質保証活動」を実現するためには、「品質保証活動の目的とは何か」「どうやってプロダクトの品質を向上させていくのか」について認識を揃える必要があります。「品質保証」という言葉だけでは人によって解釈・受け取り方が異なるため、具体的な活動内容が想像できるように「 品質保証方針 」というドキュメントを作成しました。 品質保証方針には「品質保証活動を行う目的」「品質を向上するための実際にやること」「Quality / Cost / Deliveryのバランスをどう取るか(トレードオフの関係という意味ではない)」といった情報を記載していて、この方針を元に各機能開発における品質保証活動をしていきましょう、という宣言のようなものです。 各機能開発においては、QAエンジニアが「 テスト要求分析レポート 」「 テスト計画書 」といったドキュメントを作成します。この２つのドキュメントを簡単に説明すると、「テスト要求分析レポート」は主に「テスト対象機能の特定」「テスト目的の設定」「テスト戦略の概略整理」という目的で作成し、テスト計画書は「テストの目的や目的達成に至るまでの具体的な手段・スケジュールを明確にする」という目的で作成します。 ここからは「なぜこのドキュメントが必要か」「このドキュメントを通じて何を達成したいのか」といったドキュメント作成の意図も交えながら各種ドキュメントについて解説していきます。 テストドキュメント各種について 「品質保証方針」について 「品質保証方針」は各機能開発における品質保証活動の前提となる考え方で、「私たちのチームは基本的にこうやって品質保証活動をしていきます」という方針が記載されているものです。「品質保証活動で達成すべきもの」「品質向上の基本方針」「品質保証プロセス」といった項目で構成されています。 「品質保証活動が達成すべきもの」とは 品質保証方針では、「品質保証活動が達成すべきもの」は「チームで達成すべきもの」とイコールであるという書き方をしています。そもそも「品質って何？」については現状明確な定義をしておらず、チームで掲げている目標を達成するための手段として品質保証活動があるんだよ、ということを表現しています。人によっては(あるいはチームによっては)「テスト・品質保証活動はチーム内の独立した活動である」という考え方もあると思うので、品質保証活動とプロジェクト活動が一体であることを強調しています。また、「Quality / Cost / Deliveryのバランスをどう取るか」についてもこの項目で言及しており、プロジェクトの状況に応じて「今の段階では早くリリース(Delivery)して価値検証を優先しましょう」「こういった機能については品質(Quality)を重視しましょう」といった方針が書かれています。 「品質向上の基本方針」について 「品質向上の基本方針」には、仕様の検討からリリースまでにどう言った方針で品質を向上させていくかを記載しています。「不具合は早期発見を目指す」「不具合は予防と検知に分けて対策を講じる」といった方針が記載されており、この方針に従ってテスト計画を立てていきます。 「品質保証プロセス」について 「品質保証プロセス」については、品質保証方針を前提とした各機能開発におけるプロセスを書いています。 簡単に表現すると以下のような内容です。 最後に補足的な話ですが、この品質保証方針は「初版」の段階で、これからチームのみんなでアップデートしていくものだと考えています。現状ではチームメンバーに対して共有するタイミングが少なく完全に浸透しているとは言えないのですが、今後は品質保証方針を通じてチームの品質保証活動を導いていきたいと思っています。 特に「品質の定義」「品質保証活動の目指すもの」についてはアップデートしていく必要があり、達成すべき品質の基準を作りながら品質保証活動を最適化していこうと思っています。 「テスト要求分析レポート」「テスト計画書」について 「テスト要求分析レポート」作成は「テスト計画書」作成前の情報整理のような立ち位置にしており、互いに結びつきが強いためセットで取り扱います。 それぞれに記載している内容は以下の通りです。 テスト要求分析レポート 分析のインプット(リファレンス) テスト対象の特定 テスト戦略の概略整理 テストフローの設計 テスト計画書 計画のインプット(リファレンス) テスト対象・目的・戦略 制約事項 リスクマネージメント テスト開始・修了基準 不具合管理 テストスケジュール 項目で見ると「テスト対象の特定」「テスト戦略」が重複していますが、テスト要求分析レポートではあくまで「概略を整理する」ことを目的としており、テスト計画では「明確な決定事項(これで進めるよ、と言えるもの)を記載する」ことを目的としています。ただし「テスト要求分析レポートではここまで書く。これ以上書かない」といった明確な基準を設けていないので、状況によって記載する粒度・いつどこまで決め切るかを柔軟に変更して対応しているというのが実状です。早めにテスト観点の整理や要求・仕様の構造化を行なって合意を取りたいのであれば、テスト要求分析の段階で行うこともあります。その時のニーズに合わせながら、テスト要求分析 -> テスト計画と段階的に品質保証活動を具体化していきます。 こういったドキュメントを作成しておくことで、後から見直した時に「あの時はこういう経緯・意図でこうゆうテストをやったんだな」ということがわかるので、貴重な資産にもなります。勿論リリース後に万が一インシデントが起きてしまった場合、どの工程に問題があったのか特定するのに役立てることができます。 また、これらのテストドキュメントは他のロール(PdM 、PO、Dev)にレビューしてもらっていて、レビューを通じてリリースまでに行う品質保証活動の認識を揃えています。他ロールのレビューは毎回必ず行っているものではないのですが、ドキュメントのレビューや情報共有を通してQAエンジニアが実現したい品質保証プロセスをチームに定着させていきたいと思っています。 ドキュメント作成の基本方針について ここまで「品質保証方針」「テスト要求分析レポート」「テスト計画書」という３つのドキュメントを作成しているという説明をしてきました。説明を読んでいる間「そんなにたくさんドキュメントを作って時間かからないの？」という疑問を持つ人もいたかもしれませんが、全ての機能開発で全てのドキュメントを作成しているわけではありません。テスト対象・テストで確認する観点が明確な時は「必要なものを必要な時に作る」を基本方針としています。必要かどうかは「ドキュメントを用いた情報整理が必要か」「誰とどんな合意を取りながら進めるべきか」と言ったところを勘案して決断しており、開発対象物やチーム・プロジェクトの状況に応じて適切な動き方をすることを重視しています。 その他「チームで品質保証」を実現するためにやっていること 実例マッピング 冒頭でご紹介したQA組織の行動指針についての記事でも簡単に紹介していますが、私が所属しているチームでも実例マッピング(Example Mapping)を導入しています。 実例マッピングでは開発がスタートする前にPdM ・PO・Dev・QAエンジニアが揃ってユーザーストーリーについて疑問点を洗い出し、解消していきます。こう言った活動からも品質リスクの軽減を目指しています。 私が所属しているチームでは、ロールに関係なくチームメンバー全員がサービス理解・ユーザーへの貢献に対してモチベーションが高く、仕様・デザインの共有の場では積極的に議論が行われます。プロダクト要求やデザイン共有の時点で、各ロールのフィードバックが行われ活かされていくと、その後の開発品質向上・不具合混入防止が見込めるのでとても有効です。 テスト実施状況・不具合抽出状況の計測 まだ導入して間もないのですが、バグヒット率(何件テストを実施し、何件どのようなバグが見つかったか)の計測を開始しました。テストの成果となる指標を中長期的に取ることで、「致命的な不具合がどれぐらい出ているのか」「QAエンジニアのテストでどれぐらい致命的な市場不具合を防ぐことができているのか」を可視化できる状態にしておくことが狙いです。どのような傾向が読み取れるのか不透明な状態ではありますが、まずは簡単に計測できるところから開始しています。 こういった傾向分析をチームの品質保証活動にフィードバックしていって、品質保証活動全体の質を向上していけたら良いなと思っています。 まとめ 私の所属チームでは、ここまでで説明したようなテストドキュメントを通して良い効果が出始めていますので、最後に少し紹介します。 例えば、テスト計画書レビューでは開発者とテストスコープやテストの仕方について議論する機会を作ることができています。開発者視点での品質リスクを出してもらったり、QAエンジニアから開発者に「こういうところはテストしておいて欲しい」といった依頼をしたり、効率的にテスト活動を行うための情報共有ができています。 PdMやPOにも同様の機会を設けているのですが、対象の開発案件で実現したいユーザーストーリーの認識を合わせたりテストの全体像を共有するだけではなく、プロダクトリスク・プロジェクトリスクといったリスク管理について議論をすることができています。リスク管理のところはPdM・POから良いフィードバックを得られることが多いです。 テスト要求分析レポートのチーム内QAレビューでは、特にテスト戦略のところでは議論が白熱することが多く、どの段階でどのような粒度でテストを行うか、どのようなテスト技法を使うかといったところを議論しながら進めることができています。 開発者・PdM・POそれぞれの得意領域で良いフィードバックをもらいながらテスト計画を改善し、テスト活動を実行していくことで「チームで品質保証」を実現していきたいと思っています。 ただ、今のテストドキュメントやテストプロセスが最善だと思っているわけではなく、チームの状況やプロダクトを取り巻く環境の変化に合わせて改善し続ける必要があります。テスト計画の内容は適切だったのか、計画通りにちゃんと実行できていたのかといったことを振り返るのがとても重要です。 今回ご紹介した取り組み以外にも行っている活動や、今後やりたいと思っていることもたくさんありますので、「もっと詳しく聞いてみたい！」と言う方は是非カジュアル面談の場でお話しましょう！

先日開催されたRubyKaigi 2024にエス・エム・エスもスポンサーとして参加しました。 tech.bm-sms.co.jp 社内で「実際どんな感じだったか知りたい」という声があったため、参加しなかったメンバーへ向けてフリートーク形式の「RubyKaigi共有会」を実施しました。 そこで今回は、共有会で取り上げたトークテーマと実際のやりとりをかいつまんでご紹介できればと思います！ 今回ご紹介するトークテーマは以下の4つです。 参加した目的について セッションについて ブースについて #kaigieffect *1 について トークテーマ「参加した目的について」 "RubyKaigiに参加する目的はなにか？"というところからフリートークは始まりました。"セッションを楽しむため"という話はもちろんのこと、”いままで過去仕事をしてきた人と会うため" というような再会の場として参加するという話もありました。 また、なにか特定の目的ではなく「 RubyKaigiに参加するため 」「 そこにRubyKaigiがあるから 」などの言葉も飛び出し、RubyKaigiの存在そのものが参加する理由になっているという話もありました。 トークテーマ「セッションについて」 "好きなセッションを教えて"、というような問いかけには「全部」という声がありながらもあえて1つあげるとすれば、というところでメンバーから思い思いのセッションが挙がりました。 まず話題に登ったのが二日目のキーノート " Leveraging Falcon and Rails for Real-Time Interactivity " でした。メンバーからは「取り上げられた技術に関して、"ちゃんと手を動かしてコード写経してみて動きをちゃんと見てみよう"と思うような、技術的にやってみたいと思わせるトークだった」ということが感想として述べられました。 同じく、初日のキーノート " Writing Weird Code " の話題でも盛り上がりました。参加していないメンバーに向けて、このセッションのどこがすごかったかを説明するのに苦労しながらも、過去のTRICK *2 のコードを紹介しつつ、セッションの衝撃を共有しようとしていました。 先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。 全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。 魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of — ぺん！ (@tompng) 2022年10月18日 途中でパーサーについての話題になり、詳しいメンバーからの「なぜ去年〜今年のRubyKaigiではこんなにたくさんのパーサーにまつわるセッションがあったのか」について歴史的な経緯を含めた解説も交えつつ、今のRubyコミュニティでパーサーがホットトピックになっていることをその場で体験できるシーンもありました。 トークテーマ「ブースについて」 他社さんもふくめたブースに関しての話もいくつかあがりました。まずは最初にあがったのはSTORESさんによるRuby "enbugging" quiz でした。 product.st.inc 参加メンバーも、自社のブースにお客さんがいない時間帯に楽しんでいました。 またシンプルフォームさんによる自社ドメインにちなんだクイズや、SmartHRさんの人事労務に関するフレーズのタイピングゲームなど、各社のビジネス領域をうまく活用したブースに関して盛り上がりました。 また、ちょうど我々のブースの真裏のRuby開発さんでは、プロの理学療法士さんによるマッサージが実施されていたことも話題にあがりました。弊社メンバーも何人かお世話になっており、解説付きのマッサージを受けることができて良かった、というところで盛り上がりました。 我々エス・エム・エスのブースに関しても振り返る場面がありました。エス・エム・エスでは実際に自分たちが普段開発しているプロダクションコードを会場限定で公開する、という取り組みを行いました。普段どういう開発をしているのだろう、というところに興味を持ってみてくれる方が非常に多かった印象です。 トークテーマ「 #kaigieffect について」 "皆さんの #kaigieffect を教えて下さい"という話が最後のトークテーマとしてあげられました。「コードを書きたくなった」という定番の話のあとに、「英語を頑張らないと」という言葉が出ると参加メンバの多くから同意の声があがりました。英語話者の人とコミュニケーションする機会が多い、RubyKaigiならではの話題でした。 また、「(コロナ禍に入ったことで足が遠のいていた)地域.rbに参加したくなった」という声もありました。RubyKaigiでの交流を経て、オフラインでのミートアップへの気持ちが高まっていることが感じられる一幕でした。 最後に エス・エム・エス社内には、Rubyで開発しているプロダクトやチームが複数存在しています。今回のRubyKaigi 2024への参加を通して、普段仕事では関わらないメンバー間の交流が生まれたりもしました。そんな側面も含めて、RubyKaigiへの参加は有意義なものだったのではないかと思っています。 たくさんのプロダクトがあり、Rubyで開発されているものもそうでないものもある弊社ですが、もし少しでも興味を持ってくださって、どんなふうにやっているのだろうと思っていただいた方は以下からカジュアル面談にお申し込みください！ *1 : RubyKaigiや地域RubyKaigiに参加したことがきっかけで起きたことを #kaigieffect を付けてSNSでシェアするという文化があります。 https://x.com/snoozer05/status/91327881447350272 や https://scrapbox.io/iki-iki/%23kaigieffect を参照。 *2 : TRICKは "Transcendental Ruby Imbroglio Contest for rubyKaigi" の略で、日本語にすると「超絶技巧 Ruby 意味不明コンテスト in RubyKaigi」という超絶技巧のコードを競い合うコンテストのことです。

エス・エム・エスで開発組織のマネージャーをしている @sunaot です。余談ですが、このブログでは名乗るときにいくつかの言い方を過去にしていて、「技術責任者」「技術組織のマネージャー」なども名乗っています。面接の場では「プロダクト組織のマネージャー」と言っていたりもします。これは次々肩書きが変わっている...というわけではなく、どれもロールとしてはやっているので、そのときのコンテキストで一番適切なものを名乗っていました *1 。今回は、開発組織のマネージャーとしての側面から話すのが適切でしょう。 さて、 5月28日に開催されたファインディ株式会社主催のイベント で、「継続性視点での開発生産性マネジメント」というタイトルで発表しました。今回の発表内容は、映像が YouTube アーカイブに、スライドは Speaker Deck にそれぞれアップロードされ公開されています。 イベントのアーカイブ動画 『継続性視点での開発生産性マネジメント』 スライド 『継続性視点での開発生産性マネジメント』 そのため、細かな内容はそれぞれを見てもらうものとして、この記事では、 当日話した内容への補足 今回このテーマを選んだ動機 について説明をすることにします。 発表内容の概要と補足 発表内容を一文で説明するとしたら、 「戦略志向の組織マネジメントを通して高い組織パフォーマンスを実現し、ビジネスと開発それぞれの継続性を手に入れよう」 です。 戦略を考えるステップについてはスライド p44 に紹介しています。いかにこのコンテンツをつくるかについては、より具体的な事例を話すしかなく、今回はつっこんで話すことができませんでした。ここでは少しその補足をします。 まず、このようなプランを考えるときになにをやるのかやそのプラクティスがどれだけ切れ味鋭いかっこいいものかといったことへ意識がとられますが、そうした WHAT よりも大事なのが WHY にあたる部分です。このスライドでは、 「どのような状況か」「その中でどのような状態を目指すのか」「その過程でのイシューはなにか」の部分になります。今の状況をどう解釈するのかには無数の可能性があります。その中で将来に対しての見地から、 「今はこのような状況だと見ている」というスタンスを明確に置く のがまず最初の重要な仕事です。多くの場合、ここがなんとなくの現状認識・共通見解というところからスタートしてしまい、その後のアプローチが弱いものになる傾向があります。 ここでスタンスを明確にしていくにあたり重要になるのが 「その中でどのような状態を目指すのか」 です。物事の良し悪しの評価というのは文脈によって変わってきます。今どのような文脈だと考えればよいかの指針となるのが目指すべき状態になります。 最後に 「その過程でのイシューはなにか」 です。おおよその文脈が定まり、現在地へのスタンスを明確にしました。それでも、そこからゴールへたどり着く道筋はたくさんあります。まずはその道筋の中から考慮に値するものを選択肢として挙げていきます。そして、それぞれの選択肢を評価していく中で、どのルートをたどるにしても壁になってくる問題というのが浮かび上がってきます。それが組織全員で取り組むべき重要なイシューです。イシューの設定が良質なほど、その後の解決のフォーカスや実現過程の組織の動きがぶれずに問題へ立ち向かうことができます。 一連のストラテジーを作るのは EM 一人の仕事かというと、そうとも限りません。どこまでのパートを一人で考えるか、周りを巻き込み答えをつくっていくかは状況によって最適解が変わってきます。組織でこのプランを組み立てられるようにしていくのが EM の大事な仕事になります。 このテーマとした動機 今回のイベントは Findy さんが主催し、開発生産性をテーマにこれまでも多数の発表がされてきているものです。発表の機会をもらえたときに、当然なにを話すのかを考える必要がありますが、実はやや内容に迷いました。というのも、私は あまり開発生産性を目的としてなにかを考えたことがなかった からです。 もちろん、デリバリーの効率を上げるために開発者体験を向上させることや、ムダを省くこと、早い失敗から開発のサイクルへ継続性をもたらすことといった開発生産性へつながるプラクティスの一つ一つは大事にして来ています。むしろ人よりもそこへ費やした時間は長い方だと思います。ただそれらは Time to market を短くしたいと求めた結果であって、開発生産性へこだわってやってきたわけではなかったりします。 そして、発表の中でも少し触れましたが、そうやって 開発生産性の高い状況を求めても容易にそれが壊れうる ことも知っています。その最たるものはビジネスの状況悪化ですが、そこまで大きな要素でなくても、フィーチャー開発の過程でも環境への理解不足からデリバリーの効率のために投資したはずの環境はやはり壊れることがあります *2 。 そうした理解の中で、 開発生産性をことさらに取り立てて扱うことよりも、それを通して何を実現するのかへ目的を置いた発表内容にしたい と考えていました。そして、一般解としてのデリバリーの効率が高い状態を目指すのでなく、その効率というのも何に対して最適化させるかを考えるということを話すことにしました。ドメイン固有の問題を特定し、その問題に最適化をした解決をすることで、デリバリーの効率を上げることという機能効率の問題から、そのビジネスにおいて何がパフォーマンスを決めるのかという目的志向の問題へ問題設定を変えたかったのです *3 。 発表では必要なプロセスの説明はしましたが、具体的な話をあまりできなかったので、こちらにも補足をしておきます。たとえば、ソーシャルゲームの開発をしている場合によくある話としては繰り返し行われるイベントをどう扱うのかという話があります。類似したフォーマットのイベントを繰り返すことでビジネスの成長は得られるため、そこへ最適化をして効率を高めるというのはよく採られている選択だと思います。ドメイン固有の解の一例でしょう。 では、これは良い選択なのかというと、組織の視点では様々なことが考えられます。イベントにはフォーマットがあるため、基本的にはフォーマットに沿ってパラメータを変える程度の開発へ人やプロセスを最適化したとします。これは他の新しい機会を開拓する能力を下げるかもしれません。反対にそこで生み出した時間の余裕によって、新しいチャレンジをする機会をつくることができるという理解も可能です。 今自分たちが扱っているソーシャルゲームというものをどういうプロダクト、マーケットだと理解をするのか という前提の置き方で、答えは変わってきます。 こうしたことを考えながら、 自分たちの組織にとって組織のパフォーマンスが出ている状態というのはどのような状態なのかを定義し説明可能にしていく ことはとても重要なことだと考えています。なぜなら、それは長期的な組織マネジメントの土台になっていくからです。 *1 : 参考： 「sunaotに聞いてみた・後編 あえてCTOを名乗らない理由」 。 *2 : だから無意味だというのでなく、だから常にメンテナンスを怠らず面倒を見続ける必要があり、たゆまぬその活動には高い価値があるという話です。 *3 : デリバリーが重視される背景には、高いデリバリーの能力を持つことで結果的にマーケットに対する検証が高速に進み、それが次の価値を生む可能性を高めるという考えがあります。それ自体は否定していません。ただ、同時にドメインの視点も持ちながら考えていくことが良いと考えています。

こんにちは！夏ですね。 @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年生になりやっと見えてきたことや、大変なこともあって、もちろんこれからも大変なことがたくさん待っているけど、なんとかやれているしやろうと思っている様子なども伝えて、ふとした瞬間にこのブログを読んでくださった全ての働く親御さんたちにちょっとでも共感してもらえたり、気持ちが軽くなってくれたら嬉しいです。 その上で是非エス・エム・エスにも興味を持ってもらえればと思います！