介護職向け求人情報サイト「カイゴジョブ *1 」の開発をしている児玉卓也です。 弊社の プレスリリース でお知らせしているように、カイゴジョブは2022年5月にデザインリニューアルを行いました。 デザインリニューアルにはサイトのコンセプトなどはそのままで、UIなどの見た目を部分だけを変更するものから、コンセプトやユーザーシナリオというサービスの基盤となる部分から再設計し直すことがあるかと思いますが、カイゴジョブが行ったデザインリニューアルは後者の方で、カイゴジョブにおける求職者の体験をより良くするためにコンセプト・ユーザーシナリオをアップデートした上でデザインを全面的に変更しました。 全面リニューアルとなるとその影響範囲は大きく、特にプロダクトの品質を保ちつつ大規模リリースをすることは、経験された方にはわかると思いますが大変な作業となります。今回のデザインリニューアルでは40,000行、900を超えるファイル数の変更となり、我々が日々行っているリリースの数百倍くらい大きなリリースとなりました。 デザインリニューアル時のPRの変更行数 本記事では私達が大規模リリースをしなければならなかった理由を説明した後に、どのような開発手法を用いて大規模なリリースを安全に行えたかについて説明したいと思います。 デザインリニューアルの背景 環境の変化が激しく不確実性が高まる時代ではありますが、介護業界も例に漏れず変化が激しい業界です。カイゴジョブも市場の変化やユーザーニーズの変化に合わせて新機能を追加するなど求職者への価値提供を追求してきました。そのような中でビジネスモデルの変革を進めていくこととなりました。 ビジネスモデルが変わったことで求職者に期待したい行動やサイト上でのゴールも変わりました。しかし、サイト全体の体験は2019年に設計したものであったため、機能の開発をする際に既存の導線との接続であったり、体験の整合性をサイト全体と合わせるのが困難と感じることが増えてきました。 その問題を解決するためにデザインリニューアルを行い新しいビジネスモデルにそった体験を提供することとなりました。 アジャイルなビックバンリリース 前述したように今回のデザインリニューアルではサービスの基盤となるコンセプトから作り直していることもあって、画面単位、コンポーネント単位に分けてリリースをしてしまうと全体の動線の中で体験の整合性が合わなくなってしまうので、全画面の開発完了後に一斉にリリースする必要がありました。 このような大規模なリリースをしようとする際に、開発工程が完全に完了してからQAテストを行うとなると、バグが見つかったときの手戻りのコストが大きく、また、バグの度合いによってはリリース時期の延期をせざるを得ない状況となってしまいます。そのような事態になることは避けたかったので、開発工程と並行してテストを行えるようなプロセスで進めていきました。 このプロセスで開発をすすめる上で、タスクの作成方法と優先順位付けがポイントとなります。 テスト可能な単位でタスクを作成 まず、タスクの作成方法ですが、QAエンジニアによるテストの実行が可能となる単位でタスクを作成していきます。 私達の開発チームはエンジニア、デザイナー、QAエンジニアが1つのチームとなって活動しており、日々の活動の共有に加えて、チームの活動のふりかえり、さらに実装前のフェーズである要件定義なども一緒に行い、密にコミュニケーションをとるチームであることが特徴です。 デザインリニューアルのプロジェクトにおいても、普段の開発と同様に要件定義やユーザーストーリー作成のフェーズからQAエンジニアに参加してもらい、何を作らなければならないかを対話しながら具体化し、共通理解を深めながらタスクを作成し管理します。QAエンジニアは受け入れ条件を開発前から把握できるため、開発と並行してテストシナリオの作成などテスト実行に向けた準備が可能となります。 また、QAエンジニアが要件定義の場にいることで、仕様に抜け漏れがないか、不具合が入り込む余地がないかなど、QAエンジニアの観点で提案をもらうことができ、開発着手する前に不具合に気づくこともできました。 テストの優先度の高いものは早めに着手する デザインリニューアルのプロジェクトでは事業の影響度、開発コストなどの基準に加え、テスト優先度を含めて優先順位を決定し、開発・テストの取捨選択をしていきました。 基本的に事業への影響度が高いものはテストの優先度も高くなりますが、テストを効率よく進めるために以下の観点も重要視しています。 テストボリュームが多くなりそうな改修であるか 仕様が複雑そうな改修であるか テストの優先度が高いものは不確実性が高く、早期に解消しないとリリースブロックとなる可能性もあるので、優先順位付けをする中でも重要な基準となります。 副次的効果 開発・テストのサイクルを繰り返していくプロセスの副次的効果として、バグの修正が容易であることが挙げられます。というのも、開発完了からテストのフィードバックまでのリードタイムが短いため、バグ修正の際もコンテキストや実装内容の詳細の記憶を思い出す労力を多くかけずに対応できるからです。 おわりに 今回、私達は開発とテストの工程を並行するプロセスを採用し、デザインリニューアルプロジェクトを進めてきましたが、はじめからこの開発手法を確立できていたわけではありません。日々のプロセスの中で上手くいったことや課題に感じたことをチームでふりかえりながらプロセスを最適化してきました。 デザインリニューアルを終えた後もプロジェクトのふりかえりを行い、QAエンジニアが実施したシナリオテストを自動テストに落とし込んでいきたいなど課題が見つかり、今後も継続的に改善していきたいと思っています。 最後になりますが、デザインリニューアルによってカイゴジョブは求職者にとってより使いやすいサービスとなりました。しかし、求職者に提供できる価値はまだまだたくさんあると感じています。今後も求職者の圧倒的な不足という社会的な課題を解決するために、プロダクトの価値を高めていきたいと思っていますので、興味のある方はぜひお話を聞きに来てください！ *1 : カイゴジョブは介護業界に特化した求人情報サイトで、2004年より展開しているサービスです。利用者はカイゴジョブのサイト上で求職者の希望に近い求人を検索し応募できることに加え、電話での求人検索や、応募手続きができます。 介護特有のこだわり条件で求人を探せることなど、介護に特化した求人情報サイトであることが特徴の1つでもあります。

