はじめに はじめまして。2022年4月より、介護事業者向け経営支援サービス「カイポケ」のプロダクトマネージャー（以下PdM）としてエス・エム・エスに参画した小場（コバ）です。 今回は、前職で基幹系パッケージ製品開発に携わっていた私が、どのような経緯でカイポケのPdMになったかについてお話ししていこうと思います。 よろしくお願い致します。 前職の仕事について 前職では自社開発の人事統合パッケージ製品を企画する立場にあり、世間で「基幹系エンジニア」と称されるSEをしていました。 扱っていた人事統合パッケージには、人事管理（従業員の個人情報管理、配属及び移動処理、採用・退職処理、考課など）、勤怠管理（残業時間や有給取得状況の管理、シフトの作成など）、給与計算（月々の給与・賞与計算、年末調整、源泉徴収票の発行、所得税や控除項目の計算など）の機能があり、人事部や労務・給与担当者、採用担当者など多彩なステークホルダーの要望に応える必要がある製品でした。 元々は開発エンジニアであったことから、次期製品バージョンに入れ込む新機能や頻繁に発生する法改正にプロダクトとしてどのように対応・設計-実装していくかについて考える、所謂「製品企画」をメインミッションとしていました。 新しいチャレンジ（企画）をする際には、事前にその効果を検証する作業や、オフショアを含めた開発チーム内への情報連携、上司や決裁権者へ開発内容を説明する必要もあったため、必然的にチーム内で手薄だった領域のキャッチアップを行う担当になることが多くありました。 主な例としては「UI改善を行う上で必要となるコンセプトの立案」や「DBのパフォーマンスチューニング」、「AIを用いた機能の開発」、「オフショア先の管理」など多種多様なもので、製品企画と言いつつも新しいことを始める上で要員や技術スキルの調達が追いつかなかった時にはエンジニアやプログラマーとしての仕事もこなす「何でも屋（何でもやらざるを得ない屋）」のポジションにいました。 製品企画というファジーなポジションで幅広く、様々な経験をさせてもらった点は前職に感謝しております。 転職を考えたキッカケと転職の方針 30代後半に差し掛かり自身の今後のキャリアを考えた際に、以下の点に不安を感じるようになったことがキッカケです。 各々の要点に対して、お世話になった転職エージェントの方と共に方針を立て転職活動を進めました。 ①ITに関わる人間としてオンプレミスのパッケージ開発経験のみで今後大丈夫か？ SaaS 型の製品や SaaS を用いたビジネスに携わる経験をすると共に、 SaaS におけるシステムのライフサイクルについて理解を深めたいと感じました。好きか嫌いか/合う合わないはやってから考えることしました。 → SaaS 型の製品・ビジネスを展開している企業を転職先のターゲットとして見据えるようにしました。 ②良くも悪くも『何でも屋』過ぎてアピールポイントが分かりにくい。 中途採用の面接において、ほぼ100%質問される自身の長所について、スペシャリストよりもゼネラリストよりのスキルセットになっていることに気づかされました。 →現状の全方位型のスキルセットを生かしつつ、重心をずらすことで特徴を出していく方向で職種を探すようにしました。 また、製品に対してより広い範囲でオーナーシップを持って活動できる職種を考慮したところ、 PdM が一番理想としている形に近い立ち位置の職種であると感じるようになりました。 ③前職の「基幹系」というビジネスドメイン色が強かったためか、同業種からのオファーが非常に多かった。 基幹系システムを取り扱う企業からドメイン知識をベースとした転職オファーが圧倒的に多く、仮にそれらの企業に転職したとしても環境や取り扱う製品を変えるだけの転職になる可能性が高い（仕事としてのミッション自体は前職と代り映えしない）と感じていました。 →基幹系以外のビジネスドメインの企業の中で、基幹系機能の知識を活かせる業務特化型ビジネス（メインの機能の他に、事業を運営する上で必要となる業務を行う基幹系機能が携わっている製品）を展開している企業をターゲットとすることとしました。 この大まかな3方針を軸として、より社会的に課題感がある領域に対して挑戦することができる企業を探すことにしました。 エス・エム・エス/カイポケとの出会い そんな中、転職エージェントから紹介された企業の1つがエス・エム・エスでした。 エス・エム・エスは少子高齢化が進む日本において、「介護事業者の経営改善とサービス品質の向上に貢献する」ことをミッションとして掲げており、「カイポケ」という SaaS プロダクトのPdM職が上記の①、②の方針を満たしていました。 同時に世界で一番少子高齢化が進む日本で、この社会課題の解決に取り組むことは仕事をする上で意義のあるものだと感じました。 カイポケは「ケアプラン作成・連携」、「実施した介護の予実管理」、「予実を基にした保険料請求の支援」機能といった介護事業者の業務を支援するプロダクトです。 また、カイポケは上記の介護事業特有の業務に関わる機能以外に、介護事業者が事業を運営するために必要となる機能（世に言うところのERPのような機能）を多数サポートしており、前職で関わっていた「給与計算」、「勤怠管理」、「シフト作成」等の経験や知識がカイポケであれば活かせるかもしれないと感じたことが決め手となりました。（上記の③の方針に該当） 現在の業務について/カイポケの開発現場について 現在は（当初の転職の方針通り）カイポケのPdM職として、給与計算や勤怠管理といった「介護以外の機能」について、今後のカイポケのあるべき姿を考え-実現する役割を担当しています。 入社の段階では肝心な介護に関する知識が0の状態であったため、オンボーディングや社内に在籍している有識者に意見を求めることで知識を補完してプロダクトを形にしていっています。 例えば、介護事業者の給与計算において、介護職員に対して介護報酬を加算して支給する制度（この制度の事を「処遇改善加算」と言う）があり、持ち合わせていた給与・労務管理の知識に介護ドメイン特有の知識を組み合わせることで、より理解が深まるという経験をすることができました。 また、入社当初はテレワーク主体でのオンボーディングに不安を感じておりましたが、上記のようなフォローもあり、違和感なく業務に入っていくことが出来たという印象です。 カイポケの開発現場の雰囲気については、転職者が多く在籍しており、私のように前職のビジネスドメインが介護ではないというメンバーの方が多いという印象です。 逆に様々なバックグラウンドを持つメンバーが揃っていることによって発生しているシナジー効果を感じると共に、多様なタイプ/働き方のスタンスのメンバーを受け入れることができるエス・エム・エスの懐の深さを感じています。 最後に 私のような基幹系エンジニア出身であっても、「介護の知識」をキャッチアップしつつ、「介護以外の領域」で手腕を振るう事ができる点は、介護事業者に対して包括的に機能提供をしているカイポケならではの魅力であると感じています。 「介護」という言葉を意識せずに、話を聞いてみると「畑違いの経験」を活かすことができる可能性や共通点など、思わぬ発見があるかもしれません。 この度は基幹系エンジニア→カイポケのPdMの話ではございましたが、現在弊社ではPdM、エンジニア、EMなどプロダクト関連職種を広く積極採用中です。 もし弊社に興味をもっていただけましたら、ぜひカジュアル面談にてコンタクトをとって頂ければと思います。 最後まで読んでいただいて、ありがとうございました。

エス・エム・エス テックブログ運営の小林と樽本です。 前回の田辺さんインタビュー に続いて、「エス・エム・エス社員に訊いてみた」第二弾は弊社の技術推進グループ長である光宗さん( @mitz )です。 光宗朋宏 Tomohiro Mitsumune -技術推進グループ グループ長 Ex. DeNA Q1.現在所属している技術推進グループの具体的な業務内容を教えてください 本日はよろしくお願いいたします。一つ目の質問として、光宗さんが現在所属している技術推進グループでは具体的にどんなことをやっているか教えてください。 現在技術推進グループというグループに所属しています。グループには四人いて、全員がバラバラの業務やタスクを行なっている状況ですね。各メンバーごとに得意な領域、例えばインフラとか、アプリケーションとかを持っていて、様々な角度から依頼が技術推進グループに来ます。依頼の内容は、各種サービスの改善や業務効率化、解決のレベルが技術的に高い課題などがあり、R&D(Research & Development)的な側面を持っています。 具体的な最近の業務だと、ハピすむというサービスのAWS寄りのインフラ周りのSRE業務を1年半くらいやっているメンバーがいたり、僕が手伝っているものだと、カイポケリニューアルのアーキテクトチーム(技術的方向性、技術選定)の話し合いに参加して知見を出し合っています。このプロダクトは、数人単位の複数チームがバラバラに仕事をしているので、ルール決めだったり方向性だったりを落穂拾い的に決めています。その中でも僕はAWS、フロントエンド周りで活動しています。 過去の業務で言うと、一つのプロダクトの機能改善よりも、もっとインパクトのあることをすることが多く、例えばカイポケのオンプレからクラウド移行時に「そもそもどう進めていけばいいか」の検討から入るPM的なこともやっていました。 他にもプロダクトを限定せず、例えばMySQLのパフォーマンスがめっちゃ落ちた時はパフォーマンスチューニングをひたすらやっていたり、サービスにNew Relicを導入して改善ポイントを指摘したり、カイゴジョブのフルリニューアルをする際にプロダクトオーナーをしたり、社内で元々あった技術的負債が多すぎたサービスのフルリニューアルを手伝ったりしています。開発リソースが少ないところの技術アドバイザー的なことをやっていたりが多かったです。 (インタビュアーがたまたま中途面接の時に光宗さんに面接を担当してもらっていたので) 入社から2年経ちましたが、社内事情を知ってから光宗さんの話を聞くと、かなり横断的に業務を行なってらっしゃるのが鮮明に想像できますね…。面接で初めてお会いした当時からフルスタックエンジニアのイメージが強いです。 開発に関係ないところで呼ばれたりもしますからね。バックオフィスとか、法務やコンプライアンスを担当する部署とか…。 どういった背景でそういう場所から呼ばれるのでしょうか？ 例えば法務やコンプライアンスを担当する部署の話だと、グループ長の方から「こういうことをやりたいんだけど、エンジニア目線でどうだろうか」っていう感じでお話を受けて、「実際に手伝ってくれ」と相談された流れのまま手伝うことが多いです。インフラ周りの話が多いですね。 実際に手を動かしたものの話だと、数十を超えるサービスのプライバシーポリシーやサイト規約みたいなものって、元々はワードファイルで個別管理されていたのですが、それをGCP上で管理できるような社内システムを作ったりもしました。 バックオフィス系で軽いところだと、外部のクラウドソーシングのリソース管理をスプレッドシートでやっていたものを、スプレッドシートのイベントフッキングを使用して社内のチャットツールに連携する仕組みを作って業務効率化したりしていました。 一般的なエンジニアよりもかなり広いことをやられているのですね。全社的に困っているところにスポットで入って、改善していくみたいな…。 そうですね。エス・エム・エスに入社する前はエンジニア一人、デザイナー一人、PM一人みたいな状況で仕事をすることが多かったので、「なんでも自分でやらざるを得ない」みたいな経験を積んできましたこともありますし。 技術推進グループのメンバーも光宗さんみたいなご経験を積んでこられた方が多いのでしょうか？ それぞれキャリアパスは違いますが、幅広く経験して来られた方が多いです。インフラに強いメンバーだと、toC、toBの大きな企業にいた方とか。 なるほど、異なったキャリアパスを歩みつつも、幅広い経験を持った方が多いと。 メンバーは各自バラバラに仕事されていると伺いましたが、ペアとかで一緒に仕事されることはあるのでしょうか？ ペアっていうのはありませんが、定例MTGみたいなのはあって各自進捗とか状況を共有することはあります。その時に、各自の得意な領域を背景に、チームメンバーにアドバイスしたりすることはありますね。 各メンバーがそれぞれ別々の仕事を行なっていく、というのは自走力というか一人で完結できる能力をもってないと難しそうですし、皆さんきっと高い能力をお持ちなのだろうなと思いました。 そうですね、プレイヤーとして一通りはできて、何かしら得意領域がある方達ですね。 それと単に技術ができるだけではなく、技術がわからない人や、特定のレイヤーに弱いエンジニアに対してわかりやすくコミュニケーションを取る必要があるので、そういったことができないと技術推進グループのやっている仕事的には辛いものがあると思います。 わかりやすく説明するにはかなり高度なスキルが要求されますが、技術推進のメンバーはそこらへんができる人が集まっています。 Q2. 弊社に入社を決めたきっかけは？ 二つ目の質問です。エス・エム・エスに入社することを決めた「決め手」みたいなのはあったのでしょうか？○○さんが在籍していたからとか...。 内部の状況は色々聞いていたのでよく知っていたのと、面接の中でCEOの後藤さんと話をする機会があって、それが決め手になったかもしれないです。面白いCEOだなという印象でした。 他の会社の話を聞いた時にも、割とCTOやCEOが出てきてくれて話をする機会が多かったのですが、その中でも面白い人だな、と思って、そこに惹かれたのが大きいですね。 前回インタビューした田辺さんも入社したきっかけに後藤さんをあげていたような記憶がありますね。具体的に後藤さんのどの辺が面白い人だったのでしょうか？ CEOとしての視点だけではなく、現場感も大きく持っていて、すごく高性能なCPUを搭載している気さくな人、という点でしょうか。普通の会話の中で、「この人すごいな」と思わせるところがどこかありました。 頭の回転が早い、とかですか？ 頭の回転も早いし、とてもロジカルです。いろんなことを抽象度高く話せる人ですね。そこに惹かれたところがあります。 エンジニアでグレードの高い人は確実に後藤さんの面接が入るので、「後藤さんから見たエンジニアは？」みたいな話を聞いてみても良いかもですね。 Q3.光宗さんの思う弊社の魅力は？ 三つ目の質問に移ります。面接というフィルターを除いた時、エンジニアとして光宗さんが思う弊社の魅力ってどんなものがあるのでしょうか？ 結構あるのですが、1つは「技術的な選定において、担当の開発チームに主導権/決定権があること」ですかね。 実際に社内でJavaだったりRubyだったりPHPだったりGoだったりいろんな言語が使われているのはそれを表していますし、魅力的だなと思えるポイントです。 2つ目は、「プロダクトに対するエンジニアの裁量権が大きい」ことですね。個々のチームの規模が小さい傾向にあるので、プロダクトを開発する上でただコードを書くだけではなく、プロダクトをどうしていくのか、という根幹部分にも関わっていくことができます。 当たり前のことを言っているようですが、これが実現できていない組織は多いです。 また、「プロダクトが社会的貢献性の高いものである」ことも魅力だと思います。 確かに、自分も常々感じています。最終的なアウトプットさえ帳尻が合えば、そこに至るプロセスは問われないですね。チームごとに使っているツールが違いますし、開発スタイルも委ねられている印象があります。 僕は前職大手ソーシャルゲーム企業だったのですが、そこだと「エンジニアはコードだけ書いていればいい風潮」がありました。それを突き詰めたい人にはいい環境だと思うのですが、エンジニアとしてビジネス、プロダクトに大きく関わっていきたい場合は弊社の方がフィットしているのかなと思います。 プライム上場企業でありながらベンチャーっぽい、というのは一つの特徴ですね。 新しい技術にチャレンジできる環境やプロダクトに対する意思決定のチャンスが魅力だということですね。 僕はそこら辺が好きなんですが、あまり自由にしすぎると会社として管理していけなくなってしまうので、最低限のルールは必要だと思っています。非常に難しい問題ですが...。 （後編 ↓ へ続く） tech.bm-sms.co.jp

🔥株式会社エス・エム・エスは、2022年9月8日（木）〜 9月10日（土）に開催される、「 RubyKaigi 2022 」にて Shuttle Bus Sponsor としてシャトルバスを運行します。 ご利用方法については RubyKaigi の Venue ページをご参照いただければと思いますが、同様の内容を下記に日本語でご案内しておきます。 rubykaigi.org 乗車方法 乗車の際、スマホで RubyKaigi 公式ページの乗車用画像や こちらの画像 をバス搭乗口にいるスタッフにご提示いただくか、「エス・エム・エス シャトルバスを利用します」「RubyKaigi シャトルバスを利用します」とお伝えください。運賃は無料です。 スマホでのシャトルバス画像表示イメージ 運行ダイヤ・乗降場所 ■ 会場行シャトルバス 「津駅臨時バス乗り場 ⇒ 三重県総合文化センターメインエントランス」のバスです。 ※全ての日程で5分〜10分間隔で順次出発します。 2022年9月8日(木) AM9:00 〜 AM10:30頃まで 2022年9月9日(金) AM8:00 〜 AM9:30頃まで 2022年9月10日(土) AM8:00 〜 AM9:30頃まで 【RubyKaigi 2022 会場行きバスの乗車場所】 津駅臨時バス乗り場　（ Google Mapでの確認はこちら 、 Street Viewで付近の様子を確認はこちら ） 津駅臨時バス乗り場地図 ■ 会場発シャトルバス 「三重県総合文化センターメインエントランス ⇒ 津駅臨時バス停」のバスです。 ※津駅臨時バス停行きは全ての日程で5分〜10分間隔で順次出発します。 ※津みなとまち港行きは最終日の1本のみの運行です。ご注意ください。 2022年9月8日(木) 【津駅行】PM17:30 〜 PM18:30頃まで 2022年9月9日(金) 【津駅行】PM17:30 〜 PM18:30頃まで 2022年9月10日(土) 【津駅行】PM17:30 〜 PM18:30頃まで 【会場から津駅臨時バス停行きバスの乗車場所】 三重県総合文化センター メインエントランス付近　（ Google Mapでの確認はこちら 、 三重県総合文化センターフロアマップはこちら ） 三重総合文化センターフロアマップ 【乗車時提示用画像 / 現地案内スタッフ】 各乗降場所には三重交通様にご協力いただき、案内スタッフを配置しています。 手持ち看板 / 乗車時提示画像 【特記事項】 実際のシャトルバスに 株式会社エス・エム・エス のデザインは施されていません。 運行の都合や交通状況によって、シャトルバスの運行間隔が前後することがあります。 座席にお忘れ物のないようご注意ください。 満席で乗車できない可能性がございます。ご了承ください。 COVID-19 など感染症リスク回避へご協力ください。 乗車中はマスク着用、飲食禁止でお願いします。 その他 本シャトルバス運行用 Twitter 基本的には前述の内容で運行させていただきますが、シャトルバスの運行情報などについてアナウンスの必要性が生じた場合にはこちらから発信いたします。 また、Rubyを活用して社会基盤となるサービスを提供している株式会社エス・エム・エスにご興味のある方は、RubyKaigi 2022 開催中、こちらのアカウントへのDMも歓迎します。 twitter.com 採用情報

