はじめに はじめまして。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

介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、荒巻です。 最近社内で、小さい技術ネタをなんでも発表できる会をはじめてみたので、その共有です。 ふだん社内では、まとまった技術情報は esa.io に書いているのですが、きちんとした文章として書くのは時間も心理的コストもかかります。 もう少しカジュアルに技術の話をできる場があったほうがよさそうだと思っていたところ、EMの酒井さん ( @_atsushisakai ) が前職で社内版potatotipsをやったことがあるという話になり、エス・エム・エスでもはじめてみることにしました。 社内版といっているのは、本家のpotatotips *1 を参考にしているからです。potatotipsは有志で運営されている、iOSやAndroidの技術トピックを持ち時間5分でどんどん話していくというスタイルの勉強会です。ただ、カジュアルではあるものの、5分のトークを組み立てるのは意外と大変です。 そこで社内版potatotipsは、この雰囲気を借りながらも、さらに気楽にできるように、以下のようにとてもゆるい感じでやっています。 自由参加 一人最大5分 30秒で終わってもいい 資料を用意しなくていい エディタ、ツール、フレームワークなど、技術ネタなら何でも構わない Slack channelでわいわい実況する なるべくリアクションする 最初はフロントエンドチームのみで小さくはじめ、参加者がぼちぼち定着してきたところで、他のチームからもtipsを募るようにしたところ、色々なチームの方々がtipsを提供してくれるようになりました。 実績としては、4ヶ月で110個のtipsが紹介されました。 ネタの投稿場所としてはGitHub Projectsのkanbanを使っています。ネタの種類に応じた場所にAdd Itemするだけです。 potetotips kanban たとえばこのようなネタが紹介されています。(この例はVue.jsのコードネームが日本の漫画やアニメから取っているという話) neta このようにカジュアルな発表の場があることで、新たな交流が生まれたり、さらに深掘りしたいことが思いついたりしそうです。今後とも続けていきたいと思っており、皆様の会社でも、ゆるい共有会をはじめてみてはいかがでしょうか。 *1 : https://potatotips.connpass.com/ 運営チームのtokoromさんからは、potatotipsの名前を出すことを快諾いただきました。

emfurupon777 です。今回はエス・エム・エス社内での最近の活動についてご紹介したく、筆をとりました。 中途入社の同期会結成 2023年度第一四半期入社から、同期会という取り組みを開始してみました。 発案のきっかけは、1on1で話していた同僚が 「普段の業務では関わり薄いんですけど、何だかんだでたまたま入社が一緒だった人と今でも時々話してるんですよねぇ」 と教えてくれたことでした。 弊社ではこれまで開発部門では基本的に新卒採用を行っておらず、私は”同期”という考えはあまり持っていませんでした。一方で彼の場合は、コロナによるオンライン勤務が始まる前に入社されており、全社オリエンテーションに参加したときに、同時期に入社した人となんとなく話をする流れになり、その後も関係が続いているとのことでした。 最近社内外のエンジニアと話していてよく聞く話ですが、オンライン勤務になったことで、一緒に業務をしているチームは濃い話を気軽にできるようになった実感があります。一方でチーム外とは若干距離が開いているかも……という課題を耳にするようになりました。 もちろん、エス・エム・エスもSlackでカジュアルになんでも発言して全く問題もないし、1on1だって勝手に設定してやればいい・・・どころかぜひして欲しいのですが、入社まもない時期にはなかなかにハードルは高く感じるよ、という声も正直耳にしていました。 そこでもう少しハードル低く自由に発言できる場として、 各四半期に入社した人を「同期」として、それぞれの「期」ごとのチャンネル（ex.「23年度第一四半期同期会」）を作っています 。これは特に何かを強制するようなものではなく、同時期入社で同じような疑問・ハードルにあたっていそうな人たちのための場を用意しておくことで、情報交換を遠慮なくしてもらう一助になればいいな！というものです。 LT会復活の模索 他にも私には漠然と抱えていた課題がありました。それは社内LT会です。エス・エム・エスでもコロナ前は集まってLT会を行っていたのですが、 オンライン勤務になるにつれ、読書会などは自然に継続できているものの、広くみんなを集めてのLT会はあまり実施できておらず、少しハードルが高くなっている 印象でした。 LT会というコンテンツを提供することでまずは「交流がうまれる」ことの促進ができれば良いな、ということで機会を窺っていました。（実は「まずはやってみる」の精神で去年末に納会をLT会形式で実施してみていたのですが、その後少し間が空いてしまっていたのです……） そんな中、同期会を結成した後に、その中のメンバーが所属チームでのオフサイトイベントに参加するため東京に出てくるという話を観測しました。なるほど、せっかくオフィスに集まるなら、同期会の交流も絡めてLT会にしたててみようと考えた次第です。 イベントの概要 今回のイベントは以下のような形で行いました。 開催場所：本社ラウンジ＋オンライン(Zoom) 開催時間：11:00-13:00 軽食提供：ソフトドリンク、ピザ、寿司、お菓子類 参加人数：オフィス参加約20名、オンライン参加約20名 気軽に参加してもらえるように、お昼の時間での開催としました。また、去年末のLT納会はピザだけだったのですが、今回はちゃんと(?)寿司も用意しました。いやー、やっぱり寿司はいいですねー。 発表者とトピックの紹介 社内LTであまりかしこまってもなんなので、かなり幅広くテーマを用意し、社内のLT会なのであまり堅苦しくならずに時間制限もゆるーく実施しました。 発表者は8人(2023年度第一四半期同期会から有志6名＋同期会外から社員有志2名)で、発表内容は、エンジニアリングの苦労話、ツールの紹介、チームでのプラクティスなど多岐にわたりました。 参加できなかった方のためにZoom録画もしていたのですが、「自分のLTはオフレコだ！」という登壇者もいて、それぞれのキャラクターの一端が見える一幕もありました。 ネットワーキングと交流の場 LTが一通り終了した後、ピザや寿司を食べつつ何気ない話に花をさかせました。これまでもオンラインで話はしていましたが、オフラインで話すことで得られる何かも確かにあるんだろうなと感じさせられました。 また、 『発案から運用開始まで3日。経費申請も出社も不要、技術書が自宅に届くデリバリー制度をスタートしました』 で協力していただいているコーポレート部門の担当者さんたちも顔をだしてくれて、普段のお礼をお伝えすることができたのは嬉しい出来事でした！（Kさん＆Tさん、いつもありがとうございます！) 感想と今後に向けて LT会の目的としては交流の場として以外にも下記のようにいろいろあるので、今後も継続して行ってさまざまな活動が活性化していければ良いなーと考えてます。 「人前で話すことに慣れる」 「言語化しアウトプットすることの実践」 「自分の意見のアピール、同好の士集め」 etc. とはいえ、主催した立場としてはまずはみんなが楽しめることが重要だとも思っています。今回、開催後Slackでこんな投稿を目にすることができたのが、まずは何はともあれいい感じ。 私自身、同期会という、新規に始めた取り組みと合わせて、オフィスでのLT会を実施できて非常に楽しかったです。 また、会社をまたがってのLT会なども行えるとお互い刺激になるだろうなーとも考えておりますので、一緒にわいわいしていただける会社さんはぜひ@emfurupon777までご連絡くださいませ！ お約束にはなりますが、エス・エム・エスでは一緒に技術を楽しみながらプロダクト開発してくれる仲間を積極採用中です。まずは弊社のことをもっと聞いてみたいというレベルからで構わないのでカジュアル面談しましょう！ 集合写真も久しぶり おまけ LT会の間、Slackの実況chでみんながわいわいとやっており、自分がなんとなく投下した40代ネタが流れそうなところを、若者が拾ってくれる優しき流れもあったりします。

こんにちは、株式会社エス・エム・エスに2022年10月に入社した真田です。 前職ではメガベンチャーで証券や金融サービスのサーバーサイドエンジニアやSREを担当してきました。現在エス・エム・エスでは介護教育領域のシカトルのシステムのリプレイスを担当しています。 少し他の方と違うのは、2017年から2019年に約2年ほどエス・エム・エスに在籍しており、再入社となります。前回入社時はカイポケの障害領域のエンジニアやエンジニアリングマネージャーなどを担当していました。 再入社に至る経緯をお話したいと思います。 再入社するにあたってのきっかけ 前職は3年ほど在籍しましたが、日本でもトップレベルのユーザー数を抱えているため、ユーザー数やシステムのトラフィックは桁違いです。 スケーラビリティ、可用性などエンジニアに求められるレベルは高く、また同僚のエンジニアも高いレベルのエンジニアが多く海外から入社するエンジニアも多いため、そういった点ではとても恵まれた環境でした。 こういった部分ではかなり貴重な経験が積める一方、サービスや事業を作るという部分の実感が少ないというのも事実です。 役割が細分化されている分、各領域のプロフェッショナルな人材が配置されることでサービスが成長しています。これは会社の仕組みとしては適切だと思います。 しかしサービスや事業の成長に寄与している実感がもてず、満足することができませんでした。 こういった経緯で、他の選択肢を探していたところ偶然twitterで以前一緒に働いていた技術責任者の@sunaotに声をかけていただきました。（飽きっぽい性格でもある私のツイートに反応していただいたのがきっかけです） 他社も含めていくつか検討はしていましたが、主に事業サイドの方に面談や面接をしていただき最終的にエス・エム・エスを選択しました。 私が求めているもの 転職するにあたって下記の２つを求めていました。 社会にダイレクトに価値提供できる仕事 エス・エム・エスは高齢社会の情報インフラを提供することを目指している会社です。 介護・医療・ヘルスケア・シニアライフなど直面した社会課題に対して価値を提供することができます。 私も年齢を重ねるにつれて介護・医療などについては身の回りで現実に考えさせられることが多くなってきました。これは年齢を重ねると誰しもが向き合わないといけない課題です。 そういうことを考えている内に、自分の手でこういった環境を良くすることで社会課題の解決に寄与することを仕事にすることが良いのではと考えました。 ビジネスを加速させるためのエンジニアリング 新しい領域の技術を求めるのも楽しいですが、それよりもエンジニアリングやシステムに課題があり、それを解決すればビジネスを加速させ事業の成長に貢献できる環境を求めていました。 エス・エム・エスはセールスやマーケティングが非常に強い会社です。 戦略から事業のオペレーションが設計され、複雑ながらもスピード感をもって実行されています。 そこにエンジニアリングが強化されることでさらなる成長が見込まれると感じています。 エンジニアリングについては、@sunaot が入社後に内製化を進めてから体制や環境はかなり強化されてきたとはいえ、まだまだ他の企業と比べると手が届かないところが多いのも事実です。 エンジニアリング組織体制が強固な企業よりも、成長過程にある会社のほうが貢献できるのでは？と考えました。 エス・エム・エスで得られるもの エス・エム・エスは事業戦略を重要視している会社です。 全社の戦略から各事業領域の戦略にブレイクダウンした情報を現場のメンバーまで知ることができます。また自身が担当でない領域についても必要であれば知ることもできます。 私もこれまで何社か経験していますが、ここまでオープンに知ることができる企業はありませんでした。 疑問があれば役職を問わず、誰にでもその疑問をぶつけることができますし、必要な情報を求めれば得ることができます。 エンジニアが事業戦略を理解する機会があることは非常に重要だと考えています。 ビジネスの現状の重要な課題を理解し設計することで、システムに影響がある大きな変更も一貫性を持ってすることができます。 もちろんうまく行かないこともありますが、既存の戦略に固執せず、柔軟に変化するという思考も持ち合わせているところがエス・エム・エスの良いところです。 以上が私がエス・エム・エスを再入社することを決めた理由です。 エンジニアとして仕事をする上で、ビジネスと会社の成長に寄与しているという実感を持って働ける環境だと感じています。 エス・エム・エスが事業を展開している介護・医療・ヘルスケア・シニアライフの領域の課題は、日本の人口推計上避けては通れない、非常に重要な課題で今後も変化し続けます。 変化が大きい分、課題も多く複雑で、エンジニアリングとしての難易度も高く楽しめる部分も多くあります。 エス・エム・エスでは多くのエンジニアを必要としています。事業戦略からサービスやシステムに落とし込んで開発をしたい方にはおすすめできます。 もしこの記事を読んで、少しでも興味があれば一度お話を聞いていただければ幸いです。