はじめまして、カイゴジョブの開発をしている真下です。 皆さんは今自分が所属している会社が事業を行なっている業界に対して、興味を持っていますでしょうか。また、入社時にはどの程度興味を持っていましたか。 エス・エム・エスが事業を行う業界に対する印象 私は前職では、所謂エンターテイメントの業界でWebサービスの開発を行なっていました。当時は、この業界への強い興味があったわけではありませんが、業界全体の雰囲気が何となく面白そうだと感じて入社し、結果的には、サービスの開発自体に対して面白さを見出して働いていた思い出があります。 一方で、エス・エム・エスは「医療・介護・シニアライフ・ヘルスケア」の業界で事業を行なっておりますが、私はエス・エム・エスに入社するまでこの4つの業界での業務経験は全くありませんでした。入社する前は、これらの業界に対して元々そこまで強い興味や理解がなく、「業界に対する高度な知識や理解が必要である」という印象がありました。このような理由から、エス・エム・エスでしっかりとやっていけるのだろうかという多少の不安がありました。しかしながら、入社して約１年が経ち、これまでを振り返ると日々やりがいを感じながら楽しく業務を行ってこられたと感じております。 アンケートの実施 弊社には、例えば「クラウドベンダー」「金融」「ゲーム」といった様々な業界経験をバックグラウンドに持つエンジニアが在籍しております。 そこで、弊社のエンジニアは「医療・介護・シニアライフ・ヘルスケア」の業界に対して、どの程度興味を持ってエス・エム・エスに入社したのか気になり、アンケートを取ってみました。 アンケートでは以下の項目について回答してもらいました。 入社時、エス・エム・エスが事業を行なっている業界(医療・介護・シニアライフ・ヘルスケア)への興味はありましたか？以下の３つから回答してください。 1: とても興味があった 2: まあまあ興味があった 3: 全く興味がなかった アンケートの集計結果は以下のようになりました。 回答者のうち、入社時にはエス・エム・エスが事業を行なっている業界に対する興味を全く持っていなかった人が約３分の１を占めるという結果になりました。このアンケート結果から、弊社のエンジニアはエス・エム・エスが事業を行なっている業界以外の、別のどのようなところに興味があったのか、そして今はどのようなことに魅力ややりがいを感じているのか気になり、何人かのメンバーにインタビューしてみました。 エス・エム・エスで働く魅力 インタビューでは、以下のように様々な観点からの回答が得られました。 介護・医療などの業界に対しては元々興味がありませんでしたが、入社前に技術責任者の田辺さんから聞いた事業説明で、エス・エム・エスが事業を行なっている「医療・介護・シニアライフ・ヘルスケア」の業界そのものというよりは、その業界の中で行なっているエス・エム・エスの事業が面白そうだと感じて、入社しました。事業の面白さは入社後にも感じながら仕事をしていますが、入社後に発見した面白さとして、業務ルールの複雑さがあります。現在担当しているプロダクトには、介護保険制度が関わっていて、その制度に由来する複雑な計算ルールをシステムに落とし込む必要があります。これは難しいと感じる一方で、やりがいを感じている点でもあります。 (エンジニア) 前々職は、医療業界で事業を行う会社に所属していましたが、業界に対しては特に強い興味を持っていませんでした。そして、エス・エム・エスに対しては、なんとなく社会貢献できるイメージの会社であるという印象を持っておりました。一方で入社後には、エス・エム・エスが行なっているビジネスモデルの幅広さが面白いと感じるようになりました。例えば、現在私が担当しているカイポケはフィンテック領域に関わるような事業があったり、シニアライフ領域では食事に関する事業があったりと、「医療・介護・シニアライフ・ヘルスケア」の枠を超えて事業を行なっている印象があります。(エンジニアリングマネージャー) 前職は営業代行系の事業会社に所属しており、全く異なる業界にいました。入社前には、医療や介護の業界に対する興味ではなく、これらの業界自体の市場の拡大に興味がありました。そして、入社後に自分が担当しているサービスは、医療介護に直接関わっているというよりは、その業界で、人材紹介のビジネスモデルを行なっている構造になっています。この業界における求職者のニーズを考えるのが面白いと感じています。また、転職というライフイベントを支えるサービスのサポート戦略を考えることにやりがいを感じています。 (エンジニア) 私が現在担当している「カイゴジョブ」というサービスについても、名前から想像されるような介護サービスというよりは、むしろ求人広告サービスや業務システム開発のような要素が強く、ユーザーが使いやすい検索システムデザインを考えたり、使いやすい管理機能の開発をするといったようなことに対して面白さを感じています。 業界への関心をハードルに感じる必要はない エンジニアとして働くにあたって、自分が作るソフトウェアが使われる領域への興味を最初から持っているのはもちろん素晴らしいことです。しかし実際には、別のところに面白さややりがいを見出しているケースも多いと思いますし、今回の社内でのアンケートとインタビューでも、入社前はそこまで強く業界への関心をもっていなかった人が多かったことがわかりました。 「介護・医療・シニアライフ・ヘルスケア」と言われると「あまり身近でないな……」などと感じる人も多いかと思いますが、あまりそこをハードルに感じずに、話を聴きにきていただけるとうれしいです。

はじめに プロダクト開発部でキャリア事業のEM（エンジニアリングマネージャー）をやっている大野です。前回は、私がエンジニアリングマネジメントをするに当たってどのようなアプローチをとっているのかを紹介しました。 tech.bm-sms.co.jp 今回は、他のEMと会話している際に、「EMが取り組む施策は失敗する可能性が高いよね」という話があがり、それに対して共感できる部分もありつつ、じゃあどうすればいいのか？を考える機会になったので、まとめてみました。 EMが取り組む施策は失敗する可能性が高い？ EMやそれに近しい役割を経験したことのある方なら、思い当たることがある人も多いのかなと思います。 自身の成功体験を元に組織改善しようとするが、中々変えることができない 他社のよい事例を参考に、自社での取り組みを開始したがうまく軌道に乗らない などです。 私自身も、過去こういった経験がそれなりにあり、現在でもそういった場面に出くわすことはあると感じます。 なぜそういったことが起こるのか 一概にこうだ！という理由はないと考えていて、たとえば以下のような阻害要因が経験としてはあります。 現場とEMとの温度差 現場は常に忙しく、余力がない EMとメンバーで見えているものが違い、課題として認識していない 導入時はよかったが、除々に形骸化したり廃れてしまった どうすればいいか？ こういった課題を解決するために、どうすれば組織・チームが動くのかをEMは日々トライ&エラーを繰り返していく形になります。こういった答えが明確にない課題解決を繰り返していくことで、EMとしてのスキルが磨かれていくと感じています。 私自身、何かに取り組む際、最低限意識するよう心がけていることがあります。以下でそれらをご紹介します。 1. まずは情報収集 前述した阻害要因の多くは、自分の持っている情報が不足していることに起因しています。そのため、今でも1on1やエンジニア以外の職種の方と接する機会を活用し、課題感を把握するよう努めています。 2. 期待値のすり合わせ もう1つ大事なこととして、相手との期待値を合わせていくことです。 EMがやりたいことを理解してもらい、そこにメンバーも同じような期待値を持ってもらうことで、取り組みの進み方が変わってきます。 3. セカンドペンギンを意識する ビジネス用語のセカンドペンギンとは少しニュアンスが異なるのですが、勝手にそう名付けています（笑）何か新しい取り組みをする際、1人目が動いた後、2人目、3人目が続くか、同じような熱量で取り組んでくれるか、がその後に大きく影響します。 私自身、推進していく内容に合わせてファーストペンギンになることもあれば、セカンドペンギンになることもありますし、すべてメンバーに取り組んでもらうこともあります。 4. 失敗を恐れないチームづくり これは言葉のままですが、何かチャレンジしようとした際のフットワークの軽さに影響します。失敗しても問題がないことや、そもそもチャレンジを推奨するようなチームにしていくべきです。 たとえば、リファクタリングと影響範囲に伴う不具合の懸念等を天秤にかけているメンバーがいた場合には、 万一、不具合が発生してもリカバリーすればよい 合わせて自動テストを書くチャンス など、チャレンジを後押しするよう日々接することで、チーム文化として根付いていきます。このような文化を作っていくことで、EMのやろうとしていることについても「すぐにはうまくいかないかもしれないけど、チャレンジしてみよう」とフォロワーシップを発揮してくれるメンバーが増えてくるのではないかと思います。 EMの職能 上記で記載した内容は、とても重要とは思いつつも、「どういうスキルか？」と問われると一言で表すことのできない難しさがあります。 情報収集する際に、専門的な知識が必要になる場合もありますし、事業理解が必要な場面もあります。期待値を合わせていくのに、信頼関係が構築できているようなコミュニケーション能力も必要でしょう。 そういった正解が決まってないことに対して自他の強みを活かし、成果を出すのがEMで、その再現性を高めるのがEMの職能となるため、EMの職能がはっきりと定義されたものを見ないのはそういう面があるのかなと思います。 経験上、EMとしてトライ&エラーを多く経験している人ほど、上記のような自分なりのやり方の引き出しが多い印象です。 おわりに 今回は他のEMとの話をきっかけに、EMの失敗からの学びと、そこからどういった行動に結びつけて解決していけばよいかを考える機会になりました。

