こんにちは。介護事業者向け経営支援サービス「カイポケ」でエンジニアリングマネージャーを担当している橋口( @gusagi )です。 今回は、少し前にカイポケの訪問看護チームで行った「システム障害対応訓練」について紹介します。 なお、システム障害対応訓練に関しては、今回の記事だけでなく裏側を中心に紹介する記事を掲載予定です。 今回の記事ではやったことを中心に紹介させてもらい、別の記事では準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する予定です。そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。 きっかけ 訪問看護チームでは、テックリードを中心とした体制で開発・運用を行っています。 この体制は現時点で機能していますが、ある時のふりかえりで「テックリードが不在の時に何らかの問題が起こったとしてもうまく連携して対応することができるか？」という指摘が上がりました。 テックリードが不在となった場合に心配なことは何かを具体的に挙げていったところ、票が一番多く集まったのがシステム障害が発生して対応を行う時でした。訪問看護チームではシステム障害対応のガイドラインも策定していたのですが、その中で対応時の指揮官（インシデントコマンダー *1 ）を毎回担っているのがテックリードであったため、不在の時にチームが同じように動けるのかが不安要素として挙がったのです。 特に、以下の課題に関しては早い段階で手を打つ必要がありそうでした。 テックリード以外にインシデントコマンダーを担える人がいるかが分からない チームで行う対応がインシデントコマンダーの判断・指示に依存している QAチームとの連携がスムーズにできていない そこで「テックリードが不在の時のシステム障害対応」という課題に対する対応案として、表題にもあるシステム障害対応訓練を実施するという取り組みがスタートすることとなりました。 このシステム障害対応訓練において期待する効果は以下です。 短期・直接的な成果: 障害対応の解像度を上げる インシデントコマンダーを担える人間を増やす 中長期的な期待: 各人がシステム障害対応に主体的に関われるようなチームへの成長 やることが決まるまで システム障害対応訓練を行うということを決めて、そこからどんな内容にするかをチーム内で考えていく流れとなりました。 企画に名乗りを上げてくれた若手エンジニア２名を含めて打ち合わせをして、大枠として以下のことが決まりました。 お客さまからのお問い合わせをトリガーとして、問題の調査や解決を進める流れとする 実際にシステム障害を起こしたりはせず、チーム内でシミュレーションを行う形とする ただし、ログや各種メトリクスの調査は、ある程度まで実際にやってみる そのシーンで実行できるアクションは選択肢を提示しつつも、それ以外にも参加者が考えて何をするか決めて良い インシデント時のガイドラインに則って専用のSlackチャンネル作成なども行う チーム外に不要な混乱が起きないよう、事前の周知を徹底する他、当日のSlackチャンネル名などにもシステム障害対応訓練であることを明記する 上記を満たす方法を検討した結果、テーブルトークRPG（TRPG） *2 の形式を取るのが良さそうだという話になりました。 TRPGとは、ゲームマスター（GM）と呼ばれる進行役と、プレイヤー（PL）と呼ばれる参加者で協力して会話をベースとして物語を進行させていく遊びです。 実際には起きていないシステム障害に対するシミュレーションで、選択肢にない参加者の行動も柔軟に拾っていくことを考えた結果として、TRPGが良さそうだとなりました。 TRPGの形式が良いと判断した主な理由は以下です。 リモートワーク中心の状況で実際にシステム障害に対応する場合でも、複数人で会話をしながら対応を進めることが予想されるため、近しい状態で訓練することができる シミュレーションによる訓練となるため、進行役としてGMが存在する方が柔軟に対応できる 訓練だからこそ、少しは遊び心を入れて楽しみながら取り組めるようにしたい また、企画に名乗りを上げてくれたエンジニアがどちらもTRPGを知っていたこともスムーズに方針が決まった一因になったと思います。 当日までの準備について まずは発生したとするシステム障害の内容と大枠のシナリオを決めることとしました。 訪問看護チームは、介護事業者向け経営支援プラットフォーム「 カイポケ 」のうち訪問看護の領域を開発・運用しています。従って、カイポケのサービスにおいて特にお客さまへの影響が大きく緊急性の高いシステム障害が発生したと想定する方が望ましいと考えました。 そこで、発生したシステム障害の内容を決めた上で「一部のお客さまから『診療報酬明細書（レセプト）が出力できない』というお問い合わせが来た」という状況からシナリオが始まるようにしました。 なお、シナリオにはフラグによってエンディングが分岐する仕掛けを入れておき、GoodエンドからBadエンドまで何種類かのエンディングを用意しました。 また、TRPGを知らない・詳しくない参加者がいることが予想されたため、企画に参加しているエンジニアのうち片方の人にGM役を、もう片方の人には参加者として他の人のフォローに入ってもらうことをお願いすると共に、参加者の人にはシナリオを伏せた状態で準備を進めるようにしました。 合わせて「ハンドアウト」と呼ぶ事前資料を用意して、目的を意識して訓練に臨んでもらえるようにしました。 ハンドアウトではシステム障害対応訓練の目的や進め方の説明と合わせて、TRPGに不慣れな人向けのロールプレイの説明や会話をしながら進めることの必要性なども記載しました。また、トレーラーと呼ぶようなシナリオの予告ストーリーも載せておき、訓練ではあるもののゲームとして楽しめるような遊び心も盛り込ませてもらいました。 当日の実施レポート 当日は、まずは訓練会場として用意したZoomに集合してGMから改めて当日の流れを説明しました。 その後、実際のお問い合わせを模した形で内容をJIRAのチケットとして起票し、Slackで運用担当者への確認依頼をGMから伝えて、訓練開始となりました。 初めてのシステム障害対応訓練、かつTRPG風というアレンジが入っていたことで、訓練の途中にルールへの質問が入ったり、対応に関する相談が想定以上に盛り上がり時間が押してしまうというハプニングもありましたが、PdM・エンジニア・運用・QAといった日頃の役割を超えて意見の交換が行われており、概ね成功したと言えるのではないかと思います。 なお、最後は駆け足気味になっていましたが押さえるべき観点をしっかり押さえた対応を行えており、シナリオの結果として一番良いエンディングに到達することができていました。 訓練の最中にも「このペースで問い合わせが来ているの、相当ヤバい状況だね」「どう動いたら早く・確実にこの事象を解消できそう？」という会話が出ており、訓練を通して参加者がしっかりとシステム障害対応に取り組むことが出来ていたのではないかと思います。 振り返りについて 訓練結果を有効に活用するため、訓練直後に簡単なアンケートに協力してもらい、その内容を事前に共有した上でYWT形式でふりかえりを行いました。 アンケートの回答では、訓練を実施したことそのものに対する好意的な意見、訓練を通して得た気付き、訓練の進め方に関する改善の提案、今後の希望など多くの回答がありました。 また、アンケート結果を踏まえてのふりかえりでも、書き出しの時間をそこまで取ることが出来なかったにも関わらず、想像を大きく超える数の付箋が書き出されました。内容も、やったこと(Y)よりも、そこからわかったこと(W)や次に行うこと(T)の数が圧倒的に多く、この点からも、参加者にも楽しんでもらうと共に、システム障害対応訓練で気付きを得てもらうことが出来たのではないかと思います。 公開できない情報もあるためお見せすることができないのが残念なくらいでした。 あとがき ここまでで、訪問看護チームで行ったシステム障害対応訓練でやったことの紹介は終わりとなります。 ですが、冒頭にも書いたように、準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する別の記事も準備していますので、そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。 *1 : インシデントコマンダーについては Asanaの記事 や Atlassianの記事 が参考になります *2 : TRPGに興味のある人は 富士見書房さまによる紹介ページ や Wikipediaの記事 もご覧ください

この記事は、「株式会社エス・エム・エス Advent Calendar 2023」3日目の記事です。 qiita.com 介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。 私が所属しているチームは、介護事業所の業務のなかの一部の領域を扱う箇所の開発を担当しています。最近、このチームの置かれている状況に変化があり、それに伴って（他にも様々な変化が必要になっているのですが）ドキュメンテーションについての方針転換がありました。この方針転換は、私個人にとってもこれまでの働き方を一部改めるきっかけになるものでしたので、今回の記事では、その方針転換について紹介したいと思います。 これまでのチームの状況 私たちのチームが担当している領域のシステムは、大雑把にいうと、ユーザーが触るアプリケーション（サーバーサイドレンダリングをベースとする典型的なWebアプリケーション）と、その更に裏側で動作するバックエンドのアプリケーション（WEB API+非同期処理を担うワーカー）の2つの部分に分かれています *1 。 私たちのチームが担当する業務は、カイポケの他のコンポーネントで作られたデータを入力とするのですが、基本的にはこれらの2つのコンポーネントで完結します。したがって、カイポケの他のチームのメンバーは私たちのチームの担当する業務ドメインについての知識をほとんど持つ必要がなく、ユーザーから見える仕様もこれら2つのコンポーネント間のAPIの仕様もほぼ自由に変更することができました（もちろん仕様を変える際は対ユーザーのコミュニケーションは不可欠ですが）。この自由度を活かして、新しい機能を追加したり、そのために内部API仕様を変更したりを活発に行なってきました。 カイポケリニューアルプロジェクトの進行に伴う状況の変化 しかし、ここ数ヶ月の間で、状況が変わってきました（予定通りではあるのですが）。それは以前から動いているカイポケのリニューアルプロジェクトの進行に伴うものです。 careers.bm-sms.co.jp このリニューアルプロジェクトでは、既存システムとは別の新システムを開発しており、私たちのチームが担当する業務ドメインについても、別のチームが開発をしています。しかし、先述の2つのコンポーネントのうち、 後者のバックエンドのアプリケーションについては、既存システムと新システムとが共用します 。リニューアルプロジェクト側では、ユーザーが触るWebアプリケーション *2 だけを新規開発し、そのアプリケーションから私たちのチームのシステムのWeb APIを利用するわけです。 この状況の変化により、 これまで私たちのチームだけが知っていれば良かった知識の一部を、他チーム（リニューアル側の開発チーム）にも知ってもらう必要が出てきました。その中には、業務ドメインに関する知識と、内部APIの仕様の知識の両方が含まれます 。このことが、ドキュメンテーションの方針に変化を強いることになります。 これまでのドキュメンテーションの考え方 基本はチーム内向けのドキュメント 私のチームでは、ドキュメンテーションツールとして esa を主に利用しています。esaはMarkdownで書くことのできるツールで、個々の記事がバージョン管理されるほか、 フロー情報とストック情報を分ける機能 などがあります。esa以外には、ソースコードに近い情報はGitHubリポジトリ上のコメントやREADMEなどで記述しているほか、内部APIの仕様についてはOpenAPI Specification（コードから自動生成しています）から作成したドキュメント *3 があります。 このうち、内部APIの仕様についてはチーム外の人が見ることを意識していましたが、esaに書かれるドキュメントについては基本的にチーム内の人（未来の自分たちを含む）が読むことを想定して書いてきました。もちろん仕事をしている中で別のチーム（開発チーム以外を含む）に向けて情報共有をすることはありましたが、そのときに適切な情報が伝わればよいケースがほとんどで、メンテナンスされるようなドキュメントとして書いていなかったり、必要が生じたタイミングで書くという形で書いていたため網羅性の乏しいものになっていました。 読み手としてチーム内の人を想定する場合の考え方 読み手としてチーム内の人を想定する場合、ドキュメントを書く際に意識することは少なくて済みます。まず、チーム内の人であれば、コードを読むことで得られる情報など、既に関連する部分の知識を持っていることを前提としてドキュメントを書くことができます。コードを読んだ方が正確に・詳細に把握できる事項についてはドキュメントを書かないでおく選択を取ることもできます。 また、（新規参画したメンバーは別ですが）過去の経緯がある程度頭に入っていることも期待できるので、ある時点で書かれたフロー情報的なドキュメントを見たときにそれが書かれた文脈を想像してもらいやすいですし、必要に応じてgitの履歴やGitHubのPull Requestの履歴とも紐付けて読んでもらいやすくもあります。 このような背景から、ドキュメンテーションに対する考え方は、（チームとして明確に意識していたわけではありませんが） 「多少読みづらくてもよいので、とにかくたくさん情報を残しておく」 という方に寄っていたように思います。また、私個人の経験としても、チーム開発におけるドキュメンテーションの最初の壁は「共有されてもいい情報がドキュメンテーションツール上に書かれない」ことだと感じていたので、「書くハードルを下げる」「些細なことでもとにかく書いておく」ということを重んじてきました。個人で何か作業をしたときや調査をしたときも気軽にドキュメンテーションツールに書いておくことで、他のメンバーや将来の自分の参考になる情報をなるべく増やすという考え方ですね。現在のチームの前に所属していたチームでは、この考え方に基づいたプラクティスが上手くワークしていたこともありました。以下の記事で紹介している「転ばぬ先の杖」がそれです。 tech.bm-sms.co.jp 「書き手の書きやすさ重視」のアプローチ このアプローチは、「書き手の書きやすさ重視」のアプローチということもできます。もちろんドキュメンテーションはそもそも読み手のためのものなので、書き手の書きやすさを重視することも究極的には読み手のためではあるのですが、読み手にとっての利便性のうち、情報量を増やすことにフォーカスしており、「簡単に情報にアクセスできる」「わかりやすく情報がまとまっている」という部分は犠牲にしている側面があります。読み手は検索やリンク（esaにはバックリンクを表示する機能もあります）の機能を駆使してドキュメントを「漁る」ことで、必要な情報を得ることになります。 生じてきた課題 しかし、先述の状況の変化により、課題が出てきました。 チーム外向けのドキュメントだけでは足りない まず第一に、従来からチーム外向けを意図して書いていたドキュメントでは、全く情報が足りないということを本格的にリニューアル側の開発が始まってから痛感しました。これは見立てが甘かったと言ってしまえばそれに尽きるのですが、どう想定と違ったかを少し紹介したいと思います。事前のイメージは「Web APIのクライアントとなるリニューアル側の開発チームは、OpenAPI Specificationベースのドキュメントと、それを補足するようなドキュメントがあれば開発できるだろう」というものでした。しかし実際に開発が始まってみると、私が想定した以上に細かく、実装に近い仕様や業務ドメインに関する知識を質問されることが多かったのです。 内部APIのモジュールとしての性格 こうなってしまった理由を考えてみますと、私たちの開発している内部APIのモジュールとしての性質に思い至ります。私たちのチームで開発していた内部Web APIは、情報の隠蔽を志向しているというよりは、クライアントであるユーザー向けのWebアプリケーションで求められるユースケースを最大限実現できるようにすることの方を優先して作られていました。 もちろん、内部APIとして切り出す意味がある程度の複雑な機能をAPIの裏側に持っている（データベースやオブジェクトストレージ、KVS、非同期処理を実現するためのメッセージキューなども独自で持っています）のですが、非同期処理の過程のステータスの遷移などの情報はあまり隠蔽せず、APIで露出させることでクライアント側で画面に表示したり制御に利用したりできるようにしています。 『A Philosophy of Software Design』 における表現を使えば、「機能は多いが、インタフェースも多い（複雑な）」、DeepともShallowともいえないモジュールだということです。『A Philosophy of Software Design』については、以前個人ブログの方に書いた記事や、NTTコミュニケーションズ社のブログ記事も参考にしてください。 ky-yk-d.hatenablog.com engineers.ntt.com チーム外の人も、API仕様以上の知識に関心がある このようなモジュールとしての性質から、クライアントの開発者はこの内部APIを使って開発をする際に、かなり多くの知識にそもそもOpenAPI Specificationベースでドキュメント化されているAPI仕様の段階で触れることになります。その上で、そこに露出している知識を最大限に理解した上で実装をしようとすると、OpenAPI Specificationでは書ききれていない情報、ほぼ実装の詳細に関わるような内容や、背後にある詳細な業務知識までも知りたくなってしまうようでした（そもそも私たちのチームではそこも把握した上でユーザーの触るWebアプリケーションを実装しているわけです）。 チーム内向けとして書かれていたドキュメントをチーム外の人が読む チーム外に向けて書いていたドキュメントだけでは足りないとなると、他チームのメンバーとしては個別に私たちに質問するか、私たちがチーム内向けに書いたドキュメントを読むかして情報を得ようとします。私たちのチームとしてもリニューアルプロジェクト側の開発が滞りなく進むように支援することの優先順位は高く設定しているので、もちろん質問してもらっても大いに構わないのですが、すぐに応答できないこともありますし、双方にとって効率的でないこともしばしばです。したがって、やはりドキュメントで完結する部分を増やすことは重要になります。 チーム外の人にはチーム内向けのドキュメントは理解しづらい それでは、チーム内向けとして書かれていたドキュメントをチーム外の人が読もうとすると、どんな困りごとが出てくるのでしょうか。第一に、 ドキュメントを読むだけでは理解できない ということがあります。これは先述したような、チーム内であれば期待できる前提知識や、コードを読むことによって得ることのできる情報を、チーム外の人は持っていないからです。もちろん他チームであっても開発者ではあるので「コードを読んでください」と言えば読んでもらうことは可能なのですが、私たちのチームとリニューアルプロジェクト側のチームとでは技術スタックがやや異なっていることもあり、あまりここに頼りたくはありません。 チーム外の人にはドキュメントに書かれている情報の鮮度を判断しづらい また、チーム内向けのドキュメントではフロー情報としてある時点での情報を書いたものをそのまま残してあるものも多いのですが、チーム外の人は私たちのチームやそのシステムの過去の経緯までは知らないことが多いので、あるドキュメントを見たときにそれがup-to-dateなものかの判断が付きづらく、誤った（out-of-dateな）認識を持たせてしまう危険性があります。 チーム外の人は必要なドキュメントに辿り着きづらい 更に、そもそも 必要なドキュメントに辿り着けない という問題もあります。先述の通り、「書き手の書きやすさ重視」のアプローチでは、読み手の利便性のうち、「欲しい情報への辿り着きやすさ」は犠牲になっており、検索やリンクを駆使してもらう必要があります。 チーム内であれば自分たちがどういう言葉を使っているかが分かりますし、何かを調べようと思ったときにどのようなキーワードで検索したら見つかりそうかの候補もすぐに思いつきます。「あの記事からリンクされていた気がする」というのも覚えているかもしれません。しかし、これはチーム外の人には期待すべくもないことです。もちろん最小限の語彙はOpenAPI SpecificationベースのAPi仕様という形で見えるようになっており、そこで接した用語について関心を持って調べ始めるわけなので、全く白地からというわけではありませんが、やはり「欲しい情報へ辿り着く能力」には差が出てしまいます。 ※ちなみに、将来的には現状の全文検索やリンクに加えてAIによる要約やチャット形式での検索が発展して、現在よりは必要な情報に辿り着きやすくなるのではないかと妄想しますが、その場合でもデータソースを書き捨ての文章のみで構成するのはなかなか厳しい気がします。 これからのドキュメンテーションの考え方 以上のような課題から、私たちのチームではドキュメンテーションの考え方を改めることにしました。具体的には以下のような方針を定めました。 チーム内向けとチーム外向けを分けない これまで、ドキュメントはデフォルトがチーム内向けで、例外的にチーム外向けを書くという形になっていましたが、この分け方自体をやめることにしました。チーム外の人でも読めるものに最初からしましょう、ということです。実際には、チーム内のメンバーしか読まないドキュメント（たとえば、運用上の手順書など）も出てくると思いますが、その場合でも暗黙の前提知識を要求するような形では書かないということを原則としようとしています。 ドキュメントを小分けにせず、なるべく大きなまとまりにする これまでは「場所に悩んだりして書かないよりは、とにかく書いておくことを優先する」という方針で、仕事をしている過程で小さなドキュメントをたくさん書いてきました。しかし、このアプローチでは、一度書かれたあとに更新されないドキュメントが増えがちです。更新されないドキュメントが存在することは、読み手、特に過去の経緯まで把握していないチーム外の読み手にとっては大きなノイズとなります。 新しい方針では、なるべく大きなまとまりの文書をメンテナンス対象とし、加筆・修正していくことにしています。あるテーマについてはこの文書だけが信頼できる唯一の情報源（Single Source of Truth）であるという状態を作ることです。 こうしておくことで、まず第一に、欲しい情報に辿り着きやすくなります。また、これはチーム内で話をしている中でメンバーから言われて「なるほど！」となった点なのですが、 読まれる頻度の高いドキュメントは更新されるチャンスも多くなる ということもあります。ドキュメントが更新されるタイミングとしては、何か変更が入った際に「あのドキュメントも更新しなきゃなー」と更新されるのがベストですが、更新を忘れてしまうことは実際には多いです。しかし、日頃から繰り返し開くことの多いドキュメントであれば、「あ、ここ情報が古いじゃん」と気づく機会が増えます。もちろん、ドキュメントが大きくなればその中の一部の記述だけを目当てにしてそれを開くことも増えると思いますが、それでもその部分以外の記述も併せて目に触れることはある程度あり、更新のきっかけになると思います。 フロー情報を書いたものはドキュメントとして扱わない 上の内容とも関連しますが、フロー情報として書いたものをドキュメントとして扱わないようにしようと考えています。 これまではフロー情報を書いたものもドキュメントの一部として扱い、「読まれる」ことを期待していました。しかし、この考え方はともすると「本来ストック情報として書かれるべきものがフロー情報として書かれっぱなしになってしまう」という事態を招きやすいと感じます。「フロー情報を残しただけでドキュメントを書いたつもりになる」のをやめなければなりません。そのためには 「フロー情報を書いたものはドキュメントではない」 というくらいの意識が必要だと思います。有益な情報として残すべきだと考えたなら、その情報が書かれるべきドキュメントを探して、メンテナンスするものとして記述します（もちろん、もはや必要でないと判断した場合には「メンテナンス」の一部として削除することもあるでしょう）。 インデックスとなる記事からリンクだけで必要な情報に辿り着けるようにする。 これはドキュメントへの辿り着きやすさの改善のための方針です。これまではドキュメントを新しく作成するとき、「どのようなタイトルにするか・どのような文言を入れておくか」という検索でのアクセスのしやすさの観点と、「どのディレクトリ *4 に入れておこうか」という階層構造を使ったアクセスのしやすさの観点を意識することはありましたが、他の記事との関係でいうと、関連する記事同士をリンクで結びつけることによるネットワーク構造の作成くらいまでしか意識してきませんでした。 今回、新しく各グループ（ex. 仕様に関するドキュメント群）ごとにインデックス（ルート）となる記事を設定し、そこから明示的なリンクを辿ることで必要な情報を見つけられるようにしようということになりました。先述の通り、検索頼みにするのはチーム外の人にとっては利便性が特に低いですし、「検索や階層構造で見つけてくれる」というのに甘えると自分たちがその文書に辿り着くのも意識的にアクセスしたときに限られやすくなるため、書きっぱなしで更新されないドキュメントになりがちです。特定の記事からリンクだけで辿り着けるようにしておくことで、チーム外の人からアクセスしやすくなると同時に、更新されやすいようになることを狙っています。 終わりに 以上、私たちのチームにおけるドキュメンテーションの方針の転換について、その背景と併せてご紹介してきました。この方針で動き始めたのは最近なので、実際にどうなったか（うまくいっているのか・いないのか）はまだご紹介できる段階にありません。ドキュメントをメンテナンスしていくのはそもそも簡単ではなく、だからこそ従来の方針のような「書き手の書きやすさ」を重視するという方針にも意味がある（最初から読み手の利便性を100%満たすドキュメントを書けるのであれば苦労はしない）わけですから、今回立てた方針を適切に実行できるかどうかも不透明です。 しかし、社内向けとはいえチーム外にAPIを提供するチームとしては、ドキュメントをプロダクトの一部として捉え、コードと同じくらい大切にする必要があります。ソフトウェア自体に不具合がなくても、ドキュメントが不足していたり誤解を招くものであったりした場合、使い方を間違えることでシステム全体としては正しく動作しなくなってしまうこともあるわけです。「ドキュメントをプロダクトとして扱う」という考え方は 『エンジニアのためのドキュメントライティング』 でも語られています。 pub.jmam.co.jp また、私個人としては、これまで他の開発者にクライアントとして使ってもらうソフトウェアをメンテナンスする経験がほとんどなかったので、これまでに形成してきた自分自身のドキュメンテーションに対する考え方をアンラーンする必要を感じています。今回のチームとしての方針の転換をいいきっかけとして、プロダクトの一部としてのドキュメントに真剣に向き合っていきたいと考えています。 「株式会社エス・エム・エス Advent Calendar 2023」 、明日4日目は、 @soranakk の記事を予定しています！ *1 : なぜこのような構成になっているかは割愛します。 *2 : 厳密には、リニューアルプロジェクトではフロントエンドとバックエンドがGraphQLのAPIで通信するアーキテクチャとなっているため「ユーザーが触るWebアプリケーション」はフロントエンドだけなのですが、ここでは簡略化のためバックエンドの部分も含めて「ユーザーが触るWebアプリケーション」と記載しています。 *3 : 当初は Swagger UI 、現在は Redoc を利用しています。 *4 : esaでは、ディレクトリ構造を作って記事を整理することができます。個々のディレクトリに相当する部分のことを「カテゴリ」と呼びます。

