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

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

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

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

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

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

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

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

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

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

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

介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、荒巻です。 最近社内で、小さい技術ネタをなんでも発表できる会をはじめてみたので、その共有です。 ふだん社内では、まとまった技術情報は 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といった、新しめの要素技術を利用して、長期的に高い生産性を保てるようにチャレンジしているところです。このように充実した環境ですが、日々、開発対象業務が拡大していっており、まだまだ新しい仲間を必要としております。ご興味があればぜひ、下のリンクからカジュアル面談を検討していただければ幸いです。