カイポケフルリニューアルプロジェクトの2つのチームのモブプロ事情 「カイポケ」のフルリニューアルプロジェクト で開発を行っている soranakk と setoh の所属しているそれぞれのチームでは、モブプログラミング(モブプロ)が盛んに行われています。今回はモブプロについて、良いところや注意しないといけないところ、工夫して改善しているところについて聞きました。 話し手の紹介 soranakk : プラットフォームチームに所属する元Androidエンジニア。Kotlinを使ったバックエンドやReactを使ったフロントエンド実装をしたりしている。モブプロは現職から盛んにやり始めた。 setoh : フロントエンドチームに所属する元Androidエンジニア。前職から5年以上モブプロの経験がある。soranakkとは新卒の会社時代の同期。 モブプロの良いところはなんですか？ soranakk チームで共通認識が持てる のがいいなって思っています。例えば設計について一口にアーキテクチャといっても、その適用には濃淡があって、コーディング時にどのくらい厳密に適用するかには選択の余地があると思います。完全に厳密に適用する、言語仕様等で難しいところは変更することを許容する、やりすぎず細かいところは柔軟に変える、などなど。どれが正解ということはないですが、同じコードベース上では粒度を揃えておかないとメンテナンスが厳しいコードになります。それをモブプロで一緒にコーディングすることで肌感を揃えることができるのがいいと思います。 あとは コードの属人化の防止 です。例えば新しい技術やライブラリを使うとき、ある機能の開発を担当した人だけが詳細な仕様を知っている、という状態がよくあります。こういうところをモブプロで行うことで、機能拡張やメンテナンスを当初の担当者だけではなくチーム全員で行うことができるようになります。 またチームビルディングの観点でもモブプロは有用で、 コロナ禍のリモートワークの状況での貴重なコミュニケーションの機会 になります。コーディングをしながらコードや機能の気になるところを話し合ったり、ワイワイとコミュニケーションしながら開発するのはとても楽しいです。 setoh soranakkも言っているとおり、同僚と技術的な認識を合わせる場としても効率的だと思っています。自分がチームに入った際にはまだチームのコーディングガイドラインはまだ未完成だったのですが、オンボーディングも兼ねてモブプロをしているうちに色々な案が出てきました。 モブプロを通して複数人で同じコードを実装しているのでガイドラインを書く際の前提となる認識が一致しており、ガイドライン化の必要性などを摺り合わせなくて良いので非常に楽 でした。 それ以外では、 オンボーディングの一環として使う のは実際に体験してみて良いと感じました。自分が所属するフロントエンドチームではオンボーディングの一環としてモブプロを取り入れており、自分がチームに入った後すぐにモブプロでコードを書き始めました。自分はエス・エム・エスに入社するまでフロントエンド開発は未経験だったので開発についていけるか非常に不安でしたが、 理解が足りない点や実装の背景が気になる点をすぐに同僚に聞けたり、同僚の効率的な実装手順を見ることができて、とてもスムーズにキャッチアップができた と思っています。モブプロ中の雑談からVS CodeのオススメのExtensionsなどを知ることができたのもモブプロならではのメリットだと思います。 注意しないといけないところはありますか？ soranakk 実際にモブプロをしていて起こったことなのですが、 新しい技術を触っていて詰まった場合に非効率になってしまう ことがありました。知らない技術なので調べるだけでなく、動作させて試しながら探る、みたいなことをやりたくなった時に、モブプロで行うとドライバー役の一人しか出来ない、という状況になったりします。 あとは、前にモブプロでやった内容に近くてチームの誰がやっても同じになるよね、ぐらいの 共通認識が持てている箇所をモブプロでやっても得られるものが少なくなってしまう などが挙げられます。 setoh 自分は前職から5年以上モブプロをやっているので、割とアンチパターンを踏んできた方だと思います。 よくある失敗はモブプロで情報を共有したことで満足してしまい、ドキュメント化を忘れてしまうこと です。 過去の一番大きな失敗として、モブプロで実装した部分のPRは時間短縮のためにdescriptionを雑にして良いというルールを作ったこともあったのですが、後からチームに加わった人がPRの経緯が分からなくて困るということがありました。口頭での情報共有で満足せず、 モブプロで決まった方針や経緯はしっかりと議事録やチームのルールとして明文化し、モブプロの場にいない人にも共有する という意識が必要だと思います。 モブプロのドライバーはしゃべりながら実装するので非常に疲れますし、ナビゲーターもコードを読みながら他人にコメントをしていくので頭を使うので疲れますし、達成感を感じます。でも その達成感の割にアウトプットや学んだことがあまりない場合も多い 気がしています。達成感を抜きに考えて、しっかりとモブプロの目的を達成できているのかを考えるようにしています。ミーティングの基本に近いものがありますが、モブプロの前と後で目的を確認することなども有効かもしれません。 工夫しているところや改善しているところを教えてください！ soranakk 新しい技術についてモブプロをやる時に詰まった箇所が出てきたら、最初の数分は一緒に調査します。この時はドライバーの人は動作を試しながら探り、ナビゲーターの人はググったりして文献調査するという感じで役割分担しながら進めます。そして数分で解決出来なかった場合は、そこで モブプロを切り上げて個別に調べて、次回に持ち越し って感じにしています。また事前に詰まりそうなところの調査をしておいて、目処が立った状態でモブプロを開始するようにもしています(この文献にある方法でやれそう、みたいな感じで調査しておく)。 あとは共通認識が持てているとチームで認識した箇所についてはモブプロでは行わず、PRのレビューでコミュニケーションを取るようにしています。あるいは、 どういう方針で実装するかの設計までをモブプロで行った後、実装は個別で行ってPRのレビューでコミュニケーションを取る 、みたいな工夫も行っています。 setoh ドキュメントを残すという点では色々試行錯誤をしました。モブプロが終わった後でやったこと・勉強になったこと・決まったルールなどをみんなで議事録を書いたこともありました。しっかりとしたドキュメントが残ったのは良かったのですが、負担になってしまいモブプロに気が乗らなくなってしまったりしました。現時点でのベストプラクティスとしては、 書記担当を用意してモブプロ中に議事録を作るスタイルが良さそう に感じています。 前項でsoranakkも書いているとおり、効率性には気をつけています。4人でモブプロをすると1人でやる場合の4倍の工数を消化するので、それに見合う成果を出すためには何をすべきなのかという点はいつも考えています。 モブプロの時間だけで工数に見合うアウトプットを出すのはなかなか難しいため、認識合わせや議論が起こりそうな実装など長期的に考えてチーム全体のパフォーマンスが上がるような内容をやる ようにしています。 お互いの話を聞いてみての感想をお願いします！ soranakk setohも書いている通り、モブプロの間に話した内容のドキュメント化は課題だと認識しています。 対策としてモブプロ中に一緒にドキュメント作成をするようにしたりなどをしていたのですが、書記担当を決めるというのも良さそうだと思いました。チームのモブプロに取り入れていきたいと思います。 setoh soranakkの所属するチームはほぼ毎日モブプロを行っており、どんな点を意識しているのか気になっていたのですが、モブプロに対する大きな認識のずれはないということがブログ記事を通して改めて分かったのは良い知見でした。自分の所属するチームに最近入った同僚がいるので、コミュニケーションを目的としたモブプロを増やしてもいいのかなと思いました。 最後に エス・エム・エスではモブプロやペアプロを積極的に活用し、効率を意識した開発を行っています。 エス・エム・エスでのモブプロに興味がある方や、フロントエンドやバックエンド開発へのキャリアチェンジに興味があるAndroidエンジニア *1 の方はカジュアルにお話しませんか？ tech.bm-sms.co.jp *1 : soranakkはAndroidエンジニアからバックエンド開発に、setohはAndroidエンジニアからフロントエンド開発にそれぞれエス・エム・エス入社時にキャリアチェンジしています。

介護事業者向け経営支援サービス「カイポケ」の開発をしている 橋本 宙 です。 本稿では私の所属する介護レセプトチームで実施している、「ユーザー業務とシステムに対する知識獲得に関する活動」を一部紹介します。 今回紹介する活動 介護レセプトチームは、カイポケの介護領域の開発を担当するチームです。 介護レセプトチームでは、3年に1度「介護報酬改定」という大きな制度変更に伴うシステム改修が発生します。(「介護報酬改定」については こちらの記事 を参照してください) 「介護報酬改定」は、継続的にアップデートしている大きなシステムを、短い期間かつ限られた情報を解釈して対応しなければならないという特性があるため、チームとしてユーザー業務とシステムに対する知識のベースラインを上げていくことが重要だと考えています。 知識のベースラインを上げていくためのさまざまな活動を実施しているので、今回は以下の2つを紹介します。 ユーザーストーリーマッピングで業務理解 コードを読みフローを描くことで実装や処理の流れを理解 ユーザーストーリーマッピングで業務理解 「ユーザーストーリーマッピングで業務理解」とは、ユーザーの行動を時系列に書き起こすことでユーザーの行動を認識し、書き出していく中で出てきた疑問点を解消していくことで理解を深めていく活動です。 私たちのチームでは、「介護報酬改定」で手を加えそうな部分の業務知識が薄かったため、業務を整理し理解するためにユーザーストーリーマッピングを実施することにしました。 事前準備 どの業務について理解を深めるかの選定 今回は「介護報酬改定」で影響を受けそうだが、メンバーの理解度が低い業務を選定 miroなどのオンラインホワイトボードツール 業務の一般的な流れのわかる資料や本 進め方 エンジニアとPdMが全員参加で週に1時間確保し、始まりから終わりまでユーザーストーリーマッピングし終わるまで繰り返し実施 業務の始まりから終わりまで描き終わったらドメインエキスパートを呼んで、読み合わせと疑問を解消する会を実施 工夫したこと ドメインエキスパート不在の状態で書いたこと 自分達で集めた資料を元に想像しながら書き起こしてみることで印象に残りやすいと考えていたため、わからないなりにアウトプットしてみました。 全員で質問し合いワイワイ話しながら進めたこと 開始時点では業務やその周辺の制度の理解度にばらつきがあったので、質問も交えながらゆっくり進める方針にしました。 疑問がでてきたら付箋にメモを書きながら進めたこと ドメインエキスパートに聞きたいことを忘れないようにというのと、人数が多く全員で会話できる形ではなかったので付箋を書いて貼っておく形にしました。 ペアプログラミングのようにドライバーとナビゲーターとに役割分担をしたこと 全く前に進まないことを防ぐために、ある程度詳しいメンバーがドライバーをやり、残りのメンバーはナビゲーターとして事前に用意した資料や本を使って補足したり、理解することに集中していたりしていました。 コードを読みフローを描くことで実装や処理の流れを理解 「コードを読みフローを描くことで実装や処理の流れを理解」とは、業務整理した部分に関わる機能のコードを読み現状の仕様や処理の流れなどをアウトプットしていく活動のことです。 該当機能の仕様について詳しい人がいない状態だったのと、「介護報酬改定」が短い期間で対応をしなければならないことを考えると早めに詳細を理解して「介護報酬改定」に備えたいと考え実施しました。 事前準備 グループ分けをしておく 1グループ2~3名になるように この活動を優先してよいという共通認識を持つ 普段の業務もあるので時間が取れないことを避けるため 進め方 グループごとに進め方は一任 2週間後に共有の時間を押さておく とあるグループの進め方 まとめ方のイメージも擦り合わせられていないので、集まるタイミングだけ決めて個人で思い思いにコードや業務の資料を読みmiroに書き出す 各々のアウトプットをみて会話しながら処理フローを書き出す 処理フローに登場する処理1つ1つコードを読み、input/outputを整理 制度の知識、現行システムの詳細な仕様などは適宜メモ欄に記入 工夫したこと アウトプットイメージを決めすぎないこと アウトプットイメージに引っ張られて、それを作るためだったり認識合わせに時間取られたりするのはやりたいことではなかったのと、詳細の調査をしたいときにアウトプットイメージから考えると制約になってしまう可能性もあったのでアウトプットの指定はせずに進めました。 少人数のグループ分けをしたこと 「ユーザーストーリーマッピング」と同じように大人数で広く業務を理解するのではなく、処理をより深掘りできるように少人数で手を動かしやすい形で進めました。 期限を設けたこと 間延びしてしまい時間をかけた割に学びが少ないということを避けるために期限を設けました。 成果物を共有する形式にしたこと 共有するという活動を通して、共有する側も理解を深める機会になるし、共有を受けた側は知らなかったことを知ることができるようになると考え共有する時間を設けました。 この活動をやってみての感想 よかったこと どの業務でどの機能をつかっていて、その機能のinput/outputが明確になったことで、改修時の影響がある程度わかるようになったこと 介護レセプトチームではスキルマップを活用してチームの状況を可視化していて、チームメンバー全体の知識のベースラインがあがっているような結果になったこと 「業務理解」で広く浅く業務を理解した上で「コードを読む活動」を実施したことで、全体像を掴んでから詳細に踏み込む形になり、コードが読みやすかったこと 少人数で活動をすることで、遠慮や配慮から発言を控えたり後になってから発言したりするようなことがなくなり、質問や会話がしやすくなり理解を深めやすくなるということがわかったこと 課題 今回紹介した活動はそれなりに時間を使う活動であり、全ての機能に対して同じようにやることが現実的ではないこと この課題に関しては、チームメンバーのほとんどがわからない機能で、重要度も高く、今後手を加える可能性が高いものに絞って横展開をしていこうと考えています。 最後に 「介護報酬改定」に追従し、改定後も使えるシステムにすることはもちろん、顧客が求めているものを的確に提供するためにも、ユーザー業務とシステムに対する知識獲得に関する活動はさまざまなアプローチで続けていこうと思っています。

6月6日(火)～9日(金)に熊本城ホール+オンラインで開催される「 2023年度 人工知能学会全国大会（第37回） 」にて、弊社が関わっている研究の発表が行われます。 また、弊社は今回の大会をシルバースポンサーとして支援しております。 イベント概要 名称：2023年度 人工知能学会全国大会（第37回） 日時：2023年6月6日(火)～9日(金) 会場：熊本城ホール(熊本県熊本市) ＋ オンライン 主催：一般社団法人人工知能学会 公式サイト： https://www.ai-gakkai.or.jp/jsai2023/ JSAI2023はついに来週からの開催となります！大会へ参加される方へのご案内を大会HPに記載していますので是非ご確認ください． https://t.co/KDy8AXkGPM #JSAI2023 — JSAI2023 @ 熊本&オンライン (@jsai_official) 2023年5月30日 発表1: インダストリアルセッション5「エス・エム・エスにおけるAI技術活用事例」 日時：6月7日(水) 15:30～17:10 会場：C会場 confit.atlas.jp ヘルスケア事業における食事画像解析プロジェクトを中心とした、AI関連技術の活用事例の紹介を行います。 発表は弊社Analytics&Innovation推進部の小貝が行います。 なお、今回の発表とは直接関係ありませんが、小貝が過去に書いたブログ記事はこちらです。 tech.bm-sms.co.jp 発表2: ポスターセッション2「強化学習によるマッチング数を最大化するジョブ推薦システム」 日時：6月9日(金) 09:00～10:40 会場：X会場 confit.atlas.jp 求人広告における強化学習を用いた推薦システムの紹介を行います。 こちらは、弊社と東京大学大学院情報理工学系研究科・鈴村豊太郎教授との共同研究です。なお、発表は東京大学大学院の脇聡志さんが担当されます。 おわりに 弊社では、データサイエンティストの採用も積極的に行っています。研究内容に興味を持っていただけた方はぜひカジュアル面談にお越しください！ データサイエンティスト / 株式会社エス・エム・エス データサイエンティスト(AnalyticsTranslator) / 株式会社エス・エム・エス

