はじめまして。株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」の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年を超えて成長し続け、社会に必要不可欠な存在として社会への貢献の総量を増やし続けていきます。 こちらはエス・エム・エスの経営理念です。これまでに記載してきたことからわかるように「社会からの要請に応える」ことは、経営理念であり企業として実現したい世界です。そのため、常に意識していることは「社会で必要となること、社会が必要とすることは？」から自ら考え、エス・エム・エスという企業の中でそれらを価値に変換して提供していくことです。 マーケットにとって必要で正しいことであれば、会社という枠組みと資産を使って自分のやりたいことを実現できる。言葉を選ばずに言うと、エス・エム・エスはそんな環境を提供してくれる会社です。入社して１年ですが、生意気な自分に様々な機会を提供してもらえていると思います。 だからこそ、今後も以下のようなことを意識して、エス・エム・エスという会社を超えてマーケットに必要なものを届けていこうと思います。 コトに向き合い続ける 複雑なマーケットを誰よりも愛し、マーケットが求めているプロダクトを提供し続ける プロダクトを通してマーケットをリードしていく 主語がマーケットであるプロダクトづくりは長期戦でタフですが、日々学びがアップデートされ楽しいです。短期で上手くいくということは少ないかもしれませんが、実現したい大きな世界観に向けて動いている・動かしていることを実感しています。

はじめに はじめまして。2023年4月にエス・エム・エスに入社した橋口( @gusagi ) です。 今はエンジニアリングマネージャー（EM）として、介護事業者向け経営支援サービス『 カイポケ 』の中で訪問看護に関する機能を担当しているチームで業務に携わっています。 エス・エム・エスに入社するまでの経緯は 個人ブログの記事 にも書いたのですが、その記事の中に 先週に入社したばかりなのでキャッチアップ中心ではあるのですが、少しずつチームでのアクションに参加を始めています。 ドメイン知識はこれからになるのですが、これまでの経験を（失敗も含めて）共有することでチームのパフォーマンス向上に寄与していければと考えています。 と書いていました。 この記事を書いている現時点で上記の記事を書いてから約２ヶ月が経過していますが、キャッチアップを進める中で特に印象に残ったことを一つ紹介したいと思います。 プロダクト人材におけるバリューの明文化 エス・エム・エスには、エンジニアに限らず多くの人がWiki として使っているドキュメンテーションツールで情報を明文化する・共有すると言う文化があります。書かれている情報の種類は様々で、技術的な情報だったり、打ち合わせの議事録だったり、考え方に関する情報発信のための文章だったりします。 技術責任者である田辺さん自らもこういう取り組みを積極的に行っていて、「プロダクト開発人材におけるバリュー」も明文化されていました。 こちらの内容については、少し前に公開された記事 『80人超のエンジニア組織で、６つのチームバリューを言語化しはじめた話』 に詳しく書かれているので、今回は割愛させていただきます。 興味のある方はそちらの記事も読んでいただけると嬉しいです。 エンジニアリングマネージャーとして入社した私がこの資料を読んで特に印象に残った言葉が「あなたがコミュニティ」 *1 と言う言葉でした。 「あなたがコミュニティ」 この言葉の説明は以下のような文章が続いていました。 組織というコミュニティがなにかをしてくれるのではない。自治組織ではあなたがコミュニティ。あなたがコミュニティを代表する一人として考え行動することで自治組織になる。あなたが他人事だと思った瞬間から自治は崩れていく。 OSSのコミュニティ活動に関わったことがある人はイメージしやすいかも知れませんが、OSSコミュニティの活動は有志の人が主体的に考えて行動していることが多くあります。何かしらの活動に主体的に関わっている人たちの動きの集まりが、そのコミュニティの活動を成しているといっても良いかもしれません。 「あなたがコミュニティ」の説明を読んだ時、私はOSSにおける個々人の活動とコミュニティの関係に当てはめて、文中にある「組織」を「エス・エム・エスのプロダクト開発組織」として読み替えて捉えました。 つまり「組織が何かをしてくれるのを待つのではなく、自身が主体的に動くことでエス・エム・エスのプロダクト開発組織ができあがっていく」と受け取ったのです。 またちょっと話が飛びますが、プロダクト開発組織のバリューとして大事にしたいこととして、以下のキーワードもあげられていました。 全員リーダーシップ Speak up プロフェッショナルスタンダードを高く持つ 挑戦の称賛と失敗の許容 自治と信頼 これらのキーワードについては、すべてが何かしらの形で「あなたがコミュニティ」という概念に通じるものと理解しました。 「あなたがコミュニティ」に通づるキーワードたち そこで、これまでの２ヶ月の経験を踏まえた自分なりの解釈を言語化してみると以下のようになります。 全員リーダーシップ リーダーシップというと何らかの役職を持っているような人間が発揮する指導力・統率力をイメージする方もいるかもしれませんが、ここでいうリーダーシップは「自分が為すべきことに対して主体的に取り組み、場合によっては他の人を巻き込んでいく姿勢」だと思っています。 役職があるからリーダーシップを発揮するのではなく、その人が為すべきことに向き合っていく姿勢があり、そこにその人の能力や周囲からのフォロー、あるいは運といった要素も絡み合って結果がついてくるのではないでしょうか。 また、リーダーシップについては同じEMである @emfurupon777 が 2023年4月に書いた記事 も参考になると思いますので、興味のある方は合わせてご覧ください。 Speak up 日本語に訳すと「声を上げる」「大きな声で言う」「直言する」となります。 必要なことであれば遠慮なく声をあげて自分の考えを伝えること。これまでの経験や考え方が違うからこそ、目的のために自分の考えを述べて議論を深めることで、周囲の協力を得ることができたり、自分が間違っている場合に指摘をしてもらうことができるのではないかと思います。 実際、先日に社内のSlackで田辺さんがフルタイムコミッターを同僚として雇うことについての考えを募った際にも「技術的に色々と聞くことができそう」「GitHub Sponsorsなどにより、OSS開発者への支援を優先して欲しい」「仮に同僚にOSSコミッターがいたとして直接的な刺激を受ける人がどれくらいいるだろうか」「フルタイムコミッターの方にとって環境的な満足度とかの観点も材料にした方が良い」という形で、複数の人が自分の考えを述べて議論していました。 特定の誰かが決めて後はそれに従うのではなくそれぞれが考えを持って意見を述べていたのを見て、まさにコミュニティだなと感じました。 プロフェッショナルスタンダードを高く持つ 短い期間にも変化していくエンジニアリングの世界で成果を出し続けるためには、プロとしての意識をしっかりと持ち、仕事のクオリティを自分自身で高く保つことが必要です。変化していく状況の中では何が正解かも定かではないことがほとんど。 そういった状況においても「これが今の自分が思う最善の手段である」と自信を持って言えるようなプロ意識を持ち続けたいと私も思います。 挑戦の称賛と失敗の許容 入社して約２ヶ月の短期間でも、必要だと思ったことに対して「とりあえずやってみる」を許容し、後押しする文化があるように感じています。 実際、入社して１ヶ月程度経った時点で採用に注力する必要があると思い、田辺さんに1 on 1の時間を急遽差し込んだ上で「主体的に採用に関わらせて欲しい」と相談したところ、5月から採用にも携わるようになっています。 また、短期的な成功・成果を最重要とはしておらず、より本質的な課題に向き合って組織としても個人としても変化と成長を続けることに重きを置いているように感じます。 自治と信頼 これは入社してから驚いたことですが、チームによって選択している技術スタックやツール、チームとしての動き方が異なっています。 例えば、私が所属しているカイポケで利用している言語はJavaがメインとなっていますが、 カイポケのリニューアルプロジェクト ではKotlin / Spring Boot / TypeScript / GraphQLというモダンなアーキテクチャを採用していますし、介護キャリア事業の開発チームではRubyをメイン言語としています。 また、タスク管理の方法についても こちらの記事 で紹介されているようにTrello / Asana / GitHub / Jiraとチームに合わせて自分たちで選択しています。 フェーズも異なる40を超えるサービスを開発・運営しているので、すべての技術スタックを統一することは難しいのは当然としても、チームとしての動き方までそれぞれで異なっているのは、各チームに必要な裁量が委譲されているからだと思います。 その上で、チームごとに自分たちがやるべきこと・必要なことに向けて取り組み続けているのがエス・エム・エスの開発組織の強みなのだと感じています。 「あなたがコミュニティ」を読み解く 私が考える「あなたがコミュニティ」を言語化するなら、以下となります。 個人 誰もが自分が為すべきことに対してプロ意識を持って取り組む 主体的に考え発言し人を巻き込みながら挑戦をする 組織 各員に対する信頼をベースとして取り組みを任せる 挑戦に対しての賞賛と失敗に対する許容を是とする この流れが組織自体の文化となっていくし、逆に他人任せだと信頼も薄れ、自治ではなく統治となり、主体的な挑戦などは失われていくのだろうと思っています。 実現したい自分なりの「あなたがコミュニティ」 ここまで、エス・エム・エスのプロダクト人材におけるバリュー「あなたがコミュニティ」について自分なりの考えを書いてきましたが、実現したい自分なりの「あなたがコミュニティ」を最後に書いて、この記事を締めたいと思います。 これまで書いたように、エス・エム・エスでは主体的に行動することやプロフェッショナルであることに対して価値をおいている会社です。そして、そういった人であれば、どんどん機会を作り出して組織を変えていくことができる会社でもあります。 期待されるレベルが高くなることは否定できませんが、ハードルを越えることで自身が成長できる環境を求める人であれば、とても面白い環境だと個人的には感じています。 一方で、エス・エム・エスが向き合っている社会課題に目を向けると、2023年4月下旬に国立社会保障・人口問題研究所が発表した 日本の将来推計人口（令和5年推計） が話題になったように、日本の少子化・高齢化は急速に進んでいます。そんな社会課題と向き合いながら会社として成長し続けるためには、「チーム」「担当システム」「職能」の枠を超えて連携を強化していくことが欠かせません。 そのために、以下の項目に対して主体的にチャレンジしていきたい、そのためにも成長を続けていきたいと思います。 チーム横断の形でナレッジを共有できるような場をどんどん作っていく エス・エム・エスのプロダクト開発組織について社外の人たちにもっと知ってもらって、会社の枠を超えた連携を実現したり、エス・エム・エスに入社したいと思ってくれる人を増やしていく 現在フルリニューアルプロジェクトが進んでいるカイポケを現在のシステムと新しいシステムとして分けるのではなく、「一つのカイポケ」という形でお客さまからも社内の人からも地続きの状態にしていく 多くのチャレンジをなるべく楽しみながら取り組んでいく！ 上記は一人の力で実現できるイメージはありません。色々な人のチャレンジングな取り組みに助けてもらう必要もあるでしょうし、エンジニアリングマネージャーとしてそれを後押ししていきたいとも思っています。 もし上記の項目がこの記事を書いたときよりも実現に近づいてきたと自分で感じることができたなら、私の思う「あなたがコミュニティ」に近づいているということになるんじゃないかと思っています。 *1 : 「あなたがコミュニティ」という表現は、「 Rubyist Magazine 0028号 巻頭言『コミュニティ』とは誰か 」から引用しているそうです。

