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

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

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

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

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

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

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

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

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

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

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

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

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

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

はじめに こんにちは。エス・エム・エスのプロダクトデザイングループ マネージャーの酒井 ( @_atsushisakai ) です。 エス・エム・エスは、9月30日〜10月1日 に行われた Designship 2023 にゴールドスポンサーとして協賛をさせていただきました。この記事では、 Designship 2023 におけるエス・エム・エスとしての活動の振り返りと、メンバーによる参加レポートとなっております。 はじめてのデザインカンファレンス協賛 エス・エム・エスのデザイン組織としてはこのような大型カンファレンスへの協賛を行うのは初めてでした。今回は協賛にあたって、会場で流してもらえるCM動画やブースデザイン・配布するチラシデザインなど数々の制作も行いました。また、スポンサーセッションへの登壇なども行いましたので、それらを一挙にご紹介いたします。 CM動画「デザインの力で社会課題に挑む」 今回は会場内で流してもらえる15秒という短い時間の枠の中でしたが、多くのメンバーに参加してもらいながら、たくさんの想いを詰め込み、CM動画を完成させました。組織の中にいるメンバーとして見た時にも、ストレートでメッセージ性のある動画に仕上がっていると思います。会場内で流してもらうだけではもったいないので今後色々なところで利用していくことも想定しつつ、エンジニアやPOにも協力を依頼しながら制作しました。ぜひ、色々な方に見ていただきたいです。 スポンサーセッション、パネルディスカッション登壇 会期中には弊社デザイナーの登壇もありました。 Day 1 にはプロダクトデザイナーの戒能孝祐さんがスポンサーセッションへ、 Day 2 にはは同じくプロダクトデザイナーの蔡長宏さんがパネルディスカッションへの登壇を行いました。 戒能孝祐「介護事業にデザインでどう向き合うか」 戒能孝祐さんは2023年4月にエス・エム・エスに入社しました。エス・エム・エスのプロダクトデザイナーとしてのキャリアを選んだ背景や、入社後にどのような難題と向き合っているのか、また、現時点でプロダクトデザイナーである自分自身が組織の中でどのような役割認識を持っているかといったストーリーが語られており、今後のデザイナーとしてのキャリア作りのひとつのロールモデルとして興味を持っていただけたのではと思います。資料を見ていただくだけでも参考になる部分は多いと思いますので、ぜひご一読ください。 蔡長宏「デザインリサーチの重要性」 パネルディスカッションには、蔡長宏さんが参加し、エス・エム・エスにおけるデザインリサーチの重要性や知見を共有しながら、他社のデザイナーの皆さんとディスカッションをしました。リサーチの現場でどのような観点でユーザーを観察するか、観察して得られたインサイトをどのような形でプロダクトチームに持ち帰るかなど、各社のリアルな声を聞くことができ、とても興味深い内容でした。今回、長宏さんは、日本語での登壇が初めて(！)ということで大変緊張していたと言っていましたが、落ち着いてわかりやすく、丁寧に、参加者に向けて誠実に知見を共有してくれました。 ブースでのサービス紹介とアンケート企画 エス・エム・エスという会社のこと、デザイナーが扱っている介護事業者向け経営支援サービスの「カイポケ」のことについて、来場した皆様により深く知っていただくために、今回はブース出展も行いました。ブースでは社会問題に向き合うきっかけとして、簡単なアンケート企画も実施しました。 アンケート企画の集計結果 「 どんな未来を過ごしたい？ 」という問いに対して、以下のような4種類のカードを用意して、ブースに来ていただいた皆様に選んでもらい、パネルに貼り付けてもらう形で回答していただきました。このアンケートは、高齢社会で暮らす自分自身が将来どのような事を大切に感じながら暮らしたいか、ということを想像してもらいながら「介護」という世界にほんの少しだけでも触れていただくためのきっかけづくりとして実施しました。じっくり考えて回答してもらう方も多かったり、この「問い」と「カード形式での回答」を社内でも参考にしたいということで、パネルの写真を撮って帰ってくださる方もいたりなどしてとても嬉しかったです。 最終的にはこのような結果となり、パネルからはみ出してしまうぐらいの想像以上に多くの回答をいただくことができました。 集計結果としては、以下のようになりました。 合計回答数: 191件 「健康でさいごまで自立して」74件 「人との繋がりを大切に」70件 「大切な家族とさいごまで一緒に」40件 「慣れ親しんだ街で安心して」 7件 どの回答が正解というわけではないですし、豊かな暮らしを続けるためには全てが必要な要素かもしれません。とはいえ、特に「健康と自立した暮らし」「人との繋がり」を大事にしたいと感じる方が多かったようです。これを実現できる社会を作っていくために我々は様々な問題を解決し、乗り越えていかなければなりません。その課題解決のプロセスにおいて、「デザイン」はとても重要な役割・技術であると我々は考えています。 アンケートに回答いただいたみなさまには、今回のために特別に製作したノベルティ「カイポチくん おくすりケース」をお渡しさせていただきました。こちらも「かわいい！」とお渡しした方々に喜んでいただくことができて、デザイナーみんなで「作って良かった！」と盛り上がりました。 弊社デザイナーによるセッションの感想 さて、最後にカンファレンスに参加し、セッションを聴講したデザイナーの印象に残ったセッションとその感想をお届けします。 大坪 旅人 (クリエイティブデザイン) の感想 印象に残ったセッション: 望月 美憂さん「デザインプログラムマネージャーになって気づいた「これもデザイン」」 セッションの感想 デザインプログラムマネージャーという職種は自社にはないものの、現職でも役立つ考え方が多いセッションでした。 特に、 Design People という、デザインをデザイナーだけに留めず Notion や Figma を通して組織全体で普及させていく考え方が印象的です。 自分はマネージャーではなく、制作業務がメインのデザイナーですが、デザイナーと各部署でのコミュニケーションやドキュメント整備など、日々の取り組みから取り入れられる実践的な話しが聞けました。 組織全体で Design People としてふるまうために、まずはデザイナーがデザイナーという職種に固執しすぎることなく、組織間のコミュニケーションなどからデザインの考え方を取り入れていきたいと思います。 重留奈津美 (プロダクトデザイン) の感想 印象に残ったセッション: 舘山佳奈さん「存在しないものをデザインする・AIをデザインするという事」 ※引用元： https://design-ship.jp/2023/contents/session セッション終盤で語られていた未知のものに挑戦するマインドセットについて、「挑戦する」「前例はつくればいい」「プロセスを楽しむ」の三つを挙げられていましたが、どれも共感するものがありました。AI開発とは一見まったく違うように見えますが、カイポケリニューアルプロジェクトも不確実性の高さと合わせて非常に長期的なプロジェクトであることからくる、不安になるタイミングが多い点・不確かだからこそデザイナーが力を発揮すべきという点など、共通点は多く感じました。"挑戦"と最後に舘山さんが贈ってくれた"楽しむ"という言葉を忘れずに進みたいと思います。 戒能孝祐 (プロダクトデザイン) 印象に残ったセッション: 株式会社ビットキー デザイナー 中沢 大さん「PKのようなレビューをやめた」 レビューをしてくれるメンバーは本来仲間なはずなのに、自分のデザイン(ゴール)を突破しようとする敵のように扱ってしまっていませんか？という問いかけ。PKでなく、パスを繋いで一緒にゴールを狙いにいくようなレビューが理想。聞いたタイミングで、ちょうどそんなレビューをしちゃったかも、、と思って今回いちばん刺さる内容でした。インハウスのデザイナーだからこそ、チームの仲間を信頼していくことは大切にしたいと思えるスピーカーセッションでした。 さいごに 今回、協賛という形で Designship 2023 に関わることができて、デザイナーコミュニティの熱量の高さ、デザイナーが抱えている解決すべき課題の深さと幅広さを改めて実感することができました。また、エス・エム・エスのデザイナー目線では、部署の垣根を越えてたくさんの制作物を共同で作り上げたことで、チームとしての帰属意識・目的意識を統一することができたりなど社内向けの観点としても、とても良い経験となりました。 今後も、エス・エム・エスのデザイン組織として、もっともっとコミュニティに知見を還元したり、他社のデザイナーの皆さんとも繋がりを積極的に作っていきたいと考えています。 さいごに、ぜひ、エス・エム・エスのデザイン組織にご興味を持っていただけたのであれば、ぜひ採用情報もご覧いただけると嬉しいです。 r-kaipoke.bm-sms.co.jp