エス・エム・エス テックブログ運営の熊谷です。今回の記事は sunaotに聞いてみた・前編「『言われたとおりに』が何より苦手」なプログラマーがエンジニアリング組織のトップになるまで の後編となります。 田辺順 Sunao Tanabe -技術責任者 Ex. DeNA 外資生保のSEやWebの会社のプログラマーを経験後、DeNAにて技術支援チームの立ち上げ、SET/SWETとして自動化や開発者テストの開発支援に従事。エス・エム・エスでは技術責任者として、開発組織づくりや開発基盤の整備などを進める。 Q2. 田辺さんが CTO を名乗らない理由って何かあるんですか？ 田辺さんは「技術責任者」を名乗っていますが、あまり一般的な呼称ではないなと感じています。CTOを名乗らない理由は何かあるのでしょうか？ 「困っていないから」というのが大きいです。名乗ると何が得られるのかがわかっておらず、明確に実務的に裁量が増えるなら、本部長になることや役員になることのほうが明らかに自分の責任において決められることが増えます。 ではそれが今欲しいかというと、そうは感じていなくて、今私が決められないことというのはほぼすべて全社に依存することか、事業と重なる部分の話が多いです。 もし仮に自分が CTO の名称なり、本部長や役員なりだったときに、相互に依存する事情を無視して物事を進めたいかというと、そんなことはないです。その場の意思決定のスピードは上がるけれど、その割り切りによって学びの機会や相互理解の機会を失うことになるからです。 ということで、自分が今必要としている範囲の裁量は持っていて、とくに困っていないからというのが理由です。 あと、個人的なところで気づいた点としては、価値観としてそもそも役職やポジションというものを欲していなかったというものがあります。今まではそういうものがなかったので、もう少し人並みに役職やポジションへの欲があるかと思っていたのですが、実際に技術組織のトップの役割をやってみて、自分が必要としているものを満たせば、役職やポジションの名称というのは本気でまったく欲していなかったということに気づきました。漫画の『昴 *1 』で「あたしは…そう。尊重されたいの。あたしがバレエをやる理由はそれ。尊重されて生きるため。」というセリフがあり、それを読んだときに自分が求めていたのもこれだなと納得したのを覚えています。根本の価値観として「自分が良い仕事をして世の中に価値を提供をする。それにあたって必要になる信頼を得られる程度の尊重がほしい」というのだけを必要としているのだと思います。自分にとって肩書きが寄与してくれるのはその尊重へ寄与する一部で、幸い今の会社は「その人がなにを言っているか。それはなぜか」ということへの関心が非常に強く、そこで中身があればあまり肩書きは重視されないため、少なくとも社内では必要性を感じていません。 入社から室長/部長ととくに職位は変わっていないけれど待遇としては変わっていっているので、その辺も自分の組織でもやりたいこと (肩書きへの依存を極力減らして、そこと関係なく能力によって評価され待遇が上がっていく) であるし、肩書きが強くなると暗黙に他の人と関わるときに発生する 権威勾配 も好ましくないし、積極的に欲しくないなーという風に思っています。 ただ、個人の話とは別に、なにかしらの理由で CTO がいる/経営層に技術職出身の人がいることを重視している人がいることは知っていて、本当にそれがうちの会社でも必要だと思えたら、積極的に CTO なりのポジションを拒否をするほどの理由もないなと思っています。 Q3. 田辺さんから見たエス・エム・エスならではの楽しさというか良さみたいなものはありますか？ 戦略とビジネスがセオリーを土台にした上で、実践で具体性高く実行されていく様を見られることですね、特に事業責任者レイヤー、事業戦略レイヤーで感じます。 「そんな風に考えるんだ」「そんな物の見方するんだ」など、自分にはできないなと思う発見をする機会が多いです。その結果、過去読んだセオリーが自分のなかで腑に落ちて、自分でも使える道具になることが何度もありました。 事業の成長という形で、その実践が世のなかで結果を出せるんだという証明とセットで過程を見ていくことができ、知識だったものから使える道具と使えない道具が検証されている感覚になります。 これらの戦略やビジネスの強さというのが、特定の個人や一過性のもので作られているのではなくて、過去からの連綿とつないでいる経営の歴史のなかで意識的にそうなるように作られてきている、というのが非常に特異で面白い会社だと感じています。 「社風や文化、価値観として場をつくってきた」というのは他の会社でも見受けますが、それ以上に日常の会社運営も「戦略やビジネスの強さを会社として持ち続けられるようになること」を土台とし、 ”そうなるように会社を経営しているからそうなっている” というのはユニークな価値だなと思っています。 また、それをセオリーや仕組みだけでやろうとするのではなく、あくまで人に依存して人が優秀だと最大パフォーマンスを出せるぞという思想も持ち合わせてるため、 XP の洗礼を受けた私としては『人間性 (Humanity) / 人間がソフトウェアを開発する』に通ずる価値観を感じていました。 最後に、「相手へ誠実さを期待できて、変な気を使わずに本当にするべきことに集中しやすい」というのもならではの良さかなと思います。特に私の場合、ムダだと思うことを受け入れて粛々とやるというキャパが小さいので… Q4. 将来的に作っていきたい組織の理想像みたいなものはありますか？ これまでも自分が転職をする際に、「少なからず自分にフィットする環境ってどこかにあるんじゃないか」と思って転職してきた経緯はあります。 実際どの会社も良いところはたくさんありましたが、「自分のやりたい仕事の仕方を全部できる会社」は無かった。そして 4-5 社を経てさすがに気づいたことは、自分の求めているような会社は多分ないぞ、ということです。だったらそれに近い環境を作りたいなと思ってエス・エム・エスに入社したというのがあります。 そのなかで今も残っている軸がいくつかあって、１つ目に「チーム開発大事だよね」という価値観。世の中が今ほど「チーム開発」って言い出す前に、チーム開発への思いとずっとやりたいなというのがありました。 2 つ目にプロダクト開発として見たときの「ユーザー中心設計（UCD）」で、「企画の思いつき」ではないユーザーを中心としたプロダクト開発がしたかった。 3 つ目は「ビジネスとエンジニアリングとの関係性」みたいな部分です。今までどちらか二極の会社しか経験してこなかったので、ビジネスのいいなりという開発組織も嫌だったし、逆にエンジニアがヒエラルキーのトップというのも嫌だったんですね。「僕もあなたも同僚だし、一緒に良いビジネス作って、ユーザーに価値届けたいですよね」っていうのがとにかくやりたかったんです。お互いの関係性がフラットで、気持ちよく働けていけたらいいなって当時から思っていました。 この 3 つすべてやれそうな会社が、僕の思いつく限りでは見当たりませんでした。スモールビジネスだったらいくつかあったと思うんですけれども、ちゃんと成長余地があって、かつ一定規模のインパクトを世の中に出せる会社でやりたかったんですよね。 これらの条件を全部兼ね備えている会社が僕の知る限りではなかったので、エス・エム・エスでそれを作ってしまおうというのがありました。あとは組織の話からは若干ズレますけど、 「継続性アーキテクト」という生き方 でも書いてあるとおり、ちゃんとコードを書き続けながらお金がもらえるような会社が良かった、というのもあります。 自分のポジションがまだ事業責任者から遠いポジションにいるせいか、簡単なコミュニケーションはあれど、まだ距離は遠いかなと感じる部分もあります。「俺は技術やってくぜ」っていう人はいいと思うんですけど、ビジネス側との距離をどのように縮めていけば良いか、自分のなかではまだはっきりしない部分もあります。 そこは同じく課題感を持っていて、これは採用の話とも絡むんですが、エス・エム・エスはシニア層の採用比率を多くしています。 エス・エム・エスはディレクターが何かと開発に依頼をしてくるみたいな会社ではなく、プロダクトマネージャーだったり、エンジニアとして技術とビジネス両方の話ができる人たちが事業責任者と直接喋って、「この事業戦略だったらこうしないとダメなのでは？」「こうする必要があるよね」という話を直接行なっている会社です。そのためシニアクラス程度の経験が無いと、ビジネスの話を事業責任者と上手くできないという課題があるんですね。 これらは良いことなんですが、 エス・エム・エスの事業責任者たちは、僕が今まで見てきた人と比べても、世の中で有数に優秀な人たちなんです。 戦略リテラシーも高く、まずマーケッターとして優秀だなと。反面、そのための専門知識も当たり前にあって、その人が持っている知識量とか、今どういう視点で喋っているんだろう、ということを理解しながら、適切にプロダクトの話やエンジニアリングの話に変換する能力が求められるわけです。 これらの理由から、会社としてシニアクラス層が足りないと事業スケールのボトルネックになってしまうため、ここの採用に力を入れています。 とはいえ採用だけではなく、社内での育成体制を整えていきながら事業責任者とやり取りできる人を育てていく道筋を作らないと、と思ってはいますが、まだうまく形にできていません。これらの事業戦略直結な人材を育てていくことができれば、シニア採用に頼らずとも層を厚くできますし、ジュニアやポテンシャル採用もさらにしやすくなるはずです。それによってより多くのビジネスが実現し、価値提供ができると思っています。 （完） tech.bm-sms.co.jp *1 : MOON ー昴 Solitude standing ー 1 巻 p203

エス・エム・エス テックブログ運営の熊谷です。今回は「エス・エム・エス社員に訊いてみた」と題しまして、弊社内のエンジニアを中心に聞きたいことを募集し、インタビューをする企画をスタートしました。第一弾は弊社の技術責任者である田辺さん( @sunaot )です。 質問内容については、Slack で事前に「田辺さんに聞いてみたいことはありますか？」と募集し、内容を精査したのちインタビュー形式で答えてもらいました。 本記事は前後半の二部制になります。 田辺順 Sunao Tanabe -技術責任者 Ex. DeNA 外資生保のSEやWebの会社のプログラマーを経験後、DeNAにて技術支援チームの立ち上げ、SET/SWETとして自動化や開発者テストの開発支援に従事。エス・エム・エスでは技術責任者として、開発組織づくりや開発基盤の整備などを進める。 Q1. 田辺さんて今まで何をやってきたひとなの？ すべての道は「問題解決」に通ずる 田辺さんって今までどういうことをしてきて、そして今どういう仕事をしているんですか？観測している範囲でも、組織体制を考える EM 的な振舞いからプロダクトのリニューアル判断、経営陣とのやりとりなど多岐に渡っており、普通のエンジニアをしていても経験出来ないだろうな、と感じています 事前に頂いていた質問表のなかで、この内容が一番難しいなと思っていました（笑） 携わってる仕事を例にバックグラウンドを話すと、上記の他に例えば今、「購買プロセスの見直し」も行なっていたりします。内容だけなら多岐にわたって見えますが、ベースはすべて問題解決だと思って見ています。 例えば購買プロセス1 つをとっても、ただ 「稟議の手続きを守らなくてはいけないからやってください」 という話ではなく、「会社の中における購買プロセスとはどういう位置づけなのか」「稟議の中に記述すべき起案事由はそもそも何を書けば良いのか」「それが必要になる背景・目的」「書くべきことや書かなくても良いこと、自分が何を省いたらよいか、本来しなくても良い努力」というようなことを考えるようにしています。これらも基本的には僕のなかでの問題解決の能力に紐づいて行なっています。 「言われたとおりに」が何より苦手 その上でこの「問題解決を軸にした考え方」というのは、最初から意識的に行なっています。 キャリアの最初はもともと WEB サービスのプログラマーになりたかった、というわけではなかったんです。身近な人が戦略コンサルタントをやっていたこともあって、まずはエンジニアとして経験を積みながら、プロジェクトマネージャーを経て IT コンサルや戦略コンサルにいくと面白いのかな、と初期の頃はそう思っていました。 そのため、技術の部分はもちろん学びつつも、ハーバード・ビジネス・レビューなどを読んで経営や戦略の話も同時にインプットを続けており、特にその際に出会った大手コンサルティングファーム企業の問題解決手法に感化され、関連の書籍を読み漁っていました。 当時はインプットした知識を直接利用する場はありませんでしたが、これらの知識が今のバックボーンとなっており、軸をすべて問題解決の話として解いている、というのがあると思います。 他の人との差分があるとしたら、 「人から言われたとおりのことをやる」のが極度に嫌いで 、人間的な欠陥があると思っています（笑） どんな些細な仕事でも「これはそもそもなんだろう？」と考える習慣が常にあり、納得できないとその仕事やりたくないな、と思ってしまいます。なので仕事に取り掛かる際に「これはなんの仕事だろう？」という解釈を自分の中のインタプリタに一度通す、といった頭の使い方をしています。今まで生きてきた中で、周りもみんなそうなんだろうな、と思っていたら、意外とそうでもないぞというのに最近気づきました。 最近気づいたのにはなにかキッカケが？ エス・エム・エスで組織のマネージャーとしていろいろな人を見るようになったからかもしれません。これまでの会社だと、そんなに他の人がどう考えているかを知る機会が無かったので。 Twitterでは "エンジニアはみんな社会不適合者" みたいに言っている人が多くて *1 、声が大きく見えてたんですよね、自分もご多分に漏れずそうだろう、と。 ところが実際エス・エム・エスでマネージャーという立場でみんなの勤怠打刻を承認していると、ほぼ全員ちゃんとやっているという事実に驚愕しました。「皆さんルールが守れる、スゴい！」みたいになってました。 私はたとえ会社の仕組みであっても、それが本来なにを目的にしていて、目的をクリアする上でいかに手順をハックして楽にするかということへ心血を注ぐタイプです。反対に、それがルールだから理由は問わず守ってくださいと面倒な仕組みを押し付けられるとサボりたくなります。でも、そこまで一つ一つの手抜きをしたいと考える人は少なく、意外と面倒でもそれが会社の仕組みやルールであれば守れる人は多いのだと気づきました。 プロフェッショナルとして、どこに価値提供をするか？ お話のなかで思ったことが、問題解決をベースにしていると言っても「組織編成」と「購買プロセスの改善」ではだいぶ幅がある気がしています。これらは自身で "これなら行ける" と自分からその仕事を取りにいくのでしょうか、それとも "お願い" と頼まれたことをこなしているのでしょうか？ その言い方でいうと「取りにいく」ことのほうが多いと思います。自分が会社からお金を貰っている以上は、「会社にとってベストなものを提供して、その対価を得て生きていく」というのが自分としては楽しいなと感じていました。もちろん、それによって失敗したこともたくさんありましたね、そんなものは求められていないケースも多かったので。 一方で「それを求めてくれる人とはうまく働けるな」というのはありました。 "会社にとってのベストを目指すこと" が良いかどうかはまた判断が難しい話なんですが、少なくとも自分から見たときのベストな "今やるべきこと" をしていきたい。そうなると結果的に取りにいくことになるケースが多いです。自分の範囲でできることって意外と少なくて、であれば周辺まで自分が色々手を伸ばしたほうが、結果的に会社にとってより良い形になるな、と思うことが多いので、そういう仕事の仕方をしている気がします。 能力より機会を優先すると大体が辛い現場…でも無理だったら辞めても良い なるほど。ただ「コンサルの本を 20 代で読んでいたら30-40 代にかけてエンジニア組織のトップになれるか？」と言われると疑問が残るというか… ここからはエンジニアの話に近づきますが、『 達人プログラマー 』の洗礼を受けているのが大きいです。当初意識していた戦略コンサルタントをそんなに目指そうと思わなくなったのは、「僕はプラグマティックにずっと現場で試し続けて、役に立つもの以外は信じない人でいたいな」という意識が強く芽生えたからです、完全に達人プログラマーのおかげですね。 （※過去に田辺さんは Rubyist Magazine にて達人プログラマ著者 David Tomas が来日した際のレポートも書いていますので、ぜひこちらもご一読を） また、自分が思い描くものにチャレンジする機会は、切り口を変えていくことでいくらでもありますし、転職の際に望んで選んでいた気もします。自分の能力に対してチャレンジする機会の自由度が高そうとか、裁量が多そう、範囲が広そう、という機会はあえて選んでやってきた、というのはありそうな気はします。 そして、そうやって "能力よりも機会" を優先すると、大体の場合 "辛い現場" になることが多いです（笑）。飛び込む先に何かしらの大きな課題を抱えているからこそ、その人の能力以上の裁量を渡せるので。意識的にはやってこなかったけど自分が色々チャレンジできそうなものを選んできたら、結果的にそんな仕事ばかりになっていた感じです。 うーむ、生存者バイアスにも何となく聞こえてしまうんですが… どうでしょう、生存してなかった気もするので。 超えられてきたからこそ、今に至っているんだと思うのですけど… 別に超えなくても死なないですしね。まぁインタビューで堂々と話すのもなんですけど、「エンジニアは転職できるから嫌になったら辞めちゃえばいいし」みたいなところもあって。 生存者バイアスの文脈だと、 "どこでも踏ん張り続けて、ちゃんと成果を残す" ところまでやりきれる人はホントに凄いなって思うんですが、反面僕は「この壁、自分の裁量では絶対どうにもならんな」みたいなところに当たった時、結構辞めてきている気がしてます。なのでそんなに "生存してた感" は自分の中には無いんですよね。 「自身の成長」より、 "何が貢献できるのか" なるほど、その場における自分なりの、それなりの奮闘の結果伸びた部分があり、 "もうこれ以上は" となったら辞めてを繰り返してきたら、結果として田辺さんが出来てきた、という感じですかね そうですね、機会を優先してたので、環境は正直あまり気にしたことがなかったです。それでいうと、自分の成長もそんなに気にしたことが無かったかもしれないです。自分にとって何かをトライする機会があるか、自分は何が貢献できるのかという。 僕は、「給料をもらって生きているな」という感覚が強いので、「ちゃんとその金額分の価値を返さないとマーケットに捨てられる」という危機感をどこかに抱えて生きているんです。お金を稼ぐということは、需要に対しての供給があって成り立っているので。 なので "何が貢献できるか" というのは、綺麗事としてではなく「ちゃんとニーズを満たし続けないとお金稼げないですよね」という現実的な側面からの貢献という意味です。 成長自体に楽しみを覚える人もいますが、田辺さんの場合、自身で機会を選び続ける上でまずは貢献が必要で、その手段として成長が必要だったと はい、そんな感じです。 貢献し続けられることの行動としてやり続けてきたことは？ うーん、体系的に何かを意識的に強めてきた、というのは正直無いです。もともと自分が持ってる興味でやっている部分が大きいですかね。 今自分がある程度手に持っているものをザッと出すと「問題解決」「戦略/事業」「経営」「業務」「チーム」「プロダクト」「技術」になるんですが、最初からこれらを身につけようと思ったわけではないです。 わかりやすく Web2.0 みたいなものに世の中が湧いていたとき、「自分でサービスとか作って起業とかしてみたい」と思っていた時期もありました。もともと経営とかは学んでいたので、そこから派生して必要になりそうな会計などの知識要素を学習していたことはありました。 そういう背景から、ビジネスを俯瞰で見たとき、どういう領域があるのかは何となく捉えていたな、とは思うんです。ただ、結局最後は "現場の仕事で求められるもの" がインプットとしては一番大きいですね。例えば組織論だったり、チームの話、人の話だったりなどもそれにあたります。 「これ学んでほしいな」と言われたわけではなくて、「今の状況からいくとこれも学習する必要があるな」を続けてきたら、結果的にこういう感じになっていました。直近だと、学習領域はかなりプロダクトの話に偏っていて、モダン・プロダクトマネジメントとはなんぞやみたいなものが多いですね。 ビジネスがリアルタイムで作られていく現場から得る"解像度" 今後チャレンジしてみたいことなどは？ 「チャレンジしてみたい」ではないんですけど「今のポジションをやっている以上、ここをやらないとな」という領域だと組織経営ですね。個人的には、規模のある組織を見たいというモチベーションがないので、本当はやりたいとはちょっと違うんですけど。ただ、必要だし、自分ができるようになること自体に価値があるので今後必要というならこれになります。 あとはエス・エム・エスにいるからにはやっぱり "ビジネス" ですね。うちの会社でビジネスの話をしているのが単純にめちゃくちゃ楽しいですし。今まで戦略の本や経営の本で学習してきたことの答え合わせができる感覚があります。これはチャレンジ、というより「日々の楽しみ」って感じですね。 kiitok のインタビュー記事 でも「再現性あるビジネス」の話をされていたことを思い出しました 先程「今までの書籍の答え合わせ」と話しましたが、逆を言うと「本を読んだだけで自分がビジネスで成功できる」って思える人、多分居ないんじゃないかと思うんです。端的に言うとやはり書籍だけだと具体性が弱いんですよね。 働いている現場で優れたケースが見られることの利点は「目の前でリアルにビジネスが作られていく具体性を見ていける」ことです。 「こういうときってこのタイミングで、こういうことを考えて、こういうロジックでこういう結論を出しているんだ、ここまでやっているとこういう質のアウトプットになるんだ。ここまでやらないとこの質の意思決定ってできないんだ。」など、情報量の多さと質はやはり現場ならではの解像度の高さだと思います。 そういった事例から「あ、別に本も嘘じゃなかったんだ」という答え合わせ的な感覚がとても面白いなと感じています。教科書のような本の答え合わせをするためには、教科書に書いているような戦略理論をベースにしてビジネスが進められている必要があり、理論を使いこなしてビジネスをしているエス・エム・エスで働くのは学びも楽しみも大きいです。ちなみに、『 Hot Pepper ミラクル・ストーリー―事業マネジメントを学ぶための物語 』という書籍が、「今うちでやっていることをベースにして、それを本に纏めるとこういう形になったんだろうな」というのが想像が出来てとても面白い本でおすすめです。 （後編へ続く） 後編はこちら↓ tech.bm-sms.co.jp *1 : インタビュイー注: 自身のフォローしている観測範囲のせいかもしれません