こんにちは！介護職向け求人サイト「カイゴジョブ」の開発をしています、ソフトウェアエンジニアの唐澤（ @katorie ）です。最近の関心ごとは「アクセシビリティ」です。 突然ですが、Rails Girls というコミュニティをご存じですか？ Rails Girls とは Rails Girls は、プログラミング初心者の女性たちが Ruby on Rails を学ぶことを支援する国際的なコミュニティです。2010年にリンダ・リウカスさんによってはじまり、日本でもワークショップが各地で開催されています。日本においては Rails Girls Japan がワークショップなどの運営や会計などをサポートしており、日本各地で開催されるワークショップの他にも RubyKaigi への参加支援や、学習を継続したい参加者のための勉強会 Rails Girls, more! をおこなっています。また、この活動を支援したいと考える企業には単発の「イベントスポンサー」と活動全体を支援する「年間スポンサー」の2種類の関わり方があります。そして株式会社エス・エム・エスは2023年度の年間スポンサーをしています！ Rails Girls Tokyo 2023年4月7日（金）と8日（土）の2日間、東京で第15回目となる Rails Girls Tokyo が開催され、私も参加してきましたので、当日の写真とともにその様子をお伝えしたいと思います。（写真は Rails Girls Tokyo 15th オーガナイザーチームからご提供いただきました！ありがとうございました！） Rails Girls のワークショップは基本的に2日間かけておこなわれます。1日目には参加者それぞれのPCに必要なツールをインストールして開発環境を整えます。2日目は4〜5人ずつのグループにわかれて、はじめてのウェブアプリケーションをつくっていきます。 参加者（ガールと呼びます）に対しコーチがついて開発環境のセットアップから一緒に進めていきます。時にはマンツーマン以上のことも。とても手厚いサポートを受けることができます。 ワークショップの最後には、今回はじめてつくったウェブアプリケーションがデプロイされるので、参加者の達成感に満ちた笑顔がとっても素敵です！ 写真を通して雰囲気は伝わりましたでしょうか？ また今回のランチタイムは感染症対策のための黙食となっていたので、コンテンツとしてオーガナイザーのえりりんさんと私がおしゃべりさせてもらいました。私は2013年に開催された Rails Girls Tokyo 2nd をきっかけにエンジニアになる勉強をはじめたので、その後どのように勉強を続けてエンジニアになったのか、参加したコミュニティやRubyKaigiでの思い出などを混じえてお話しさせていただきました。 またスポンサー企業がLTをする時間もいただいたので、私もエス・エム・エスのメンバーとしてLTしました。エンジニアを目指すきっかけとなったRails GirlsでスポンサーとしてLTできるのはとっても嬉しいことだったので、スポンサーLTだったのですが、個人的な想いをつめこんだLTをさせていただきました！ 介護業界の抱える問題と、それに立ち向かう弊社の事業について簡単にご説明させていただきつつ、私がなぜカイゴジョブの開発をしているのかという秘密（ちょっとヨコシマな事情）もお話ししました。（続きはカジュアル面談で） 最後に Rails Girls の活動はもう10年以上続いていますが、まだまだ需要は尽きることなく、今後も全国各地で開催されることを願っております。株式会社エス・エム・エスとしても今後もサポートを続けていきたいと思っています！ Ruby や Ruby on Rails のコミュニティとも関わりの多い株式会社エス・エム・エスでのお仕事に興味を持たれたかたは、ぜひご連絡ください！

こんにちは、介護事業者向け経営支援サービス「カイポケ」のフロントエンドエンジニアの setoh です。2022年12月から株式会社エス・エム・エスで働いています。 私は大学時代にAndroidアプリ開発を始め、就職後は一貫してAndroidアプリ開発を軸に10年以上のキャリアを積んできました。しかし心機一転、エス・エム・エスに入社後はこれまで全くの未経験であったフロントエンドエンジニアとして業務を行っています。 今回の記事ではAndroidアプリエンジニアがフロントエンドエンジニアとして業務をこなせるようになるまでに効果的だった学習内容について書きます。 学習する観点 以前に同じフロントエンドエンジニアの城内が記事にしていますが、「カイポケ」のフルリニューアルプロジェクトではTypeScriptとReactを採用しています。まずは業務レベルでコードを書けるようになるために、こちらの内容を中心に学習することにしました。 tech.bm-sms.co.jp 今後フロントエンドエンジニアとして働いていくためには幅広い分野の知識をしっかりと身につけることが必要だと思っており、長期的にそこを目指していくために言語とUIフレームワークから基礎固めをするという狙いもありました。 実際、入社3ヶ月以内には任されたタスクを設計に沿って1人で実装できるレベルにはなっていたため、ある程度効果的であったと感じています。 React 以前から「Reactは難しい」「React何もわからない」という話をよく聞いていたためかなり警戒しており、まず最初に学習することにしました。 業務でReactを使う複数の友人から『りあクト！』シリーズ *1 を読む事を薦められたため、転職前のタイミングで読みました。 前職のAndroidアプリでは宣言的UIフレームワークであるJetpack Composeを採用していました。そこで、同じく宣言的UIフレームワークに分類されるReactはJetpack Composeとどのような点が同一でどのような点が異なるのかという観点を意識して比較することにしました。結果として、自分にとってはJetpack Composeと細かな違いはあれど大まかな書き方では同一に感じ、あまり苦労せず基礎を理解できました。 また『りあクト！』では、JavaScriptの成り立ちから解説されていたため、自分のようにフロントエンド経験がない人には基礎知識のキャッチアップとして役立ちました。 入社後1~2ヶ月くらいまでは『りあクト！』を片手にコードを書くことも多くありましたが、最近は内容が一通り身についたため、Reactの公式のリファレンスから情報を得るようにしています。 TypeScript TypeScriptとKotlinは構文が似ているという認識だったため、最初は書き方がわからない部分について逆引き的に調べていました。しかしコードを書くことが増えるにつれ両言語には思想のベースが異なる部分が多々あり、TypeScriptの基礎から学ばなければTypeScriptとしての良い設計ができないと気付きました。 良い評判を聞いていたので 『プロを目指す人のためのTypeScript入門』 を読んで学習することにしました。TypeScriptの基本的な文法から細かな仕様までが網羅されており、業務で頻繁に使う仕様を把握するには効率的な本でした。 この本を読んでからは以前より高い解像度でコードを読み書きできるようになったと感じたため、もっと早く読むべきだったという後悔があります。 学習したことを身につける 自分は座学や読書の学習が好きであまり実践をしないという悪癖があるのですが、実践せずとも学習しただけで初心者でもすらすらとコードが書ける...というような甘いことはありませんでした。 フロントエンドチームではチームビルディングの一環としてモブプロをしており、自分も入社3日目から参加しました。本を読んで完全に理解した気になっていたのですが、いざモブプロになると全くコードを書く手を動かせずに固まってしまい、学習したことがコーディングに生かせるほど身についていないと認識できました。 自分はモブプロに慣れていたので「何をしていいか皆目見当がついていない」「○○は理解できているしそれを使いたいが、そこまで持っていく実装がわからない」など思っていることを率直に口にし、同僚からヒントをもらいつつなんとか実装をすることができました。 当たり前ですが、モブプロという場で半強制的に手を動かしてコードを書いたことは学習したことを身につけるのにとても効果的だったと感じています。また同僚のサポートがありつつも、自分が書いたコードがプロダクトに反映されることは大きな自信に繋がる良い体験でした。 しかしながらチームに入ったばかりで自分のようにストレートな発言ができる人ばかりではないと思っており、初心者でもよりスムーズに知識を身につけていける方法を模索中です。 知識を深めて広げる ReactとTypeScriptについて学んだりペアプロ・モブプロによって最低限コードを書けるようになったため、次のステップとして特定の分野の知識を深めていくことでレベルアップをしようと考えました。いわゆるT字型と言われるような知識獲得を目指し、深く掘りつつ広げていく狙いです。 テストから知識を深める Androidアプリ開発ではテストまわりの実装を整えることが多かったため、フロントエンド開発でもテストを起点にして知識を深めていくことにしました。 まずはテストのフレームワークの使い方を覚えるために、公式のドキュメントを積極的に読みました。その中でも使えると思った知識は積極的にチームのコーディングガイドラインに反映してコードを修正しています。 「テストについてわからないことがあったらsetohに聞けば大丈夫だな」とチームメンバーに思ってもらえることを目標に、今後も知識を深めていきたいと思います。 テストから知識を広げる テストフレームワークの動作や仕組みが気になった部分については内部実装を読むようにしています。フレームワークのAPIを深掘りしていくと背景には多くのAPIが使われており、それぞれについて調べるだけでもかなりの学習になっています。実践的なTypeScriptらしい書き方なども感じることができました。 テストについて学習する際に、自分が学習する必要のある分野を把握することも心がけています。 例えば、React Testing Libraryの QueryのPriorityについてのドキュメント を読んだことにより、アクセシビリティを意識したコンポーネントの構造を考えるようになりました。AndroidではMaterial Designに沿っていればある程度のアクセシビリティが確保できていたため意識が薄くなりがちでしたが、WebアプリケーションではDOMの構造などの観点も考える必要があり、この点についても学習の必要があると認識できました。 最後に 業務内容を変える際には学ぶことが非常に多く、この記事ではほんの一部しか書くことができていません。他に観点はあると思いますし、もっと効果的な学習方法もあると思います。 この記事が起点になり、フロントエンドエンジニアの学習に効果的な情報が多く発信されると嬉しく思います。 *1 : 『りあクト！ TypeScriptで始めるつらくないReact開発 第4版【① 言語・環境編】』 ほか。

2023年1月にエス・エム・エスに入社した荒巻です。現在、介護事業者向け経営支援サービス「カイポケ」のフロントエンドのエンジニアリングマネージャーを担っています。これまでは組み込み開発やモバイルアプリなど、興味のままに関わってきました。自分のキャリア観は5年ごとくらいで徐々に変化しているように感じており、転職にあたり、その変遷と、なぜエス・エム・エスなのか、ということについて書いてみたいと思います。 サービス志向に至るまで キャリアの初期には、とにかく技術的なことに興味がありました。学生時代は日本の製造業の絶頂期で、NHKスペシャルの「電子立国 日本の自叙伝」に感化され、「世界中で使われるデバイスを作ることこそが世の中の役に立つことである」という認識を持っていました。とはいえハードウェアは専攻していなかったため、組み込み業界でファームウェアを書くところからキャリアをスタートしました。製造業ではハードウェアがソフトウェア開発を主導しており、モノを作っている感覚がありました。無線のプロトコルやCPUの開発などに携わることができ、技術的な好奇心はある程度満たされました。 そうこうしているうちに、世の中では「Software is eating the world」に象徴されるように、ソフトウェアやサービスからハードウェアが生み出される流れになってきていました。そこで、自分の目標を「自分でも使いたくなるようなサービス開発に携わりたい」にアップデートしました。使いたい技術を使うよりも顧客やユーザーの問題を解決するほうが重要であるという意識が強まってきたこともあり、webやスマートフォンアプリの開発にスイッチしました。 グローバル企業で感じた壁 いくつかのアプリ開発を経験後、スマートニュース株式会社に入社しました。いくつかの施策が成功して会社が急成長し、グローバル企業となりました。優秀な英語話者が大量に入社してきて、いわゆるベイエリアのスタイルが導入され、王道のプロダクト開発を行えている実感がありました。エンジニアリングマネージャーも経験することができ、多くのことを学ぶことができたと同時に、いくつかの壁を感じることにもなりました。 一番大きなギャップは英語力です。それなりに英語力がついたものの、日本語力とは大きな隔たりがありました。自分はボトムアップで考えがちですが、英語だと語彙力が足りないので、まず日本語であれこれ考えてから抽象化し、英語に変換してからGrammarlyで修正するような毎日を送っていました。会社にさらなる貢献をしたいとは思っていたものの、チーム内の責務からはみだしたことに挑戦するには英語力が不足していました。 また、それまで大きな組織でのプロダクト開発の経験がなかったこともあり、プロダクト開発のベストプラクティスや組織づくりに関する知見がまだまだ足りない状態でした。そのため、英語とプロダクト開発の二重のギャップがあるように感じてきていました。 スマホアプリからSaaSへ グローバルエンジニアになりきれてはいないものの、グローバルエンジニアになることが目的化しつつあるように感じていました。それよりも足場を固め、プロダクト開発に貢献することを考え始めました。 社内では数多くのSaaSを利用しており、BtoCのスマホアプリから見て、SaaSのビジネスモデルは魅力的に映りました。BtoCのサービスはユーザーベースは大きいものの、「ユーザーはユーザーのことを知らない」と言われたりします。せっかく開発した新しい機能も、A/Bテストを実施した結果、ユーザーの興味を惹くことができなければ正式リリースしない、というようなこともよくあります。一方BtoBのSaaSでは、日々のビジネスオペレーションの一翼を担っており、ユーザーが切実に必要とする機能を開発していけるのではという期待を持ちました。そのようなタイミングでエス・エム・エスから声をかけてもらい、転職を決めました。 エス・エム・エスに入社してみて 現在、介護事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトに従事しています。(詳しくは、 カイポケリニューアル のタグのついた記事をぜひ読んでいただければと思います) 3ヶ月やってみての感想ですが、よいプロダクトを届けるため、必要なことをチーム全体で実直に取り組んでいると感じています。一つ一つは地道な作業で、プロダクトオーナーとドメインエキスパートがユーザーからヒアリングしてストーリーマップを作り、デザイナーとソフトウェアエンジニアが議論して機能やUIに落とし込んでいきます。開発プロセスとしてはスクラム開発で不確実性を徐々に減らしながら、着実に成果を積み重ねていっています。これだけだと簡単そうに聞こえますが、品質を犠牲にせずに、必要な機能を洗練されたUIで、ある程度のスピード感を持って開発を進めています。もちろん方向転換や手戻りなども多少ありますが、そこを含めて総合的には絶妙のバランス感を持って前進できているかなと思います。 特徴的なこととしては、積極的にユーザーとコミュニケーションを取っており、介護事業所に訪問してヒアリングやインタビューできる機会が定期的に用意されています。私も参加してみたところ、ちょうど開発している機能に相当する業務を現行バージョンのカイポケで行っていました。実際の操作を見せていただき、使いづらい点をその場で質問できたことで、ユーザーの課題感を肌で感じることができ、対象業務の理解も深まりました。正式リリースはもう少し先ですが、良い体験がユーザーに届けられそうな予感がしています。 技術スタックとしても、backendでSpring for GraphQL、frontendはReact + Storybookといった、新しめの要素技術を利用して、長期的に高い生産性を保てるようにチャレンジしているところです。このように充実した環境ですが、日々、開発対象業務が拡大していっており、まだまだ新しい仲間を必要としております。ご興味があればぜひ、下のリンクからカジュアル面談を検討していただければ幸いです。

