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

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

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

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

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

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

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

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

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

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

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

こんにちは、プロダクト開発部人事のふかしろ( @fkc_hr )です。 年の変わり目ということで目の前の数字だけではなく、通年単位での実績の振り返りなどをしていたところ、なんとプロダクト開発部の採用活動の中で、2023年で約400件のカジュアル面談を実施していたことがわかりました！ありがとうございました。 カジュアル面談のFAQページを作りました カジュアル面談の時間をより充実したものにするために、改めてこんなコンテンツを作成しました。 careers.bm-sms.co.jp 上記コンテンツでは、カジュアル面談でよくご質問いただくことへの回答や、補足になるような過去の記事をご紹介しています。 カジュアル面談に参加するかどうか迷っている方もこちらのページをご覧いただいて、興味を持っていただくきっかけになると嬉しいです。もちろん、 カジュアル面談前に目を通していただく必要はございません 。 カジュアル面談の雰囲気 2021年に記事公開したころから、スタンスは変わっておらず、 面談の参加に転職意欲は問いません。 tech.bm-sms.co.jp カジュアル面談は技術責任者の田辺、エンジニアリングマネージャーの古萱、酒井、荒巻、その他状況に応じて現場社員が参加します。 マネージャー陣が現場の状況を知っているので各事業のご紹介はもちろん、一人ひとりのキャリアに向き合って相談する1時間になっています。 人事として採用・広報活動をしている中で、もっとエス・エム・エスのことをいろんな方に知ってほしいな！と考えて作成いたしました。 今年も様々な方とカジュアル面談含めてお話させていただきたいです。 最後に エス・エム・エスのプロダクト開発部では2024年も採用・広報活動を実施していきます！よろしくお願いいたします。 もっと詳しく聞きたい！と思っていただけましたらお気軽に記事末尾のカジュアル面談応募リンクからお申し込みください。

こんにちは、プロダクト開発部人事のふかしろ( @fkc_hr )です。 エス・エム・エスは複数の事業を展開しており、プロダクト開発部もそれぞれのチームが事業ごとに開発を進めているのが特徴です。今回、キャリア分野の取り組みについてまとめた事業・プロダクト紹介のピッチ資料を作成いたしました。本記事では一部抜粋する形で内容の紹介と今後の記事の告知をさせてください！ 医療キャリア事業とは？ エス・エム・エスのキャリア事業領域では、高齢社会が直面する「質の高い医療・介護サービスの提供が困難になる」という社会課題に対し、「医療・介護の人手不足と偏在の解消」に貢献することで解決を目指しています。 医療キャリア事業とは、その中でも特に医療領域にフォーカスをあてている事業です。医療従事者の長いキャリアを線で捉え、マーケットの真のニーズに寄り添ったサービスを提供しようと考えています。 医療キャリアに向き合う開発組織の変化について ピッチ資料からの引用になりますが以下のような開発組織の現状があり、開発体制を変化させようとしています。 これまで10年以上に渡り医療キャリア事業のサービス運用をしています。市場が伸び続けていることもあり、それに応えるために求められる機能をどんどん積み上げていくような開発をしてきました。 しかし事業フェーズも変わり、この手法ではより大きな課題への対処が難しいと感じています。今後は、開発チームがよりドメインに精通し、プロダクトの検証を重ね、ユーザーに提供すべき価値を洞察するための開発体制を築いていく必要があると考えています。 このような現状や課題以外にも、本ピッチ資料では医療キャリア事業が抱える技術的な課題や組織の取り組みなどについて赤裸々に書いておりますので、ぜひご一読ください。 careers.bm-sms.co.jp プロダクトやチームの裏側を順次公開予定 ピッチ資料は非常に項目が多くなってしまうため、それぞれの具体的な取り組みや組織強化中のチームの社員紹介などもしていきたいと考えています。 すでに数名入社エントリーを公開済みです。 tech.bm-sms.co.jp tech.bm-sms.co.jp さらに、今後、以下のようなテーマで記事を公開していく予定です。 ぜひ Xのアカウント をフォローして新着通知をお待ちください。 プロダクションレディな品質についての記事 各メンバーの入社エントリー記事 カンファレンス登壇内容の資料公開記事 事業責任者のインタビュー記事 プロダクトを支えるメンバーを積極採用中 最後になりますが、このキャリア事業における取り組みは、まだまだ多くのエンジニアの方の協力を必要としています。先ほどご紹介したサイト内に募集中のポジションを記載していますので、興味のある方はぜひご覧ください！また、エンジニアだけでなく、プロダクトマネージャー・UI/UXデザイナーなどプロジェクトに携わるポジションを全方位的に募集しています。 カジュアル面談もやっておりますので「選考に進む気持ちはまだないけどプロジェクトについては面白そうなので聞いてみたい」という方でも構いません。ご興味があれば是非お気軽にお声がけください！