はじめまして、人材紹介開発グループでEMをやっている大野です。 突然ですが、みなさんは組織・チームでの振り返り会をどのように行っていますか？いざ、定期的な振り返りを行ってみると、MTGがマンネリ化したり、有効な時間として活用しきれなくなることはよくあると思います。 今回は自分たちのチームで行っている、週次の振り返り会についてお話できればと思います。 振り返り会の概要 振り返り会とは言っていますが、KPTやスクラムでいうレトロスペクティブとは少し異なり、毎週トピックを変えながら実施しています。 イメージを持ってもらうために、バックナンバーの一部を貼っておきます。 振り返り会のバックナンバー 上記の通り、勉強会のような回もあれば、KPTでチームの課題を洗い出す回、また新しいメンバーが増えた際はコミュニケーション中心に時間を使う回等、毎週やることが変わります。 内容によっては2,3時間することもありますが、大体は週1時間程度になっています。 この運用になった背景 以前はKPTベースで振り返りを行っていました。ただ、運用期間が長くなるにつれ、以下のような問題が目立つようになってきました。 Keepの内容がマンネリしがち Problem→Tryが溜まりすぎて、Tryが形骸化 一方で、チームの人数も増え、多様なメンバーがいることで、持っている技術スタックや、サービスに対する理解の差分等が課題として見えてきました。 そういった差分を埋めるために、メンバーが知りたいことや学びたいことを、知っているメンバーから伝える場を作ろうと考えました。 結果、今のような形に落ち着いています。 運営する上で気をつけていること チーム内では以下の認識をもってもらっています。 開催ハードルをあげない =>週次でやるので、継続性を重視。準備に時間をかけないようにしています。 他チームの人もゲストに => スピーカーをしてもらうときもあれば、他チームの興味ある人が見に来たりするときもあり、自由度高め スピーカーを増やす => チーム全員がスピーカーになれるよう、後述のネタ出し会を開催しています。 ネタ出し会 毎週やることを変えるので、2ヶ月に1回程度ネタ出し会を行っています。 Jamboardベースで以下のようなことを行っています。 自分の知りたいことを書く チーム内で詳しい人 or 調べれる人をスピーカーに選出する 数回分のスケジュールを決める ネタ出し会 得られた効果 当初目指していたチームメンバー間の情報補完はもちろん、他にも以下のような効果がありました。 ネタを考えるために、普段の業務と違う部分にアンテナを広げる動き 事業面やチームビルディング等、技術以外の部分への関心が増加 スピーカーに対するハードルの低下 この時間で何か学ぶ/進めるといった意識と文化の醸成 もっと面白く、魅力的なものにするために必要なこと 現在は、継続性を重視して比較的軽い内容のものをたくさん行うような形を取っていますが、数週間かけてリファクタを進める回等、プチプロジェクト化した取り組みのようなものも今後行っていければと思っています。 また、自分が担当しているもう1つのチームは、KPTベースで振り返りつつ、週毎にテーマ性を持つことでメリハリつけるような形で運用しており、Tryのアクションも活発に行えているので、両チームの良いところをうまく活用していければと思います。 さいごに チーム運営をする中で、振り返りの場や勉強会をどう行うか？はチームビルディングの一環としてとても重要になるかと思います。 今回、お届けした内容がチーム運営の1つのやり方として、参考になれば幸いです。

エンジニア採用の経路とは？ 突然ですが、みなさんは現在お勤めの会社にどういったことをきっかけに入社しましたか？ リファラル（社員紹介） エージェント紹介 ダイレクトリクルーティング 企業の採用ページに直接応募 求人広告 etc. と、さまざまではないでしょうか。 それぞれのアプローチに特徴があり、一つで記事になるくらいの観点がありますが、今回はリファラル採用について考えてみます。 一般的にリファラル採用では下記のようなメリットがあげられることが多いと思います。 カルチャー・技術面でマッチしたエンジニアと出会いやすい 現場エンジニアの生の声を聞いた上でカジュアル面談ができる(現場目線とエンジニアトップやマネージメント目線の両方をインプットにしていただける) 転職意志が無い/薄いタイミングからお互いの情報を提供しあうことができる いいですね。では、早速紹介してみましょう！といきたいところですが・・・ で、誰を紹介すればいいですか？ リファラル（社員紹介）制度を導入している会社も多いため、「良い人いたら紹介してください！」というのはかなりの方が言われたことがあるのではないでしょうか？ では、「紹介できる良い人」が自分の中に湧いて出てくるかというと、そんなことはありません。もちろん、友人・知人と一緒に食事に行ってて「実は転職しようと思っててさー」ということはあり得るのですが、なかなか自然に遭遇することでは無いと思います。 そこで、リファラルで仲間候補を集めるための手法にメモリーパレスと呼ばれるものがあります。採用に関わったことがある方は耳にしたことがあるかもしれません。 メモリーパレス(記憶の宮殿)とは？ このメモリーパレス(Memory Palace)ですが、元をたどるとリファラルのための手法というわけでもなく、座の方法(Method of Loci)などとも呼ばれる記憶術だとのことです。 Method of loci - Wikipedia この記憶術のきっかけは、古代ギリシアの詩人シモニデスが、宴会場の天井が崩落するという事故に遭遇した際に、被害にあった人々がどこに座っていたかを記憶していて、身元を割り出すことができた・・ということにあったそうです。 一般的には、羊たちの沈黙のハンニバル・レクターが身につけているという設定が有名なようですね。 ハンニバル・レクター - Wikipedia ・・・全然今回の趣旨とは関係ないですが、シモニデスはエーゲ海にあるケオス島(現在のケア島)生まれだそうです。綺麗な夕日が眺められる高級リゾートがあるとか・・・いいですね。行ってみたい。 で、なんでリファラルにこれが使われる？ 現在のプロダクト開発界隈でなぜメモリーパレスがリファラル採用の手法として認知されるようになったのでしょう？この手法を使ってリファラル採用を支援するような会社さんもあるようですが、今回改めて調べてみても起源ははっきりしなかったものの、Sequoia Capital - Human Capital Teamの記事が参照されていることが多いようです。 3X Your Referral Rates いきなりリファラルでいい人紹介して！と言ってもなかなか挙がってこないので、エンジニアと構造化したコミュニケーションを行うことでエンジニアの知己を思い出してもらおうという考え方ですね。 メモリーパレスは本来場所と結びつけてそこを移動する・・・というもののようですが、リファラル活動では社員の経歴を宮殿と見立てて質問を行っていくというやり方です。確かに実際やってみるといきなり人物を思い出すよりも、経歴から想起した人をあげる方がはるかに思い出せるという実感が得られます。面白いですね。 公開されているサンプルのスプレッドシート 副次効果 よしよし、リファラル採用の候補者が上がってきたぞ。良い人と出会えるといいな。・・と採用担当者は考えるのですが、では一緒に取り組んでみたエンジニア個人としては何が得られるのでしょうか？ よくある誤解は「会社にとってメリットあるだろうけど、社員からすると一方的に自分から吸い上げられてメリットがない」です。この結果、協力しにくいというのはよく聞きます。では、何か。社員紹介制度に則った報奨金？なるほど。。 これも良いのですが、EMをやっている身としては、別のメリットもあるよと言いたいです。私は転職意思などにかかわらず振り返りを兼ねて職務経歴書(的なメモでも良い)を作ってみると非常に効果的だと考えているのですが、これに合わせてメモリーパレスを実施すると、何気なく過ぎてきた中に自分としての価値観などを見つけ出せるなーという気がしています。 いつも思い出す大恩人みたいな人が想起されてくることももちろん多いのですが、それよりも実は価値があるかもしれないのは、 難しいプロジェクトでちょっと自分を助けてくれた先輩エンジニア 障害対応時に颯爽とあらわれ、アドバイスで一緒に解決に導いてくれたSRE 気持ちよく働けた同僚 のように今の自分を形作ってきた、”小さいかもしれないけど後になってみれば重要な経験”に関与してくれていた人たちの発見ではないかと思います。 さらに、なぜ彼らを思い出したのか・・と深掘りしていくと 彼らの当時の振る舞いが今の自分にはできるのか 今彼らはどういったポジションにいて何をやっているのか 彼らの共通点は何か（＝自分は何に価値を感じているのか） など、改めて確認するとャリア形成(というと大袈裟な気もしますが)に役だったり、彼らに連絡をとって話をすることで、人物の想起の先にさらに経験の擬似体験などまで得ることができたりします。いいですよね！ 実際にやってみると メモリーパレスは一人でやることも可能なのですが、弊社エンジニアと実施してみると、ご本人の価値観についてよりお互いの理解を深めるきっかけにもなり、面白いなーと感じました。 同じ企業にすれ違いで所属していたことが分かり心理的距離感がさらに縮まる 優れたスキル・能力を身につけるに至ったプロセスを知ることができる 共通の知人について「強い」「一緒に働いてみたい」という話で盛り上がる ぜひこの記事を読んだ皆さんもまずは一回やってみてください。 ということで、さまざまな会社で取り組まれているであろうリファラル採用活動とメモリーパレス。せっかくなら個人としても得るものがあるように活用していきたいですね、という話でした。 最後に。弊社ではPdM、EM、Webエンジニア、QAなどプロダクト関連職種を積極採用中です。興味を持っていただけた方はTwitter DMでの連絡でも構いません。カジュアル面談しましょう！

エス・エム・エスで介護施設への入居マッチングサービス「 安心介護紹介センター 」の開発をしている中村と申します。「安心介護紹介センター」は2022年3月にローンチしたばかりの新規サービスで昨年から開発プロジェクトの担当をしています。 安心介護紹介センターはゼロからプロダクトを作るプロジェクトだったので、インフラの構成や監視など全てをゼロから考えて作る必要があったのですが、開発チームのメンバーでその経験が豊富な人はおらず、私にいたっては経験ゼロ。いつもインフラについては社内のインフラチームだったり他の誰かに設計・構築してもらい、自分はアプリケーションのコードを書くのみで、ALBもIAMもSecurity Groupも名前と役割は知っているけれど、自分でAWS環境で設定したことはありませんでした。またローカル環境構築のためにDockerを利用してはいましたが、コンテナでサービスを運用したこともありませんでした。 AWSよくわからん、コンテナよくわからん、という状態を脱したくて、自分で本を読んだりAWS Black Belt Online Seminarをみていたところ今回のプロジェクトにアサインされることになったので、これはスキルアップのチャンスになると思いすべて自分でやることにしました。 初めてのゼロからインフラ構築 こまったこと 今ならECSだよね...でも何から手をつけてよいのかわからんぞ...という状態でスタートしましたが、特に最初つまづいたのが以下の点です。 ECS運用のベストプラクティスは？ インフラの構成をコード管理するってどうやるんだろう？ コンテナのデプロイはどうやるの？ コンテナの定期バッチってどうやるんだろう？ Fargateのベストプラクティスは「sshを避けるというメンタルモデル」。sshできないって困らない？ ECSの監視って何でするの？ どう乗り越えたか ECS運用のベストプラクティスは？ エス・エム・エス社内ではAmazon Web Services, Inc. のソリューションアーキテクトの方が定期的に勉強会を開いてくださっており、たまたま直前にDocker・コンテナ入門のハンズオンがあったので、それに参加しました。 ここでECSを使うメリットとECSでの開発・運用のベストプラクティスについて知ることができました。メリットデメリットと原理原則を正しく理解した上でサービスを使うことは大切なことなので、これを一番最初に、しかも専門家に教えて頂けたのはとても有益でした。 コンテナを使うメリットを生かすために、安心介護紹介センターではproductionとstaging環境は（マシンスペックという点は差分がありますが）、構成と使用しているDockerファイルは全く一緒にし、差分は環境変数(Parameter Store)で管理するようにしました。また、開発環境もなるべく本番と同様の構成になるようにしています。 この講習を受けてなかったらきっと環境によって差分をだしてしまって、コンテナ使ってる意味ないやん状態を作ってしまっていた可能性があったので、事前に原理原則とベストプラクティスを学べたのは良かったです。 インフラの構成をコード管理するってどうやるんだろう？ これはもう素直にインフラチームの方に相談して、今回はterraformを使うことにしました。(terraformを選んだ理由は社内でよく使われているから、程度の理由です。) ドキュメント 調べまくりました。 コンテナのデプロイはどうやるの？コンテナの定期バッチってどうやるんだろう？ これは 社内制度 で購入した 書籍 を参考にして、デプロイはCodePipelineを中心にデプロイメントパイプラインを構築し、ECSへデプロイしています。 GitHubのmainブランチにマージ GitHubからソースコードを取得 DockerイメージをビルドしてECRへプッシュ ECRからイメージをプルしてECSへデプロイ また定期バッチは、バッチの数が少ないのでECS Scheduled Tasksを使いECSのタスクを定期実行しています。（EventBridgeからタスクを起動する） Fargateのベストプラクティスは「sshを避けるというメンタルモデル」。sshできないって困らない？ ECS運用のベストプラクティスに「SSHを避けるメンタルモデル」とあったので、SSHを想定した運用は絶対なしということを大前提にしました。そして運用時にサーバーへのsshするときってどんなときだろう...というのを洗い出して、それに対して別の解決方法を決めました。 たとえば、 障害がおきたときに、原因を調査したい →デバッグに必要な情報は外部に送信するようにする。 各種ログはALBなどS3にログを出力するものはS3に、ECSやRDSなどCloudWatch Logsに出力するのものは一定期間がたつとCloudWatch Logsから消えるようにしているので、監査上長期間保存が必要なログは、CloudWatch LogsからKinesis Data Firehoseを通してS3に保存しています。またアプリケーション側も調査に必要な情報をログに出力するように気をつけました。 DBのデータをみたい →AWS Elastic Beanstalkを使ってMetabaseを構築し、そこからDBのデータを参照できるようにした。 DBマイグレーションがしたい →なるべく作業は自動化したかったので、DBのマイグレーションはCodeBuild内で実行することにした。 ECSの監視って何でするの？ これはすでに社内で使用されていたMackerelを使用することにしました。調べてみるとタスク定義にmackerel-container-agentコンテナを追加するだけでOKでした。（もちろんMackrel側のモニターの設定などは別途必要です） 全体の構成をきめたら、そこで一旦社内のインフラチームの方にレビューして頂いて構成をここでFixさせました。 次にAWSのドキュメントとterraformのドキュメントを読み、環境構築をトライアンドエラーを繰り返して作っていきました。ここでもインフラエンジニアにレビューを必ずお願いするようにして、できあがったけどこれはあかんぞ、というようなことがないように間違えたらすぐ修正できるように進めました。 実際どうなったか 実際の構成はざっくりですが以下のようになっています。（ECSはオートスケーリング設定してあります） まとめ よかったこと 無事にリリースができたこと。そして今のところトラブルなし！ 初めてのゼロからインフラ構築だったので「何もわからん」からのスタートで当初はかなりあたふたしましたが、新しいことは楽しいな！という気持ちで進められたのがよかったです。もう一回やりたいくらい楽しかったです。 今回楽しいなと思えた理由は、以下の2つが大きかったです。 専門家が主催した勉強会で事前に正しい知識を学べたこと チーム内外からのレビュー エス・エム・エスでは誰でも参加できる社内勉強会があったりレビューの文化があるので、1人で悶々と悩んだり、間違えたまま突き進んでしまうようなことが起きにくいです。もちろん自分でドキュメントを読んだり勉強することは必要ですが、初めてやることは「これでいいのだろうか...」とやはり不安になるので、このような制度/文化があることは健やかな開発とスキルアップの助けになっています。 また技術選定は基本的に現場に任せられており、やったことないことでもどんどんやってみたまえ、という雰囲気なので、新しいことにチャレンジしやすい環境だったこともよかったです。 おわりに 「安心介護紹介センター」はローンチしたばかりでまだ小さいプロダクトですが、 これからサービスを成長させながら運用可能なシステムを維持し続けること が次の目標です。そのために引き続き勉強してスキルアップしていきたいと思います。 今回はゼロからのプロダクト作りでしたがエス・エム・エスでは規模やフェーズが様々なプロダクトがあります。自分も成長しながらプロダクトの成長に関わりたい、というエンジニアのみなさま、ぜひ一緒に開発しましょう！おまちしております。

