事業会社は今こそSWEを高給で雇ってWebシステムを内製しよう

YOUTRUST プロダクトヒストリーカンファレンス2026での登壇資料です。

Transcript

1. 事業会社は今こそ SWEを高給で雇って Webシステムを内製しよう 株式会社MyVision 取締役CTO 岡部匡志
2. 2 自己紹介 MyVision 取締役CTO 岡部 匡志 東京大学大学院情報理工学系研究科在学中にモバイルアプリを開発するITベ ンチャーを創業し、医療系HRのメドレー社に売却。 そのままメドレー社に入社、PMI業務に携わった後、2023年初頭に MyVisionを創業・取締役CTOに就任。
3. 3 なにをやってる会社？ A. HRの会社。 コンサル転職の支援から始まり、6つの職種・ブランドで事業展開 CAやRAといった営業職が社員の大半を占める、営業中心の会社 転職支援業界は2020年以降急速に「企業が選ぶ側」から「求職者が選ぶ側」に変わってきて おり、その潮流の中で、求職者中心の転職支援を実施することで、急速に拡大している 創業期から技術投資コミット。アジャイルな強い開発部を構えており、開発部が業務フロー 含めて責任負うことを徹底（これが業界的に稀有） 創業4年で400名弱、同業の上場企業を上回る売上規模
4. 4 開発部は なにをやってきたか
5. 5 社内システム InVisionの開発 SFA/MA/ERP/CMS/日程調整/各種データ集約/AI分析…などの機能を含む、 社内の全職種が使う、100p超えのモンスター社内システム
6. 6 Web系出身のメンバーとWeb系のやり方で社内開発をやる 日本では歴史的理由から、社内システムの開発を外部のベンダーに投げがち Web系企業においても、 「メインのプロダクトの次」みたいな扱いをされがち しかし社内開発も（定義上当然）業務の中心で、競争優位になりうる 本来はプロダクト開発と同様に、リーンに構築・計測・学習を繰り返し、探索的に開発す るべきだし、リリースも1日に複数回行うようなアジャイル開発でやるべき 開発部のバックグラウンド例 👉️強いメンバーを揃えるべき、ということです
7. 7 今日話したいこと：社内開発のリアル 1.社内開発とプロダクト開発との違い 2.どういう場合に事業会社が開発チームを持つべ きか？
8. 8 社内開発と プロダクト開発との 違い
9. 外部向け プロダクト 社内開発 ユーザー 数百〜数万（toB） 数百万〜数千万（toC） 基本的にN1 マネタイズの ハードル 定量的 厳密 タフな交渉がある 定性的 短期的にシビアではない 9 違い①：SWEがプロジェクト推進のスキルを要求されやすい ユーザと作り手の関係がシンプルなため、 PdMやBizDevなどの役割が小さい（いないわけではない） 逆説的に、SWEが プロジェクト推進のスキルを要求されることになる。 例：PRD/DDといったドキュメント・ドリブンの開発
10. 10 違い②： 「ユーザの業務フローを変更できる」ゆえのデリバリーの難しさ 社内開発では、ユーザの業務フローを自由に変更できる このことは通常のtoBプロダクトと比較したとき、提供価値における大きな差分 一方で当然、ユーザ（=社内の社員）は日々の業務で忙しい！ 業務フローの変更は、言うは易し、行うは難し 前スライドの都合で、いわゆる「デリバリー」もSWEの仕事 Webプロダクトと同様、使われない機能に価値はないので、純開発業務と同様に重要
11. 11 違い②： 「ユーザの業務フローを変更できる」ゆえのデリバリーの難しさ この辺もSWEの仕事となる ユーザの定例（例：営業定例）にリリースを合わせ、そこでの告知内 容を、現場のマネージャーと一緒に考える 簡単なユーザマニュアルを用意し、配る リリース後にユーザと喋ってみて、期待通りの価値を生んでいるか追 いかける 何回もSlackで言う（大事） 何回もリアルで言う（大事） 開発部には「リリースフロー相談の判断基準フロー」がある（右）
12. 12 違い③：ユーザとの距離の近さゆえに、健全な信頼構築が重要 通常のプロダクト開発と同様、ユーザには課題を聞くべきであって、ソリューションを聞 くべきではない それでは、誰の声を、どこまで聞くのか？ ユーザは当然、現在の業務については作り手よりも詳しい とはいえデザインA/Bを持っていって「どっちがいいですか？」は変だ リファクタ・リアーキといった開発部以外が軽視しがちなイシューもある 権力闘争ではなく、健全な信頼構築を目指そう 営業のゴリ押しに負けるな、といった単純な話ではない 作り手は独力では絶対に課題に気付けない ユーザに「こいつに相談したら良いことあるぞ」と感じてもらい、信頼↔実績の好循 環を生むことが重要
13. 13 違い④：わかりやすいKPIがない中での意思決定を迫られる ARPUや1DRRといった、わかりやすいKPIがない かなり抽象的な「生産性」や「サービスの質」を追い求めることになる 何を優先するか？ 単体の事業部の課題？事業部横断的改善？全くの新機能？リファクタリング？ クイックに仮説検証でリリースを刻む？正解が見えてるからまとめてリリース？ 完全新機能だと「カルチャー」も変数に入るので、仮説検証がある意味難しい 例：AI
14. 14 どういう場合に 事業会社が 開発チームを持つべきか？
15. 15 A1. 業務フローが枯れていない場合 枯れていないということは、継続的な探索行動が必要 そのようなケースでは、業務フローの違いが競合優位の源泉になりやすい 私見では、HR業界は典型的にそう 逆に枯れている場合は内製するメリットが少ないかもしれない 法人営業におけるSalesforce？
16. 16 A2. 自社固有のAI応用が豊富に期待できる場合 枯れてないといえば…AI応用 業務におけるAI応用、業務理解が全ての根幹 ML知識が高度に要求される領域も当然ありつつ、言ってしまえば素人がゴリゴリ新機 能を作っていくことで生まれる価値もかなり大きい リーンな開発フローもかなり重要になってくる Cが個人開発で気軽にアプリをリリースできるようになったのと同様に、Bも気軽に機能を リリースできる体制を構築するべき
17. 17 A3. 場合によってはプロダクトを作るかも…！の場合 迅速に動ける・均質なカルチャーを持った・信頼関係のあるチームを、ゼロデイから展開 できることはかなりの強み 上記を業務委託中心で実現することはかなり難しい もともと開発チームを構えていれば、リソースを寄せるだけで良い まさに今、やってます リリース数日前…！乞うご期待…！