株式会社エス・エム・エス Advent Calendar 2023 エス・エム・エスで開発者をしている @koma_koma_d です。 今年もアドベントカレンダーの季節ですね、ということで、今年はエス・エム・エスでもアドベントカレンダーをやります！ qiita.com 記事は、このブログ以外に、各メンバーの個人ブログ、Qiita、Zennなどの様々な媒体に投稿される予定です。公開された記事はXのアカウント @BM_SMS_tech で随時シェア予定ですので、ぜひアカウントをフォローしていただけると幸いです！ 誰が何を書くのか 参加するメンバーは、 開発者 SRE エンジニアリングマネージャー QAエンジニア プロダクトマネージャー など、プロダクト開発に関わる多様な職種が集まっています。 内容についても、業務に関わることに限定せず、各メンバーの好きなテーマで書いてもらいます。エス・エム・エスのメンバーがどういう技術に興味を持っているのか、日頃どのようなことを考えながら仕事をしているのか、などを知っていただける機会になると嬉しいです！ 初日である明日の執筆者は、フロントエンドエンジニアの setoh です！お楽しみに！ setoh が過去に執筆・登場した記事 tech.bm-sms.co.jp tech.bm-sms.co.jp

はじめに エス・エム・エスのヘルスケア事業部所属のエンジニアの今村と申します。この会社に転職してきて気がつけば10年以上となります。 その間に、新規登録の処理を何度も何度も設計してきました。設計とは言うものの、入力用の画面を用意しPOSTしたらその値をサーバーサイドで検証してDBに登録するという大枠の流れは同じです。しかし最近になって、それで本当に良いのか？ と再考する機会がありました。 今回は、その時に再考した内容を整理したいと思います。 再考することになった経緯 仕事では、webサービスの改善・運用の他、業務で使うkintoneのカスタマイズも担当しています。 ある日、kintoneアプリのカスタマイズ要望がありました。具体的には、画面内の項目Aに特定の値を入力して保存した場合、ダイアログを表示して「次に担当者がとるべきアクションを明示したい」というものです。 kintoneには固有のイベントハンドラがあり、データの保存が成功したことをトリガーにして処理を実行することができます。今回はこれを使えば簡単に実装できると思っていました。 前提として、今回の値は新規登録と更新のどちらのケースでも入力されうるものです。そして、kintoneの画面は、新規登録を行っても完了ページには遷移せず、その画面内の項目が全てdisabledになるのみです。もしそこで「編集ボタン」をクリックすると、disabledが解除され、各項目の値を変更したりできるのです。業務アプリケーションではkintoneに限らず、よくある仕様と言えるでしょう。 しかしこの仕様、合理的なように見えますが、ユースケース次第では厄介なことになります。 更新画面ではURLで対象レコードのIDを指し示している必要があるものの、新規登録画面入力時には、まだIDが払い出されていません。このためkintoneでは、登録完了のレスポンスをAPIから受け取ったあと、フロントエンド側でリダイレクトをかけて編集画面を表示していました。 その結果、新規登録時の送信成功イベントハンドラを使って表示したダイアログは、一瞬だけ表示されるのみで、すぐリダイレクトされることがわかりました。これではイチロー並みに動体視力が発達した人しかメッセージを読み取ることができません。 結局、新規登録時には処理成功のイベントハンドラでCookieを発行し、編集画面が表示されたタイミングでCookieの有無をチェックしてダイアログを表示し、その後にCookieを削除するという煩雑な処理が必要でした。 そこで、ふと思ったのです。「新規登録では、入力完了後にデータを保存し、IDを払い出すのが唯一の正解なのか？」と。 新規登録という名の更新 気になった私は、早速世の中のさまざまなwebサービスはどうなっているのか調査しました。結果、一部のサービスでは、新規登録を行うと入力開始前にIDが払い出されて、新規登録画面という名の更新画面を表示していることがわかりました。 メジャーなサービスでは、Google Workspace(Docs、Sheets)、note、Zenn.devがこのような設計になっています。これらのサービスでは、一度登録画面を表示した後に入力を行わず離脱すると、そのデータは一覧上には表示されません。しかしURLを直接入力すれば表示できます。数日経つと、URLを入力してもアクセスできなくなります。以降ではこの方式を便宜的に「登録編集共通方式」と呼ぶことにします。 登録編集共通方式のメリットとデメリット この処理方式、主にフロントエンド観点では、実装が楽になるというメリットばかりとなります。一方バックエンドは、フロントエンドの実装が楽になったしわ寄せとして、主にDB周りの設計に複雑さが生じます。以下詳しく整理してみます。 メリット フロントエンド側の考慮事項が減る 登録と編集を共通化してしまえば、新規登録を編集と同等の挙動に見せかけるための様々な工夫が不要になります。当然、実装もシンプルになると言えます。 多重POST問題から解放される IDが払い出されていない場合、同一の投稿がすでに送信されていないか判断する必要があります。フロント側でボタンをごく短時間不活性化すれば良いとの意見もありますが、ユーザーは数秒後に同じ内容を送信してくることもあり、バックエンド側での多重POST判定の処理が必要なケースもあります。 他方、IDを払い出す場合、内容如何によらず、POSTされたら素直に上書き保存すれば良いだけなので、先述のような考慮は不要になります。 デメリット テーブル設計が複雑になる この設計を実行に移すには、未入力の状態でも登録ができるように、多くのカラムでnullを許容する設計にするか、IDを払い出すための最小項目の親テーブルと実データを格納する子テーブルの関係で設計する必要があります。 チームの方針として、テーブルの項目に原則nullを使用しないことになっている場合は、自ずと後者の設計を選択することになるでしょう。 新規登録時点では親テーブルのレコードのみを登録してIDを払い出し、最初のデータ保存のタイミングで子テーブルのレコードを登録します。これはアプリケーションの都合にDB設計が従属する形となるため、受け入れられないこともあるでしょうし、受け入れられたとしても、テーブルの管理が従来より煩雑になるのは間違いありません。 ごみレコードが沢山できる/定期的に削除処理が必要になる 新規登録の画面を開く都度にレコードが作成されるため、結局その後保存されずに離脱されてしまうと、そのレコードは、ゴミとして蓄積していくことになります。 DBの性能とシステムの規模によっては、パフォーマンスの劣化を早めてしまうため、定期的な削除が必要で、その場合バッチ処理を別途作成することになるでしょう。 まとめ 以上の通り、 登録編集共通方式について、採用した場合の具体的なメリットとデメリットを整理しました。 繰り返しになりますが、登録編集共通方式ではフロントエンド周りの開発コストが削減できそうですが、バックエンド周りの開発コストは増える可能性がありそうです。 例えばフロントエンド周りの機能が今後複雑化していきそうな場合には、バックエンド側が開発コストを多く負い、フロントエンド側をシンプルに保てる登録編集共通方式のほうが長期的に優れた結果をもたらすでしょう。一方、従来の会員登録のような機能では登録編集共通方式の採用はデメリットが目立つ結果になりかねません。 このため、プロジェクト全体の方針やユースケースに応じて、既存の方式と登録編集共通方式を比較検討しながら、その時々でベターな選択をしていけると良いかなと思います。

技術責任者の @sunaot です。エス・エム・エスのプロダクト組織では、カンファレンス参加や専門書籍による学習などを強く推奨して、金銭的・時間的な支援も広く行なっています。 取組み自体はとくに最近の Web の会社では珍しいものではありません。ただ、位置付けや考え方を表明しているのはやや珍しいらしく、入社してきた人やカジュアル面談の場などで説明すると面白がってもらえることがあります。そこで、今回はその背景や考え方を説明してみます。便宜上ソフトウェアエンジニアを例に説明をしますが、基本的にはプロダクトマネージャーやデザイナーなど他の職種においても同じことが言えると考えています。 学習への投資は責任を果たしてもらうための必要経費 エス・エム・エスのプロダクト組織では、カンファレンス参加や書籍の購入といったものに会社のお金や業務時間が使えることを 福利厚生として位置付けていません 。では、報酬ではないのだとしたらどのような位置付けなのでしょう？ 実は、これは十分なクオリティの仕事をする上で当然必要なもの、 責任を果たすための過程で必要なものの一部 として提供をしています。 元々、エンジニアを始め、プロダクト開発の仕事というのはタスクを終えることが仕事ではなく、一定の品質水準を満たすものを届けることが仕事の完了条件に含まれています。そして、その自律の求められ度合が高いのが特徴です。ソフトウェアは目に見えないのでぱっと見で品質の判断ができず、自律しないと手抜きができてしまいます。さらに、目の前でやる仕事が全て自分の知識の範囲に収まることは非常に少ない仕事であることも特徴です。エンジニアであれば、大体知らない技術要素であったり製品だったりが関わってきます。 そのため、成果物に対してプロフェッショナルな水準の仕事をするとなったときに「調べる・学習する」ということが仕事の当たり前の一部になってきます。そして、仕事のたびに全部を新しく調べるわけにはいかないとなると、自分の道具を磨くための学習をし続ける必要があります。 必要な品質を満たすために十分な調査・学習をしてほしい こうした見方をしているので、今のエス・エム・エスのプロダクト組織では学習をするということに対して積極的に支援をしています。それは仕事に必要だと知っているし、明らかに投資に対してリターンが大きいからです (全部を学習し終えた人を転職市場から探して採用してくるのはとても難しくコストもかかります)。 "知らないことを調べることも仕事の内で、自身でクオリティの判断ができないうちに仕事を期限だけに対して終わらせないでほしい。必要な品質に対して調べることをしてほしい" ということもよくメンバーに対して伝えています。これも同じ理由で、それがまともな品質のエンジニアリングの仕事に必要だからそう求めています。仕事の時間を使って経験のない技術の調査をしてよいと聞くと、一見その人の時間への優しさのように聞こえますが、実はそうではなく仕事のクオリティへの厳しさゆえの方針だったりします。 直接は目の前の仕事に関係しない勉強会を仕事の時間にやっていたり、カンファレンスへの参加を業務時間に入れているのも同じ理由で、けっきょくいつ学ぶかだけの問題で、そうして積み重ねた学習がなければ必要になったときに一から全部学ぶことになってコストが高いから積極的に奨励している、という背景になります。そういう仕事だから、ですね。 もちろん、そうした学び合う環境があるほうが働いていて楽しいとか、優秀な人と学習すると刺激になって働きがいがあるとか、学習を支援している環境のほうがわいわいしていて周りの人も学ぶ気持ちになるとか、色々副次的なメリットもあるとは思っているのですが、一番の理由は「そういう仕事で、必要だから」という考え方をしています。 まとめ この記事のまとめです。 エス・エム・エスのプロダクト組織ではカンファレンス参加や専門書籍・コンテンツによる学習を推奨し、広くその支援をしています。 これは個人の学習支援のためという以上に、そのときにマーケットやプロダクトが必要とする水準のクオリティの仕事を求めるという姿勢から来ています。それまでの経験で得た知識・スキルでできる範囲のクオリティの仕事をしていくのでなく、必要であれば都度学習しながら未知の課題にも取り組める人とチームでいるための方針なのです。