プロダクトマネージャーカンファレンス2023で登壇しました 介護職向け求人情報サービス「 カイゴジョブ 」のプロダクトマネージャーを務めている田中（ @tatsunori_ta ）です。 株式会社エス・エム・エス Advent Calendar 2023の8日目の記事 でもお伝えしておりますが、会社を代表して プロダクトマネージャーカンファレンス2023（pmconf2023） にて登壇する機会をいただきました。 note.com pmconf2023では「”リビルド”プロダクトマネジメントの極意」のタイトルで発表しております。 発表要旨は以下です。 ある程度の規模、組織では既にあるプロダクトのPMになる方も多いでしょう。創業者からPO・PMを引き継ぐケースや、他PMからPM業を引き継ぐケースなど。キャリアを通して、プロダクトの再検討フェーズに入ることが多い私ですが、今あるもの・プロダクトの「そもそも」から疑い、あるべき価値・戦略を描き直すことを現在も実践しています。既存組織やオペレーションなど制約もある中で、私がどのようなスタンス・動きで「リビルド」を実現しているかをお話します。 2023.pmconf.jp 2024年と年明けになってしまいましたが、この記事では発表資料・録画を紹介し、発表時に寄せられた質問の一部への応答・補足説明をいたします。 発表資料 録画（YouTube） www.youtube.com Q&A Q.（転職して２ヶ月の方からの質問）リビルドできるのは新しく入ったPMならではというのに惹かれました。新しく入った状態で「情報を集めること」に苦労していると話されていましたが、どうクリアしましたか？ 誰しも今まで所属していた組織における「情報共有・蓄積の仕組み」があります。その中で慣れ親しんだツールや、情報の保存場所があるはずですが、新しい組織に入るにあたってはこれらをアップデートする必要があるため、まずは以下を理解することが大事です。 どこにどんな情報が蓄積されているのか（そもそもないのか） 誰がどんな情報を持っているのか 前者のどこにどんな情報があるかは、１ヶ月ほど共有フォルダ（BoxやGoogle Drive）を漁っていると分かるようになっています。PMは着任初日から会議等で忙殺されることはないので、時間にゆとりがある着任初期に、格納されている情報・データを漁ってみることをおすすめします。 個人的に後者をどう抑えるかは大事だと思っており、誰がどんな情報を持っているかを知り、その人と信頼関係を早めに作っておくことを心がけています。例えばプロダクトのデータを見たいのであれば、データサイエンティストやエンジニアにどんな情報が取れるかを先んじて確認しておく必要がありますし、業務理解をしたいのであれば業務設計者も業務担当者も接点を持たないといけないでしょう。すべてがドキュメント化されていることは稀なので、私は後者の「人」からの情報を積極的に取りに行くことでクリアしていきました（まだまだ知らないことが多いなと感じており、日々学んでおりますが）。 Q. ユーザーヒアリングする対象を選定される際（サンプリングの際）に気を付けていることや選定の基準などはありますでしょうか？ 自分の理解度と学びたいテーマによって変えていますが、以下のようにしています。 ①着任初期 前提：事業・顧客に対して解像度が低い状態 セグメントを定めずに無作為に顧客に会いに行く とりあえずランダムサンプルで10人/10社ほど行く ただし、事前にどのような顧客であるかは調査しておく 目的は業界、顧客、業務をざっと掴むこと（肌感を得ること） 質問事項は事前に用意するが、仮説を固めすぎない 基本調査（業務内容、顧客属性）を実施 業務観察は概要を把握するのみに留めて、細かい点は理解できなくてもOKとする ②着任してから約3ヶ月〜6ヶ月目以降 前提：ある程度ドメイン知識が付いてきている状態 ユーザー、顧客をある程度のロジックでセグメントを作る 例：大手/中小、都市部/地方部、ベテラン/若手、業界A/業界Bなど ターゲットと思われるセグメント（8人ほど）、違うであろうセグメント（2人ほど）とかでヒアリングを実施 違うであろうセグメントのユーザーヒアリングをする理由は、あくまでも確認程度 ①に比べると解像度はもう少し高くなっている 仮説と質問事項を用意する 仮説検証するためにヒアリングおよび観察を行う