この記事は 株式会社エス・エム・エス Advent Calendar 2023 の11日目の記事です。 無いに越した事はありませんが、サービスを長い間運用しているとどうしてもシステム障害対応をやらなければいけないタイミングがあります。この記事では、小規模なアラート対応から数日間に渡るチーム横断での大規模障害までいくつのシステム障害対応に関わる中で実際に私が行ってきた事を 11 個紹介してみようと思います。 前置きとして、現在私が所属するチームはほぼ100%フルリモートで開発を行っており、それを前提とした内容になっています。 1. 専用のコミュニケーションスペースを作る 2. 役割分担をする 3. 積極的に音声通話でやりとりする 4. 情報整理用のダッシュボードを作る 5. 専用のカンバンを作る 6. 情報同期のための定時ミーティングを設ける 7. 通常業務を進めるメンバーを残す 8. メトリクスのスナップショットを残しておく 9. 異なるメトリクスを同じ時系列で並べる 10. 他のチームにも相談してみる 11. 意識して休憩を取る 最後に 関連資料 1. 専用のコミュニケーションスペースを作る まず、障害対応モードに入ったほうが良いと判断したタイミングで誰でも良いので専用の Slack チャンネルを作ります。これにより障害対応の情報を一つのチャンネルに集約して、普段チームが利用しているチャンネル上で障害対応の情報がノイズとならない様にします。関連する情報へのリンクは slack チャンネルの関連ページや canvas に記載しておきチャンネルから辿れる様にしておくと便利です。 その後、チャンネルを作ったらすぐにチャンネル上で huddle を立ち上げて関係者を呼び寄せ、障害対応の情報収集や役割分担を行います。 2. 役割分担をする 意思決定を迅速に行うために、インシデントコマンダーを頂上とした階層構造の組織体制を作ります。 指揮官(インシデントコマンダー) -- 全体の指揮を取り、他の役割を動かすための意思決定を行う 外部連絡役 -- カスタマーサポートやリスクマネジメントの部署とやりとりをし、チーム外とのコミュニケーション窓口となってもらう。普段からそういった部署とやりとりをしてもらっているメンバーに担当してもらう場合が多い。 観測・記録役 -- 原因調査・復旧担当や外部連絡役から入ってくる情報をまとめて、皆に伝えやすい形にする。インシデントコマンダーである自身が兼任する場合も多い。 原因調査・復旧担当 -- サーバーのログやメトリクスの調査を行い原因調査を行う。ほとんどの場合技術者が担当する。 場合によってはこれら以外にも現象の再現を試してもらう役割を作るなど臨機応変に対応します。いずれの役割を決める際も、コミュニケーションが混線してしまわない様に役割に対してまとめ役を必ず1名任命して、基本的にインシデントコマンダーはそのまとめ役とコミュニケーションを行う様にします。 なお、私の所属するチームはスクラムチームとして活動しているため通常時はトップダウンで意思決定を行う事はほぼありませんが、障害対応の際は例外的にこの様な体制に切り替えています。 3. 積極的に音声通話でやりとりする 障害対応では不確定な判断材料でリリース内容のロールバック、サービス停止、サーバースペック増強等の難しい判断を迅速に行う必要があります。このためコミュニケーション速度が速く、微妙なニュアンスを把握しやすい音声通話でのやりとりを積極的に使って作業を行います。特に対応初期はメンバーが揃わず情報収集もしづらいため、しばらく huddle を立ち上げっぱなしにしておいて状況の変化があった際にすぐに報告したり、何かを確認する際に声をかけやすい状況を作ります。 注意点としては、あまり多くの参加者が障害対応の本部機能を持った音声通話に入ってしまうと本部機能のノイズとなってしまう事があるため、役割分担が済み原因調査が動き始めたタイミングでそれぞれの役割ごとに音声通話を分けてもらう様気をつけています。 4. 情報整理用のダッシュボードを作る 障害対応時の情報整理は Notion 等のドキュメント管理ツールより miro の様なオンラインホワイトボードをダッシュボードとして使う様にしています。 ドキュメント管理ツールはシーケンシャルに構造化された情報を扱うのには向いていますが、複雑な関連性を表す表現力はありません。 オンラインホワイトボードツールであれば位置関係が離れている情報もドラッグアンドドロップですぐに移動できますし、何より縦横の二次元で情報を表現できます。更に位置関係を変えずに線を引いたり要素を囲ったりしてあげることで柔軟に情報の関連性や構造を表す事も可能です。複雑な判断要素が絡む障害対応ではこういった点が情報整理にとても役に立ちます。 5. 専用のカンバンを作る 状況が混乱していると記憶や認識のずれが発生しやすくタスク状態があやふやになる場合が多いです。これを避けるために障害対応専用のカンバンを作ります。私は miro の カンバン 機能を使い、標準のカラムに Backlog というカラムを追加して Backlog (検討中のもの) To do (実施が決ったもの) In Progress (対応中) Done (完了) というカラムがある状態にしています。今後進めるタスクの提案はいったん Backlog に入れて、対応する事が決まったものは To do へ、実際に実施中のものは In Progress へ移動して、状況が変わったら Done へ移動したり Backlog に戻したりといった運用です。 miro のカンバンは担当者を設定したり期日を決めたりすることも可能ですし、ホワイトボード上の他の情報から矢印を引っ張って関連付けを行う事ができるため GitHub Projects や Jira 等のカンバン専用のツールよりも柔軟な使い方ができます。障害対応では、この様にラフに使えるタスク管理方法のほうが情報を整理しやすいです。 6. 情報同期のための定時ミーティングを設ける 状況に応じてだいたい１〜２時間ごとに情報同期のための定時ミーティングを設けます。このミーティングでは 現在の状況に合わせてカンバンのアップデート 新たに発見した情報の共有 次に実施・中止するタスクの選定と担当決め を行っています。このミーティングは不確定要素の多い状況への適応とその対応を行うためのリズムを作ることを目的として、スクラムのデイリースクラムとプランニングをとても短い間隔で行うイメージでやっています。 7. 通常業務を進めるメンバーを残す 障害が発生すると不安から「全員で障害対応を行おう！」という気持ちになってしまう事があります。しかし、障害の内容によってはその原因調査を行えるメンバーが限られていたり、障害対応以上に重要な通常業務が存在する場合もあります。必要以上に障害対応への人員投下をするのでは無く、障害対応に入ってもらう必要があるメンバーを明確にしたうえで「〇〇さんは通常業務をお願いします」と、障害対応に入らなくて良いメンバーが明確になる様にしています。 8. メトリクスのスナップショットを残しておく メトリクスも種類によって保存期間や時間経過で情報の粒度が粗くなってしまい、障害発生当時のメトリクスが後から再現できなくなってしまう事があります。これを避けるために、気がついたタイミングで必ずメトリクスのスナップショットをスクリーンショットで残し miro に貼り付けておく様にしています。この際グラフがなるべく細かい単位で描画される様にしておくのもポイントです。 9. 異なるメトリクスを同じ時系列で並べる 障害発生時の状況把握を行う際はサーバー負荷やエラーレート、お問い合わせ発生日時等といった様々な情報の関係性を把握する必要があります。これを行うには同一時系列上に並列で異なるプラットフォームで取得したメトリクスを並べるのが効果的です。 ここで活用できるのが 8 で残しておいたスクリーンショットです。miro 上でx軸の時間を他のスクリーンショットのx軸の位置と合わせることで AWS 上のメトリクスや Datadog , Google Analytics といったプラットフォームの垣根を超えて同じタイミングで同時に変化が起こっているという状況が把握しやすくなります。miro であればグラフ上の気になる部分に注釈を付けたりする事も簡単にできますし、複数のスクリーンショットを繋げる事でブラウザ上では描画が難しい、長時間に渡るグラフを表現する事も可能です。 10. 他のチームにも相談してみる 障害対応にあたっているチームで原因や対策方法が見つからず解決が難しいと感じた場合、他のチームにも何か気がついた点が無いか相談してみます。複数のサブシステムが一つの共有リソースを使っている様なサービスの場合、特定のサブシステムでのみ発生していると考えられていた問題が実は別のサブシステムの影響によって発生していたり、共有リソースの問題がたまたまそのサブシステムに影響を与えていたという事もあり得ますし、他のチームメンバーが持っている専門知識によって意外な解決策が見つかる可能性もあります。 緊急事態なので、頼れる物は貪欲に頼るのが吉です。 11. 意識して休憩を取る 障害対応は場合によっては深夜作業や休日作業が発生してしまい体力的にハードなものです。この状態が続いてしまうと判断力が低下し、通常業務では行わない作業をやっている事も相まって不適切な情報を共有してしまったり、オペレーションミスでデータを削除してしまったりといった二次災害 1 を招いてしまう事があります。これを避けるために、意識して休憩を入れる様にします。 打ち合わせや議論が長くなる様であれば1時間ごとに小休憩を挟み、できるだけ昼休憩は通常と同じ様に設け、日が変わる前に一旦その日の対応を終え翌日再開できる様な動きができると理想です。当然それが難しい状況もあるのですが、その場合はシフトを組むなどして負荷が集中してしまわない様に配慮します。 最後に この記事を書くために当時の slack チャンネルを見ていると大変だった記憶が蘇ってきました。システム開発に関わる皆さんが、年末年始は何も起きず無事な年越しができる事を祈っています。 最後に、私が障害対応をするにあたって参考にしている資料を記載しておきます。 (筆者: プロダクト開発部桐生) 関連資料 今日からできる。初めての障害対応ガイド | DevelopersIO (dev.classmethod.jp) インシデント指揮官トレーニングの手引き | Yakst (yakst.com) Google - Site Reliability Engineering (sre.google) 重大事故の時にどうするか？｜miyasaka (note.com) -- ヤフー株式会社(現LINEヤフー株式会社)の元社長宮坂さんによる記事。 (PDF) National Incident Management System - Incident Command System (ICS) | FEMA.gov (www.fema.gov) -- アメリカ合衆国連邦緊急事態管理庁の資料。 Google SRE の資料中でもこのシステムが参照されており、インシデントコマンダーという役割を理解する際に Incident Command System (ICS) の章を翻訳しながら読みました。 疲労が原因によるものでは無いですが、ちょうど最近クラスメソッドさんでもクライアントのインシデント対応にあたって実施した作業でオペレーションミスによる障害が発生していました。 2023年12月5日に発生した複数AWSアカウントが操作不能となった障害について | クラスメソッド株式会社 (classmethod.jp) ↩

