justInCaseTechnologiesのしごと図鑑 vol.1 PjM 宮越康平

justInCaseTechnologiesのしごと図鑑とは

インシュアテックに特化したスタートアップ企業であるjustInCaseTechnologiesでは、2024年6月現在、約50名の社員が働いています。社員の平均年齢は36歳。20代から60代まで幅広い世代のメンバーがそろいます。テクノロジー企業の特色として、従業員の約半数をエンジニアが占めますが、一言でエンジニアといっても、フロントエンジニア、バックエンドエンジニア、QAエンジニア、デザイナーなど、その役割は様々です。また、一般にバックエンドエンジニアと呼ばれる職種であっても、当社の場合、その人の個性や能力によって、他の企業とは少し違った働き方をしていることもあります。
そこで、本企画では、職能別に、第一線で活躍するメンバーのリアルな「しごと」をご紹介したいと思います。第１回はPjMの宮越に自身の「しごと」について語ってもらいました。

目次
1. 入社時期・所属部署
2. これまでの経歴
3. 入社の決め手
4. justInCaseTechnologiesのPjMとしての役割
5. 1日の流れ（お客様とのミーティングがある日）
6. ここがポイント！

入社時期・所属部署

開発部門のPjM、宮越と申します。私は業務委託として2023年の8月に入社し、9月から正社員として働き始めました。当社ではアジャイル開発の一種として扱われる「スクラム開発」を採用しており、スクワットと呼ばれる少人数のチームごとに役割やタスクを分散しつつ、コミュニケーションを取りながら開発を進めています。
私は入社当初から デリバリースクワット部に所属し、開発のフロントでPjMとして顧客対応を担当しています。肩書きに関しては、2024年4月からスクワッドリードに就任しました。スクワッドの体制も4月で大きく変わり、私が所属するスクワッドCは、フロントエンドエンジニア１名と、 バックエンドエンジニア２名に私を加えた4名体制でやっています。バックエンドエンジニアのうち1名がスクラム体制におけるスクラムマスターを兼務しています。

これまでの経歴

以前はエネルギー関連企業のDX部門でPjMとして働いていました。
社内で新しい案件が出たときに、提案依頼書を書いて、 複数のベンダーに対して「こんなことできないですか」「こういう提案をしてください」と依頼をし、提案いただいた内容を精査して、発注先を決めるといった業務や、ベンダー決定後の要件定義、コストの交渉や、スケジュールやスコープの調整、納品された製品の受け入れテストといった、ベンダーコントロールと呼ばれるような業務を担当していました。

入社の決め手

入社を決めた理由は主に二つあります。
一つは、働く環境を変えたかったということです。
家庭の事情により、家にいる時間を長く取りたくなったことから、より柔軟な労働環境でPjMの経験を活かせる仕事を探していました。

もう一つは、純粋にプロダクトが魅力的だったことです。
当社が開発・提供している保険業界に特化したSaaS「joinsure」は、基幹システムが基盤となっている保険業界に、新しい風を吹き込むプロダクトだと感じています。前職でも契約管理系の基幹システムの維持・開発に携わっており、得意とする分野だったのですが、「joinsure」は顧客の要望に応じて次々に新機能を追加しているという話を聞き、SaaSならではの機動性に魅力を感じて入社を決めました。

保険業界の経験もなく、SIerからの転職でもないという私の経歴は、社内では少し珍しいかもしれません。

justInCaseTechnologiesのPjMとしての役割

現在の私の職責は、「joinsure」を顧客の案件にしっかりと適応させることです。
私自身にはいわゆるエンジニアリング的なスキルはほぼありません。
ただ、私のPjMとしての強みは「ギャップとフィットを見極めて調整する力」にあると考えています。

当社での私の仕事は、お客様の要望をしっかりと聞き取り、「joinsure」とのギャップを確認するところから始まります。このギャップへの対応方法はおおまかに二つです。
一つは、お客様の要件に合わせて「joinsure」をカスタマイズする方法。
もう一つは、お客様側での運用によるフォローの提案です。
いずれの場合も、コストとスケジュールの折り合いを常に考えながら、ベストな落としどころを探る必要があります。「カスタマイズにはこれくらいコストがかかります」とお伝えしたときにお客様から「どうしてそんなにかかるのか？」といった質問が出た場合にもきちんと根拠を説明しますし、お客様が「こうやったらうまくいきそうだ」と言われたときに「こちらの方がもう少し良い方法だと思いますよ」といった提案をすることもあります。

また、社内に対して「お客様からこういう機能を求められているが、これは個社の話ではなく、将来を見据えた時にjoinsureのコア機能としてあるべきだと思う」といった提案をして、社内全体に合意形成を促すといった動きをするのもPjMの仕事です。
この他にも、新規の開発案件について、アカウントマネージャーと連携してシステム面からの知見を注入する開発営業の役割もあります。目の前の案件だけでなく、社会の動きや会社の将来像など、さまざまな方向から物事を考えていく必要がある仕事だと思います。

仕事のやりがい

お客様の要望と、「joinsure」の機能に全くギャップが無い、ということはまずありません。お客様ごとに理想のサービスはさまざまですし、当然、時間の経過とともに求めるサービスが変化することもあります。そうした要望に機動的に適応できるのがSaaSである「joinsure」の強みでもあるので、そのギャップはいわば「不可避」なものであり、我々PjMの存在意義でもあるわけです。

現実問題として、きれいにうまくいくことばかりではありませんが、社内のメンバーと協力していくつもの課題を乗り越え、お客様の希望に沿ったカスタマイズができたときには大きな達成感が得られます。

1日の流れ（お客様とのミーティングがある日）

9:00：業務開始 －仕事の整理。顧客MTG準備

10:00：顧客MTG

11:00：デイリースクラム（Squad内）－チームメンバーの今日のタスク共有・調整

13:00： 課題解消ミーティング（上長と）－顧客MTGのフィードバック・相談

14:00： ハドルミーティング（Squad内）－チームメンバーとの情報交換。時には雑談も。

15:00： work

16:00： work

17:00： 開発案件進捗確認MTG（社内）－社内全体の案件の進捗確認・課題検討

17:50‐20:00：いったん離席。2人の子どものお迎え・夕ご飯・お風呂など

20:00 ：work　残りの仕事や翌日の準備

ここがポイント！

・スクラム開発
当社では、アジャイル開発の一種として扱われる「スクラム開発」を採用しています。チームを組んで役割やタスクを分散しつつ、コミュニケーションを取りながら開発を進める点が特徴で、ラグビーのスクラムにちなんで、「スクラム開発」と名付けられています。コミュニケーションが仕組みとして組み込まれていることで、リモート環境でも、チームメンバーとの物理的・心理的距離を感じることなく仕事ができているといいます。

・フルリモート＆フルフレックス
住まいが北海道ということもあり、仕事は基本的にフルリモート。PjMという職種の特性上、お客様とのミーティングも多くあるものの、コロナ禍を経たことでリモート会議が広く普及し、不都合を感じることなく仕事ができているといいます。東京のオフィスには３か月に1度程度出社してメンバーとの直接的な交流を持つようにしているそう。

・コミュニケーションはややオーバーに
時折、専門性の高いエンジニアのメンバー同士の話が分からないこともあるそうですが、そういうときにはそのまま流さず「それってどういう意味ですか」と、しっかり確認するよう心掛けているといいます。「私はリモートで仕事することが多いので、発言しないとそもそも理解できていないことが伝わりません。少しオーバーなくらいのリアクションで思ったことは伝えるようにしています。幸い優しいメンバーばかりなので、みんな丁寧に教えてくれます」と語ります。