エス・エム・エスが提供する介護事業者向け経営支援サービス「カイポケ」では、サービス停止も含めたプロダクトの「見直し」を継続的に実施しています。たとえば、2023年2月には、カイポケ内にて5,000法人が利用していた勤怠管理・給与計算機能をクローズし、株式会社マネーフォワードとの業務提携によって実現した「カイポケ会計・労務 by Money Forward」への一本化を進めました。 カイポケリニューアルプロジェクト が進む中で、介護業界の複雑性と課題の大きさを改めて認識するとともに、限りあるリソースの中でカイポケが本当にユーザーに届けたい価値は何かと問い続けた結果、その他にも、2022年度には7件のサービスや機能のクローズを実施、2023年度も上半期だけで7件のサービスや機能のクローズを実施しました。 プロダクト開発というと新規機能の追加に目が向きがちですが、リソースの確保、ひいてはユーザーにとってより価値あるプロダクトを提供していくという観点では、一部機能やサービスの終了について検討することも重要な取り組みといえます。ユーザーや社内をはじめとするステークホルダーへの説明など大変な場面が多いですが、なぜエス・エム・エスでは継続的に見直しの活動ができているのでしょうか。それによってもたらされる価値とは。カイポケの事業責任者である園田さん、経営企画としてプロダクトポートフォリオ・マネジメントを担う川合さんに聞きました。 よりユーザーに求められるプロダクトにするために ――カイポケの見直しに関する取り組みの概要を教えてください。 園田： 私がエス・エム・エスへ入社したのは2020年7月ですが、それより前からカイポケでは機能追加やサービス追加がされ、「40以上のサービス」というキャッチコピーからも分かる通り、機能やサービスが多い事が美徳とされているように見えました。しかし、カイポケのプロダクトマネージャーに各機能について話を聞くと、本当にユーザーに使われているのかわからない機能が多数あるという状況が明らかになってきました。そこで、カイポケの機能をリストアップし、それぞれに対して利用状況などのデータを1つずつ半年程かけて可視化していきました。すると、開発当時の予想に反して、実際は数十法人ほどにしか使われておらずクローズの判断をしたほうがよい機能や、数千の法人が利用しているもののサードパーティのサービスを利用したほうがよい機能などが多くあることがわかり、そのひとつひとつに対して、定量調査、定性調査、及びそのプロダクトが存在している文脈の調査を行い、①現状維持、②他サービスへの移管、③クローズ、の3つに分けて、それぞれ対応策を検討していくことにしました。 ▲これまでのカイポケの機能リスト一例 ――現時点では実際にクローズしている機能もあります。クローズも含めた見直しをする目的は何でしょうか？ 園田： 目的は、希少な開発リソースをサービス向上に向けて100%投下できるようにするためです。これまでは介護経営をあらゆる側面から支援する観点でなるべく多くの機能をプロダクトに搭載しようという方針でしたが、改めて見直してみると、なかには当社が提供することがベストではない機能もありました。たとえば、勤怠管理や給与計算のように、機能というにはあまりに大きいサービスは、その専門プロダクトを開発する企業のものを利用した方が、ユーザーとしては、日々メンテナンス・アップデートされる品質の高いプロダクトに触れることができます。10年前は選択肢が無くて違ったかもしれませんが、現状は他社のHorizontal SaaSを利用する選択肢も増えています。私たちとしては、介護業界に特化した機能に注力するほうが、よりユーザーに求められるプロダクトを作っていけると考えました。 そのようなプロダクトは、現実にはリソースが割かれない結果として、担当が割り振られず、運用やメンテナンスのコストは発生しているのにもかかわらず、障害対応のフローが定まっていなかったり、セキュリティ面での問題があったりという保守運用上の課題も発生します。エンジニアとしても、戦略の存在しないプロダクトを担当するのはなかなか辛いのではないかと思っています。 私たちは、介護業界に特化した機能に注力するほうが、よりユーザーに求められるプロダクトを作っていけると考え、そのためには、常に自分達がその機能開発のベストオーナーかどうかを問う必要があると考えています。 プロダクトドリブン組織へ転換していくうえで見直しは必至 ――カイポケの見直しの取り組みにおいて、苦労しているポイントがあれば教えてください。 川合： ユーザーと社内の双方に納得していただかなければならない点です。ユーザー視点では単に機能縮小と感じられてしまいますし、社内では財務的なインパクトはもちろん、営業のようにユーザーの対応に追われる部署もあります。これまでは、さまざまな機能があるからこその経営支援サービスという方針でプロダクトを開発してきましたが、これからは介護業界において本当に必要なものを提供していく方向性へと舵を切っていきます、という方針転換に納得してもらうストーリーをユーザー向け、社内向けに展開することが求められます。正直にいうと、やはり当初は社内からも大きな反発がありました。 ――抵抗感もあるなかで、どのようにして社内の理解を得ていくのでしょうか。 川合： なぜクローズをするのか、実際に現場でどのような対応が必要になるのかという具体的な進め方を丁寧に説明することが大事だと考えています。たとえば、ユーザーにとっては単なる機能縮小に感じる変更をどのように説明をするのか、ユーザーから値引き対応が求められた際にはどのように対応するのか、他社の代替サービスを紹介できるのか、カイポケ内にあるデータや帳票はどうなるのか、実際の移行オペレーションはどうなるのかなど、細かいところまで検討し、ビジネスのフロントがプロダクトのストーリーに納得するだけでなく、その中での自分たちの役割を具体的にイメージしてもらえるように準備をしていきました。 ▲社内向けの説明で用いた資料一例 園田：かつてエス・エム・エスは、セールスやマーケティングといったビジネスサイドの力が強く、プロダクト文化が弱い環境にありました。しかし今後は、ユーザーにとって本当に必要な機能をユーザー起点で考え、プロダクトドリブンで実現する方針を打ち立てています。そうなると、自ずとプロダクトポートフォリオの見直しをしていく必要が出てきます。それは、たとえ社内のどの部署から反発を受けようがゆるがない結論です。現在では、ビジネスとプロダクトが対等に存在し、お互い理解しようとするカルチャーが醸成されてきており、経営陣の理解も得られやすい環境ができてきているように思います。 なぜ5,000法人が利用する勤怠管理・給与計算機能を停止したのか ――勤怠管理・給与計算機能のクローズは具体的にどのように進めていったのでしょうか？ 川合： 背景としては、やはり勤怠管理・給与計算機能に対しては私たちがベストオーナーではないという考えが強くありました。細かいバグ対応なども発生していましたが、プロダクトの中心となるレセプト機能の対応が優先されるため、どうしても修正の優先順位が落ちてしまいます。また、勤怠管理・給与計算機能は毎年法改正への対応が必要になります。サービスとして中途半端なものになっているのに、維持するコストはかかり続けている状況でした。そこで、もともと当社がマネーフォワードと業務提携していたこともあり、同社と連携して同様の機能を提供できるようにする方針を決めました。 園田： ただし、対象となったのは非アクティブユーザーも含め約5,000法人。多くの方が利用する機能のため、ハレーションが起きることは容易に予想できました。サードパーティと連携するにも毎年数億単位でコストが増えるため、社内への合理的な説明が必要です。ユーザーからしても、これまでカイポケの機能の一部として使えていたものが有料化されることになりますし、サービスを移行すること自体への抵抗感もあります。 川合： 対経営層には、サードパーティ移行に必要な費用とその効果、そのままメンテナンスしつづけた際の費用やデメリットなども含め、最終的に事業成長につながるストーリーを組み立てて説明しました。実際、開発費用はほぼ減価償却されていて、現段階では費用がそれほどかかっていないというのも説明しづらいポイントでした。また、ユーザーに対しては、当社からの持ち出しにより移行先となるマネーフォワードのサービスを安価で利用できるようにすることや、セールスやカスタマーサポートを巻き込み、移行についての説明をこちらから電話を架けて行うことなどの対応を行いました。社内に対しては、会社、それを支える人・文化としてどこを目指しているのか、エス・エム・エスの価値観を基本路線にコミュニケーションを取ることを大事にしました。こうした対ユーザー、対経営者、対社内に対する説明がそれぞれ齟齬のないよう丁寧に説明することにも気をつけていました。 園田： マネーフォワードと連携したことにより、今後プロダクトは日々アップデートされ、長期で見るとよりよいものへとなっていきます。これはユーザーにとって価値のあることです。また、当社としては、より注力すべき領域へリソースを割り振ることができ、プロダクトマネージャーやエンジニアはより価値の高いプロダクトに集中して開発に取り組めるようになります。 ▲「カイポケ会計・労務 by Money Forward」 新しいものを生み出すためのプロダクトライフサイクルを実現する ――見直しがなかなかできていない企業も多くあるように思います。なぜエス・エム・エスでは、積極的に見直しに取り組み、筋肉質なプロダクト開発を実現できているのでしょうか？ 園田：戦略を考える際に、長期的な視点でプロダクトを見ていることが一番大きいです。これは、介護という市場規模も課題も大きく、かつ長期的に成長しているマーケットで、すでに多くのユーザーを抱えてある程度のビジネス規模を実現しているカイポケだからこそ言えることかもしれません。カイポケというプロダクトはこれから先もずっと提供されていくものですし、ユーザーもずっと変わらず存在していくはずです。こうした観点でたとえば10年後を見据えると、さすがにどこかのタイミングで見直さなければならないし、どうせやるなら早いほうがいいという考え方になります。 ――今後もカイポケの見直しには取り組まれていくのでしょうか？ 川合： はい。しかし、見直しだけがすべてではありません。さまざまな機能を追加していた過去の判断は、それによって「経営支援」というコンセプトがユーザーに受容され、事業成長できた面もあるので、現状だけを見て間違っているというのは少し違うと思っています。市場感をつかむためにまず機能追加をして様子を見てみるという方法も、プロダクト開発を進めるうえでは有効だと考えています。そのため、単純に機能追加をしていく姿勢自体を是正したいわけではありません。 そうではなく、各機能は、市場のニーズの変化や事業成長のフェーズにしたがって開発・運用・整理されるべきだと考えています。新しいものを生み出すための開発工数がきちんと担保されるよう、それが必要なものであるかどうかを適宜見直し、プロダクトライフサイクルをきちんと回していくことこそが重要な考え方だと思っています。注力したいところにリソースを投下できる状態をつくることは、結果としてよりよいプロダクト開発を可能としますし、その積み上げがユーザーの生産性向上などの価値につながっていきます。 ――カイポケを今後どのようなプロダクトにしていきたいと考えていますか？ 園田： ユーザーの課題を解決できる良いプロダクトとする事を起点に考える、という思想を今後も貫いていくことに尽きます。カイポケが対象としている介護・障害福祉領域には多くの課題があり、それに対して多岐にわたるサービスがあります。カイポケだけで解決できる課題ばかりではありませんし、ユーザーにとって課題解決の手段がカイポケである必要がないサービスもあると思います。ユーザーにとって価値あるプロダクトにしていけるよう、他社との連携も含めて課題解決ができる仕組みづくりが重要だと考えています。