介護事業者向けの経営支援プラットフォーム「カイポケ」で、プロダクトマネージャー兼アーキテクトを務めている三浦です。 11月2日にオンラインで開催された、プロダクトマネージャーカンファレンス 2022（pmconf 2022）で、「日々の意思決定で使うB2Bプロダクトマネジメントサイクル」のタイトルで発表しました。 発表要旨は以下のとおりです。 プロダクトマネージャーの重要な仕事の一つに意思決定があります。ユーザー価値を生み出すために、プロダクトマネージャーはプロダクトマネジメントトライアングルそれぞれの観点から次に作るものは何か？要件は何か？作っているものはユーザー価値があるのか？など様々なイシューに対して開発チームとして日々、意志決定をしなければなりません。さらにB2Bプロダクトの場合は法令や行政、マーケット、プロダクト導入決定者の観点が加わり、プロダクトマネージャーにとって意思決定は難しいものになります。 このセッションでは、B2Bプロダクトマネジメントにおいて必要な観点が何かを整理し、どうやってプロダクトマネジメントトライアングルを使って意思決定をしていくのか実例を交えて紹介します。 （セッション内容紹介より） 2022.pmconf.jp この記事では、発表資料とともに、発表時に寄せられた質問の一部への応答・補足説明を公開します。 発表内容やカイポケの開発についてより詳しく聞いてみたいという方は、 ぜひカジュアル面談にお越しください！ open.talentio.com 資料 質問への回答・補足説明 Q：複数の介護形態でペインの発生場所も異なる中で、どのように優先度をつけてきたか、これまでとこれからの話も踏まえてお聞きしたいです。 前提として、介護業界は非常に広大な市場ですので、基本的には介護業態によって市場が細分化できます。その上で、優先順位は、マーケットの大きさ、エス・エム・エスの強みがフィットするかなどの要素を掛け合わせて決めています。まずは細分化した市場を選んで、特に注意すべきペインに取り組んでいくという形です。 Q：歴史の長いプロダクトだとは思うのですが、それならではのプロダクトマネジメントの難しさはありますか？ 歴史が長いので、「どうしてこういう仕様になっているのか」という仕様がわからない箇所がどうしても出てきます。カイポケは18年以上の歴史がありますので、当初のメンバーは当然ほとんど在籍していません。そうすると、仕様の「なぜ」はもはやリバースエンジニアリングで解き明かしていく感覚になります。 Q：アクセスコントロールの例で、外側のトライアングルから具体化していくのが分かりやすくていいと思ったのですが、トライアングルのバランスはどんな感じで取っていくのでしょうか まずはトライアングルの登場人物のペルソナを考えています。 開発者の市場...エンジニア 顧客(ユーザー)...介護事業、意思決定者(経営者) 行政(GTM: Go To Market)...厚労省、財務省 三者が何を考えていて、今後何をしたいのか？を意識的に考えています。その上で、例えばAという要件に対して三者が「いいよね」って言ってくれるかどうかを考えて判断しています。 Q：トリプルトライアングルを用いて意思決定するときにバーティカル SaaS ならではのアプローチってありますでしょうか？よく使うパターンがあるのかどうか気になります！ 前提として、個人的にトリプルトライアングルを使うのはtoB向けがメインだと思っています。 そしてVertical SaaSになると、「ペインの深さ」だとか、「業界にいかに深く入り込めるか？」がポイントになってきますので、トリプルトライアングルの三つの角をさらに分解する、例えば顧客(ユーザー)でも「経営者、管理職、従業員」とさらにトライアングルを作って考える、といったアプローチを行っています。 Q：法令対応はドメインエキスパートのような方がいるのでしょうか？難しそうです。。 もちろんいます。介護業界からドメインエキスパートとしてお越しいただいた方もいらっしゃいますし、おなじく介護業界出身の方がPdMをしているケースもあります。 業務上の細かなやり取りや、無数に種類がある帳票などについて、どういう目的で作っていて、次の工程は何か、などを把握して開発していくには、やはりドメインエキスパートの存在は不可欠です。 Q：トリプルトライアングルの導入について、どう使えばいいかわからない？という事がありそう…つまずいたポイントなどあれば教えて下さい 外側のトライアングルから考えることは大事だと考えています。 最初は内側のトライアングルから整理していました。しかしそうすると、例えば、アクセスコントロールについて足りない観点が出てきます。カイポケの場合であれば、行政の出しているガイドラインで遵守すべき項目が定められており、これは最初から要件として取り込んでおく必要があります。 外側のトライアングル(法令)から要件を抽出していかないと「蓋を開けたら法令遵守できてないかも？」みたいなことが起こるとわかってきたので、外側からトライアングルを作り始めるようになりました。

はじめに プロダクト開発部でキャリア事業のEM（エンジニアリングマネージャー）をやっている大野です。今回は自分が見ているチームに関して、普段どういったアプローチをしているのか？という話を元に、自身のマネジメント術に関して深堀りしていきたいと思います。 一般的なEMとは？ 企業におけるフェーズや組織設計で、EMが持つ役割は変わるものの、大きくはピープルマネジメントを行いつつ、プロジェクトマネジメントやテックリード、プロダクトマネジメント等組織に必要な役割を多岐に担っている形が一般的なEM像かと思います。 大野の担当範囲 私自身、前職を含めると約9年EMに近い役割を担っています。 最近だとピープルマネジメント、テックリードが主で、状況次第でプロジェクトマネジメントやプロダクトマネジメントに近い役割で動くこともあります。 マネジメントボリュームの話をすると、エンジニア30人弱をEMとしてマネジメントしており、事業としても様々な方と仕事を進めるため、ステークホルダーとしては100名超の方とお仕事させてもらっています。 よく聞く「マネジメントは多くて10名まで」という一般的な数からするとかなり多い部類になるのかなと思います。 そのため、どうやって回しているのか？と聞かれることもよくあります。 こういった背景から、今回自分の仕事術を深堀りしていくことで参考になる人も多いのでは？と思った次第です。 ピープルマネジメント編 まとめてみた結果、極力、「マネジメントコスト = 人数*時間」にならないようにしているなと自分でも理解しました。 まずは任せる メンバーと仕事を進める際、可能な限り裁量を渡すようにしています。 事業側とのコミュニケーションをどう取るか 開発におけるリファクタをどう進めるか などの裁量を渡すことで、メンバー自身が考える成長機会となり、チームの成長に結びつきます。 任せる上で大事なこととしては 狙いを伝える（裁量を譲渡すること・自分で思考する等） 失敗も経験として恐れないこと チャレンジした上でキャパオーバーするものは手伝う あたりに気をつけて伝えています。ここが認識合わせできていないと、ただの丸投げとなってしまうので気をつけないといけない部分です。 1on1よりも普段の接点を増やす これは前職で30人マネジメントすることになった際に定着したのですが、メンバーとのコミュニケーションは普段の接点を多く持つことに重きを置いています。 1on1でしか得られない高揚はもちろんあるのですが、1on1で改まって話をするより、普段の業務中に会話をしたほうが圧倒的に鮮度・頻度が増えるため、プラスになることが多いです。結果、1on1の頻度としては多いメンバーで隔週、大半のメンバーはQ単位で1回程度と一般的な1on1の頻度よりはかなり少ない形で運用しています。 リモート業務中心となり、偶発的な会話の機会が減ってしまったこともあり、業務上のコミュニケーションはSlack中心、雑談等はMTGの間のGoogle Meetでの通話等で行うことが増え、より普段の接点自体に意識を向けるようになりました。 自身もバリューを発揮する 上記のようなコミュニケーションをメンバーと取る上で重要なのは、自分が業務やエンジニアリングにおける示唆をするに値する人間であることをメンバーに知ってもらうことです。 もちろん、色々やり方はあるとは思うのですが、私自身は「背中で語る」が最も手っ取り早く効果も高いと思っています。 といっても、すべての領域で無双するような必要はなく、自身の強みをベースにチームメンバーとの関係構築を行っていくことで、エンジニアならではのスキルからくる信頼関係が構築されていきます。 テックリード編 自身の技術力 私自身、技術面に関してはそこまで尖っているわけではありません。元々、マネジメントにキャリアを歩むきっかけとしても、技術を極めていく自分が想像できなかった面もあったりします。 ただ、実際にマネジメントをやってきた結果、やはり技術力は必要だなと認識する場面は多々あります。 結果、自分としては「自チームにおいて、最も技術力が高い人と同じレベルで会話ができる」をモットーに技術面のキャッチアップを行うようにしています。 これが満たせない場合、チームでの技術的な意思決定に自分が関われず、それがビジネスに本当に必要なものなのか？の判断を間違える可能性があるからです。 メンバーの興味関心に合わせる 見る範囲が広い為、自分だけで技術面のチャレンジを行ったところで、チームには浸透しません。そのため、メンバーが今どういう部分に興味関心を持っているか、業務上どういう課題を持っているか等、メンバー個々が動機づきやすいような内容を中心に開発改善を進めることが多いです。 こういった流れ自体が定着していくことで、新たな提案にも前向きに取り組めるチーム文化ができていると感じます。チームに感謝！ プロダクトマネジメント編 事業を広い視点から理解する 事業に貢献するために、事業理解の中でも「色々な視点」から事業を見ることを意識しています。 それぞれの深い部分は各担当の人に勝てないので、実際に事業面で把握するようにしているのは以下のような情報です。 大枠の事業戦略 各担当が日々追いかけているKPIとその相関 サービスを利用するペルソナ 隣のチームのHOTな話題 これらの情報をインプットとして、「事業の色々+エンジニアリング」を理解したユニークな人になるようにしています。 こうして、事業での意思決定の場で自分ならではのバリューを出すようにしています。 問題解決を進める 業務を進める上で、開発に限らず日々たくさんの問題が発生します。 私自身、どんな問題があっても必ず前に進めるというのを意識しており、これを体現していくことで周りからの信頼も勝ち取れ、更に自分に情報が集まりやすくなる好循環が生まれます。 ここで前に進めると表現したのは、必ずしも自分で解決する必要はないからです。重要なのは「大野に聞けば何かしら前に進む」と思ってもらうことなので、自分で解決してもよいですし、解決に適任な人に繋ぐこと自体にバリューがあります。 今は、メンバーにどんどん裁量を渡しているので、大野ではなくメンバーに真っ先に相談・質問が来るように関係構築を進めるよう推進しています。 また同時に、メンバーにとって困難な問題が発生した際はいつでもヘルプできるような距離感は保ちつつ、自身は比較的難易度の高い問題の解決に時間を充てられるようにしています。 おわりに 今回は、広い範囲の組織をみる上で、自分なりに行っている仕事術のような形で色々と書かせていただきました。 こういった言語化や、この記事から生まれる会話でよりEMとしても、組織としても成長していければと思います。