こんにちは、エス・エム・エスで採用担当をしているふかしろ( @fkc_hr )です。 プロダクト開発部にはエンジニアだけではなく一緒にプロダクトを作っているプロダクトデザイナーが所属するデザイン組織があります。 2023年6月15日に開催された「 Career Design Night #6 社会課題に向き合うインハウスデザイナーの本音とキャリア 」にて、デザイン組織の編成やチームの雰囲気、事業会社でインハウスだからこその悩み・楽しさなどについてお話させていただきました。 イベントの後半は実際に参加者の方からもご質問を頂きながら、参加したデザイナー/マネージャー陣がさまざまなリアルな回答をしてくれました。 人数制限もあったため、他の方にもぜひ知っていただきたいなと思い、一部抜粋するような形で特に印象的だった質問と回答をご紹介いたします。 資料 インタラクションの質問と回答 Q.介護事業は課題もあり複雑なイメージがあるのですが、何が業界のボトルネックなのでしょうか？ 介護事業所には継続的に経営課題が降りかかる まず、経営観点での法人の課題としては、継続的に経営課題が降りかかることが挙げられます。 介護業界の仕組みとして、国の社会保障をもとに費用回収をしています。弊社からすると今後伸びゆく大きな市場ですが、国の視点に立つと費用が増えることになり、都度見直しをされています。その中で、実際にカイポケのユーザーである介護事業所を経営している方からすると、削減を余儀なくされている不安定な状況で、継続性に不安を抱えているという課題があります。 また、見直しに伴って、介護保険制度の改正なども数年に一度行われるため、仕組みが変わることへのオペレーション変更対応なども必要で、介護事業所は同じ業務を繰り返しているだけでは自然と経営を続けることが難しくなっています。 介護従事者がケアに集中できない また、介護の現場で働く介護従事者の方の課題としては、本質的なケアに集中できないことが挙げられます。 介護の現場の業務は今でも紙文化で、指定のフォーマットに記入する必要があります。そして、複数の事業所同士が連携する必要があるため、データの更新があった際にも紙に記入しFAXで送るという形が現在でも取られています。その結果、高齢者の方にサービスを提供することが本業なはずなのに、高齢者の方と向き合う時間以上に紙やパソコンやホワイトボードに向き合う時間が長くなっているという課題があります。 上記2点から総合的に、非効率な現場を効率化し、経営課題を解決することが重要だと考えています。カイポケはユーザー業務の体験をいかに向上させるかがとても大事なので、マーケットにとってのボトルネックの解消のためにプロダクトづくりを日々進めています。 デザイナーとしてやりがいに感じる瞬間を教えてください。 複雑なフローを確実に「よりよくできた」と思えること まだ入社二ヶ月で経験少なめなのですが、それでも介護事業のフローの複雑さを感じています。画面パターンを検討していて、テスト版を先行して試してもらっているユーザーから「この方が使いやすい」「もっとこうしてほしい」というコメントをもらえたときに、一歩ユーザーのお仕事の手助けになれたかなと感じて嬉しかったです。 ユーザーの距離が圧倒的に近いこと これまで関わったサービスやプロダクトの中で、一番ユーザーとの距離が近いと感じています。上記にもありますがユーザーと検証で話す機会も多いですし、社内にドメインエキスパートと呼ばれる、介護事業に精通したメンバーがいます。UI画面を作る中で、ユースケースに悩むことは多々あるのですが、その度に相談に乗ってもらえてるのがとても助かっています。デザイン作業を通して、介護従事者の方の仕事の仕方がぐっと解像度高く見えてくる瞬間があって、誰かが実際に使うサービスを作っていると強く意識するので、モチベーションになります。 リモートワークを感じさせないコミニケーション 基本的にプロダクト開発組織はリモートワークです。デザイン組織は毎日夕方にdaily ミーティングを設けて疑問を共有したり、心理的不安を解消するために会話の機会を多く設けていて、下手に出社する会社より会話は多いと感じています。私は愛知県からリモートワークでお仕事してるのですが、遠方なことをマイナスを感じずに働けています。 デザインについて理解があまりない方に対して、どのように接することを心がけていますか？ 理解ではなく共感を プロダクトデザインチームではエンジニア、PdM、QAと一緒にプロダクトづくりをしています。 その中で意識していることは、ただ自分のデザインを理解してもらうよりも前に、まず「ユーザーへの共感」をしてもらうことです。 デザイン自体は、あくまでユーザーの課題や期待に沿って、デザイナーが工夫してアウトプットしたもの。誰のために、何のためにこういうデザインが必要だ、という一連の論理的な説明の構成が大事だと考えています。より開発関係者に共感をしてもらうために、例えば、インタビューやテストの録画をみんなで視聴するなど、いわゆる0次情報である、リアルのユーザーの言動と思考プロセスを共有しています。 さいごに カイポケは介護業界に特化したSaaSです。エス・エム・エスとして叶えたい高齢社会の課題解決の方向性と、実際に利用頂いている介護従事者の皆様は同じ方向を向いているので、率直にフィードバックをもらいながらプロダクトづくりを推進することができています。 たくさんの事業所に使っていただいているからこそ、実際のユーザの顔を見ながら、ユーザー体験の良いプロダクトを深く思考し作ることができる良い組織だなと改めて感じました。 エス・エム・エスでは、プロダクトデザイナー、コミュニケーションデザイナーと幅広くユーザー・マーケットに向き合ってくれる方を募集しています。 もし「もっとお話聞きたいよ」と思っていただいた方はお気軽にTwitterでご連絡いただくか、カジュアル面談申し込みページからご応募ください。

