介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、荒巻です。 最近社内で、小さい技術ネタをなんでも発表できる会をはじめてみたので、その共有です。 ふだん社内では、まとまった技術情報は 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

エス・エム・エスのエンジニアの宮坂です。2022年1月に入社し、以来、介護事業者向け経営支援サービス「カイポケ」の リニューアル開発 に携わっています。 今回は私が開発を担当している「介護報酬の算定ロジック開発」についてお話したいと思います。 介護報酬とは何か そもそも介護報酬とは何でしょう？ 高齢になったり病気になったりして、周りのサポートがないと生活が難しい状態になってしまった場合、介護サービスを受けることになります。介護サービスは、提供したサービス内容や介護の必要度合いなどに応じて金額が定められていて、これを介護保険（一部、利用者負担）から介護サービスを提供した事業者に支払われます。これが介護報酬と呼ばれるものです。 介護保険は、法律によって40歳以上になると誰もが加入することになり、その保険料は毎月の給与などから引かれているので、介護を受けていない人も含めて介護サービスを支えていることになります。 難解な介護報酬の算定 この介護報酬、ちゃんと計算して請求しないと介護サービスを提供している事業者は収入を得られないので事業を続けられず困ってしまうのですが、この算定がすごく難しいのです。 提供される介護サービスにはそれぞれ「単位数」というものが定義されていて、提供した条件によってはさらに単位数が加算されます。その計算のルールが算定構造として国から提供されており、それをもとにロジックを組み立てていきます。こうして、算定した単位数に、地域ごとに定められた「地域単価」を掛けることで、介護報酬が決まります。（介護報酬 = 単位数 × 地域単価） 例えば、ある介護サービスの利用者に 「身体介護」という訪問介護のサービスを20分提供した 訪問は2人で行った その提供時間は「早朝」だった とします。このときの地域単価が10円の場合の介護報酬は、 身体介護 20分以上30分未満 = 250 単位 … ① 2人の訪問介護員等による場合 = ① × (200/100) = 500 単位 … ② 夜間もしくは早朝の場合 = ② + ② × (25/100) = 625 単位 … ③ 介護報酬 = ③ × 10 = 6,250 円 となります。このうちの利用者の負担額が1割とすると、 介護保険への請求額 = 6,250 × (1 - 0.1) = 5,625 円 利用者への請求額 = 6,250 - 5,625 = 625 円 となり、介護サービス事業者は、介護保険から 5,626 円、介護サービスの利用者から 625 円を受け取る計算になります。 (介護保険の自己負担は所得に応じて1割から3割までのいずれかとなります) 図1：訪問介護費の算定構造の一部 https://www.wam.go.jp/gyoseiShiryou-files/documents/2022/0322211552821/202203a.pdf (赤囲み線は引用者) (2023年3月3日 閲覧) こういった単純なパターンであればそこまで難しくありませんが、介護報酬を算定する際には様々な条件を考慮しなくてはなりません。 単位数が加算される条件の考慮 図1 だと「緊急時訪問介護加算」は「身体介護」提供時にしか加算されない 利用者の介護度（どの程度の介護が必要なのかのレベル） 介護度に応じた介護保険から支払うことができる金額の限度額の考慮 生活保護などによる公費負担 利用者が引っ越しをした、介護度が変わったなど介護サービス提供中に発生した変更の考慮 などなど、挙げ出したらキリがないですが、介護報酬をキチンと計算するには、すべてのパターンを考慮した算定ロジックを実装する必要があります。このパターンとこのパターンを組み合わせた場合はどう算定したら良いのだろう…というような算定構造だけではわからない不明瞭なパターンも多くあり、様々な資料を読み漁りつつ、正確な算定を実装していく必要があり、ここが介護報酬の算定を難解にしている理由の一つでもあります。 3年に一度の介護制度の改正 もう一つ、介護報酬の算定にとって高いハードルがあります。それは3年に一度行われる報酬改定です。刻々と変わる社会の状況に対応するため、定期的に介護保険制度の見直しが行われています。これによって、今までの制度が更新されることもあれば、新しい制度が追加されることもあるので、これに対応して行かなければいけません。 報酬改定については以前にも記事にしているので、興味がある方はそちらもご覧ください。 tech.bm-sms.co.jp この改正された制度は大半が4月から（一部は10月から）適用されるのですが、適用開始のギリギリまで正式決定されません。例えば令和3年の報酬改定では、令和3年3月31日に確定された旨が通知されました。お金に関わる計算なので、正確な実装を求められるのですが、制度の内容が不明瞭な中での短期間での開発が必要になり、開発の難易度が高くなっています。 もちろん、過去分の請求をしていない人たちも存在するため、制度改正前の介護報酬の算定もある程度の期間は維持しておかないといけません。これもロジックの実装の難易度を上げる要因となっています。 難解な算定ロジックと闘うために だからといって、この部分の実装を諦めるわけにはいきません。介護報酬の算定とその請求処理はカイポケのコア機能です。これが正しく実装されなければ、プロダクトが成り立たないのです。 そこで、難易度の高い計算をより容易により正確に実装するため、様々なトライをしています。 新たな介護報酬算定ロジックの開発 度重なる報酬改定の短期間での開発で、継ぎ足し継ぎ足しの実装をしていった結果、既存の介護報酬の算定ロジックは非常に複雑度の高いものになっています。そこで、介護報酬の算定順序や算定に影響のある条件を整理し直して、介護報酬算定ロジックの開発を一から行っています。 先程ご紹介した算定構造はある程度のパターンを持った構造で表現できるので、これを元に算定ロジックの実装を進めています。一度算定構造の理解が誤っていて、実装を一からやり直しをすることがありましたが、理解度が上がった段階で整理をすることができたので、シンプルな設計に再構成することができました。 まだまだ完成には程遠いですが、短期間での報酬改定に対応できる算定ロジックを目指して開発を進めて行きたいと思っています。 専門家によるテストケースの作成 紹介したとおり、介護報酬の算定には、様々なパターンが考えられ、すべてのパターンで正確に算定できる必要があります。算定ロジックの実装と並行して、ドメインエキスパートやQA、プロダクトオーナーなどエンジニア以外のロールの方々の知識を集結して、考えうるパターンを網羅したテストケースを作成してテスト実行を自動化しました。 これによって、実装の変更による不具合をすぐに検出し、品質の担保をしていきたいと思っています。 まとめ 介護報酬の算定の難解さと、その難解な算定ロジックとどのように闘っているかを紹介しました。正直、私も入社して1年ほどなので、まだまだわからないことだらけです…。 ですが、いろいろな知識を持ったチームメンバーと、難解なロジックを一つのアプリケーションに落としていく過程にやりがいも面白さを感じています。チームの雰囲気も良く、協力的なので、様々なトライをしながらの開発ができ、そういった環境もロジック開発の面白さを感じさせてくれる部分なのかなと思ったりしています。 まだまだ開発の半ばなので、一緒にチャレンジしてくれる仲間が必要です！少しでも興味を持ってもらえたら幸いです！

