エス・エム・エス テックブログ運営の熊谷です。今回は「エス・エム・エス社員に訊いてみた」と題しまして、弊社内のエンジニアを中心に聞きたいことを募集し、インタビューをする企画をスタートしました。第一弾は弊社の技術責任者である田辺さん( @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

これを書いているのはだれ？ 2012年から社会人になって、今年で34才になりました、空中清高です。Twitter とかではsoranakkってIDでやっています。前職の同僚からこんな 画像 を作ってもらったりしてる感じの人です。 なにをやってきたの？ Webフロントエンドエンジニア→Webサーバーサイドエンジニア→Androidアプリケーションエンジニアという経緯でソフトウェアエンジニアをやってきました。Androidアプリケーションエンジニアになってから、かれこれ8年以上経過していて、ソフトウェアエンジニアとしての経歴の大半がAndroidアプリケーションエンジニアです。 直近では株式会社Mobility Technologiesでタクシー配車のGOアプリのAndroidアプリケーションを開発していました。と言っても、開発していたのは一般に使われているGooglePlayにリリースされているGOアプリではなくて、タクシー車内にあるAndroid端末に自社サーバーから配信する感じのAndroidアプリケーションです。BtoBtoCなアプリケーションなので普通のAndroidアプリケーションとは違うところも多々ありましたが、まあAndroid端末の上で動作するアプリケーションを開発していたので、私の直近の経歴はAndroidアプリケーションエンジニアのはずです。 また DroidKaigi と iOSDC Japan のコアスタッフをしていて、微力ながらソフトウェアエンジニアコミュニティの活性化に協力していたりします。 どうしてエス・エム・エスに？ 実は3年前に DeNA に転職したときにエス・エム・エスからも内定を頂いていて、その時はお断りしたという経緯がありました。当時もすごく悩んだのですが、ラストワンマイルを解決することに尽力したいという想いがあり DeNA(後に事業譲渡してMobility Technologiesに転籍になった) を選びました。当時は (今もですが)運転免許を持っておらず、駅から先の移動手段については自分自身でも課題になっていて、その問題に自分自身が取り組むことに魅力を感じての選択でした。 それから3年ほど経過したある日に、エス・エム・エスで技術責任者をしている田辺さん @sunaot から連絡をいただきました。その時に「3年前はエス・エム・エスを断ったけど、そういえば DeNA に行ってやりたかった事ってなんだっけ？」みたいなことを思い出しながら、「あの時は出来なかったけど、今ならとりあえずどこにいてもアプリを使ってタクシー呼んで移動する、みたいなことがほぼ出来るようになってるな」「全部ではないけど、3年前にやりたかったことの一部ぐらいは出来たのかも」ってぼんやり思いました。また、「チームビルディングとか少し興味出てきたな。今期の目標に設定してやっていくぞ」みたいな時期でもありました。 そんな状況で田辺さんからエス・エム・エスの3年前からのアップデートや近況を聞いて、 「ちょうどこれから新しいチームを作ってやっていこうと思うのですが興味ありませんか？」 と誘われて選考を受けることにしました。「新しいチームでチームビルディングから関われるのって楽しそうだな」っていうのが選考を受けた理由の大半で、まだこの時はエス・エム・エスの事業やプロダクトのことについてはぼんやりとしてて「複雑っぽい課題があって挑戦しがいありそう」みたいにしか思ってなかったです。 エス・エム・エスに入社することになった決め手は？ そんな状況で選考を受けていく中で、現場の人やビジネスの人とプロダクトや事業の話をするにつれて、エス・エム・エスのやってること、やろうとしていること、めちゃ面白そう！ってなりました。 医療・介護の状況は国の方針、地方自治体の方針、法律改正などで複雑性は増していく一方で、同時に高齢化もどんどん進行している。これから起きるだろう問題は医療費や社会保障費の推移、人口推移等のデータから予想はされているけど、どう解決したらいいかは誰にもわかっていない。エス・エム・エスはそういった課題に対して打ち手を考えてサービスを開発し、課題解決に取り組んでいる。その取り組み方も現場経験者が社内にいたり、また現場に直接ヒアリングしたりしていて(最近はコロナ禍のため、直接のヒアリングはあまり実施できていないみたいですが……)、本当に課題と向き合ってプロダクト開発しているな、と感じました。 そして特に決め手となったのは、これからの高齢社会に必要なサービスを作ることが結果的には自分たちに返ってくるようになるだろうと言われ、たしかに将来自分が引退した時に使うだろうサービスを自分で作ってみるのは面白そうだ！って思ったことでした。 エス・エム・エスに入社してどうだった？ エス・エム・エスはさまざまなサービスを開発していていろんな部署があるのですが、その中でも私は介護事業者向け経営支援サービス「カイポケ」のリファクタリングを行うチームに所属しています。 現在のカイポケは介護事業の複雑さがそのまま反映されているような状態になっていて、 介護のさまざまなサービス種類(居宅介護支援事業、通所介護事業、etc,etc,etc,本当に大量のetc...)に次々と対応していったという歴史的背景からそれぞれが複雑に組み合わさった大きなプロダクトになっています。 カイポケは現在の介護事業を支えるプロダクトに仕上がってはいるのですが、今後の社会情勢の変化やますますの高齢化を迎えるにあたって、カイポケのサービスを5年、10年といった長期で見た場合に今より良い体制はないだろうか、という試行錯誤を続けてきました。 そういった背景があって、カイポケというサービスを適切な単位でのマイクロサービス化したりなどのリファクタリングを行うことで、他に影響しない閉じた改善を行いやすく変化に対して強いプロダクトにしようとしています。 リファクタリングのプロジェクトは本格的に始まったばかりで、プロダクションコードはこれから書いていく段階ですし、チームも出来立てほやほやな感じで、チームビルディングから始めています。また、利用予定の技術スタックもそれぞれに精通している人ばかりではない(私も含め、初めて触れる技術もたくさんある状態)ですし、そもそも対象としている介護事業の複雑さもあって、私たちのチームでは「わからない」を口癖にしようという活動をやっていたりします。 エス・エム・エスは誠実でいろんなことに前向きな人が多いと感じています。こういうのやってみようと言うとすぐに「いいね、やろうやろう」って返ってくる感じで、私的にはとても居心地がいい環境です。また、さまざまな経歴の人がいて層も厚いと感じます。介護業界からきた人もいれば、それとは全く関係ない業界からきた人もいるし(私もその一人)、大企業出身だったりスタートアップ出身だったりで、本当にいろんなバックグラウンドの人がいます。 技術に関しては「この技術を極めたい。この道のプロになる」という人より「プロダクト開発やりたいので、それに必要な技術は習得するぞ」みたいなスタンスの人が多いように感じます。この辺りは好き嫌いあるかもしれないですが、どちらかというと私も後者な感じなので合っているなと感じています。 チームは出来立てでいろんなことが決まっていないふわっとした雰囲気だけどチームで決めていく楽しさがあったり、本格的なDomain-Driven Designでの開発や、React、GraphQL、AWS環境構築などなど初めてやることばかりで毎日が新鮮で楽しくやっています。 エス・エム・エスにはどんな人が合いそう？ 介護業界は更なる高齢化社会を迎えるため、これから未知の問題がいくつも出てくるだろうと予測されています。なので社会の要請もどんどん変わるだろうし、それに合わせてエス・エム・エスのプロダクトもどんどん変えていく必要があります。そういった事業領域でエンジニアに求められるのは変化や未知なことに対する前向きな姿勢だろうな、と私は考えています。 例えば私のチームだと、「マイクロサービスとかバリバリやってたぜ」的な人ももちろん大歓迎なのですが、「マイクロサービスの開発や運営はそんなやったことないけど、やってみたい。他の経験から補いながらキャッチアップしてやっていくぞ」みたいな人も大歓迎です。実際、私のチームで使う予定の技術スタックで誰も専門でやったことがない技術もあります。また私自身も前職はAndroidアプリケーションエンジニアですが、今共通している技術スタックはKotlinや前前職でやったことがあるSpring Frameworkぐらいで他はほぼ初めてのことばかりです。なので新しいことでも状況に合わせて前向きにやっていける人は合っているのかなって思います。 この記事を読んでちょっとでも興味が湧いたら、エス・エム・エスでは転職の意志がなくても話を聞いてみたいって感じでカジュアル面談していますので、是非是非話を聞きに来てみてください！ tech.bm-sms.co.jp

はじめに 医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスのAnalytics&Innovation推進部（ 以下、A&I推進部）でデータ分析基盤開発を担当している長谷川です。 A&I推進部はエス・エム・エス社内のデータを横断的に収集し、データの分析や加工から、データに基づく施策までを行う部門で、現在は介護事業者向け経営支援サービスである「 カイポケ 」や、介護職向け求人情報サービスである「 カイゴジョブ 」のデータ分析やレコメンドシステムの開発を行っています。 今回はその中で「カイゴジョブ」における介護求人の課題をディープラーニングによる分類モデルで改善した取り組みについて紹介します。 介護業界の課題 具体的な説明に入る前に、簡単に介護求人の課題感を説明します。 ご存じの通り、昨今の日本は少子高齢化が進み、介護にまつわる課題が毎日のように新聞やテレビなどで取りざたされていることと思います。 介護業界に関する課題は多くありますが、介護の需要が増大する一方で生産年齢人口減少によりサービスを支える介護従事者の不足が大きな問題となっています。 こちらは公益財団法人介護労働安定センターの調査結果ですが、介護職員全体の不足感は65%以上と高く、また様々な理由により介護従事者の採用が困難になっています。 出典：「介護労働の現状」 http://www.kaigo-center.or.jp/report/pdf/2020r02_roudou_genjyou.pdf このような課題を解決すべく、エス・エム・エスでは介護職向け人材紹介サービスである カイゴジョブエージェント や、介護従事者向け求人情報サービス カイゴジョブ 、介護・医療・福祉の資格講座情報サービス シカトル などの介護・医療・福祉の資格講座情報サービスを通じて「医療・介護の人手不足と偏在の解消」に貢献を目指しています。 A&I推進部の取り組み A&I推進部は、数理技術や先端技術を用いたデータ活用を通じたイノベーションによるエス・エム・エスの事業課題解決を通じた業界への貢献をミッションとした横断組織です。 A&I推進部の業務はデータ分析からシステム開発、共同研究など多岐に渡りますが、今回はその中でもカイゴジョブの開発を担当するプロダクト開発部と協力して進めている施策について紹介します。 介護求人における課題 カイゴジョブは多くの介護求人を扱う検索求人サービスですが、それらの情報を求職者の望む形でどのように届けるか、求職者に寄り添ったうえでどのようなサービスを提供するかについて日々研究・改善を進めています。 求人票の情報の多くはカテゴリ化されたセグメントデータの他に、多くのテキストデータも入力されます。特に介護保険制度は2000年4月に施行された比較的若い制度のため、およそ3年ごとに大きな見直しが入り資格や用語などが変遷してきたという背景があり、その影響で入力されるテキストデータにもかなりの幅があります。 例えば「介護福祉士」は介護職で唯一の国家資格ですが、介護福祉士の受験資格として「介護福祉士実務者研修」があり、これは2013年以前は「ホームヘルパー1級」と呼ばれていました。 そのため「介護福祉士実務者研修」を有する従事者を求める求人票には「介護士」や「実務者（研修）」「ホームヘルパー1級」「ヘルパー1級」「旧ヘルパー1級」などの記載が現在でも多く使われています。 また資格としては「介護職員初任者研修」から「介護福祉士実務者研修」へ、さらに国家資格である「介護福祉士」へと続くため、「介護職員初任者研修以上」と書かれる求人票も多く、この場合は「介護職員初任者研修」「介護福祉士実務者研修」「介護福祉士」いずれかの資格を有する従事者を求めていることになります。 このように介護における応募資格は複雑に入り組んでおり、具体例を挙げるとこのような表記をされることが多いです。 ・初任者研修（ヘルパー2級）以上 ・ヘルパー2級（介護職員初任者研修修了者） ・介護福祉士 ※いずれか必須 ・ヘルパー1級、基礎研修、介護福祉士のいずれか 【いずれか必須】 ■介護福祉士 ■介護職員実務者研修（旧ヘルパー1級） 【いずれも必須】 ・ヘルパー2級（介護職員初任者研修修了者）以上 ・普通自動車免許（AT限定可） 【あれば尚可】 ・介護福祉士（優遇） このようなテキストデータから、介護事業所の求める資格情報を抽出し、レコメンドなどに利用する場合、正確性を担保しつつも様々な表現に柔軟に対応できるロジックが必要となり、A&I推進部ではこの課題に対して最初に正規表現を用いた抽出ロジックを検討しました。 正規表現による抽出 正規表現は法則化された文字列の一致を検出するケースにおいて正確に対象を抽出できますが、求人票のような意味合いは似ているが表現が複数あるようなテキストの抽出を行うには、例外となるケースが多すぎ、それらを全て拾うことが困難であることが分かりました。 例えば【いずれか必須】と【いずれも必須】では意味合いが変わりますし、歓迎資格でも【次の資格・経験お持ちの方は尚可】と【上記あれば尚可】では求人票のどの部分を指しているかが変わるため、正規表現による抽出は断念し、代わりにニューラルネットワークを使った分類モデルの開発に着手しました。 応募資格構造化モデル A&I推進部で開発に着手したモデルは、求人票の応募資格を入力データとし、あらかじめ決められたカテゴリ構造に属するか否かを推論するモデルですので、名称を応募資格構造化モデルとしました。 モデル選定の選定については、入力テキストを時系列と見立て、文章の前後関係を学習するLSTMやTransformer、大規模な事前学習タスクを学習することで汎用性を獲得したBERTがありますが、求人票の応募資格は記述に極端な乖離がなく、介護という専門領域では比較的専門的な用語が頻出することから、事前学習モデルは利用せず、LSTMとAttentionをベースとした独自モデルとしました。 LSTMはディープラーニングの中でも時系列データを扱うリカレントニューラルネットワークの一種で、RNNよりも長期的な依存関係を学習します。 さらにAttentionという、結果に対してどの単語が影響するか注意して学習させる機構を追加することで精度向上が期待できます。 カイゴジョブは介護領域の求人の中でも多くの職種を掲載しておりますので、構造化のカテゴリ数も多く、応募資格構造化モデルでは108種類の構造化を対象としました。 以下はその一例です。 開発当初は1つのモデルで108種類の構造化を行うように設計していましたが、カテゴリによっては訓練データに偏りがあり、また学習時間もかかるなどの問題があったためカテゴリをグループ単位に分割し、4つのモデルを並行で訓練することとしました。 LSTMモデルはテキストを時系列データとして扱うのですが、テキストをそのまま学習することはできず、文字列を単語単位に分割する必要があります。 テキストを単語単位に分割する場合、日本語は英語のように単語の区切りが自明ではないため、文字列を1単語ずつ区切るか、形態素解析器を利用して形態素という単位に分割する必要があります。 例えば「いずれか必須」という文字列があった場合、1単語ずつ区切ると「い」「ず」「れ」「か」「必」「須」の6単語になりますが、MeCabという形態素解析器を利用する場合は「いずれ」「か」「必須」の3つの形態素に分割されます。 応募資格構造化モデルでは求人票の文脈を理解させたかったので形態素解析器を利用した単語分割としました。 またその際、通常のMeCabでは「介護福祉士」は「介護」「福祉」「士」まで分割されてしまいますが、このモデルでは「介護福祉士」を1単語として扱いたかったため、必要な資格は予めMeCabのユーザー辞書に登録しました。 こういった固有表現に強い辞書として mecab-ipadic-NEologd があるのですが、介護の資格である「初任者研修」を正しく分割しないなどの問題があったため、今回は標準辞書にユーザー辞書を足す形で文字列を分割しました。 訓練はGCPのVertex AIを利用し、ai-platformでジョブ登録することで不要なインスタンスが起動し続ける状態を回避するとともに、インプットの訓練データを変数化し同一ソースで複数のモデル学習を並列で実行しています。 gcloud ai-platform jobs submit training $JOB_NAME \ --module-name $MODULE_NAME \ --package-path ./packages \ --runtime-version $RUNTIME_VERSION \ --region $REGION \ --job-dir $OUTPUT_PATH \ --python-version $PYTHON_VERSION \ --scale-tier BASIC \ -- \ --batch-size $BATCH_SIZE \ --epochs $EPOCH \ --train $INPUT_PATH \ 　... モデルの詳細 応募資格構造化モデルの訓練手順を以下に示します。 最初に応募資格テキストの半角文字を全角に変換、記号を除去するなどの前処理を施します。 そのうえで1.の応募資格をMeCabを使い単語単位に分割します。 2.で分割した単語の並びを入力として双方向LSTM+Attentionモデルを通し、各応募資格ごとの確率を出力します。 3.の結果を正解データと比較し、正解との誤差を算出します。 その誤差を最も少なくするために学習を繰り返します。 1～5を繰り返し、誤差が少なくなった時点で訓練を終了します。 モデルの精度と改善の仕組み 約9,000件のデータを用いて訓練を行い、500件のテストデータで評価した結果、99.5%の精度となりましたが、実際の求人票で推論すると成果率は約80%くらいまで落ちてしまいます。 カイゴジョブには誤った推論データをアノテーションできる専用画面が作られており、この画面を通じて入力した訂正結果を訓練データに追加して再訓練することで精度向上を図っています。 データ連携 応募資格構造化モデルはA&I推進部で開発・訓練を行います。 そのためカイゴジョブのサービスとは切り離されており、データの連携は日次バッチで行っています。 求人票をデイリーでA&I推進部の環境へ連携してもらうと、A&I推進部ではその中身を確認し、前日との差分のみを取り出したうえで応募資格構造化モデルで推論を行い、結果をカイゴジョブに戻す形でデータを連携しています。 モデルの活用 カイゴジョブでは利用者の希望条件にマッチした求人情報をメールマガジンという形で定期的にお届けしています。 求職者に入力いただいた希望条件と、求人票の内容をマッチングしたうえで求人票をお送りしていますが、その際に求人票から応募資格構造化モデルで推論した条件を利用してメールをお送りしています。 応募資格によってはほぼ100%の精度となるものや、改善が必要な資格もあり、一定の精度以上の資格のみメルマガで活用し、そうでないものは、モデルを改修して引き続き精度の向上を進めています。 さいごに エス・エム・エスには数多くのサービスがあり、特に介護、医療に特化したデータを数多く保有しています。データサイエンスを活用したサービス向上ニーズも高く、今回の記事で少しでも興味を持って頂ける方がいらっしゃいましたら是非お話を聞きに来ていただけたらと思います。 open.talentio.com

技術推進グループの窪です。 SMSでは主にインフラ全般を見ていますが、主な領域はユーザーサービス側のインフラを担当しています。 入社したのは2017年で、当時と比べるとSMSのインフラは大きく変化してきました。 入社当時はオンプレでしたが約2年半でクラウドに移行し、開発者それぞれがクラウド環境を利用でき、シームレスにログインできるようになりました。 その変遷をご紹介させていただきたいと思います。 入社時はオンプレがメイン 入社した頃はまだオンプレでサービスを運用しており、SMSの中でも介護事業者向けに提供しているカイポケが開発側もインフラ側も課題が大きかったためクラウドに移行する事が急ピッチで進められている印象でした。 当時、私を除いて4名のインフラエンジニアがオンプレを日々運用しており、サーバーやアプライアンスのハードウェアの運用、ネットワークの運用、事業部からくる依頼や調査、オンプレリソースの切り出し、コスト管理などの運用で手一杯で、スキルの継承も難しく属人化が進んでいるように見えました。 私もネットワーク機器やアプライアンスをオペレーションできるスキルがなかったので、インフラを構築してもらいたい時はインフラエンジニアに依頼して待つという状態でした。 このような事もあり全社的にクラウド環境への移行を計画しました。 オンプレからAWSへ移行 クラウドへの移行を進めるにあたり「運用の効率化による持続可能なインフラ体制」を目的とし、以下の方針で進めることとしました。 オンプレの構成を極力変更せずにAWSに移行する。 移行後に課題がある部分を改修し、極力クラウドネイティブな形とする。 既存以外の新規は全てクラウド上で構築し、構築するものはIaCを用いること。 オンプレをそのまま移行するのは「えっ？」と感じる方も多いと思いますが、SMSではとにかく高い頻度でサービスが作られるため課題を先に改修しても、事業が継続しない可能性もあるためクラウドに移すことでの運用負荷を下げる事に注力しました。 移行先は、オンプレで利用していたVMをインポートできる事や、AWSに慣れているメンバーもいたためAWSにしました。 移行の進め方としてはシンプルですが、環境やこれまでのやり方を大きく変えると技術以外の問題も発生しました。 特に課題として大きかったのは関係者の調整が多岐にわたった事と費用面の複雑さでした。 当時SMSは外部の委託が多かったため、結合しているシステムでは、社員にわからないことが増えていく負のスパイラルに陥る可能性のある中で進めていくこととなり、移行が完了するまでに2年半近くの時間がかかりました。 AWS移行時の失敗 AWSに移行する際に１つ大きな失敗をした事があります。 SMS全体のインフラを俯瞰した際にカイポケが最も巨大で、それ以外は比較的小規模なインフラ構成でサーバー要件も複雑ではなさそうでした。 オンプレでは集約率がコストパフォーマンスに影響し、減価償却の分母も大きくなると各事業部の負担も小さくなります。そのため、SMSも小規模なサービスで似た要件のものは同一サーバーに集約していたのだと思います。 後ろ向きな姿勢ではありますが、ブラックボックスが多い中極力変更を加えずにインフラを移行を完了したい事もあり同様の方法で集約して運用するやり方で移行を進めました。 具体的には、１つのAWSアカウントにサービスを集約し、それぞれのインスタンスにリソースタグを付け、インフラの集中管理とコスト効率化を維持させようと考えていました。 しかし、このやり方は実際に多くの問題を発生させました。 AWSは従量課金となり、オンプレのように減価償却で定率のコストではないためサービス単位で費用を分割した際に「A事業部はそこまでつかっていないのにコストが高い」などの公平性とコストが不透明になり事業部が正確なコストを把握しづらくなった事。 リソースタグに対応してないサービスがあり、その費用の分配に関する社内手続きが複雑になり請求処理などのコストが大きくなってしまった事。 権限を厳密にしようとすると権限管理が複雑になりポリシーの上限に達するなど、AWSの制約と運用コストが増えた事。 すぐに、この方式は止めることにしましたが既に移行してしまったサービスもあり是正するのに3年近くかかることとなりました… 後述するAWSのベストプラクティスを無視した構成であった事も原因の１つですが、事業を運営する上で必要な情報や経理などが必要とする情報をスムーズに提供できるかという観点も抜けていたので、構成や運用を１から検討することにしました。 改善されたSMSのAWS構成 現在SMSは全サービスをクラウド上で運用しており、100以上のAWSアカウントをSSOなどを利用して効率的に管理できるようになり、開発により集中できる環境を提供できているのではないかと思います。 構成 AWSのベストプラクティスにもあるのですが、環境ごとにAWSアカウントを作ることが推奨されています。 SMSでは多数のサービスがあるため、最大でサービスの数 * 環境数(Dev,Stg,Prod)となり110アカウントほど現在はあります。 この方式ではAWSアカウントが増えると運用コストも線形に増加しやすい事や、小規模なサービスではオーバースペック気味になるというデメリットもあるのですが、サービス単位で疎結合になりやすい事とインフラの見通しがよくなることで改善に取り掛かりやすくなります。 アカウント運用については、現在はAWS SSOが提供されており運用コストが低くなる構成が作れるのではないかと思います。 SMSは社内でoneloginを利用していたのでoneloginと連携する事で入退社と同時にAWSアカウントへのアクセス制御され、インフラは権限の管理だけに集中する事ができるようになりました。 アカウント管理でインフラ側でやることは「誰を」「どの権限」でログインさせるかだけに注意するのみです。 LPやHTMLのみの簡易的なサービスに関してはAWSアカウント単位で分離すると逆に運用の手間が大きくなるため同一VPC内でもサイト間の通信はプライベート通信を使わない事やVPC Peerをさせない事で通信レベルは疎結合を保ち、もしそのサイトが大きくなっても個別にAWSアカウントを作れば移設が容易な構成にしました。 共通リソースの提供 前述の通り、SMSではサービスが高い頻度で作られます。そのため共通で利用するリソースをManageと言われる共通リソースだけを提供するAWSアカウントを用意し、VPC Peerで接続するだけで提供できる形にしています。 Manageの役割は主に踏み台、メールサーバー、ログ収集、監視、監査です。 特に監査はアカウント数が多くなると、監査自体が困難になってしまうのでAWS Config、GuardDutyで全体のガバナンスを保てるようにし、違反があればSlackに通知されます。 こうすることで基本的なAWS利用ルールはあるのですが、いつでも気付けるようにすることで制限なしでAWSを利用できるようにしています。 AWS移行を終えて AWSに移行して運用負担が大きく効率化されたのはもちろんですが、最大のメリットは属人化する要素が少なくなったことと、インフラの透明性が高くなった事で個人への権限の分配がしやすくなったと考えています。 まだ試験段階ですが全エンジニアにAWSのサンドボックス環境を個別に提供もできるようになってきました。 オンプレやアプライアンスがあるとどうしても特定の人にスキルが偏ってしまい、スキルの継承もその人のやる気次第となり組織としては常にアンコントローラブルな要素を持つことになり、持続させることが難しくなります。 オンプレと比べると今は複雑さが少ないコスト体系なのでインフラ以外の人もコスト意識を持つことができ、IaCで管理すれば再現性も担保される状態にあるので当初目標にしていた「運用の効率化による持続可能なインフラ体制」に近づけているのではないかと思います。 おわりに こうして4年近くかけてAWS移行から定着へと進めてきましたが、実際には個別の運用や対応が続いていたり、レガシーシステムをクラウドネイティブに持っていきたいけど工数面などで進んでいなかったり、AWSの布教ができていなかったり、などの課題が多く残っている状態です。 特に事業部によって特性が異なり、個別対応が必要なケースは悩まされますが「インフラをどのように適用すると事業がドライブしやすくなり、SMSが成長し社会に貢献できそうか」と考えながら進められる仲間がほしいなと最近思っています。

はじめまして、2021年8月よりエス・エム・エスに入社した熊谷です、10月で37歳になりました。これまでに約60万人の会員を保有していたポイントカードシステムの開発や、営業支援システムの開発に携わって来ました。 “入社エントリを書いてみませんか？”と社内で打診があった際、「書いてみたい！」と二つ返事をしてみたものの、いざ過去記事を見ると、メガベンチャー、ナショナルクライアント、世界最大手クラウドベンダーからの転職など凄い経歴の方ばかり。 異色のキャリアを歩んでる自覚はあったので、「やはり私の入社エントリなぞ書かないほうが良いのでは・・？」とご相談したところ、”むしろそのキャリアも含めて書いてほしい”とのことでした。 この記事では私の入社前のキャリアから、転職を考えたキッカケ、入社を決めた理由、そして入社した後の印象を皆さんにお伝えできればと思っています。 それと併せて、もし入社エントリー tech.bm-sms.co.jp を見て”ハードル高そうだな･･･”と感じていた方がいらっしゃいましたら、 私のような人間もおりますのでどうぞご安心下さい とお伝えしたいです（笑）。 ぜひ気軽に カジュアル面談 にご参加頂ければと思っています。 入社までのキャリア 新卒の話になると早15年前になってしまうことに年齢を感じます。当時は大手メーカーの携帯電話（まだ2つ折りが主流だった時代）工場にてソフトウェアQA部内の検査ツール開発を行っていました。 2年ほどその企業に在籍していましたが、その後は知り合いに誘われるがままに転職することに。 転職先の企業はいくつかの事業を持っており、その中の1つに立ち上げたばかりのタクシー事業もありました。タクシー事業の在籍になった私は、当時原野状態だったタクシーの管理システムをイチから作る気満々で居たのですが、気づけばあれよあれよと二種免許を取得しタクシーを運転する方に早変わり。その後3年間、タクシー運転手が私の仕事となりました。 この3年間がソフトウェアエンジニアとしてのブランクにあたるかというと実は違いまして、同企業で運営していた他サービスの開発相談なども同時に受けていたこともあり、タクシーに乗りつつ、黙々とプログラミングやシステム設計の勉強を進める、という中々に異質な生活を送っていました。 道玄坂にある「とある会社」の前でご乗車頂いた”プログラマっぽいひと”に片っ端から声をかけ、勉強を教えてもらっていた過去もあります。今考えると滅茶苦茶ですが、当時は急拡大する事業に対応するため必死でした。タクシー運転手がお客様に勉強を教えてもらう、という異常な状況にも関わらず親切丁寧に教えて頂いた方々、本当にありがとうございました。今の私があるのは皆様のおかげです。 そんな生活を重ねつつも、やはり開発側の比重が増えていき、3年後に同企業の開発部へ移籍となりました。 一番最初の仕事は当時60万人の会員数が居た共通ポイントカードサービスのシステムリニューアルです。 当時は私を含め社内のエンジニアは3名ほどしかおらず、運用・保守の大部分を外部企業に頼っている状況でしたので、社内リソースのみで運営出来るような”自社化”を含めたリニューアルを企画しました。 そして、この”たった数名の社内エンジニアで”というのがうまく作用しました。少ないリソースで運営していくには、最も重要な機能開発などに多くのリソースを割ける状況にしていかなくてはいけない。そう考えた結果、移行先のサーバーとしてHeroku、フレームワークにLaravelを選択し、「インフラ管理の大部分を省く」ということを前提にリニューアルを進めました。2014年のことです。 AWS FargateやGoogle Cloud Runに通ずるServerlessやコンテナ技術に当時からイチ早く携われているため、結果論ではありますが、この判断は正解だったと思っています。 さて、そんな形で同企業に在籍していく期間が伸びていくにつれ、会社が飛躍的に大きくなり、同時に私の役職も上がっていきました。プログラマから開発部の部長へ、そして事業統括というポジションから事業戦略に通ずるシステム投資の価値判断など。上流工程の部分はもちろんあるのですが、社外へ開発を依頼する前のプロトタイプ的な実装なども兼務していたので、最終的なポジションでもずっとコードが書けていたのはとても幸せでした。 転職を考えたキッカケ 在籍期間も12年を超えていくなか、自身も30代半ばの年齢に差し掛かり、色々と思うところも出てきました。前企業は特定の分野・業界に根ざしているわけではなく、チャンスと見れば未経験の業界にもドンドン進出していきます。当然失敗も多いのですが、「失敗して元々」「経験から学ぶ」がモットーのような姿勢からか、次々と新しい企画や事業が立ち上がります。 若いうちは”当たって砕けろ”の精神で立ち向かえた自分も、年齢を重ねるごとに「このままで良いのか？」と考える日々も多くなりました。 一方で、条件面や待遇に不満があったわけではありませんでしたので、「今の会社に残るかどうかも含め一度考えを整理したい」という思いから、いくつかの会社からお話を伺うことになりました。エス・エム・エスとの一番最初のカジュアル面談も、「お声をかけてもらったので」という程度のことですし、今だから言える話、何をやってる会社かも全く知りませんでした。お話を伺って初めて「あ、医療・介護の会社なんですね」と言うレベルです。 エス・エム・エスに入社を決めた理由 有り難いことにいくつかの会社からオファーを頂きつつも、最終的にエス・エム・エスに入社を決めたのには、大きく2つの理由があります。 1つ目は、面接を重ねていくに連れ、入社後のイメージが上手くついたことです。他社の採用面接と違った点の1つに、技術責任者の田辺さんを始めとして、「エス・エム・エスがいかに素晴らしい会社か」という話を延々とされるのではなく、「今会社にはどのような課題があって、どういった部分に困っているんです」という話しを多くして下さいました。 採用面接というのは中々に難しく、“お金と時間をかけている以上、基本的には入ってほしい”ものであり、“出来る限り自社のことを良く見てもらいたい”ものだと認識しています。 そんな中、課題の共有は極端に言うと出来ていないダメな部分を見せる行為ですので、中々に勇気がいることかなと思っていますが、結果として「（課題に対して）自分は何ができそうか？」「どういう形で貢献出来るか？」など、入社後の動きや働き方のイメージが具体的に出来たこと、また課題をありのまま共有頂ける誠実さを感じられたことが大きかったと思います。 2つ目は、最終面接でお会いした社長の後藤さんとの話です。私が後藤さんに対して投げかけた質問に対する回答が、入社の意思を固める決定的なものになりました。 その質問内容は、 「エス・エム・エスはどういった考えのもと事業やサービスを展開していくのですか？」 というものです。 この質問の背景には前述で記載した通り、当時在籍していた企業が様々な分野に進出していくことで素晴らしい経験をしてきた反面、苦労してきたことも多かったからです。何をやる会社なのか、何をやらない会社なのか。これを知る意図で質問したところ、次のような答えが返ってきました。 “人口動態の変化で生じる歪みのうち、社会保障だけでは解決出来ない領域を、ビジネスとして解決する” 私達が生きている日本という国で超高齢化は避けられず、2025年には人口の3.3人に1人が65歳以上と言われています。この流れが更に加速していく中、求められる社会保障のあり方というのも変わり続けています。土台としての社会保障というのは今後も欠かせないものとして提供されていくでしょう。一方、国の制度として広く提供していくことや社会の変化のスピードに合わせる必要があることを考えると、社会保障が埋めきれない領域というのも常に存在し続けます。ここにビジネスが介在して持続的に解決していく機会と価値があります。「エス・エム・エスは医療・介護の会社」なのではなく、「医療・介護」が社会保障だけでは解決出来ない領域の1丁目1番地だから、事業として手掛けてるんです。 この回答は、質問の背景にある「何を事業としてやるか・やらないか」という問いに対して、自身の中で完全にマッチするものでした。それと同時に”残りの人生で、どうせ長い時間仕事をしていくなら、わかりやすく誰かの為になりたい”という風に考え始め、これらの意識が「辞めるか残るか」と迷っていた前職に対し、一つの踏ん切りをつけられる理由になりました。 医療・介護は、現代を生きている私達にとって不可欠なものです。例え今は特別重要でなかったとしても、数十年後にはきっとたくさんお世話になるはず。なのでまず 自分自身を含めた、身近な人の将来を支えていける を目標にしようと思い、転職することを決意しました。 入社後の印象 前述の通り、課題感の共有を面接時にして頂いていたこともあり、入社前後におけるイメージのギャップはほとんどありませんでした。またエス・エム・エスの社員の皆さんも、カジュアル面談で感じていた誠実な人たちばかりで、非常に働きやすいな、と感じています。 配属先のチームは最初から固定されておらず、数週間に渡ってチーム体験ツアー tech.bm-sms.co.jp を通じていくつかのチームの様子をお伺いし、その中からエス・エム・エスの キャリア事業領域 において、業務基盤として機能しているカスタマーサポート/顧客管理ソリューションチームに入ることに決めました。理由は至ってシンプルで（入社前から話しは聞いてましたが） 一番困ってそうだったから です。 エス・エム・エスは2003年の創業以来、短期間で急成長をしてきました。その過程でグループの統合などもあり、作られてきたサービスや基盤などに未だチグハグな部分も残っています。これらを「あるべき姿」へ変えていくのが私のミッションになります。 もちろん話は単純なシステム改修に留まりません。経営戦略として必要になるであろう機能・データは常に要求されますし、ビジネスサイドとのコミュニケーションとバランスを取ることや、平時の運用業務もパワーが必要なものもありそうです。また、“業務でヘビーユースされているにも関わらず”メンテ不全になっているツール類もあったりします。これらが今後起こりにくくなるような、「組織文化」的な部分にも少しずつ踏み入っていく必要性を感じています。 WEBエンジニアの方々は、エンジニアがなぜ「カスタマーサポート/顧客管理ソリューション」なのかと思うかもしれませんが、最近のCRMツールはWEBのテックトレンドをかなり意識しています。 例を上げるとSalesforceです。最近は Salesforce DX という試みから、CLIからのデプロイ操作やGit管理も可能となり、スクラッチ組織という使い捨て可能なテスト環境が用意されたりなど、開発体験がかなりモダン化されました。利用できる言語も元々はAPEXだけだったのが、Winter’22では Salesforce Functions というServerless環境が用意され、Node.jsやJavaでコードが書けるようになりました。 また、現在はまだPilot版ですが、複数存在したAPIを全て包括するようなgRPCベースの Pub/Sub API も計画されています。 このような最新の技術スタックを追従したい方にも、私達の運用チームはぜひオススメです。 時代に寄り添い、変化し続けられること 「継続性アーキテクト」という生き方 - エス・エム・エス エンジニア テックブログ tech.bm-sms.co.jp の記事でも語られているように、現代では「作って終わり」という開発は減ってきており、サービスの成長段階やニーズによって「あるべき姿」を柔軟に変えていくことが望ましいとされています。 そしてそれらは、サービスのみに留まらず 社内で利用されている業務基盤としてのアプリケーションも同様なはず です。チーム・組織・会社がそれぞれの成長段階で、市場によって、社会によって、時代によって変化していきます。 上記を実現するために必要なことは、一言で片付けるなら「柔軟性のあるシステム設計が重要だよね」に集約されてしまうんですが、それが一朝一夕で達成出来ないことは、ソフトウェア開発に携わっている皆さんであれば共感して頂けるでしょう。 幸いにもエス・エム・エスは、これまで同事業領域において20年近い実績があり、その過程で生まれた業務知識が山のようにあります。これら1つ1つを紐解きながら整理し活かし、あるときはバッサリ捨ててビジネスプロセスから考え直したりなど、やれることも、やらなくてはいけないことも膨大にあります。 これらの作業は非常にタフではありますが、もともとタフな仕事を求めていたというのもありますし、「この状況下でこれだけ業績が伸びている」というのはウラを返すと、事業としてもまだまだ伸びしろがあるということなので、非常に楽しみな部分でもあります。 入社後2ヶ月（執筆時点）で、長い道のりのやっと一歩目を踏み出せたかな、という感覚です。険しい道ではありますが、入社の動機にもある「身近な人の将来を支えていける」こと、 そしてこの記事を見て下さった皆さんの、ひょっとしたら数十年後を支えられるような仕事が出来れば この上なく嬉しい限りです。 勿論、私一人では不可能なので、ほんの少しでも共感して頂ける方がいらっしゃいましたら、ぜひカジュアル面談などでお会いしましょう。 カジュアル面談からOK/アーキテクト・テクニカルリード職 - 株式会社エス・エム・エスのWebエンジニアの採用 - Wantedly