技術組織のマネジメント @sunaot です。エス・エム・エスで技術組織のマネージャーをしています。入社時点から技術組織全体のマネジメントを担う役割でスタートし、今年で７年が過ぎました。 「エンジニアリングマネージャー (以下、EM) の仕事とはなんですか？」と聞かれたときにその定義を答えられるでしょうか？ 「1on1をすること」「メンバーの育成をすること」など、これは EM の仕事だという要素は挙げられても、全体像を言える人は中々いないのではないかと思います。そうしたときに頼りになるのは書籍ですが、EM に特化して仕事の全体像を語った書籍というのは日本語ではなかなかありませんでした *1 。 EM の仕事単体でその全体像を説明するのが難しいのにはそれなりの理由があります。この記事では、全体像を語りにくい EM の仕事というものについて、技術組織のマネジメントという視点から全体を説明し、その中で EM の果たす役割を定義するという流れで説明をしてみたいと思います。 対象となる読者の人は、 ある程度 EM としての経験があり、これからどのようによりよい EM となっていけばいいか悩んでいる人 現在 EM をしていて、より広い範囲の役割で仕事をすることが求められそうな人 です。自分で自分の仕事をつくっていく必要が出てきた人の考える土台になることを狙って書いています。 一方で、あまり対象ではないであろう人は、 これから初めての EM をするという人 です。経験をしていない人にとっては、もう少し具体的にどういう活動をすればいいのかというのをステップ・バイ・ステップで解説してくれるようなもののほうが合っていると思います *2 。 技術組織のマネジメントの要素とレイヤー それでは、技術組織のマネジメントから説明をしていきます。最初に、技術組織のマネジメントと EM の仕事の区別を説明します。 技術組織のマネジメントは、会社の技術組織全体の成功へ責任を持ち、成功のために必要な活動を設計し、実行をすることです。スコープとして技術組織という組織を対象にしています。一方、EM の仕事はスコープとしてチームを対象としています。人数としては多くて8名、最大でも15名くらいをイメージしています。 技術組織という組織が成功するためには、次のような要素が必要になります。 実現したいことと目標 体制とアプローチ アライメントと実行 組織構造 情報流通 コラボレーション 価値観と文化、モラル さらに、技術組織のマネジメントのレイヤーとしては次の3つがあります。 個人 チーム 組織 組織が、技術組織のマネジメントの要素を満たして成功をするために、各レイヤーのそれぞれで必要な活動をしていくのが、技術組織の経営です。 ここからは、それぞれの要素やレイヤーについて説明をしていきます。 技術組織のマネジメントの７要素 実現したいことと目標 これは文字通りの意味ですが、マネジメントの根幹になります。他のすべての要素のゴールでもあり、制約でもあります。その組織にとって成功とは成果とはというものを定義します。表現形式としてミッション・ビジョンや短期的にOKRのような形態をとります。 会社組織であれば、上位概念になる組織から求められることもありますし、一方でそれを鵜呑みにしないことも組織の価値になります （鵜呑みにするならサブセットになって組織固有の価値が低いため）。あとは、周辺の他の組織から求められる要求というのもあります。より広い役割の場合は社会や市場、競合他社という視点から考えることもあるでしょう。 いずれにせよ、その組織固有の価値とはなにかを考え続け、状況の変化に合わせた更新を加え続けていく仕事になります。 体制とアプローチ 実現したいことと目標、それに向けて得たい成果からスタートします。そこへ向けて必要な体制やアプローチというのは多くの選択肢の中からマネージャーと組織の能力のキャパシティの中で変わってきます。これがマネージャーを優秀な人に担ってもらうべき理由でもあります。 現在の組織能力と実現性というのは制約になりますが、基本的にはあくまで成果からの逆算で考えます。 無限の選択肢と組織能力を持っているのであれば、最善の解を選べばいいわけですが、通常マネージャーが置かれている状況はそうではありません。制約条件があり、ビジネスや開発/技術におけるセオリーがあり、その中で数少ない成功の可能性のある選択肢を選ぶ必要があります。 ビジネスや開発/技術の状況・コンテキストをどう読むのか。組織の能力や体力、マネージャー自身の得意不得意も加味して、どの選択肢に勝算を求めるのか。これはマネージャーの仕事の思考の自由度における最大の楽しみになります。 先行するのはアプローチであり、それを実現するために必要な体制を整えていくというのが基本です。体制は、採用と育成、組織づくりが支えているので実際はこれだけで一大トピックになります。 アライメントと実行 アプローチと体制から進むべき道が決まったら、今度はそれを組織的に実現していく必要があります。ここまでの内容は主に戦略と呼ばれますが、実現されない戦略は絵に描いた餅です。戦略が優れていたと評価されるためにはここから先の実現の過程が重要になります。実現の過程は地味ですが、現実の仕事で重要なのは実現とそれを支える実行です。このパートが組織が動くかの肝だと言ってもいいでしょう。ここから、それぞれについて説明します。 アライメント ここで言うアライメントは組織におけるアライメント (organizational alignment) です。実現したいことと目標に対して、組織の一人ひとりが同じゴールへ向かうように理解と意思と行動の方向をそろえ続ける活動です。アライメントという活動があるというよりは、様々な活動を通じてアライメントのとれた状態を実現していきます。たとえば、組織での方針説明会のようなものは活動の一例ですし、インセプションデッキのような活動もアライメントのための活動の一種になります。いわば、組織の照準を合わせる活動です。 実行 実行は、アライメントでそろった方向に対して進めていく過程です。現実には様々な理由で目指した方向に対して歩みを止める力が働きます。実行の過程は、個人や人と人の間に生まれる歩みを止める障害を取り除き、素早く目的地までたどり着くための活動です。戦略や方針が間違っている以前に実行をできずに物事が進まず停滞する組織というのが多く、マネージャーが新しい組織へいった場合に最初にテコ入れするのが実行の文化をつくることであるケースは多いです (一般に実現したいことやアプローチを見直すことは時間がかかるが、実行の文化をつくることは短期で成果を出しやすいため)。 実行の過程についてはマネージャーによって得意なやり方が分かれるところですが、共通する基本的な形式としては「現状把握」と「進行 (進めること)」と「進路補正 (問題の解消)」で成り立っています。たとえば、 『HIGH OUTPUT MANAGEMENT』 ではインディケーターや1on1 *3 によって現状把握をして、教育 (訓練) とモチベーションの向上やナッジングによって進行や進路補正をする手法が解説されています。実行とは、論理的には成り立っている方針に対して、実現をする過程で現れる現実とのギャップを解消しながら前へ進めていく活動です。 組織構造 組織構造は、他のマネジメント要素に対しての枠組みになります。組織の成功に向けて適した構造をとるといった形で導出されるものです。導出されるものでありながら、一度決めた枠組みは制約として働くので、継続的に狙いにあった形に変化させていく必要があります。組織上密結合にするほど、同じ目標を見ることの容易さが上がったり、日常の中での情報流通の量が増えるなどの効果が出やすいです。ただ、組織の構造によらず、狙って特定の要素を強化することは可能なので、もっとも優先したいことへ寄せて組織構造を設計して、課題が出る部分にサポートをしていったりします。特定の優れた組織構造を目指すよりも、その組織構造で過ごす中での組織のコンディションへの影響を追いかけて、主要なテーマが変わってきたら構造を見直すことが重要です。 情報流通 組織の構造ができあがったら、その中で働く人たちが仕事を主体的に進められるように必要な情報を手に入れられる状態をつくる必要があります。プッシュであれプルであれ、どこでどのような情報が手に入れられるのかという土台になる場を設計して、その場の提供をします。場は会議や定期的なイベントという実装をとることもありますし、イシューやチケット、ドキュメントのような実装をとることもあります。土台で埋まらない部分の情報について、ハブとして日常的に埋めていく活動をしたり、他の人が埋める手伝いをします。とくに組織と組織の間で情報流通が途切れることが多いので、必要な情報が相互にやりとりされるように場の設計をします。 コラボレーション コラボレーションは実行の過程で組織やチーム、個人のレベルでの相互の関係が機能するようにしていく動的な活動です。チームのレベルではチームビルディングによってコラボレーションの質と量を上げたり、個人と個人の間では協力して物事を進めるための考え方や行動に働きかけたりします。直接的にコラボレーションの機会や場をつくることもありますし、コラボレーションが活発になるような環境づくりをすることもあります。 価値観と文化、モラル 価値観や文化といったものは、会社の単位で設定されていることも多いと思います。当然それを一つの前提とするわけですが、ただ技術組織固有の価値観や文化があることが多いのと組織の状況やフェーズによって今テーマとして取り組むべきものというのが移り変わるので、意識的に扱ったほうがよいと思います。実現していくための活動としては、採用や育成、評価といったものもあれば、直接的な価値観や文化浸透のための施策、日常の一つ一つの振舞いや行動習慣に至るまであらゆるポイントで「どのような組織でありたいか」を表現していくことになります。仮に他の目的で行う組織の施策だとしても、その思考様式や表現方法は価値観や文化の表明を含むものになるため、いろいろな場面で意識をする必要があります。 技術組織のマネジメントの３レイヤー 個人 スタートは個人のレイヤーです。そもそも個人は組織のために居るわけではないので、個人が個人としてパフォーマンスを発揮できるように支援をしていくというのが一つの役割です。そして、個人は組織のために居るわけではない一方で、技術組織のマネジメントの仕事は組織の成功を実現することです。個人のレイヤーではこの個人の働きを組織の成果へつなげるための働きかけをしていきます。技術組織のマネジメントの７要素が個人のレイヤーではどのように評価できるのかを考え、個人への後押しをしたりコーチをしたりフィードバックをしたりします。 現実に個人に向き合っているときには、必ずしも組織の成果のことだけを考えるわけではありません。というよりも、目の前のマネージャーが組織の立場からしか会話をしてくれないのであれば信頼関係は築けません。個人としてのその人の立場を尊重して考えることへ100%の意識を使いながら、同時にチームや組織の視点も提供できるのがマネージャーの付加価値になります。 チーム チームは現代のサービス開発の基本単位です。そのため、技術組織のマネジメントの７要素はどれもチームのレイヤーで機能をしている必要がありますし、考えるときにもチームを主体として考えたときにどのようにそれぞれの要素を機能させるかという視点で考えることが多いです。また、一見すると個人のものに見える課題を解決するときにも、あえて「チームのレイヤーでその課題を解決するとしたら」という視点の置換をすることも多いです。個人に課題が出ているときは、その一つ上のチームのレイヤーでなにかの課題を抱えている結果であることが多いからです。 組織 組織のレイヤーで考える場合も、基本はチームを中心に考えます。物事が成し遂げられる基本単位がチームだからです。一方、チームはそれぞれに状況や成熟度合いが違います。複数のチームに対して一定の土台となる仕組みや質、成熟度合いをつくっていくには組織というレイヤーでのサポートが必要になります。チームが気持ちよく働き成果を出すことへ集中できるようにするには組織がどうあればよいかを考えていくのが組織のレイヤーです。 ここまでで、技術組織のマネジメントに必要な７つの要素と３つのレイヤーについて説明をしてきました。次回は、この要素とレイヤーに対してエンジニアリングマネージャーはどういった仕事を担っているのかを説明します。 *1 : 『エンジニアリングマネージャーのしごと』 という翻訳書が8月に出版されました。 *2 : この点、『エンジニアリングマネージャーのしごと』は期待に応えてくれる場合が多そうです。 *3 : 書籍では「ワン・オン・ワン」として紹介されています。