はじめまして。2022年4月1日にプロダクトマネージャー(PdM *1)として入社しました一柳です。 私はエンジニア(*2)からPdMへキャリアチェンジしており、PdMとしての転職活動は今回が初めてでした。 エンジニアとしての転職活動には慣れていたものの、PdMとしての転職活動にはエンジニアとは異なる面が多々あり転職活動に苦労しました…。 約4ヶ月に渡って試行錯誤をしながら転職活動を進めてきたなかで、いまから振り返れば「最初からコレをやっておけば…」と後悔するポイントも多かったです。 これからPdMとして転職される方の参考になればと思い、ギャップがあったポイントと工夫した点についてお伝えします。 *1 プロダクトマネージャーはPMと省略することもありますが、本記事ではプロジェクトマネージャーとの混同を避けるためPdMの略称を使います。 *2 本記事ではソフトウェアエンジニアのことを指します。 この記事の想定読者 現役PdMの方 PdMキャリアを想定しているエンジニアの方 PdM候補者の気持ちが知りたい採用担当者の方 お伝えしたいこと エンジニアとPdMの転職活動のギャップ PdMとしての転職活動で役立つTips 時間がない人向けのサマリ 自身のスキルやスタンスをしっかりと企業に伝えるためにプロフィール資料を用意しましょう。 企業の情報収集はカジュアル面談を活用しましょう。スケジュールに余裕を持てるとなお良いです。 行動面接を想定して、過去案件の背景情報を整理した資料を用意しましょう。 オファー面談でも焦らずに、丁寧に期待調整のコミュニケーションを行いましょう。 転職活動の背景 本記事を読み進める上での私の背景情報です。 エンジニアとして2回転職経験あり 前職でエンジニアからPdMにキャリアチェンジ 退職済みの状態から転職活動をスタート 事前準備段階 感じたギャップ PdMとしてのスキルアピールがしづらい。 エンジニアであれば職務経歴書に扱える言語やフレームワークを記載したり、GitHubなどで制作物のポートフォリオをアピールできるのですが、PdMの場合それが難しいです。 単に職務経歴書を書いただけではスキル背景を伝えにくいように感じました。 対策として行ったこと 自分のPdMとしてのスキルや、今後のキャリアの方向性を書いたプロフィールページを作成し、職務経歴書にURL添付しました。 私の場合は、 PdMとしての得意領域 転職軸 大切にしている価値観 期待する企業文化 を記載して、自分自身の特性をお伝えできるようにしました。 プロフィールページの作成は、GoogleDocs、Notion、Proffなどを使えば、限定URLで公開するお手軽に作成できます。 求人票確認～応募まで 感じたギャップ 求人情報が薄く、応募先選定を行う材料が少ない エンジニアの場合、求人情報の時点で使用技術、チーム文化、エンジニア向けの福利厚生が分かるためある程度足切りができるのですが、PdMの場合判断材料となる情報が少なく求人情報の時点で足切り判断するのが難しい状態でした。 対策として行ったこと とにかくカジュアル面談に行きまくりました。 1ヶ月の間で15社と面談できたので頑張ったほうだと思います。 カジュアル面談をうまく活用するコツとしては、 求人情報や採用サイトから読み取ったPdMが解決する課題への認識が正しいかどうか？ 企業がPdMに求めていることの解像度をあげる という観点に絞って質問リストを作成しておくことです。 面談直前の1時間を作業時間として事前インプット+質問リスト作成を行いました。 あまり準備に時間をかけすぎても量がこなせないため強制的に時間を区切る目的と、短期記憶を使って効率よくインプットする目的でこのような運用をしていました。 今回の場合は急遽カジュアル面談での情報収集に舵をきったので、1ヶ月の間で急ピッチに数をこなしましたが、本来なら半年ぐらいの期間でゆるやかにカジュアル面談の数をこなしていくほうが良かったなと感じています。 応募～面接まで 感じたギャップ 過去の実務実績ベースの質問を受ける「行動面接」が多かった エンジニアの場合、どちらかというと状況設定型面接が多かったり、コーディングテストや設計テストのようなスキル面接が行われるため、行動面接ベースが少なかったように感じます。 そのために自己アピールしていくことに難しさを感じました。 また特にPdMの場合、過去案件の説明をする際に前提となる情報が多くなりがちなので、課題状況を伝えるだけで面接時間を長々と使ってしまい実りの少ない面接となることが多くなってしまいました。 対策として行ったこと 事前にホワイトボードツールを使って、過去案件の背景情報を整理した資料を用意しておき、それを使いながら過去案件の状況を簡易に伝えられるようにしました。 使うツールはMiroやFigJamなどになります。 これらのツールを使い、プロダクト構造と組織構造、それぞれの構造から生まれる課題と制約を簡易的な図に起こしておくようにしました。 こういった資料を事前に用意しておくことで、スムーズに背景情報を伝えることでき、自己アピールに時間を使うことができました。 ※ 念の為ですが、過去案件の説明をする際には守秘義務契約を守れるように、フェイクやマスキングを用いて説明するようにしましょう。 ※ 個人的には上記の前提があるため、PdMに対して行動面接が有用なのか疑問に感じています。 オファー面談 感じたギャップ PdMのポジションや期待のすり合わせにとても気を使う 一般的にオファー面談にて企業が何を期待しているのか、自分が何の貢献ができそうかといった期待のすり合わせは重要になってくると思います。 PdMは特に「具体的に何をしていくのか」が分かりづらい職種ですし、実行するにあたっての体制も企業ごとに様々です。 それまでの面接を通じて断片的な情報から、おおよそのポジションを推定できますが、オファー面談の場で改めて観点をすり合わせることが大事になってきます。 実際オファー面談で期待調整をしてみると、それまでのコミュニケーションで想定されたポジションと異なるオファーだったことが分かるシーンがありました。 対策として行ったこと 担当するプロダクト領域、意思決定の範囲、意思決定する上で関わる重要ステークホルダーを再度整理して確認するようにしていました。 自身が得意とすることや、今後の志向性とズレたアサインとなっていた場合、入社後に非常に苦労することが想像に難くないため、内定企業と自分自身のためにも丁寧にコミュニケーションをとっていきました。 要点まとめ 改めてPdMとしての転職で気をつけたいポイントをまとめます。 自身のスキルやスタンスをしっかりと企業に伝えるためにプロフィール資料を用意しましょう。 企業の情報収集はカジュアル面談を活用しましょう。スケジュールに余裕を持てるとなお良いです。 行動面接を想定して、過去案件の概要が分かる資料を用意しましょう。 オファー面談でも焦らずに、丁寧に期待調整のコミュニケーションを行いましょう。 おまけ：エス・エム・エスの選考過程の感想 私がエス・エム・エスの選考過程に入った段階では、上記で書いたような対策ができていたので、スムーズに選考を進めることができました。 なかでも上手くいったポイントは、カジュアル面談でした。 事前に質問事項を準備していくことで、どのような課題を解決したいのか、PdMに期待することはなにか、PdMが所属する組織はどのような状態なのかが、おおよそイメージできる状態となりました。 カジュアル面談を終えて、私がフィットするかのイメージが持てたので選考にも前向きに取り組むことができました。 また会社側からも私の関心に寄せて事業の説明を厚めにしていただいたので、質問の手間が省けた部分が多かったように思います。(その分アドリブで突っ込んだ質問をすることができました。) 入社して丸2ヶ月経っていますが、面談時と入社後のイメージギャップがかなり少ないです。 もちろん組織や事業についてもろもろ課題感はあるのですが、面談でお話いただいた情報と齟齬はありませんでした。 もし弊社への応募を検討いただける方は、面談や面接にて知りたいことを率直に質問してもらえると良いと思います！ おわりに この記事では私がPdMとして初めて転職活動をするなかで感じたギャップと対策を書いてきました。 この記事では端的にまとめていますが、実際に4ヶ月弱の転職活動をしていくなかでは手探りの連続で、苦労の多い転職活動でした。 この記事が少しでも、PdMの転職活動に役立てば幸いです。 最後にお約束ですが、弊社ではPdM、エンジニア、EMなどプロダクト関連職種を積極採用中です。 もし弊社に興味をもっていただけましたら、ぜひ カジュアル面談 にてコンタクトをとって頂ければと思います。

採用サイトリニューアルを実施しました @emfurupon777 です。今回は弊社エンジニア採用サイトリニューアルのお知らせです。 careers.bm-sms.co.jp 何はともあれ、こちらのリニューアルしたサイトをご覧いただければ幸いです！ リニューアルされたエンジニア採用サイト リニューアルの経緯 こちらは私が入社前から弊社内で議論されていたことなのですが、旧サイトは公開後時間も経過してしまっており、 本来ほしいターゲットに対して訴求すべき情報が整理されていない サイトの受け皿としてのゴールがエントリーのみになっている デザインがレガシーな印象で更新されることもないため、むしろネガティブな印象をもたれかねない という課題が社内からも指摘される状況になっていました。 リニューアル前のエンジニア採用サイト これらを改善し、その後も弊社エンジニアリング組織の変化とともに更新を行っていくことを目的として今回のリニューアルを実施しました。 採用サイトとテックブログ、コーポレートサイトの違いについて 各社さまざまとは思いますが、弊社のエンジニアリング組織の場合は下記のような違いがあると考えて対外発信させていただいています。 ブログ： 技術・チーム・執筆者によるスナップショット 採用サイト：エンジニアリング組織での組織運営上の数値や体制など更新されるコンテンツ コーポレートサイト：エンジニアなど特定の職種にフォーカスしない経営的コンテンツ 採用サイトで触れていること エンジニアリング組織の価値観や現在の状況、他社と比べた時のポジショニングや醍醐味の違い、といったことにフォーカスして記載させていただいています。 About / エス・エム・エスとは？ Business / エス・エム・エスの戦略的事業領域 Development / エス・エム・エスの開発組織 TechStack / エス・エム・エスの技術スタック People / エス・エム・エスの人 Challenge / エス・エム・エスの技術的チャレンジ Culture / エス・エム・エスの文化・働く環境 Read More / エス・エム・エスをもっと知る Positions / 募集職種 我々の事業ドメインは介護ですが、個人的にはエンジニア目線からすると社会構造に注目して事業を行っている会社とみていただいた方がわかりやすいように感じています。介護というと高齢者の問題と考えてしまう方も多いものの、ヤングケアラーなどの課題提起も世の中一般で目につくようになってきたように、現役世代にとっても人ごとではない状況です。 では「我々エンジニアは何ができるのか？」というと、今までも磨いてきたし、これからも磨いていくWebの能力スキルが存分に活かせます。当然働き方としても普通にパフォーマンスを発揮できるようにしてありますし、今後とも継続・発展できるように組織として成長させていきます。 ・・・と言うことが伝われば幸いです！ 今後採用サイトで発信していくこと 今後とも、例えば下記のような内容について継続的に更新していきます。 各チームの具体的な技術チャレンジ エス・エム・エスでの具体的な働き方がイメージできる粒度での組織情報（所属する可能性のあるチーム詳細など) 今後ともテックブログとともに採用サイトも折に触れご覧ください。

このブログの運営に携わっているエンジニアの @koma_koma_d です。 5月11日に開催された「DevRel Meetup in Tokyo #74 〜アウトプット〜」で、「普通のWeb系事業会社のブログ運営」というタイトルで発表してきました。 devrel.connpass.com 発表にいたるまで きっかけは、3月に公開した以下のブログ記事で、運営の方から「発表しませんか？」とお声がけをいただいて発表することになりました。 tech.bm-sms.co.jp 当初はブログ記事の内容をそのまま発表するような形を考えていたのですが、私の後に登壇するのが株式会社メルカリで技術広報を担当されている @afroscript10 さんということだったので、差別化できるような内容でお話ししたいなと考えました。そこで、たくさんのエンジニアがいるわけでもなく、特定の技術に尖っているのでもない「普通のWeb系事業会社」においてどのようにブログを運営しているのか、という切り口でお話しすることにしました。 私が企業のテックブログといわれてすぐに思い浮かぶのは、 メルカリ や クラスメソッド のブログでした。これらのブログは更新頻度も高く、自分自身記事を参照することも多いです。この域までブログを発達させられれば、非常に技術広報としての効果も高いだろうと想像します。とはいえ、弊社のようなそこまでエンジニアが多いわけでもない（それなりにはいますが）会社で、同じあり方を目指そうとするのはなかなか難しいと感じているのも事実です。同様の悩みを、似たような規模や特徴をもった会社の技術広報担当者の方々も持っているのではないかと考え、上記の切り口を設定しました。 発表当日 当日は以下の資料で発表をしました（公開用に事後的に少し手は入れています）。 3つのテーマ（チーム、コンテンツ、組織全体との関わり）に分けてお話ししたのですが、前2者はどこの会社でもやはり課題になる部分なので、共感していただけたり、参考にしていただけたりしたようで、よかったです。最後のものについては、まだ弊社としても実験段階でもあるので、これからまた何かにつながれば発信できればと思っています。 オンラインでの発表は初めてだったのですが、運営の方などがビデオをONにして頷きながら聴いてくれたので非常にやりやすかったです。感謝！ 発表中は余裕がなくてみられなかったのですが、Twitterでもたくさん反応があり、ありがたかったです。全部は掲載できませんが、一部を抜粋してご紹介します。 「テックブログが採用へ直接結びつくことは少ないからこそ、限られたリソースでどんなコンテンツを出すかが重要」 周りにそのことを根気よく伝えていくことが重要になりそう。 #DevReljp — なないろ (@nana_nigiiro) 2022年5月11日 あー、良い視点だー。これ良い！ #devreljp #devrel pic.twitter.com/Msz4TYH1xK — Atsushi@MOONGIFT (@goofmint) 2022年5月11日 「社内のエンジニアが面白いと思うもの」を面白いと思うかどうかでマッチしているかどうかっていうの、言われてみれば心当たりがある。 #devreljp — れれのーと (@rerenote) 2022年5月11日 おわりに 発表資料を作るなかで、「もっとこうしたらいいんじゃないか」などと考え直すこともあり、いい機会になりました。私たちも発表のなかで言っていることをすべて綺麗ににできているわけではないので、もっと上手くブログ運営していけたらと思います。 最後にはなりますが、貴重な機会をくださり、また当日の話しやすい雰囲気づくりにもご尽力いただいた DevRel Meetup in Tokyo の運営のみなさま、ありがとうございました！ Appendix 他の登壇者の方の資料 本日のDevRel Meetup in Tokyoで発表した発表資料を公開します #devreljp #devrel https://t.co/BPXxFxCbCc — 小島優介(ハピネスチームビルディングの人) (@kojimadev) 2022年5月11日 今日の発表資料です：） SpeakerDeck https://t.co/R9fnBu71vv Google slide https://t.co/hUtHanpl1Y #devreljp — afroscript@mercari R4DのOutreach (@afroscript10) 2022年5月11日 参加者などによるまとめ togetter.com 質疑応答に入りました。 #devreljp #devrel pic.twitter.com/Bxbp23cgv6 — YOKO（ひろむママ） (@i57WmpPHbRytBnM) 2022年5月11日 本日のDevRel Meetup in Tokyo #74 で学んだ事を書きました #devreljp #devrel https://t.co/LjmMNmT17H — 小島優介(ハピネスチームビルディングの人) (@kojimadev) 2022年5月11日 発表中で言及した資料など kakakakakku.hatenablog.com newspicks.com www.shoeisha.co.jp