はじめに この記事は 株式会社エス・エム・エス Advent Calendar 2023 の 10 日目の記事です。 カイポケリニューアルプロジェクトでエンジニアリングマネージャーをしている @hotpepsi です。 フロントエンドのチームが本格的に立ち上がってから一年ほど経過しました。現在では二つのフロントエンドチームが日々活発に開発しており、多くの時間は、アプリケーションコードを書いたり、より良い仕様を議論したりすることに費やしています。並行して、コンポーネント共通で発生する問題を解消したり、開発者体験や生産性を向上させる取り組みも数多く行ってきました。 今回は一年分のまとめとして、アプリケーション固有でない様々な取り組みについて紹介したいと思います。 こんな感じのスクリプト で一年分のフロントエンド共通の pull request の title と description を markdown で取得して、その中から 100 個をピックアップしました。カテゴリごとにおおよそ時系列に並んでいます。両方のカテゴリにまたがるものは関連性の高そうな方に分類しました。 利用しているフレームワークやコンポーネント 前提として、カイポケリニューアルプロジェクトのフロントエンドチームでは、以下のフレームワークやコンポーネントを利用しています。この構成になった経緯は「 大規模 SaaS 「カイポケ」の未来を支えるフロントエンドの技術選定 」にありますので、ぜひご一読ください。 言語: TypeScript UI framework: Next.js , Chakra UI linting: ESlint GraphQL client: Apollo Client state management: Recoil form: React Hook Form schema validator: Zod component catalog: Storybook testing framework: Jest testing library: Testing Library visual regression testing: Chromatic やったこと 共通ガイドラインやファイル構成 コードレビューガイドラインを追加 はじめに、pull request のテンプレートや、大まかなレビュー方針を作成。 コーディングガイドラインを esa から移設 開発者のドキュメントは esa に書いているが、コーディングガイドラインは GitHub にあるほうがレビューや議論がしやすいので移設した。 テスト実装に関するガイドラインを追加 なぜテストを書くのかや、Storybook の活用方針などを記述。 モノレポに移行 プロジェクトチーム全体で議論した結果、モノレポに移行した。サービス毎の GitHub Actions の調整などは必要だったが、GraphQL のスキーマ管理などがしやすくなった。 Props に type を使うことにした Props に interface と type が混在していた。たいていは type で十分であり、意図しない拡張も防げるので、 type を使うことにした。そのあと、Props 以外でもなるべく type を使っていくことにした。 Node.js のバージョンを固定する CI や開発者の Node.js のバージョンを揃えることにした。 package.json での記述など、複数の手段を検討したが、ツールの選択肢などを考慮して .node-version で固定することにした。 ファイルコロケーション テストを tests/ 、ストーリーを stories/ に置いたりしていたが、関連するファイルが同じディレクトリにあるほうが見通しがよくなるので、コロケーションを採用した。 named export への移行 default export を行っているコードが少し存在したが、 なぜ default export を使うべきではないのか？ を参考にして、named export を利用することにした。既存のコードを修正して ESLint の import/no-default-export も追加した。 コードレビューガイドラインにコメント prefix を追記 question: や suggestion: や nits: など、コードレビューのコメント時に prefix をつけて意図を明確にすることを推奨することにした。 ポータルドキュメントを GitHub に設置 様々な場所にストック情報が増えてきたので、フロントエンドチームのミッション・ビジョン・チーム構成などへのリンクをポータルドキュメントとして一箇所にまとめた。 テストガイドラインに、推奨するテストの書き方を追加 Common mistakes with React Testing Library で紹介されているようなベストプラクティスを導入していて、ガイドラインにも反映した。 zod の import 方法の統一 import * as z from 'zod'; と import { z } from 'zod'; が混在していて、 公式ドキュメント などを参考に、後者に揃えた。 ファイル名の規則の lint ルール化 コンポーネントの名前やファイル名は PascalCase、ディレクトリ名を lowerCamelCase にしており、それを lint ルール化した。 eslint-config-airbnb-base を参考に lint 設定を見直し ソースコードの src ディレクトリへの移動 ソースコードが src/ 以下にあるほうが grep や lint に便利なので、移動した。 PropsWithChildren 利用の lint 化 子要素を受け取るコンポーネントは PropsWithChildren の利用を推奨している。 no-restricted-syntax の selector を使ったカスタムルールにより、 ReactNode の children を検出してエラーにするようにした。 Design System Chakra UIでDesign Systemを構築 アプリケーションコードからChakra UIのimportを禁止する 基本的な部品を全てデザインシステム上に構築できたので、アプリケーションから直接importしないようにした。 import/no-restricted-paths により検出。 Design SystemのStorybookの分離 Design SystemのStorybookをアプリケーションから分離した。 Storybook と Chromatic StorybookでHMRを有効化 GitHub Actions で Chromatic を実行する Chromaticによりvisual regression testを行うようにした。 Fakerの結果を固定する モックデータをFakerで生成しており、毎回異なるとChromaticの差分として検出されてしまうので、seed値を与えてデータを固定するようにした。(なおその後Fakerを利用するテストを削除したため使わなくなった) Chromatic導入に伴うレビューガイドラインの更新 pull requestレビュー時に、見た目の差分がある場合には確認して承認する必要があるので、ガイドラインを整備した。 mainブランチマージ後にStorybook をビルドする featureブランチだけでなく、 main ブランチにマージされたときにもChromaticでビルドするようにした。 main ブランチのStorybookはURLが固定されているので、他のチームに共有するときに使用している。 Chromaticで意図しない差分が出るStoryをUI Testの対象から除外する ポップアップなどのアニメーションを使用しているStoryで、変更がなくても差分として検出されてしまうケースがあり、 delay オプションでも解決できなかったので、 disableSnapshot オプションで除外した。 除外対象の一部修正 レンダリング終了より早くクリックしてしまっていたケースがあったのを修正。 Chromaticの TurboSnap を有効化し、スナップショットの数を減らした Chromaticの差分が生じたときにコメントする Chromaticで差分が検出されたとき、見逃してマージしてしまうことがあるので、差分が発生したというコメントをpull requestに追加するようにした。 create-or-update-comment を使用した。 フォントのプリロードについて調査 Chromaticの結果が不安定なコンポーネントがあり、 公式ドキュメント に従ってフォントのプリロードを試したが、改善しなかったため導入しなかった。 Storybook 7 へのアップデートとマイグレーション Chakra UIが対応したため、Storybook 7にアップデートした。これだけで1記事にできるくらいの更新があった。 CSF もバージョン3にした。 日付に依存したStoryの現在時刻を固定する 現在月を表示する画面で、月が変わるごとに差分が発生していたので、 mockdate により日付を固定した。 ChromaticでModalやPopoverのスナップショットを修正する play関数やアニメーションにより描画領域が変化する要素のスナップショットを安定して取得するために、画面サイズを指定した。 pull requestのマージにChromaticの結果の承認を必須にする Chromaticの差分があるとき、承認せずにマージしてしまうと、baselineが更新されないため他のpull requestでも差分として表示してしまう。そのため、差分があったらpull requestの必須のアクションの状態をpendingにして、承認するまでマージできないようにした。 Chromaticの結果のリンク先をChromaticの対象ビルドにする Chromaticの結果(UI Tests)がアプリのトップページにリンクしていて不便だった。pull requestのイベントの github.event.target_url にビルド毎のURLが入っているので、それに書き換えた。 main ブランチでの実行では autoAcceptChanges を有効にする Chromaticの結果の承認を必須にできたので、 autoAcceptChanges を設定して、baselineを更新するようにした。 PR時の reactDocgen の無効化 Chromaticを高速化するため、pull request作成時にStorybookの reactDocgen を無効化した。 各ページにStoryを書くことにした コンポーネントだけでなく、ページのStoryも書くことにした。Storyやテストも同じ場所におけるように、ビルド対象であるページのファイル名のsuffixを .page.tsx とした。 テスト JestやStorybookでGraphQLのクエリをテストするためMSWを導入 MSWのレスポンスに型制約を与える @graphql-codegen/typescript-msw を導入した。 mockの姓名を 名姓 から 姓名 にする fakerが生成する fullName が 名 姓 の順だが、逆にした。 Jestのタイムゾーンを東京に固定 console.error が出ているテストがあれば CI を失敗させる CI でtestとbuildを並列で実行する テスト実行時間の可視化 10秒以上かかっているテストを洗い出し、分割するかどうか検討した。 CIのJestのテストを高速化する --shard と --maxWorkers を与えて並列実行するようにした。 CI にキャッシュを設定して実行時間を速くする main ブランチにpushしてビルドするとき、キャッシュを保存するようにした。 Jestでwrapperを書かなくて済むようにする custom renderを定義し、 ApolloProvider や RecoilRoot など、共通で必要なwrapperをいちいち書かなくて済むようにした。 Jestを3回リトライするようにした テスト実行時間のばらつきがあり、タイムアウトして落ちるテストがあるので、リトライするようにした。 ローカル開発ではJestをリトライしないようにした fireEvent よりも userEvent の利用を優先する userEvent のほうが実際のユーザーの操作に近いため、推奨することにした。lintルールも追加した。 テストの実行時間が長くなる場合は fireEvent の利用を許可する旨をドキュメントに追加 テストのshardingの改善 テストの実行時間のばらつきがあるため、前回の実行時間を考慮するTestSequencerを実装し、shardingを改善した。 testing library v14対応 jest.useFakeTimersを使うと userEvent が終わらない問題の対処などを行った。 Larger Runnersの導入 テストの高速化のためLarger Runnersを導入した。Jestの maxWorkers は CPUコア数 - 1 にした。 mainブランチではテストを1shardで実行する CIのキャッシュの効率化のため、 main ブランチではテストを1shardで実行するようにした。 JestのエラーをSentryに送る Jestで失敗したテストを、テスト用のSentryプロジェクトに報告するようにした。 テストの日付を固定する 現在時刻から年齢を計算して表示する画面があり、 useFakeTimers により日付を固定した。 main ブランチのCIが失敗したらSlackに通知する 大量の文字入力のテストをclick/pasteに変更した 大量の文字入力をチェックする際に、 user.type ではテストに時間がかかるため、大量の文字を扱う場合は user.paste を利用するようにした。 lintとデプロイ失敗時にもSlackに通知する 共通コンポーネント 編集中にブラウザの戻るボタンをクリックした確認ダイアログを表示する ブラウザバックを監視するカスタムフックを実装した。 カレンダー編集UIのパフォーマンスチューニング データ量が多い複雑な編集画面のパフォーマンスを改善するため、オリジナルの仮想スクロールを実装した。 Kaipochiコンポーネントを追加 カイポケのマスコットキャラクターであるカイポチくんを追加した。なおカイポチくんの身長は133.4cm、体重はイチゴ3個分である。 ゼロ埋めの内部処理を標準組み込みメソッドに置換 標準メソッドに String.prototype.padStart があったのでゼロ埋めのメソッドを置き換えた。 電話番号の表示にハイフンを付ける libphonenumber-js を導入して、電話番号の表示にハイフンを付けた。バンドルサイズを軽くするため、 Customizing metadata の方法で日本のmetadataだけ使うようにした。 Feature Flagの導入 開発中の機能を限定された範囲で有効にするため、Feature Flagを導入した。 デバッグ用に日付を固定する 日付や時刻によって挙動が異なるページがあるため、デバッグ用のデータをlocalStorageに保存して、特定日時にできる機能を実装した。 Storybook用のFeature Flag判定を追加 Storybookのみで有効になるコンポーネントが実装できるようになった。 Next.js Dynamic Routing で 403 になった際のフォールバックを追加 SPAかつCloudFrontの環境で、Dynamic Routingを使ったページでリロードすると、プレースホルダ置換後のURLをアクセスしようとして403となっていた。CloudFront内で403を404にリダイレクトし、アプリケーションの404のハンドラ内で、routerで元のページに戻すようにした。 Dynamic Routingで存在しないページをリロードしたときに404にする 存在するページのみでリダイレクトしたいので、ビルド時にページの一覧を生成して、マッチしたページがあるときだけ遷移するようにした。 アプリヘッダの再レンダリングを抑える アプリのレイアウトをページコンポーネントの .getLayout に移し、再レンダリングを抑えるようにした。 フォーム 全角の英数字入力を許容する フォームのバリデーションのタイミング変更 onChangeでバリデーションを行うと、入力してすぐにエラーとなり体験が悪かったので、バリデーションのタイミングをonTouchedに変更した。 入力した文字の前後の空白・タブをtrimする GraphQL Apollo Server でモック用の GraphQL サーバーを起動 refetchQueriesに関するガイドラインを追記 リスト系のデータの再描画では refetchQueries を発行する必要があり、いくつかの注意点をガイドラインに追記した。 特定コンポーネントのGraphQLのqueryにprefixをつける GraphQLのクエリ名が衝突しないよう、prefixをつけることにした。 @graphql-eslint/naming-convention により判定。 near-operation-file-preset 設定 .graphql ファイルをコンポーネントと同じディレクトリに生成するために @graphql-codegen/near-operation-file-preset を導入した。 フロントエンドでのsupergraph生成をやめ、バックエンドのファイルを参照するように修正 GraphQLのsupergraphの生成方法を試行錯誤した結果、最終的にバックエンドで合成するようにした。フロントエンド側ではCIのタスクでコピーして、変更点を確認したり壊れていないかどうかを検証するようにした。 複数のmutationを呼んだ時も確実にrefetchするようにする @deprecated の扱いを warn にする APIに @deprecated をつけるタイミングをフロントエンド側で決められず、 error だとCIが失敗するので、 @graphql-eslint/no-deprecated のルールを warn に変更した。 GraphQL 利用側の推奨ルールを導入 @graphql-eslint/operations-recommended を導入した。 Renovate Renovateの導入 パッケージのアップデートのため Renovate をGitHubに導入した。 Next.js を Renovate から除外する Next.jsのバージョンアップは慎重に行いたいので、Renovateからは除外した。 Renovateが作成したpull requestではChromaticを実行しないようにする ライブラリのアップデートでは見た目が変わらなかったり、頻繁にrebaseされたりするため、botが作成したpull requestでは自動実行しないようにした。 ChromaticのCIを手動で回せるようにした 見た目を確認したいこともあるので、手動でも起動できるようにした。 特定のライブラリのアップデートでChromaticを実行する Renovateが作ったpull requestはChromaticを実行しないようにしたが、Storybookなど見た目に関わるライブラリのアップデートではChromaticを実行するようにした。 手作業で閉じたRenovateのpull requestが再度作られないようにする Renovateが chore(deps): をつけたりつけなかったりして閉じたものを再度作るケースがあったので、 semanticCommits を enabled にして常に付与されるようにした。 GitHub actions デプロイ通知を良い感じにする デプロイ成功時のアイコンを機嫌の良いカイポチくんに、失敗時にはしょんぼりしたカイポチくんにした。 pull requestを作るbotは自前のトークンを使う GITHUB_TOKEN でpull requestを作成するとCIなどのワークフローが起動しないため、自前のトークンに置き換えた。 ドキュメントだけ更新したときにコード系のactionsを起動しないようにする dev環境へのデプロイを直列にする main ブランチにマージするとdev環境にデプロイするようになっていて、近いタイミングでマージするとリソースが壊れることがあったため、直列にした。 その他 pre-commit フックに時間がかかるので pre-push でチェックする Huskyのpre-commitを導入していたが、小さい単位でコミットしようとすると地味にlint待ちが発生していた。基本的にVSCodeで整形＆lintされているので、pre-pushに変更した。 git pull時に package-lock.json に差分があれば npm install する Huskyのpost-mergeで実装。 フロントエンドのhooksを希望者のみで発動するようにする モノレポで開発しており、必要な開発者だけhuskyのhooksを動作させたかったが、 npm install を実行したバックエンドの開発者でも発動してしまっていた。 .env.local ファイルに特別な記述をしたときだけ発動するようにして解決した。 Hygen 導入 循環参照の調査と修正 eslint-plugin-import の no-cycle で検出した。ルールを追加するとlintの時間が大幅に増加し開発効率が著しく下がるため、発見のみに使用した。 pre-push の処理を並列化 https://github.com/open-cli-tools/concurrently を導入してpre-push の処理を並列化した。 バージョン番号の生成スクリプトを作成 commit hashなどをJSONファイルとして公開し、どのバージョンがデプロイされているのか取得できるようにした。 ローカルデータ追加用のE2Eテストの設定追加 Playwrightを導入して、ローカル開発環境でユーザー登録から初期データ投入までできるようにした。 おわりに フロントエンドの技術は年々進化して複雑化しており、モダンな開発を普通に実践しようとすると、多岐にわたる取り組みが必要になることが確認できました。今後も、中長期のプロダクトを想像しつつ、より良い技術や手法をバランス良く取り込んでいきたいと思っています。 なおエス・エム・エスでは、フロントエンドだけでなく、様々なポジションで開発メンバーを募集しています。興味を持った方は、ぜひお気軽にお声がけください。