0. 本記事の位置付け 1. バリューのつくり方・考え方 2. エス・エム・エスが向き合うマーケットの定義とは 3. 全社の経営理念・バリューについて 3.1 経営理念について 3.2 バリューについて 「価値主体であり続けること」 「社会からの要請を真摯に受けとめ続けること」 「変化対応し、成長し続けること」 「誠実であり続けること」 4. プロダクト開発組織におけるバリューの位置付け 5. エス・エム・エスが考える「プロダクト人材」とは 5.1 プロダクト人材の活動の目的について 5.2 プロダクト人材の仕事の特徴について 5.3 プロダクト人材とはどういう人材か、どのように働くのか 6. プロダクト開発組織の人材理念について 「Purpose」 「価値主体と情熱」 「社会からの要請」 「プロフェッショナル」 「誠実」 「自治と信頼」 7. 最後に 0. 本記事の位置付け エス・エム・エスは2003年の設立以降『永続する企業グループとして成長し続け、社会に貢献し続ける』を経営理念に、高齢社会の課題解決に向け複数の事業を展開してきました。 プロダクト開発組織は2015年から本格的な内製化を進め、今では80人超の組織となっています。このプロダクト開発組織では、どんな文化・価値観を大切にしチームづくりを行っているのか。 本記事では、2023年2月7日・3月22日に社内で行われた技術責任者 田辺による『プロダクト開発組織のバリュー説明会』の内容を、一部当日の資料を引用しながら文字起こし形式で紹介しています。 (※本記事の内容は、エス・エム・エスとして定義しているバリューそのものではなく、現時点でのプロダクト開発組織向けに解釈し、落とし込んだ内容となっています。) 1. バリューのつくり方・考え方 まずはじめに、バリュー制定の背景にあるバリューのつくり方・考え方について解説します。 当社のプロダクト開発組織のバリューを考えるにあたって「 メルカリ・小泉社長による『 1→100の組織設計を丸裸にする』人事組織（HR）勉強会の備忘録 」の内容を参考にさせていただきました。 特に、 ”Plan（設計時に大切にしていること）「ビジネスゴールや市場特性とバリューが紐付いていることが大切」” という箇所に記載されている 「バリューは経営陣の経験や思いで定めるのではなく、ミッションや事業特性で決めるべき」 という点を意識し、当社の向き合うマーケットや事業特性を考慮した上でバリューを定めています。 The Pyramid Azit Inc. CEO & Designer―ミレニアル世代が考えるこれからの日本, 「メルカリ・小泉社長による『 1→100の組織設計を丸裸にする』人事組織（HR）勉強会の備忘録」, https://shuyuy.com/mercari-koizumi-hr.html （2023年6月1日 閲覧） 2. エス・エム・エスが向き合うマーケットの定義とは 次に、当社が向き合うマーケットの定義について解説します。 私たちは現在、高齢社会の課題解決に向け複数の事業を展開しています。 「高齢社会」というマーケットは、ステークホルダーの多さや政府の規制など扱う変数が多く、また変化のタイムスパンも長いため、実際に手を動かしながらでないと解決策が見えてこないような「複雑性の高い市場」です。そのため、私たちの向き合うべきテーマは 「複雑性の高い市場での事業開発」 であると考えています。 複雑性の低い市場＝課題に対する解決策がある程度見えているので、まとまった資金を投入すれば One product でインパクトを残せる 複雑性の高い市場＝巨大な資本力や単一のイノベーティブなアイデアは、持続的な成長ドライバーになりづらい 逆に「複雑性の低い市場」の例としては、QR コード決済の市場などが挙げられます。すでに海外で実例があり、プロダクトの姿まで見えていて、Winner takes all だったため、いかに早く市場を握るかがゲームの勝利条件となっていたようなケースです。 一方で、「複雑性の高い市場」はこうしたゲームのルールがわかりにくい領域です。 3. 全社の経営理念・バリューについて 次に、上記で説明した「複雑性の高い市場での事業開発」というテーマや事業特性をふまえた上で、経営理念・バリューはどのように位置付けられているかについて解説します。 3.1 経営理念について エス・エム・エスの全社の経営理念は 『永続する企業グループとして成長し続け、社会に貢献し続ける』 です。 この理念からも、私たちは、“短期で成功して売り抜けるぞ！”というのを目指しているのではなく、社会と共存共栄し相互に発展していくことを目指しています。そのため、永続のために会社と社会との相互発展の永久機関のようなイメージを持っています。 ここで言う「永続」とは、変化しないことでなく、 変化する社会に対して貢献し続けていく ということです。 例えば、下の図式のように、変化する社会の中で貢献の量を増やしていくためには、組織が成長する必要があります。そして、組織が成長すると、個人へ新しい機会提供ができ、個人も機会を通じて成長できます。そして、個人の成長により貢献の量が増え、それが組織の新しい貢献へとつながっていきます。 社会への貢献が増えた組織は、売上などを通じて新しい成長を得て、そうしてまた組織の成長が個人への機会を生んで〜というスパイラルで、 「組織・個人の相互発展により、社会への貢献の量を増やし続け、永続を目指していく」 というのがベースの考え方になっています。 エス・エム・エス「経営原則　〜経営理念実現のためのマネジメントポリシー〜 組織と個人の相互発展」, https://www.bm-sms.co.jp/company/values/ このように、社会への貢献・価値提供をし続け、さらにそれを営利企業として毎年15%〜20%程度の売上・利益成長とともに続けていこうとすると、長期目線・連続性・継続性が重要になる一方で、非連続な成長・変化・拡張といったものも必要になります。 また、この成長ペースは4〜5年で約2倍の企業規模への成長を意味するので、このような成長を生み出す個人を組織として作り出し続けることが、組織や人材の観点で非常に重要であり、これが「個人」のあり方を考えるうえでベースになっています。 実際には、このペースでの成長を同じ事業だけで拡大していくことは非常に難しく、多くの企業では別の事業やサービス開発を行うケースが多いのも事実です。 しかし、当社は、ある程度同じ領域で永続成長を続けながら、4〜5年で約2倍に成長していくことを目指しています。 3.2 バリューについて 当社では、下記４つを全社のバリューと定めています。 大前提として、バリューというと会社組織のものと受け止められることが多いですが、エス・エム・エスにおいては会社のものであると同時に、組織やチーム、個人のどのレイヤーの視点へ移しても境界線はなく、同じであると考えています。 とはいえ、今回は現時点で皆さんに意識して欲しいことに絞り、あえてピックアップする形でお話ししたいと思います。 はじめに、上記４つのバリューのうち「価値主体であり続けること」と「社会からの要請を真摯に受けとめ続けること」はセットであると考えています。 「価値主体であり続けること」 まず、「価値主体であり続けること」について、これは「個人と組織＝個と全」という関係性で考えると、 個人として組織全体に対して固有の価値を発揮し続ける ことを示しています。 このバリューの背景には、一人ひとりが個人として能力や成長の可能性を持っており、組織としてその個人の価値を信じているという会社のスタンスが表れています。会社がやりたいことにただ従順な個人を求めているのではなく、個人として独立した志向や意志をもち価値を発揮する人物を求め、その個人の総和として組織が社会に貢献していくことを会社として望んでいるのです。 「社会からの要請を真摯に受けとめ続けること」 次に、「社会からの要請を真摯に受けとめ続けること」について、これは 自分以外の社会や世界といった全との関わり方 を示しています。 個として価値を持っていても単独で価値を成立できるわけではなく、あくまで自分以外の社会や世界との相互関係のなかではじめて個としての価値が生まれ、評価されます。 社会や組織、上長からの要請などに対して、それらにただ従うのではなく、「価値主体であり続けること」を軸に個人として価値を発揮しながらも、その価値が自分以外の社会との関係性のなかで相対的なものであることを理解し、独りよがりにならずに社会からの要請に対して、謙虚にそして真摯に受けとめ続けることが大切です。 また、個人と組織の関係性や、会社と社会の関係性も全て、この考え方と同じ捉え方をしています。そのため、このように個人を尊重する考え方が、さまざまな会社の方針の基礎となっています。 「変化対応し、成長し続けること」 次に、「変化対応し、成長し続けること」についてです。これは、個と全の関係性に対して「時間軸との付き合い方」を加え、 時間の経過に沿って変わり続ける外部環境に対して、適用し、成長し続ける ことを示しています。 前述の通り、当社は4〜5年で2倍に成長していく会社であると考えているため、組織として、未来に対してコンスタントに変わり続ける必要があります。そして、これは組織だけでなく個人単位でも同様です。 そのため、例えば評価制度などもこのような考えがベースとなっており、「変化対応をし、成長していくことで貢献してほしい、そこへ報酬で報いたい」と考えています。 「誠実であり続けること」 最後に、「誠実であり続けること」についてです。 ここまで個と全の関係性、そしてそれに時間軸を加えたものが上記３つのバリューでしたが、ここではそれら ３つのバリューにどのように付き合っていくかという姿勢 を示しています。 エス・エム・エスが考える「誠実」は、「個と全、時間軸、そして世の中の構造を考えたときに、どこかに明らかな不利益を押し付けて得をしようという利己的な態度は長期的には無理が出るからダメである」というのが基本的な解釈です。 例えば、自身の得のために周囲の誰かしらへ不利益を押し付けたり、気付かないことを良いことに将来的な不利益を前提として短期的な得へ誘導したり、そういったことはいずれどこかに無理が出て永続が実現できなくなるのであってはならず、そうではなくフェアにいこう、というのが当社の考える誠実の基本的な考え方です。 また、誠実についても時間軸が影響を及ぼすと考えているので、時間の経過とともに変わっていく社会のルールに適応していくことも大切です。 4. プロダクト開発組織におけるバリューの位置付け では、ここからプロダクト開発組織におけるバリューについて解説していきます。このプロダクト開発組織のバリューは、全社のバリューに基づいて定めています。 全社のバリューの抽象度の高さや解釈の自由度を適切に補う形で、さらにプロダクト開発組織の仕事の特徴を考慮しながら、より重要視されるべき部分に焦点を当て、全社バリューを補正・拡張するなどして設定しています。 5. エス・エム・エスが考える「プロダクト人材」とは 5.1 プロダクト人材の活動の目的について まず、当社が考える「プロダクト人材」の定義について解説します。 当社では「プロダクト人材」とは、『ユーザーストーリーマッピング（2015）』にあるように、現在のデリバリーをしていくこと自体が仕事ではなく、最終的に 「その成果をユーザーに対して生み出し、その先でインパクトを世の中に届けること」 が本来の活動の目的であると考えています。 4_ユーザーストーリーマッピング キャプション：Jeff Patton 『ユーザーストーリーマッピング』 川口 恭伸、長尾 高弘訳（オライリージャパン、2015年） P13 5.2 プロダクト人材の仕事の特徴について 当社では「プロダクト人材」の仕事は、 「不確実な市場に対する探求と実現の過程」 であると考えています。 漸進的な成長を継続させることももちろん重要なのですが、NETFLIXの最強人事戦略(2018)に紹介されるエピソードのように、プロダクトの探索を行い、プロダクトだけに限らず、変化し続けるマーケットに対して問題解決の探索をしていくこと、そしてそれを実現していく過程を全てまとめたものがプロダクト人材の仕事です。 パティ・マッコード『NETFLIXの最強人事戦略-自由と責任の文化を築く』櫻井 祐子訳　(光文社、2018年)　序章 5.3 プロダクト人材とはどういう人材か、どのように働くのか 次に、プロダクト開発組織ではどのような人たちが、どのように働くのかについて解説します。 まず大前提として、プロダクト開発組織は 「さまざまな専門性のある職能を持った人が集まったプロフェッショナル組織」 であると考えています。それぞれが卓越した専門性をもち、自立したプロフェッショナルが集まっている組織です。 そして、私たちの仕事の目的である「変化し続けるマーケットの最前線でユーザーに成果を生み出し、世の中にインパクトを届けること」を達成するために、 プロダクト人材はマーケットの最前線で、かつど真ん中で仕事をし、プロダクトの成長と変化へ責任を持っている と考えています。 一方で、ひとりでは「不確実な市場」へ対処できないので、チームで動き、問題解決をしていくことが必要です。そのため、チームとして成果を生み出すための仕組みとして、共通のプロトコル（考え方、プロセス、約束事、ツール）を理解して働くことも重要です。 このように、マーケットやユーザーに向けて価値を提供するのはプロダクトチームとそこで働く個人であるため、組織というのはそれをサポートするインフラであると考えています。一人ひとりが「もし、自分がプロダクトのオーナーとしてすべての責任を担っていたら、マーケットとユーザーに最善のプロダクトを届けるためになにをするか」を常に考えて、その実現にリーダーシップを発揮し行動することを期待しています。 6. プロダクト開発組織の人材理念について ここから、プロダクト開発組織の人材理念について解説します。 全社の 人材理念 や行動指針との差異は、 コラボレーションを中心とした働き方 である点です。 全社のバリューである「価値主体・社会からの要請・変化対応・誠実」や、人材理念である「情熱・誠実・プロフェッショナル」を土台に、チームが主体の環境でいかにコラボレーションをするか、という点を強調した内容となっています。 また前提として、もちろん全体の戦略も重要ですが、それと同じくらいに プロダクト開発組織がユーザー接点の主役である 、という考え方を重要視しています。 例えば、プロダクト人材はプロダクト細部の手触りを生み出したり、エンジニアの場合はユーザー体験の構築や実装する1行のコードがユーザーが触れるものを生み出すことにつながっているので、まさにユーザー接点の最前線の仕事です。そして、このような点からもプロダクト開発組織がユーザー接点における重要な事実に最初に触れる人物であり、場合によっては全体の戦略を覆すような重要な事実へ触れる機会もあります。そのため、プロダクト開発組織が自立的に思考して意思決定をしていくことが非常に重要であると考え、これらをベースに人材理念を定めています。 プロダクト開発組織の人材理念は、「Purpose」「価値主体と情熱」「社会からの要請」「プロフェッショナル」「誠実」「自治と信頼」の６つに分解されます。 以下に、当日の説明資料を添付し、理念の詳しい定義を解説しています。 「Purpose」 「価値主体と情熱」 「社会からの要請」 「プロフェッショナル」 「誠実」 「自治と信頼」 ※ 文中の「あなたがコミュニティ」という表現は、「 Rubyist Magazine 0028号 巻頭言『コミュニティ』とは誰か 」から引用しています。 7. 最後に チームの拡大に伴い、改めて組織のバリューを言語化しました。チームがどこを向いて仕事をしていくのか、そして、何を大切にすべきなのか、共通の価値観を持って仕事をすることが重要であると考えています。 弊社ではエンジニアやプロダクト人材の採用を積極的に行っておりますので、ぜひご興味のある方はこちらよりご応募ください。