こんにちは。2022年10月にエス・エム・エスに入社した塩井です。 現在はプロダクト開発部介護キャリア開発グループにて、介護職向け求人情報サイト「カイゴジョブ」の開発を行なっています。 この記事では、私が前職からの転職先にエス・エム・エスを選んだ理由、そして実際にエス・エム・エスで働いてみて感じていることなどをご紹介したいと思います。 誰？ 改めましてしおいと申します。Twitterでは @coe401_ 、GitHubでは @shioimm と名乗っています。 前職では東京と福岡に教室を展開する小中高校生向け英語塾の社内開発チームで学習管理システムの開発を行なっていました。 プログラミング言語Rubyとそのコミュニティが大好きで、好きが高じた結果RubyKaigi 2021とRubyKaigi 2022にて登壇の機会をいただきました。よく地域Rubyコミュニティのミートアップに出入りしています。 前職までのあらすじ 前職が英語塾の会社であったことを前述しましたが、更に遡るとそれ以前はプログラマではなく、コールセンター業務や事務職で数社を転々としていました。そうするうち、「せっかく働くのなら自分が働いた分、少しでも世の中が良くなるような仕事をしたい」と考えるようになりました。 世の中には、解決すればもっと世の中が良くなるような課題がたくさん存在しており、それらの課題に取り組んでいる企業・団体・人々もまたたくさん存在しています。その中でも特に、テクノロジーの力で社会課題の解決を目指すようなプロダクトを作る仕事をしたい、と考えてプログラマになることを志し、自分の中での大きな関心ごとであった教育事業に関わるため前職で働き始めました。 とはいえ特にコンピュータサイエンスについての素養はなく、付け焼き刃で少々Rubyをかじった程度の状態で職に就いたため、最初は右も左もわからず…。社内では周りの上司や先輩方にお世話になり、社外ではRubyコミュニティの人々と交流しながら七転八倒しているうちに何とか業務でも趣味でもたのしくプログラミングができるようになっていきました。 前職は小さなチームで小さなプロダクトをじっくり開発するという特徴があったため、自分たちで考えて実現できることも多く、次第に開発をスムーズに進めるための自分たちらしいやり方も整っていきました。 2021年から2022年にかけては事業部を含めたチームメンバーたちとのn人n+1脚で、将来のサービス開発に向けた土壌を整えるための一連の大きな改修を行い、それらがひと段落つきそうな気配が見えた時、このサービスはこれから先も続いていくけれど、自分の仕事はここまでだな、という感覚が自分の中に芽生えました。プログラマとして初めての転職のタイミングがやってきたのです。 3つの転職条件とエス・エム・エス さて転職を考えるにあたり、こんな会社で働きたい、というふんわりとした条件を3つ考えました。それは、「やっぱり世の中が良くなるような仕事がしたい」「今よりももっと技術力を高めたい」「Rubyが好きな人々と一緒に働きたい」というものです。 そして、いろいろな会社の方からお話を伺った中で、これらの条件を全て満たしていたのがエス・エム・エスでした。 ①「世の中が良くなるような仕事がしたい」 転職先が自分自身の問題として力を尽くしたい社会課題に取り組んでいる会社であってほしい、というのは自分がプログラマになることを決めた動機づけであり、どうしても外すことのできない条件でした。 これに対し、エス・エム・エスは高齢社会が直面する社会課題の解決を目指す会社です。 ご存じのとおり少子高齢化・人口減少は、この社会における喫緊の課題であり、これから時間の経過と共に人口動態がどのように変化していくか、それによって世の中がどのように変化していくか、はある程度予測可能である一方、それをどのようにすれば解決できるのかについては今なお手探り状態です。エス・エム・エスでは40以上ものサービスを展開しており、介護・医療・ヘルスケア・シニアライフという4つの領域でそれぞれに情報インフラを構築することでこれらの課題に向き合おうとしています。 また医療・介護は社会にとっての大事な関心ごとであると同時に、自分の家族や自分自身の人生に直接関わる大事な関心ごとでもあります。老いと無縁な人はいません。 カジュアル面談の際に「介護にまつわるサービスは介護を受けるその人のためのサービスでもあるけれど、その家族のためのサービスでもある」と技術責任者である田辺さんが仰っていたことが印象に残っています。 ②「今よりももっと技術力を高めたい」 前職ではプロダクト開発が売上に直結するビジネスモデルではなかったため、腰を据えて機能を考える、開発に取り組むという経験を積むことができました。 一方で自分自身の経験不足による引き出しの少なさを痛感しており、転職先では前職とはまた異なる開発経験を積むためにより規模が大きく・成長がはやく・そして長く使われるプロダクトの開発に携わりたいと思っていました。 これに対し、前述の通りエス・エム・エスは4つの事業領域で40以上ものサービスを提供しており、それらの中には歴史があり規模の大きいものから比較的新しいものまで様々なものが含まれています。それらの共通点は、いずれも10年20年と成長し続けるサービスを目指して提供されているという点です(高齢社会の課題に向き合うということはそれほどに長い時間を見据えてのサービス提供が必要であるためです)。 こうした特徴を踏まえて、エス・エム・エスで開発者として働くということは、長い時間をかけて成長し続けるサービスに関わることができるチャンスであると感じました。 同時に、キャリアを積んでいく中で場合によっては特徴の異なる複数のサービスに関わるなど選択肢の幅が広がる可能性もあるのではないかと考えました。 ③「Rubyが好きな人々と一緒に働きたい」 冒頭でも自己紹介しましたが、私は職業プログラマであると同時にRubyistでもあります。そのため、同じRubyが好きな人々が働いているような、そして業務外での自分のRubyistとしての個人的な活動を見守ってもらえるような環境で働きたいと思いました。 一方、エス・エム・エスでは多くのサービスを多くのチームで開発しており、その全てのプロダクトがRubyで開発されているわけではありません。 しかし技術責任者の田辺さんはもちろん、入社後私の所属先となった介護キャリア開発グループにもRubyコミュニティでおなじみの人々が所属しており、そして会社としてはRubyKaigiやKaigi on Railsなどのカンファレンスにもスポンサーとして協賛しており、Rubyコミュニティと地続きの環境であることに間違いありません。 (余談: 入社直前に参加したRubyKaigi 2022では現地会場のホワイエにて、入社後の私の上長である諸橋さん、私、そして私にとってのRubyコミュニティの憧れの人々という面々でお喋りするというとてもRubyKaigiっぽい一幕があり、地続き感溢れていました) こうしたことを踏まえて、改めて「こんな会社で働きたい」を考えてみた時、自分にとってエス・エム・エス以上の選択肢はない、と判断しました。そして実際の転職活動ではエス・エム・エス一社のみに選考を申し込み、ありがたいことに入社が決まったという次第です。 エス・エム・エス入社後の日々 ということで入社して数ヶ月が経ちました。 予想はしていたものの、前職とは会社の規模・事業ドメイン・技術スタック(一部)・開発の進め方…と何もかもが違う環境に身を置いているためまだまだ学ぶことの多い目の回るような毎日を過ごしています。 と同時に、ここまでの数ヶ月は自分にとってエス・エム・エスは最良の選択だった、という点について確信を持つことのできた数ヶ月でもありました。 私の所属先である介護キャリア開発グループで開発している「カイゴジョブ」は、介護従事者の方々が新しいキャリアを歩むお手伝いをするための求人広告サービスです。 エス・エム・エス社内にはカイゴジョブに隣接する他のサービスもあるのですが、私の入社当時はそれらのサービス間を横断するような形でより手厚くユーザーの方の支援ができるようにするための機能開発の真っ最中でした。どんな機能を開発すると、それがどんな形で介護従事者の方々のもとに届き、それによってどんな風に世の中が少し良くなるか、を入社直後から早速体感することになりました。 技術面では予想の通り、前職との主に事業ドメインの特性や事業規模やインフラ構成の違いなどから自分にとって初めて出会うような課題が数多くあり、その分学びの機会に恵まれています。 それに加えて頼りになるチームメンバーの先輩たちに囲まれながら、困り事を気軽に相談できるSlackチャンネルや過去の開発の知見が詰まった膨大なドキュメントを活用しつつ日々の開発を行なっています。 さらには開発メンバーの間でごく自然にペアプロ・モブプロが行う文化があり、私の好きな『達人プログラマー』の一節にある「一人ぼっちでコーディングに取り組んではいけない」というTipsが体現されている環境で働いています。 (最近は開発タスクを管理しているTrelloにてペアプロ相手を自動アサインする「モブりたい」ラベルが追加されるなどどんどん運用が進化しています) そして何より、開発に責任感を持って真摯に向き合い、ごく自然にお互いに助け合うチームメンバーの姿勢からはいつも刺激をもらっています。 チームメンバーである児玉さんによる先日の記事『アジャイルでビッグバンリリースの不確実性を低減する試み』の結びに 今回、私達は開発とテストの工程を並行するプロセスを採用し、デザインリニューアルプロジェクトを進めてきましたが、はじめからこの開発手法を確立できていたわけではありません。日々のプロセスの中で上手くいったことや課題に感じたことをチームでふりかえりながらプロセスを最適化してきました。 とあることからも、より良いやり方を皆で模索し続けるチームの真摯さが伺えます。 カジュアル面談の際に田辺さんが「エス・エム・エスのメンバーには誠実な人が多い」と仰っていたのを日々実感しており、自分もその一員として事業、プロダクト、チームに対して誠実なメンバーでありたいと思っています。 tech.bm-sms.co.jp おわりに 以前、チームメンバーである真下さんの記事『エンジニアはプロダクトの事業領域に関心を持ってなければいけないのか？』が投稿されました。 tech.bm-sms.co.jp エス・エム・エスで開発に携わる各部署メンバーへ入社時点でエス・エム・エスの事業領域(医療・介護・シニアライフ・ヘルスケア)についてどの程度興味を持っていたかについて調査した結果についてまとめたもので、なかなか興味深い結果となっています。 私自身も医療・介護・シニアライフ・ヘルスケアという事業領域に明確な興味を持っていたわけではありませんが、ふんわりとした「世の中が良くなる仕事がしたい」「もっと技術力を高めたい」「Rubyが好きな人々と一緒に働きたい」という気持ちで入社したエス・エム・エスで、現在は事業への手応えを感じつつ、技術的なコンフォートゾーンから出つつ、信頼できる人々と一緒に働くことができています。 この記事では執筆者である私にとってのエス・エム・エスが転職先としてどんな会社だったのか、について書き連ねてきました。この記事でエス・エム・エスに少しでも興味を持ってくださる方がいれば幸いです。