エス・エム・エスでEM兼採用担当をしている emfurupon777 です。 2022年1月に入社して1年が経過し、採用を軸にして職務にあたる時間もかなり多くなっていますが、私よりエス・エム・エス歴の長い仲間たちに加え、多くの新しい仲間のJOINにより、楽しみな2年目を過ごしています。 今回は、一人のEMとして、”リーダーシップ”についての見解を書いてみたいと思います。 会社のテックブログの場を借りていますが、私個人の主観も大きく影響しており、必ずしもエス・エム・エスで語られることと表現や詳細が一致しているとは限らないのでご容赦ください。 我々が相対しているもの VUCA(Volatility（変動性）・Uncertainty（不確実性）・Complexity（複雑性）・Ambiguity（曖昧性）)なんて言葉を使うような世の中ですが、我々が日々挑んでいるプロダクト開発は、そもそも不確実性が高いことを前提にしておく必要があります。相対する課題も、技術的課題・適応課題どちらも山積ですよ・・・というのがほとんどの会社で感じられているのが正直なところではないでしょうか。 そんな中、さまざまなバックグラウンドを持った仲間と仕事を進めるにあたって、EMとしてはよく意識して行動しているものの、意外とリーダーシップについて話すことってないなー、と感じている今日この頃で、今回筆を取りました。 リーダーシップとはなんなのか？ 私は、リーダーシップを WHY:　設定された成果のために WHEN:　決定に十分な情報が完全には揃っていないとき HOW:　高い視座・複眼で考え、できる前提の短いポジティブな表現を使って(Can do attitude) WHERE:　周囲を巻き込んだ場所で WHAT:　設定した良いイシューを WHO:　解決しようという意志を持っている人が 行動すること、と定義しています。 これだけでは伝わらない面が大きいかと思いますので、それぞれについてもう少し言及してみようと思います。 WHY: なぜリーダーシップを発揮する必要があるのか 組織が存在するからには何かしらの成果期待があり、経営者・従業員である以上、我々は所属している組織の成果を最大化する責務があるからです。 より高い成果を目的とするからこそリーダーシップは必要となってくるものと考えます。 逆に言えば、成果に繋げようという行動でなければ単なる干渉・おせっかいになっている可能性が高く、実際後で振り返ると自分の理解が足りていなかった、感情的な対立があった、などの背景があり、その回避行動のあらわれだった・・というケースがままあります。 WHEN: いつリーダーシップを発揮するのか 不確実性が高い時、まだ重要な「根拠となるファクトが揃っていない時」にこそリーダーシップは必要です。条件が出揃っていて、みんなが同じ結論を導けるならばそれは単なる”判断”で、意思決定ではありません。 不確実性が高い中で行うからこそ価値があるのが意思決定で、その意思決定に達するために必要なのがリーダーシップです。 多くのケースで意思決定の後に新たなファクトが出てきているため、後になって振り返りをしてみれば、「より良い決定ができたのではないか・・・？」と言う思いが湧いてくるのは多くの方が経験したことがあるのではないでしょうか。この思いを抱けるのであればなんらかの意思決定をしていたと言えると思います。 HOW: どのように発揮するのか リーダシップの発揮時には自分が普段見ているところよりも、1段・2段高い視座に立ち、取りうる手段を考えることが重要です。 例えば、部・課・チームのような組織階層があるとき、チームの課題を解決するためには課長・部長と目線を上げていくことによって、ヒト/モノ/カネなど扱えるリソースが大きくなることによって強制的に思考のリフレーミングを起こせるなどの効果があります。 (これは一例なので、必ずしも組織構造ではなく、ロールなどで考えてももちろん良いと思います) また、視座を高くするだけでなく複眼(複数の視点)で観察することも重要です。1視点では対象を立体で把握することができません。 複数の視点から観察することで対象を立体的にとらえることができ、より的確にファクトを捉えることができるはずです。 そして、最後の「Can do attitude」は私が以前一緒に仕事をしていた尊敬するCTOに重ねて伝えられた言葉で、これはリーダーシップを発揮するときには非常に重要だと思っています。どんなに難しいイシューでもできる(Can do)ことを前提に議論をする、それでこそ実現にあたって超えるべきギャップを測ることができます。 (私は当時この振る舞いができておらず、「先にできない理由を並べてチャレンジしない状況では、成果はついてこないし、そもそも誰も相談に来なくなるでしょう？」と言われ、「確かに…」としか言えませんでした。。) WHERE: リーダーシップを発揮すべきなのはどこで？ リーダーシップは同じ成果を出すために同じ方向を向いて欲しい人たちがいる場で発揮すべきです。一人でやってみてうまくいってから皆に共有する・・・のは、やらないよりははるかに良いものの、もう一歩だと考えています。 リーダーシップは一人が発揮しているだけでは成果が大きくならず、継続性も生まれにくいと考えます。その影響する範囲は大小さまざまかもしれませんが、関係している人たちがそれぞれリーダシップを発揮した総量や、その重なりによってこそ期待通り、あるいは期待を超える成果に繋がっていくものだと思います。 WHAT: 何に対してリーダーシップを発揮すべきなのか 一言で言ってしまえば、「良いイシュー」で、詳細には参考図書にあげている『イシューから始めよ』に書いてある3点になります。 本質的な選択肢である 深い仮説がある 答えを出せる とは言え、いきなりこれを追い求めるのはハードルが高いですし、リーダーシップの発揮は習慣化していく必要がある性質のものでもあると思っています。そのため、ちょっとしたことで・・・例えば、やろうと思えば誰でも対応できるかもしれない、ちょっとした社内の困りごとについて自らリーダーシップを発揮して対応してみるのがおすすめです。 これは、優れたリーダーシップを発揮されている方のお話を伺っていると、自分に求められている役割がどのようなときでも、可能な範囲(もしくはそれをちょっと超えた範囲)でリーダーシップを発揮するという経験をごく小さなものから繰り返し積み上げていくことで、より広い範囲でリーダーシップを発揮できるようになっていることを観測しているためです。 WHO: リーダーシップを発揮すべきなのは誰なのか リーダーシップを発揮すべきなのはマネージャーですか？リーダーですか？ いえ、リーダーシップには権威・権限は不要で、誰でも発揮することができるはず・・・立場に関わらず意志を持って臨める人こそリーダーシップを発揮すべきです。 あなたの所属会社では、マネージャーとリーダーをポジション・ロールとして明確に定義しているでしょうか？両者を区別して扱っているでしょうか？ プロダクト開発にあたって、明確なポジション・ロールとして定義した場合は、プレイヤーとして組織の平均以上のスキル・能力も求められることが多いのではないでしょうか。そのため、組織の価値観に沿った形で、かなり広範囲にリーダーシップを発揮することが求められることになり、結果その任にあたれる人は絞られてくるかと思います。 また、暗黙のうちに広範囲で継続的なリーダーシップを求められることが多いと思います。 前述の定義によれば、「根拠となるファクトが揃っていない時」に求められるのですから心労も絶えません、、 ・・・大変ですね。 ですが、マネージャーやリーダーになったからリーダーシップを発揮しよう！と考えている方はほとんどいないと思います。むしろその逆で、なんらかのリーダーシップを発揮してきた結果、マネージャーやリーダーを担うようになったはずです。 会社組織として予算管理、労務管理、コンプライアンス遵守などの任を遂行せねばならず、組織として一定の規模が出てくるとマネージャーは必要です。 一方で、組織の規模にかからわず必要なのがリーダーシップで、これは組織がある以上目標としている成果があるはずで、その達成には不可欠だからです。 この不可欠なリーダーシップを発揮している人にリーダーというポジション・ロールをつけることがある、というのが私の認識です。 せっかく組織だって活動をしているのだから、明示的なポジション・ロールに興味があるかないかは別にして、成果を残していくためにリーダーシップを発揮するという意識を持った方達と働けたら面白いなと思います。 エス・エム・エスで求められるもの エス・エム・エスのプロダクト開発組織では「自治と信頼」を重要視しており、弊社内ドキュメントでは下記のように説明されています。 自治と信頼 ユーザー接点のチームが自立的に思考し意思決定していくために、上意下達で思考停止する組織でなく、自治と信頼をベースとした組織を目指していく。 あなたがコミュニティ 組織というコミュニティがなにかをしてくれるのではない。自治組織ではあなたがコミュニティ。あなたがコミュニティを代表する一人として考え行動することで自治組織になる。あなたが他人事だと思った瞬間から自治は崩れていく。機能性を担保するために役割 (ロール) を設定しプロトコルを決めることはあるかもしれない。でも、それがあなた自身のコミュニティへの責任を肩代わりするわけではない。役割によらずあなたも等しく責任を担っている。序列を強化することは権威勾配の高い関係性をつくり、コミュニティのパフォーマンスを悪化させる。序列はいらない。マーケットだけが王様だ。 参考 「コミュニティ」とは誰か 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 自治と信頼を継続していくためには、リーダーシップを発揮し続けられる仲間が欠かせません。 どういう状態を目指すのか・・と考えると、参考書籍にあげた「採用基準」という書籍のなかに出てくる「リーダーシップの総量」という表現が色々なことを内包していて非常に興味深いです。EMとして、ぜひ仲間を集め、リーダーシップの総量を上げて素晴らしい開発組織に成長させていきたいです。 最後に 取り止めのない話になってしまっている気もしますが、エス・エム・エスの「リーダーシップの総量」を上げて社会課題に挑んでみるのも面白いかも？と少しでも興味をもっていただける方はカジュアルなところからおはなしさせてください！We are Hiring！ 参考書籍 伊賀 泰代『採用基準』 安宅和人『イシューからはじめよ――知的生産の「シンプルな本質」』 ロナルド・A・ハイフェッツ, マーティ・リンスキー, アレクサンダー・グラショウ『最難関のリーダーシップ』