はじめに はじめまして。エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」の開発をしている古川です。今回はエス・エム・エス内で行っていた『プロダクト・レッド・オーガニゼーション』読書会の取り組みを紹介します。 エス・エム・エスでの読書会 エス・エム・エスでは読書会が数多く行われています。チーム内で実施しているものもあれば、チームを跨いだ有志での会もあります。カイポケの開発チームは現在リモート中心で業務を行っているので、読書会もリモートで行っています。本記事でご紹介する読書会もリモートワークが主体になってから生まれた読書会です。 『プロダクト・レッド・オーガニゼーション』とは 読書会の話に入る前に、『プロダクト・レッド・オーガニゼーション』（以下、本書）について簡単に内容を紹介します。 pub.jmam.co.jp 本書はPendoの共同創業者兼CEOであるトッド・オルソン氏の著書で、原著は2020年、日本語の翻訳書は2021年10月に発売されました。本書ではプロダクトを通して顧客の獲得と維持、拡大を行う組織をプロダクト主導型組織と呼び、そのような組織がどのようにプロダクトからデータを収集し、意思決定を行っているかについて解説をしています。 私の所属するカイポケの開発チーム内で、ロードマップの作成や優先順位づけにあたって、利用データをこれまで以上に重視しようという意識が高まっていたこともあり、この書籍に興味を持ちました。 『プロダクト・レッド・オーガニゼーション』を読書会で読むことになった経緯 本記事でご紹介する読書会は、2021年4月頃から現在の形式で活動をしています。エンジニアだけでなく、プロダクトマネージャーなども参加して一緒に本を読んでいるのが特徴です。 読書会で読む本はそれぞれが候補をいくつか挙げ、最終的には参加者全員の話し合いによって決めています。明確な選定基準はないのですが、技術一辺倒の本よりも、エンジニアとプロダクトマネージャーがそれぞれの立場で読むことができ、みんなで色んな話をするきっかけになるような本を選んでいます。 そのような経緯で、これまでにこの読書会で読んできた本は以下のとおりです。 『プロダクトマネジメント』 『エリック・エヴァンスのドメイン駆動設計』 （一部） 『プロダクト・レッド・オーガニゼーション』 『プロダクトリサーチ・ルールズ』 （現在読書中） プロダクト系の読書会と銘打っているわけではないのですが、並べてみるとプロダクトに関する書籍が多いことに気づきます。 読書会の進め方 Slack上で通話をしながら行っています。進め方は以下の通りで、これを1時間ひたすら繰り返します。 読む範囲（数ページ程度）を決める それぞれが黙々と読む 読んでいる間に生まれた疑問点や感想をesaに書き出す それぞれが読み終わったところで、出てきた疑問点や感想について議論する すべて話したら次の読む範囲を決める 実際に行われた議論の例 以上のような進め方で本書を読んでいる中で、実際に行われた議論の例を紹介します。 『プロダクト・レッド・オーガニゼーション』は、さまざまな視点から幅広いプロセスについて、非常に具体的に記述しているため、「自分たちのプロダクトで考えるとどうなるだろう？」という問いが生まれやすかったです。 例えば無料トライアルの効果的な事例として、ガイド付きのセルフサービス体験が紹介されています。トライアルの中でプロダクトの価値を最大限に感じてもらうため、そこに至る準備や設定を省略し、架空のテストデータとウォークスルーのプログラムを用意することで、より短い時間で効果を感じてもらえるようになったという事例が紹介されていました。 この事例紹介を読んだあと、自分たちのプロダクトであるカイポケのトライアルについての議論が生まれました。介護サービスの提供は1ヶ月単位で行われます。そのため給付管理業務がカイポケでどこまで効率的になるのかを実感していただくためには、最低でも1ヶ月という期間が必要になります。カイポケではこの1ヶ月単位で行われる業務が円滑に行えるように設計をしています。 しかし、前述のウォークスルーの例を読んで、カイポケ内で有効性を十分に伝えられていないのではないかという疑問が生まれました。そこで、カイポケであればどのようなウォークスルーが考えられるかについて議論しました。 1ヶ月の流れを掴めるようなウォークスルーはどのようなものが考えられるのか。 そのために準備しておくデータは何か。 使い始めのユーザーがつまずきやすいポイントはどこなのか。 これらを実現するためにはどのような環境が必要か。 現状の仕組みで実現するためにはどのような設計が考えられるか。 このような論点に加えて、実際の利用状況のデータ等も参照しながら、エンジニアとプロダクトマネージャーが立場を跨いで議論することができました。 読書会を終えての感想 読書会を通じて、本書で出てくるアイデアを自分たちのプロダクトだったらどのように適用できるだろうかと考える機会が度々ありました。 また、データ分析やメトリクスに基づく意思決定の重要性が繰り返し説明されていたことも印象に残りました。業務の中でもメトリクスの整備や振り返りを進めていたところだったので背中を押してもらえたような気がします。 以下では、私の感想だけでなく、読書会の他の参加者の感想も紹介します。 プロダクトマネージャーの感想 「正しいもの」を作るためにデータを活用すること、プロダクトチームとカスタマーサクセスチームの連携、価値の無い機能は捨てるなど、全体的に取り組み始めたことや今後やりたいと思っていることに関連した内容が多く刺さる本だった。 顧客の獲得からプロダクトの改善、戦略の立案からプロダクトオプスの部分まで幅広い観点で書かれていたので、今後のガイド的に使っていけると思った。 エンジニアの感想 顧客満足度やNPSといったよく目にする指標について、それを利用する文脈・目的を含めて説明されていて、役に立った。 プロダクトを改善していくための仕組みをプロダクト自体に色々と組み込んでいくのがよいという話が多々あり、そのようなことを行おうとしていくと、システム開発の仕方にも変化が出てくるのではないかと感じた。 終わりに 現在読書会では『プロダクトリサーチ・ルールズ』を読んでいます。読書会のesaやSlackから興味を持ってもらい、新しいメンバーも加わりました。単純に参加者が増えただけでなく、カイポケではないプロダクトを担当してるエンジニアや別チームのプロダクトマネージャーが参加してくれるようになりました。 このような読書会だけでなく、エス・エム・エスでは普段からプロダクトマネージャーとエンジニアが近い距離で働いています。役割によって壁を作ることなく、共に取り組みながらより良いプロダクトを提供できるよう努力していきます。