はじめまして、エス・エム・エスでSREとして介護事業者向け経営支援サービス「カイポケ」の開発・運用に携わっている小笠原です。 2022年10月に入社してしばらく働くなかで組織やプロダクト開発の状況がある程度見えてきたので、入社エントリを兼ねて自身の所属するチームや仕事について紹介します。 内容は現在のスナップショットにはなりますが、中で働いている人や組織の雰囲気、向き合っている課題について今後入社を検討される方の参考になると嬉しいです。 入社までにやってきたこと 先に自身の経歴について紹介しますと、情報系の大学院を出て2017年からIT業界で働き始めて今年で6年目です。ポジション的にはいわゆる中堅どころのエンジニアです。新卒でSIerに入社してSEとして顧客の比較的規模の大きなWeb基盤の開発・運用を1年ほど行い、そこからWebベンチャーに転職して4年半ほど中規模なWebシステムの開発・運用に幅広く携わりました。 前職ではReact/Railsを用いたアプリの機能開発を経験し、その後は基盤開発に軸足を置いて基盤の構築・運用やアプリと基盤の間に落ちるような諸々の課題解決に取り組んでいました。 個人的に興味のあった課題（フロントエンド/バックエンドの機能開発、アプリのパフォーマンス改善、基盤の刷新、CI/CD構築、セキュリティ強化、モニタリングの導入・運用、コンテナオーケストレーションツールを用いたアプリ開発など）を一通り経験でき満足したことと、コンフォートゾーンに入っていたこともあり一度環境を変えようと考えたのが転職のきっかけです。 Web開発に関して一通りの経験は積めたものの技術的にはまだまだ未熟と感じていたため、これまでの経験を活かしつつさらに経験を深められる会社を探していました。 エス・エム・エスを知ったきっかけ そんな中、LinkedInでEMの古萱からメッセージをもらったのがエス・エム・エスを知るきっかけでした。それまではエス・エム・エスについては会社の名前も知らなかったのですが、メッセージに添えられていた 技術責任者田辺のブログ を読んで興味を持ちました。この記事では「継続性アーキテクト」という概念で技術を深める方向のキャリアを説明しており、技術志向のエンジニアに寄り添った考え方に感銘を受けました。そのような考え方を持った人が運営する組織であるなら一度話を聞いてみたいと考えました。 そして、実際に転職活動を行う中で採用要件や向き合っている課題について話を聞く中で私がこれまで行ってきた経験が多く活かせそうだと気づき応募するに至りました。 入社の決め手 複数社を受けて総合的に判断した結果入社を決めたので「これで決めた！」というものはないのですが、エス・エム・エスが他と比べて良いと思ったのは以下の点です。 ビジネスモデルが強い 医療介護業界は今後も需要が伸びるためそこをターゲットとしているエス・エム・エスは継続的に事業が発展する可能性が高く、エンジニアとして長期でコミットできそうと考えました。 事業に興味を持てた 私は自分が携わったシステムやサービスが最終的にどんな価値を社会に提供できているかが仕事のモチベーションになっています。エス・エム・エスが取り組んでいる医療・介護領域の事業はその点提供価値がわかりやすいため取り組みがいがあると考えました。 課題が多くて挑戦の余地がある サービスおよび機能の数が多く歴史もあるため、課題が多く取り組む仕事の範囲も広くて飽きないと考えました。よい設計で整理が進んだプロダクトの場合、かえって面白い仕事がない場合もあるので課題が多いことは自分は肯定的に受け取りました。 個人の裁量や動きやすさがありそうに見えた 大企業ではあるものの開発組織は人数的にも体制的にもまだまだ発展段階にあり、開発者個人の裁量が大きく動きやすさがあると考えました。また、組織の技術責任者やリードする立場の方がいわゆるWeb系の企業出身者が多く、エンジニア個人の動きやすさに配慮している印象を受けていました。 実際に入社してからは「カイポケ」というプロダクト（後述）およびそのリニューアルプロジェクトにSREメンバーとして関わって働いています。２つのチームで色はそれぞれ異なるのですが、自分が入社前に抱いていた組織やチームへの印象は入社後も大きく変わることはなかったように感じています。 関わっているサービス「カイポケ」について 「カイポケ」は介護事業者向けのSaaSです。 介護事業者が国の保険制度を利用する際の請求業務を行ったり、事業所職員がタブレットから記録業務を行ったり、それ以外にも介護事業に関わる様々な業務をこのサービス上で行うことができます。 カイポケの現行システムは開発開始から10年以上が経過しており、当初は主に外部のリソースを利用して開発していたところ、その後 内製化に舵を切って取り組んできた歴史があります 。現在４万を超える事業所で導入されており、40個以上の機能を備えています。 機能・ドメインごとにサーバが分割されているためサーバ台数は多いものの、主となるシステムの基盤構成はシンプルでALB、EC2、RDSをベースとした一般的なWebアプリを想像してもらえると良いかと思います。アプリケーションサーバのレベルでは分割されているものの、DBなどのリソースのアプリケーション間で共有されているため、システム全体としてはモノリシックな側面も残っています。 ところで、先日以下の記事でもご紹介したように、現在、この現行のシステムをリニューアルするプロジェクトが進んでいます。 tech.bm-sms.co.jp リニューアルをすることにした理由はいくつかあるのですが、先述のようにモノリシックな部分があるがゆえに変更の影響範囲が広くなりやすいこと、また、共有されているリソースの存在が組織全体の開発スピード向上のボトルネックになりうること、などがSREチームに関わる部分として挙げられます。 そのような背景のなかで私は現行「カイポケ」（以下、現カイポケ）のSREとリニューアルプロジェクトのSRE、２つのチームにメンバーとして関わっています。それぞれ向き合っている課題と求められる仕事に違いがあるため、雰囲気がわかるよう簡単に紹介していければと思います。 現カイポケのSREについて まず現カイポケのSREの責務ですが、開発・運用含め基盤関連の仕事全般と言うような形でふわっと与えられています。開発チームからの依頼対応や各種基盤リソースの障害対応、各種コンポーネントのバージョン更新、脆弱性対応などインフラエンジニアという括りで担当が分かれるような運用寄りの仕事もあれば、リリース改善やトイルの削減、プラットフォームのモダン化と言った一般的にSREが担当するような仕事まで様々です。 その中で何を優先してどこまで手を出すかはチームの体制・余力に応じてチーム内で調整するようになっており、チームの裁量は大きいです。チームが少数体制だったときには現状維持を主な目的とした「守り」の施策に集中していたときもありましたが、現在では人員が増えたこともありチームの業務範囲を拡大して現状改善を主な目的とした「攻め」の施策の割合を増やしているところです。 例えば直近で進んでいる施策には「バッチ実行基盤のマネージドサービスへの移行」、「デプロイ自動化」、「オブザーバビリティ改善」などがあり運用負荷削減や開発効率化、システム安定性向上といった現状からの改善を図っています。 現カイポケはシステムが少し古い構成で動いていることもあり、仕事の傾向としては現代的な構成や運用に持っていくことで価値が出ることが多いです。アプリは介護ドメインの複雑さを反映してビジネスロジックは複雑である反面、非機能要件はシビアではないため基盤側は世の中的によく使われているWebアプリケーション運用のベスト・プラクティスを正しく導入できれば着実に改善を進めることができるように見えています。 ただ、プロダクトの主たる部分がモノリシックな作りということもあり変更の影響範囲が広くなる傾向があります。新しい技術スタックの導入を試みると、検証中に思わぬ箇所で導入を妨げるような課題にぶつかります。課題にはいろいろな種類があるのですが、経緯を紐解いて地道に解決の道筋を作る必要が出ることが多く、歴史の長いプロダクト特有の難しさを感じます。 個人的にはそのような課題がある中でうまく差し込めるような解決策を考えるのがパズルゲームのようで面白いと考えています。技術責任者やEM、アーキテクトの方々も「過去のしがらみは気にせずどんどん改善を進めてくれたら良いよ」と肩を押してくれるので、今後もSRE主導での改善活動に積極的に取り組んでいきたいと考えています。 リニューアルプロジェクトのSREについて 一方でリニューアルプロジェクトのSREの責務はプロダクトが初期構築のフェーズということで柔軟性を持って動くことを期待されており、明確な定義はありません。ただしチームの大きな目標としては「システムが安定して動いている状態」と「システムを早く世の中にリリースできる状態」を維持することを目指して動いています。 SREの立ち位置がわかりやすくなるので先に開発体制について説明しておくと、リニューアルプロジェクトではアジリティの高い開発体制を目指しており、これを実現するため開発チームには基盤リソースのアクセス権限が与えられています。開発チームがオーナーシップを持つサブシステムごとの基盤リソースについては開発チームが管理するため、SREチームはシステムの全体設計や共通コンポーネントの管理を始めとするシステム横断の技術課題の解決に集中できるようになっています。 例えば直近の仕事で言うと以下の記事で紹介しているように「OpenTelemetryの検証」や「本運用を見据えた監視体制の整備」などに取り組んでいます。 tech.bm-sms.co.jp リニューアルプロジェクトではシステムを０ベースに近い形で設計しているため、制約が少ない中で技術選定や開発が行える環境です。もちろん技術の導入には妥当な選定理由は必要ですが、検証で該当技術の成熟度を測って導入判断を行ったり新しいバージョンのライブラリの使い勝手を試したりを気軽にできるのは新規構築ならではの楽しい部分だと考えています。 現在リニューアルプロジェクトでは初期バージョンのリリースに向けて動いており、運用基盤もそれに合わせて整備を進めていく段階です。SREチームでも開発状況に合わせて様々な施策を担っていくことになるので、自分でもどんどん手を動かしてプロジェクトの成功に貢献していきたいと考えています。 まとめ 個人的な転職の経緯から、現在関わっているチームや仕事について簡単に紹介させていただきました。これを読んで「カイポケ」のSREチームの雰囲気や普段どのような課題と向き合って仕事をしているかについて理解が深まると嬉しいです。 どちらのSREチームも開発状況が日々少しずつ更新されているため、本文では敢えて具体的に利用している技術の話やシステム構成の話、組織内の詳細な体制の話などは省略しました。より具体的な話や今後の見通しなどが気になった方はぜひ一度カジュアル面談にいらしてください。