はじめに 介護事業者向け経営支援サービス「カイポケ」のプロダクトオーナーをしている 岩下 真志穂 と申します。 入社して約４年間ビジネスサイドでセールス業務をしていたのですが、2023年中頃に入ってプロダクト開発の知識がほぼゼロに近い状態で異動をして、プロダクトオーナー(PO)をすることになりました。 どんな方に読んでほしいか そんな私がこの約半年間でどういう課題に直面し、それをどう解決してきたのかを本エントリーで共有したいと思います。この記事は ビジネスサイドや事業部での経験はあるが、全くの異職種へ未経験で転向した人の異動エントリが読みたい！ Vertical SaaSを提供しているエス・エム・エス/カイポケ事業において、プロダクトオーナーがどんなことをやる人なのか気になる！ ドメインエキスパートがプロダクトマネージャーを目指したいときに、どういうスキル獲得が必要なのか知りたい！ といった方に、何か一つでもお役立ちできればと思って書いています。 そもそもPO（プロダクトオーナー）とは？ エス・エム・エスではプロダクトマネージャー（以降PdM）とプロダクトオーナー(以降PO)をロール＝役割として区別しており、平たく言うと以下のような違いがあります。 PdM＝プロダクト全体（マルチプロダクト）のビジョンを明らかにし、成功させるためにチームをまとめる人 PO＝シングルプロダクトの開発においてユーザーのWhyを考える人 どちらも「いいプロダクトを作るために汗をかく人」という点では同じなので、エス・エム・エスとしてもそこに役職としての優劣をつけていないのですが、上記のように見ている範囲（マルチプロダクトか、シングルプロダクトか）に違いがあります。 また、実際に私が携わっているカイポケリニューアルプロジェクトにおいては、PdMはリニューアルするカイポケのプロダクト全体を見ているのに対し、POである私はその中の細分化された機能であるシングルプロダクトの「ケアマネアプリ」を見ているといった違いが出てきます。 なぜ社内転職を選んだのか ここまで読んでくださって「ちょっと待ってよ岩下さん！異動エントリと思ってこの記事読んでるんだけど！！」とお思いの方がいらっしゃるかもしれません。ご安心ください、今からその話をします。 先述の通り、元々ビジネスサイドに４年間いたわけですが、なぜ畑違いのプロダクト開発部に異動したのかというと、現場経験があるからこそ分かるユーザーの「不」（不便・不快・不満・不安）に対して、開発という分野からチャレンジしてみたくなったからです。 ユーザーのソフト面での「不」とこれからリニューアルするカイポケのハードの特性をフィットさせ、ひいてはユーザーにとってクリティカルな課題の解決をプロダクト自身を通してしていきたいと強く思うようになりました。 セールス視点から見たプロダクトへの「不」 「不」の例を挙げて説明します。 カイポケには請求ソフトとしての機能に加えて、経営状態を見える化するための機能の一つとして「売上管理」の機能があるのですが、この機能について以下のような「不」がありました。 現状：「売上管理」機能は月次でしか見れない 顧客ニーズ：日次で売上を把握したい 運用 提案：日次計算ができる売上シミュレーション（エクセル）を独自作成 「不」ポイント：複雑な加算が絡む介護請求においては「あくまで概算」のシミュレーションしか提供できない 実際に社内転職してみて 最初に感じたのは「安心」でした。 スクラムイベントや開発知識についてのオンボーディングの場があったこと、ワーキングアグリーメントが言語化されていること（これも新しい方がジョインされたらPOやプロジェクトリーダー主導でチームで議論しどんどんアップデートしていきます）、外部講師からの研修が設けられていること、などなど未経験でも安心できる体制があることはありがたかったです。 また、今あるプロダクトに対してユーザーのニーズを知っている人が開発部署に社内転職することは、プロダクトを開発していく上で価値があることだという実感はあります。自分の中に、ある意味ユーザーについてのビッグデータがある状態なので、開発サイクルで検証を重ねる際にも「どこに課題があるのか」や「どこをユーザー価値にするのか」が判断しやすいからです。 ドメイン経験があって社内異動を検討している方がいたら、自分の介在価値がどこにあるのか参考にしていただけたらと思います！ エス・エム・エスでの「社内転職」というキャリアパス 上記のような思いがあるものの、事業部経験者がプロダクト開発部へ未経験で異動する、というのは社内でもほぼ初めてでキャリアパスを開拓する難易度は高いだろうな、と予想していました。ですが、実際に具体的に動いてみるとそんなことはなく、事業部長の 園田さん は異動や新しいチャレンジは歓迎！という考えだったので、面談を重ねて異動が決まりました。（ちなみに、事業部側には” 部門の最高責任者とも誰でもカジュアルに1on1できる仕組み ”があって、そこでフランクに話せたのも良かったと思ってます。） ちなみに私の場合、社内転職に向けて以下のようなことを整理してみました。 自分が持っている課題は、今の部署では解決できないのか （具体的な打ち手を考えるとしたらどういうアイディアがあるか） 異動先の部署ではなぜその課題を解決できると考えるのか 異動後、今の自分が持っているどういうスキルが活用できそうか POの魅力 難しさを感じる部分 ビジネスサイドからの異動だったことで当初感じた難しさは「これまでと目標（仕事のゴールやKPI）が全く違う」部分でした。 ビジネスサイド：進捗管理（決められたKPI＝数字を達成する、タスクを早く終わらせる）が大事 プロダクト開発：プロセス管理（ベロシティはみるが量的には評価せず、不確実性を消しながら目指すゴールに向かえているかをチェックする）が大事 スクラムという概念を導入した結果、個人としての達成を目指すのではなく、スクラムを組んでチーム全体でスキルや知識を補いながら一緒にちょっとずつ進んでいくということを知りました。 また、開発知識・デザイン知識などが一定ないとスムーズに業務を進められないので、本やポッドキャストなどから常にインプットはしています。今はドメインモデリングの勉強をしているところです。 楽しさ・面白さを感じる部分 一方でやりがいを感じる部分もたくさんあります！ 新しい職種POに挑戦してみて、これまでの４年間に現場ユーザーと相対する中で「今のプロダクトでは解決が難しい」部分について考え続けていたことが、一つ一つ解消できていることに充実感と達成感を感じています。 特に、私が携わっているカイポケのリニューアルプロジェクトは「介護業界」というドメイン知識が高度に必要な分野のため、これまでの経験・知識を活かして、エンジニアやデザイナー向けの社内勉強会を定期的に開催しています。物事を型化することは元々好きだったのですが、それを勉強会という場で価値としてコンスタントに発揮できるのは嬉しいですし楽しいです。 エス・エム・エスならではの楽しさもあります。エス・エム・エスの事業内容は大きく４つ（ヘルスケア・医療・介護・シニアライフ）ありますが、カイポケと親和性が高い事業もあります。 外部に頼んだら時間もコストもかかるような調査がすでに行われていて結果を共有してもらえたり、会社のリソースを使った検証やナレッジ共有ができるのはすごいことだと思います。 逆に、カイポケ側からの情報提供もあります。例えば、アドバイザリー契約を結んでいるユーザーやそのコミュニティを活用し、シニアライフ領域のケアマネドットコムなど他事業部へ接点を繋ぐことでエス・エム・エス全体でプロダクトの改善に向けて動く取り組みもしています。 エス・エム・エスの事業領域と展開サービス まとめ 以上、この半年間の私の経験をもとに、未経験からの開発部への社内転職やエス・エム・エスにおけるPOという職種、カイポケリニューアルプロジェクトの取り組みを紹介させていただきました。 Vertical SaaS特有の課題を解決しつつドメイン知識やユーザー理解をしていくプロセスに疑問があった方や、全くの異職種への転向に不安を持っている方が、この記事を読んで安心感を持っていただけたら幸いです。