介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、酒井( @_atsushisakai )です。 前回は、 カイポケのフルリニューアルプロジェクト の紹介をさせてもらいましたが 、今回はローンチから17年も経過したカイポケのような大規模 SaaS プロダクトをフルリニューアルする、という大きなゴールを目指すプロジェクトに立ち向かうために、どのようなプロセスとマインドで開発を進めているのかをご紹介させていただきます。 フルリニューアルプロジェクトの特徴 まず前提として、このフルリニューアルプロジェクトは、いくつかの観点で、プロジェクトの進行難易度を高めるような特徴がいくつかあります。 作るべき「価値」が膨大に存在することが最初からわかっている このプロジェクトでは、すでに現在動いているカイポケの重要なお客様にとっての「価値」を大きく損なわないように開発を進めていかねばなりません。これは、機能的な互換性を保つ、ということではなく、あくまで「価値」にフォーカスした話です。そして、その価値はローンチから17年間も積み重ねてきた結果、非常に膨大な分量になっています。 ただし、すべてのお客様にご満足いただけるような機能一式をいきなりすべて作り上げてビッグバンリリースするわけにもいきません。フィードバックを得ながらも戦略的に小さく価値を積み上げ、結果的に現在動いているカイポケが提供している価値以上のものへと、プロダクトを超高速に育てていくことがどうすれば可能なのか、ということを常に模索していく必要があります。 関わるメンバーやチーム数が最初から多い 上記の通り、作るべき価値が膨大であることは最初からわかっているため、関わるメンバーもそれなりに大人数となっています。少数精鋭で密なコミュニケーションを取りながら、小さく小さく…、という作り方ではなく、ドメイン分析を行い、最初から複数のチームで責務分割しながらたくさんの価値を並行で生み出していけるような開発プロセスが必要です。 チームの構成や規模感はこちらでご紹介しています 。 介護保険制度や介護事業所の業務への深い理解が必要不可欠 例えば、 先日の宮坂さんの記事 で書かれているように複雑な介護保険制度への理解が必要不可欠であったり、法改正についての情報のキャッチアップも必要です。また、介護事業所における細かな業務を再度理解し直すことも重視しています。これらの複雑度の高い情報を扱いながら、抽象度高く戦略的・長期的にプロダクトがユーザーの課題を解決し続けていくことを狙えるプロセスを見つけていくことは非常に難易度が高いものです。 プロダクトマネジメント体制 さて、上記でご紹介したようにこのフルリニューアルプロジェクトは、意識せずにやっているとコミュニケーションコストが高く、解くべき課題が膨大かつ超高難度、という非常に難しい特徴があります。このような状況に対応するために、常に開発組織全体がさまざまな観点の解像度を高く維持することができるよう、プロダクトマネジメントに関わる各種ロールが設計されていますのでご紹介します。 プロダクトマネージャー プロダクトマネージャーは、新しいカイポケにおける複数のアプリケーションを束ねた SaaS 全体の視点から顧客価値をスケールさせ、事業価値へつなげていくためのビジョンや戦略の立案を行います。ユーザーストーリーマッピングを元に、プロダクト全体の長期ロードマップとスコープ管理を横断的に行っていきます。 プロダクトオーナー プロダクトオーナーは、カイポケ内にドメインごとに設計された複数のフロントエンドアプリケーションやバックエンドサービスのそれぞれについて、プロダクトビジョンを作り、プロダクトバックログアイテムの優先順位を管理していくことに責任を持ちます。プロダクトオーナーに紐づく形で開発者やQA、デザイナーなどのクロスファンクショナルなスクラムチームが組成されています。 ドメインエキスパート ドメインエキスパートは、プロダクト開発組織に対して、複雑な介護保険制度や介護事業所内の業務プロセスの専門知識を提供し、プロダクトの成長に貢献します。過去の経歴において、実際に介護事業所での勤務を経験しているため、開発する対象への深い理解と意味づけをしてくれる重要な存在です。 このような体制を敷くことで、プロジェクトの全体像を組織全体で捉えながら、スクラムチームで足元の仮説検証を繰り返し、ユーザーや業務・制度の理解を深めていくことで提供価値に向き合えるように体制設計されています。 プロダクトバックログアイテムができるまで それでは次に、各スクラムチームがプロダクトバックログアイテムの優先順位を確定し、チームのスプリントで着手可能なタスクにどのように分解されていくのかを解説します。 まずは、プロダクトマネージャーとプロダクトオーナーが協力して将来2〜3ヶ月分で創出したい価値を「エピック」と、それに紐づく「プロダクトバックログアイテム」という粒度でざっくりとリストアップします。エピックは、プロジェクト開始時に作成された巨大なユーザーストーリーマッピングが元になっています。 その後、ここで作成されたプロダクトバックログアイテムを各チームのエンジニアがレビューし、背景や要件を理解しながら、さらに細かなプロダクトバックログアイテムの分割を行っていきます。ある程度プロダクトバックログアイテムの粒度を整理し、チーム間の依存関係なども理解しあった段階で、開発の規模感を見積もるためにストーリーポイントを用いた「ざっくり見積もり」（組織内では本当にこう呼ばれています）を行います。その後、見積もりを材料に、スコープと優先順位を再度プロダクトマネージャー/プロダクトオーナー/エンジニアで話し合いながら、向こう2〜3ヶ月で取り組む開発内容を確定させていきます。 既にドキュメントやUIのドラフトとなる資料が Figma などにある場合は、その上にでコメントし合ったり、プロダクトオーナーとエンジニアやデザイナーが直接ディスカッションしたり、ドメインエキスパートにヒアリングして介護事業所で行われている業務を把握したりしながら、開発対象の理解を深めていきます。正直、果てしなく地道な作業でとても大変なのですが、ここでの対話はその後の開発対象への理解を深めるための非常に重要なプロセスとなっています。 フロントエンドチームでのスクラム さて、ここからは私が所属しているフロントエンドチームのスクラム開発の様子を解説します。まず、すでに作成されたプロダクトバックログアイテムに情報を加えながら、 チームで管理している JIRA プロジェクトに全てのプロダクトバックログアイテムを改めて登録していきます。ある程度事前に見積もりもされているので、それをそのままストーリーポイントとして入力していきます。 プロダクトバックログアイテムは、最終的に以下のようなフォーマットに整理して登録を行っていきます。 このフォーマットは、非常にシンプルに記載できますし、主にユーザーに提供する価値にフォーカスしているため、個人的に非常に気に入っています。例えば、How をプロダクトバックログアイテムに記載しすぎると、見積もりの正確性を求めすぎてしまったり、相対的に Why への意識が目減りしてしまったりするので、このぐらいの内容でざっくり書いておくと開発チームが自律的に思考できるようになる、という良い影響を感じた経験があります。 バックログが完成すると、バックログリファインメントで着手していくための戦略をリードエンジニアが中心となって立てていきます。リードエンジニアは事前に関連するバックエンドエンジニアとのコミュニケーションを取っており、その情報と合わせて最短経路で上位のプロダクトバックログアイテムやエピックを実現するための手順を考えながら、スプリントにおける優先順位の調整や必要であればさらにプロダクトバックログアイテムの分割、再見積もりなどをリードしていきます。そして、毎週の「バックログリファインメント」の時間では、精度が上がり、開発対象への理解が深まったプロダクトバックログアイテムがスクラムチーム内で再度共有されることになります。スプリントが終了する頃には、次のスプリントで着手するスプリントバックログが完成されており、スプリントプランニングでは、計測されたベロシティをもとに、見積もり済みのプロダクトバックログアイテムを使ってコミットラインを決めていきます。 最終的に、このスプリントで達成したいとチームで決めたことを1文で表したスプリントゴールを決めることにしています。スプリントゴールを決める目的は、チーム内で以下のように定義しています。 チームとして期間中に達成したいことを一言で表現することで認識を揃える このゴールを達成するために障害となることを積極的に取り除いていくように意識を働かせる スプリントの途中でも、時々ゴールを見直して、本当にゴールに向かえているかをデイリースタンドアップミーティングの中で確認しあって、集中できているかを確認したりします。 そのほか、スプリントレビューやレトロスペクティブ、スプリントプランニングなど、各種イベントをスクラムガイドの通りにしっかりと行っています。経験を大事にして、チームが成長する過程で出てきた、チームに最適化されたローカルルールもいくつかで始めており、イテレーションの回数が増えて行くほど効率化したり、チャレンジしたりできているのも実感しています。 まとめ ここまで述べてきたように、私たちは、カイポケという非常に大きな SaaS プロダクトをフルリニューアルするという非常にチャレンジングな開発に取り組んでいます。この記事では、難易度の高いプロダクトをどのようにマネジメントし、日々の仕事に落とし込んでいるかというプロセスを紹介してきました。この記事を書いてみて感じたのですが、我々が今取り組んでいることは、複雑さや難易度の高さを正面から受けとめ、現実的な落とし所を見つけていく作業の繰り返しというのが正直なところです。驚くような効率的なプロセスではないですが、地道に向き合いながら、スクラムのプラクティスを取り入れて実直に経験を積み重ねるように開発を進めています。フルリニューアルプロジェクトは、まだまだ不確実性が高い状態なので安定した開発プロセス、というのとはほど遠いものですがチャレンジングであるがゆえの面白さも日々感じています。 経験主義で技術もチームワークも学習することを大事にしながらプロダクトと共にチーム全体が成長している実感を味わえる非常にスリリングでわくわくするプロジェクトだと思います。興味のある人はぜひより詳しい話を聴きにきませんか？