2022年10月、介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー (以下、EM)としてエス・エム・エスに入社した酒井( @_atsushisakai )です。先日、転職活動については 個人のブログ の方に書いてみましたが、入社エントリとしてエス・エム・エスの入社までの経緯と、EMとして実際にどのような仕事をしているかも簡単にご紹介します。これから「EMとして」転職を控えている方で、不安を持たれている方にとっての指針になったりすると嬉しいです。 私のバックグラウンド 前職では、株式会社 MIXI で「家族アルバム みてね」というプロダクトを、創業メンバーとして立ち上げからグロースまで8年以上に渡り開発を続けていました。ソフトウェアエンジニアとしては、iOS/Android のネイティブアプリ開発、Ruby on Rails でのバックエンド開発や AWS でインフラを構築・運用するなど、少人数チームならではの領域を越えまくるスリリングな開発を行なっていました。 また、後半数年間は EM として、ピープルマネジメントとプロダクト開発チームのスケールのための組織作り・プロセス作り・採用活動などに取り組んでいました。 エス・エム・エスとの出会い そんな中、エス・エム・エスに出会ったのは転職のおよそ1年前、YOUTRUST でのスカウトメッセージでした。メッセージを受け取った後、コーポレートサイトを見てミッションや事業内容が非常に特徴的に感じ、その時は転職を全く考えていなかったのですが「面白そうだし一回話を聞かせてもらおう。自分の組織のために学びも得たいし！」くらいの軽い気持ちでカジュアル面談を申し込み、技術責任者の @sunaot と話をしました。 カジュアル面談では、エス・エム・エスの ミッション を中心に、展開しているサービスの課題、開発組織の課題などを広く聞かせてもらいつつ、自身の組織マネジメントの悩みなどを話して共感してもらったりなど、とても楽しく会話したのを思い出します。 なぜエス・エム・エスに入社を決めたのか その後、何度か @sunaot と話をさせてもらう中で私は転職する決意をし、最終的にエス・エム・エスを選びました。転職先としてエス・エム・エスを選んだ理由はいくつかあります。 エンジニアリング組織をより大きくスケールさせていくフェーズであること 私はこれまで、比較的小〜中規模 (50名くらい) の規模でプロダクト開発を中心とする組織のEMとして活動していました。自身の中には、EMとしてより成長していくためには、さらに大きな規模の組織で発生する課題に向き合い、そこから得られる経験が必要であると感じており、その規模感とエス・エム・エスのプロダクト開発組織がこれからスケールしていくであろう規模感のイメージが合致していたことが、この会社を選んだ一つの理由です。 戦略を特に重要視していること カジュアル面談で何度も話を聞いていく中で感じたのは、エス・エム・エスが一貫して「戦略」をとても重要視していることでした。社会課題に対してどのような視点からペインを解決しなければいけないかという Why の部分と、それをいつまでに解決すべきかという When の部分が徹底的に言語化されており、それに沿った形で非常に多くの事業やプロダクトに紐づいています。自分自身、事業における戦略が明確かつ相応な分量で言語化されていることは、迷った時に立ち返ることができる安心材料になるのでマネジメントの観点からも非常に業務が進めやすそうな魅力的な会社だと感じました。 子ども世代への影響度が大きいこと 最後は当然、解決しようとしている課題とそのための事業についてです。エス・エム・エスが展開している非常に多くの事業は、2040年問題と呼ばれる高齢者人口がピークに達する時代を見据えた課題解決の方向性を示そうとしています。2040年といえば、現在3歳の自分の子どもがちょうど社会に出る時代です。それを考えた時に、ひとつのプロダクトをじっくり作っていくことも重要ですが、多くの観点から社会の根本的な課題を解決するために自分の能力を使い、少しでも生きやすい社会に変化させていくことが、今の自分にとっては納得度も高く、何より我が子の未来のためになるのではないかと考え、最終的にこの会社に入社することを決めました。 入社してどうだったか？ 入社後、最初の一週間は非常に戸惑いました。それは、「EMとして会社にジョインする」ということが初めてだったことが一番大きな理由だと今振り返って思います。膨大な情報量と日々目まぐるしく動くプロジェクトの状況など、プロダクトの立ち上げからほとんど全てを把握していた前職の環境からは一変し、自分自身がどの情報を選択し、深くインプットした上でチームやメンバーに影響を与えていくことができるかを判断するのがとても苦労しました（これは正直、今でも苦労しています）。 ただ、チームメンバーは非常にオープンマインドの方が多いので、積極的に1on1を申し込んだりなどを重ねて、コミュニケーションを取る機会を増やしていったことで思ったよりも早く溶け込むことができました。そうすることで、EMとしてコミットできる小さな課題を徐々に見つけることができるようになっていったのを思い出します。エス・エム・エスの開発カルチャーとして、モブプログラミングや意識的なオンライン雑談の時間などが充実しており、新しい人を受け入れやすいマインドが備わっているのも影響が大きいと感じています。 入社後にやった仕事 現在は介護事業者向け経営支援サービス「カイポケ」の開発プロジェクトにおいて、フロントエンドチームの EM としてアサインしてもらっています。また、エンジニアやデザイナーのプロダクト開発に必要な人材の採用活動も幅広く扱わせてもらったり、プロジェクト全体のエンジニアリング部門におけるマネージャーとして、課題の集約や情報共有の結節点となるなど、現場に近いところでプロジェクト推進のためにできることを徐々に増やしていっています。 この中でもいくつか、入社後にフロントエンドチームの EM として取り組んだ仕事をご紹介します。私が EM を務めるフロントエンドチームは、私が入社する1ヶ月前に新たなチームとして発足しており、様々な整備やチームビルディングを行っていかなければいけない状況でした。以下は、そういう状況で私が EM として取り組んだ課題解決のいくつかの事例となります。 チームの価値観や暗黙知を言語化する 私がジョインしたタイミングでは、徐々に技術選定は進んでおり、チームがコードを書き始められるような土台は出来上がってきていました。ただ、立ち上がったばかりのチームなので、複数人でコードを書いていく上でそれぞれのメンバーが持つ開発の価値観を揃えたり、暗黙知となっている事柄を言語化することなどがまだそれほど出来ていない状態であったことに気づきました。これらを言語化することが長期的なパフォーマンス向上を実現する土台となるという経験はこれまでもあったので、まずはここに取り組ませてもらいました。そのひとつの成果として「コードレビューガイドライン」を GitHub リポジトリ上に立ち上げたり、同様に「コーディングガイドライン」も叩きとして作り、今後コードを書いていく中で何か取り決めがあった方が良いだろうというものをガイドラインとして言語化し、明確に共有していく流れを作りました。 コードレビューガイドライン スクラムの導入 コードベースが徐々に整理されていくのと同時に、ユーザー価値の実現プロセスとしては、スクラムを取り入れていくことが初期に決まっていました。スクラムのフレームワークを使い、どのようにプロダクトバックログアイテムを管理・見積もりを行うか、チーム内でスクラム関連のイベントをどのタイミングで、どのぐらいのタイムスケールで実施するかなどを PdM とじっくり話しながらプロセスを構築していきました。プロセス全体においては自身がスクラムマスターとして、チームがスクラムにおけるメリットをしっかりと享受できるよう、まずは教科書的に必要な要素をしっかり実践していくことを徹底しています。このあたりは、前職で長年スクラムを実践してきた経験がとても活かされていると感じています。 フロントエンドチームのMission/Vison策定 開発が安定的に進み始め、新たにメンバーがジョインした頃に、より細かくお互いの価値観を揃え、チームとして目指したい姿を共有するために、今後数年を見据えた Mission/Vision をメンバーみんなで作ることにしました。プロジェクト全体のミッションを達成するためにチームとしてどのような貢献をするべきか (Mission)、また「組織・技術・採用・プロダクト」の様々な観点で、チームがどのような状態になっていたいか (Vision) を複数回ディスカッションを重ね、言語化し、将来像をメンバー間で共有しました。 フロントエンドチームのMission/Vision フロントエンドチームの分割 チームが立ち上がり数ヶ月経つと、様々な方面からチームにメンバーがアサインされるようになり、人員のボリューム感も出てきました。今後開発対象となるアプリケーションも複数あるため、チームを分割していく流れを作っていくことが自然な状況になってきました。チームをどういう単位で分割するか、また分割していく上で事前に考える必要がある様々な事柄を整理し、ガイドライン化しながら、チーム内外で認識合わせをしたりなどをしてきました。主に実施したことは以下のようなものです。 誰をどのチームにアサインするかの決定 メンバー間での役割分担 (マネジメント、プロジェクトリードなど) 複数チームの情報流通のためのドキュメントや会議体の整備 複数チームで行うコードレビューのためのガイドラインのアップデート 事前のコードベースのリファクタリング 共通コンポーネントの整理 現在は、ふたつのフロントエンドチームがお互いに連携しながら、アプリケーションを開発しています。 おわりに 以上が、入社の経緯や入社して以降の実際の仕事の内容でした。まだ入社して数ヶ月ではありますが、EMとして大きな裁量を持ち、自分自身が一番レバレッジを効かせられる場所を見つけ、自由に動いて良いということを技術責任者の @sunaot から言ってもらえています。そういう中で、徐々に転職した理由であるEMとしての「マネジメントの規模感」を大きくしていけるような視点も増えてきており、これから EM としてエス・エム・エスでプロダクト開発と事業に全力投球できることを非常にワクワクしながら過ごしています。 EMとしてこれから転職を考えている方は「どのように既存の開発組織に入っていくのが良いだろうか？」ということを悩まれると思いますが、今回の私のポストの内容が少しでも役に立つと嬉しいです。 最後になりますが、エス・エム・エスでは社会の課題解決を一緒にやっていただける様々なプロダクト開発の人材を募集しておりますので、気になった方は、ぜひ一緒によりプロダクト開発に取り組んでいきましょう！