※この文章は死に関する内容が含まれています。 ※この文章は漫画のストーリーに関するネタバレを含みます。 あなたは、人生最期の食事に何を食べたいですか? 家族の作った肉じゃが、採れたての魚で作ったお刺身、もしかしたらおせんべいなんかを食べたい人も居るかもしれません。 では、それを食べると死期が近づいてしまうとしたら? 「突然そんな事を言われてもわからない。」 「実際にその状況になってみないと…。」 「家族はそれをどう感じるだろうか?」 色々な考えが浮かんできます。 私が開発を行っているカイポケ訪問看護という Web サービスの向こう側では、看護師と患者、またその家族は、この様な難しい判断を迫られているのだと思います。 訪問看護を知る上では外せない終末期医療。これをより深く知るためにはどうすれば良いか、サービスの開発をしながら私も時々考えています。 開発者が現場を深く知るために、エス・エム・エスが行っている取り組みとして事業所訪問や事業所インタビューがあります。しかし、看取りの現場を体験するというのは難しく、あくまで想像するしかありません。私は、現場で行われている訪問看護の看取りがどの様なものか、という知識を補強する情報として漫画というフォーマットにとても助けられました。 今回は、この訪問看護の漫画における看取りの話を紹介しながら、その倫理観について考えてみようと思います。 紹介する漫画は、私が一番最初に読んだ訪問看護の漫画である 広田奈都美 さんの「 おうちで死にたい～自然で穏やかな最後の日々～ 」です。看護師でもある作者が訪問看護の取材を反映しながら、一話完結形式で訪問看護師とその患者、患者の家族を描いた作品です。タイトルからもわかる通り、看取りについて描かれた内容が多い作品です。 主要な登場人物はこちらの看護師の三名。 花 おかっぱの新人の訪問看護師。研修医時代に訪問看護に出会う。 馬渕 メガネをかけた花の先輩看護師。病院での看取りに対する違和感から訪問看護師となった。患者の気持ちを汲み取ろうとしすぎるところがある。 持田 花と馬渕の先輩。所長と一緒に訪問看護ステーションを立ち上げたベテラン看護師。 まずは「在宅で効果的な療養が行えていない状況を許容する」という話が登場する 第6話「花が訪問看護師になった理由」 を紹介してみます。 この話は、看護師という職業に対して自信が無くなる様な事件を経験した花が、訪問看護の実習で出会った様々な家族と、それに対する先輩訪問看護師の考え方に影響を受け訪問看護師を目指すという内容です。 話の中盤で初めて訪問看護サービスに同行するのですが、ここで先輩訪問看護師の馬渕は患者の高齢の妻から聞かされた「痰の吸引が夜間に十分に行えていない」という療養状況をサラッと許容してしまいます。 出典：広田奈都美「おうちで死にたい～自然で穏やかな最後の日々～①」 / 第6話「花が訪問看護師になった理由」 / 2017年フォアミセス7月号掲載 病棟で行われている「効果的な療養」をするべきと考えていた花はこれに面食らいますが、馬渕から説明をされる中で、夫婦が以前から家で亡くなりたいと話をしていた事を聞かされます。 この夫婦は客観的に判断できる療養上のリスクよりも主観に基づいて自宅に居るという事を優先し、持田はこれを支持しているのです。この話には他にもいくつか異なる家庭の話がダイジェストで出てきますが、お金が無いから施設に入れられず看護をする気もない家庭、姑いじめをした母を一人で看護する息子等、必ずしも望んではいない状況で在宅看護をしている家庭も出てきます。持田はこれも「そうなる歴史があって様々な要因でそうなったって思う…」と受け入れます。 まだ訪問看護というものをあまり理解していない当時の私は、この話を読んで「それって正しいのだろうか」と、もやもやしていたのを覚えています。 第18話「癌になって初めて妻に弱い姿を見せられた年上夫」 は、働き盛りのプログラマーという自分に身近な話でした。末期がんで余命宣告を受けているにも関わらず、死を受け入れられない妻のために、患者は元気な姿を演じます。病状が悪化する中、なし崩し的に最期を迎えるべきでは無いと考えた馬渕は主治医とケアマネージャを同席させ、患者の妻とケアカンファレンスを開催します。 ここで馬渕は「患者・家族の防衛機制に対して侵襲的なコミュニケーション *1 」をしてしまいます。患者の妻は死という現実を受け入れられず動揺し、妻に対して病状を隠していた患者を激怒させてしまいます。患者と看護側の信頼関係が崩れてしまった、とてもマズい状況です。 出典：広田奈都美「おうちで死にたい～自然で穏やかな最後の日々～③」 / 第18話「癌になって初めて妻に弱い姿を見せられた年上夫」 / 2018年フォアミセス6月号掲載 客観的に正しい情報をありのまま伝える、という事は、情報伝達としては正しいのかもしれません。しかし、ここで重要視されて描かれているのはそういった事ではありません。患者とその家族が何を望み、何を望まないか。そしてそこに医療従事者として伝える事のできる情報を交えつつ、踏み込んでも大丈夫な範囲を見極めながらコミュニケーションしようとしています。 第27話「おばちゃんナースの底力」 は、人間力の高いおばちゃんナースと花がペアになって訪問看護をする話です。花は資産家の一族に嫁入りした女性が、他の家族から患者のケアを押しつけられているというのを目にします。一家の空気を読みながらコミュニケーションしつつ、女性に対してのフォローも忘れないおばちゃんナースに対して、花は良かれと思って同情の声を掛けます。 しかし、これが相手には自分の立場に対する否定として捉えられてしまい、女性に怪訝な表情をされてしまいます。悩んでいる花に対して、訪問看護ステーションの所長は「病院では病院がルール、訪問看護は家庭がルール」と説明します。 出典：広田奈都美「おうちで死にたい～自然で穏やかな最後の日々～⑤」 / 第27話「おばちゃんナースの底力」 / 2019年フォアミセス2月号掲載 物事を勝手に判断せず、その家庭の生き方、暮らし方を尊重することが訪問看護においては重要なんだ、と所長は言います。おばちゃんナースも、過去に入浴サービスの提案をしたり女性をかばったりした際に一家との関係が悪くなってしまい出入り禁止になるところだったとの話を聞き、花は自分が感じる正しさだけでは物事を判断できないという訪問看護の難しさを学びます。 最終話「馬淵が訪問看護師を志した理由」 は、物語全体を通しても何度も扱われる「病棟での看護」と「在宅での看護」の違いに特に注目した話になっています。病院の看護師時代の馬渕は、命を守り、事故を起こさないように、そんな事を考え忙しい仕事を精一杯こなしていました。ある日「在宅の基本は家族」という訪問看護師の持田と出会い、病院での看護と自身が持っている看護に対しての考え方のギャップに違和感を持ち始めます。そんな中、ある患者から答えの出せない質問をされます。 出典：広田奈都美「おうちで死にたい～自然で穏やかな最後の日々～⑤」 / 最終話「馬淵が訪問看護師を志した理由」 / 2019年フォアミセス8月号掲載 馬渕は言い訳をしつつその場を逃れますが、考え方と仕事のギャップはどんどん大きくなっていきます。その後も悩みながら仕事を続ける馬渕の担当患者の家族から自宅で看取りをしたいという話が持ち上がります。 そして持田と共に訪問看護での看取りを進める中で、馬渕は患者に寄り添いケアを行うのが好きだという自身の看護観を発見して行きます。 全編を通して、持田は患者の意志を尊重しようとする気持ちが強い訪問看護師として描かれていますが、実際の訪問看護師もこの様な気持ちで仕事をされている方は少なく無い様です。 サービス開発を行う中で「細かいケア内容を書きたいのに文字数が足りなくて書ききれない」といったお叱りの言葉があるという話を聞いたり、業界紙のコロナ禍特集の中で「感染症対策で接触時間を短くする必要があり、本来できていたはずの看護ができず落ち込んでいる」という記事を読んだりすると、訪問看護師には、本当に患者に寄り添って看護をするのが好きな方々が多いのだろうなと感じます。 以上、4つの話を紹介してみましたが、患者が望む「生きる」というものがどういったものなのか、看護する側と看護される側、その家族、それぞれが迷いながら考えるという内容となっています。作中の表現は多少誇張された表現になっているかもしれませんが、私達のユーザー企業である訪問看護事業所と、ユーザー企業のユーザーである患者とその家族が、どう悩み、考え、結末を迎えるのか。そんな事が仮想的にではありますが、見ることができているのではないかと思います。 今回紹介したのは看取りに注目した話でしたが、他にも精神科訪問看護や認知症についての話も描かれています。続編となる「 ナースのチカラ 〜私たちにできること 訪問看護物語〜 」では主要メンバーが新たに加わり、連続したストーリー形式で病棟ナースが大切にしている考え方や介護施設が抱える課題、更には新型コロナウィルス感染症下での看護にも切り込んで行きます。 紹介した漫画の話からもわかる通り、看取りを行う際、患者自身にとっては自分の生をどう終着させるか、そういった難しい意思決定を行う必要があります。 この意思決定を支援するためのアドバンス・ケア・プランニング(ACP)別名人生会議というプロセスが存在します。 「人生会議」とは、アドバンス・ケア・ プランニング（Advance Care Planning）の愛称です。 アドバンス・ケア・プランニングとは、あなたの大切にしていることや望み、どのような医療やケアを望んでいるかについて、自ら考え、また、あなたの信頼する人たちと話し合うことを言います。 あなたの希望や価値観は、あなたの望む生活や医療・ケアを受けるためにとても重要な役割を果たします。 誰でも、いつでも、命に関わる大きな病気やケガをする可能性があります。 命の危険が迫った状態になると約70％の方が、これからの医療やケアなどについて自分で決めたり、人に伝えたりすることができなくなるといわれています。 もしも、あなたがそのような状況になった時、家族などあなたの信頼できる人が「あなたなら、たぶん、こう考えるだろう」とあなたの気持ちを想像しながら、医療・ケアチームと医療やケアについて話合いをすることになります。 その場合にも、あなたの信頼できる人が、あなたの価値観や気持ちをよく知っていることが、重要な助けとなるのです。 – 人生会議とは？ | ゼロからはじめる人生会議 (www.med.kobe-u.ac.jp) ACP に関連する用語としてインフォームド・コンセントや事前指示 Advanced Directive(AD) がありますが、インフォームド・コンセントは「どの様な医療を選択するか合意するプロセス *2 」で、あるタイミングでの医療選択に係るプロセスであり、AD は「自身で医療選択が行えない場合、その選択をどの様に行うかを決めておくこと(文書化すること) *3 」です。 対して ACP は、プロセスの結果得ることができる意思決定そのものよりも、健康状態が変わりゆく療養者がどの様な状況でどの様に意思決定を行うのかを、継続的なプロセスを通して関係者が理解しようとする事が重要とされています。 この違いは、ADがあくまでADを作成した時点での意思決定であり、ADが利用される状況の複雑性が考慮しきれておらず、ADが利用される局面で患者が望むであろう意思決定が行えるわけでは無いといった課題を反映したものです。ACP では患者の家族や医師、看護師等が「こういった時に患者はこう判断するだろう」という感覚を継続的なプロセスを通す事により獲得し、事前に想定しきれていなかった局面に対しても患者が望むであろう意思決定を、例え患者本人でなかったとしても行えるという状態を目指すことにあると言えます。 また、ACP は大きく分けて「健康成人に対するACP」と「病気を持った患者に対するACP」に分かれています。 前者は健康な状態では将来的な医療的選択が自身にもたらす影響に関してのリテラシーや興味が高くなく *4 、将来的に意思決定が変わる可能性があるという実態をを考慮し、ACPやAD等、終末期医療に関する理解を深めるという事が目的となります。 後者は自身の健康状態をコントロールするための意思決定を行える環境を作るという事を目的としていて、ACPを経て行われる意思決定が実際に運用されるのはこのフェーズになります。予後1年を目安として行われますが、早すぎるACPは患者が望まず利益より害が多い *5 。ADを作成するタイミングが早すぎると非現実的な選択をしたり、遅すぎても患者の嗜好を反映できない *6 。更には疾病によって機能低下の波が異なるため終末期の判断が難しい。といった課題もあり、タイミングを見極めるのが非常に難しいものになっています。 漫画の中でも、最初は深く看取りには踏み込まず、患者やその家族との対話を通して心理的に受け入れ可能かどうか判断し、医療者としての観点を踏まえつつ、患者に合わせて言葉を選びながら看取りの話を切り出しています。ACPの対象を決めるためのサプライズクエスチョン *7 やSPIC *8 といったツールもある様ですが、正解となるやり方がある訳ではありません。ツールによって一定の指標を見るという事より、その人の生にとってどうするのが良いのかという事を考え抜く、という事がACPにおいては大切とされているのではないでしょうか。 訪問看護という学問は、コミュニケーションというものをとても大切にしているという印象を強く持っています。漫画の例を見ても普遍的・客観的な価値尺度での評価を絶対視するわけでは無く、患者やその家族の多様性を許容し、非常に曖昧で、揺れ動く感情というものを重要な判断基準としています。劇中で、医学的には効果的な療養が行えていないように見える患者に対して、積極的な介入を行わない先輩看護師馬渕の行動を新人看護師の花が不安がる描写があります。 しかし、これは医療者である花の客観的視点です。馬渕は患者及びその家族の「おうちで死にたい」という主観を時間をかけて汲み取る事によって、患者と意思疎通が取れなくなった状態でも、自宅での死に寄り添うという判断が行えているのです。ゴミ屋敷のゴミも、その人にとっては大事な物かもしれない。不貞を働いた夫でも、妻にとっては最愛の人かもしれない。普遍的・客観的な事実からは読み取れない大事なものを劇中の看護師は見つけようとしています。 ソフトウェアエンジニアである私は、プログラムを書くという仕事をする際に数値的な根拠やテストコードでの正当性証明という普遍的・客観的事実によって行うのが重要だと考えています。これは、上記の価値観とはだいぶ異なります。逆に、チームビルディングや1on1の実施、コミュニケーションが重要となる場では、こういった曖昧な感情というものも大事なものとして扱っています。 過去記事 にもコミュニケーションにおいては「あそび」が重要だと書いたのですが、それはコミュニケーションには曖昧な部分を許容する力が必要だと感じていたからです。訪問看護で大事にされている感覚に近いものを自分も少しは理解できているのかもしれません。 tech.bm-sms.co.jp 仕事を通して訪問看護を知るまでは、終末期医療、それも在宅での看取りに関してリアルに想像する事はありませんでした。それが今では、自身の開発しているサービスを通して、人の生に関わっているという実感に変わっています。 私もいつか死を迎えます。その時に、自分の人生の終わりの片隅に関わる様な仕事ができていたら嬉しい。そう思いながら仕事をしています。 最後になりますが、この記事を読んで訪問看護の世界に興味を持ち、その世界を作っていく事に関心を持ってくれた方は、ぜひ弊社の 門 を叩いてみてください。 r-kaipoke.bm-sms.co.jp (筆者: プロダクト開発部桐生) *1 : 患者・家族の防衛機制に応じて侵襲的でないコミュニケーションを – [PDF] アドバンス・ケア・プランニングいのちの終わりについて話し合いを始める p.54 *2 : インフォームドコンセントとは、患者・家族が病状や治療について十分に理解し、また、医療職も患者・家族の意向や様々な状況や説明内容をどのように受け止めたか、どのような医療を選択するか、患者・家族、医療職、ソーシャルワーカーやケアマネジャーなど関係者と互いに情報共有し、皆で合意するプロセスである。 – インフォームドコンセントと倫理 | 日本看護協会 (www.nurse.or.jp) *3 : Advance directives explain how you want medical decisions to be made when you're too ill to speak for yourself. – Advance directives & long-term care | Medicare (www.medicare.gov) *4 : Participants were asked to imagine that they were in this scenario and to choose either: all life support treatments; try life support with an option of stopping; or no life support. They were then asked how certain they were about this decision. Forty-five percent of participants were uncertain about their decision. – Uncertainty about advance care planning treatment preferences among diverse older adults - PubMed (pubmed.ncbi.nlm.nih.gov) *5 : This reflected a belief that if ACP were initiated at an earlier time-point, patients would simply not be ‘unwell enough’ for ACP 21, 25, 27. Introducing ACP later in a patient's illness trajectory was also considered to allow patients to focus on living in the present by ‘carrying on as normal’ while they still felt reasonably well 5, 30, 38 and ‘allow patients to enjoy what is left of their remaining lives’ – Advance care planning for cancer patients: a systematic review of perceptions and experiences of patients, families, and healthcare providers - Johnson - 2016 - Psycho-Oncology - Wiley Online Library (onlinelibrary.wiley.com) *6 : a poorly chosen target patient population that is unlikely to need an AD in the near future may lead to patients making unrealistic, hypothetical choices, while assessing preferences in the emergency department or hospital in the face of a calamity is notoriously inadequate. – Strategic targeting of advance care planning interventions: the Goldilocks phenomenon - PubMed (pubmed.ncbi.nlm.nih.gov) *7 : The surprise question — “Would I be surprised if this patient died in the next 12 months?” — has been used to identify patients at high risk of death who might benefit from palliative care services. – The “surprise question” for predicting death in seriously ill patients: a systematic review and meta-analysis (www.ncbi.nlm.nih.gov) *8 : SPICT™ helps identify people with deteriorating health due to advanced conditions or a serious illness, and prompts holistic assessment and future care planning. -- SPICT – Supportive and Palliative Care Indicators Tool (www.spicy.org.uk)

2021年12月 に入社した丸井です。 エス・エム・エスに入社する前は、大企業向けのソフトウェアを開発している会社や、スタートアップで主にバックエンドの開発をしてきました。 スタートアップは 2 社経験しており、1社目では社長・技術責任者に続く 3 人目の社員として、当時ベータローンチを迎えたばかりだった Web システムの開発をしたり、システムを提供していたパートナー企業の現場に足を運んで課題ヒアリング、時には現場の作業のヘルプに入ったり...と、色々やってました。 2 社目のスタートアップ(前職) にも創業間もないタイミングで加わり、1 社目とは打って変わってユーザーからやや遠い領域のシステムの開発や、技術検証などをやっていました。 そして、現在エス・エム・エスでは、介護事業者向け経営支援サービス「カイポケ」の開発チームに所属しています。 エス・エム・エスを知った経緯 前職のスタートアップでサービスの立ち上げを経て、継続的な開発・運用フェーズを経験するなかで、個人的にプロダクトに向き合えていないと感じる場面が増えてきていました。 なぜそう感じるのか？を掘り下げてみると、プロダクトが提供する価値を理解し、そしてその価値を高めることに貢献できるイメージを持てていない、ということが主な理由だと気づきました。 「プロダクトが提供する価値」というとかなり固い表現ですが、要はそのプロダクトが「誰をどう幸せにするのか」という点についてあまり咀嚼できていない状態でした。そしてそんな状態だったので、今後何をしていけばよいかについても迷子になっていました。 立ち上げフェーズでは作ること自体に没頭し、そして「作ってみないと分からない」ことを理由に疑問の解消を先延ばしにしていたように思います。 自分なりに貢献できることを模索するため創業メンバーと話し合いを重ねながらも、他の道も探ってみたいと感じていたタイミングで、偶然エージェントからエス・エム・エスを紹介してもらいました。 エス・エム・エス入社の決め手 カジュアル面談やその後の選考を通して、高齢社会の課題にアプローチするプロダクトの価値や今後の可能性を感じるとともに、エンジニアチームと事業チームが互いを尊重しつつプロダクトを作り上げている点について、とても良い印象を受けました。 「互いを尊重しつつ」と一言で書きましたが、これは単に仲良くやってるという話ではなく、時には侃々諤々（かんかんがくがく）なやり取りをしながらも誠実に対話を重ねているという意味合いです。 面談でお会いした現場のエンジニアから経営層の方まで、チームの関係性についての話に一貫性があったのも好印象でした。 ちなみに、ちょうど選考を受けているタイミングの前後で、上記のような関係性に至った過去の経緯についても触れられている記事が投稿され、個人的に納得感が増しました。 tech.bm-sms.co.jp 価値あるプロダクト、そして関係者が一丸となってプロダクトを作り上げることができる可能性を感じ、そこに自分も加わってみたいと思う気持ちが芽生えたことが決め手となり、入社を決意しました。 入ってみてどうだったか 前述の内容については、ほぼ期待通りだと感じています。 特に互いを尊重し合う姿勢については想像以上で、一人一人の意見を引き出すことを非常に大切にしています。 反面、意外だったこともありました。 例を挙げると、私は直近スタートアップで過ごしていたため、エス・エム・エスのように成熟したプロダクトを持つ組織では、開発を進めるにあたって窮屈に感じるような場面に出くわすことも覚悟していました。 ところが、これまでそのような場面にはあまり遭遇していません。もちろん全く無いわけではありませんが、前職のスタートアップと比較してみても遜色なく、むしろ自由度が高いように感じる点も多くあります。 このあたりは立ち上げられたばかりのチームに配属されたということとともに、「フェアプロセス」を意識して開発組織が運用されていることも関係しているように思います。 tech.bm-sms.co.jp 蓄積したドメイン知識を掘り下げるおもしろさ 入社してからは、主にカイポケのアーキテクチャ改善に向けたドメインモデリングやプロトタイピングに取り組んでいます。 エス・エム・エスでは、これまで15年以上にわたって上記のプロダクトを提供しており、人・プロダクト・運用オペレーションに豊富なドメイン知識が蓄積されています。 これらドメイン知識をドメインエキスパートと力を合わせて掘り下げることで、これまでに積み重ねてきた価値を再発見できることは醍醐味です。 例えば、一見冗長な作りに思えるところに現場でありがちなミスを防ぐための工夫が盛り込まれていたり、無駄に思える運用オペレーションにユーザーの満足度を上げるポイントが含められていたり。 同時に今では不要になった機能や形骸化したオペレーションも蓄積しているので、それらを解きほぐすことができるのも、ある意味醍醐味と言えます。 エス・エム・エスでの課題との向き合い方 エス・エム・エスの開発チームの特徴として、個人の裁量の大きさが挙げられます。 課題解決方法を自由に選択できるというだけでなく、そもそもどんな課題に取り組むかも自主的に決めることができるため、入社当初は多少戸惑うほどでした。 そのような環境で個人的に意識しているのは、まず自分がやりたいことを考えた上で、周りを巻き込んだ時に良い影響がありそうであれば巻き込んでみる、というものです。 例えば、現在所属しているチームではドメインモデリングと並行して技術選定や開発運用の感覚をつかむための「実装トライアル」を実施していますが、これも元々は個人的にコーディングする機会を確保したいと感じたことをきっかけに、チームメンバーに呼びかけて始めたものです。 呼びかけた当初は、Kotlin や GraphQL のキャッチアップ、そして最近あまり使っていなかった AWS に少しでも触れる機会が作れると良いな、というくらいに考えていました。 ところがトライアルを始めてみるとメンバーから次々にやりたいことが出てきて、結果、GraphQL のフェデレーションを試したり、将来的に必要になりそうなアクセス制御のパターンを実装してみたり、AWS の CDK Pipelines や AppMesh が整備されていったりと、自分一人では考えつかなかった様々な取り組みにつながっています。 このあたりは同じチームの空中さん @soranakk の入社エントリでも触れられている内容です。 tech.bm-sms.co.jp 社内の他のチームにおいても読書会や勉強会が盛んに行われているので、周囲を巻き込んだり、面白そうな企画に参加してみるということが、エス・エム・エスの開発チームの文化として浸透しているようです。 (ちなみに、私が今社内で参加している会は『モノリスからマイクロサービスへ *1 』読書会、『Node.js Best Practices *2 』勉強会、『Production Ready GraphQL *3 』読書会などです) 前述したとおり、入社当初は個人の裁量の大きさに戸惑うこともありました。しかし、今では個人の裁量に委ねられているからこそ、自分に合った課題との向き合い方やプロダクトへの貢献の仕方を模索できる環境になっていると実感しています。 *1 : https://www.oreilly.co.jp/books/9784873119311/ *2 : https://github.com/goldbergyoni/nodebestpractices/blob/master/README.japanese.md *3 : https://book.productionreadygraphql.com/