この記事は株式会社エス・エム・エス Advent Calendar 2023の9日目の記事です。 qiita.com はじめに 株式会社エス・エム・エスでエンジニアリングマネージャーをしている @emfurupon777 です。今回は両利きの経営という考え方をエンジニア組織に適用していくにはー？を考えてみる。ということで、概要の紹介と弊社の今年の取り組みをあてはめてみようと思います。 ※記載内容に誤りなどがある場合は筆者のX(旧Twitter)宛に連絡をいただけると幸いです。 参照書籍 エンジニアにとっては馴染みが薄い書籍かもしれないのですが、こちらです。 str.toyokeizai.net 原文は "Lead and Disrupt: How to Solve the Innovator's Dilemma" で受ける印象が学術っぽいですが、日本語では表紙に『「二兎を追う」戦略が未来を切り拓く』と書いてある本です。どうでもいいことですが、一石二鳥が座右の銘の私にとっては、日本語のほうがちょっとテンションが上がる好きな表現です。 両利きの経営 企業が両利きであるということはどういうことなのでしょうか。 企業活動における両利きは、主に「探索(exploration)」と「深化(exploitation)」という活動が、バランスよく高い次元で取れていることを指す。 ざっとまとめてしまうと、探索とは既存の枠を超えて破壊的イノベーションを生む活動で、リーダーシップ課題ととらえることができる。一方で、深化とは主に既存事業において品質や性能、効率性などを向上させることによる漸進的イノベーションを生む活動で、マネージメント課題としてとらえることができる・・・のような定義と理解しました。 両者では行動原理やKPIが異なるということですね。確かにこれを一人、一組織が同時に実行に移すことは難しそうです。みなさんの所属している組織では、今両利きの経営が意識的に行われている状態でしょうか？ そもそも変化が速いなかで、両利きの経営が求められている企業は多い気がしますし、エンジニアとしてはキャリアの中で、0->1, 1->10, 10->100といったフェーズの違いを意識していることも多く、探索と深化の両方を経験してきた/経験しようとしていることが多いのではないでしょうか？(採用活動の中でも、最近は「今回はこの経験が得られる環境を探してます」と明言される方が多い印象です) また、本書のなかでリーダーも失敗を認めるといったことも挙げられているのですが、アジャイルを志向しているプロダクト開発のコンテキストでは当然だと思うので親和性も高そうです。 なんだかエンジニアにとっても、組織のあり方を定義していくのに良さそうな考え方ですね。スゴイ、やろう、すぐやろう、今やろう。・・・では実践していくのに何が重要なのでしょうか？ 浸透させるのは価値観ではなく行動 両利きの経営をしていくためには探索と深化をつなぐカルチャーが大事だと説かれています。そして、組織が価値観(VALUES)を持つことは良いが、コントロールしていくためにはその価値観に基づいて期待される行動(NORMS)を明確にせよと言います。 例えば、様々な国がカルチャーを持っていることは誰もが認めているが、国の文化は価値観ではなく、予想される行動でしょ？組織として浸透させられるのは行動だよね、ということのようです。 具体例として挙げられていたマイクロソフトの変革では10のこと全てを行う必要があった、とまとめられています。これは非常に参考になる事例だなと思います。 news.microsoft.com しかし、マイクロソフトのサイズでこれら全てを実行するというのは、かなり難易度が高そうですね・・・ エス・エム・エスでの取り組み さて、弊社の取り組みについてです。 弊社では今年、まずテックブログにおいてカルチャーを言語化してみました。 tech.bm-sms.co.jp とはいえこれだけでは浸透は期待できません。様々なところでMVV(Mission Vision Value)は言語化する取り組みをしているものの、その浸透に四苦八苦・・・というのを多く目にし、私自身も経験してきました。 そこで、価値観を体現する行動をとっている社員をピックアップして紹介し、さらに最近技術責任者の田辺からは学習することへの投資の観点で推奨する行動の一部について発信してもらいました。 tech.bm-sms.co.jp これらはもちろん社内の取り組みとして実践していくことも可能ではあったのですが、両利きの経営において例示されたマイクロソフトにおいて、参考になるコンテンツがオープンでリーチしやすい状況にあったことがやはり良い体験でした。そのため、弊社も外部にもオープンなテックブログという場での発信によって、弊社について知っていただくとともに、あわせて社内への浸透もはかっている面があります。 今後について 弊社は創業から新規事業の開発とその継続的成長が重なって発展してきている会社です。そのため、我々エンジニアリング組織がマーケットに向けて働くにあたって、常に変化をしながら両利きの経営を実践していくケイパビリティが必要だと私は考えています。そのために我々のカルチャーをより強くしていきたいです。 先日、『両利きの経営』著者オライリー教授の講演(JBPress社 第19回 DXフォーラム)をきいていたところ、強いカルチャーを持つ企業がとっている手段として下記のような5つが挙げられていました。 5 Levers for Managing Culture (the LEASH Model) Leader Actions Employee Involvement Aligned Rewards Stories, Symbols and Signals HR Alignment どれも掘り下げていくと取り組みがいのあるテーマですが、私も(失敗しながらも)継続的に挑み続けたいと思います。そして、これらについて社内の取り組みだけでは視野が狭くなりそうなので、同じようなことを考えているエンジニアリング組織の方はぜひ情報交換してみたいです。 おまけ 知っていることと行うことは同義ではないとして、F・スコット・フィッツジェラルド氏の言葉として下記の紹介されていました。 「頭の中で相反する二つの考えを同時に持ち、なおかつ、その機能を維持することができるかどうかが、第一級の知性を占う試金石となる」 第一級の知性であるかどうかは別にして、これを行っていますよ、と自信をもって言える組織でいられるといいなーと素朴に思いました。 そして、弊社に興味を持っていただけた方は、ぜひこちらのページものぞいてみてください！