はじめに この記事は 株式会社エス・エム・エス Advent Calendar 2023 の 20 日目の記事です。 はじめまして、キャリア事業部でマネージャーをしている @kenjiszk です。2023年4月に入社し、はや9ヶ月目になりました。私は、エス・エム・エスのミッションである「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」がとても気に入っているのですが、特にお気に入りポイントである「社会に貢献し続ける」という部分について私の経験をもとに紹介できればと思っています。 ひとこと「社会に貢献し続ける」といっても解像度が荒いので、そのためにはどういったシステム、どういった組織、どういった事業であるべきかといったあたりが少しでも伝わると嬉しいです。 動くものではなく、動き続けるものをつくれ 遡ること十数年前、私は某ソーシャルゲーム開発会社のインフラエンジニアとしてキャリアをスタートします。タイトルにある言葉は当時の上司から頂いたありがたいお言葉です。簡単にいうと、作った時は正常に動いているのは当たり前で、作った後何年経っても正常に動き続けるものを作りなさいということなんですが、当時の私は右も左もわからず、サーバー構築やら何やらを行っていたので、ふーんくらいの気持ちで聞いていました。 そんなある日、作業ミスで割と大事なサーバーを落としてしまったのですが、予想に反してサービス全体は正常に動き続けていました。なるほど、上司が言っていたのはそう言うことね、と腹落ちした経験になります。 また、この時期にクラウドが利用され始めていて、作ったものは壊れる前提でシステム全体として健全に動かし続けるための工夫を学びました。 長期的な開発速度とは その後、ベンチャー企業で働き始めましたが、インフラ基盤としては前職の経験を踏まえてそれなりに堅牢なものを作っていたと思います。ですが、少し目線を広げるとそこには常に忙しそうにしている開発チームがいました。かなり忙しそうにしている割にはそこまで成果が出ていないような状況に見えましたし、実際に開発メンバーからは、短期的に最速の方法をとっていると思うけど持続可能ではない、といった意見も出ていました。 もちろんこれは当時私が感じた一部の側面であり、いろいろな観点で見た時の最適解であったのだろうと今では思っています。ベンチャー企業であればリリースしなければ死を待つのみですし、一時的にストレッチが必要な場面や気合いで乗り切らないといけない場面は多々あります。ですが、長期的に開発速度を出すにはもっと別の問題があるようにも感じていました。 ありがたいことに数年後、開発組織全体の責任者もやらせてもらうことになったので長期的に開発速度を上げるにはどうすると良いのかということをCTOやエンジニアリングマネージャーたちと議論できるようになりました。この時は、チームトポロジーの考え方を参考に「長期的に安定したチーム」による開発を試すことができ、その有効性も実感できました。 開発体制が良ければ大丈夫なのか 「長期的に安定したチーム」が作れて一安心かと思いきや、そういったチームが必ず売れるプロダクトを作れるかというとそんなこともありません。もちろん打率は上がると思いますが、市況、マーケット、さまざまな要因でプロダクトが売れないという状況を何度か体験しました。 「長期的に安定したチーム」が永続していくには、適切な市場選択や戦略などさらに上位の概念が必要になってきます。 PMFしていれば安泰なのか そんなことを考えている時に、ご縁があってエス・エム・エスに入社することになります。エス・エム・エスは19期連続増収増益という実績からもわかるように、伸びるマーケットで売れる事業を作り続けている会社という印象でした。一方で色々と話を聞くとシステム面や組織面の課題はいくつかあり、自分自身が経験してきたことでなんらかの貢献ができるのではないかと感じ入社することに決めました。 という目論見で入ったのですが、現実はそんなに甘くないというのが入社して9ヶ月経った感想です。マーケットで評価されているということは競合が多数出現するということ、10何年も継続しているということはユーザーの世代が変わっているということで求められるニーズが変化し続けていること、など事業・サービスのあり方というところでも常に変化が求められることを感じています。 今は、システム面、組織面を整えながら、今後どういったロードマップでプロダクトに改善を重ねると長期的に価値のあるものをマーケットに届けられるのかということに日々頭を使っています。 まとめ ということで、エス・エム・エス入社前後の経験を振り返りながら、「社会に貢献し続ける」ために必要なことについてつらつらと書いてみました。 経験上、インフラからアプリケーション開発、組織運用や事業へと視点や関心が移っているのですが、単純に事業に関心を持つべきと言ったような話ではなく全ての視点がそれぞれ大事で総合格闘技的な立ち回りが必要になると思っています。 それぞれの項目についてどれも大事でどれも外せない中でどうバランスをとりながら物事を進めていくか、というところに難しさと面白さがあると感じます。 サービスの可用性やセキュリティを担保するインフラ 安定した開発体制により継続的に生み出す開発速度 開発というコストを払うことで着実に積み重ねられる資産 マーケットや競合の変化に対応できる根本的な提供価値の追求 最後に、これらを進めるためには仲間がたくさん必要です！という気持ちなので一緒にこの課題に取り組んでいる人を積極募集しています！よろしくお願いします！