はじめまして。株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」のQA組織の運営をしている星と申します。2020年1月に入社し、チーム活動やQA組織づくりを通じて体制強化を進めています。 本記事ではこれまで行ってきたQA組織強化に対しての状況アップデートと、それに付随して行動指針や大切にしていきたいものを言語化するまでの過程をまとめています。 他ロールのメンバーも弊社テックブログにチームとしての価値観を紹介する記事を投稿していますが、QA組織としてカイポケ含め、エス・エム・エスのサービスと開発組織をどう捉えているか、その中でどういった思いを大切にして品質に対して向き合っていこうと考えているのかを記事にしています。 QAエンジニアの方のみでなく、チームで品質を作り込んでいくことに興味がある方は是非ご一読頂けると嬉しいです。 QA組織のこれまでと現状 以前、弊社テックブログにQA組織として過去と未来についての話を投稿しましたが、私が入社した2020年も引き続き、記載されているようなQAプロセスの浸透、メンバーのアサインや検証に対する各施策の細かい実行、小さな改善を積み重ねていくことで体制強化を図っていました。 tech.bm-sms.co.jp 弊社は複数のチームに分かれて開発を進めておりますが、私もカイポケの1チームを主軸にjoinして、実作業に深く携わりながらプロセスを意識した日々の品質活動や実際の検証業務を行っておりました。 QA含む開発チームからの協力の中で、改善活動やコミュニケーションを積み重ねてきましたが、その活動を経てカイポケや弊社の事業を取り巻く環境や特性の解像度を上げていくことが出来たと実感しています。入社から3年が経ち、チーム横断の開発時の検証や介護報酬改定という大きなイベントも経験しました。 その中で、エス・エム・エスとして取り扱っているサービスがもっているミッションの解像度の高まりもあり、各チームで取り組む品質の担保・向上のためのテストプロセスに柔軟性を持たせて、進めていくことの重要性を感じ、改めてQA組織としての行動指針を言語化していきたいと考えるようになりました。 こういった考えにシフトしたのは、取り組んできた以下の課題について、一定先が見通せる状態になってきたという背景があります。 QAプロセスの安定化 各チームにて一連のテストプロセス浸透が進められている。 目的に即した形かつリスクを念頭に置いた状態で、対応内容ごとにプロセスの要不要判断をチームで議論する土壌も出来つつある。 QAチームの品質活動の定常化 リリースに向けた検証対応以外の品質活動を各チームで考え、進められる状態になった。 E2Eテストの自動化や属人化を防ぐ活動、QAメンバー以外との連携を各チームで検討しながら進められている状態。 このような各メンバーによる小さな課題解決の積み重ね、育成や採用での体制強化の結果があり、前述の思考へ舵が切れる状況になったということが大きいと感じています。 QA組織から見たカイポケや開発組織について 前提として、私含めたQA組織が弊社のサービスや開発組織をどういう視点で捉えているか触れておきます。 エス・エム・エスは医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラ構築をミッションとしている会社です。エス・エム・エスが行っている事業を取り巻く環境の変化は激しく、極めて不確実性や複雑性が高いものを取り扱っているという認識を持っています。介護業界も例に漏れず変化が激しい業界ですし、3年に1度の介護報酬改定という大きなイベントも定期的にあります。 tech.bm-sms.co.jp そのため、QA組織を含む開発組織としてのフェーズの変化に加えて、市場やニーズの変化に対応していくべく、QA組織としての考え方を継続的にアップデートしていく必要があると考えています。 その他の背景としてはカイポケリニューアルの始動と開発組織のバリュー言語化があります。 リニューアルプロジェクトは、従来のカイポケの追加開発・制度対応のプロジェクトとは性質が様々な点で異なるため、QAチームとしてもその性質に適応した活動をしていく必要性を感じています。 また、これまでQA組織の価値観の言語化は独立して行われてきましたが、今回開発組織全体のバリューの言語化が始まったことで、QA組織の価値観の言語化を開発組織全体の価値観と整合性の取れる形で行う良いタイミングだと考えました。 リニューアルプロジェクトについては、EMの酒井さんの記事を、 tech.bm-sms.co.jp 開発組織のバリューの言語化については、技術責任者の田辺さんの記事をそれぞれご覧ください。 tech.bm-sms.co.jp QA組織の行動指針検討の過程 始めに、行動指針の検討とQA組織が大切にしているものを言語化していくにあたり、大事にしたかったポイントを書きます。 エス・エム・エスのサービスの特性、組織として持っているミッションと開発スタイルを踏まえて言語化し、貢献に繋げたい。 あくまでも大切にしたい価値観、考え方の指標にする。これをベースに各チームでも落とし込みや最適化が出来るようにしたい。 QAエンジニアとして楽しみながらチャレンジができるものにしたい。 適宜見直すことを前提に、なるべくシンプルかつ目的にピンポイントな言語化をしたい。 行動指針を定義していくにあたり、次に挙げる3つの要素の読み解きと洗い出しから言語化を進め、それをベースとして検討をしていきました。 QA組織の行動指針検討に用いた要素 ☆エス・エム・エスの「サービスの特性や開発スタイル」の読み解き 前述の「カイポケの特性」や弊社の開発スタイル、開発組織全体のチームバリューを読み解いて可視化していきました。その中でQA組織がどう貢献していけるか、どう貢献していきたいかを議論していきました。 ☆「アジャイルテストの10の原則」の読み解き、活動とのリンクづけ 活動や日々の仕事において大事にしたい点として、『Agile Testing Condensed』にもある「アジャイルテストの10の原則」の考え方があり、上述のサービスや開発組織の特性、取り組んでいきたい活動をテストマニフェスト *1 と掛け合わせた形での可視化を進めようと考えました。 leanpub.com ☆QA組織として「取り組んできたこと、やっていきたい品質施策」の洗い出し 現状のQA組織と各開発チームの品質に関わる取り組み、継続してやっていきたい取り組みを洗い出しました。新規で取り組んでいきたいことだけでなく、「QA組織として過去と未来についての話」でも記載があったE2Eテストの自動化であったり、連続性がある検証といった要素も継続取り組みとしてピックアップしています。 QA組織の行動指針言語化 これらの要素を踏まえた検討を繰り返し、大きく3つの行動指針へ落とし込んでいきました。 行動指針と実際の動きのイメージを結び付けやすくするため、一例としてユーザーストーリーマッピングや探索的テストといった形で具体的な活動ともリンクさせて言語化しています。 ☆継続的テスト リリースを含めたプロセスの最適化(高速化や安定化含む)を目的とし、一連の開発プロセスを通じた改善に向けた前倒しテスト、フィードバックのサイクルをまわしていく活動が重要と捉えています。 これによって、不確実性が高い業界のサービスであるという特性に対し、品質のキープと向上を見据えつつも、状況に応じて最適なプロセスにチューニングするといったアプローチをとれるようにしていきたいという思いがあります。 ☆価値に対するテスト ユーザーの課題感や実際の業務プロセスを理解し、最優先に考え続け、それを品質活動にも適宜取り入れていくことを大切にしていきたいと考えています。 前述の通り、社会の変化に対して貢献していくことが大きな価値になるサービスであると捉えています。そこに向けて大切にしていきたい価値観となっています。 ☆チームで品質保証 各ロールの専門性を持ち、協働して開発を進めることで、難解な制度にも安定した品質で対応していけるように進めたいと考えています。 複雑性が高い業界のサービスであるという点を特に考慮し、PdMやエンジニア、ドメイン知識に秀でたメンバー含め、チーム全員で取り組んでいく意識を持つことを言語化しています。 行動指針のひとつとして「価値に対するテスト」を掲げていますが、前述の市場の変化や定期的な報酬改定を踏まえて、ユーザーが継続して当たり前の業務プロセスを通せるかということも大きな「価値」となると考えています。 そのため、新しく生み出していく価値の品質にフォーカスするだけでなく、E2Eリグレッションテストを駆使し、既存の価値も担保し続けるという意思は変わらず強くあります。 弊社のQA組織としては既に根付いている価値観ではあるため、行動指針としての定義や言語化、アクションとしてあえての記載はしていないですが、取り扱っているサービスの特性上、ここも非常に大事なポイントと捉えているということを補足しておきます。 完成したものについて社内公開や共有を進め、今後も引き続き活動への落とし込みとブラッシュアップをしていきたいと考えています。 行動指針をベースに取り組んでいる活動の一例 今回言語化した価値観をベースにして、既に各アプリチーム内でQAチームが関わっている活動、主導して進めている活動がいくつかあります。 ☆実例マッピング 早期の開発内容理解、テストスコープの共通認識化でテスト分析や設計のスピード向上、ふるまい上で気にしているポイントをフィードバックすることでの手戻りやリスク低減をメイン目的として取り組んでいます。進め方自体もチーム内で振り返りをおこない、随時精度を上げている現状です。 leanpub.com ☆業務フローの理解と顧客価値を踏まえたテスト戦略の定義 リリースや機能開発ごとの提供価値の読み解きから、テストレベルの最適化やテスト分析、テストカバレッジの共通認識化といったチーム内での価値共有をメイン目的としています。複数アプリチームで活動していることから、横断的な視点も必要になってくるため、引き続き精度を上げるように日々開発しているものの価値を考え続けています。 ☆開発者とのテスト最適化検討 複雑なシステムに対して、チームで品質担保をしていく足がかりとして取り組んでいる施策です。エンジニアとQAでお互いがやっているテストをより深く知っていくことで、チームで担当している機能に対しての共通認識化、該当箇所の開発対応の難易度すり合わせとしても活用していけると考えています。 ☆E2Eテスト自動化 引き続き、E2Eテスト自動化に対しての施策を重点的に進めています。以前はテスト戦略の策定や設計、実装面での課題も多くありましたが、今ではリグレッションテストとしての運用やプロセスへの組み込みも進められています。今後も活用シーンが更に増えてくることを見込んでおり、運用/保守の検討にも力を入れていっています。 取り組みの詳細や効果については改めてテックブログ内でも公開したいと考えていますが、まずは一例として紹介しました。 前述の通り、カイポケ開発は複数チームに分かれて運用しており、それぞれがもつ担当アプリの特性やチーム状況等も踏まえ、各チームで最適な施策を模索し、取り組み活動と改善のサイクルを回しています。 その中で、今回言語化に至った「大切にしていきたい価値観」をベースに品質への活動も考え、取り組みを続けてきている組織だということを、言語化を通して再認識することもできました。 これからのQA組織 エス・エム・エスの開発組織には、ユーザーに対しての価値を考え続け、作り込み、継続的に提供していく思いが強いメンバーが多く在籍しています。 開発組織のチームバリューにもある通り、変化し続ける課題に対しての動き含めて、柔軟性と目的をもった品質活動を定義してチャレンジしていける組織だと思っていますし、それに対して技術責任者、エンジニアリングマネージャー、他ロールの方々からの協力を沢山もらえる環境です。 もう1点、今回公開した行動指針やそれに伴う活動については、落とし込みも含め、見直せる点や精度を上げていける点が非常に多く、取り組みとしてもこれから積極的にチャレンジしていきたいものを含んでいます。 例えばユーザー理解から、それを検証や品質活動としてフィードバックしていくことに対しても、まだまだ沢山の取り組めることがあると思っています。 tech.bm-sms.co.jp QA組織としてもまだまだ多くのチャレンジやキャリアアップが出来る環境であると思っていますし、「過去と未来についての話」にも記載している通り、将来的には「サービスを運営する上で全ての品質に関わっていきたい」という思いは継続してあります。 そして、それを実現するための仲間もまだ足りない状況です。 今回ご紹介させていただいた、QA組織として大切にしていきたいと思っている価値観に興味を持ってもらえた方がいらっしゃれば、是非お気軽にご連絡ください！ *1 : 参考: 「【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 2023年10月12日閲覧

11月2日「Qiita Night～プロダクトマネジメント～ 」でLTを行いました 11月2日に開催された「Qiita Night～プロダクトマネジメント～ 」で、プロダクトマネージャーのキム ダソムが「BtoB の顧客理解が捗るミニリサーチ」のタイトルでLTを行いました！ increments.connpass.com 資料「BtoB の顧客理解が捗るミニリサーチ」 こちらが当日使用した資料です。 speakerdeck.com 当日に発表を聴いていただいたみなさま、イベント主催のQiita株式会社のみなさま、ありがとうございました！ 2024.2.21 追記 発表の内容をログミーTechさまで記事にしていただきました！ logmi.jp

こんにちは、WEBエンジニアとして2023年7月に入社した髙田です。この記事では入社エントリとして私が転職先としてなぜエス・エム・エスを選んだかというのを通して、少しでもエス・エム・エスの魅力を伝えることができればと思っています。 私のこれまで 前職ではベンチャー企業で開発組織がほぼない状態のところからある程度の形になるまでを体験し、Ruby on Railsを主体に開発業務やチームリーディングに従事してきました。その中で、転職する間近まで事業責任者に近いポジションの方と一緒に仕事をすることがあり、企業成長のための売上をつくるためにどのようにエンジニアリングリソースを使うべきかということを考えさせられる場面が多くありました。 買ってもらえるプロダクトを提供するために限られた人員でどう開発を進めるか、ただでさえ時間的制約が多い中で同時多発的に発生する課題へどう向き合うか、そしてその状況下で事業側の求める要求にどう沿わせていくべきか、そんなことを考えることが多かったように振り返ると思います。 成長に沿わせながら課題解決をさせる難しさはその時に身をもって痛感しました。そして同時に「会社の成長を考え、同時に難しい課題を解く」ということをやり続けることは、自分自身の糧になる部分が非常に多いということも感じていました。 そうしたことをやっていく中、転職を思い立つタイミングがやってきました。 入社を決めたきっかけ 転職を思い立った理由は様々な理由が折り重なった複合要因ではあったのですが、次の会社を探すにあたっては「事業や収益拡大に貢献できる」「健康的な生活サイクルで仕事をできるか」ということを軸にして色々な会社とカジュアル面談などをしました。 というのも事業の拡大を目指す過程では様々な課題が降り掛かってくるので、それをこなしていくと自然と自分自身の成長にも繋がり、ひいては会社も大きくなるので得るものが多いと思ったからです。ただこのように事業の拡大を目指す場合にベンチャーなどではハードワークとワンセットで語られることもあり、自分の中で「健康的な生活サイクル」という軸もワンセットで考えていました。 そんな軸を持ちながら色々な会社にお話を伺ったりしていたのですが、最終的に「エス・エム・エスに決めよう」と思ったのは選ぼうと思った軸に関して満たしている会社であり、「会社の成長を考え、同時に難しい課題を解く」ということをやっている会社だったからでした。 こちらに関しては 直近で公開された記事 を見ていただいたほうがわかりやすいのでそちらを見ていただければと思うのですが、面接を通しても部分的に記事内で紹介されていることの説明があり、非常に共感できる部分が多いので転職を決めたというところがあります。 自分自身がやれることを着実にやる そんなこんなで現在転職してからしばらく経つのですが、現在は看護学生向け就職活動情報「ナース専科 就職ナビ」のWebアプリケーション開発に携わっています。 サービスとしては歴史が長いため様々な機能が実装されており、それが故に仕様が複雑化しているものも数多くあります。例えば合同説明会の機能です。もともとはイベント会場などで行われる合同説明会のために作られていたものでした。しかしながら、コロナ禍でオフラインの開催ではなくなり、オンライン開催の形に添わせる必要が出てきたため、仕様として方向性の違う拡張をしなければならず、複雑な構造になってしまっていました。 そのような状況に対処すべく、直近で私を含めて新たにチームメンバーが増え、人数に沿った開発のやり方をシフトチェンジしている真っ最中です。私自身は過去にチームの拡大をいくつか経験してきたので、その経験をもとに現状のチームでは何がベストなのかを模索しながらチーム内で提案や議論をしながら進めています。また、元々のチームメンバーも私の提案に耳をしっかりと傾けてくれるので、新しい人の発言もしっかりと受け止めてもらえるのはもともとの会社の文化醸成のたまものなのかな、と思っています。 私個人としては自分の過去の経験を活かしつつ、自分自身がチームに貢献できることを探し、チームの一員として着実にできることを増やし、ひいてはチームのポテンシャルを上げていくということを直近では取り組んでいます。 サービス成長の結果生み出されてしまった複雑さと向き合いながら、もっと良くしていくためにどういうアクションを起こすべきか、という難しい課題に取り組むことは自分の成長にまた寄与してくれると信じて日々職務に取り組んでいます。 やれることがたくさんある 私が携わっているのはエス・エム・エスの開発におけるほんの一側面であり、様々なプロダクトや開発チームが存在している状況です。様々な選択肢があるのもこの会社の特徴だと思います。どの方も「誠実」であるなということは感じているので、非常に気持ちよく仕事ができるのではないかと思っています。もしエス・エム・エスにご興味を持たれたらぜひ採用サイトを覗いてみてください。