こんにちは、介護事業者向け経営支援サービス「カイポケ」のエンジニアの加藤です。 カイポケが提供するサービスの一つ、障害者支援を行う事業所向けサービスの開発をしています。 現在、私たちのチームは一部機能のリプレースを行っています。本稿ではリプレースに至った経緯についてお話ししたいと思います。 ※「しょうがい」には「障害」「障がい」「障碍」といった複数の表記があります。それぞれに意味があり、何が適切かは様々な見解がありますが、本記事では 法令表記 もある「障害」で統一しています。 ※ 本稿では、伝わり易くすることを優先した表現を使っています。本稿の表現に正確性が欠けるものがある点を、あらかじめご了承ください。 我々のミッション 私たちチームのミッションは一言で表すと、 ユーザーの業務効率化と経営状態健全化に貢献すること です（カイポケのミッションの詳細は こちら をご参照ください）。このミッションの実現のために、私たちが考えていること・行っていることをお話しします。 私たちチームの担当プロダクトのユーザーは、障害者支援（障害児含む）を行っている障害者支援事業所の経営者・職員の方々です。 ユーザーは日々、障害を持つ方々の介護・自立支援を主体業務としつつも、事業所経営に必要な多くの付帯業務をこなしています。そこでカイポケを利用することで、付帯業務の効率を上げて、主体業務に集中しやすい状況を作っていただきたいと考えています。 複雑なドメインを持つユーザーの付帯業務 付帯業務と一言で表してはいても実際は複数の業務があります。その中でも、効率アップを実現したい業務の一つに請求業務が挙げられます。なぜなら障害者支援事業者が行う請求は、一般的なサービスの請求より複雑なためです。 一般的なサービスでは「サービス提供者が、サービス内容と料金を考え、サービス利用者にサービスを提供して、料金をサービス利用者へ請求する」という流れが多いと思います。 これが障害者支援では、「国や自治体がサービス内容と料金を法令に基づいて制度化する。その制度に沿ってサービス提供者（事業者）がサービス利用者（障害者）にサービスを提供して、料金の一部をサービス利用者に請求し、残りは自治体に請求する」といった流れです。（この流れは医療の保険制度と似ています。） 一見すると、本来サービス提供者が考えるべきサービス内容と料金が制度化されているなら、その分楽に見えるかもしれません。しかし、もちろんそう簡単な話ではありません。 国や自治体が制度化した内容は、理解しやすい内容ではなく、とても複雑です。複雑である理由はいくつかありますが、ここでは３つに絞って説明します。 １つ目は、サービス内容のパターンが多く料金設定も細かいこと。 ２つ目は、請求業務に登場するアクターが多いこと。 ３つ目は、制度自体が改定され続けていること。 まず１つ目、サービス内容のパターンが多く料金設定も細かいこと。 一言で障害者といっても、どこに障害をお持ちなのか、どの程度のものなのかが人によって異なります。そのため、障害者に必要なサポートの形も様々で、それに即した多様なサービス内容が必要です。 多様なサービスがあるのだから当然料金設定も細かくなりますし、同じサービス内容でも時間単位の段階性料金が設定されていたりと、とても細かい料金パターンとなっています。 次に２つ目、請求業務に登場するアクターが多いこと。 一般的なサービスの請求業務のアクターは、サービス提供者とサービス利用者の２アクターだと思います。一方、障害者支援はここに国・自治体というアクターが追加されます。ここでは詳しく話しませんが、さらに他事業所というアクターが追加される場合もあります。 業務におけるアクターが増えれば増えるほどフローも複雑になるので、それを制度化したものも伴って複雑化します。 最後に３つ目、制度自体が改定され続けていること。 この制度は不変ではなく改定され続けています。大小様々な改定が数ヶ月から数年毎に入ります。人々の生活は社会情勢や技術の進歩によって日々変化しています。その変化に対応するため、障害者支援の制度も変えていく必要があるということです。 制度に沿って請求する以上、改定される制度の情報をキャッチアップし続ける必要があります。 ドメインの複雑度をカイポケが引き受けたい これらの理由で複雑化した制度を理解した上で請求をすることは大変そう、ということはご想像いただけるかと思います。障害者支援を行う方々は、複雑な制度の上に成り立つ請求業務を介護・自立支援といった主体業務と並行して行う必要があるのです。 そこで私たちは、複雑な制度を読み解き、制度の変更に追随しながら、使いやすいプロダクト（カイポケ）にしてユーザーへ提供する。つまり付帯業務の持つ複雑度をカイポケが引き受けて吸収する。そうそうすることで障害者支援事業所の業務効率アップに貢献できると考えています。 ここまでミッションと実現したいことについてお話ししてきました。これらのために日々頑張ってはいるのですが、もちろん全てがうまくいっているわけではありません。課題も多くあります。 複雑な制度 × 期限必達 = 複雑化した仕様と肥大化したコードベース カイポケの障害者支援領域は複数プロダクトがありますが、最も長いプロダクトはサービスインから8年経過しています。その間、サービスを運用していく中で、大きな制度改定への対応も数回乗り越えてきました。 改定後の新しい制度に関する情報は厚生労働省から公開されるものをソースとしています。新しい制度の情報は少しずつドラフトの状態で公開されるのですが、確定情報が出てから制度施行日まで余裕がないこともあります。過去に私が経験した制度改定への対応では、制度施行日の数日前まで確定情報が公開されないということもありました。 そういった背景もあり、ときには開発に十分な時間が確保できず、急いでリリースまで行う必要があることがあります。「新しい制度への対応版のリリースが遅れる＝ユーザーの業務が止まってしまう」ということを意味するからです。 理想を言えば、「適切な時間を使って、要件を検討し、既存の要件と新しい要件を最適化しながら仕様に落とし込み、その仕様に沿って実装し、リファクタリングを行い、必要なテストをクリアしてから、リリースする」というプロセスを踏みたいところです。しかし、デットラインまであと数日という状況ではそうも言ってられません。 ではどこを削るか？ですが、過去の私たちは、”既存の要件と新しい要件を最適化しながら仕様に落とし込む” と ”リファクタリングを行う” に対し、”適切な時間を掛けること” を削るという選択をしました。全ての変更において一貫してこの選択をしたわけではないですが、いくつかの変更において選択してきたことは事実です。 新しい要件は、既存の仕様に簡単に上乗せできるものばかりではありません。ときには既存の仕様を見直した上で新しい仕様を取り込むべきものもあります。 しかしながら、新しい制度の施行日という期限がある以上、変更箇所を少なくするために既存に手を入れずに新しい要件を加えるということもありました。そういった対応は少なからず歪さや冗長な面を残すことになります。 このような歪さや冗長な面は、その瞬間においては許容できるレベルであったとしても、年月を経るごとに当時の記憶も薄まり、忘れたころに複雑で理解し難い仕様として開発者を苦しめることになります。 ミッションの説明でお伝えしたように、障害者支援における請求のドメインはとても複雑です。ドメインが複雑な上に輪を掛けて仕様も複雑になってしまっています。つまり結果だけ見れば、過去の私たちの選択は「仕様の複雑度 ＞ ドメインの複雑度」という状態を招いてしまいました。 また、仕様の複雑度が高いということは、コードベースの複雑度も増します。複雑度が増せば自然とコード量も増え肥大化していきます。複雑度が高く肥大化したコードベースのメンテナンス性は言わずもがな悪いものです。 これまでも私たちは、コードベースに一定の秩序を取り戻そうと、制度改定の合間などの時間的制約が少ないときにリファクタリングを行ってきました。ただリファクタリングも肥大化したコードベース相手では膨大な時間を要するため、まだまだ道半ばです。 仮にこの先、多くのリソースを投入してリファクタリングを完遂したとしても、複雑な仕様は残ります。それでは一時的な効果はありますが、根本的な解決とはなりません。 時を経るごとに複雑になっていく仕様、複雑度を増す仕様に引きずられて肥大化していくコードベース、そんな状況を改善しようと行うリファクタリング。自分たちで穴を掘って、後で穴を埋める、そしてまた穴を掘る、という消耗戦を続けてきました。 この消耗戦を終わらせなければ、いつか私たちの手に負えない状況になってしまうでしょう。そうなる前に「複雑化した仕様」と「肥大化したコードベース」をなんとかしなければなりません。 ユーザーへの価値提供を増やしたい 話は変わりますが、数年前からカイポケは内製化を進めてきました。（内製化の話は「 【前編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか 」をご参照ください） 私を含めカイポケのエンジニアの多くは、内製化へ舵切りしてからJOINしています。それから、制度改定や機能追加、リファクタリング、不具合への対応などを通して、ドメインとプロダクトに関する知識を蓄積してきました。 そうなると見えてくるものがあります。「ココがこうだったら便利そう」とか「ユーザー業務を考えると今と違うアプローチの方が使い易くなるだろう」といった、ユーザーに今より多くの価値を提供できそう！というアイデアです。 ではそのアイデアを実装してみよう！となるのですが、アイデアはあくまで仮説です。事前にいくら検証したところで効果が100％保証されるものではありません。そのため、仮説→検証→実装→リリース→効果測定→仮説→（以下略）というループを高速に回していきたいのですが、そこで壁となるのが複雑化した仕様と肥大化したコードベースです。 複雑化した仕様と肥大化したコードベースに変更を入れることは容易ではなく、設計・実装・テストに多くの時間を要します。アイデアを実現しようとするたびに、たくさんの時間が掛かってしまうのであれば、実現するアイデアはより効果が期待できるものに限定する必要があります。ユーザーに提供できる価値のありそうなアイデアはたくさんあるのに、それらを実現するための時間が足りなくて、仮説のまま終わってしまうアイデアが多い。これはとても勿体ない話です。 リプレースへ ここまで私たちが抱える課題についてお話ししてきましたが、ここからは課題解決に向けて私たちが決断したリプレースについてお話しします。 上述の課題は以前より認識はしていました。ただ、制度改定であったり、リソースが足りなかったりと、なかなか根本的な解決に踏み切ることができない状況でした。そんな状況がしばらく続きましたが、ついに根本的な対応ができそうなタイミングが巡ってきました。それが今です。 次回の大きな制度改定まで期間があり（次回予定は2024年4月）、内製化以降エンジニアも増えてドメインやプロダクトに関する知識も蓄積できてきた、という２つの要因が揃った今だと判断して、根本的な解決としてリプレースを行うことにしました。 まず、リプレースのスコープは、広げ過ぎると時間も掛かりリスクも大きいため、現実的かつ効果的なスコープとして、一つの領域における請求機能（※）に絞りました。 ※私たちチームが担当している領域は障害者と障害児の２種類あり、今回は障害児の請求機能がスコープ。 次に、どのように進めるかですが、リプレースで行うことは大きく３つです。 既存の仕様を参考にしつつも、複雑さを排除した新たなドメインモデルを設計・構築する。 言語の表現力も借りて、基本に沿って秩序あるコードベースを再構築する。 ドメインモデルとコードベースに対し、変更容易性を維持する仕組み作りや取り組みをする。 １つ目は複雑化した仕様に対する対処で「仕様の複雑度 ≦ ドメインの複雑度」を実現すべく新しいドメインモデルを再構築します。 ２つ目は肥大化したコードベースへの対処で、モダンな言語仕様の力も借りて、適切なコード量でメンテナブルなコードベースを手に入れるために、基本を守って実装します。 １つ目と２つ目を達成できれば、開発スピードが上がることが期待できますが、ここで終わってしまっては一時凌ぎにしかなりません。そこで大事なのが３つ目です。 ３つ目は、今後も続く制度改定や新しい価値を提供するための機能追加を行うときに、過去の私たちと同じ選択（既存変更を抑えて単に上乗せする選択）をしなくて済むように短時間で開発できる状態を維持するための仕組み作りや取り組みです。 しかしながら画期的なソリューションを発見したわけではありません。変更容易性を維持するために、やるべきことをしっかりやる、というだけです。 具体例を挙げると、 ドメインモデルは、制度改定や機能追加によって変更される可能性を考慮し、それぞれの境界と接続ポイントを可視化（ココを変えるとコッチに影響するよね、というのがわかり易くなっている状態）しておくこと。そして仕様を変更する際は必ずドメインモデルの最適化を行うこと。 SOLID原則などの原則論に沿って実装すること。 テストコードをちゃんと書くこと。 PRレビューによって複数人の目を通すこと。 などです。（当たり前のことではありますが大事なので例に挙げました） これらは行動規範や規約として設けることは大事ですが、それだけでは人に依存してしまいます。新たなメンバーを迎え入れたときにスムーズにキャッチアップできるよう、可能なものはCIや静的解析などの機械的な仕組みで担保するようにしています。 2023年4月現在、請求機能リプレースはまだ完了しておらず鋭意開発中です。そのため今回のリプレースの決断と取り組み内容の良し悪しは、まだ評価できません。もちろん現時点では良い決断・良い取り組みだと信じているわけですが、最終的な評価はまだ先になります。 リプレース後に、ユーザーから使いやすくなった等の嬉しい声をいただく、カイポケの利用者が増加するといった目に見える成果がでる、または数年後の私たちが「リプレースしたお陰で開発しやすい」と感じることができたら良い決断だったと言えるでしょう。 最後に 今回お話しした請求機能のリプレースの成功は、私たちのゴールではなく一つの中継地点でしかありません。 解決したい課題や実現したいアイデアはまだまだあります。今後も新しいアイデアは出てくると思います。その時に一緒に考えて課題を解決するための仲間はまだまだ足りていないです。 今回はあまり技術的な内容に触れませんでしたが、今回のリプレースは以下の技術要素で開発中です。 Kotlin x Spring Boot TypeScript x Vue3 AWS Fargate Aurora Serverless v2（PostgreSQL） これらの要素にご興味があり、「ユーザーに多くの価値を提供したい！」と考える人がいらっしゃいましたら、ぜひ一緒に働きたいと思っております。 We are hiring! Join our team!!