こんにちは、SREをやっている @okazu_dm です。 経歴としては、サーバサイドエンジニアからセキュリティエンジニアを経て、エス・エム・エスではサービス横断で技術的な課題を解決しています。 基本的には組織に必要なことと自分ができることや、やりたいことが交わるポイントで仕事をしており、現在はSREとして働いています。 今回は、 過去の記事 とは違い、既存SREチームとは別に、介護事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトにスコープを絞って新しく立ち上げたSREチームとしての活動を紹介します。 リリース前のプロダクトのSREなので、一般的なSREの定義とは乖離する内容もある点ご留意ください。 リニューアルプロジェクトの概要 昨年末に出したフロントエンドの技術選定に関する記事 での説明と内容的な差分はありませんが、SREの業務の説明の前にこちらでも改めて触れておきます。 インターネットサービスとしては比較的長く稼働しているカイポケですが、ソフトウェアとして見ると、10年以上の時間の中で発生した様々な需要に応じる形で機能を継ぎ足されてきた大きなモノリシックアプリケーションです。 現在進行しているリニューアルプロジェクトは、カイポケのサービスの安定性やプロダクトの優位性を高めるべく、アーキテクチャレベルで見直しをかけ、部分ごとに移行する形でリリースしていく開発プロジェクトです。詳しくは以下のサイトをご覧ください。 careers.bm-sms.co.jp リニューアルプロジェクトのSREチームの担当範囲 開発途中という性質上、プロダクト全体の仕様やシステム構造のボラティリティも高く、SREの役割もプロダクトの状況に応じて変化しています。 その上でチームの大きな目標として「システムが安定して動いている状態」と「システムを早く世の中にリリースできる状態」を維持することを目指しています。 実務的には現在は以下のような役割を担っています。 インフラの設計&構築 内部的にサービスを分割する設計となるため、インフラについても各開発チームと分割統治する形をとっています。SREチームは全てのサービスが乗る基盤となるインフラを担当しています。 開発プロセスの大まかな整備 同じAWSアカウント上で複数チームが同時並列で開発を進めるために、アカウント全体の利用ルールやコスト管理などはSREチームの担当としています。 モニタリング基盤の整備 モニタリングに利用する外部SaaSの選定やシステム全体のアーキテクチャにどのようにモニタリングを組み込むかについてはSREチーム主導で検討し、構築を進めています 今後の開発の中でプロダクトの全体像が明確になっていくにつれて役割が増えることが予想されますが、現状は以上が主要な業務です。 直近の技術的トピック SREチームでは前述のように役割が流動的なため、日々の業務に伴い広くツールや外部サービスの技術検証や導入を行っているのですが、その中でもこの場に書きやすいものをピックアップしてご紹介します。 認証基盤の選定 リニューアルするに伴い認証部分についても検討が必要になりました。これについてはSREチームを含む一部のメンバーで最初にいくつかの候補を出し、最終的にAuth0を採用することに決めました。 大まかな方針として、「ユーザの認証情報を社内に持たない」点と「各開発チームが簡単に扱える(独自仕様が少なく直感的である)」点を重視して選定しました。 候補としたものと、調査した結果の短い所感をそれぞれ以下に書いていきます。 Google Identity Platform: 特に不足はなさそうだが、Auth0のほうが便利そうだった。 Amazon Cognito: 他のソリューションと比べて安上がりだが、仕様がやや独特で開発者全員がスムーズに理解できるかは不安があった。 Azure AD B2C: 安くて安定していそうだが、Azure自体を触ったことがなく使いたい機能が限定的であるのに対して未知の部分が多いため今回は見送り。 汎用的なモニタリングのパイプラインの実現 こちらでは、具体的にはOpenTelemetry関連ツール導入の実現可能性について検証し、実際に導入して分散システムのモニタリングの構築を進めている現況の紹介をします。 OpenTelemetry まず、OpenTelemetry(以下で一部otelと略していることもあります)について簡単に紹介します。 プロジェクトの公式サイト( https://opentelemetry.io/ )から引用したものを日本語訳して貼りますが、以下のように表現されています。 OpenTelemetryは、ツール、API、および SDK の集合です。テレメトリデータ(メトリクス、ログ、およびトレース) を計測、生成、収集、およびエクスポートし、ソフトウェアのパフォーマンスと動作の分析に役立てます。 これだけだと理解が難しいかと思うので、公式の図を踏まえつつもう少し具体的な紹介をします。 図は https://opentelemetry.io/docs/ より引用 図の中心にあるOTel Collector(以下単にCollectorと称する)が重要な役割を果たすツールです。これは、アプリケーションやインフラ(図の左側のコンポーネント群)から能動的または受動的にテレメトリデータを吸い上げ、Collectorがサポートするいくつかの形でエクスポートします。エクスポート先の例としては以下のようなものが存在します。( https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter より) Jaeger Zipkin Prometheus Datadog AWS X-Ray また、アプリケーション側が自動でリクエストや関数呼び出しなどの単位(上記の公式の文中にあるテレメトリデータの中で言うところのトレース)で処理の実行記録を残すために、アプリケーションに組み込む計測用ライブラリも開発されています。 これは使い方の一例ですが、例えばDatadogの従来の導入方法は、公式のライブラリをアプリケーションに組み込み、Datadog Agentを立ててDatadog Agent経由でDatadogにログやトレースを送る、という形でした。これのもう一つの選択肢として、ライブラリをDatadogのものからOpenTelemetry用のものに変更し、Dataodg Agentの代わりにCollectorを導入することで同様のことが実現できるようになりました。 このように、OpenTelemetryは従来のベンダが個々に作っていたモニタリングのパイプラインの一部を統一的な形で実現しています。 導入の背景 OpenTelemetryを導入すると何ができるのか、という点については前述したように、少なくとも現状の我々の利用範囲だと何か新しいことができるようなものではありません。 その上でOpenTelemetry導入に至った経緯について説明します。 まず、今回のプロダクトでは初期のリリースの規模などから見てもモニタリング基盤は外部のソリューションに任せた方が良いだろうという方針でDatadogを採用することにしました。 そして既に社内でOpenTelemetryを採用しているチームがあった点と、プロダクトが拡大した場合はDatadog以外のソリューションを検討することもあるだろうという将来的な可能性を見据えて、サービス間の乗り換えが比較的容易そうなOpenTelemetryを採用しました。 Datadog Agent vs OTel Collector Datadog AgentはOTLP(OpenTelemetryProtocol)のメッセージを受けることが可能なので、OpenTelemetryを採用する場合でも以下の図のようにCollectorを使うか、Datadog Agentを使うかの選択肢が発生します。 図は https://docs.datadoghq.com/opentelemetry/ より引用 それぞれ単純なアプリケーション1つの環境でsidecarとして動作させて、デプロイ時の落とし穴がないか、という点やコンピューティングリソースの消費量などをざっくり確認してみました。検証の結果、どちらも単体で使う分には大きな差はないように見受けられたため、中長期的にCollectorの柔軟性が活きることを期待して、Collectorを標準のツールとして採用しました。 また、計測用のライブラリについては未検証ですが、OpenTelemetryのものを使ったコンポーネントとDatadog製のものを使ったコンポーネントを同時に使った場合、分散トレーシングに問題が出るのではないかと考えています。 具体的には以下のように、DatadogとOpenTelemetryの間でトレースのIDのデータフォーマットが違う点が問題となることが予想されます。 https://docs.datadoghq.com/ja/tracing/other_telemetry/connect_logs_and_traces/opentelemetry/ なお、仕組みの話を補足するとトレースのID自体は計測用ライブラリ側で生成しており、OpenTelemetryのライブラリを利用した場合Datadog AgentやCollectorのDatadog ExporterがDatadogに送る前にフォーマットを変換しているようです。 例: Datadog Exporterでフォーマット変換していると思われる箇所 github.com 現状の懸念 ここまで、利便性や今後の可能性について様々な点から紹介してきましたが、一方で現状で本番投入するにあたっては以下のような懸念もあります。 Stableでない部分も多く、各種データの吸い上げからエクスポートの部分までをすべて公式が実装していた状態よりは今後の不安がある(どちらか片方の破壊的変更が今後起こった場合など) 現在、sidecarとしてAWS FireLens(fluentbit) *1 とCollectorを立てているが、関係する要素が増えると事故が起こる可能性もそれだけ増えるため可能であればもっと単純な形に置き換えたい(単純計算だとシステム内部に直列で繋がる要素が増えると事故率は上がる) まとめ この記事では、現在進行中のカイポケリニューアルプロジェクトのSREチームが担っている役割についての紹介をしました。 また、SREチーム内の直近の業務紹介の中で、OpenTelemetryの紹介とDatadog連携についての調査内容の一部分を要約して説明しました。 興味を持っていただけた方は、直近での転職意思の有無にかかわらず、ぜひカジュアル面談にお越しいただければと思います。 *1 : ECSタスクのログをS3に転送するために使用しています https://aws.amazon.com/jp/blogs/news/under-the-hood-firelens-for-amazon-ecs-tasks/