この記事は、「株式会社エス・エム・エス Advent Calendar 2023」7日目の記事です。 qiita.com Webサービスが長期間運営されると、成長に伴い複雑なプロダクトコードが蓄積されます。このような長寿サービスは多くの人が関わってきたということでもあり、様々な思いや依頼のもとにプロダクトコードが少しずつ変わってきています。そんな長いサービスに対して手を加えるとき、関わってきたすべての人たちがコミュニケーションできる範囲内にいるとは限りません。そのため、いまあるプロダクトコードから当時の意図を汲み取り、手を加えるという場面は多く存在すると思います。 これらの場面に直面する話は多くあれど、実際にどのように読み進めていくかというのはあまり多くは語られていないと思っています。そこで今回は「過去携わった人が近くにおらず、GitHub上でバージョン管理されたコードを読み解きながら改修をする」というようなシチュエーションを想定して探り方と直し方のアプローチ例をご紹介できればと思います。 どのようにアプローチするか 今回は、以下のような改修の依頼を題材に、大きく3つのステップに分けて取り組み方の例をご紹介していきます。 『TOPページのリストアイテムの並べ順を更新日時が「更新日：2022-11-20」の形式になっているので、その値をもとに日付の降順に並べ替えてほしい』 1.変更箇所にあたりをつける まずは改修する機能とソースコードの位置に関してあたりをつけます。これは改修依頼の内容によってアプローチは変わりますが、一番直感的な追い方は「改修箇所のユニークな部分から特定する」というやり方がよいと思います。 たとえば今回ののような改修の話であれば、"更新日："という文字列を手がかりに探すということができます。もちろん扱っているフレームワークの構造などから「TOPページ」というところを手がかりに探すこともできるので、自身の持ち合わせている知識や利用しているフレームワークの特性を活かしてで特定していくのがよいと思います。 変更する場所がわかったら次は歴史を追っていく作業です。 2.GitHubのblameとhistoryの機能を利用して「何故行われたのか」を追う ソースコードを改修するときに「なぜ今の形になっているのか」というのを確認する作業が必要な場合が多いです。その時に役に立つのがblameです。blameは直訳すると「非難」という意味なので物騒な言葉ではあるのですが、GitHubでソースコードを探すときには大変有効に利用できます。 GitHubのblameの機能を利用すると、行単位に「いつ」「誰が」「どのコミットで」変更してくれたのかを可視化してくれます。 この機能を使うことにより、目星をつけた改修箇所のコミットを確認できるので差分を確認することができます。また、コミットがわかるので、コミットに紐づくPullRequestも確認することができます。PullRequestを見ることができればdescriptionを読むことができるので、そこから新しい情報を入手することができます。文章そのものも有益な情報ですが、JIRAやbacklogなどの別サイトで管理されている依頼情報を追うこともできたりするので、当時の背景理解を助けてくれます。 またhistoryの機能を使うとそのファイルが過去に行われてきた変更を確認することができます。commitによってはrevertしているなどで直前のコミットだけでは変更の真意まで読み解けないときがあるので、そのようなときにhistoryを使って過去のコミットを順を追っていくことで得られる知見もあります。 この過去の内容を追うときに念頭においたほうがいいのは「該当箇所にどんな変更があり、何故その変更が行われたか」です。例えば最初に挙げたリストアイテムの表示順を並べ替えたいという話であれば、何故最初に昇順で実装されていたのか、その後変更がされた形跡があるかというのは一度調べておくといいかと思います。これを調べることにより現在の担当者が知らなかった背景が見つかったりする場合もありますし、逆に当時何も考えて作られていないことがわかれば修正してしまってもなんの問題もないという裏付け材料になるので、調べておくことのメリットは大きいです。 3.前後比較ができる状態で改修をかける 変更箇所がわかり、修正する内容に関しても憂いがないことがわかったらあとは直すだけです。ただ直す際に気をつけなければいけないのは「関係ないところを変更してしまわない」ということです。 例えば今回の改修依頼の例でいくと、並び順は降順になったが、リスト表示するアイテムがおかしくなってしまう、などの事象が起きてはいけないので、その点に関して修正前後で問題がないかというところを確認する作業が必要です。 修正する箇所にテストコードがあり、修正した箇所以外に変更が加わっていないかということが検証できるのが一番良いのですが、歴史の長いコードベースの場合はちゃんとテストコードが用意されていないこともあります。そのため、予め「修正前後を確認できる方法」を用意しておいたほうがいいと思います。 修正前後を確認できる方法というのは、テストコードを書き足すということでも実現できます。もともの改修前の箇所に関してテストコードを書き足し、その後改修とワンセットでテストコードも書き換えるというやりかたです。こうすることにより元の仕様の理解も深まり、また未来コミットログを見た人がどういう振る舞い変化を期待して直したかというのもわかりやすくなります。 ただ、テストコードが継ぎ足すのが構造上難しい箇所もあると思います。その場合は一般的にマニュアルテストと呼ばれているようなテストケースを文章で書き起こし、それを実施するというのも方法の一つだと思います。その場合はPullRequestのdescriptionに行ったテストケースに関する情報があれば、未来の人に何をしたかを残すこともできます。 ここで大事なのは「修正したい場所と修正する場所に近いところがちゃんと壊れていないかを確認する工程を踏む」ということを意識づけてやるところなので、テストコードでもマニュアルテストでも確認作業を踏む、踏んだ足跡を残せるとよいかと思います。 過去を探ることで、足場を固めて改修する 歴史のあるプロダクトコードはビジネスの成長に合わせて無理をしていることもあります。そのようなプロダクトコードに手を入れるときに当時の背景を理解するということは改修の手助けになることがあります。過去を知るチームメンバーに色々と話を聞けるとよいのですが、もしそのようなメンバーがいない場合、GitHubでソースコードを使うことで断片的にでも情報を探ることができます。 また断片的に得られた情報から改修を行う際は、テストコードなどで足場を固めて改修をしていくとバグを生み出す確率を減らすことができます。下記のPullRequestでは今回のアプローチで紹介していたような探りを入れ、そこに対し既存実装にあわせたテストコード（RSpec）を追加、そのRSpecを元に既存実装から改修実装に切り替え、最終的に影響が他に伝搬してないかを確かめつつ改修しています。かなり複雑な箇所の改修でしたが、大きな不具合を出すことなく改修ができました。 これらのアプローチを無意識にやっている方が多い部分もあるとは思いますが、もしこの記事で少しでも学びや再発見があれば幸いです。 こちらの文章は直近 入社エントリ を書いた高田の提供でお送りしました、明日のアドベントカレンダーもお楽しみに！