はじめまして。エス・エム・エスでエンジニアをしている宮坂です。 これまでは、主にWebサービスを提供する会社でエンジニアやマネジャーをしてきましたが、2022年1月に入社し、エンジニアとして介護事業者向け経営支援サービス「 カイポケ 」の開発に携わっています。 入社して間もないですが、エス・エム・エスに入社して感じたことを書いてみようと思います。 今まで何をやってきたか 学生時代からコンピュータを使った仕事に就きたいと思い、大学では情報工学を専攻。大学卒業後に入社した会社では、新規ビジネスの立ち上げを担うを行う部署に配属され、その立ち上げに必要な開発を担当していました。組込み機器の開発からWebアプリケーション、インフラまで様々な技術的な経験ができました。 ただ、その組織の性質上、プロトタイプの開発で終わることが多かったため、世の中の人たちに役に立つものを作りたいと思い、転職。その後、Webサービスのバックエンドのアプリケーション開発を主にWebサービスの会社を2社ほど経験しました。アプリケーション開発だけでなく、安定的にサービスを提供するための全体のアーキテクチャを考慮したシステム構築やチーム間の仕様調整なども経験し、エンジニアとして良い経験ができたのではないかと思っています。 また、どちらの会社でもエンジニアだけでなく、マネジャーもやったりしていたので、役割としても様々な経験をすることができました。何度かマネジャーとプレイヤーとで行き来しましたが、エンジニアとして手を動かしつつもマネジャーとしてうまくいかなかったことをどうやって他の人は解決しているのか？という視点も持ちながら働くことができて、いろいろと視野が広がったような気がしています。 エス・エム・エスに入社した理由 エス・エム・エスという会社を知ったのは、スカウトが来たときでした。正直、それまではどんな会社なのかよくわからず…。 ただ、介護や医療という分野は、自分たちの親の世代に差し迫っていることを実感していることもあって、今後のニーズも高く、「世の中の人たちに役に立つものを作りたい」という自分の指向にもマッチし、自分の経験を活かすには良いかも知れないと思い、話を聞くことにしました。 今まで経験した転職活動に比べると、多くの方々と面接や顔合わせをさせてもらいました。 そのお陰で、 ビジネスの戦略に筋が通っていて、堅実な開発をしている印象を持った 技術的負債の返却にエンジニアだけでなく会社全体で注力する姿勢が垣間見えた 一人で気負うことなく、チームで一緒になってゴールを目指せそう というようなことを思いました。 特に介護業界は慢性的な人手不足で、テクノロジーを活かして課題を解決していくことに意義を感じましたし、新たなデバイスなどを活用していく将来のイメージを面接の中で語られていて、自分の経験も活かせるし、さらに新たな技術的なチャレンジも今後できそうという面白さを感じました。 また、それぞれ別の会社で昔の同僚だった、 光宗さん と 岩田さん がいたのも大きかったと思います。特にリファラル採用というわけではなかったのですが、昔一緒に働いていた仲間とまた一緒に働けるというのは心強いという思いもあり、入社することにしました。 入社してどうだったのか 現在は、カイポケのアーキテクチャ改善に携わっています。 日頃接することのない介護業界の業務知識を得るのは難しく、聞き慣れない言葉も多いのですが、介護の現状や高齢社会を迎える日本の将来を考えると、介護業界をITの力で支えていくことにやり甲斐を感じつつ、日々キャッチアップしています。 入社すぐのオンボーディングには力を入れてやってもらいました。 オンボーディング担当者を一人を付けて様々なサポートするパターンが多い中、入社前から、いち早く立ち上がるためにはということで、チーム全体でオンボーディングを考えてもらったようでした。事前にオンボーディングタスクを洗い出し、誰が何をやるのか分担してもらうことで、自発的にオンボーディングに関わってもらったような気がしています。 こういったところにも表れているのですが、会社の文化として、担当一人が黙々と作業していくというよりは、チームみんなで作業する時間を確保し、その時間を使って物事をドライブしていく文化なんだなということを感じています。設計やプログラミングなども話をしながら作業を進めることが多く、一人で気負わず相談しながら進められていて、特に右も左もわからない時期に様々な意見や気付きをすぐにインプットしながら、キャッチアップできたことは非常に良かったなと思っています。 お陰で早い段階でチームに馴染むことができましたし、自分も何をやったらよいかわからないということもありませんでした。現在フルリモートでの勤務で、最初はどうなるかなという不安はありましたが、違和感なく今の仕事に取りかかれた気がしていて、チームのみなさんには感謝しています。 また、今のチームでは、ソフトウェア設計手法に DDD を採用し、アーキテクチャの改善に向けて介護領域の業務を再度分析しています。 Domain-Driven Design Starter Modelling Process に倣い、定義されている一つ一つステップを踏みながら、開発対象をソフトウェアに落としていっています。（Domain-Driven Design Starter Modelling Process の取り組みについては、今後具体的にご紹介できればと思っています。） 技術的負債やアーキテクチャの改善に対しては、今までの自分の経験ではエンジニアだけで仕事を進めていくことが多かったのですが、DDD を通して、エンジニアだけでなく、PdMやドメインエキスパート、デザイナー、QAが一丸となって進めています。入社前に感じたプロダクトの改善を組織全体で解決していこうという姿勢を体感することができていて、技術的な改善には比較的進めやすいのかなということを感じています。 これから アーキテクチャ改善は始まったばかりです。 自分としてはまだ触れたことのない Kotlin や GraphQL など新たな技術に触れながら、モダンなシステムアーキテクチャを採用しプロダクトを作り上げていくフェーズに不安を感じつつも、新たな価値が生み出せることに非常にワクワクしています。 自分は知識も技術もまだまだですが、今後より加速する高齢社会に対して、より良いプロダクトを提供し続けられるように、今後もチーム一丸となって頑張っていきたいと思っています。

はじめまして。株式会社エス・エム・エスに、2022年1月1日からEM(Engineering Manager) として入社した @emfurupon777 です。 少し前からEMという呼称がプロダクト開発、エンジニアリングの話題の中で普通に使われるようになり、SNSやブログ上でもEM自身から、その成果の見えにくさや結果が出るまでの時間軸の長さなどに起因する難しさを意識した発信が多くされるようになってきたように感じています。 今回、私の入社エントリとして、エンジニアリングのトップが存在する組織にEMとしてJOINする際に不安に思った要素と、それに対して取った行動を軽くまとめてみました。 はじめに エス・エム・エスでのEMの位置付け(私なりの理解) 弊社の人事組織としては部長、グループ長などは存在しますが、EMが会社組織上の職責を担っていないこともありえますし、EMでない者・・例えばテックリードが職責を担うこともありえます。実際、私の場合入社時の人事的な配置としては 同じくEMを務める岩田 の下につくという形でした。 が、 @sunaot が実は自らはCTOと名乗っていないころからも推測できるように、弊社もいわゆる普通のWeb企業。肩書きにこだわらない、ロールベースのカルチャーとなっています。正直、人事組織を気にしている人間はほとんどおらず・・というか組織図をみたことがない人の方が多いかもしれませんw 私は何者なのか EMを担うようになった経緯として、私の略歴をあげておきます。 所属 経歴概要 学生時代 ・情報工学ではあったが、学部までのため正直かじった程度の、業務の役には立たないレベル ・第1種、第2種、プロダクションエンジニア(どれも今は名称が変わったり無くなったりしている資格)など基本的な知識をえておくかーくらいな学生(SIer向きw) 1社目 SIer ・新卒入社 ・ケータイキャリア向けの開発をC/C++, Javaで経験 ・事業から遠くて悶々。。というSIerエンジニアにありがちな思いを抱きつつ勤務 2社目 医療Web 事業会社 ・JavaのWebエンジニアとして謎の会社に入社 ・主力サービスをはじめとする複数サービスの担当として開発から運用まで経験 ・メンバー => チームリーダー => EMと役割を変えて経験 ・急成長事業会社のスピード感とコスト感にカルチャーショックを抱きながら勤務 3社目 動画SaaS ベンチャー ・VPoEとしてJOIN ・プロダクトの開発に直接は関わらない、以外はなんでもやる ・資金調達しながら進むベンチャーとしての振る舞いを学びながら勤務 本題 不安要素 さて本題です。今回、ざっと振り返って主に感じた不安は以下のようなものでした。(細かいことまであげるともっと無数にありますがキリがないので、、) 技術的理解が不十分 開発プロセス、技術スタックを把握していないし、その導入経緯も不明 それぞれのエンジニアが書いているコードを(少ししか)見ていない 技術課題の把握やカイゼンの取り組みがどこで誰によって進んでいるか不明 障害対応の役に立てない（SPOF、ボトルネックなどの勘所がわからない） 事業を理解できていない ドメイン知識の習得に時間がかかる 事業領域が複数あり、そのフェーズもさまざまな会社のため、エンジニア以外のステークホルダー・プレイヤー把握が難しい 収益構造の理解がない 人が理解できていない 面接で直接お話しした同僚は少数 共通コンテキストがゼロ（に感じる）の人が多数で、それぞれ何をする人なのかわからない 信頼貯金がない これまで具体的にやってきたこと・得意なことが伝わっていない 同じ課題を乗り越えていないので、心理的距離がある EMとしての(主たる)ミッションを明確化しにくい 中長期のミッションは、究極的に表現すれば「◯◯なエンジニアリング組織にする」がミッションだが・・ 短期のミッションはふわっとしたもの、「要は諸々のバランス」になりがち アドホックなミッション/タスクは、これの優先順位はどう決めましょうね？のような意思決定に関する相談を受けたり、背中を押したりする・・・ことが多いが、ユニバース（全体感）が把握できていない中での振る舞いがむずかしい いざ書き出してみると、どれも一人のエンジニアIC(Individual Contributor)として入社した場合にも不安に思う要素かなと思います。では、どのような順番でこれらに取り組めば良いでしょうか？ 例えばEMを初めて経験した前々職では、担当するプロジェクトに取り組むことで、1->2->3->4->5のように、ある程度限定された範囲から徐々に広げるステップを踏みながら経験していきました。実際前々職で私の場合は約8年かけてEMに役割が移っていったので、主力サービスのコードは読んだことはあるし、事業構造や社内での人間関係や意思決定のクセのようなものまでそれなりに理解したうえでEM業にあたっていたように思います。 ただ、ここにEMとして入社という前提条件が加わると途端に困ったことになります。いちエンジニアとしての経験から・・となると、さすがに8年は大袈裟ですが同じように経験していったのでは、アウトプットとして期待されているものとは異なると思いますし、アウトカムとしても不十分な期間が長そうです。 ここで一人のEMとしては「今、俯瞰してみて大きな課題になっているのはなんなのよ？誰か教えて！」と考えますが・・・。ただ、世の中でこれが与えられることは稀なんだよな、と今回改めて実感しました。なぜなら！その課題抽出自体がEMのミッションに内包されているからですね。。 取りうると考えた手段・取った手段たち ひたすら訊く【全体への対策】 何はともあれ訊くことは大事です。相手の時間も使ってはしまうものの、Slackで素朴に聞いてみると、どこの組織でも人/情報をつないでくれるコネクターが存在するもので、そういった存在は非常に貴重です。 また、Slackやチームのミーティング、1on1してもHRTフルに迎えてくれたことが入社後の心理的安全性の確保に非常に寄与したように思います。 ローカル開発環境の構築【1への対策】 EMなので、まずはエンジニアリングを経験してみたいというのは自然なことですね。実際Github権限を得てcloneし、READMEに従って構築してみる・・とやってみることで、今後入社してくる仲間と同じオンボーディング体験をしてみました。どこの会社でもそうですが、独特のクセのようなものが存在しているが、後から入ったものにしか実感できない課題も散見され、カイゼンポイントが多数見つかるとともに理解が深まりました。 ドキュメント /コミュニケーション探索【1,2,3への対策】 弊社での探索対象はドキュメントはesaやgoogle docs、コミュニケーションはSlack、スケジュール管理はGoogle Calendarでした。 esaについては、オンボーディング用のエントリや同僚の自己紹介エントリから始めて、情報を効率よく得ることができます。ただし、重複して書かれていたり鮮度が落ちていたりというどこの会社でも起きる課題も正直あります。ここは読みながら必要に応じて適宜修正していくというのが基本ですね。(それが難しいわけですが) Slackはリモートワーク中心になった今、EMとしては情報の宝庫です。特定の人物についての「 from: @emfurupon777 」のような検索を起点にすることで、誰も資料をまとめていなくても、誰かに聞かなくても、入社のタイミングや、やってきたこと、場合によってはキャラクターの片鱗まで掴むことができる場合があります。今回もSlackリサーチは参考にさせていただきました。 Google Calendarは特に決定権者の予定をみると将来という、時間軸で少し先の見通しに関して得られるものがあります。個人的にはこれを徹底的にやる人と一切気にしない人とはっきり分かれる印象を持っていますが、ハックしていくと非公開設定だけどあの人とあの人が同じ時間を共有してるっぽいからあの手の話題をここで話してるな・・なんてことが推測できたりします。 グループミーティングへの参加【不安要素1,2,3への対策】 各チームのデイリースクラムを中心に週替わりで参加させていただきました。正直、どこのチームから参加すべきかどのミーティングから参加すべきか・・というのが悩ましいところなのですが、今回キッカケをEMの岩田が作ってくれたためスムーズに開始することができました。 1on1【不安要素1,2,3への対策】 グループミーティング行脚を手がかりにして各エンジニアのみなさんとご挨拶を兼ねた1on1を行っていきました。業務の内容に終始して終わることもあれば、プライベートに近いようなところがメインになることもある・・という感じではありますが、それぞれの人となりを知ってみるというユルいところと、もし相談に乗れることがあればその場で乗ってしまうというスピードをあまりかたく考えずに実施してみるのが重要かなと思って望みました。ただ、完全に行き当たりばったりではなく、前述のSlackサーチを可能な限り行っておくようなことも非常に役に立ちました。 プレイヤーとして振る舞えるポイントを見つけてやってみる【4への対策】 ここは好みの分かれるところです。所属チームが明確なICであれば、そのチームの納期に余裕があり、適度な粒度なタスクを拾ってPullRequest・・といきたいところで、EMでもこういう選択をする方が多いように思いますが、私個人としてはもう少し広く組織に貢献できる可能性を狙って、通常業務を改善できないか探るようにしています。 前職では勤怠のSlack打刻(人事側と調整が必要で意外と手間がかかる)導入をしたのですが、弊社では用語集の改善を選択しました。スプレッドシートで管理されているものがいくつか見つかったのと、ちょうどタイミングよく元同僚の @KawamataRyo が用語集ツールを公開していたので使わせていただくことにしました。 Firebase + Bolt.js + Spreadsheet で社内用語辞典をいい感じに使えるSlack Botを作ってみた。楽しい。 Fuse.js 使ってあいまい検索にも対応しているのがポイント。 https://t.co/CrSoZusQav pic.twitter.com/slDVIXaLdC — Kawamata Ryo (@KawamataRyo) 2022年1月11日 実は、弊社ではAWSを使うことが多いですし、GoogeDriveの外部共有も限定されているのですが、今回Firebase/GCPからSpreadSheetをデータストアとして使う構成というイレギュラーな協力依頼もSRE、情シスの協力をスムーズに得ることができ、今後も業務改善が行えそう・・と実感できました。 他にも勝手にReacji Channelerで情報を集めることなどをトライしています。EMとしてはコミュニケーションの場であるSlackは活用を考えてみる良いフィールドになると考えています。 組織開発アプローチ【4,5への対策】 1,2,3への対策で行ってきたことを総合して、組織開発アプローチで行えることを考え実施します。 AさんとBさんが話せる場を持てるようにファシリテーションを行う 普段話をしているマネージメント層にフィードバックを行う(ご本人としても伝えて良いことに限る) 人材開発アプローチ これは、今回まだ課題の解決としては行っていません。それぞれの関係性の中で学習機会を得たり、輪読会・勉強会などが行われているのを観測しているため、そこにあえて私が追加で働きかけるまで具体的なものを得られていないためです。 Slackで簡単に書籍購入をリクエストできたりするのがうまくワークしているのかもしれません。 tech.bm-sms.co.jp まとめ 取り止めもなく取りうる手段と私の経験をあげてきましたが、ICと比較して特徴的になる傾向にあるのは組織開発アプローチかもしれません。 天才的に強いエンジニアがいるんだからマネージャーはいらないのでは？という有名なGoogleのProject Oxygenの結論を地でいくようなことを考えている希少種がEMだと思っています。(個人的には、感覚的にも経験的にもEMよりはテックリードと呼ばれたいエンジニアが多いように感じています) この記事を通してEMが入社する際の参考になったり、EMがどんなことを考えて参加してきているか、をご理解いただくのに資すれば幸いです。 なお、弊社でもEMを積極採用中です。まだ大きくなり切ってはいないが組織開発が不要なほど小さくはない。というフェーズこそ組織開発経験にもってこいなので、興味がある方はぜひカジュアル面談からお話しさせてください。 また、今回はあえて触れていませんが、EMの大きな役割として採用があります。 エンジニア経歴をお持ちでキャリアの一環としてエンジニア採用を一緒にやってくれる方 あるいは採用人事でエンジニア採用に深くコミットしていきたい方 も募集していますのでこちらも気軽にご連絡いただければ幸いです！