はじめに 医療・介護・ヘルスケア・シニアライフの4つの事業領域で高齢社会の情報インフラを構築している、株式会社エス・エム・エスのAnalytics&Innovation推進部（以下、A&I推進部）の新卒3年目の小貝です。現在は主に介護職向け求人情報サービスである「カイゴジョブ」のデータ分析・アルゴリズム開発を担当しています。 A&I推進部はエス・エム・エス社内のデータを横断的に収集し、データの分析や加工から、データに基づく施策展開までを行う部門です。部門の役割としては以下の3つが挙げられます。 事業課題解決：事業会社のデータ活用組織として、PL貢献をする 技術開発：データ活用組織としての専門性をもつ 事業開発：専門性をお金に換える そのなかで最も優先度が高いのは1つ目の事業課題解決なのですが、組織としての専門性を維持するために技術開発や事業開発にも取り組んでいます。 今回は私が技術開発の一環で行っていた、介護事業者向け経営支援サービスである「カイポケ」のデータを使った「数理最適化による訪問介護のシフトスケジューリングモデル開発」について紹介します。 数理最適化とは 数理最適化とは、「ある条件を満たしつつ、利益やコストなどの関数が最大or最小になる変数の値を求める手法」です。扱える問題の例として、 300円以内で最も効用が高いおやつの組み合わせを求める（ナップザック問題） 商品の配送先がいくつかあったとき、移動距離が最も短くなるような巡回の仕方を求める（巡回セールスマン問題） ある駅からある駅への最安経路を求める（最短路問題） などが挙げられます。身近なところだと、乗り換えや経路検索のアプリは内部で数理最適化アルゴリズムが動いています。 最近では、「機械学習によって予測した応募率をもとに、数理最適化によって期待応募数が最大になるように求人をレコメンドする」「機械学習によって商品の需要を予測し、数理最適化によって最も経済的な在庫数を決める」といったように、機械学習との相性が良いこともあり、企業での活用が進みつつある技術です。 医療・介護業界における「勤務シフト作成」の難しさ 数理最適化という分野の中で有名な問題の1つに「ナース・スケジューリング問題」があります。名前の通り、病院などで働く看護師の勤務シフトを作成する問題です。「そんなの簡単じゃないの？」と思う人もいるかもしれませんが、看護師のシフトには以下のように考慮しなければならないことがたくさんあります。 各時間帯に◯人以上配備する必要があり、そのうち△人はベテラン看護師でなければならない AさんはBさんのメンターなので同じ時間帯に入れる必要がある 1人の看護師が2連続で夜勤をするのはNG AさんとCさんは不仲なので同じ時間帯に入れてはいけない すべての看護師さんで希望休の反映度合いを同じくらいにする必要がある（公平性） … これらすべての条件を満たしたシフトを、人間が作るのはかなり大変だと思われます。 実際、この問題の研究者が病院に行ったアンケートでは「勤務シフト作成にかかる時間は最大で30時間」「多くの人は勤務時間内ではなくプライベートの時間で作成している」「やりたくないと答えた人が90%」といった結果も出ています。 https://orsj.org/wp-content/or-archives50/pdf/bul/Vol.41_08_436.pdf ここまで複雑なのは看護師特有かもしれませんが、介護業界における介護ヘルパーでも同様に、勤務シフト作成の業務は発生しています。特に、ヘルパーが利用者の自宅を訪問する訪問介護では、介護士の勤務可能日時だけでなく、地理的な要素も考慮する必要がある（あまりにも遠くて非効率的な移動はさせたくない、など）ため、人間が手でシフトを作るのはなかなか大変だと思われます。 そこで今回は、数理最適化によって「訪問介護のシフトスケジューリング問題」を解いてみました（A&I推進部内に訪問介護のカイポケデータにとても詳しい人がいた、ということも訪問介護を扱うことにした大きな理由です）。 問題の整理・定式化 問題を解くために、「どういうデータが使えるのか」「どういう問題を解きたいのか」の整理をします。 カイポケには介護事業者の経営を支援する機能がいくつもありますが、その中に 利用者のサービス提供予定を登録する ヘルパーの勤務可能日時を登録する という機能があります。今回はその2つを使って、利用者のサービス提供予定が与えられたとき、ヘルパーの勤務可能日時を守りながら自動で各サービスにヘルパーを割り当てる数理最適化モデルを作ってみました。また、カイポケ内には「実際にどのような割当がされていたか」というデータもあるので、モデルによる出力と比較もしてみます。 データとモデルによる出力の比較 先ほども書いたように、数理最適化は「ある条件を満たしつつ、利益やコストなどの関数が最大or最小になる変数の値を求める手法」なので、 どういう条件で（＝制約条件） 何を最大化 or 最小化するか（＝目的関数） の2つを決める必要があります。思考の過程は省略しますが、今回は以下のような問題を解くことにします。 制約条件 可能な限りすべてのサービスにヘルパーを割り当てる 各ヘルパーの月間勤務時間の合計を一定の範囲内で収める（働かせすぎず、休ませすぎない） これに関するデータはないので「各ヘルパーは1日8時間まで勤務できる」としました 1人のヘルパーが同時にできないサービスには同時に割り当てない ヘルパーを分身・瞬間移動させない 遠すぎる移動もさせたくないので、移動距離が一定以上になるサービス（利用者宅）のペアも同時割当NGにしました 目的関数 未割当のサービスができたり、ヘルパーの勤務時間の合計が過不足した場合にペナルティを与え、それを最小化する 問題を数式に落とし込むことを分野特有(？)の言葉で「定式化」というのですが、今回の問題を定式化すると以下のようになります。なお、定式化にはこちらの書籍を参考 *1 にしました。 https://www.kindaikagaku.co.jp/book_list/detail/9784764905580/ www.kindaikagaku.co.jp データ 決定変数 minimize, subject to ※補足 データ：問題を解く前にわかっている入力データ 決定変数：問題を解かないとわからない（求めたい）変数 「minimize ～～～」：～～～（目的関数）を最小化する 「subject to ～～～」：～～～を制約条件とする Pythonによる数値実験 さて、問題の定式化ができたので、実際のカイポケデータを使って解いてみます。 数理最適化問題の解き方には大きく分けて「解を求めるアルゴリズムを自分で書く」「数理最適化ソルバーで解く」という2種類があります。とてもざっくり言うと、前者は解の探索手法や効率的な計算方法など競技プログラミング的なスキルが強く求められ、後者はソルバーで解ける形に数式を落とし込むという学術的な知識やスキルが求められるといった違いがあります。今回は個人的になじみのある、後者のソルバーを使ったやり方で解いてみます。 数理最適化ソルバーには有償・無償のものを含めいくつか種類があり、当然有償のほうが高性能ですが、今回はそこまで問題の規模が大きくないので、無償かつ商用フリーのCBCというソルバーを使います。また、ソルバーに問題を入力するラッパー（モデリング言語）としてPython-MIPを使います。先ほど定式化したものをPythonで実装すると以下のようになります。 https://github.com/coin-or/Cbc https://www.python-mip.com def model (): ''' ヘルパーごとの勤務時間量の上下限をなるべく守って各サービスに担当可能なヘルパーを割り当てる ヘルパーごとの移動範囲をコンパクトにするために、移動距離が大きい利用者のペアは1人のヘルパーに同時に割り当てない ''' model = Model( "model" ) model.emphasis = 1 # 最適性よりも実行可能であることを優先する model.verbose = 1 # ログを表示する model.preprocess = 1 # 定式化を解きやすくする # 変数の定義 x, alpha, beta_m, beta_p = {}, {}, {}, {} for h in target_helper_id_list: # ヘルパーごとの勤務時間量の上下限を下回る/上回る量 beta_m[h] = model.add_var(lb= 0 , name=f "beta_m_{h}" ) beta_p[h] = model.add_var(lb= 0 , name=f "beta_p_{h}" ) for s in target_shift_id_list: # ヘルパーhにシフトsを割り当てるとき1、それ以外は0になる変数 x[h, s] = model.add_var(var_type=BINARY, name=f "x_{h}_{s}" ) for s in target_shift_id_list: # シフトsがどのヘルパーにも割り当てられなかったとき1、それ以外は0になる変数 alpha[s] = model.add_var(var_type=BINARY, name=f "alpha_{h}_{s}" ) # 目的関数 ## シフトにヘルパーが割り当てられなかったり、ヘルパーの勤務時間の過不足に関するペナルティを最小化する p1 = 10000 # シフトにヘルパーが割り当てられなかったときのペナルティ p2 = 10 # ヘルパーの勤務時間の過不足のペナルティ（1時間ごと） model.objective = minimize(xsum(p1 * alpha[s] for s in target_shift_id_list) + xsum(p2 * (beta_m[h] + beta_p[h]) for h in target_helper_ids)) # 制約式 for s in target_shift_id_list: ## すべてのシフトにヘルパーを割り当てる（アルファで緩和） model += (xsum(x[h, s] for h in target_helper_id_list) + alpha[s] == 1 ) for h in target_helper_id_list: ## ヘルパーごとに勤務時間量の上下限を守る model += (xsum(shifts_time_amounts[s] * x[h, s] for s in target_shift_id_list) >= low_time_amounts[h] - beta_m[h]) model += (xsum(shifts_time_amounts[s] * x[h, s] for s in target_shift_id_list) <= upp_time_amounts[h] + beta_p[h]) ## 勤務時間量の緩和制約 model += (beta_m[h] <= low_time_amounts_ease[h] - low_time_amounts[h]) model += (beta_p[h] <= upp_time_amounts[h] - upp_time_amounts_ease[h]) # 同時に担当不可能なサービスには割り当てない for s1, s2 in overlapped_shifts: for h in target_helper_id_list: model += (x[h, s1] + x[h, s2] <= 1 ) model.__data = x, alpha, beta_m, beta_p return model 得られた結果と考察、課題 カイポケ内のデータにある10事業所に対して、今回の問題を解いてみたところ、以下のような結果が得られました。 得られた結果 「ヘルパー数」「利用者数」「サービス数」が入力データに関する情報、「実行時間」がソルバーによる計算にかかった時間を表しています。「ヘルパー1人あたりの移動時間」は、カイポケ内に記録されている実際のシフトでの移動時間と、今回作ったモデルの出力での移動時間、その差分を表しています。差分がマイナスなほど、モデルによって移動時間が大きく削減されていることを意味します。なお、地図上の直線距離から移動時間を計算していて、移動速度は簡単のため東京都では自転車移動を仮定して分速250m、東京都以外では車移動を仮定して分速500m（時速30km）としています。 これを見ると、まずおおむね実際よりも移動時間が短くなるシフトが得られていることがわかります。最大だとヘルパー1人あたり月間279分（＝4.6時間）もの移動時間の削減ができています。一方で、差分がプラスで削減されなかったケースもありますが、そこそこ効率的なシフトが「人の手を借りず自動で」得られたことにも価値はあると考えています。 また実行時間をみると、月間のサービス数が多いと実行時間が長くなることがわかります。特に、サービス数が1000を超えたあたりから急激に実行時間が伸びていそうです。今回はあくまでも技術開発として進めましたが、もしこのモデルによる「シフト自動作成機能」を実際にカイポケに組み込むとすると、月間サービス数が1000を超える大きい事業所には何らかの工夫をする必要がありそうです。 モデルの挙動をもう少し細かく見てみます。こちらの図は、とある事業所の一日のシフトを地図上に可視化したものです。 シフトの可視化A 色はヘルパーに対応し、①などの数字はヘルパーごとの訪問順を表します。左がカイポケ内に登録されている実際のシフト、右が今回のモデルによって得られたシフトです。 これらを比較すると、実際よりもモデルによるシフトのほうが遠距離の移動が減り、全体的にコンパクトに利用者宅を巡回していることがわかります。合計の移動時間も25分→15分に削減されており、「遠すぎる移動はさせない」という制約条件をモデルに組み込んだ効果が得られています。 一方で、望ましい結果が得られていないケースもあります。こちらの図は、先ほどと同じ事業所の別日のシフトを可視化したものです。 シフトの可視化B これを見ると、たしかにモデルによるシフトのほうが移動時間は大きく削減されているものの、1シフトのためだけに出勤するヘルパーが増えてしまっていることがわかります。「ヘルパーを増やしたら移動時間も短くなる」というある意味当然の結果になってしまっており、これを改善するためには移動時間以外の効率性も考慮する必要がありそうです。 さいごに 今回はカイポケ内のデータと数理最適化の技術を使って、訪問介護のシフトスケジューリング問題を解いてみました。 簡単なモデルを作成して結果を見てみると、おおむね実際のシフトよりも効率的に移動するシフトが得られました。一方で、今回のモデルだと月間のサービス数が一定を超えると計算時間が急増したり、「移動時間が減るかわりに稼働するヘルパーが増える」といった微妙な結果になることもありましたが、改善のための示唆が得られたという点ではプラスだと思います。 そして何よりも、社内データを使って数理最適化の技術検証ができたというのは、A&I推進部にとって大きな意義があると考えています。数理最適化にかぎらず、今後もさまざまな技術を検証して、ゆくゆくは事業課題解決に役立てることができたら嬉しいです。 エス・エム・エスには数多くのサービスがあり、介護、医療に特化したデータを数多く保有しています。データサイエンスを活用したサービス向上ニーズも高く、今回のような技術開発にも力を入れています。今回の記事で少しでも興味を持って頂ける方がいらっしゃいましたら、ぜひお話を聞きに来ていただけたらと思います。 *1 : シリーズ：最適化モデリング 第3巻 ナース・スケジューリング 問題把握とモデリング p.157

介護事業者向け経営支援サービス「カイポケ」のソフトウェア開発者の空中清高( @soranakk )です。 2021年12月に入社し、介護事業者向け経営支援サービス「カイポケ」のフルリニューアルプロジェクトに携わっています。 今回はフルリニューアルプロジェクトのアーキテクチャ選定や背景についてご紹介したいと思います。 フルリニューアルプロジェクトのアーキテクチャ フルリニューアルプロジェクトのシステムはざっくりと解説すると、バックエンドにいくつかのサービスが並んでいて、フロントエンドとバックエンドの間にゲートウェイが立っているサービスベースアーキテクチャになっています。 それぞれのサービスはAWSに配置するようになっていて、この図のような構成になっています。 またフロントエンドとバックエンドはGraphQLを利用して連携している形になっていて、さらにバックエンド間通信においてもGraphQLを利用しています。 このようなアーキテクチャを採用したのは介護業界で適切なソフトウェアを開発するためです。 そこで、介護業界とはどんなものなのかを説明して、なぜこのようなアーキテクチャを採用したのかを深ぼっていきたいと思います。 複雑で変化の激しい介護業界 まず一口に介護業界と言っても、そこには多種な介護サービスがあり、また介護サービスには登場人物がたくさんいます。 介護サービスは通常のサービスと異なり、介護を受ける利用者が介護サービスを提供している事業者から介護サービスを受ける、というだけではありません。 その人にどんな介護サービスが必要で、どこの事業所ならその介護サービスが提供できて、一月分の予定(ケアプランと言います)はどうしたらいいか、ということを考えて利用者にケアプランを提供するケアマネジャーという方がいます。 介護が必要になった人はまず、このケアマネジャーからケアプランを受け取って、それを元に介護サービスを提供している事業所で介護サービスを受ける、という形になっています。 また、この時のお金の流れも普通の買い物などと異なり、介護保険というものが大きく関わってきます。 利用者は介護サービスを受けるときに全額負担ではなく、介護保険によって1~3割の負担を事業所に支払います。 介護サービスを提供した事業者は利用者から受け取らなかった保険分は1ヶ月分をまとめて次の月に国民健康保険団体連合会(通称：国保連)に請求して残りの金額を受け取る(介護保険請求)、という流れになっています。 また、そもそも利用者から直接報酬を受け取っていないケアマネジャーは次の月にまとめて国保連に請求することで報酬を受け取るようになっています。 このときケアマネジャーの提出するケアプランの内容と事業所の提出するサービスの提供実績に齟齬があると介護給付費が支払われないため、単に国保連に提出するだけではない複雑さがあります。 介護保険請求の流れ さてここまでで、介護サービスを受ける人、ケアプランを決定するケアマネジャー、介護サービスを提供する事業所、介護給付費を支払う国保連、という登場人物が出てきました。 さらに介護サービスと言っても、そのサービスの種類はたくさんあります。 介護施設で受けるサービスの他に、例えば在宅で受けるサービスは内容によって数種類ありますし、他にも福祉用具の貸し出しサービスなど、本当にたくさんのサービス種類があります。 さらに数年毎に法改正が行われるため、たびたびルールに変更が加わったりサービス種類が増えたりと変化がとても激しいです。 サービスベースアーキテクチャ カイポケのフルリニューアルプロジェクトでは、このように複雑で変化の激しい介護事業の環境に耐えながら継続して開発し続けられるシステムの形をドメイン駆動設計を通じて考えてきました。 その結果、「カイポケ」はいくつかの領域に分割できるだろうということがわかってきました。 大まかに言うと、ある介護サービス種類に特化した領域、介護保険との関連が強い介護報酬に関係する領域、カイポケをSaaSとして提供するための領域、などです。 そこでカイポケのフルリニューアルプロジェクトでは、確実に分解できそうな粒度の粗い領域毎のマイクロサービスにシステムを分割するサービスベースアーキテクチャを採用することにしました。 これまでモノリシックだった「カイポケ」をいくつかのサービスに分割して並行開発体制を取ることで、介護事業の複雑さや法改正による変化に対応しようとしています。 サービス分割を行なったばかりの頃は、まだフロントエンドとバックエンドには分かれておらず、それぞれのサービス毎にカイポケを開発していく想定でした。 いわゆるマイクロフロントエンド構成です。 次はどのようにしてマイクロフロントエンド構成からフロントエンドとバックエンドが分かれたのかについて、ご紹介したいと思います。 フロントエンドとバックエンドの分割 初期のアーキテクチャでは分割したサービス毎にフロントエンドを開発するマイクロフロントエンドの構成を考えていました。 しかし更なるドメイン駆動設計やユーザーテストの結果からバックエンドの分け方とフロントエンドの分け方は異なることがわかってきました。 バックエンドは介護業界のサービス種類や介護保険などの法律上の制約で分けることができたのですが、フロントエンドも同じような分け方をすると使いづらいソフトウェアになってしまうことがわかりました。 また、フロントエンドはカイポケを利用する人、つまり介護業界に登場する人物毎に分けた方がUXがよさそうということがわかりました。 そのためフロントエンドはバックエンドのサービスとは分かれ、マイクロフロントエンドの構成をやめることになりました。 その経緯について、こちらの記事でも詳細に書かれていますので、ご紹介します。 tech.bm-sms.co.jp ただし上の記事からのアップデートとして、一部の利用者に依らない共通のフロントエンドについてはバックエンドのサービスと合わせてマイクロフロントエンド構成で開発を進めているサービスもあります。 フロントエンド/バックエンド連携 フロントエンドとバックエンドは分かれましたが、フロントエンドからいくつもあるバックエンドを選んで通信を行うのは辛いだろうということからフロントエンドとバックエンドの間にAPIゲートウェイを置いています。 当初から認証の観点でゲートウェイを置くことになっていましたが、さらにAPIを束ねる機能も担うことになりました。 また、フロントエンド/バックエンド間通信のプロトコルはクライアント側から柔軟にデータの取得方法を選択できるGraphQLを採用しています。 このAPIゲートウェイの置き方を少し工夫しているのでご紹介します。 APIゲートウェイでバックエンドのGraphQLを束ねる フロントエンドからはゲートウェイだけが見える状態になっていて、ゲートウェイへGraphQLリクエストがやってきます。 その後のゲートウェイから適切なバックエンドへ流す処理を実現するため Apollo Federation を採用しています。 Apollo Federation は複数あるGraphQLサーバーを一つにまとめることができる技術です。 Apollo Federationを用いることでゲートウェイにやってきたGraphQLリクエストを適切なバックエンドのGraphQLサーバーに流すことができ、適切なレスポンスをフロントエンドに返すことが可能になります。 Apollo Federation を使わないで複数のGraphQLを束ねようとすると、ゲートウェイにやってきたGraphQLリクエストから適切なサーバーを選んでルーティングする処理を実装しなければならず、実装コストの増加や管理が煩雑になる懸念があります。 ただし、Apollo Federation を使う場合にも注意しなければならないことがあります。 バックエンドのGraphQLサーバーはそれぞれ独立しているのですが、最終的にゲートウェイで一つに束ねられることになります。 そのためバックエンドのGraphQLのスキーマ同士で、それぞれ名前等が衝突しないように作っておく必要があります。 また命名規則も統一しておかないと、あるバックエンドのGraphQLスキーマでは複数形は s を付けるようになっているけど、別のバックエンドでは List と付けるようになっていて〜、といった混乱が起こってしまいます。 なのでスキーマの命名規則などはバックエンドのチーム間で話し合って統一するようにしています。 また名前の衝突など、バックエンドのGraphQLスキーマを束ねた結果に不整合が発生していないことをチェックするため、GraphQLのスキーマ管理サーバーとしてApollo Studioを利用しています。 それぞれのバックエンドサーバーはApollo StudioにGraphQLスキーマを登録する形になっていて、ゲートウェイからはApollo Studioを参照して合成GraphQLスキーマを取得するようにしています。 またバックエンドのチームはCIで合成したGraphQLスキーマが壊れてしまわないこともチェックするようにして、不意に壊れてしまってフロントエンドからアクセスできなくなることを防いでいます。 フロントエンド・バックエンド間の通信だけでなく、サービス間連携においてもGraphQLを採用しています。次に、そのことについてご紹介します。 サービス間連携におけるGraphQLの採用 リニューアルプロジェクトではバックエンド間のサービス間通信プロトコルでもGraphQLを採用しています。 バックエンド間通信だけを考えるとGraphQLは適切なのだろうか？といった疑問もありました。 しかしそれぞれのバックエンドはフロントエンド用にGraphQLプロトコルを提供することが決定していたため、サービス間通信用に新しいプロトコルに対応すると、フロントエンド用とサービス間通信用で二つのプロトコルを管理することになります。 また二種類のスキーマを管理するのは煩雑になるだろうというもありました。 そこで、スキーマ管理とプロトコルスタックを少なくしてシンプルにしたいという理由からバックエンド間通信でもGraphQLを利用することに決定しました。 フロントエンド用とバックエンドのサービス間通信用のGraphQLスキーマを統一的に管理するために少し工夫しています。 完全に二つのスキーマファイルを分けて管理する方法も検討したのですが、queryやmutationは違うだろうけど、type等は同じものを使いたい場面がありそうで、その場合にそれらを共有する方法をどうしたらいいのかが課題になりました。 そこでGraphQLのDirectiveとApollo Studioの機能を使って、一つのスキーマファイルで両方を管理できるようにしています。 Directiveには可視性を制御できるものがあり、バックエンドのサービス間通信用のスキーマは不可視の状態でApollo Studioに登録することで、ゲートウェイからApollo Studioを参照したときは存在しないように見せることができます。 一方、サービス間通信の場合のスキーマはバックエンドの統一スキーマではなく、通信したいバックエンド単体のスキーマで良いので、直接そのスキーマを見るようにして参照します。 最適なシステムの形を目指して 今回紹介した構成で実際に並行開発体制を維持しながら法改正に対応できるかどうかは、これから確認していくことになります。 その結果からまたドメイン駆動設計を行うというサイクルを通じて、私たちはより良い「カイポケ」を作り上げていこうとしています。 昨今のソフトウェアは開発してリリースしたら終わりという訳ではなく、継続して改善し続けていくことが基本となっています。 私たち「カイポケ」のフルリニューアルプロジェクトチームでも次の法改正を視野に入れながら、変化していく介護業界で継続して改善し続けられるシステムアーキテクチャを目指して開発を続けています。 実際、今回紹介したアーキテクチャではフロントエンドとバックエンドは完全に分かれているのですが、さらなる検討の結果から、一部の利用者に依らない共通のフロントエンドについてはマイクロフロントエンドのようにバックエンドもフロントエンドも開発している状況だったりします。 こういったエス・エム・エスでのアーキテクトの仕事の仕方についてはこちらの記事で詳細に書かれていますのでご紹介します。 tech.bm-sms.co.jp 最後になりますが、フルリニューアルプロジェクトではエンジニアだけでなくプロダクトマネージャー・UI/UXデザイナーなど、複雑で変化の激しい介護業界での最適なシステムの形を目指して一緒に開発をしてくれるメンバーを募集中です！ プロジェクト専用サイト 内に募集中のポジションを記載していますので、興味のある方はぜひご覧ください！ またカジュアル面談もやっておりますので「選考に進む気持ちはまだないけどもっと突っ込んだ話を聞きたい」とか「ここはどうなってるの？」みたいな感じで軽く話してみるだけでも結構ですので、興味があれば是非お気軽にお声がけください！