この記事は株式会社エス・エム・エス Advent Calendar 2023の14日目の記事です。 qiita.com カイポケリニューアルプロジェクトのバックエンドチームに所属している丸井です。 私のチームでは Spring for GraphQL を使ってバックエンドサービスを開発しています。監視基盤としては Datadog を利用していますが、トレースやGraphQL クエリ関連の各種メトリクスは java プロセス起動時に javaagent として dd-java-agent を指定することで収集がされています。 dd-java-agent を使うことでアプリケーションコードに何も手を入れなくても収集されるのはありがたいものの、どういう仕組みで動作しているのか分かっていなかったため調べてみることにしました。 ※ Datadog の Metrics メニューを開いてみると、GraphQL 関連のメトリクスが収集されているのが確認できる 参考: OpenTelemetry Instrumentation for Java の仕組み javaagent を利用してよしなに情報を収集するライブラリとしては他にもありますが、dd-java-agent と類似の位置づけのものとして OpenTelemetry Instrumentation for Java があります。 VA Linux エンジニアブログ: OpenTelemetry Instrumentation for Javaの自動トレースの仕組みの調査 という記事にその仕組みが解説されており、分かりやすかったので紹介します。 上記の記事にあるように、OpenTelemetry Instrumentation for Java(や dd-java-agent)は javaagent によってクラスファイルをロードする前にバイトコードを動的に変更して、一般的なライブラリやフレームワークからテレメトリを収集して監視基盤に送信している、というのが基本的な仕組みです。 dd-java-agent が自動的に収集する対象 dd-java-agent も一般的なライブラリやフレームワークをカバーしているため、導入するだけで情報が収集されます。 https://github.com/DataDog/dd-trace-java/tree/master/dd-java-agent/instrumentation 2023/12現在、収集対象は200を超えており、spring、tomcat、servlet など Web サービスに関わるものから、java.lang 系の一部のクラスなんかも含まれています 1 。 Spring for GraphQL が依存している GraphQL Java も対象となっており、そんなわけで GraphQL のクエリ情報が収集され Datadog に送信されています。 GraphQL Java の情報はどのように収集されているか ここからは GraphQL Java 用の instrumentation を見ていきます。 ちなみに instrumentation(計装)とは、 wikipedia: 計装 によると「生産工程等を制御するために、測定装置や制御装置などを装備し、測定すること」とあり、OpenTelemetry のドキュメントの Docs/Concepts/Instrumentation にもシステムを観測可能にするために実施するなにがしかのこと、という趣旨の説明が書かれています。 GraphQL Java の instrumentation コードは dd-trace-java リポジトリ内の /dd-java-agent/instrumentation/graphql-java-14.0 に配置されていますが、先に dd-trace-java の CONTRIBUTING.md: Adding Instrumentations を見てみると、 Must implement Instrumenter - note that it is recommended to implement Instrumenter.Default in every case. instrumentation の追加には Instrumenter の実装が必要とあるので、まずは Instrumenter から見ていきます。 GraphQL Java の Instrumenter 実装 GraphQL Java の Instrumenter は GraphQLJavaInstrumentation.java というファイルに実装されています。中を見てみると以下のように checkInstrumentationDefaultState というメソッドに対する Advice を適用しています。 @Override public void adviceTransformations(AdviceTransformation transformation) { transformation.applyAdvice( isMethod() .and( namedOneOf( "checkInstrumentationDefaultState" // 9.7+ // https://github.com/graphql-java/graphql-java/commit/821241de8ee055d6d254a9d95ef5143f9e540826 // "checkInstrumentation" // <9.7 // https://github.com/graphql-java/graphql-java/commit/78a6e4eda1c13f47573adb879ae781cce794e96a )) .and(returns(named( "graphql.execution.instrumentation.Instrumentation" ))), this .getClass().getName() + "$AddInstrumentationAdvice" ); } checkInstrumentationDefaultState というのは GraphQL Java に 実装されているメソッド で、GraphQL サーバー機能のセットアップ時に呼び出されるものです。 Advice を適用することで、上記のメソッドの呼び出し前後に処理を追加することが出来ます。 適用する Advice は以下のようになっており、GraphQL Java で作成された instrumentation を dd-java-agent 側で実装している GraphQLInstrumentation でラップして返すようになっています。 @SuppressWarnings ( "unused" ) public static class AddInstrumentationAdvice { @Advice.OnMethodExit (suppress = Throwable. class ) public static void onExit( @Advice.Return (readOnly = false ) Instrumentation instrumentation) { instrumentation = GraphQLInstrumentation.install(instrumentation); } public static void muzzleCheck() { // Class introduced in 15.0 ValueUnboxer value = ValueUnboxer.DEFAULT; } } 突然「GraphQL Java で作成された instrumentation」というのが登場していますが、GraphQL Java 自身も計装のための仕組みを備えており、起動時に instrumentation のためのセットアップがされるようになっています。 https://www.graphql-java.com/documentation/instrumentation/ dd-java-agent は「GraphQL Java で作成された instrumentation」をラップすることで Datadog 連携用の計装を追加している形になります。 GraphQLInstrumentation の実装 GraphQL Java の Instrumentation のラッパークラスの実装は こちら 。 GraphQL クエリの情報を収集する上で重要なのは以下の DataFetcher に関する箇所です。 @Override public DataFetcher<?> instrumentDataFetcher( final DataFetcher<?> dataFetcher, InstrumentationFieldFetchParameters parameters) { State state = parameters.getInstrumentationState(); final AgentSpan requestSpan = state.getRequestSpan(); return new InstrumentedDataFetcher(dataFetcher, parameters, requestSpan); } オリジナルの DataFetcher を dd-java-agent の InstrumentedDataFetcher でラップしています。 そして InstrumentedDataFetcher の実装は こちら 。 GraphQL クエリを処理する際に呼び出される DataFetcher#get に注目してみると、 public Object get(DataFetchingEnvironment environment) throws Exception { if (parameters.isTrivialDataFetcher()) { try (AgentScope scope = activateSpan( this .requestSpan)) { return dataFetcher.get(environment); } } else { final AgentSpan fieldSpan = startSpan( "graphql.field" , this .requestSpan.context()); // ...省略 dataValue = dataFetcher.get(environment); // ...省略 fieldSpan.finish(); // ...省略 } startSpan と finish が実行されることが読み取れます。 このように GraphQL クエリに対する処理を実行する前後に処理を追加することで、情報を収集していることが分かりました。 (ちなみに上記の箇所以外では、GraphQL クエリの parse や validation に対する情報が収集されていました) まとめ dd-java-agent や OpenTelemetry Instrumentation for Java は javaagent を利用することで一般的なライブラリやフレームワークに対する自動 instrumentation を実施 GraphQL Java に対する instrumentation は GraphQL Java 側に実装されている checkInstrumentationDefaultState メソッドに Advice を適用して実装を差し替えることで実現 java.lang 系の instrumentation を覗いてみたところ、脆弱性検出のためのコードを含んでいました。(例: java.lang.Math.random の呼び出しの監視 ) ↩