2023年春、エス・エム・エスのプロダクト開発部にデータプラットフォームチームが立ち上がりました。データプラットフォームの構想から経営層の意思決定、チームづくりまでがスムーズに進行し、現在は技術選定を終え、実証の段階にまで駒を進めています。 ここまでスピード感をもって進めることができているのは、プロダクト開発部のバリューである「マーケットへ向けて動く」という意識が、経営層からチームメンバーにまで浸透していることの現れであるともいえます。「組織や各メンバーの役割だから」ではなく、「マーケットへ価値を提供できているか」という視点でそれぞれが責任感を持ち、プロジェクトに取り組んでいます。 今回は、データプラットフォームチームをリードする三浦に、データプラットフォーム立ち上げの背景や展望、またマーケットに対し日々どのように向き合っているのかについて聞きました。 顧客に価値提供するプロダクトとしてのデータプラットフォーム ——三浦さんの経歴や普段の業務内容について教えてください。 ソフトウェアエンジニアとして約15年のキャリアがあり、ガラケーのサービス開発や社内向け分析基盤の整備、小売業の機械学習パイプライン整備などさまざまな案件に取り組んできました。エス・エム・エスには3年ほど前に入社し、介護事業者向け経営支援サービス「カイポケ」の技術的な課題解決のための取り組みを始めていきました。現在は、プロダクト開発部のカイポケ開発グループで、カイポケのリニューアルをリードしています。エンジニアリングだけ/プロダクトマネジメントだけではなく、リサーチから、プロダクト戦略立案、リソース調達などあらゆる領域をカバーしています。 ——現在カイポケでは、データプラットフォームの構築・整備を進められているそうですね。データプラットフォームの構想はどのような問題意識から生まれたものなのでしょうか。 介護サービス関連のデータが散在することで、利用者の全体像が見えづらくなっているという背景があります。詳細はこちらの記事（ 「なぜ介護事業者向け経営支援 SaaS「カイポケ」でデータプラットフォームをこれから作るのか」 ）にまとめています。 介護職員は、介護サービスを提供する事業所のほか、複数のサービス事業所や居宅介護支援事業所、医療機関などと日々連携していくことが必要となりますが、現状では、情報共有には電話とFAXが使われることがほとんどで、利用者のデータが分散してしまっています。 また、介護サービスは入退院の前後に提供されることが多いため医療との連携も不可欠ですが、医療ではバイタルデータなど定量的な情報を扱うのに対し、介護では普段の生活の様子など非構造化データの重要性が高まります。要配慮個人情報を扱うことから、高いセキュリティも求められます。 このため、利用者を軸にデータを集約・構造化し一元管理できるプラットフォームをつくり、介護サービス関連の事業所を横断してセキュアにデータ共有できる情報インフラの構築を目指すべきだと考えました。 ——プロダクトとしては具体的にどのようなものをイメージされていますか。 データプラットフォームや分析基盤というと社内向けのイメージがありますが、最終的には、カイポケのお客さまに対して価値提供できるプロダクトにしていきたいと考えています。現行のカイポケにおいても情報共有機能は一部ありますが、事業所と利用者の1対1で共有する形となっています。これを、1人1人の利用者データに対して、各サービス事業所、介護職員、医療などあらゆるステークホルダーが適切な状態でアクセスできるようにしていくイメージです。 出典: 厚生労働省 「地域包括ケアシステム」 顧客視点で課題感を解像度高く伝え、経営陣の理解を得る ——データプラットフォームに関するこれまでの取り組みについて伺えますか。 日常的にリサーチ活動をしているなかで、2022年秋ごろからデータプラットフォームの必要性を感じるようになり、大まかな構想を練り始めました。当時はカイポケの新アプリの方向性が固まり、スケジュールが見えはじめた時期だったので、データプラットフォームの取り組みに時間を掛けられるようになったという背景もあります。2022年末ごろまでに社内やアドバイザーへのヒアリングを重ね、2023年に入ってからカイポケの事業責任者の合意を得て具体的に動き始めました。2023年2月には、経営陣へプレゼンテーションを行いました。 ——経営陣の反応はいかがでしたか。 社内のデータ分析関連組織を再編成する話が動いていたので、そことのつながりをどうすべきかという議論はありましたが、データプラットフォームのコンセプト自体には賛同を得られました。エス・エム・エスのミッション *1 と密接に関わっているプロダクトであり、お客さまにとってどのような価値を持つものなのか理解してもらえたと感じています。 プレゼンでは、会社として長期的な視点で考えた際にどういう意味を持つプロダクトなのかを意識して話すよう心がけました。また、現行のカイポケの機能でのデータ連携による価値を評価していただいているお客さまの声や、エス・エム・エスのアドバイザーからいただいたデータ連携の要望などを紹介し、マーケットの現状についても整理しました。経営陣への提案がスムーズに通ったのは、お客さまやユーザーの観点から現在の課題感を解像度高く伝えられたことが大きかったと思っています。 実際にプレゼンに利用した資料の一例 あらゆるレイヤーのメンバーが「マーケットへ向けて動く」を意識 ——経営陣としても「マーケットへ向けて動く」という意識が高いということですよね。 エス・エム・エスの入社最終面接で、代表の後藤からは、戦略を立てる際には長期かつ業界全体の視点をもって見渡すことに加え、フワッとならないよう会社や顧客の成果を解像度高く設定し、その成果から逆算して主体的に動いていけなければ、エス・エム・エスにおいてはリードしていく人材にはなれないと伝えられました。 経営との進捗会議の中で後藤からカイポケと隣接するマーケットで過去の事例を紹介してもらい、そのファクトからマーケットの見立てを説明していた時の解像度の高さに驚いた場面が何度もありました。「マーケットへ向けて動く」はエス・エム・エスにおいては十分に文化になっていると感じています。 ——三浦さん個人としては、「マーケットに向けて動く」というバリューを普段の業務のなかでどのように意識されていますか。 最初に意識を持つようになったのは20代後半に転職したコンシューマ向けWeb サービス企業にエンジニアとして転職してからになります。その会社では常に自分の仕事を誰に評価されたいのか *2 というところを起点に仕事をしていく文化でした。 さらに大きな転換点となったのは前々職の国内EdTech企業で、幼稚園生向けのiPad用の教材を開発していたときのことです。児童向け遊戯施設を国内外に展開する企業とともに、タイ・バンコクの遊戯施設でその教材をトライアル導入することになったのですが、実際に設置してみたところ現地の方からまったく利用されていないとの指摘を受けました。ビデオ通話で現場の様子が中継され、自分たちの遊具の周りにだけ子どもたちが集まっていない光景を見たときはショックでしたね。急いで現地に向かい、まずは実際の子どもたちの動きをみて課題を整理してきました。さらにその後は、開発チームのメンバー全員で現地に行き、改善を繰り返していきました。最終的には大盛況で終えることができたのですが、この経験を経て、プロダクトは最終的にユーザーの行動を変えるものであり、その行動に至る背景や目的、その後のアクションなどを具体化しなければ、最終的なプロダクト像は見えてこないと思うようになったんです。 ——現在ではどのような形でマーケットを意識されていますか。 社内のドメインエキスパートやアドバイザーに日常的に話を聞いたり、リニューアルのコンセプトを検証するために現場へ同行して議論したりなど、基本的には現場に足を運ぶようにしています。また、厚生労働省が主催する介護分野における生産性向上推進フォーラム *3 や健康・医療・介護情報利活用検討会介護情報利活用ワーキンググループ *4 を視聴したり、財務省による予算執行調査 *5 の中から社会保障費に関わる分野の調査を調べて、介護の現場における情報の利活用の現状や今後についてリサーチを継続しています。 特に現状のカイポケでは、施設系の介護サービスに対応できないという課題があります。この課題に対応するために、事業責任者とともに現場へ向かい、実際の業務や利用者の様子、IT環境も含めた周囲の環境などを把握し、帰り道に業務の課題をディスカッションしたということもありました。 利用者にとってプロダクトは、画面の中だけで完結するものではありません。実際の環境があってはじめて利用者の行動につながるものとなるので、現場を理解していくことは非常に重要です。 マーケットに向き合っていれば、「未来にある普通」がつくれるはず ——データプラットフォームチームのメンバーの特徴について教えてください。 チームづくりは経営陣へのプレゼンテーション後に本格的に動き始めました。データエンジニアリングや分析の領域は採用市場が小さいうえに、経験値を積んでいる人材となるとかなり希少で、メンバー集めには苦戦すると思っていました。しかし、タイミングと運がよく3名の副業メンバーが集まりました。狙ってやったわけではありませんが、「人が人を呼ぶ」という状態ができていたのかもしれません。 メンバーは皆それぞれ、データプラットフォーム構築を複数回経験しており、視座を高く持って自走できるレベルの人たちです。抽象度や不確実性が高い状況でもデータの持つ力を理解できるメンバーであり、介護事業者の業務構造や情報分断という社会課題の重要性、データを通してお客さまに価値を提供することに対して皆強く共感しています。 ——ここまでかなりスピード感を持ってプロジェクトを進められてきたように思います。何かハードルになった点はありましたか。 開発環境の整備やメンバーのスケジュールの工面など、立ち上げ時には多少苦労しましたが、比較的スムーズに進んでいます。長期視点かつユーザー視点で物事を考え、データの重要性を理解している会社だからこそできているように思っています。 ——データプラットフォーム構築に向けた今後の展開や課題について伺えますか。 技術選定、アーキテクチャの設計はできているので、現在は実証フェーズに移っていく段階です。チームメンバーに加え、SREやアプリ開発、バックエンド、セキュリティを担当するチームなどとの連携が始まるため、ステークホルダーのコンセンサスを取ることが今後は重要な動きになっていくと考えています。 ——最後に、三浦さん個人としてデータプラットフォームに掛ける思いをお聞かせください。 私としては、ドラスティックに業務や生活を変えるようなプロダクトよりも、「現在にはないが、未来にある普通」をつくっていきたいと思っています。当たり前であればあるほど、マーケットのシェアも拡大していくはずです。現場に足を運ぶようにしているのも、こうした考えがもとになっています。介護関係者が日々のケアで当たり前に利用するプロダクトを目指していきたいですね。 *1 : https://www.bm-sms.co.jp/company/mission/ *2 : https://jkondo.hatenablog.com/entry/20060422/1145674096 *3 : https://www.mhlw.go.jp/stf/kaigo-seisansei_forum.html *4 : https://www.mhlw.go.jp/stf/shingi/other-rouken_485753_00001.html *5 : https://www.mof.go.jp/policy/budget/topics/budget_execution_audit/index.htm

介護事業者向け経営支援サービス「カイポケ」のプロダクトマネージャーを担当している 田村 恵 です。 我々のようなBtoB SaaSでは、ユーザーや業務を深く理解することがサービスの価値を生み出す上で重要です。今回はどのようにユーザーからインプットを得ているのかを紹介します。 今回紹介する活動 私たちは、ユーザー業務に対する理解を深めるために、ユーザー事業所を月に1回ぐらいのペースで訪問しています。カイポケユーザーである介護事業所を訪問し、実際の業務や関連業務を見学することで、ユーザーの業務に対する理解を深める取り組みです。 業務を見学することの重要性 私たちのユーザー訪問では、単に訪れるだけではなく現場の活動を間近で見学し、ユーザーが日々どのような業務に取り組んでいるか、どういったところに課題があるのかを実際に目で見ることを重視しています。具体的な業務の実態を目にすることで、抽象的な概念から具体的な課題やニーズへとつなげることができます。 仮説を持たない姿勢で取り組むこと ユーザー訪問では、あらかじめ仮説を持つことなく、ユーザーの業務に没頭するよう心がけています。仮説を持つことは、既存の予断や偏見を持ち込む可能性があるため、ユーザーの実際のニーズや課題を見逃す可能性があります。そのため、素朴な疑問や興味を持ちながら、ユーザーの業務に没頭することで、真のニーズを探り出すことを意識しています。 デザイナーやエンジニアの参加 ユーザー訪問には、プロダクトマネージャーだけでなく、デザイナーやエンジニアも積極的に参加してくれています。デザイナーやエンジニアもユーザーの業務に対する理解が必要であり、プロダクト開発において重要な視点を提供してもらいたいからです。デザイナーやエンジニアの参加により、ユーザーの視点や現場の課題をより多角的に捉えることができます。 このことの重要性は、事業責任者の園田が書いた記事「 大規模SaaS「カイポケ」の意思決定を支える事業責任者の思考と技術 」でも触れていますが、自分たちのプロダクトを、ユーザーが現場でどのように使っているのかの肌感覚を得ることを大切にしています。 解像度を上げるための工夫 事前準備 ユーザー課題の解像度を上げるために、訪問前の準備として以下のようなことをしています。 ユーザー情報の確認 訪問させていただく事業所が法人設立からどれぐらい経っているのか、法人・事業所規模、カイポケをお使いいただいている期間、担当利用者数、毎月の請求実績などの情報を事前に確認しています。 訪問メンバーの現在地の確認 訪問するメンバーが入社後どれぐらい経っているのか、ユーザー訪問の回数、担当している領域などを確認し、状態にあった訪問先を選定したり、どのようなことをメインで確認するかを決めたりしています。 見学業務の事前レクチャー 訪問させていただく事業所で、訪問日にどのような業務を見学させていただく予定かを事前に訪問メンバーに伝え、必要に応じて実際の画面だとどのように操作をするのかをレクチャーします。 これによって、理想的な操作、遷移はこうだという情報を持っていくことができるので、ユーザーがどこで課題を感じているかの解像度が上がりやすくなります。 有識者の同行 ユーザー訪問には、社内のドメインエキスパート(介護業界経験者)やカスタマーサクセス担当者、セールスメンバーなどにも同行してもらっています。ドメインエキスパートやビジネス部門のメンバーは自身の専門知識や経験を通じて、より深い洞察を提供してくれます。彼らとの協力により、私たちはユーザーのニーズや要件をより高い解像度で把握することができます。その結果、開発チーム全体が的確な方向性を持ち、効果的なプロダクトを提供することができると感じています。 ユーザー訪問の効果と継続性 プロダクトへの直接的な効果 ユーザー訪問によるプロダクトへの直接的な効果として、やはりユーザーの課題にダイレクトに直面するので、生の声をプロダクトに反映させることができる点があります。 例えば、50〜60代の年齢層のユーザーであれば、「今の画面だと文字が小さいなぁ」という反応をいただくことができたり、「曜日の色が分かれていないと見えづらい」などといったフィードバックがあります。 副次的な効果 定期的なユーザー訪問を通じて、デザイナーやエンジニアが業務に対する高い解像度を持つことができるようになりました。彼らが実際の現場を見学し、ユーザーと直接対話することで、プロダクト開発における意思決定が迅速かつ的確に行われるようになりました。さらに、ユーザー訪問に参加したチームメンバーが「自分が訪れた事業所でも同様の課題がある」と気づくことがあります。これにより、私自身がプロダクトマネージャーとしても安心感を持つことができます。 また、ユーザー訪問時やユーザーインタビュー時に撮影した内容を、チームメンバーで見る上映会をすることがあるのですが、実際に訪問していないメンバーが参加してくれたり、「この人に喜んでもらえるプロダクトを作りたい！」というモチベーションにつながっていたりするので、とてもいい取り組みだと感じています。 さいごに ユーザーを深く知ることと解像度の維持は、私たちにとって非常に重要です。ユーザーのニーズや要件は絶えず変化しており、1回の訪問だけでは完全には把握できません。そのため、私たちはユーザー訪問を継続し、定期的に現場を訪れることで、ユーザーとの関係を深めています。今後も、私たちは常に最新の情報を得ながら、ユーザー中心のプロダクトを提供していきたいと考えています。