はじめまして。 @kimukei です。 2022年9月1日からソフトウェアエンジニアとして株式会社エス・エム・エスで働いています。 この記事では、「カイポケリニューアルプロジェクト」（以下「リニューアル」）とこの会社について、最近ジョインした私の目線から実際どんな感じなのかを掘り下げていきます。興味を持っていただけている方にチームの雰囲気や文化などが伝われば幸いです。 リニューアルについては以下のサイトもぜひご覧ください。 careers.bm-sms.co.jp これを書いている人 2018年に新卒で株式会社LIFULLに入社してからずっとWebの領域でフルスタックに色々エンジニアリングしてきました。正社員エンジニアとして働きながら副業エンジニアとしても複数の会社でプロダクトを手がけていたりと精力的に活動してきました。前職のBASE株式会社では主に顧客管理システムのローンチや新機能の開発のリードをしてたりしていました。 詳しくはここにまとめていますので興味があれば覗いてみてください。 https://kimuchanman.github.io/self-introduction/ では早速本題に移ります。 そもそもなんでエス・エム・エスに入社したの？ まず、エス・エム・エスをどうやって知ったかですが、一番最初は転職ドラフトの指名です。私の場合、指名いただいた企業様の指名理由やテックブログなどに目を通してからお返事していました。 エス・エム・エスはテックブログやドキュメントから、アーキテクトを定義しアーキテクトへのキャリアパス *1 *2 があることが伺えて興味を持ちました。組織によってアーキテクトの役割が異なりフワッとしがち、なんならアーキテクトという役割は設けていなかったりする中、自組織におけるアーキテクトの役割や考え方を明確に語っている組織は多くないと思います。 選考の前に、カジュアル面談を通して介護領域の複雑さと、2025年問題や2040年問題などの近い将来に迫った問題について説明していただきました。 日本が高齢化先進国になるということは、それを支えるシステムは高齢化社会の世界的なモデルとして模倣されるようになるはずです。そのため介護業界は近い将来、日本が世界をリードする領域になり得ることに関心を持ちました。 エス・エム・エスとはカジュアル面談を3回行なったのですが、リニューアルの指揮を執っている三浦さん *3 とのカジュアル面談では、プロジェクト概要や開発プロセスを説明してもらいました。 開発プロセスについては Domain-Driven Design Starter Modelling Process に沿った本格的な DDD のプロセスを導入しており、実際に介護現場での経験が長い方がドメインエキスパートとしてプロジェクトにジョインしているということを知りました。ここまでしっかりした DDD のプロセスを組織全体で実行するのは相当な体力がないとできないことだと思い興味が深まりました。 また、介護ドメインは複雑ながらも、入社前から介護制度に明るいエンジニアはごく少数であることやみんな入社してから学べていること *4 から、未経験の介護ドメインに飛び込む勇気が湧きました。 そういった経緯で、このプロジェクトは学びが多そうで面白そうだと思い入社に至りました。 実際に入ってみて 概ね入社前に聞いていた情報と大きな乖離はありませんでした。 リニューアルでは、多くのシニアメンバーがプレイヤーとして実際に手を動かしてサービス開発をしています。みんな経験豊富で、日々多様な視点や解決法が見られプレイヤーとしてはなんとも代え難い福利厚生を享受していると感じます。 また、実際に学んでみると介護制度の複雑さがわかってきました。というのも、そもそも介護まわりの法制度が既存のものに継ぎ足しで今があるような構造なのです。ソフトウェアエンジニアの方には、機能の追加を重ねていく中で複雑度が上がってきてしまったソフトウェアをイメージしてもらうと伝わりやすいかと思います。 更に、エス・エム・エス社内の中で紹介されている推薦図書に 『最新図解 スッキリわかる! 介護保険 第2版 基本としくみ、制度の今とこれから』 があり、これを読むとなおさら介護制度の複雑さが理解できました。 たとえば、単位数の計算がサービス種類や加算の種類の多さによって複雑になっていることや、サービス種類によって関わる人の役割や職種が変わってくることが挙げられます。そして、法改正の際にはこれらに変更が生じることもあります。リニューアルプロジェクトにおいても、このような複雑さをどのように取り扱うかは大きな焦点の一つとなっています。 その過程でドメインエキスパートと一緒にドメインモデリングができたり、ドメインエキスパートに気軽に相談できたり、定期的に施行される法改正についてドメインエキスパートによる説明会が行われることは非常に安心感があります。 しかし、入社前の想像と実際に入ってみてのギャップを感じる点もありました。入社時点（2022年9月）に感じたギャップとしては、ADR（Architecture Decision Records）などのドキュメント類が完全に整備されている訳ではなかったことが挙げられます。詳しくは後述します。 ドキュメンテーションについて 入社時点では、ドキュメントはそこまで整備されている方ではなかったです。 これは、当時はプロジェクトメンバーが少数で MTG やモブプロなど同期的な場で解決されることが多かったことが理由としてはあると思います。 しかし、プロジェクトメンバーの規模が拡大していく中でこのやり方に課題を感じ、組織としても、 GitLab Handbook を参考にしたコミュニケーションガイドラインを策定し、なるべく非同期で仕事を進められるようにドキュメンテーションをより意識的に取り組んでいます。また、フロー情報とストック情報を意識し、決定事項をストック情報としてロックして共有する方法を取るようになりました。 プルリクエストについても、GitHubのテンプレートの機能も活用して、変更の背景や設計方針や今回の変更のスコープ外の点などを明記するようにしており、プロジェクトとしても少しずつそういった「なぜ」や「どうやって」を明文化する意識が根付いてきたように感じます。 どういった人におすすめできるか エス・エム・エスはプロダクトごとに組織の色は違っていて、私がジョインしたリニューアルを手がける組織では、大きく二つの特徴があると思います。 一つ目は、個人に与えられる裁量が大きいということです。組織構造として縦のレイヤーが少なく、かなりフラットな体制を取っています。そのためきっちり分割されたタスクという単位では仕事が降ってくることは稀です。自発的にプロジェクト全体を成功に導くために必要なことは領域を問わず発揮することを期待されます。 自発的にタスクを定義し調和を取りつつ進めるような動きを取るため、ルーズボールが発生しやすい仕組みになっているとも言えます。そのため、ルーズボールを積極的に拾って行けたり、そもそもそういった問題を未然に防げたり、幅広く動ける人が現況だとより活躍しやすそうです。ファシリテーション力や巻き込み力も重要です。 よく「鳥の目、虫の目、魚の目」と称されるような、視点の使い分けをしながらのエンジニアリングスキルがあると非常に活躍できると思います。 とはいえ、この組織体制のままではなかなかスケールしません。現状についてはプロダクトがローンチ前であることに起因していそうで、開発初期はファジーで動的な要素が多いためであり、この構造はプロダクトの輪郭が出来上がるにつれて解決されていきそうです。 二つ目は、更なる成長を目指している大規模で複雑なシステムの構築に初期段階から携われる点にあります。 勝負する介護業界は前述の通り複雑性が高く、構築するシステムも簡単なものではありません。つくるものも多岐に渡りますが、その分得られる知識や体験は大きいです。 会社としてもスキルの習得には最大限補助をしてくれます *5 し、学ぼう、成長しようと思えばどんどん成長していける環境にあると思います。 また、まわりのメンバーのアウトプットから刺激をもらうことも多いと思います。 これらの点に魅力を感じてくださる方には是非ともジョインしていただきたい、成長に飢えていたり刺激が欲しい人にはもってこいの環境です！ おわりに リニューアルの全容や詳細は、カジュアル面談や会食の場の方がもっと話せてよりニュアンスなどが伝わりやすいと思います。 高齢化社会を支えるシステムの需要は明確にあります。 また、今後の日本の高齢化現象を考えると介護はかなりの成長市場で、どんどん面白くなってくると思います。社会的なインパクトや意義も大きい分野です。 そんな市場で一緒にエンジニアリングしていくメンバーを随時募集中です。 以下のページから連絡いただくか、直接 私 に連絡してくれればお話します！ やっていきましょう！ *1 : https://tech.bm-sms.co.jp/entry/2021/01/05/142920 *2 : https://tech.bm-sms.co.jp/entry/2021/03/09/090000 *3 : 三浦さんの入社エントリー: https://tech.bm-sms.co.jp/entry/2021/05/18/120000 *4 : Domain-Driven Design Starter Modelling Processで学んでいった過程や成果物は Miro に残しているという話も伺っていたため、入社後にそれまでのドメインモデリングのキャッチアップは可能だろうとも考えていました。 *5 : 特徴的な制度・環境: https://careers.bm-sms.co.jp/engineer/kaipoke-renewal#block-ed672e58230841bd92a655e618bf7983