こんにちは！ 介護職向け求人情報サイト「カイゴジョブ」のアプリケーション開発と、全社共通インフラの仕事をしている 伊藤 です。 さっそくですが、みなさんはこのブログのタイトルを見てどんな印象を持たれましたか？ 昨今ではだいぶ認識が変化している気がしていますが、一昔前にはプログラマ35歳定年説というものもありましたね。 そんな定年説があるなかで、私はインフラエンジニアでありつつもアプリケーション開発へも挑戦している真っ只中です。 この記事では今まで自分はどんなことをしてきたのか、なぜアプリケーション開発をやりたいのか、チーム内でどうたち振る舞っているのか等をお伝えできればと思っています。 同じように新しいことに挑戦しようとしている、実際に挑戦中の方へ少しでも後押しできればとても嬉しいです:) 今までどんなお仕事をやってきたの？ 私は現在35歳ですが、秋頃には36歳になります。 2010年の新卒からインフラエンジニアとして継続して働いて、気がつけば今年で13年も経過していました、早すぎますね・・・ ※直近4年ほどではDevOpsやSREという職種でもお仕事をしてきましたが、インフラの業務がほとんどでした。 2010年 - 2018年: SIer/ソシャゲ/ISP/オンライン英会話の会社でオンプレやAWSを使ったインフラエンジニアとして働く 2019年: HRの会社で初めてDevOpsとして働く この辺りからgemを作ってみたり趣味でコードを書くことが増え始める 2020年: ECにおける在庫管理システムの会社でSREとして働く 2023年4月: エス・エム・エスで、アプリ開発・インフラの兼務で働く アプリケーション開発に挑戦したいと考えたきっかけ 実は明確に何かがあって挑戦したいと感じたわけではなく、 以下のような小さなことの積み重ねで挑戦したい気持ちが湧き上がりました。 趣味でコードを書くことの楽しさ 必要性を感じて自分でググりながらコードを書いて日々の業務に活かすことの楽しさを少しずつ感じていました。 例えば、以下のような具合です。 AWSのマルチアカウント構成でチェックボックスにチェックをいれると上位に表示してくれるChrome拡張 マルチアカウント環境でインフラエンジニアだと数十個表示されことがありますが、常用アカウントは数個で都度アカウント検索がめんどくさくて作りました ランチャーアプリのRaycastでKibelaを表示するプラグイン Googleカレンダーに入力したスケジュールで作業時間を計算するgem 日報に活動内容や時間を計算するのがめんどくさくて作りました フィヨルドブートキャンプ さんでアプリケーション開発を学ぶ 過去に退職後の有給消化のタイミングで勉強していたことはあったのですが、仕事が始まるとなかなか時間を取れなくて休会していました 現在は少しずつ再開しています🏃 知識欲(特に仕組み)の渇望 元々自分の性分として全てのレイヤーを知りたいという欲求がありました。 例えば、自宅から目的のサーバまでのネットワーク経路や、NICにパケットが着信してからLinux Kernel、プロセスに渡るまでの流れやプロセスそのものの仕組みといった具合です。 オンプレ時代であればMHA for MySQLでフェイルオーバーするときにネットワークレイヤでは何が起きてどういう仕組みでアプリケーション側から影響がほとんどないように見えるのかを検証するのもとても面白かったと記憶しています。 当時、 O’ReillyのUnderstanding Linux Network Internals を見てARPのキャッシュ管理方法としてGCの仕組みがあることや、デバイスドライバからユーザーランドまでパケットが処理されていく図を見て、こうなってるのか！とワクワクした記憶があります。 細かいところはまだまだ知らない世界は山のようにありますが、日々のインフラの業務をこなす上で必要最低限の知識は少しずつ身についていた感覚があります。 その一方で、プロセスから先のデータ処理については一部のコードを見ることはあっても通しで全体を理解するところまでは踏み込めていませんでした。 仕事への慣れ 2018年頃からインフラエンジニアとしての仕事にも慣れてきて、よくある構成の構築や運用はあまり苦労することなくできるようになってきました。 例えば、新規でサービスを作るためにサーバーを一式用意してほしいと依頼があったとします。 サーバーはクラウド、監視やデプロイ周りはSaaSで要件を整理しながらAnsibleで書けば1週間くらいあれば開発環境は用意できそう。といった形でゴールまでの道筋や手数がやる前から大体掴めますし、多少想定外があってもtcpdumpとstraceがあれば問題の切り分けくらいはおおよそつくといった具合です。 俗に言うコンフォートゾーンに突入し始めてしまったのがこの時期で、少しずつ危機感と日々の業務に退屈さを感じ始めていました。そうしたなかで、新しいことを始めていきたいと考えるようになりました。 こうして振り返ってみると、コードを全く書いてなかったわけではないですし、アプリケーション開発を主としても働けるのではないの？と思われる方もいらっしゃるかもしれません。 しかし、実はここまで書いているコードにはテストコードはほぼありませんし、コード自体もいわゆるシェルスクリプトの延長くらいの書き方しかしたことがありませんでした。 また、まともにフレームワークを使ってWebシステムを作ったことはありませんでしたし、 数ヶ月に1回程度しか思い起こさないので、初歩的な書き方すら都度思い出すような状態です。アプリケーション開発を本職とするには経験が不足していたことをお分かりいただけると思います。 転職活動について 転職ドラフト で指名を頂いたことがきっかけになります。 会社としてどういう期待・見通しでの指名だったのか 最初はインフラエンジニアとしての立ち位置で指名を貰っていました。ただ、カジュアル面談でRubyを使ったアプリケーション開発をしていきたいことを伝え、正式な選考ではインフラチームとカイゴジョブチームの責任者と面接をしていました。 カイゴジョブチームでは専任のSREがいなかったこともあり、アプリケーション開発に携わりながらインフラ面を強化できる立ち位置として期待されていました。 インフラチームでは、今までのインフラエンジニアとしての経験と合わせてカイゴジョブチームで得られたSREとしての経験を全社に展開できることを期待されています。 入社後について 働き方 月曜日〜水曜日はカイゴジョブの開発をしており、木曜日と金曜日はインフラチームの業務を行っています。 稼働日は厳密に定めているわけではなく、カイゴジョブのタスクを優先したり、逆にインフラタスクを優先したりと裁量を持った上で働けています。 入社してみてどうだったか 10年ぶりくらいに毎日知らないことだらけの世界に飛び込んで、正直必死です（笑） ですが、チームの雰囲気はとても良く、ペアプロ、ペアワークを推奨していてとても楽しくお仕事できています。 私がメインで働いているカイゴジョブチームはとても大人なチームで、いわゆるHRTの原則をとてもよく体現されています。 また、隔週でスプリント・プランニングを開いているのですが、タスクのゴールまでのイメージのすり合わせがとても丁寧に感じています。 今まで私が所属していた組織では個々が独立して動くことが多かったため新鮮で、とても助かっています。 ※インフラエンジニアとアプリケーション開発エンジニアの職種の違いというのもあるかもしれません 入社後に意識していること 無理に一人で仕事を進めようとしすぎない 先述の通り、カイゴジョブチームではペアワーク・ペアプロを推奨しています。 一人で進めていくことも大事ですが、無理に一人で進めてチームとしての生産性が上がらないのも困ってしまいます。 こんな感じでSlackで投稿するとメンバーが反応してくれますし、 朝会等で今日は手が空きそうなのでペアプロ求める人がいたらお声がけください〜！といった呼びかけも当たり前に発生しています。 わからない、つまづいているときは素直に周りに助けを求めて、逆に自分が手助けできるところは積極的にやっていくぞ〜！という気持ちになります💪 自分の過去の経験や強みを貢献して積み重ねていく 当たり前のことではあるのですが、私は周りと比較するとアプリケーション開発のみでは成果を出せません。 また、会社としての期待もアプリケーション開発のみではなく、SREとしての振る舞いを期待されています。 そこで、今までの経験からどうしたらチームに対して成果を出せそうかは常に考えるようにしています。 私の場合は、一例として次のようにインフラエンジニアとしての知見を共有できるように意識しています。 インフラエンジニアとしての振る舞いを伝える ペアワークで障害対応を行う 障害の予兆を検知した場合や発生した時にペアワークを行いメトリクスの読み方を伝えることでインフラレイヤのわかるエンジニアの動き方を少しでも伝えられるようにしています 例えばCPU使用率ひとつとってもユーザーランドなのか、Linux Kernelなのか、iowaitなのか、どういう時にこれらのパラメータが上がってどのくらいになると怪しく感じ、どう問題の切り分けを行っていくか等 ポストモーテムをドキュメント化する 障害対応についてドキュメント化することでペアワークしてないメンバーにも伝えられるようにします インフラ設定の改善 サービスの監視をどのようにすると良さそうかをドキュメント化する ECSオートスケーリングの改善 エス・エム・エスに入ってみて感じる強み インフラエンジニアとしてキャリアを積み重ねてきたメンバーをアプリケーション開発へも挑戦する機会を設けてチャレンジさせられるのはとても強いなと感じています。 ミドル・シニアクラスのメンバーの場合は過去の積み重ねがあり、そこを期待したうえで入社している都合上、 組織として期待値に沿うパフォーマンスをすぐには発揮しづらいであろう業務に時間を割り当てることを許容できる組織はなかなか多くはないのではないでしょうか。 時間が余ったら個人の裁量でアプリ開発のタスクを取ってもOKというのを見かけることはありますが、 日々の割り込み業務、開発タスクの期限、マネージメントへの期待というものがあるなかで、なかなか継続的に時間を確保するのが難しいのが現実だと思います。 入社して今日にいたるまで、実際にはインフラ業務を優先してアプリケーション開発の時間が割り当てられなかったということは一度もありませんでした。 入社前にアプリケーション開発もやっていきたいと伝えているので当然なのかもしれませんが、ちゃんと組織として対応できているのは凄いなと感じています。 最後に この記事の執筆時点(2023/07/05)で3ヶ月経過し、試用期間も終わりました。 まだ3ヶ月弱ではあるものの、振り返ってみると大きな会社としての良さは享受しつつチームで仕事をしているときは大きな会社特有の難しさみたいなものはあまり感じていません。 たとえば、継続的にRuby Kaigiをスポンサーしているのはもちろん、Rails Girls Japan、PHPerKaigi、iOSDC等様々なイベントにスポンサーしています。イベントに参加するときの経費は会社負担で、参加している日は出勤扱いですし、宿や交通機関のチケット手配もお願いすることができます。 また、 技術書はSlackで呟くと購入手配してもらえますし 、 オライリーのサブスクリプションサービスを使わせてもらえる制度 があったりと、技術に対する投資が活発な印象があります。 その一方で、ひとつひとつのプロダクトはチームとして独立性が高いためチーム内で合意形成できればスピード感を持って新しいものを導入したり変更しやすいと感じています。 ※もちろん、全社で利用している基盤のようなものであれば調整が必要になります。 大きい会社としての良さを享受しつつもスピード感を持って、 一緒に働ける仲間を募集している ので、興味を持っていただけたらTwitterでもリアルでも気軽にお声がけいただけたら嬉しいです！！