医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会に適した情報インフラを構築している株式会社エス・エム・エスのAnalytics&Innovation推進部（ 以下、A&I推進部）でデータ分析基盤開発を担当している長谷川です。 A&I推進部はエス・エム・エス社内のデータを横断的に収集し、データの分析や加工から、データに基づく施策までを行う部門で、現在は介護事業者向け経営支援サービスである「カイポケ」や、介護職向け求人情報サービスである「カイゴジョブ」のデータ分析やレコメンドシステムの開発を行っています。 エス・エム・エスは多くのサービスでAWSを採用しており、A&I推進部においてもAWSのマネージドな機能を活用してデータ分析やサービス開発を行っています。 A&I推進部とは エス・エム・エスは主に医療・介護領域を事業のドメインとしていますが、それらのうち特に介護領域は労働集約型の事業が多く、産業データ活用があまり進んでいないのが現状です。 ここ数年で介護給付費は10兆円を超え、国家予算のおよそ1/10を占めるほどにまで膨らんでいますが、日本の少子高齢化は今後も進んでゆく可能性が非常に高く、 2065年には65歳以上の高齢者が全人口の4割近くになるとも予想されています。 高齢化に伴い医療や介護の需要が増大する一方で、生産年齢人口の減少により、これらのサービスを支える医療・介護従事者の不足が深刻な課題となっています。これにより、今後質の高い医療・介護サービスの提供が難しくなると予想されます。 エス・エム・エスは、解決すべき重要な社会課題の1つとして「質の高い医療・介護サービスの提供が困難になる」という問題を捉えており、A&I推進部はその中でデータ分析を利用した介護領域への貢献を推し進めるために立ち上げられた事業部です。 横断データ分析するための環境づくり エス・エム・エスには介護・医療領域の従業者と事業所とのマッチングを業務領域とするキャリア事業部や、SaaS型の「カイポケ」など、介護・医療領域のデータが多く蓄積されていますが、個々のサービスごとにデータが分断されており、蓄積されたデータが最大限に活用されているとは言い難い状態でした。 A&I推進部はエス・エム・エスでのデータ活用を押し進めるべく、各サービスのデータを横断的に収集、安全にアクセスできる仕組みと、個人情報を匿名化したうえで配布できるデータ分析環境をAWS上に構築しました。 この仕組みはA&Iが主としてデータ分析を行いつつ、エス・エム・エスの社員が希望すれば分析環境にアクセスできる仕組みも同時に提供してきましたが、なかなか活用が進みませんでした。 「データの民主化」の誤解 データ活用が進まなかった理由として、「データ民主化」という言葉への誤解があったと思います。 我々は「事業横断でデータを集めて一元管理すること」ができ「希望すれば誰もが分析環境にアクセスできる仕組み」を提供できれば、データエンジニアやアナリスト以外の社員が自主的にデータにアクセスして分析するようになると考え、それを称して「データの民主化」と捉えていました。 しかしながらこれは完全に誤った解釈で、データの管理や環境を用意するのはあくまで手段であり、本来は「誰もが容易に集めたデータにアクセスし、分析や意思決定を行える文化を醸成すること」だったのですが、この視点が完全に抜け漏れていたのです。 データ活用が捗らなかった理由 私はエス・エム・エスに入社するまではWEBエンジニアとしてビッグデータソリューションの開発・運用に携わってきました。 そのためマーケターやアナリスト業務について深い理解を持っておらず、逆にSQLやビッグデータ基盤などの知識・経験を有していました。これが誤解を生む要因の一つでした。 SQLはWEBエンジニアのほぼ共通言語のようなものなので、欲しいデータの入ってるテーブルをいくつかJOINしてデータを集計することが当たり前でしたが、開発以外の業務ではSQLを使わないことのほうが多く、SQLクライアントに接続することの障壁が高く、さらにそのうえでSQLを書くということはかなり難しいことでした。 例えば毎日所定のフォルダにバッチ処理でDBのデータを集計したデイリーサマリを出力しているとします。 このサマリを時間別に集計したいとなった場合、バッチ処理で利用しているテーブルを特定し、集計軸を変えて正しく動くクエリを書く、ということを１からやれと言われたらエンジニアでも難しいですが、それをマーケターやアナリストが自分でやるというのはかなり難易度が高い業務になります。 また、分析そのものの難しさもデータ活用が進まなかった理由です。 分析を依頼する場合、依頼元も何をどう可視化したいのか、どこのデータを使えばやりたい分析ができるのかがわからないことのほうが大半で「時系列でマーケットシェアを出したいんです」のような依頼が来た場合、直近12か月に絞ったシェア率なのか、月次・週次は平均値なのか、その場合は移動平均なのか、などのイメージを予め固めたうえでないと可視化することは難しいです。 しかしながら、大抵の場合は「おそらくこういったデータがあれば何かが見えてくるはず」という主観的なイメージが起点となるので、手さぐり状態で可視化や分析を始め、「データを探す→抽出する→分析して可視化する」を繰り返す必要があり、A&Iの分析環境ではこのサイクルを繰り返すことに非常に多くのコストがかかっていました。 課題解決に向けて 課題が見えてきたので、分析したいことはあるが解像度を上げることが難しい事業側に対し、より高速にデータを可視化し、そのうえでそのうえで多種多様な軸で分析を繰り返すにはどうすればよいかを考えました。 A&I推進部はDWHにRedshiftを採用しているのですが、これまではRedshiftで集計したデータを一度S3に出力し、S3から各事業部のBIツールごとに異なる出力先へ出力、必要に応じてTableauなどのダッシュボード更新を手動で行っていました。 これでは最新のデータに更新するにも手動で再取り込みが必要ですし、BIツールのビジュアル更新にも時間がかかり、最新の状態でKPIを見直すことができません。 そこで、各事業部で利用しているBIツールについてはCSVデータを提供するに留め、新しい分析依頼については可視化をすべてQuickSightに集約することに方針を変更しました。 QuickSightはAWS上のマネージドサービス（S3、Athena、Redshift、RDSなど）をデータソースとしてWEBブラウザベースで可視化できるBIツールで、他のBIツールに比べても閲覧者が最大$5/月、作成者も$24/月（年間契約なら$18/月）という リーズナブルなコストで利用できるBIツール です。 QuickSightはデータソースという単位で可視化するデータを管理しており、 ほとんどのAWSのマネージドなリレーショナルデータベースに接続可能 です。 A&I推進部では事業データを集計してサマリデータを作る部分を共通バッチ化しているため、Redshiftには加工されたサマリデータの最新版が常に格納されており、QuickSightから最新のサマリデータに直接接続できるため、この仕組みを使えば可視化におけるアウトプット速度を最大化できることがわかりました。 しかしながらプロダクトとして採用するためには、A&I分析環境のルールに沿ったセキュリティ要件をクリアする必要がありました。 A&Iの分析環境はセキュリティの観点から特定のIPからのみ接続を許可しており、一般ユーザーにはAWSコンソールも開放していません。一方でQuickSightはグローバルなサービスのためAWSコンソールからログインする必要があり、アクセス元IPによる接続制限をかけることができませんでした。 これを解決するためにまずAWS SSOによるIP認証を試みたのですが、AWS SSOを通すと接続元IPがAWSのIPとなってしまい、正しい接続元IPを取得することができずこの方法も利用できませんでした。 そこでフロントにIP制限を設けたKeycloakを配置し、認証をkeycloak経由とすることで接続元IPに絞ったうえでQuickSightにアクセスする手法を採用しました。 QuickSight導入により、Redshift上の最新のデータソースに即座にアクセスしブラウザで最新のKPIを確認出来るようになりました。 またダッシュボードを見ながら「この軸を深掘りしたい」「別の軸で集計したい」という希望に対してその場で更新しその結果を共有できるようになり、一番の課題であった「多様な軸をすぐに可視化して分析」することができるようになりました。 QuickSight導入後 QuickSight導入後、可視化案件の質が大きく向上しました。 例えばコールセンターの可視化案件では、これまではダッシュボード更新の煩雑さからダッシュボードの元データをExcelで直接集計し、ダッシュボード更新が行われない問題がありましたが、今ではQuickSight上で日々のKPIを追うようになっています。 またQuickSightはSPICEというインメモリDBを利用しているためデータ集計速度が向上し、Excel集計では限界だったデータの可視化なども可能になりました。 すべてがAWSのマネージドな環境に収まった結果、今まではデータエンジニアがデータ集計し、データアナリストが可視化を行うというように、暗黙的に業務が分担されていましたが、データエンジニアがデータ集計からボード作成まで行うようになり、メンバーの業務スキルの幅が広がるという、当初想定していなかった良いフィードバックも生まれました。 昨年9月に本格導入した後、これまでに60以上の可視化を行い、うち40以上のダッシュボードが今でも活用されています。 今後の課題 QuickSight導入により分析・可視化の速度を格段に改善でき、A&I事業部と事業担当者双方が、データの解像度を揃えながら分析を繰り返すことができるようになったことは「データ民主化」の大きな一歩だといえます。 ただしこれらのダッシュボード作成はデータエンジニア、データアナリストが行うことがまだまだ多く、本来のデータ民主化である「社員誰もが独自に分析を行い、意思決定できる文化の醸成」まで及んでいません。 しかしながら今回QuickSightを導入したことで「便利そうだからやってみたい」という土壌ができ、このムードを維持しながらデータ分析に参加してもらうことが今後の課題と考えています。 また技術的には、QuickSightには異常検知や未来予測などのインサイト機能であったり、SageMakerで作成した独自モデルと統合できるなどML機能が豊富に備わっていますが、これらの機能についても十分に活用できていないため、ゆくゆくはAI機能を活用したダッシュボード開発も進めていきたいと思います。