初めまして。 エス・エム・エスのBPR推進部EA推進グループの西田です。私の簡単な自己紹介からさせていただきます。大学卒業後、2017年4月に人材紹介会社に入社し、求職者集客のマーケティング業務を行いました。その後、2018年3月にエス・エム・エスにカイポケのインサイドセールスとしてジョインし、インサイドセールスの小チームリーダー、営業組織全体の営業企画、マーケティングと経験を積みました。2023年4月からBusinessArchitect（以降 BA）としてカイポケ全体の既存事業の高度化/社内業務の高度化・効率化を担当しています。 BAになったキッカケ カイポケでは、入社時点から業務基盤としてSalesforceをメインに利用していましたが、 日々の行動指標やKPI管理ではまだまだスプレッドシートが使われていました。 そんな時Salesforceのセミナーに参加し、システムとしてのパワーを体感した私はその後もインプットを深める中で、レポート/ダッシュボードだけではないSalesforceの機能を知り「うちでやっている〇〇は、Salesforceの△△を活用したら解消できるかもしれない」というアイディアが浮かぶようになり始めました。 その当時、部内のこういった課題を取りまとめて、エンジニア（当時は業務委託のみ）と会話をする、という役割を持った人がおらず、改善アイディアに対する合意形成も上手くできませんでした。 BA不在当時のやり取り 事業サイド：商談オブジェクトに〇〇という項目を追加してほしいです。項目を1つ追加するだけだから短納期でお願いしたいと考えています。 ↓ エンジニアサイド：その項目を追加するには△△について調査する必要があり時間がかかりそうです。また、既に似たような項目がありますがコチラを使って対応できたりしないのでしょうか？そもそもSalesforceの商談には～という機能があって、、、 ↓ 事業サイド：こちら側の意図した通りに実装してほしいので進めてもらえますか？ というような具合で、事業サイドとしてはSalesforceやシステムについて、エンジニアとしては事業サイドのビジネスニーズ/背景について、まだ理解を深める余地がある状態でした。 「自分がここの間のかけはしになったら良いのでは？」と思うようになりました。 Salesforceの入門資格であるアドミニストレーターを取得した上で、当時の上司に「ココの役割が足りず、必要な改修を進めることができていないので担当させてほしい」とお願いし、ココの役割を営業担当と兼務でやり始めました。これがBAとしての第一歩になって現在の役割を担当しています。 そもそもBAとは？ BAはBusinessArchitect（ビジネスアーキテクト）の略称です。一般的にはBusinessAnalyst（ビジネスアナリスト）と呼ばれたりしています。 iiBA という組織の定義によると「ビジネスアナリシスとは、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」とされています。 プロダクト開発の文脈でもBusinessAnalystという役割の人がおります。当社の棲み分けとしては、顧客の業務改善⇒プロダクト開発部、社内の業務改善⇒BPR推進部、というような具合です。 最近では、DXの取り組みが注目されている背景からIPAがBusinessArchitectという役割について明文化してくれており「DXの取組み（新規事業開発/既存事業の高度化/社内業務の高度化・効率化）において、ビジネスや業務の変革を通じて実現したいこと（＝目的）を設定した上で、関係者をコーディネートし関係者間の協働関係の構築をリードしながら、目的実現に向けたプロセスの一貫した推進を通じて、目的を実現する人材」というようなまとめ方もされています。 引用元) 「DX推進スキル標準」人材類型の定義 エス・エム・エスでのBAの役割 私達の部署においては「戦略推進/支援の中で、価値提供先の要望の深堀りやソリューションの提案を行うことはもちろん、業務担当者や他部門の関係者など、多くのステークホルダーを巻き込みながらその中心となり、推進の主体となる役割を担う者」としております。 基本的には、社内業務の高度化・効率化についての課題に対応しておりますが、最近は既存事業の高度化にもチャレンジしております。 社内業務の効率化というとバックオフィス系の効率化というイメージを持たれる方もいらっしゃるかもしれませんが、私のところでは主にフロントオフィス（マーケティング/セールス/カスタマーサクセス/サポートetc）の課題について取り組んでおります。バックオフィス（契約管理、販売管理etc）の課題との比率的には６：４ぐらいになります。 事業の戦略や重点Issueを踏まえた上で自分のリソースをどのように配分するかを判断して動いているようなイメージです。 BAの2つの視点から思うエス・エム・エスで働く魅力と楽しさ 私自身、今の環境が非常に面白いなあと感じています。 「Salesforceの活用の仕方」と「価値提供先との距離」の2つの視点からお伝えしたいです。 Salesforceの活用の仕方について 製品としてはAccountEngagement（旧：Pardot）、SalesCloud、ServiceCloudを利用しており、一部Salesforce外で開発したシステムもありますが、マーケティング、セールス、カスタマーサクセス、サポート、契約管理、販売管理などの業務プロセスのほとんどをSalesforce上でカバーしています。 これは私のポリシーなのかもしれないですが、何かSalesforce改修を行う際は、できるだけ標準オブジェクトや標準項目、標準機能を使ってビジネスニーズを満たせないか？という観点でソリューションを検討するようにしています。私自身、Salesforce好き、ということもあるかもしれませんが、標準周りの機能を使っておけばメジャーリリース等で機能追加されるかもしれない、標準オブジェクト/標準機能に関連した強化が行われるかもしれない、と期待していますし、何より実装/保守/メンテコストが安くなります。 念を押してお伝えしたいのですが、ApexやVisualforce、LWC（LightningWebComponent）などのカスタム開発を全く行わないわけではありません。価値を実現し、ビジネスニーズを満たし続けるために最適なQCD（Quality/Cost/Delivery）を常に考慮に入れてどのように作るかを判断するようにしています。ビジネスの動きも常に変わっていくことも考慮し、作り込みすぎずに標準機能を踏まえながら小さく作って検証を回すような動きになることが多いです。 価値提供先と距離が近い 今の立場で非常にありがたいと感じていることは、「価値提供先と一緒に問題抽出や課題設定を行うことができる」ことです。 中長期でどのようなことを実現したいか？をきちんと理解し、あるべき姿と実現したい世界観を事業側とすり合わせるようにしています。 意識としては、事業側で時間/労力をかけて作った戦略を念頭に置き、その戦略を推進するための戦術実行を支える、という具合です。また、戦術を着実に実行するために、BAの立場からシステム外のオペレーションについても問題整理/課題設定、提案を行う場面もあります。 そのため、細かい保守/エンハンス案件、一定規模以上のプロジェクトなど規模の大小にかかわらず、事業としてどんな姿になっていきたいか？今注力すべきIssueは何か？を念頭に優先順位を決めるようにしています。 価値提供先との距離が近いので、取り組みによるアウトカムが見えやすく、フィードバックループを着実かつ素早く回すことができます。そのため、価値提供先への貢献実感を持って業務に取り組むことができていると感じています。 また、事業側とも距離が非常に近いので、問題抽出、課題設定段階では、なるべく一次情報に触れてインプットを行うようにしています。 業務を遂行するのはあくまで現場メンバーであることを意識し、実際にDoする人が納得感を持てるように設計や運用の落とし込みをする必要があるためです。 例としては「管理者やマネージャーから聞くのと合わせて、現場メンバーが業務しているところを見る」「実際のデータを見たり、分析する」ようなことをしており、時には事業側と一緒に「法令文書を調べる」などもしております。 実体を繋ぎ合わせる作業を事業担当者と一緒に行うことで現状認識が統一され、今まで顕在化してはいなかったけど実は原因ってココだよね、と言った整理もできるようになります。 ワークとしては、 EventStorming を行うことが多いです。 終わりに 私たちの部署ではBusinessArchitectやSalesforce エンジニアがとても不足しています。業務に近いところで戦略推進/戦術支援をしたい、Salesforceの機能をフル活用できるようにスキルアップしていきたいという方にはとてもおススメです。ご興味ありましたらお声掛けいただけますと嬉しいです。

こんにちは、Analytics&Innovation推進部の小貝（ @oddgai ）です。 先日 ブログでも告知していた ように、9月14日(木)～15日(金)に開催された 日本オペレーションズ・リサーチ学会 2023年秋季研究発表会 にて登壇予定だったのですが、体調不良により残念ながら参加できなかったため、発表に使う予定だったスライドを公開いたします。 弊社のOR分野における取り組みを知っていただきたいのはもちろん、個人的には今回の研究発表会をかなり楽しみにしていたので、その気持ちに区切りをつける意味でも公開いたします。興味のある方はぜひ読んでみてください。 なお、内容は過去に小貝が書いたブログ記事をまとめたものになります。 tech.bm-sms.co.jp 弊社では、データサイエンティストやエンジニアの採用を積極的に行っています。ORを研究している方、研究内容に興味をもっていただけた方はぜひカジュアル面談にお越しください！ open.talentio.com

カイポケの SRE 担当の有賀です。 社内では Mac で Docker Desktop を使うのが標準的になっている中、 Docker Desktop 以外の選択肢も試してみようと思い、 Docker Desktop や、社内で使っている人のいた Rancher Desktop を調べはじめました。その仕組みを調べている中で Rancher Desktop が採用している Lima がGUIを利用しない用途だと必要十分と感じたため、 Lima を使うことにしました。 Macを使って検証・構築しているため、Macでの仕組み・動作が前提になっています。 Docker を動かす仕組み(前提) Docker Desktop と Rancher Desktop の仕組みを見ていきます。 基本的には Docker を Mac 上で動かすためには仮想環境上にLinuxを建ててその上で dockerd を動かしているため、どちらも似たような構成になっています。 Docker Desktop Docker Desktop を動かす場合には、現在だと Apple の Virtualization framework を使って Linux 仮想マシンを動かしています。 その上で dockerd, containerd が動いており、この dockerd, containerd 上で Docker コンテナ を作って我々は Docker を利用できるようになっています。 参考程度にですが、以下のコマンドを実行すると、図で書いた Linux マシンに入れるので、 ps コマンドなどで dockerd が動いているのが確認できます。 docker run -it --rm --privileged --pid=host alpine:edge nsenter -t 1 -m -u -n -i sh / # ps aux | grep dockerd 2 root 0:00 dockerd --host-gateway-ip=198.19.248.254 余談ですが、一昔前までは Hypervisor が使われており、Mac上でDockerを動かすと遅いと言われる一因となっていたようです。また、現在でも Docker Desktop の 設定 から切り替えることが出来ます。 Rancher Desktop Rancher Desktop を動かす場合には、 公式ページ に載っている以下の図のように、Lima/QEMUを使ってLinux仮想マシンを動かしています。 こちらもDocker Desktop同様、そのLinux上で containerd/dockerd を動かしています。 図は https://rancherdesktop.io/ より引用 Rancher Desktop が提供しているのはこの仕組みと、図の通りDocker CLIを始めとするいくつかのCLIツールや、Lima などの OSS とGUIのインターフェースをまとめて提供するものになっています。 つまり、GUI を必要としない場合、 Docker CLI や Lima を各々インストールすれば、Docker を動かすことが可能になりそうだということが、Rancher Desktop を調べていてわかりました。 Lima を使ってみる Limaは先述した Rancher Desktop や Finch などの一部で使われている Mac 上で Linux 仮想マシンを動かすためのOSSです。 今回、筆者はGUIを必要としておらず、Linux仮想マシンへのアクセスが容易な点もあり Lima で Docker を動かすことにしました。 Lima は基本的には QEMU での仮想マシンの立ち上げを行いますが、Docker Desktopが利用している Virtualization を使った仮想化も対応しているため、速度の比較も行いました。 検証したマシンは Apple M2 Max で メモリ 64GB です。 インストール brew を使って簡単にインストール出来ます。 $ brew install lima 起動 dockerd が入った仮想マシンを動かすためのテンプレートが Lima には用意されています。 そのテンプレートを使って仮想マシンを起動していきます。 以下のコマンドを打つことで、 テンプレート にある dockerd が入った仮想マシンを起動することが出来ます。 $ limactl start --name=default template://docker 選択肢が出てくるので「Proceed with the current configuration」を選択します。 しばらく待っていると、仮想マシンの立ち上げが完了するので、以下のコマンドで仮想マシンの list を見ると、 qemu を使って起動されていることがわかります。 $ limactl list NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK DIR default Running 127.0.0.1:60022 qemu aarch64 4 4GiB 100GiB ~/.lima/default また、lima の仮想マシン上で実際 Linux が動いていることを以下のコマンドなどで確認することが出来ます。 $ lima uname -a Linux lima-default 5.15.0-72-generic #79-Ubuntu SMP Tue Apr 18 16:53:43 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux Docker CLI をインストールする Docker CLI のインストールは Dockerの公式 に書いてあるのでそれを参考に実施します。 $ curl -O https://download.docker.com/mac/static/stable/aarch64/docker-24.0.2.tgz $ tar xzvf docker-24.0.2.tgz $ sudo xattr -rc docker $ sudo cp docker/docker /usr/local/bin/　# 当然 /usr/local/bin に置かなくても使えるので、必要なければこれは実施しなくても良い HelloWorldをしてみる Lima の中の dockerdにアクセスできるようにして、上記でインストールした Docker CLI を使って hello world をしてみます。 DOCKER_HOST を Lima に向けてから、hello-world を動かします。 $ export DOCKER_HOST=unix://$HOME/.lima/default/sock/docker.sock $ docker run hello-world ~ 省略　~ Hello from Docker! ~ 省略　~ 無事、動作が確認できました。 Virtualization を使った仮想マシンで Dockerd を動かして比較する QEMU よりも Virtualization framework を使った仮想化のほうが実行速度が早いとのことなので、実際に試してみます。 Virtualization を使った仮想マシンで Dockerd を動かす Virtualization を使った仮想マシンを起動するには以下のコマンドで起動できますが、dockerd は入っていないので、 https://github.com/lima-vm/lima/blob/master/examples/experimental/vz.yaml を元に docker をインストールするように修正したものを指定する必要があります。 $ limactl start --name=vz template://experimental/vz 以下のように用意した vz-custom.yml テンプレートを使うようにコマンドを打って、仮想マシンを立ち上げると、Virtualization を使った仮想マシンでDockerd を動かすことが出来ます。 vz-custom.yml vmType: "vz" rosetta: enabled: true binfmt: true images: - location: "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img" arch: "x86_64" - location: "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-arm64.img" arch: "aarch64" mounts: - location: "~" - location: "/tmp/lima" writable: true mountType: "virtiofs" networks: - vzNAT: true containerd: system: false user: false provision: - mode: system script: | #!/bin/sh sed -i 's/host.lima.internal.*/host.lima.internal host.docker.internal/' /etc/hosts - mode: system script: | #!/bin/bash set -eux -o pipefail command -v docker >/dev/null 2>&1 && exit 0 export DEBIAN_FRONTEND=noninteractive curl -fsSL https://get.docker.com | shrootless systemctl disable --now docker apt-get install -y uidmap dbus-user-session - mode: user script: | #!/bin/bash set -eux -o pipefail systemctl --user start dbus dockerd-rootless-setuptool.sh install docker context use rootless probes: - script: | #!/bin/bash set -eux -o pipefail if ! timeout 30s bash -c "until command -v docker >/dev/null 2>&1; do sleep 3; done"; then echo >&2 "docker is not installed yet" exit 1 fi if ! timeout 30s bash -c "until pgrep rootlesskit; do sleep 3; done"; then echo >&2 "rootlesskit (used by rootless docker) is not running" exit 1 fi hint: See "/var/log/cloud-init-output.log". in the guest hostResolver: hosts: host.docker.internal: host.lima.internal portForwards: - guestSocket: "/run/user/{{.UID}}/docker.sock" hostSocket: "{{.Dir}}/sock/docker.sock" message: | To run `docker` on the host (assumes docker-cli is installed), run the following commands: ------ docker context create lima-{{.Name}} --docker "host=unix://{{.Dir}}/sock/docker.sock" docker context use lima-{{.Name}} docker run hello-world ------ limactl start --name=vz vz-custom.yml 速度を比較する 速度の比較には、flyway を使った MySQL の DB のマイグレートを行うものがあったのでそれでの比較をしました。 やり方は割愛しますが、以下のような結果になり Lima で Virtualization を使った仮想マシンを利用すれば、今回の利用用途だと、 Docker Desktop と同じ速度で利用できることがわかりました。 Dockerdを動かしているアプリ マイグレートにかかった時間 Lima (QEMU) 61秒 Lima (Virtualization) 45秒 Docker Desktop 46秒 最後に 以上、「Limaを使ってDockerを動かしてみた」について書きました。 そこまで難しいことをしないのであれば Lima (Virtualization) でも十分使えるという結果になりました。 また、Virtualization を使った Colima という Lima で動いているOSS もあるのでこちらを Docker を無料で使いたいことがあれば使うのも良いかと思います。 記載している内容に誤りなどがあれば、 https://twitter.com/BM_SMS_Tech までご連絡ください。