介護事業者向け経営支援サービス「カイポケ」アーキテクト兼プロダクトマネージャーの三浦です。 以前 テックブログにて紹介 しました「カイポケ」のフルリニューアルにおいて、データプラットフォームを作って行くことにしました。今日はなぜデータプラットフォームに取り組むのか、そしてこれから作るカイポケにおけるデータプラットフォームで重要な特性が何かをご紹介します。 介護職員が要介護状態の高齢者と向き合うということ 令和2年度末(2021年3月)時点で介護を必要とする65歳以上の高齢者は日本国内に682万人 *1 います。682万人の要介護の高齢者に対して、高齢者の尊厳を守ることを目的に利用者の自宅や介護施設で入浴、食事、排泄などの生活支援やケアの記録や業務日誌の作成、家族との連携などの業務を行うのが介護職員です。介護職員の人数は推定で約201万人 *2 います。 介護職員が働く介護事業所は全国に約25万 *3 もあり、その数はコンビニエンスストアの店舗数の約4倍 *4 に相当し、介護サービスは日本においてインフラサービスと言えます。 インフラサービスである介護ですが、介護職員が日々向き合う要介護状態の高齢者とはどのような存在なのでしょうか？そこには要介護状態の困難な特性が3つあると考えています。 1.要介護状態は長期間にわたる 介護が必要な状態になるとほとんどの方は亡くなるまで介護を必要とします。みずほ情報総研株式会社(現 みずほリサーチ&テクノロジーズ株式会社)がある自治体の2013年から2017年までの要介護認定のデータを分析した調査 *5 では、要介護の資格喪失者の約90%が死亡となっています。 また、死亡された方の要介護認定の期間を調べると15年程度が半数です。 介護が必要な状態になると約15年間、亡くなるまで介護サービスを受ける必要があり、介護職員は非常に長い期間、利用者と向き合う必要があります。 2.加齢に伴い様々な疾患が複合化する 加齢に伴う病気または心や体の状態の問題が複雑に関連しあうことで生じる、高齢者に多くみられる症状を老年症候群 *6 と呼びます。 この老年症候群は急性疾患関連、慢性疾患、介護の3つに分けられ、介護に関連する症状は75歳以上の後期高齢者から増加します。 高齢になればなるほど、そして要介護度が進むほど様々な介護サービスが必要となってきます。さらには介護だけでなく医療も必要となってきます *7 。 利用者の全体像を把握するためには、特定の介護サービスを提供する事業所に留まらず複数のサービス事業所や居宅介護支援事業所、そして医療との連携が日々必要になります。 3.要介護状態は不可逆性が高い 1年間での要介護状態の変化を区分ごとに見ると5% が軽度化、80%が維持、15%が重症化となっています *8 。 要介護度が軽度化する割合が低いことから、介護は医療と異なり治癒という前提に立てないという不可逆な構造があります。言い換えると介護サービスを提供していく中で、介護職員が利用者さんの状態が良くなるところを目にする機会は少ないと言えます。 今後さらにニーズが高まる社会背景 高齢者と長期間にわたって日々向き合う上で困難が多い介護職員ですが、85歳以上の高齢者は今後も増加するため、2040年度にはさらに約70万人が必要とされています *9 。 利用者さんの状態を介護・医療に関わる人全てが同じ情報を多角的に正確に把握し、利用者さんの状態が良くなる機会を増やすことで介護職員のやりがいを増やすことが、介護職員が圧倒的に不足するという社会課題を解決する上で重要であり、カイポケにとって支援するポイントの一つであると考えています。 「プロダクト」としてのカイポケのデータプラットフォーム 利用者の状態を多角的に正確に把握するためにはデータの利活用が必要となります。一方で平均年齢が 47.5 歳 *10 とされている介護職員であるためデータリテラシーは十分に高いとはいえません。そのため、利用者さんのデータを見える化するだけのテクノロジー中心のソリューションでは利用者さんのデータを十分利活用できるとはいえません。 データの十分な利活用のためにはカイポケのプロダクトのデザインと同様に既存の業務フローの分析に始まり、業務においてどうデータを利活用し利用者さんの状態が良くなり、最終的に介護職員のやりがいにつなげるのかという体験の設計が必要になります。 出典: DAMA DMBOK2 https://www.dama-japan.org/Introduction.html カイポケでデータプラットフォームを設計していくにあたり、特に大切にしたいことは介護職員のユースケースから逆算し、リサーチやテストを通じてユースケースの解像度を上げ続けることだと考えています。 カイポケのデータプラットフォームを作る上で高く求められること ではここまで説明してきたプロダクトとしてのデータプラットフォームをカイポケで構築する際に特に求められること、そして他のデータプラットフォームとの違いはなんでしょうか？ 重要な違いは以下の3つの特性にあると考えています。3つの特性はデータマネジメント観点から2つ、システム観点から1つの特性を挙げています。 出典: DAMA DMBOK2 https://www.dama-japan.org/Introduction.html データ品質: 利用者さんのバイタル情報などを扱うことから、高い品質が求められます データセキュリティ: 利用者さんの病歴などの要配慮個人情報を扱うため、高いセキュリティが求められます システム可用性: 利用者さんの情報がいつでもどこからでもアクセスできるプラットフォームが求められます これら3つの特性を高い水準で守るためのデータプラットフォームの設計、構築、運用をこれからしていきたいと考えています。 まとめ 介護職員が圧倒的に不足するという社会課題解決のため、そして利用者の状態をより良くするためのデータプラットフォームが必要であり、カイポケをフルリニューアルするこのタイミングでカイポケの顧客のためのデータプラットフォームを作っていくことにしました。この取り組みはテクノロジーによって長年の大きな社会課題を解決するというチャレンジであり、求められる品質はとても高いですがデータプラットフォームを推進していく面白さを日々感じています。 「プロダクト」としてのカイポケデータプラットフォームに興味ある方、腕試ししてみたい方はカジュアル面談でもっと具体的に作ろうとしているものをお話ししましょう！ *1 : 厚生労働省 令和２年度　介護保険事業状況報告（年報） https://www.mhlw.go.jp/topics/kaigo/osirase/jigyo/20/index.html *2 : 厚生労働省 第８期介護保険事業計画に基づく介護職員の必要数について https://www.mhlw.go.jp/stf/houdou/0000207323_00005.html *3 : 厚生労働省 令和３年介護サービス施設・事業所調査の概況 https://www.mhlw.go.jp/toukei/saikin/hw/kaigo/service21/index.html *4 : JFA コンビニエンスストア統計調査月報 2023年4月度 https://www.jfa-fc.or.jp/folder/1/img/20230522122726.pdf *5 : みずほ情報総研株式会社 要介護認定等データ及び介護レセプトデータを用いた 要介護度変化の予測モデルにかかる実現可能性等の調査(2019) https://www.mizuho-rt.co.jp/case/research/pdf/mhlw_kaigo2019_03.pdf *6 : 全国健康保険協会 高齢者の特性（老年症候群） https://www.kyoukaikenpo.or.jp/~/media/Files/kochi/20140325001/201701260083.pdf *7 : 厚生労働省 社会保障審議会第29回介護保険部会資料 *8 : 厚生労働省 令和３年度 介護給付費等実態統計の概況 https://www.mhlw.go.jp/toukei/saikin/hw/kaigo/kyufu/21/dl/11.pdf *9 : 厚生労働省 第８期介護保険事業計画に基づく介護職員の必要数について https://www.mhlw.go.jp/stf/houdou/0000207323_00005.html *10 : 公益財団法人介護労働安定センター 令和２年度介護労働実態調査 http://www.kaigo-center.or.jp/report/pdf/2021r01_chousa_cw_kekka.pdf