はじめに エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。エンジニアとしての職務の傍らで、このテックブログの編集チームメンバーを務めてきました（「編集チーム」が何かについては後述します）。 当ブログは、2021年3月に開始し、この3月でちょうど1年になりました。この1年間のブログ運営では、うまくいったこともありましたし、うまくいかなかったこともたくさんありました。今回の記事では、この1年間をふりかえることで、 「企業のテックブログに携わる人たちに役立つ情報を提供する」 ことができればと思います。 ブログの始まりと編集チームについて 編集チーム発足まで テックブログを開設しようという考えは、実際に始動されるだいぶ前からあり、マネージャーなどが中心となり準備を進めていました。企画の検討や、ブログとは別にある 採用スライド資料 の作成などはこの段階からされていました。 しかし、マネージャー陣だけではブログの持続的な運営は困難ということで、2021年1月に私を含む3名に声がかかり、「編集チーム」が組成されることになりました。このチームの主な役割は、ブログの記事制作を担うことです。ブログを始めるのは簡単ですが、継続するのは困難です。記事を執筆してくれる人を探し、執筆が始まった記事を公開まで導くというのは、労力を必要とすることだからです。記事を一定以上のペースで公開していくためには、記事のデリバリーに責任をもつチームが必要だと考え、編集チームが発足しました。 編集チームの発足とブログの始動 編集チームのメンバーは、それまでに進行していたコンテンツ案のそれぞれを「担当編集」として引き継ぎ、執筆担当者の書いた原稿のレビューやスケジュール管理、実際のブログ公開作業などを担うようになりました。 そうして、いよいよ2021年3月にブログが始動しました。最初に公開したのは、Ruby コミュニティなどでも活動してきた技術責任者の @sunaot の記事2本で、幸いなことに、いずれの記事も広く読んでもらうことができました。 tech.bm-sms.co.jp tech.bm-sms.co.jp 始動してから取り組んだこと・工夫したこと さて、以上のようにスタートしたこのブログですが、ブログを始動させるタイミングでは、記事自体をデリバリーすることを優先して、コンテンツ以外の部分（デザインや運営の仕組み）は作り込まずに始めました。ここからは、始動してから取り組んだことや、始めた工夫について紹介します。 ブログデザインを刷新する ブログのデザインは、始動から少し経った5月に、社内のデザインチームに作ってもらったものに切り替えました。始動の前には既に「デザインどうする？」という話は出ていたのですが、「まずはブログとしては始めてしまおう」ということで、このタイミングでの刷新になりました。 「エス・エム・エスって見たこと/聞いたことある会社だな」と思ってもらえるようにしたいというのが目的のひとつなので、早い時期にデザインをコーポレートカラーに合わせたものに変更したのは良かったと思っています。ただ、アイキャッチ画像との平仄が合っていないという問題がつい最近まで存在していたので、もっと早く変更できていればという思いはあります。 定期的なふりかえりを実施する デザイン刷新と同じころに、月次での「ふりかえり」も始めました。 開始当初は Google Analytics を入れるだけ入れていたという程度で、とにかく記事をリリースしていくということに専念していたのですが、軌道に乗ってきたため、試行錯誤ができるように月次でふりかえりをチームで行うことにしました。 このふりかえりでは、記事のデリバリープロセス全体についての改善を模索するのですが、その一環として、前月に公開した記事を中心に、 Google Analytics などでさまざまなメトリクスを確認しています。記事はそれぞれがユニークなので、どのような記事（内容だけでなくタイトル・アイキャッチなどを含めて）が読まれやすいのかなどを分析し、試行錯誤を重ねるようにしています。 例えば、以下のようなメトリクスを確認しているほか、気になる動きが Google Analytics 上で見られれば細かく「どうしてそうなっているのか」などを掘り下げたりもしています。 ブログ全体での月間ユニークユーザー数 ブログ全体での検索流入ユーザー数 記事別の訪問数 記事別の検索流入数 Search Console での特定キーワードでの順位 執筆してくれた人の労に報いる ブログの継続のためには記事を執筆する人が不可欠です。記事の執筆をお願いしてきた人たちはみなさん協力的なのですが、そうはいっても記事を書くのは大変なことです。1本の記事がそのまま何かの成果（代表的なのは採用）に結びつくことはそうそうないのですが、執筆担当者が「書いてよかった、また書いてもいいな」と思ってもらえるように配慮しています。 たとえば、記事を公開したときには、Slackのエンジニア全員のいるチャンネルで編集チームメンバーから一言添えて共有しています。RSSフィードの機能で配信する手もあるのですが、 あえて手動で投稿 しています。 執筆者と一緒に記事を作ってきた編集チームメンバーはその記事の良いところを一番よくわかっていますし、執筆中の執筆担当者の苦労も知っているので、他の人にも見えるところで執筆担当者に感謝の意を伝えるとともに、社内の多くの人にその記事の魅力を伝えるという役割も担っています。 始動後に出てきた課題とそれへの対応 ブログを始めてから出てきた課題もたくさんあります。前述のふりかえりの場や、ブログ運営用の Slack チャンネル での話を通じて、課題に対して手を打っていきました。ここでは一部ですが、取り組んで良かったと思うことを紹介します。 始動後に速やかに増員を行った 3人体制で始まった編集チームでしたが、2ヶ月くらい経ったタイミングで、「結構これは負担が大きい」という声が上がり、編集チームの人員増強を行うことになりました。 それぞれが所属チームでのエンジニアとしての仕事も抱えていたため、所属チームでの仕事がばたつくと記事のデリバリーにも影響が及んでしまうという難点もありました。 この段階で即座に @sunaot が追加で3人のエンジニアに声をかけ、6人体制になりました。6人体制になったことで、障害対応や体調不良、重要なプロジェクトなどでメンバーの一部が欠けた際にも、補い合って記事をデリバリーし続けることができましたし、一人当たりの負荷が減って続けやすくなりました。 また、人数が増えたことにより、それぞれの人が持っているスキル（Google Analytics の読み方など）や、それぞれの人の近くにいる「いい記事を書いてもらえそうな人」の情報の情報が共有されるようになったのも、ブログ運営にとっては有益でした。 マクロのメトリクス以外のフィードバックを得るようにした 前述の通り、ふりかえりの場では、Google Analytics などのメトリクスを見ています。それらのメトリクスは、「記事がどれだけ読んでもらえたか」などといったマクロの傾向を把握するのには有益なのですが、「読み手に対してどういう影響を与えたのか」などはこれだけではわかりません。 そこで、エンジニア採用担当者や面接担当者から、「ブログを読んでもらえているか」や「ブログに対してどのような声があったか」などを共有してもらうようにしています。そうしたフィードバックを得ることで、「ブログを通じてどのようなことを伝えていく必要があるのか」を考える自分たちでも気づいていなかった「エス・エム・エスの特徴」を発見することもありました。 「むきなおり」を行うようにした 前述のように、「ふりかえり」は定期的に行い、「これまでの記事・取り組みはどうだったか」「次はどういう取り組みをすればいいか」という議論は常にしていました。しかし、どうしても限られた時間の中で実施しているため、もう一段抽象的な「何を目的として、どこを目指して行動をしていくのか」というレベルの議論をする機会は作れていませんでした。 その結果、始動のタイミングでは全員で話をしてある程度は合わせていたはずのチームとしての方針に対する理解が、時間の経過とともにバラバラになってしまい、コンテンツを考える際などの議論がまとまらないという場面が出てきました。 そこで、普段のふりかえりとは別に、「 むきなおり 」の時間を設けるようにしました。その場では、「ブログでどのようなことを目指しているのか」といった全体に関わる事柄を改めて話し合います。その中で、コンテンツ作りの方針や、ブログ運営の体制など、見直していくとよさそうな点を見つけられたので、一つ一つ改善していこうとしているところです。 ブログを運営する中でわかってきたこと 最後に、ブログを運営する中でわかってきたことを紹介します。 バズる記事だけが重要ではない 上記のようにふりかえりをしながらブログを運営していく中で、公開するコンテンツの位置付けについて少しずつ自覚的になってきました。 記事のなかには、SNSで「バズる」記事もありますが、ほとんどの記事はそうではありません。しかし、バズりはしなかったけど検索流入がありつづける記事や、広く読まれるわけではないが特定の読み手に刺さる記事（スカウトを送る際などに、その人に読んでもらうと良さそうな記事を添付したりしています）にも意義があるということが見えてきました。 また、ブログ全体としての記事の積み重ねによって会社のイメージが形成されていく（「エス・エム・エスさんはこういう記事が多くて、〇〇を大切にしている会社なのだなと感じました」というフィードバックをもらうことが繰り返しありました）という側面もあるということも発見でした。 編集チームでの仕事には副産物がある 編集チームのメンバーはエンジニアリングの仕事の傍らでブログ運営の仕事をしているのですが、ブログ運営を通じて得られる副産物がありました。この種の仕事はともすると「本当はエンジニアリングにもっと時間を使いたいのに」と敬遠されがちですが、以下に書くような副産物があると、ブログ運営に関わるインセンティブにはなりそうです。 他事業・他チームのエンジニアとの関わりが得られる エス・エム・エスは、40を超えるサービスを運営しており、エンジニアは（多くがプロダクト開発部という横串組織に所属してはいるものの）普段は担当するサービスのなかで仕事をしています。Slackでの雑談・勉強会や、社内のテックトークイベントなどで関わる機会もあるのですが、ブログ編集チームメンバーを務めることでこれまでにはない他事業のエンジニアとの関わりが生まれました。 まず、 編集チームの他のエンジニア です。編集チームは、記事コンテンツ案を考える都合などもあり、様々な事業のエンジニアの混成チームとなっています。事業ごとに扱っている技術スタックもビジネスモデルも異なるので、そういったチームで一緒に仕事をしていると、新たな発見がしばしばありました。例えば、私は担当している事業が介護事業者向けのSaaSで、基本的にはログインした後の世界を主戦場としているのですが、人材紹介のサービスを担当しているエンジニアは集客の部分にも強みがあり、SEOやGoogle Analytics などの扱いに慣れているので、ブログの運営面では学ばせてもらうことが多かったです。 また、 執筆担当者のエンジニアとの関わり も貴重でした。記事の中には、執筆担当者単独で書けてしまうものもありますが、編集チームメンバーと執筆担当者が二人三脚で進めていくものも多くあります。その場合、打ち合わせや非同期でのコミュニケーションを通じてコンテンツを作っていくことになるのですが、その過程でのやりとりで（最終的な記事には表れないような）裏話や、技術の詳細について話を聞くことがしばしばありました。執筆担当者はシニアなエンジニアであることも多いので、そういった話を直にきけるのは「役得」でした。 普段のエンジニアリングとは異なる学びがある 普段主にWebサービスの開発をしている私たちですが、広報目的のブログの運営はWebサービス開発とは異なる営みです。（一部Webサービス開発の知見が流用できるところもありますが）ブログを運営していく中では今まで考えたこともなかったことを考える機会が多くありました。 たとえば、以下のような事柄が挙げられます。 企画の検討（ペルソナの設定〜コンテンツの企画） Webマーケティングの観点（Google Analytics を用いた分析など） 読んでもらえるタイトルやアイキャッチ画像の検討 会社の発信としての質の担保 これらの事柄は、それぞれに専門分野として蓄積もある領域でもあり、私たちのブログ運営のなかではごくごく初歩的なことしかできていない（あるいは初歩的なことすらできていない）とは思いますが、勉強をするきっかけを得られたのはブログの運営に携わったことの良い副産物だったと思います。 俺たちの戦いはこれからだ！ 以上、ブログ編集チームメンバーとして1年間このブログを運営してきてのふりかえりを書きました。ブログ運営は順風満帆とはいえず、まだまだ課題は多くあります。たとえば、 どうすればもっと執筆者/運営の負担を減らせるか？ どうすればもっと「意味のある」ブログになるか？ などは常に付きまとってくる課題です。これらについては、常に社内でも議論をして改善を試みてきてはいますが、抜本的な解決策には辿り着いていません。今後も試行錯誤をしながらこのブログを運営していければと思います！

はじめまして。株式会社エス・エム・エスの土屋匠です。 弊社では医療・介護・ヘルスケア・シニアライフの４つの領域で高齢社会の情報インフラを構築しており、シニアライフ事業領域では高齢社会が直面する「高齢社会の生活にまつわる困りごとの解決が困難になる」という社会課題に対し、「多様な選択肢と質の高い意思決定情報の提供」を通じて解決を目指しています。 私はこの４つの領域のうちシニアライフ領域のエンジニアとして、介護で悩む人向けコミュニティ「安心介護」とケアマネジャー向けコミュニティ「ケアマネドットコム」の２つのコミュニティサービスの開発を担当しております。２サービスとも直近ではサイトリニューアルを行い、新しいアーキテクチャのもと課題解決に取り組んでいます。 今回は私たちのチームカルチャーや開発スタイルの一部について紹介したいと思います。 小さなチームでプロダクト開発をリード シニアライフの事業領域はIRで公開されている情報にあるように、他の事業分野と比較すると売上規模が小さく加速度的な成長を目指しているフェーズの事業が数多く立ち上がる部署です。横断的な部署とプロジェクトを組み連携しながら進めることもありますが、１名で事業立ち上げのプロダクト開発をリードしたり１つの開発チームで複数のサービス開発を担います。 チームメンバーには オープンソースのコードを読み、そのプロジェクトにIssueを立てPull-Requestを投げる 海外経験あり英語ドキュメントを難なく読んでしまう 先見性を持って最新のデザインツールやフレームワークの提案や導入をする など、多種多様な視点で集まったナレッジがプロジェクトの課題解決の後押しとなっています。 私たち開発チームの技術スタックと開発で使用するツール類の一部を紹介します。 カルチャー１「成長を加速させる当事者意識」 機能開発は誰にとってどんな目的の機能を提供するのかを明確にした上で、細かい仕様や技術選定などは個人に判断を委ねています。よくトップダウン型のチームだと開発チームの技術スタックや課題解決の質がトップの能力や経験に引きずられてしまうのですが、 個々の能力が最大化された状態のチームであるためには制約は少なく、ゴールのありたい姿だけを共有するようにしています。 時には細かい仕様の落とし込みなど実装する際にチームでの議論が必要になりリリースまでのリードタイムが長くなってしまうこともありますが、話し合うことでチームの全員がその意思決定に対して腹落ちして前に進むようにしています。 その甲斐あって、私たちは当事者意識を持ち主体的に働いており、個々の能力の最大化が個人のさらなる成長にも寄与しています。 カルチャー２「心理的安全性で改善が活発化」 私たちは失敗を許容できるチームでありたいと思っています。たとえば、サービス運営をしていると多かれ少なかれ不具合が発生しますが、それは失敗してもいいということではなく同じことを繰り返さないようにその失敗から学び成長できると捉えています。 チームでは誰が言ったかは重要ではなく、正しいことを正しいと言えてその実現に向けて愚直に取り組むことを大事にしています。 開発者が自身で改善Issueを立てることがあり、そこからプロダクト改善がスタートすることもあります。これはとても良い習慣で、誰かに遠慮したりせず常に物事の対象がプロダクトに向いています。 カルチャー３「生産性が高い非同期コミュニケーション」 同期的なコミュニケーションはZoomまたはGoogle Meetで２週間に１度の定例ミーティングで行っています。これは全員が持ち回りで前後２週間のタスクを共有します。この定例ではプランニングも兼ねているので、緊急度・重要度の判断軸に当てはめて事業戦略とすり合わせながら開発タスクを決めています。 それ以外のコミュニケーションは非同期で取ることがほとんどです。通常は同期的なコミュニケーションの比重が高いほうが一般的かもしれませんが、私たちのチームは非同期コミュニケーションの比重が高いのが特徴です。非同期コミュニケーションはSlackやGitHub上で全員が目にできる場所でオープンにしようと心掛けています。 課題共有や解決のアプローチなどはすべてGitHub Issue/Pull-Request/Wikiに残します。それをドキュメントと呼ぶには程遠いですが、思考や作業のプロセスを時系列にトレースして振り返ることができるようになっています。 プロダクトの開発フェーズ ２サービスとも直近のリニューアルでペルソナやユーザーストーリーからコア機能の再定義を行いました。現在は一定のアーリーアダプターが付いており、ユーザー自身の課題を解決するためにプロダクトを利用してもらっています。 そのようなフェーズですので、あらためてユーザーからのフィードバックを得て改善を進めており、プロダクトの細部に至るまで使い勝手を改善することや機能仕様を見直すことが第一に求められます。 もちろん必要があれば新機能の開発なども進めますし、定期的にビジネス側とKPIのすり合わせを行い、日々のプロダクトの利用状況を可視化することも大事な開発タスクとして取り組んでいます。 施策立案からリリース後の検証 まずはユーザーの声に耳を傾け、定量的なデータの分析を行い、ユーザーの課題を洗い出します。洗い出した課題に対してビジネス上のインパクトや課題の重要度・緊急度を鑑みて優先度付けをした上で高いものから順に仮説を検証していきます。もちろん解決策が疑う余地もなく有効である場合にはそのまま機能を作り込みにいくこともありますし、逆に解決策を作り込んで提供するにはリスクが高い場合には人手のオペレーションで試してみたり外部ソフトウェアなどのツールを利用して検証します。 プロダクトのフェーズからも分かる通り、改善スピードをあげて対応していくことが重要なのでリリースのタイミングは基本的にコードレビューと検証環境で動作確認が通ったら順次リリースしていきます。これは実装コードと対になるユニットテストやインテグレーションテストが通っていることが前提です。もちろんユーザーやビジネス上のクライアントへの影響がある場合には事前のアナウンスや日程の取り決めを行いリリースします。 リリース後の検証も定量的なデータを分析して評価します。日常的にモバイルやPCからサイトにアクセスして使われるコミュニティサービスという特性上、ある程度の母数のあるユーザーにすぐ届くので、ユーザーの反響が定量的なデータに反映されやすく、事業の手触り感を得やすいのも特徴の１つです。 開発者体験（DX：Developer eXperience）の向上 新しいアーキテクチャでの開発をスタートして以降、開発者体験の向上にも力を入れています。たとえば、言語・フレームワーク・ミドルウェア・ライブラリのバージョン管理を導入していますが、単に脆弱性に対するセキュリティアップデートだけの用途ではなく、開発者が生産性が高く気持ちよく開発することができる環境をつくるためでもあります。 具体的にはDependabotで依存ライブラリのバージョンアップを毎日行っています。Breaking Changesを含むメジャーバージョンへのアップグレードも発生しますが、利用の技術スタックの最新動向を知る機会と捉えて積極的に対応しています。 直近だと Ruby / Rails / Vue.js へのアップグレードを終わらせ、今後は AWS CDK のアップグレード対応を視野に入れています。そしてこれらの保守対応は事業施策と同じテーブルにあげて優先度付けされ対応していくので、プロジェクトで利用する技術スタックは比較的最新のバージョンに保たれています。 さいごに 私たちは小さなチームですが、その分フットワーク軽く自律的な行動ができるひとが集まっています。今後もシニアライフには様々なアーリーフェーズの事業が立ち上がることから、技術を武器に社会課題の解決に貢献したい仲間を求めています。 事業の初期段階からプロダクト開発をリードしたいひとがいましたら、一緒にワクワクするようなプロダクトをつくりにいきましょう。