エス・エム・エスのプロダクト開発組織では、メンバーそれぞれがコミュニティを代表する一人として考え行動する「 あなたがコミュニティ 」というバリューを大切にしています。 このバリューを同組織の人事という立場から実践しようとしているのが、プロダクト開発部採用・組織開発支援グループの @fkc_hr です。ほとんどのメンバーが技術職であるプロダクト開発組織に対し、深代さんはどのような形でコミュニティづくりに貢献しているのでしょうか。具体的な取り組みやそのモチベーションについて、深代さんに聞きました。 正解がないなか、自分たちの力でカルチャーをつくっていく ——ご経歴と普段の業務内容について教えてください。 新卒で人材系ベンチャーに入社し、インターン時代からIT領域の人材紹介の営業を担当していました。その後、支店の立ち上げからクローズ、新規事業の営業なども経験しました。一貫して、成果を出して介在価値を見出さないと、支店が存続できない/顧客に価値提供できない/仲間を増やせない/事業が続かない……という意識を持っており、顧客志向と達成志向が身についた時期だったと思っています。そんな時に、メンバーの成長や顧客満足度の向上なども含め、組織や事業の継続性や成長に貢献できる仕事にチャレンジしたいと思うようになり、転職活動をしているなかで、エス・エム・エスは人事の側面から横断的に関われるというオファーをいただき、転職を決めました。 現在は、プロダクト開発組織の採用業務をメインで担当しています。採用における母集団形成のための媒体活用や人材紹介会社との連携、選考体験を向上させるための選考オペレーションの設計、適切な面接官・面談官のアレンジなどを社内のEM陣や各メンバーとコミュニケーションを取りながら進めています。また、2023年度から所属しているグループ名が「採用・組織開発支援グループ」となったことで、採用だけでなく、広報活動として当社プロダクト開発組織の外部発信も推進しはじめており、前年度から徐々に自分自身も関わらせて頂けているため、より社内・社外に対して当社プロダクト開発組織の良さを伝えていけたらと思っています。 ——顧客志向や達成志向が根底にあるとのことですが、エス・エム・エス入社後、そうした価値観が変化した、あるいは理解が深まった部分はありましたか。 扱える”変数”が増えたように感じています。前職では自身の顧客への貢献や、自身の目標達成という範囲で仕事をしていましたが、エス・エム・エスにおいては自身が担当しているプロダクト開発の採用・組織開発だけ考えればいいのではなく、事業や他複数の組織も踏まえた全体最適とのバランスを複合的に思考する必要があり、捉えないといけない変数が必然的に広がったように思います。そのため、分かりやすい貢献や達成ではなく、本質的に会社や事業成長につながる「成果」の捉え方が変わったように思います。 ——「あなたがコミュニティ」というプロダクト開発組織のバリューをどのように解釈されていますか。 「ボトムアップであれ」という意味合いに受け取っています。たとえば、技術責任者の田辺さんからは、組織全体に対し「どう思いますか」「意見をください」といった形で問題が提起され、社歴やロール、職種関係なく意見を言い合える雰囲気があります。上で決まったことが下に降りてくるという体制ではありません。 私のなかでは、人事部内でよく言われている「風土はこれまでの取り組みによってできてきたもの、カルチャーはこれからつくっていくもの」という表現がしっくりきています。正解がないなか、自分たちの力でカルチャーをつくろうとしていくことが「あなたがコミュニティ」ということなのだと解釈しています。 原動力は「入社してくれた方にもっと活躍してほしい」という想い ——「あなたがコミュニティ」というバリューに関連して、どのような活動をされていますか。 たとえばボトムアップでフラットに意見を言えるように、というカルチャーに、新入社員の方々も早期に馴染めるように「同期会」というslackチャンネルを立ち上げました。 そこでは、気軽にちょっとした困りごとを相談できるような場として、例えば「経費申請の仕方が分からない」「こういう資料が欲しい」といったことを発信してもらい、人事側から早めにこれらの困りごとに対応できるようにしています。 またオンラインミーティングの場を設けて、同期同士の自己紹介や所属チームの紹介ができるようにもしています。今後はメンバーの増員に合わせて四半期ごとに同期会をつくっていこうと思っています。 ▲Slackチャンネル「同期会」でのやりとり 特に2023年4月入社のメンバーはまさに私が採用を担当した人たちなので、各メンバーの経歴や特徴などを把握しながら、メンバー同士がつながるきっかけとなるコミュニケーションを意識しています。 ——同期会のコミュニケーションにおいて、気をつけているポイントがあれば教えてください。 前職での仕事のスタイルによって各メンバーの考え方は違いますし、喋るのが好きな人もいれば、あまり自分からは発言したくない人もいるなど、それぞれに個性があります。コミュニケーションのルールをつくってそれをメンバーに押し付けるのではなく、状況に応じたコミュニケーションを取ってもらえたらと思っています。 ——そうした取り組みの原動力はどこにありますか。 自分が携わった採用活動を通して入社してくれた方にもっと活躍してほしい、そのための力になりたいという気持ちが根底にあります。もともと人が好きなこともあり、単純にそれを楽しく思えるところも大きいのかもしれません。人事として採用活動を担当しているのは、プロダクト開発組織のなかで私1人だけです。チームに所属していない分、いろんなところで盛り上がっているお祭り騒ぎに参加している感覚がありますね。 「社内駆け巡り」で、事業・プロダクト・人の理解を深める ——ほかにはどのような活動をされていますか？ 色々なことを行っていますが、あえて名前をつけるなら「社内駆け巡り」という活動です。計画的に実施しているわけではありませんが、面接に同席したり、採用に関係ありそうな社内のミーティングに参加したり、社内のSlackチャンネルを巡回したり、オンラインホワイトボードサービス Miroの付箋を好きなチームに貼りに行ったりなど、さまざまなところに顔を出すようにしています。 ▲「社内駆け巡り」活動での深代さんのコメント ——そうした取り組みを主体的に行うことは、重要性を理解していてもなかなか難しいと思います。深代さんのなかで何がモチベーションになっているのでしょうか。 そもそもエス・エム・エスの採用は、会社や事業の継続、成長のために行っているものです。今、必要な人を採用をするためには、どのような事業やプロダクトが運営されていて、どのような人がどういう仕事をしているのか、深く理解する必要があると思っています。誰かに依頼されたからではなく、自分の理解のために積極的に情報を取りに行くようにしています。 もともと人事の仕事に就くことを目的にしてエス・エム・エスに入社したわけではないというのも、積極的に社内駆け巡りができている要因の1つかもしれません。どうすれば会社が伸びるのか、自分が事業のためにしなければいけないことは何か、人事という立場から考え続けていたところ、自ずとこうした行動を取るようになっていました。 前職でも社内外の情報を取りに行く意識は持っていましたが、積極的に人に話を聞くところまではできていなかったように思います。ただ、エス・エム・エスに入って以来、自分がやろうとしている採用や組織改善などは1人だけでは達成できないと考えるようになったので、いろんな人に協力してもらおう、わからなければとにかく人に聞きに行こうという意識が強くなりましたね。会社の雰囲気的に何でも聞いたら教えてくれるし、論理が通っていることも、理解を深める面白さだなと思っています。 「深代に聞けば何か答えてもらえるんじゃない？」と思ってもらえるように ——そのほかの取り組みについても教えてください。 RubyKaigiなどのコミュニティイベントへ参加しています。登壇手続きや協賛関連の仕事だけでなく、LTなどを聞いたり、他社の人事の方と話をしたり、人と人をつなぎ合わせる役割を担ったりと、その場にいるからこそできる動きをするようにしています。こうして社内外の方に「エス・エム・エスのプロダクト開発組織の採用をしている人はあの人だ」と知ってもらえることが重要だと考えています。 また、採用広報の仕事の一環として技術ブログの運営にも関わっています。「この人ならこういう記事が書けそう」と案を出したり、同期会のメンバーに入社エントリを書いてほしいと打診したりなどして、記事の企画をサポートしています。 ▲入社エントリー記事の執筆依頼をしたときのやりとり ——一連の活動を通してどのような効果が出てきていますか。 採用にどれだけ効果があるか定量的に測るのは難しいですが、メンバーからいろんな質問に打ち返せるようになったり、リファラル採用の相談を受けるようになったりと、「深代に聞けば何か答えてもらえるんじゃない？」というイメージを持ってもらえるようになってきたと感じています。 ——これまでの活動に対する周囲からの反応はいかがですか。 デザイナーを対象とした社外向けのイベントを企画した際、登壇者が作成したイベント資料へフィードバックを行ったのですが、「ちゃんとつっこんで指摘できるのは良いこと」などとフィードバックをいただきました。自分としてはあまり意識せずやっていることなのですが、自分の役割に制限を設けず、誰かのためになることをしようという姿勢が認めてもらえているのだと感じた事例です。 「採用に関わったメンバーの成果が出てくる日が楽しみ」 ——現在、課題に感じられている部分や苦労されていることなどはありますか。 今私が取り組んでいるような活動は、このままだと属人化してしまうリスクがあると思っているので、チームとして機能できるようにしていきたいです。そのためには、やはり人事の仲間が欲しいですね。また、長期的な目線で自身の活動を捉えていく点も課題の1つだと感じています。 ——最後に、今後の展望をお聞かせください。 これまでの中途採用と並行して2025年度の新卒採用に向けて動こうとしているところです。シニアのエンジニアと若手エンジニアでは当然コミュニケーションの内容も変わってくるので、より多くのコミュニティに伝わるような視点を持ってエス・エム・エスの魅力を伝えていく必要があると考えています。 また、私が人事として採用に関わった社員もすでにチームに馴染んでいる様子や、さまざまな場所でのフィードバックは聞いているのですが、もう少しすれば、よりプロダクトや事業に貢献している姿を社内外に発信していける事例がたくさん出てくるはずです。そうした成果が見届けられることを、今からとても楽しみにしています。

エス・エム・エスの技術責任者 @sunaot です。この記事では組織の文化をつくっていくときにどういうことをしているかを説明します。文化をつくるといったときに、もちろんトップレベルでどういう状態を目指しているかは大切なのですが、普段からチームづくりに心を砕いている人はよくご存知の通り、細かな日常での振舞いが大事になるという話です。 なぜ過剰にへりくだった表現に対してツッコミを入れるのか？ 例として、「社内に対しての非常に丁寧な言葉使いに対してどのように振る舞うか」をテーマに説明をします。「なぜ過剰にへり下った表現に対してツッコミを入れるのか」と言い換えてもいいかもしれません。 仕事をしているとたまに「〜していただけたら幸いです」「ご教示ください」といった言い回しに出くわすことがあります。所属している組織の文化によっては違和感を感じることなくスルーするでしょうし、仮に若干の違和感を感じたとしても「その人はそういう人なのだ」としてやはり流してしまう人が多いと思います。 しかし、私はわりとかなりの頻度で「それは望んでいる態度ではないのです」ということを伝えます。たとえば、「ありがとうございます。〜でいいと思います！あと、同僚なので『これでお願いします！』くらいのノリで行きたいです！」というような返信をしたりしています。言葉使いは信頼関係から来るシグナルなので、そこをきっかけにそもそも信頼関係を築けるようにしていくというのも並行してやりますが、それも含めて組織の前提を『社交儀礼としての糖衣を取り去り、相手を信頼してストレートな要求をしてもいい組織だ』という基本的な信頼へ置きたいというのを伝えていくようにしています。 言葉使いに遠慮があると、どうしてもマーケットやユーザーへのベストを考えたときに、周囲に対してタフな要求をするということの難易度が上がり、最短でマーケットへ価値を届けるというのが難しくなります。そこで 私たちの組織ではまず最短でマーケットへ価値を届けるのが一番重要なことで、同僚はそこに向けて一緒に困難へ取り組む仲間だというスタンスで居たい そのときに、遠慮や過剰な丁寧さは不要で、それよりも目の前の課題をどうクリアしていくかを率直に話せる関係性を大事にしましょう という主旨を理解してもらうようにしています。 特に役職がついていたりすると、世間においてはそれなりに尊重をして然るべきという理解をされることは多く、必要以上に丁寧な物言いを見かけることがあります。これは上意下達の文化が強く、それが事業フェーズに合っているのであればその方がワークするのでしょうが、2023年時点のエス・エム・エスはそうではなく、むしろ現場ドリブンでの新しい発見こそが次の成長やリスク認識の種になるというフェーズです (あと20年はおそらくそうでしょう)。この状況で『役職上上位にあたる人は尊重すべきであり、より正しい意思決定をできるのだ』という認識は完全に実情に合っていません。『立場によらず、事実や合理的なロジックによってユーザーやビジネスにとってより良い意思決定がされるべき』という考え方が「普通」になることはとても重要だと考えています。 望ましい振舞いを皆が見える場で表明してチューニングする ではそのような組織はどうやったらできあがるでしょうか。もちろんこうしてどういう状態を目指しているかを明文化して表明していくことも大切ですが、それだけでは文化は定着しません。組織の文化は行動の積み重ねが作ります。文化として目指している価値観のように行動をしている人が増え、お題目を唱えなくても価値観通りの振舞いが組織に溢れていると、皆がそのような組織のスタンダードに従って行動をするようになっていきます。 冒頭で挙げた言葉の使い方というのは非常に小さい話で、マネージャーがそのような細かい点へ口を出すのは適切でないように思われるかもしれません。正直なところ、私自身も細かいことを言われるのが人並み以上に嫌いな性格なので、マイクロマネジメント臭がして嫌だなと感じるときもあります。しかし、How に口を出すマイクロマネジメントと組織の文化をつくるための行動のチューニングは別のものだと考えて、How への干渉をなるべくしないことを意識する一方、組織の中で望ましい振舞いをなるべく広く皆が見える場で表明してチューニングしていくことは極力行うようにしています。前述の通り、そうして皆がどのように行動するかが組織の文化をつくると考えているからです。

はじめまして！QAエンジニアとして、2023年3月にエス・エム・エスに入社した金川です。現在、介護事業者向け経営支援サービス「カイポケ」のQA業務に携わっています。 この記事では、入社エントリとして私がエス・エム・エスを選ぶまでの経緯や、実際にエス・エム・エスで働いてみて感じたことなどをありのままに書いてみようと思います。 入社を少しでも検討している、そんな方へも参考になるものがあれば幸いです。「介護のことはよくわからないし不安……」という方もいらっしゃると思いますが、その辺りも後述しますのでご安心ください。 カジュアル面談も絶賛受け付けていますので、ぜひご応募いただけると嬉しいです。 入社まで QAデビューの場は前職でした。もともとイラストを描くことが趣味ということもありペイントアプリを制作している会社に入社し、なんと入社初日にQAチームなるものに配属されることを知らされました。そこで初めてテストという業務を一から学びました。 そしてQAとして更なるチャレンジをしたく転職を考え始めた時期に、エス・エム・エスに勤めている知人に誘ってもらいカジュアル面談を実施してもらいました。 正直なところ私自身その時点では介護への知識は皆無だったのですが、面談の場で「介護業界へ貢献したい」という思いやビジョンを聞いて強く興味を惹かれました。介護はこれからも成長していく分野であり、自分自身や自分の子世代もいずれお世話になるであろう業界です。そのように社会から期待されているサービスに携われるということにとても関心を持ちました。 ほかに求めていた条件として、制限なく自発的に動ける、在宅業務でもコミュニケーションが円滑に取れる会社を求めていたところがあり、それらの部分がクリアできそうだったのでエス・エム・エスへの入社を決めました。 初めて触れる介護業界への不安を払拭する エス・エム・エスへの転職で最も不安に感じていたのは、介護という領域への理解が不足していた点でした。先述の通り、前職ではペイントアプリという自分自身もユーザーとしての視点に立ちやすいプロダクトを扱っていたのに対して、介護という領域は馴染みのあるものではなかったため、QAとしてのスキルを前職時代と同じように発揮できるのかが不安でした。 しかし、この不安はオンボーディングのプロセスの中で払拭することができました。実は、エス・エム・エスに入社してくるメンバーには、私と同じように介護についての知識を元々持っていない方も多いので、エス・エム・エスのQA部門では前提知識がない方でも大丈夫なように、介護ドメインの知識を含めてオンボーディングの時間をしっかり取っています。 オンボーディングは具体的には以下のような流れで行われました。 1. 介護業界・ドメインについて知る まず最初に、メンターからざっくり介護について説明してもらえる時間がありました。 社内には介護業界のあれこれについてまとめられた資料が様々あるので一つ一つ目を通していきます。 社内には元々介護業界にいたドメインエキスパート職の人もいて、そういった方々の知見も資料には含まれており参考になりました。 2. 「カイポケ」を実際に操作して理解する マニュアルに沿ってユーザーの実際の操作を意識し、一通り機能を触っていきます。 「時間をかけてもいいから、じっくり触ってみてほしい」とメンターが言ってくれたので、自分のペースで操作を習得することができました。疑問が生じたときは都度Slackで質問を投げ、気付いた先輩がすぐ丁寧に教えてくれました。 私の場合は、先述の不安もあったため、長めに時間を取らせてもらいましたが、「早く実践で鍛えたい！」や「経験者だから不要！」という方もいると思うので、その辺りはメンターと相談しつつ柔軟に調整できます。 3. ジョイン先のチームごとに必要になる知識を身につける カイポケの開発組織では、プロダクトごとのチームにジョインして業務に臨みます。担当するプロダクトによって必要になる業務知識や関わるメンバーも異なるため、各チームへのジョインにあたって必要な知識をオンボーディングでは付けました。チームのメンバーについての説明も事前にメンターからして貰えます。 QAができる価値提供 ここからは実務についての話です。 そもそもQAとは「品質保証」を指しており、バグを見つけることにとどまらず、ユーザーのニーズおよび満足感を満たしているかを考えて、プロダクトの品質向上に貢献することも重要な役割とチームでは捉えています。 後者の役割を果たすためには、ソフトウェアの仕様だけではなく、ソフトウェアの外側を含めたユーザーの業務を解像度高く理解する必要があります。 正直に書くと入社時点での介護へのイメージは「世話が必要な人の手助けをする」という単純なものしかありませんでした。 しかし裏では何時何分にこのサービスを提供したという記録や、月末月初に国民健康保険団体連合会（国保連）へ明細書や請求書を提出するいわゆる請求と呼ばれる作業など、様々な業務が付随していることがオンボーディングを経て理解できました。 カイポケのような電子ソフトがなかった時代は、それこそ紙にペンで記録するしかないわけですから夜中までずっと作業をしていたという話も耳に挟み驚きました。 ただ、オンボーディングで介護について学んだとは言っても、付けることができたのは机上での学習で得た知識のみです。QAとしてユーザーに近い目線で業務を理解するためには、現場の方の生の声を聞くことも大事なので、介護職に就いている知人にヒアリングをさせてもらえないかと考えました。実際に相談してみたところ、快く引き受けていただき、偶然カイポケのユーザーでもあったので、実際に使っている立場としてどのような感想を持っているか？も併せて質問させて貰いました。 最も印象に残ったのは、「実績を付ける」という記録業務です。 利用者さん毎にカレンダーがあり、利用があった日には「1」を付け、利用がなかった日には「×」を付けるという作業です。このように書くとシンプルに聞こえますし、私自身マニュアルを見ながら操作をした時には時間を掛けずにさっくりと済ませていた工程だったのですが、この作業に最も気を遣っているとお聞きしました。 実績登録機能の説明 現場では慌ただしく動くのでPCを常に持ち運ぶわけではなく、ボールペンを持って移動しては、テーブルの上に置いている紙にその時の記録を付けていくそうです。 紙からカイポケへの転記作業については「月末月初にまとめて行っている」とお聞きしました。毎日マメに付けると楽なのでは？と思ったのですが、「実績を付けることだけが介護の仕事ではないから後回しになりがち」という声を聞いて納得しました。やるべきことは山積みでほかにも時間のかかる作業が多いように伺っています。 [予定を実績にコピー]という事前に立てた予定をそのまま実績へも反映できる機能もあります。 マニュアルに基づいて操作をしている際では何度も使用したのですが、この方は実務で基本的に使わないそうです。あくまで予定は予定であって、たとえばデイサービス（通所介護）において利用者さんのご家族のお迎えがあり送迎減算という請求金額の変更が発生するような日もあるようです。そして金額計算に関わってくる作業なので、慎重に行いたいというようにもお聞きしました。 「予定を実績にコピー」機能の説明 ヒアリングを行ってみて、オンボーディングのみでは不足していたユーザーの業務を解像度高く理解するという点について一歩前進することができました。 もちろんユーザーによって業務の仕方・カイポケの使い方はそれぞれ異なるはずですが、[予定を実績にコピー]機能を使わずに日毎に記録を付けるユーザーもいることを知るというスタート時点に立てた上で、実績をさらに付けやすくするには現状のような月ごとの画面では編集しづらそう、じゃあどういった改善方法が考えられるんだろう、提供日別に利用者の実績を付けられる画面で先述のようなサービス提供内容の変更にも対応できた方が使いやすいかもしれない、など考慮を巡らせることができるようになりました。 この経験を経て、ユースケースの幅広い考慮を一層大事に感じました。 引き続きヒアリングなどを通じて情報のキャッチを行い、チームで共有して意見を交わし、ユーザーへの価値提供に繋げていきたく思っています。 これから 介護は、この国においてなくてはならないサービスです。 日本では高齢化社会が進んでいますし、利用者やその家族の生活を日々支えてくれています。 そのように社会からも大きく期待を向けられている業界ではありますが、介護保険法や請求制度などとても難しい部分が多いです。 だからこそ日々学ぶ姿勢を持ち、情報共有しつつ知見を広げていっています。書籍の購入は会社の費用で行えますし、定期的に社内での勉強会も開催されています。 「カイポケ」というプロダクトに対しても、みんなが我が子のように愛を持って向き合っています。 カイポケの使い勝手をより良くして記録業務の短縮に繋げるにはどのような実装方法が最も最適か？カイポケを通して更にユーザーをサポートするにはどんな機能が求められており必要なのか？と考えを巡らせては都度意見を交わし合っています。 QA部門ではユーザー価値を大事にして一緒に品質を考えていけるメンバーを募集しています！テスト実行に強い方、チームマネジメントに強い方、介護ドメインに強い方など幅広く求めています。 少しでも介護業界に、またエス・エム・エスにご興味を持っていただけたならこの記事を書いてみてこれほど嬉しいことはありません。