この記事は株式会社エス・エム・エス Advent Calendar 2023の13日目の記事です。 qiita.com はじめに 介護事業者向け経営支援サービス「カイポケ」のQAを担当している中村です。2021年10月に入社して早2年、現在ではQA組織の運営や横断的に複数QAチームに関わりつつ、チームのサポートや改善活動の推進など様々なことを担当させてもらっています。 今回の記事では改善活動で実施した施策の一つである、『E2Eテスト自動化の導入』をテーマにどんなテストを自動化しているか？どんな運用をしているか？など、現状を整理する形でお話ししていきたいと思います。ここでお話しするのはあくまでQAエンジニアの取り組みの事例で、開発エンジニアが実施しているUT（ユニットテスト）などの自動テストは触れませんのでご了承ください。 テスト自動化のお話し 1. どんなツールを使っているのか？ 弊社では MagicPod というノーコードのテスト自動化ツールを使用しています。ツール選定の主な理由は以下の通りで、約2年ほど使い続けています。 プログラミングスキルが不要で開発未経験でも導入が容易 テストの実行回数に制限が無く費用を気にせず繰り返しのテストが可能 ローカルPC上でテスト実行が出来るのでプロキシサーバーを介してWEBアクセスが可能 SaaSサービスなので環境構築、保守の手間が不要 2. どんなテストを自動化しているのか？ 担当している「カイポケ」では、主にWEBとネイティブアプリ(iPadOS)にサービスを展開しています。現状はWEBを対象にE2Eテストの自動化を進めていて、メンテナンスコストが掛からないように機能や画面に変更が入りにくい部分のリグレッションテスト（機能の追加や改修が入った際、既存機能に問題が起きていないかを確認するテスト）を対象としています。全機能を網羅するとテストケースが膨大になるのでハッピーパスなどの基本機能のテストに絞っていて、バグを見つけると言うよりはシステムが問題なく動作することの確認を目的としています。 3. どんな工夫をしたのか？ 過去の経験から実装/メンテナンスコストの増加、属人化、テストの安定性といったところの課題を感じていたので、以下の取り組みをすることでよりスムーズに導入出来るように進めていきました。 テスト実装/メンテナンスコストの削減 MagicPodが提供している以下の機能を活用して実現しています。 共有ステップ（共通化） 複数のテストで使う処理は基本的に共通化 参考： 共有ステップの活用 変数 テストケースやテスト環境によって値が変わるデータやロケーターは変数を使用 参考： 変数の活用 データ駆動テスト 計算結果を確認するようなテストでは、同じテストケースでデータパターン（入力値や期待値）を変えて繰り返し実行をしている 参考： データパターン(データ駆動テスト)の活用 属人化対策 実装者によってテストの書き方が大きく変わらないことや導入がスムーズに行えることを目的とした、実装方針や最低限のルールを記載した手順書を用意しました。以下は手順書の記載例となります。 共通化、変数の使いどころ テストの組み込み方法 コメントの使い方 命名規則（テストケース、共有ステップ、ロケーター） ロケーターの指定方法 テスト実行の安定化 テストの独立性 基本的に他のテストの影響を受けてテストが失敗することを防止するために、テストケース同士の依存関係は無くして、各テストケースが独立して動くように作成しています。また、テストを再実行した際にクリーンな状態でテストが行えるように後処理（テスト中に登録したデータの削除など）を実施しています。 リトライ 不具合ではなくタイミングや不確定要素によるテストの失敗は自動テストのあるあるなのですが、都度テストを再実行するのではなくMagicPodが提供しているリトライ機能を使って自動で再実行する仕組みを取り入れています。途中でテストが失敗した場合に元の状態からテストが出来るように初期化（テスト中に登録したデータの削除など）も実施しています。 実行環境を仮想環境に移行 主にローカルPC上でテスト実行をしているのですが、ブラウザの操作をツールに奪われてしまうので作業が中断してしまう、リモートワーク主体の中でも安定したネットワーク接続が必要（瞬断でもテストが止まってしまう恐れあり）といった課題があり、それに対応するためにテスト実行環境を仮想環境に移行し安定して動作するようにしました。 4. どんな運用をしているのか？ 現状はシステムに改修が入った場合やミドルウェアのバージョンアップが入った場合などに自動テストを実行するようになってきて、活用する機会がかなり増えています。簡易的な動作確認であっても、今までは時間をかけて手動で実施していた or 時間の都合により割愛せざるを得なかったのですが、素早く人の手を介さずに毎回テスト出来るようになったことで、より品質に自信を持って高速リリースが出来る状態となったのは大きな利点だと考えています。 5. 現状の課題は？ 上述したとおり導入は進められているのですが、課題もまだ残っていて現在進行形で進めている点や今後実施予定としている点をいくつか紹介していきます。 他チームへの拡張 現状は特定のチームでのみ導入が進んでいる状況です。人的リソースやスキル的な課題もあって十分に導入が進められていないのですが、リグレッションテストの使用頻度はどのチームでも高いので少しずつ範囲を広げていきたいという思いがあります。 定期実行の導入 定期実行自体はMagicPodの機能として提供されているのですが、「クラウド」実行のみ使用が可能となっています。前述した通り、弊社は「ローカルPC」での実行をメインとしているので、定期実行を実現するには自前で仕組みを作る必要があるのですが、まだ手を掛けられていないという状況です。 テストの高速化 テストケースが増えたり長くなると、相対的にテストの実行時間が増えてくるといった課題が出てきています。テストケースの見直しや並列実行の仕組み化などやれることがありそうなのですが、こちらもまだ手を掛けられていません。 さいごに 前述の課題対策に加え、開発チームとの協業/分担なども考慮したテスト自動化の最適化も必要になりますし、並行して始まっているリニューアルプロジェクトへの本格導入とまだまだ先は長いです。テスト自動化に関わる人手も今以上に必要になってくることを想定していますので、一緒に働く仲間は絶賛募集中となっています！ 最近QA組織の行動指針なるものを構築したのですが、テスト自動化もその中の取り組みの一つとなっています。そちらのブログも合わせて確認していただけると、QA組織の目指しているものがより見えてくるのではないかと思います。 tech.bm-sms.co.jp 少しでも興味を持たれた方がいたらカジュアル面談や選考へのご応募をよろしくお願いいたします。 エス・エム・エス-エンジニア採用情報 ソフトウェアエンジニア カジュアル面談(PM/EM/SRE/QAも歓迎)