はじめに はじめまして。ヘルスケア事業部にて開発を担当している今村と申します。 私は、金融系のSIerからエス・エム・エスに転職し、介護職向け求人情報サービス「カイゴジョブ」、看護師向け求人情報サービス「ナース専科求人ナビ」、管理栄養士・栄養士向けコミュニティ「エイチエ」、遠隔指導特定保健指導サービス「遠隔チャット指導」などの事業を担当してきました。転職して10年以上経過していますから、この会社ではかなりの古株ということになります。 エス・エム・エスでは様々な事業を展開しているため、その事業のフェーズやとりまく環境に応じてとりうる戦略が違っていて、必ずしもプロダクトの価値だけが事業の成功要因ではないこともあります。具体的には、プロダクトは競合と横並びだけど、オペレーションによって競合より優位性を獲得するようなケースです。 例えば弊社が事業の柱の1つにすえている医療介護向けのキャリア事業では、プロダクト = 人材紹介の登録サイトですが、そこで担っているのは主に集客です。しかし、人材紹介の売上は「紹介手数料」をもらうことで成り立っているため、集客したユーザーのニーズを汲み取って適切な転職先をご提案する「後工程」も集客と同じかそれ以上に重要となります。特に医療分野は、どの企業も集客には力を入れています。その場合、プロダクトによる差別化の余地は少なくなるので、オペレーションによって求職者と顧客の双方がハッピーになるようマッチングしていくことが成功の鍵となります。 このため、エス・エム・エスのエンジニアは、プロダクトの改善に関わるのみならずオペレーションの改善に関与する機会も多くなります。そして私の経験上、オペレーションの改善には、技術力より要件定義や業務分析力に強みを持っている方のほうが、力を発揮しやすいと考えるようになりました。 今回はその点について掘り下げてお話したいと思います。 事業の成長とともに起こったこと どのような事業でも、事業開始当初の段階でオペレーションが固まっていて、成長の段階に達しても同じオペレーションを維持していられることはまず無いと思います。 実際に事業を始めてから見えてくることが多いというのもあるし、そのオペレーションを行う人材を事業成長のスピードにあわせて増員することが難しく、その代わりとしてオペレーションの効率化が求められるからというのもあるでしょう。そういった諸般の事情により、オペレーションは常に流動的かつ改善が求められ続けるものと言って良いと思います。 弊社においては、私が入社した当初この改善はプロダクトの中に作られた管理システム、あるいはExcel上で行われていました。管理システムについては、プロダクト開発の合間に浮いた工数でエンジニアが改善したり、ExcelについてはVBAや関数に秀でた現場の担当者が居て、その人が中心となって改善が行われていました。 しかし、そういったアプローチによるオペレーション改善は、事業の変化についていけたとはお世辞にも言えないものでした。 管理システムについては、改善の優先度がプロダクトの改善より低いことが常でしたし、Excelに関しては担当者のスキル依存であり、仮に素晴らしいものが出来上がったとしても、次の担当者に同様のスキルが無ければメンテできなかったからです。一部は、VBAのスキルをたまたま備えていたプロダクト開発のエンジニアが巻き取ったなんてこともあったほどです。 SaaSを使ったオペレーションのはじまり 弊社では、期初に事業部ごとの「戦略」を作りグループへの浸透を図ります。その際にもオペレーションの高度化や効率化は必要と謳われていました。 そのような背景があり、弊社では徐々にExcel運用や管理システムを捨てて、SalesforceやkintoneなどのSaaSを使うようになっていきました。その結果、導入当初は現場の改善が進んで盛り上がることになりました。 しかし数年経つと、上記のSaaSの活用もシステムの様々な制約に直面するようになり、停滞したりトラブルを抱えるようになってきました。アプリケーションが乱立し、データ間の依存関係もよく分からず、さらに1アプリにフィールドを詰め込みすぎてシステムが定めていた上限に達しそうなものさえあったと聞いています。 今でこそローコードやノーコードと言ったキーワードとともに「エンジニア要らずのDX改善」などともてはやされているSalesforceやkintoneですが、いずれも提供してくれるのは「コードを書かなくて良い環境」のみです。しかし考えてみると、開発において「コードを書く」フェーズは全体のプロセスの中のごく僅かに過ぎません。その手前の、要件を洗い出して設計に落とし込むという作業は残り続けます。それをエンジニア抜きで進めていたわけですから、やはりどこかで限界が来るのは必然と言えるしょう。 こうした反省もあって、エス・エム・エスではSalesforceやkintoneを使ったオペレーションにおいても、エンジニアが参画するようになりました。まだまだ事業によって濃淡はあるものの、弊社のオペレーションの改善においては、エンジニアも一丸となって改善に取り組むのが当たり前となりつつあります。 エンジニアとオペレーション改善 私が所属するヘルスケア事業部でも、事業のスタートこそExcel運用が多かったものの、徐々にkintoneへの移行を進めています。kintoneのアプリを作成する際には、エンジニアが必ず要求を出す段階から関与し、kintoneを含んだ業務フロー全体の流れも把握し、他のアプリやデータと整合するようコントロールしています。実はkintoneの導入が決まった当初は、エンジニア抜きで利用を進めるという案もあったのですが、他の事業での失敗の経緯を説明してエンジニアも参画することになったのです。 kintoneを担当するようになってからは、長期的な視点でのデータの設計、安全なアプリケーションの連携方法の模索、kintoneの標準機能で賄えない部分を内製するかサードパーティのプラグインで対応するかの検討など、考えることが多岐にわたると実感できるようになり、もしエンジニア無しにスタートしていたら1、2年という早いスパンで業務が破綻していただろうと思うようになりました。 ただこういった業務は、プロダクトの開発と比べるとなかなか地味です。どちらかというと、要件のヒアリングや設計に重きを置くからです。自分で手を動かしてコードを書くことが必ずしも正解ではなく、場合によっては「作らない」という判断こそが求められます。 一方、不特定多数のユーザーがターゲットとなるプロダクトと違い、価値の提供先は社内になるわけですから、より具体的な課題を聞くことができます。このため要件定義や業務分析をうまく行い、kintone上でオペレーション改善につながる仕組みを提供すれば、それだけで業績に大きく跳ね返ることもあります。 一例を挙げますと、とある架電にまつわるオプションサービスの運用業務を、Excelからkintoneに移行する小さなプロジェクトが事業に大きく貢献したことがあります。 私が担当したそのプロジェクトは、単に移行するだけでなくオペレーションも効率化したいという要望がありました。そこで細かく要件のヒアリングを行い、誤入力や入力漏れが無いよう制御し、状態管理もひと目で行えるよう作り込んだうえでkintoneアプリケーションを提供しました。結果、そのオプション商品による架電効率が向上してKGIが大きく伸び、オプションサービスの販売数増に繋がりました。しかもこのオプションサービスは、メインのサービスの重要指標を改善するためのものであったことから、メインのサービスの契約継続や受注にも良い影響を及ぼしたのです。 これは特に効果が高かった事例ですが、他にも日々このようにオペレーションの改善に関与し続けていると、少人数の組織体制でも多くの業務を捌けるようになる利点もあります。その結果として、受注が増えても業務のキャパシティが溢れてしまうリスクを減らせるので、安心して事業を伸ばしていけるという側面もあるだろうと考えています。 多様な事業、多様なエンジニアニーズ 昨今、事業会社のエンジニアに求められるスキルといえば、特定のプログラミング言語やフレームワークをうまく扱うためのものだったり、AWSなどのインフラを柔軟かつ安全に構築するためのものだったり、技術力に重きを置いていることが多いと感じます。それはおそらくプロダクトの改善こそが、その事業の成長にとって不可欠だからでしょう。「プログラミングのスキルを身に着けて、SIerから事業会社に転職しました」というような話も聞きます。 しかし弊社のように、多くの事業を抱え、事業フェーズやとりまく環境がそれぞれ異なる状況においては、プロダクトの開発に力を発揮するエンジニアだけではその成長を支えられないこともあります。 すでに述べた通り、必ずしもプロダクトの優位性だけが事業の競争力の源泉とは言えないからです。 そのため、SIerで培った経験や能力を存分に発揮しつつこれから技術力を高めていきたいエンジニアや、技術力の向上よりも事業の成長に貢献することに関心のあるエンジニアなど、様々なバックグラウンドを抱えている方々に活躍する場を提供できるのが弊社の強みではないかと考えています。 もし事業会社のエンジニアとしてのキャリアに関心があれば、現時点でのスキルの過不足は考えずに、一度弊社のカジュアル面談をご検討いただければと思います。あなたの今のスキルや経験を必要としている事業が、見つかるかもしれません。

介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。 エス・エム・エスには、エンジニアの学習を支援する制度がさまざま存在しています。そのうち、AmazonのURLをSlackで伝えるだけで即日注文、数日で自宅に技術書を届けてもらえる制度については、以前の記事でご紹介しました。 tech.bm-sms.co.jp 上記の制度とは別に、 「オライリーのサブスクリプションサービスを使わせてもらえる制度」 があります（2022年3月現在）。今回は、このオライリーのサブスクリプションサービスをどのように活用しているのかを社内のエンジニアに聞いてみました。 オライリーのサブスクリプションとは？ オライリーのサブスクリプションは、正式には「O'Reilly Online Learning」といい、技術出版社の O'Reilly が運営しているサブスクリプションサービスです。普通に契約をすると年間499ドル 、（一部機能制限付ですが） ACMの会員になることで年間99ドル （2022年4月追記：ACM会員のこの特典は2022年6月末で廃止されるようです） で利用することができます。 www.oreilly.com このサービスでは、膨大な種類の技術書や講義動画、オーディオブックなどが読み放題/見放題になります。読むことのできる技術書には、オライリーから出版された書籍はもちろん、Addison-Wesleyなど他の出版社の書籍も含まれています。Webブラウザで閲覧する以外に、iOS/Androidのアプリで閲覧することができます（アプリにデータをダウンロードしておいて、オフライン状態で閲覧することもできます）。 リソースのほとんどは英語ですが、2020年11月ごろに 日本語書籍が一部追加 されて話題になりました。2022年3月現在では、102冊の日本語書籍を読むことができます。 オライリーサブスクリプションに、日本語書籍が！！！ タイトル検索も出版社検索もヒットしないので、ラインナップは今のところ不明だけれど、これはもうみんな課金するしかないのでは…? pic.twitter.com/IAZJDXcaPQ — kawasima (@kawasima) 2020年11月16日 どんなふうに活用しているか聞いてみた！ 今回、実際にこの O'Reilly Online Learning（以下オライリーサブスク）を利用しているエンジニアに、活用方法を聞いてみました。 関心のある技術やテーマを概観する or 拾い読みする 多かった回答は、 「新しい技術を勉強するときに、まずオライリーサブスクで検索して何冊かをざっと見てみる」 というものでした。オライリーサブスクでは（Early Release版を含め）新旧の書籍を読むことができます。書籍購入制度を活用することもできるのですが、技術調査段階だとスピーディにさまざまな本を見たいということがあるので、検索してすぐに&追加のお金をかけずに読むことのできるオライリーサブスクが便利だということでした。最近では、GraphQLやマイクロサービス関係の本をこれで読んでいるメンバーがいました。 learning.oreilly.com また、たくさんの書籍を読むことができるので、 関心のあるテーマについて複数の書籍の関連する章だけを拾い読みする ような読み方をしている人もいました。最近だと、EventStorming を実践しているチームがあるのですが、ドメイン駆動設計関係の書籍のEventStorming について言及している章を（後述する全文検索も活用しながら）探してきて、理解を深めるというような使い方です。 learning.oreilly.com 全文検索が便利！ 他には、全文検索を活用しているという声もありました。オライリーサブスクは サイト内全文検索にも対応 しているので、仕事をしていて出会うエラーメッセージやオプション名などをそのまま検索すると、関連する書籍がヒットすることがあります。もちろん公式ドキュメントを確認するのが最も確実ではあるのですが、公式ドキュメントでは簡単にしか書いていない事柄について書籍だとより詳しい説明がある場合も多いため、便利です。 翻訳書を読むときのお供にも また、これは私個人の話ですが、翻訳のある書籍を読んでいると、「ちょっと意味が取りづらいな？」と思う箇所に時折出会います。そういうときに、オライリーのサブスクで原書の該当箇所を確認するというのは結構な頻度でやっています。この1年ほど、社内で『プロダクトマネジメント』（原題は『Escaping the Build Trap』）や『エリック・エヴァンスのドメイン駆動設計』の読書会を実施しているのですが、いずれの書籍も原書がオライリーサブスクで読めるので、「ここってどういう意味なんでしょう？」「原文だとこうなってますねー」というやりとりをすることがありました。『プロダクトマネジメント』読書会をしているときには、翻訳で違和感のあるところを見つけて、訳者の吉羽さんにフィードバックを送るという場面もありました（ すぐ確認していただけて、正誤表に反映していただけました ）。 learning.oreilly.com 機械翻訳サービスと組み合わせると便利！ また、最近はGoogle翻訳やDeepLを使うことで、英語が苦手な人でも「オライリーのサブスクでざっと読む」が簡単にできるようになっています。オライリーのサブスクはWebブラウザで読めるものなので、たとえば Google ChromeのGoogle翻訳の機能を使うとシームレスに（わざわざコピペや範囲選択をせずに）翻訳をかけて読むことができます 。私個人も英語はどうしても読むスピードが格段に落ちてしまうので、「精度はともかくどんなことが書いてあるのかをさっと知りたい」というときには機械翻訳をオンにした状態で読んでいます。 おわりに 社内では、それなりの人数のエンジニアがサブスクのライセンスを持っているので、「オライリーのサブスクにあるこの本が良いよ」とか「オライリーのサブスクのこの本にはこう書いてあるよ」というやりとりがなされています。私個人は元々そんなに英語の技術書までキャッチアップしていなかったのですが、オライリーのサブスクを使うようになり、また同僚と同じものが常に参照できる状態で仕事をする中で英語の技術書が身近な存在になってきました。 英語の本を読んだらすぐ仕事ができるようになるかというとそんなことはないわけですが、日本語だけで得られるよりは格段に幅の広い情報に接することができ、中でもオライリーのサブスクは質・量ともに非常に充実しているので、一度使い始めるとやめられないサービスです。みなさんもぜひ契約してみてください&他に便利な使い方を知っていたら教えてください！

2021年10月にエス・エム・エスに、介護事業者向け経営支援サービス「カイポケ」のQAエンジニアとして入社した中村です。前職は第三者検証会社に勤めており、約15年ほどソフトウェアのQA業務に携わり、テスト設計/実施から始まり、テスト計画書/テスト報告書の作成やテストチームの管理など管理業務を経て、最近では、品質管理/分析、改善活動、テスト自動化といった業務を主に担当してきました。色々な現場を転々としてきましたがずっと一社で勤めてきたので、今回が初めての転職 🔰 となります。 本記事はQAエンジニアや品質に関心のあるエンジニアの方をターゲットと想定していますが、それ以外の方もエス・エム・エスにはこんなQA組織があるんだと、1つでも参考になる情報をお届けできれば幸いです。 転職の経緯 私が転職を考えた理由はシンプルで、色々な現場を転々として様々な製品や人たちに関わってきたことで、自身も事業を持つ会社に所属して腰を据えてより製品に向き合いたい・責任を持って製品に関わりたい、という思いが強くなったことにあります。転職先をエス・エム・エスに決めた理由はいくつかあるのですが、大きくは以下の3つとなります。 1. 今後の企業成長性が高く組織と共に自身も成長出来る環境にあること こちらの入社エントリー記事でも紹介されていますが、「市場/事業が伸びている」という点は私も重要な判断基準としています。 tech.bm-sms.co.jp 今後も成長していく企業に貢献していくことが自分自身の成長やモチベーションにつながると考えているからです。正直、入社前の介護業界知識は０に等しく、介護は大変そうという漠然としたイメージしか持っていなかったのですが、少子高齢化の社会で人材不足と財政難という非常に難解な課題があることは転職活動を通じて知ることが出来ました。そのような社会的な課題の解決に微力ながら貢献出来るということはやはり大きなやりがいになると感じています。 2. 職場環境が良好で働きやすい環境にあること 私が働く上で特に重視しているのが、人間関係やチャレンジし易い環境にあるかといった点になりますが、カジュアル面談や選考工程を通じて会社や人の雰囲気が合っているという感触を得ていました。詳細は「入社して感じたこと」に記載していますが、その判断に間違いは無かったと感じています。 3. QAとして経験してきた自身のキャリアが活かせる職場であること 改善活動・テスト自動化の導入など自分が経験しモチベーションを持っている業務が会社の求めていた部分とマッチしていました。後述する「取り組み事例」に進行中の施策を紹介していますが、早速その辺りを担当させてもらっています。 入社して感じたこと 気軽にコミュニケーションが取れる 現在はリモートワーク環境下ですが、コミュニケーションは非常に取りやすいです。定期的なミーティングも開催されていますし、ビデオ通話などで気軽にコミュニケーションが取りやすくなっていることも良いポイントだと思います。また、厳格な上下関係というものも無く意見を言いやすい環境にあると思います。 高い品質意識 品質を高める・より良い製品を作る・顧客に使ってもらう、といった意識の高いメンバーが集まっています。 開発やテストの規模を考えるとテスト期間中に検出される不具合の数が非常に少ないと感じました。業界知識や製品知識（古くからあるサービスですが、その当時のことを知る人がほぼいないという状況）が充分とは言えない中でもこうした成果が出ている点を見ると、いかに慎重&正確に企画、開発、テストがされているかが分かると思います。 また、エンジニアで介護業界を経験している方はあまりいないのですが、勉強会が各所で開催されているなど、ドメイン知識の習得はもちろん、顧客が何に困っているのか？どうすれば使いやすくなるか？といった情報のキャッチアップなど経験不足を補うための取り組みが活発に行われています。 チャレンジし易い 上長の理解もあり、方向性が合っていれば細かい部分のやり方や意思決定は裁量を持ってやらせてもらえること、短期の成果で見るのではなくゴールに進んでいることが分かれば失敗したり遠回りしても評価されることが、チャレンジのしやすさを感じる大きな要因になっていると思います。ただ、チャレンジへの制限はないので手を出す範囲を広げすぎるとパンクする危険性もあるので注意が必要ですが、上手くバランスが取れれば自身の成長にもつながる非常に良い環境だと思います。 オンボーディング 入社後の研修は充実しており、全体的な研修として会社の経営理念やルール、介護業界やカイポケの説明を受けられるので介護業界の知見が無くても大丈夫です。その後は各部門に移動してより詳細の説明や研修を受けることになるのですが、私が配属したQAチームでは、まずは製品を理解することを目的に操作マニュアルに沿ってカイポケを一通り触るところから始まります。その間のフォロー体制も充実しており、気になったことや不明点はすぐに確認出来る環境にありますし、定期的に1on1が開催されるので現場には馴染みやすいと思います。 QAチームについて ここからは入社してから私が取り組んでいる事例を簡単に紹介していきますが、その前に所属しているQAチームのことを簡単にご紹介しておきます。下記図の通り、QAチームは横断的な組織として存在しており、小チームを形成して各サービスチームに参加しています。 QAチームとしての役割は様々ですが、主に下記の作業を担当しています。 テスト前：仕様レビュー、テスト計画作成、テスト設計、テスト実装 テスト中：テスト実施、不具合報告、改修確認 テスト後：テスト結果報告、リリースサポート、市場障害対応サポート 取り組み事例①：開発/QAプロセスの整備 開発/QAチームでのコミュニケーションも適宜取れており、関係性も問題は無いように見えたのですが、関係者から話を聞いてキャッチアップしていくうちに下記のような漠然とした課題感が見えてきました。 作業の透明性を高める必要がある 上流フェーズでのコミュニケーション頻度が少ない リリース内容ごとに柔軟性が求められるため、プロセスを統一することが難しいという側面もあるのですが、まずは現状のプロセスを整理/可視化しつつ具体的にどんな課題があるかを明確にしようと考え、プロセス図を作成しました。 ※本取り組みは、以前 別の記事 でも紹介した「検証業務プロセスのフロー」をより具体的にして、更に開発側のプロセスや共通で実施するプロセスも記載した形になります。 以下は作成したプロセス図の一部ですが、下記の課題感が明確に出来ました。 テスト計画やテスト報告の共有に改善の余地がある 定期的な振り返りが合同で出来ておらず、お互いの課題感を共有するタイミングが取れていない 企画/仕様作成の段階でQAのアプローチが強化出来そう 今後は上記課題への対応はもちろんですが、最終的な目的はプロセスを作ってそれを守ることではなく、上流フェーズから品質・仕様・テストについてのコミュニケーションがもっと活発になる、改善点や課題に対しお互いの意見が言いやすくなるなど開発/QAの関係性がもっと強化される、ことにあると考えています。これらが仕組みとしてチームに定着するよう引き続き取り組んでいきます。 取り組み事例②：E2Eテスト自動化導入 ノーコードの自動テストツールが導入されたばかりで、調査や情報交換も活発に行われていましたが、時間的な余裕が無い&導入のノウハウが無いといった課題もあり、あまり進められていない状態でした。そのため推進やサポートが必要と判断しテスト自動化に関わっていくことにしました。 事前に何人かの方とお話しをしたのですが、E2E自動テスト実行やテスト実装には関わったことあるけど導入には関わったことがないというメンバーが多く、最低限知っておくべき知識のインプットは必要だと感じたので、まずは下記資料を参考にナレッジ資料（記載内容：メリット/デメリット・向き/不向き・導入フロー・活用事例など）を作成し勉強会を実施しました。 テスト自動化の8原則 （文献） システムテスト自動化 標準ガイド （文献） 初めての自動テスト Webシステムのための自動テスト基礎 詳細は割愛しますが、その後は所属サービスチームでのテスト自動化を推進すべく下記の流れで進めています。 計画策定 何を目的とするかによって対象や優先度は変わってくるのでまずはそこを明確に 目的を決める 自動化の対象を決める 優先度を決める 期日目標を設定しないとだらだらと進まなくなってしまうことも懸念されるので マイルストーンを決める 設計 テスト実装/メンテナンスをしやすくする 変数化/共通化 テストケースを他から独立させる 前処理/後処理 テストの質を人に依存しないよう一定に保つ Assert（どのタイミングで何をテストをするか） テスト実装（&テスト） 手戻りのリスクが大きいので徐々に精度を上げて作り込んでいくため 優先度が高いものから小さくスタート 現在はテスト実装まで進んでおり、ようやく形になってきています。ただ、今後の運用/保守を考えると、属人化への対策とテスト実行/結果確認を簡単に出来る仕組みの構築が課題としてあります。まだまだやることは盛りだくさんですが、弊社内でリグレッションテストの需要は今後確実に高まっていきますし、高速でテストを回す上で自動テストは必要不可欠ですので、重点的に取り組んで行く必要があると考えています。 最後に 以上、QAエンジニア目線での入社エントリを執筆させて頂きましたが、少しでも会社やQAチームの雰囲気・作業内容をお伝えできたでしょうか？しつこいようですが間違いなく言えることは、コミュニケーションが取りやすい、やりたいことにチャレンジしやすい、やりがいを持って仕事が出来る環境であるということです。 最後に「やっていきたいこと」として大きく2つの施策を紹介しましたが、不具合分析導入、ユーザビリティテスト強化、脆弱性テスト強化、市場障害の撲滅、などなど他にも考えなければいけないことはたくさんありますし、今後はQAの活動範囲もどんどん広がっていくことが予想されています。ですが、QAエンジニアの数はまだまだ足りておらず、一緒に働く仲間を絶賛募集中です！少しでも興味を持たれた方がいたらカジュアル面談へのご応募を宜しくお願い致します！！ tech.bm-sms.co.jp