エス・エム・エス テックブログ運営の小林と樽本です。今回の記事は 技術推進グループ長に聞いてみた・前編 「全社横断の技術アドバイザー」 の後編となります。 光宗朋宏 Tomohiro Mitsumune -技術推進グループ グループ長 Ex. DeNA 面接においてどういうことを意識されているのでしょうか？ 四つ目の質問です。光宗さんはエンジニアの方の技術面接を担当されることが多いと思いますが、面接の際にどんなことを意識しているのか教えてください。 自分も面接時に、光宗さんに技術面接を担当いただいたのですが、今までの仕事について突っ込んで聞かれた覚えがあります...(笑)。 もちろん先方の経歴は事前に拝見しているのですが、「話を組み立てる能力」は特に重視しており、そこをチェックできるような面接を心がけています。 具体的には、ご自身の経歴を自由作文形式で喋っていただくようにしています。 僕がいっぱい喋ってしまうとなんだか誘導尋問のようになってしまうので、例えば「今までキャリアの中で一番大変だった仕事はなんですか？」と投げかけてみて、聞かれたことに対してどうやって話を組み立てていくのかな？という点を見ています。 エンジニアって「難しい課題に対してロジックを組んで解決するスキル」と同じくらい「組み立てたロジックを他人に説明するスキル」が大事だと僕は思っています。 なので、自分は面接中になるべく喋らないことを目標にしたりして、その辺りのスキルを見るようにしていますね。 となると、光宗さんが面接でいっぱい喋ってしまう時は候補者さんがうまく話を組み立てられなかったりで、お見送りとなってしまうパターンが多いのでしょうか？ エンジニア3〜4年目のいわゆるポテンシャル枠の方に対しては、話している中でヒントを出したりすることもありますが、エンジニア15年目のベテランの方にはそれ相応の期待値があるので、そういったヒントを出すことはあまりしないですね。なので、僕がいっぱい喋ったことがお見送りの基準になるかどうかは、先方に対する期待値によって変わってきますね。 なるほど、こちらの問いかけに対するアウトプットの質でレベル感だったりを測っているのですね。 はい。これまでの面接官の経験として、一時間という時間の中で相手のことをより深く知るには「相手に多く喋ってもらう」方針は間違っていないと思っています。 面接時に意識していることとしては、「相手に多く喋ってもらうこと」ということになるんですね。 エンジニアとしてステップアップしてきた方法は？ 最後の質問です。ベタですが、今までエンジニアとして働かれてきた中で、どうやって様々な壁や修羅場を乗り越えてステップアップしてきたのかというところをお聞きしたいです。 どうやってステップアップして来たかと言われると、自分で狙ってキャリアを築いてきたわけではないので偶然なところがあります。 過去に3回転職してきた中では、結局今まで自分がやってきたことの延長戦だと面白くないので「自分の手に負えないことをやりたい」とか、「明らかにレベルの高そうなところに行きたい」「ハードルがあるところに行きたい」などのマインドを持つようにしていました。そうすると壁というかチャレンジみたいなことが自然といっぱい出てくるので、それをその時々で乗り越えられるように努力してきましたね。 転職歴的なところでいうと、一社目がメーカー系で二社目が大手toCのWeb企業でした。その時の社内の風潮として、新規事業を立てたり別の会社を子会社化したりするものがありまして、その流れで新規事業として立ち上げるWebサイトの開発を希望して入ったんですね。 チームにはエンジニアが僕一人、デザイナーが一人、そしてPMとして起案者が一人いまして、起案者のやりたいこと、実現したいことをヒアリングした上で当時の競合サービスを片っ端から調べました。 人気だった他社サービスのデザインをベースにしようということになり、デザイン面はデザイナーと協力して考え、それ以外のサービスの立ち上げからは僕一人でやっていました。サーバーの知識は大学〜大学院時代に研究室のLinuxサーバーの管理者を好きでやっていたり、当時は自宅サーバーが流行っていた時代でその流行に乗っかっていたりしたので、わりかしそこら辺は得意だったので進められました。 その時エンジニア1人でやり遂げられたのは、自分が持っていた趣味嗜好と仕事がたまたまフィットしてうまくいっただけなので、狙ってやったかと言われると全く狙っていなかったです。 「手に負えないことをやりたい」と思って進んでみたら、良い方に進んだようです。なのでステップアップというか、自分を成長させるためにあえて「手に負えない」現場や環境に飛び込んできたと思います。 かなりストイックですね...。自分のできること/できないことの線引きをした上で、できないことをできるようになりたいという姿勢ですよね。 できるようになりたい、はちょっとかっこよく言い過ぎですね(笑)。 単に飽き性なんだと思います。同じことをやり続けると飽きるだけです。 大体何年くらいで飽きが来るのですか？ 大体3-5年ですね。一般的なエンジニアの転職サイクルと一緒です。 なるほど...(笑)。 新規事業立ち上げのWebサイト開発を希望し入社され、そこからどのようなキャリアを進んで行ったのでしょうか？ 新規事業のサービスは無事にローンチされて、社内の評判もよかったです。社内的な知名度と評価はこれがきっかけで生まれたんじゃないかなと思います。 ローンチ後の二年半くらいはそのサービスの開発と運用を諸々、サーバー監視以外は基本一人でやっていました。 その二年くらいの実績を評価してくれる人から、子会社の開発部長やらない？みたいな話をいただいて、二年以上やっていて流石にやることがなくなってきていたので、引き継ぎ資料を作って子会社に開発部長として移籍しました。 その時が初めてのマネージャー職だったのでしょうか？ そうですね、初めてです。 なるほど。初めてマネージャーをご経験される中で、多くのエンジニアが悩みがちな満足のいくエンジニアリングとマネジメントの両立はできていたのでしょうか？ できていたと思います。一応部長として、営業だったりデザインだったりの他部署の偉い人が集まる会議に出ていたんですが、そこで僕が喋ることは「こういうことやりたいです」でした。 結局マネジメント役でそういう場所に出ると、ある程度の裁量があるのでやりたいことを自分で決められるんですね。もちろんやりたくないこともあるんですが。 自分のやりたいことができるような流れを作っていたので、満足にエンジニアリングができていました。 ただ、忙しいっちゃ忙しかったですね...。 確かにお話を聞いているとエンジニアの数が足りていなさそうな感じはしていました。 マネジメントするエンジニアの数は4-5人と多くなかったので、マネジメントで忙しい訳ではなかったです。 タイミングとか巡り合わせもあると思うのですが、元々マネジメント志向はあったのでしょうか？ 1ミリもなかったです。 ただ、その会社で働いていくうちに「この会社ではマネジメントスキルがないと、給料も上がらないしやりたいことができないな」ということはわかってきていたので、マネジメントをやりたいかやりたくないかは置いておいて、やった方が得になるなと考えました。 長い目で見ても、コードも書けてマネジメントもできる方が人として強いんじゃないかと考えてました。実際楽しくないしあまりやりたくはなかったですが、やっておいた方がいいと思ってやってましたね。 なるほど...。お話を聞く限りエンジニアリングとマネジメントの両立もできていたように思えるのですが、そのままそのマネージャ職を続けるという選択はしなかったんですか？ その会社に5年いたんですけど、開発部長としてマネジメントをやるのに飽きたので転職したのが前職の大手ソーシャルゲーム企業なんです。 飽きるっていうと言葉が悪いですが、向こう3、5年同じ環境に居続けた場合と、違う環境に移動した場合で伸び幅がどれだけ違うかとか、モチベーションを保てるのか、とかが大きな理由ですね。 あとは当時の大手ソーシャルゲーム企業は、どこも有名他社と採用合戦をやり合ってて、できるエンジニアはそこら辺のどこかに行くみたいなのが風潮としてあったんですよ。なので、できるエンジニアに囲まれることで自分のレベルがどのくらいなのか客観的にわかるかな、と期待していたのも大きいですね。 やっぱりお話を聞いているとストイックなところが垣間見えるのですが、そんなことないんですかね...。 うーん、自分の実力って他人に評価してもらわないとわからない部分もあるじゃないですか。そして、同じ環境に居続けると、「どう立ち振る舞えば高い評価を得られるのか」がわかってきてしまいますし、それは評価を受ける上でフェアじゃないと思っています。それがストイックなのかはわかりません(笑)。 感覚的には、お金を稼いでる会社がネームバリューある人をいっぱい採用する環境ってメジャーリーグっぽくて、そういう憧れみたいなのもありました。 大手ソーシャルゲーム企業の時に田辺さんと一緒にお仕事されてたんでしたっけ？ そうです。3年半ぐらいいて、最初の一年ぐらい田辺さんと同じチームで働いてて、仕事内容としてはエス・エム・エスにおける技術推進グループみたいなところで、僕と田辺さんは横串で開発効率改善のようなことをしていました。 前職から既に横断的にご活躍されてきたんですね。エス・エム・エスに入ってこられたのは田辺さんがエス・エム・エスに入られてからなんですか？ 田辺さんがエス・エム・エスに転職してから、1年半後ぐらいに入社してます。ずっと誘われてはいましたが、少し時間が空いてますね。その時は、エス・エム・エスも一つの選択肢として考えていて、他にもいろんな会社の話を聞きつつ転職活動をしていて、最終的にエス・エム・エスに決めました。 その時はエス・エム・エス一本ではなくて、別の会社の話も聞いていたんですね。 ですね、いろんな会社の話を聞いてました。 そろそろお時間になりました。本日はありがとうございました。インタビューという名目でしたが、色々とスケールの大きい話が聞けて為になる時間を過ごさせてもらいました！ キャリアの話は意図してこのキャリアに進んだわけではないので、あんまり参考にならないかもしれません。ただ、迷ったら面白そうな道を選んできたのでそれが吉と出ているかも。選択をミスっても死なないですし、売り手市場なのでなんとでもなるでしょう、という気持ちでキャリアを選択してみて良いと思います。 (完) tech.bm-sms.co.jp