この記事は 株式会社エス・エム・エス Advent Calendar 2023 の6日目の記事です。 エス・エム・エス BPR推進部 カスタマーデータチームの橘と申します。 私は「ナース人材バンク」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 今回は私の組織におけるデータエンジニアの役割を簡単にご紹介し、データ活用の推進のために進めている活動の1例として、データカタログの整備についてご紹介します！ データエンジニアとは そもそもデータエンジニアとはどういう役割でしょうか？ 一言でいうと、社内のデータ活用に携わるITエンジニアです。ビジネスの意思決定を決めるデータ活用の基盤として、データ分析基盤があります。そのデータ分析基盤はデータの収集、蓄積、加工、可視化、出力などの機能を持っています。また、データ分析基盤を活用するためのデータの整理、カタログ化、セキュリティの担保等も必要になってきます。これらの開発・運用に携わるのが私たちのチームにおけるデータエンジニアとなります。 私たちキャリア横断開発グループではGoogle Cloud を中心にデータ分析基盤を構築しております。以下の記事でもご紹介しておりますので、合わせてご覧ください。 キャリア事業におけるデータ活用 エス・エム・エスのキャリア事業のみに限定しても、「ナース人材バンク」や「カイゴジョブ」等の複数サービスを展開しており、非常にたくさんの種類のデータが、あちこちに存在します。 これらのデータを1つのデータストレージ、具体的にはGoogle Cloud のBigQuery に連携して、データを活用できるようにしています。 私たちは貯めたデータをもとに、マーケターからヒアリングした課題の解決に向けて、データの出力や可視化、分析を進めています。 とはいえ、単に条件を指定したデータの出力や単純な可視化等は、データエンジニアチームを介すことで実装完了までのリードタイムが生じたり、依頼内容と開発者の認識の祖語が発生したりする問題もあります。そのため、マーケター自らが収集したデータを探して、活用していくという、“データの民主化”に課題がありました。 キャリア事業というドメインのデータ分析基盤は、データメッシュという考え方における、“セルフサービス型データプラットフォーム”を目指してます。データエンジニアに依存せず、マーケター達が自律的にデータを取り扱えるようなデータ基盤を構築し、データカタログ、データマート、BIツール等の各ツールを活用して、データの分析を行う世界を目指しています。 今回はそのうちのデータカタログというプロダクトに焦点を当ててご紹介します。 データカタログの整備 前置きが長くなりましたが、データカタログについての話に入ります。 そもそもデータカタログとは何でしょうか？その名の通り、“データのカタログ”になります。データのメタデータ、ビジネス要件などをドキュメント化して、検索ができるカタログのことを指します。 私たちのデータ分析基盤では、目的に応じた大量のテーブルが存在し、各テーブルには大量の項目が存在しています。 セルフサービス型データプラットフォームは、こういった大量のデータを分析するにあたって、データを発見しやすく、アクセスしやすい環境でなくてはなりません。そのため、データ分析基盤の各データのメタデータをもとに、データカタログを作成する必要があります。 私達のデータ分析基盤(今回はGoogle Cloud のデータウェアハウス、BigQuery 内のデータに限定しています)におけるデータカタログの要件は以下としています。 分析を始めたい人がデータカタログにすぐにアクセスできる 各データセット、テーブル、項目の定義やビジネス要件が整理されている データカタログを検索できる メタデータの収集は自動化できる ビジネス要件を継続してメンテナンスできる これらの仕組みが一か所に集約され、データカタログを起点にデータへのアクセスが容易となっている 単純にメタデータの収集であれば、Google Cloud にも、 Data Catalog という製品があります。 しかし私たちは上記の要件を満たすために、Googleスプレッドシートで簡易的なものを作成して運用しています。 今回はそのGoogleスプレッドシートで作成したデータカタログついてご紹介します。 実際のデータカタログ こちらが実際のGoogleスプレッドシート上のデータカタログになります。 実際にデータ一覧をお見せすることはできないので、Cloud Loggingからエクスポートしている、App Engineのnginxのリクエストをテストデータとして表示しています。（テストデータのため、論理名や説明は省略してます） シートの構造は以下の通りです。 README データカタログの使い方を記載したシートです。 データセット一覧 分析用プロジェクト内の、BigQuery データセットの一覧や説明を記載したシートです。 テーブル一覧 分析用プロジェクト内の、BigQuery テーブル（Viewやテーブル関数なども含む）の一覧や説明を記載したシートです。 利用者は主にこのシートを参照します。テーブル一覧のみでは分析用途として事足りないので、Google Apps Scriptを用いて、上記キャプチャのように、選択中のセルのテーブルで、項目一覧シートの情報を検索し、結果をモーダルで表示する機能を用意しています。テーブルの情報、各項目の情報を一覧で見れたり、SQLやテーブルスキーマファイルの自動生成などといった機能も用意しています。 項目一覧 分析用プロジェクト内の、BigQuery テーブル全ての項目の一覧や説明を記載したシートです。 データカタログの更新方法 データカタログの更新方法は、 BigQuery のメタデータ取得による自動更新 データエンジニアによるビジネス要件の手動入力 の2パターンがあります。 これらのアーキテクチャを簡単にまとめますと以下のようになります。 BigQuery のメタデータ取得による自動更新 項目名、型、更新日時や件数などの情報はBigQuery のメタデータにあるため、SQLで取得することができます。 以下のようなSQLを実行し、自分たちのデータカタログの各シートに出力できる形に整形して、日次のバッチ処理でスプレッドシートに自動出力される仕組みです。 1.BigQuery データセット一覧を取得 SELECT * FROM INFORMATION_SCHEMA.SCHEMATA 2.取得したデータセット毎に、BigQuery テーブル一覧とメタデータを取得(それぞれのクエリで取得できる情報は異なります) SELECT * FROM [データセットID].INFORMATION_SCHEMA.TABLES SELECT * FROM [データセットID].__TABLES__ 3.取得したデータセット毎に、BigQuery の全テーブルの項目一覧と、メタデータを取得(それぞれのクエリで取得できる情報は異なります) SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMNS SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMN_FIELD_PATHS データエンジニアによるビジネス要件の手動入力 テーブルや各項目の説明（集計項目であれば集計ロジックなど）、更新頻度など、メタデータで取得できない情報については、テーブルを実装したデータエンジニアが手動で入力する必要があります。また、不足している情報があればスプレッドシートの編集権限を持つメンバーが更新できるので、入力インターフェースとして準備が簡単だったGoogleスプレッドシートを採用しています。 とはいえ、メタデータ取得は自動的にされているものの、ビジネス要件が入力されておらず、カタログとして情報が不足してしまうことも多々あります。そのため、定期的にデータカタログ上で情報が不足している箇所を検知して、Slackに通知し、データエンジニアに入力を促すなどしています。データを収集してテーブルとして公開するまでが仕事ではなく、実際に分析するユーザーがデータにアクセスしやすい環境づくりを心掛けています。 まとめ 以上、私たちのチームにおけるデータカタログについてご紹介しました。 実際に分析をするマーケターや、開発担当のメンバーからも、 「BigQueryのデータを見るときはまずこのデータカタログから見てます！」 「テーブルをリリースすると項目定義が自動で連携されるから便利！」 といった声が上がっています。 一方で、利用範囲が広がるにつれ、データのオーナー情報、集計ロジックを直接見れるGitHubのURLも載せてほしいなど、データカタログとして管理していきたいビジネス要件が増えてきて対応しきれない部分もあるのが課題としてあります。 社内のデータの活用を推進する立場として、こういったドキュメントの整備も怠ることなく進めて行きたいと考えております。 エス・エム・エスは新しいメンバーを募集しています。 特に私たちのチームでは、データ分析・データ活用の推進に関わるデータエンジニアを募集しています。 今回紹介したデータカタログは、データエンジニアの仕事のほんの一例のご紹介にすぎません。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。 エス・エム・エス - エンジニア採用情報 データエンジニア（キャリア事業） / 株式会社エス・エム・エス