現在、80人超の規模となっているエス・エム・エスのプロダクト開発組織。今の規模にまで成長する過程で、開発組織としての文化や価値観が醸成されてきました。そして現在、更なる組織の成長のために、全社のバリューを土台にしつつ、開発組織独自のバリューを言語化し、組織内に更に浸透させていく活動を始めました。活動の概要や、具体的なバリューについては以下の記事で紹介しています。 tech.bm-sms.co.jp 上の記事の内容を踏まえつつ、バリューに即した行動や考え方がどういうものなのかをよりイメージしやすくなるように、具体的なメンバーの仕事を事例として取り上げて紹介していきます。今回は、「あなたがコミュニティ」のバリューの事例として、EMの @emfurupon777 から名前が挙がったカイポケ伝送チームの @koma_koma_d を紹介します。「チームという環境をメンテナンスする」ための具体的な取り組みやその原動力についてインタビューしました。 「あなたがコミュニティ」であるために、主体的にチームづくりへ貢献する ──これまでのご経歴と、現在の業務内容について教えてください。 文系大学院の修士課程修了後、金融系のシステム開発会社などを経て、2020年4月にエス・エム・エスへ入社しました。入社後は、介護事業者向け経営支援サービス「カイポケ」の介護レセプトチームに約2年間所属し、2022年3月に今のカイポケ伝送チームへ異動になりました。現在は、カイポケリニューアルを見据えた既存サブシステムのリプレイスを担当しています。立場としては一貫して開発者ですが、入社2年目ごろから採用広報や組織改善の取り組みにも携わるようになりました。 ──「あなたがコミュニティ」という開発組織のバリューをどのように解釈されていますか。 技術責任者の田辺さんからはじめてバリューの話を聞いたとき、自分が取り組んできたことに近い考え方で、つながりがあるものだと感じました。前職時代からアジャイルなどのコミュニティに参加し、 Scrum Developers Night! などの社外の勉強会運営などにも携わるなかで、自分たちが過ごしている環境は他人任せにするのではなく、自分たちで維持・改善していくべきだという考えをずっと持っていました。 コミュニティは放っておいたら廃れてしまいます。コミュニティを維持するためには、新しく入ってきたメンバーをサポートしたり、他のメンバーが気持ちよく動けるようにしていったりといった活動が必要です。これらの取り組みを特定の誰かに担ってもらうのではなく、各メンバーが主体的に行っていくことが重要だと考えています。問題意識を持って自ら動くということが、「あなたがコミュニティ」というバリューにつながってくると思っています。 メンバーの悩みごとを拾い交流を促す「カイポケチームをよくする会」 ── 具体的に「あなたがコミュニティ」を実現するために、どのような活動に取り組まれていますか。 具体的には「カイポケチームをよくする会」という名称でチームづくりの活性化活動に取り組んでいます。例えば、マネージャー・メンバーという関係性以外で行う「ピア1on1」や、カイポケ開発組織全体に向けた「DevMeetup」というイベントなどを運営しています。 これらは、他のメンバーとの交流が少なく悩みを相談できず困っていたメンバーがいたことがきっかけでスタートした取り組みです。コロナ禍を受けてリモートワークへ移行し、チームによっては日常的なコミュニケーションが減ってしまったことで、定期的にメンバーの悩みや困りごとを拾う仕組みが求められていました。また、カイポケは現在、既存システムの開発・運用を継続しながらリニューアルに向けた開発を進めており、これに伴い組織規模も拡大しているところです。 チームが違うと通常の業務のなかではコミュニケーションを取る機会が少なくなりがちなので、カイポケチーム全体として人的な交流や他チームが取り組んでいることを知る機会を設けることも重要だと考えました。 ──ピア1on1はどのようなテーマで行われることが多いのでしょうか。 ピア1on1の「ピア」とは、英語で「同僚や仲間」を表している単語からとっています。マネージャーとメンバーという関係ではない人との間で行う1on1で、例えば、入社して日の浅い人や普段業務では関わることの少ない違うチームの人にカジュアルに話を聞きにいくといった形で行っていました。「チームをよくする会」の自分以外のメンバーにはマネージャー職の人も多いのですが、ピア1on1では対象のメンバーの組織図上のマネージャーとは別の人を割り当てるようにするなど、なるべく対等な関係で話ができるように設計しました。 もちろんマネージャーとメンバー間の継続的な関係のなかで行われる1on1も大切ですが、「お隣さん」のような対等な関係の方が話しやすいこともあると考えていたからです。たとえば、フラットな関係で普段の仕事の仕方やどういう仕事をしていきたいかなどのキャリアの話を聞いていくなかで、「そういえばこういう課題がありました」や「ここって組織としては方針どうなってるんでしたっけ？」といった話が出てきたりしました。 ──DevMeetupはどのような役割を担っているイベントですか。 月に1度開催しているDevMeetupは、新しく入ったメンバーや違うチームのメンバーなど、普段仕事で密なやり取りがない人たちとの接点を生む場となっています。カイポケの各開発チームは担当している領域が大きく異なったり、開発のやり方も違っていたりするので、チームごとにどのような開発をしているか紹介することで、「今度使おうとしているこの技術/プラクティス、あのチームで実績があるみたいだから聞きにいこう！」といった動きも生み出すことができています。 このほか、チームをよくする会の定例の場では、カイポケの開発組織に関する最近目にした課題や、これから取り組んでみたいと考えていることなどをざっくばらんに話し合うようにもしています。個人ではなかなか荷が重い活動も、他のメンバーと一緒であれば動きはじめやすいという点は、会として取り組む意義だと考えています。 「ソフトスキル」の強みを活かし、課題解決に貢献する ──そのほか、チームメンバーが快適に働けるようにするための取り組みは何かされていますか。 「Slack巡回」を積極的に行うようにしています。自分のチーム以外のチャンネルや他のメンバーの分報チャンネルを見て回って、「XXがしたいけれど、どこに申請すればよいかわからない」といった困りごとや他の人にも役立つ情報を発信している人がいないかを見ています。 Slackを巡回するなかで困っている人が見つかれば、関連するドキュメントの場所を伝えたりします。本来は、私がSlackで見つけなくても本人が自力で解決できるようになっていることが理想なので、ドキュメントを新しく書いたり、既存のドキュメントへの導線を整備したりするほか、同じことで困る人が出ないようにするためにも、「そういう困りごとはここで質問するといいですよ」といった形で参加人数の多いSlackチャンネルに誘導するようにしています。また、Slackで情報共有する際には、あとで検索しやすいような言葉やまとめ方にすることを心がけています。 また、Slack巡回にも関連しますが、日常的にドキュメントを書く文化を作ることも意識しています。リモートワークが中心の現在はSlackに一次情報が書き込まれることが多いのですが、それを後から見つけやすいようにするためにはドキュメンテーションツール（esaを主に利用しています）に載せていくことが大切です。私個人は日常的にSlackの検索を駆使して過去のフロー情報を業務に役立てることも多いのですが、ストック情報として整備する必要性がなくなるわけではありません。 例えば、介護レセプトチームに所属していたときの話になりますが、ドキュメントを書かずに終わってしまう理由として「小さいことだから書かなくていいか」と「ちょうど良い置き場所がない」の二つが、最も多い理由だと当時感じていました。そこで、特に内容を問わずに「将来誰かの役に立つかも」というもの置いておく場所として「転ばぬ先の杖」というディレクトリ（esaでの言い方は「カテゴリ」）を用意したところ、多くのメンバーが何かあればそこにドキュメントを書くようになりました。もちろん、このディレクトリよりも適切な置き場所がある場合もありますが、まずはドキュメントを書いて他の人の見えるところに置く習慣を身に付けることが重要だと考えています。こうしてドキュメントとして情報共有する文化ができてくれば、普段の業務で感じた困りごとを自ら解決できるようになるだけでなく、新しいメンバーのオンボーディングにも役立ちます。 誰かの役に立ちそうなものを書いておく場所として作ったディレクトリ「転ばぬ先の杖」 ──ちょっとした工夫で情報共有の仕組みがうまく回り始めているんですね。こうした活動に取り組まれてるなかで、どのようなことを大切にされているのでしょうか。 自分が「もっとこうだったらいいのに」と思ったり、誰かが不便そうにしていたりするときは、改善の提案やそのためのアクションを積極的に取るよう意識しています。ツールの管理者や他部署の人を巻き込まなければならない場合もありますが、そこまで含めてやることも多いです。 一方で、みんながみんな何か問題意識を持ったら自ら改善のためのアクションまで取らないといけないかというと、そうではないと考えています。私はもう入社4年目なので、どうすると改善の動きが進めやすいかなども割とわかってきているのですが、逆に現状に慣れてしまっていて問題意識を持ちづらくなってしまっていることも感じます。また、人の個性としても問題によく気がつく人、声を上げやすい人というのは必ずしも改善の動きを実際にするのが得意な人とは違ったりするので、声を上げるだけでも貢献だと考えています。これは、OSS開発でissueを立てるだけでもよくて、必ずしもpull requestを送るところまでやらなくてもいいんですよ、ということに似ています。もちろん、新しいメンバーがpull requestを送れるように、組織の文脈でいえば改善のための動きを取れるように支援するということも大切ですけどね。 自ら改善のアクションを取ろうとするのは、単純に困っている人を助けたくなるという自分自身の性格的なところが大きいかもしれません。また、もともと情報系のバックグラウンドがほとんどない状態でエンジニアとしてのキャリアをスタートしたので、技術的な知識やスキルが他の人に比べて弱かった分、ソフトスキルで貢献しようという意識を持つようになったというのもあります。開発者であれば、ツールを作成したり、CIを整えたりというアプローチで他のメンバーの働く環境を良くして組織全体のパフォーマンスを上げるのが一般的で、自分もそういった形での貢献をもっとしていきたいと思いますし、実際に取り組んでもいるのですが、自分の場合はより広く技術以外の部分も含めて環境を整えているというイメージです。組織や同僚のために今の自分ができることはなんだろう？と模索をした結果、こうした活動に行き着きました。 自分以外に同じような活動をする人が増えてほしい ──どのような思いや考えが活動の原動力になっているのでしょうか。 仕事をしている時間は生活の中でも結構長いので、楽しく快適に仕事に取り組めるようにしたいですし、周りのメンバーにもそうであってほしいという思いがあります。また、自分や一部のメンバーにとってだけ快適な環境では他の人に皺寄せがいってしまって持続性がないので、チームや職種を問わずみんなが快適だと感じ、組織として成果を出せる環境を目指すべきだと考えています。 ──活動を通して課題に感じられている部分や苦労されていること、今後やっていきたいと思うことなどはありますか。 オンボーディングや環境づくりはマネージャーの仕事というイメージがあるのか、入社して間もないメンバーから「マネージャーだと思っていました」と言われてしまうことがあります。そう言われるのが嫌なわけではないのですが、本意ではありません。マネージャーでなくても、自分たちの組織を良くする活動には積極的に取り組んでもらいたいからです。 こういうふうに思われてしまうのは、「あなたがコミュニティ」というバリューがオンボーディングの中でまだ全体に十分に伝わりきっていないからかもしれません。また、自分がやりすぎているというのも要因の1つなのでは？と最近は感じています。「あの人がやっているから自分はやらなくてもいいや」と思われてしまうと、組織としての持続可能性がなくなってしまうので、マネージャーやリーダーが委譲をするのと同じで、一歩引いて他に同じような活動をしてくれるメンバーが出てくるのを待つことも必要なのかなと感じています。ついつい関わりに行ってしまうので我慢が必要なのですが……（笑） こうした課題感があるので、今後はもうひとつ上の視座から、チームや組織の改善活動に取り組んでいきたいと考えています。

9月14日(木)～15日(金)に関西学院大学西宮上ヶ原キャンパスで開催される「日本オペレーションズ・リサーチ学会 2023年秋季研究発表会」にて、Analytics&Innovation推進部の小貝が登壇します。 学会概要 オペレーションズ・リサーチ（OR）は困りごとを科学的に解決するための問題解決学で、 日本オペレーションズ・リサーチ学会 はORに関する情報交換や発表を行っている学術的コミュニティです。 毎年春と秋に開催されている研究発表会では、大学や研究機関の研究者だけでなく実務家からの発表も盛んに行われており、理論と実践の両輪を重視しているのが特徴です。 イベント名：日本オペレーションズ・リサーチ学会 2023年秋季研究発表会 日時：2023年9月14日(木)〜15日(金) 会場：関西学院大学 西宮上ヶ原キャンパス 主催：日本オペレーションズ・リサーチ学会 公式サイト： https://orsj.org/nc2023f/ 登壇概要 タイトル：訪問介護におけるシフトスケジューリングモデルと自社データによる検証 日時：9月15日(金) 10:00〜11:00 セッション：医療・福祉 会場：C会場 発表者：小貝洸希 なお、発表内容は過去に小貝が書いたブログ記事をまとめたものになります。 tech.bm-sms.co.jp おわりに 弊社では、データサイエンティストの採用も積極的に行っています。ORを研究している方、研究内容に興味をもっていただけた方はぜひカジュアル面談にお越しください！ open.talentio.com