9/10 に閉会をした RubyKaigi 2022 へ Shuttle Bus Sponsor として参加しました。 今年の RubyKaigi では現地参加をする人がどのくらいいるのかが読めなかったため、スポンサーブースを出すことやノベルティの配布をせず、明らかに必要があるだろう Shuttle Bus Sponsor 1 本に絞って参加をしました。 蓋を開けてみれば、スポンサーブースも大盛況で「これは我々もスポンサーブースを出せばよかった!!」と若干の後悔もしながら各社のスポンサーブース巡りを楽しみました (今年の様子を参考にして、来年はスポンサーブースの出展もしていこうと一足先に心に誓いました)。 Shuttle Bus Sponsor 1 本に絞ったのは、アイデア一発勝負よりも、明らかにニーズがあるところへビジネスをつくりに行くという社風が現れた参加の仕方だったとも思うのですが、自社のスポンサーブース出展をしていなかったため、ほとんどの方へはエス・エム・エスという会社を知ってもらう機会をつくれていません。 もし、どんな会社かわからないので話を聞いてもいいよという方がいたら、Twitter アカウント エス・エム・エス@RubyKaigi 2022 や sunaot や採用担当の fkc_hr への DM や この記事の案内ツイート への LIKE をください。LIKE をもらえた方へは連絡をするようにします。また、記事末尾からは Wantedly からのカジュアル面談の申込みも受け付けています。 「RubyKaigi の土産話をして余韻を楽しみたい」「ただ技術の話をしてみたい」「カジュアル面談で会社の話を聞いてみたい」などなど、どんな形のご興味でも大丈夫です。もちろん、現地参加はしていない方からのご連絡も歓迎です。 LIKE やご連絡お待ちしています！ RubyKaigi 2022 に参加していたメンバーのブログ記事 tech.bm-sms.co.jp tech.bm-sms.co.jp tech.bm-sms.co.jp Wantedly 経由、カジュアル面談への申込み

はじめに はじめまして。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の能力スキルが存分に活かせます。当然働き方としても普通にパフォーマンスを発揮できるようにしてありますし、今後とも継続・発展できるように組織として成長させていきます。 ・・・と言うことが伝われば幸いです！ 今後採用サイトで発信していくこと 今後とも、例えば下記のような内容について継続的に更新していきます。 各チームの具体的な技術チャレンジ エス・エム・エスでの具体的な働き方がイメージできる粒度での組織情報（所属する可能性のあるチーム詳細など) 今後ともテックブログとともに採用サイトも折に触れご覧ください。