この記事は 「株式会社エス・エム・エス Advent Calendar 2023」 の12日目の記事です。 こんにちは、Analytics&Innovation推進部（以下、A&I推進部）の小貝（ @oddgai ）です。 M-1グランプリの決勝が近づいてきて、今年ももう終わりか〜としみじみしています。 今年は夫婦で真空ジェシカ、令和ロマン、ヤーレンズ、敗者復活でななまがりを応援しています。がんばれ！ さて、社内のデータ活用チームであるA&I推進部にデータサイエンティストとして新卒入社して4年目になるのですが、今年の4月から 「カイポケ」のフルリニューアルプロジェクト のエンジニアチームに社内留学してアプリケーション開発も行っています。12月時点だとデータサイエンティスト1割、エンジニア9割くらいの割合で働いています。 この記事では、今年を振り返って なんで/どうやって社内留学したの？ 開始から今までにやってきたこと やってみてどう？ あたりをまとめようと思います。 なんで/どうやって社内留学したの？ 社内留学した理由を一言でまとめると、 今後のキャリアや社内での役割を見据えて、ソフトウェア開発の基礎的な経験を積んでおきたかったから です。これだけ書くと立派に見えますが、もう少し心の内をさらけ出して書くと下のようになります。 研修などでソフトウェア開発の体系的な知識を付けないまま新卒4年目まで来てしまい、 「同世代のデータサイエンティストが当たり前に知っているであろうことを知らない気がする」という焦り があった データサイエンティストとしてエンジニアとやり取りすることも多いが、あまり勝手がわかっていなかった 数理最適化や機械学習などのモデルは最終的に何らかのシステムに組み込まれることも多いので、ソフトウェア開発の知識や経験があったほうがいい 大きな環境の変化がないまま4年目になり若干だれてきた感があったので、何かしらの外的変化がほしかった このようなもやもやがあったので、3年目の終わりの考課面談で上長に相談してみました。周りに社内留学をした人がいなかったのもあり、このときは留学という発想はなく「何かしらの研修を受けさせてもらえたらいいな」くらいの気持ちでした。 そこからあれよあれよという間に話が進み、気づいたらエンジニアチームにいました。裏ではいろんな人が動いてくれていたのだと思いますが、私目線だと下のようなスケジュールになっていて、このときは正直このスピード感に心が追いついていませんでした。 2023/3/8: 考課面談で「開発経験が積みたい」と相談する 2023/3/24: 技術責任者の田辺さん（ @sunaot ）と面談して社内留学ができる説を知る このときは「やるにしても半年後くらいでしょ」と思っていた 2023/4/24: 受け入れ先チームの空中さん（ @soranakk ）達と面談する ここで「アッこれすぐの話なのか」と気づく 2023/4/28（その4日後！）: チームのモブプログラミングに参加して、以降ほぼフルコミット 開始から今までの振り返り こんな感じでいきなり始まった社内留学ですが、現時点で開始から7ヶ月くらいになるので、今までをざっくり振り返ってみます。 開始〜1ヶ月目：プロジェクトのことを知る期 最初にプロジェクトやチームに関わるいろんなドキュメントをもらったので、そのインプットから始めました。カイポケがリニューアルするのは知っていたのですが、その背景や具体的にやっていることまでは把握していなかったので、そこを埋めるようにドキュメントを消化していきました。 介護業界に関わるドメイン知識などはすでにあって、それに関するつらさがほぼ無かったのは社内留学のいいところだなと感じています。 ちなみに当時の私はこんな資料を残しています（A&I推進部内での報告資料です）。右下のE資格というのは日本ディープラーニング協会が実施している資格試験のことで「開発の勉強もしたいけど資格対策もしないと〜〜〜」と大変な状況でした。がんばれ！ 2〜3ヶ月目：バックエンドがんばる期 プロジェクトやチームの動きがある程度わかったところで、実際の開発タスクに手を付け始めます。 ちょうどその頃に着手予定になっていたバックエンドAPI実装をやったのですが、KotlinやSpring Bootを触ったことがなかったので、モブプログラミングで大いに助けてもらいながらなんとか実装しました。 モブプロはオンボーディング関係なくほぼ毎日やっているのですが、これが経験の浅い私にとっては本当にありがたくて、開発の勉強になるだけでなく「昨日〇〇がおいしかった」などの雑談も挟まるため チームの一員になっている感 があり、何もわからん状態だった私は精神的に救われました。やはり雑談は大事。 このAPI実装が終わった後に、チーム全体で別チームのバックエンド開発を手伝うことがあったのですが、そこまで難しくないタスクだったこともあり基本的には独力で進めることができて「なんかイケてるぞ」という自信に繋がりました。 また、この時期にはデータサイエンティストとして、求人のレコメンドAPI開発のプロジェクト管理もしていました。その際、エンジニアチームに依頼してAPIをサービスに組み込んでもらうタイミングがあったのですが、前よりもエンジニアの気持ちがわかるようになっていたからかスムーズに依頼ができて「 データサイエンティストとしてのスキルアップにも繋がってるぞ！ 」と嬉しくなりました。 ちなみに当時の気持ちはこんな感じだったようです。えらいぞ！がんばれ！ 4〜6ヶ月目：フロントエンドも触ってみよう期 バックエンドがチョットワカルようになってきたので、フロントエンドにも手を出し始めます。 最初は、当時タスクとして挙がっていた氏名入力フォームなどでの姓名分離（バックエンドは対応済みで、画面側の対応）をやりました。 ここでStorybookやChromaticに初めて触れたのですが、「画面がチェックできる！！すごい！！」と感動しました。成果物として実際に動く画面が見られるのは楽しいです。 次に手を出したタスクが当時の自分としてはやや難しく、というのも 最初の仕様ではそこまで難しいタスクではなかった 途中から仕様変更があり、チーム内で触ったことがないコンポーネントを扱うことになった 🤯🤯🤯 という変貌を遂げたもので、フロントエンドチームにも助けてもらいながらなんとか終えることができました。今振り返ると、デザイナーや別チームのエンジニアとやり取りしながら開発する経験ができたのでとても良かったです。 7ヶ月目〜現在：どんどんタスクを拾っていこう期 バックエンド、フロントエンドともに何となく進め方がわかってきたので、引き続き助けてもらいながらもどんどんタスクを拾っています。 積まれているタスクをやるだけでなく「ここの画面ちょっとおかしいですね→後で直しておきます」のような動きもできるようになり、「 俺は！！エンジニアとして働いているぞ！！ 」という実感があって楽しいです。 一方で、個々の開発タスクで得た知識や経験を有機的に結びつけられていない感覚もあるので、改めて体系的に基礎を学びたいです。 まとめると今の気持ちはこんな感じです。いいぞ！ やってみてどう？ 最初は「開発のことなんもわからん」「チームの雰囲気に慣れない」などで大変でしたが、振り返ると本当に良い経験をさせてもらっているなと思います。 具体的に良かったことは挙げるときりがないのですが、ぱっと思いつくだけでこのくらいあります。 経験が浅いところからのスタートというのもあって「先週できなかったことが今週はできるようになっている」が続いて楽しい データサイエンティストとしてのスキルアップにも繋がっている 社内でカジュアルにコミュニケーションできる人が増えて嬉しい モブプロ や 社内版potatotips などの文化がとてもよい エンジニアとの距離が縮まりテックブログへの投稿が増えた このアドベントカレンダーもそうだし、去年なら 「学会に出るから発表資料を公開しよう！」 という発想にはならなかった気がする 外からは見えにくいエンジニアの大変さがわかって、もっとリスペクトが湧いた いつまで社内留学を続けるのか具体的なスケジュールは未定ですが、もっとエンジニアとしてのスキルを伸ばしたいのと、このプロジェクトにもう少し関わっていたいので、もう少し続ける予定です。 おわりに 改めて振り返ると、慌ただしかったですがとても良い刺激を受けた1年でした。 最後になりますが、社内留学のために動いてくれた方々や、日々助けてもらっているチーム内外のメンバーには感謝してもしきれません。本当にありがとうございます！ 弊社では、データサイエンティストやエンジニアの採用を積極的に行っています。興味をもっていただけた方はぜひカジュアル面談にお越しください！ データサイエンティスト(AnalyticsTranslator) / 株式会社エス・エム・エス ソフトウェアエンジニア カジュアル面談(PM/EM/SRE/QAも歓迎) / 株式会社エス・エム・エス