2023年4月、介護事業者向け経営支援サービス「カイポケ」のプロダクトマネージャー (以下、PdM)としてエス・エム・エスに入社したキム　ダソムと申します． BtoB SaaS の特徴として，ある業界・業種に特化したドメイン知識が関わることが挙げられると思いますが，私自身を含め，周りの方々がドメイン知識のキャッチアップや理解に悩まされているように感じることがありました． 本エントリーは，改めて入社二ヶ月を振り返りながら入社するまで介護への知識がほぼゼロに近い状態だった私が，ドメイン知識や業界の基礎知識に関連して良かったと思った取り組みを中心に，継続的に実践していきたい学びを共有したいと思います．このエントリーを読んでくださる方にとってなにか一つでもお役に立てる部分があれば幸いです. あえて全部を把握しようとしない BtoB SaaS プロダクトが業務アプリケーションとしての性質を持っている以上，プロダクトにおいてミッション・ビジョンといった中長期的な世界観はもちろん，日々の意思決定を顧客やユーザーにとって価値あるものにするためには，業界・業態・業種を取り巻く状況とその中で起きている問題と課題を把握することは必須不可欠な作業です． 「カイポケ」は介護業界特化型のバーティカル SaaS ですが，厚労省から公開されている介護サービスは全 26 種類 54 サービスあります．初めてこのサイトを見たときは介護サービスの種類が多いことに圧倒されました． https://www.kaigokensaku.mhlw.go.jp/publish/ そこで，キャッチアップ方法について周りのメンバーに相談をしたところ，キャッチアップへのアプローチはそれぞれでありながらも共通して「一人で全部を把握する必要はないです」というアドバイスをもらいました． 複雑なドメインだからこそ業界の仕組みや構造から全体像を把握することと業務(意思決定)に必要な最低限の情報を押さえて，あとは，社内のドメインエキスパートや周りのメンバーに背中を預けていく． 当時はキャッチアップのスコープが狭められたことにとりあえずホッとしました．一方で，終わりが見えない戦いになりそうという漠然とした不安を持っていたことも覚えています．しかしながら今振り返ると足元の状況を深ぼって理解することに時間を使うより，社会と法制度の大きい流れに沿った具体的な事象や課題の点と点を繋いでいくのが以下の点からしてとってもよかったと思います． 変化し続ける社会と制度の方向性に対し関連情報が柔軟にキャッチできる インプットした知識をアウトプットして現場の理解度を測りながら次のインプットの方向性をチューニングできる 狙いを定めて広げていく ドメイン知識を全体に及んで理解していくアプローチをやめてからは，プロダクトマネジメントのトライアングルを拡張させた「トリプルトライアングル」を活用していました． 「トリプルトライアングル」は意思決定で使うものとして 2022 年 PM カンファレンスで紹介 されたものですが，ドメイン理解でも応用できると思い少しアレンジを加えて使っています． １．視点を決める 私の場合 UX デザイナーにバックグラウンドを持っていることもあり，ユーザー目線で入る方が理解と共感の面でスッと理解できることから「祖母に介護が必要になったら」にフォーカスを当てて介護サービスを利用するまでの流れや介護サービスの種類のデスクリサーチを始めました． 次は私が実際に作っていた入社２週目のキャッチアップ目標になります． 2. 視座を最上位まで上げ１ユーザーとのつながりを掴む 一度家族目線で介護というものがどういったものか理解を進めた上で，介護保険法の意義や法改正の流れに移りました． そうすることによって「今」存在しているサービスや直近の法改正の傾向や社会全体的な課題を調べながら，市場のマクロ的な数字や動向についてデスクリサーチを進めました． 3. 意思決定者や業務担当者のペインを抽出する デスクリサーチから見えてきた情報やサービス事業所への探索型，仮説検証型のリサーチをしながら見えてきた課題をもとにプロダクトビジョン・ミッション・コンセプトを作り，コンセプト検証をしました． 入社してから2ヶ月で20ヶ所の現場に足を運んで実際に目でみて話を聞くことで解像度が上がったと思います． おわりに：エス・エム・エスだから加速できたこと 現場に足を運んだりインプットへの時間をしっかり設けることはチームや組織の理解とカルチャーが関わる部分もあると思います． 最後はそういった環境要因でドメイン理解が加速した部分をご紹介したいと思います． ビジネス戦略がクリアでオープン プロダクト理解においてドメイン知識に付随して役に立ったのは自社のビジネス戦略でした． 入社してすぐのオリエンテーションでは会社の中期経営計画について共有されますが，会社の存在意義や中長期的な戦略がクリアで分かりやすくプロダクトのミッション・ビジョンとのつながりと整合性の確認がしやすかったです． 現場・現物・現実を重視する三現主義カルチャー 担当するプロダクトフェーズがちょうどユーザーリサーチを行っていたこともありますが，社内には普段から開発側が商談に同席したり，事業所体験ができる環境が整っています． 事業責任者も現場に行くことから得られる肌感覚を大切にしていて組織全体として現場を知る環境づくりを進めていることを後から知って，これからもどんどん活用したいと思いました．（ 『大規模SaaS「カイポケ」の意思決定を支える事業責任者の思考と技術』 ） 入社５日目から現場に出向き事業所体験や見学ができたことと，実際のケアの様子やプロダクトが介在する場面を目で見て手に取ることでドメインとユーザー理解が加速できたと思います．

1. はじめに はじめまして。株式会社エス・エム・エスでプロダクトマネージャー（PM）をしている田中達規（ @tatsunori_ta ）と申します。 2022年5月に入社し、１年間は介護事業者向け経営支援サービス『 カイポケ 』の障がい領域に関するプロダクト開発を、現在は介護・保育・障がい福祉キャリア領域で採用・転職支援のプロダクト開発に携わっています。 また私はプロダクト開発部というPM、エンジニア、デザイナーが混在する部署に所属しています。入社して約１年が経った2023年3月に弊社技術責任者の田辺より、プロダクト開発部としての「バリュー説明会」が開かれました。恥ずかしながら私はこれまでエス・エム・エスにおける「Value」を考えずに仕事をしてきましたが、本説明会は改めて我々の仕事を見直す良い機会になりました。エス・エム・エスのプロダクト開発組織が大切にしていることをぜひ社外の皆さんにも知っていただきたいので、本記事にてまとめさせていただきます。 2. エス・エム・エスの事業について エス・エム・エスが提供しているサービスは、医療・介護・福祉・保育など幅広くも特有の文化がある業界におけるプロダクトです。ステークホルダーが多く、政府や自治体が定める法規制や施策等で、プロダクトの要求事項を変化させる必要があります。また私はこれまでにtoB向けもtoC向けのプロダクトにも携わってきた経験はありますが、医療社団法人や社会福祉法人という営利目的だけではない法人で働く人達向けのプロダクトはエス・エム・エスで初めての経験となります。 プロダクトマネージャーとしては、「この機能さえ獲得すれば良い」「モダンでキレイなUIにすればKPIが上がる」というほど簡単な市場ではなく、難しくもあり面白いポイントでもあります。このように「複雑度が高い」市場をあえて選定しているエス・エム・エスは非常に特殊で、難易度が高く、プロダクトマネージャーは腕の見せどころだと日々感じています。 eijionline.com そんな中2023年2〜3月にかけて、改めてプロダクト開発メンバー向けに技術責任者の田辺より「プロダクト開発人材におけるバリュー」が名言化され、発表・説明が行われました。以下は田辺が説明をしているドキュメントの一部になります。 プロダクト開発人材におけるバリュー プロダクトづくりで日々体感していることが、田辺から改めて言語化されたことで、自分の中での腹落ち感が強くなりました。複数説明されたバリューの中でも個人的に気になり、大事にしたいと思っている「マーケットへ向けて働く」について紹介いたします。この記事を通して、エス・エム・エスのプロダクトメンバーがどのように「マーケットへ向けて働く」ことを体現しているかを感じ取っていただけると幸いです。 3. 「マーケットへ向けて働く」の意味 プロダクト開発の現場ではよく、「ユーザーの声を聞きなさい」という言葉を見聞きすることがあるでしょう。これは間違ってはおらず、ユーザーと対話してユーザーニーズを探り出し、ユーザーの課題を解決するプロダクトを構築していくことはエス・エム・エスでも大切にしていることです。ではここで田辺からあった説明会での内容も踏まえて解説していきます。 マーケットへ向けて働く 組織や任されている役割でなく、マーケットへ価値を提供できているかという視点で責任を担い、行動する。組織の論理や不確実性への自身の不安といったものへとらわれず、ただマーケットへ向けて働くとしたら今なにをすべきかを問い、必要なことをする。仕事なので。 こちらは田辺が明文化していた「マーケットへ向けて働く」を解説した補足説明です。まず特徴的なのは「ユーザー志向」などという言葉は出てこず、マーケットというより大きな概念での価値提供について言及されていることが分かります。目の前のお客様にどう価値提供し、その結果がマーケット（市場・業界）が良くなっていくという観点を持つきっかけとなりました。この感覚はエス・エム・エスに来るまではあまりなかったので新鮮であり、奥が深いなと感じた点です。 エス・エム・エスが向き合っている「高齢社会」という国家課題の社会要請は、日々変わり続けています。ユーザー・顧客の価値観だけでなく、政策状況によってやらなくてはいけないこと・やめなければいけないことも出てきます。 だからこそ「ユーザー」だけではなく「マーケット」という言葉を使っていると理解していますし、実際にプロダクトづくりに携わる一員として、「マーケット」に向けて働いている実感があります。 www.bm-sms.co.jp 社会への貢献を第一に謳っているエス・エム・エスでは、プロダクト開発メンバーも社会課題に向き合い、プロダクトを通して社会に価値を創っていく一員です。組織でもプロセスでも開発でもなく、「マーケットを良くすること」を最大の目的とした一言として、「マーケットへ向けて働く」という言葉が出てきていると理解しています。 4. 開発チーム向けのバリューとして「マーケットへ向けて働く」という言葉ができた経緯 今「マーケットへ向けて働く」という言葉が誕生したように見えますが、決してそういうことではないと思っています。もちろんエス・エム・エスのプロダクト部のメンバーでは、このバリューを体現している人が多いというのが前提です。改めて我々が大切にしたいことを言語化し、さらにこのバリュー体現度を上げていこうということだと理解しています。 社外の方や、最近エス・エム・エスに入られた方向けに一部補足していくと、この言葉の特徴の一つに「主体性」が含まれています。「ユーザーの声を聞く」だと受動的に捉えられますが（もちろん一概にそうではないですが）、「マーケットへ向けて働く」だと自らがマーケット側へ動いていくというニュアンスになります。そのため、マーケットを理解することは必須ですし、マーケットにプロダクトを届けていくというスタンスで仕事をすることが求められます。これはPMに限った話でなく、エンジニア・デザイナーも求められることです。 実際に働いている自分の感覚としては、マーケットの中に自分たちのチームが存在し、マーケットを理解しに行きながら、マーケットに必要なプロダクトを定義して作り、マーケットへ届けていくことを継続的に行っています。 5. 「マーケットへ向けて働く」に含まれている要素の解説 前述のバリュー説明会（およびドキュメント）では、それ以外のキーワードも挙げられていました。「マーケットへ向けて働く」に近い考え方を持っているキーワードをここでは紹介いたします。 5-1. マーケットへ向けて働く ☝ 組織や任されている役割でなく、マーケットへ価値を提供できているかという視点で責任を担い、行動する。組織の論理や不確実性への自身の不安>といったものへとらわれず、ただマーケットへ向けて働くとしたら今なにをすべきかを問い、必要なことをする。仕事なので。 この記事で最も解説したい内容がこの「マーケットへ向けて働く」です。主語が自分ではなく、マーケット（顧客・ユーザー・業界）であり、彼ら・彼女らの成功を何よりもミッションとして置いています。プロダクトを開発・提供していく過程で、売上を追うことや、自らの立場への不安というものはどうしても出てくるものです。特に組織という立場にいると、短期的なKPIを追ったり、自身の評価が気になるのは人間なので不思議なことではありません。 しかし私達が大切にしたいことは、最終的なGoalに向けて愚直に、自分が何ができるかを考え、行動することです。エス・エム・エスのプロダクト開発組織では、この動き・スタンスを良しとされる文化があります。 5-2. 相対的な視点で評価する ☝ 事実と解釈を分ける。事実を解釈するときに、主観的な視点だけでなく二人称、三人称での相対的な視点での評価をする。 「相対的な視点で評価する」は社内の中での働き方や考え方に関してのものもありますが、マーケット観点で見た時はどうでしょうか？例えば私が携わっていた児童福祉領域の事例にすると、我々が対象にするプロダクトのマーケットには、保護者・児童・サービスを提供する事業所・自治体・国と様々なステークホルダーが存在します。事実を得ようとしても、保護者の観点と、事業所の観点ではどうしても得られる情報が変わってきます。幅広ければ良いというわけではないですが、個人の主観にならずに二人称、三人称で事象を見ることで、課題設定が変わってきます。 「マーケットへ向けて働く」ためには、この相対的な視点が非常に重要になります。 5-3. 謙虚でいる ☝ 自分が間違っているかもしれないという可能性に対してオープンであること。防衛的にならない 主観以外の視点へ冷静な評価をするには、二人称、三人称視点でのフィードバックへ謙虚にいることが必要 ここで言う謙虚さは控えめであることの美徳ではない。それは Speak up に反する 顧客・ユーザーの課題解決のためであれば、「誰が言ったか」は関係のないことであり、自分の意見の正しさも関係がありません。そのため、プロダクトの意思決定者は私達PMですが、PMのアイデアは絶対ではありませんし、”間違いの指摘”はWelcomeというスタンスです。 マーケットに「正しいもの」を提供することが目的であり、自らの考えを時には否定し、他者の考えを受け入れることを重要視しています。そのため積極的にフィードバックをもらい、そのフィードバックをまずは受け入れるということを良しとしています。 私自身もエンジニアやデザイナーから「何故それを作る必要があるのか分かりません」と言われることはよくあります。しかし、その言葉のおかげで「では、どうするとユーザーにとってもっと良いですかね？」という議論がしやすくなります。前述した「相対的な視点で評価する」と似た内容ではありますが、二人称・三人称視点でフィードバックをいただけることは非常にありがたいですし、私も心がけないといけないなと思います。 5-4. Time-to-market 思考 ☝ 本来やるべきことを最短で。高い成果へコミットするプロフェッショナルとして、本来やるべきことへフォーカスして最短で実現するように行動する。冗長なコミュニケーションや官僚的な手続きといったもので他者の時間を損なうことは組織のパフォーマンスを下げる プロフェッショナルだから、Quality も Cost も Delivery も自分たちの裁量で適切なものを設定する。裁量を持つ責任として Time to market を意識して、自分の行動が会社にとってベストなものであるよう全力を尽くす マーケットはいつまでも私達を待ってくれません。そして、社会要請が今あるということは、既にマーケットは我々が届けるプロダクトを待っています。（潜在的なニーズであるため、これがほしいというものを求めている状態ではないことが多いですが） いかに早くプロダクトを通じて課題解決ができるか、社会・マーケットからの要請に早く答えるためには、重大・多重な会議や煩雑な手続きは不要です。だからこそ、どんな品質でいつまでにプロダクトを届けるかも基本的にはプロダクトメンバー各々に委ねられています。そして我々プロダクトメンバーは、プロフェッショナルな一員として、上長や会社のためにではなく、マーケットのために責任を持っているのです。 5-5. 自身の正しさよりもチームの成功を優先する ☝ チームは「あなたの正しさ」のために働いていない。マーケットでの成功 (ミッションの実現) が目的。自分の優秀さや自己顕示、自己正当化よりもチームの成功を優先する。自己正当化のコストを組織に負わせないこと エス・エム・エスのプロダクト開発部が重視しているのは、「あなたの正しさ」よりも、「マーケットが正しいと認めるもの」です。この考えは、5-3.「謙虚でいる」にリンクする内容になっています。自分が何を言ったかは重要ではなく、チームとしての成果＝プロダクトの形を大事にしています。 そのためには、チームの中で自分の考えが正しいとすることに時間は使ってはいけないですし、自分自身を正当化するような行動は必要ありません。そのような言動にパワーと貴重な頭を使うのであれば、マーケットに向けて正しいことをやっていきましょう。 1から5を踏まえてエス・エム・エスにおいて「マーケットへ向けて働く」とは 言葉の通りですが、私自身がこの言葉を聞いて、自分たちがどのように働いていくかを考えたイメージを記載します。 まずはマーケットをリスペクトして、この業界を理解すること。前述の通り、我々が対面する介護・福祉・医療・保育業界は複雑性が高く、ドメイン理解をし続けないとあっという間に市場が変わっている業界です。国の政策動向を理解する、マーケットにいるユーザーに話を聞く、ユーザーの顧客という直接の価値提供者ではない方に話を聞く、社内の有識者にヒアリングする。このようにマーケットを理解するというのが最初です。 その後はマーケットに対してプロダクトを創って届けていく仕事ですが、ここはチーム活動になります。チームの活動目的も、当然マーケットが主語です。マーケットに必要なものをチームで見極め、なるべく早くマーケットが求めるプロダクトを提供していく。そのためには、冗長な社内手続きや承認作業は不要で、何よりもマーケットに向かって動いていくことを追求しなくてはいけません。 対マーケットに向けた仕事はシンプルで簡単なように聞こえますが、マーケットが複雑な分なかなか実現の難易度は高いのが実態です。その精度・確実度を上げるためにチームプレイが必要となり、チームメンバー全員が謙虚にフィードバックしていく文化があります。 6. まとめ エス・エム・エスのプロダクト人材におけるバリュー「マーケットへ向けて働く」について、田辺の言葉を借りながら、自分なりの考えをここまでに書いてきました。最後に今後「マーケットへ向けて働く」について自分自身がどのような考えを持っているかを紹介して、本記事を締めさせていただきます。 経営理念　‐普遍的に追い求めるもの‐ 永続する企業グループとして成長し続け、社会に貢献し続ける 当社は、社会をより豊かにするために、社会の要請に応え続けることにより100年を超えて成長し続け、社会に必要不可欠な存在として社会への貢献の総量を増やし続けていきます。 こちらはエス・エム・エスの経営理念です。これまでに記載してきたことからわかるように「社会からの要請に応える」ことは、経営理念であり企業として実現したい世界です。そのため、常に意識していることは「社会で必要となること、社会が必要とすることは？」から自ら考え、エス・エム・エスという企業の中でそれらを価値に変換して提供していくことです。 マーケットにとって必要で正しいことであれば、会社という枠組みと資産を使って自分のやりたいことを実現できる。言葉を選ばずに言うと、エス・エム・エスはそんな環境を提供してくれる会社です。入社して１年ですが、生意気な自分に様々な機会を提供してもらえていると思います。 だからこそ、今後も以下のようなことを意識して、エス・エム・エスという会社を超えてマーケットに必要なものを届けていこうと思います。 コトに向き合い続ける 複雑なマーケットを誰よりも愛し、マーケットが求めているプロダクトを提供し続ける プロダクトを通してマーケットをリードしていく 主語がマーケットであるプロダクトづくりは長期戦でタフですが、日々学びがアップデートされ楽しいです。短期で上手くいくということは少ないかもしれませんが、実現したい大きな世界観に向けて動いている・動かしていることを実感しています。