事業会社で働くエンジニアに向けた要 件定義Tips
 2023年11月14日
 

自己紹介 エムスリーキャリア株式会社 IT推進部 BDEグループ　マネージャー 近藤 敦慎 （こんどうあつのり） 経歴 関西学院大学 → 大和総研 　通信キャリア向けシステムコンサルタント、 　　　　　　　プロジェクトマネージャー → インデックス（iXITに社名変更）プロジェクトマネージャー、VPoE、 　　　　　　　　　　　　　　　　執行役員（技術系） 　　 スポーツ競技団体向けCRM、ソーシャルゲーム、 　　 アクティビティスポーツ予約ポータル、地方創生/インバウンド事業等　→ 現職 　 医師、薬剤師の方向けの採用支援領域でのプロジェクトマネージャー スキル Ruby on Rails / Vue.js / AWS / Salesforce / GA4 / Redash X(Twitter)@atkondo 

エムスリーキャリアについて 医療の人・組織の課題を解決するサービスを展開 設立　2009年12月(創業11期目)　　従業員数　649名（2022年9月30日時点、正社員、契約社員数合計） 
 売上高140.8億円（2021年3月期） 　　　男女比　約2：3　　平均年齢　32.5歳 
 

目次 1. はじめに 2. 事業会社におけるエンジニアの要件定義とは？ 3. 要件定義のアウトプット 4. Tips a. エンジニアとしてのバリューを出すことを意識する b. エンジニアとしての代替案を出す c. 未来を見据えたアーキテクチャを検討する 5. 最後に 

はじめに①事業　 ・採用支援事業 　 ┗新規開発したSaaSによる支援 ・病院経営支援事業 　 ┗医療機関の経営収支改善、レセプト分析等 ・医師人材事業 ・薬剤師人材事業 ・健康経営事業 　┗産業医とともに企業の健康経営をサポート 

はじめに②エンジニア組織/担当システム エンジニア部門
 ・エンジニア組織　約50名のエンジニアが在籍。概ね全てのシステムを内製 
 　
 ToC系サイト ToB系サイト SFA/CRM
 医療従事者向け求人サイト 、口コミサイト、情報サイトなど 計18以上のサービス 医療機関向けの採用管理 ツール（スカウト送信、マー ケットデータ分析等） SFAをSalesforceで構築。SFA を中心にAI、MAツール、 LINE、DWH、BIツール等と連 携 

事業会社におけるエンジニアの要件定義とは？ 担当
 ・ビジネス部門: 事業担当者
 ・マーケティング部門:　IA(InformationArchitect)、PdM(Product Manager)
 ・エンジニア部門:　PdM(Product Manager)、BDE(BusinessDevelopmentEngineer)
 開発案件起案 開発会議 ビジネスサイドだけでなく、エンジニアも積極的に開発案件を起案 課題を掘り下げ、工数を見積もり、投資対効果を算出して開発優先順位 を決定 要件定義・仕様検討 ビジネスサイドと協力して要件や仕様を決定
 大きな案件は、QAが要件定義・仕様検討時点から関与し、要件・仕様不 具合を防ぐ 要件定義に向けての仕事の進め方としては以下のような流れです。 

要件定義のアウトプット 
 このフェーズでは次のような内容、形式でアウトプットでまとめられることが多いです。
 ● ビジネス部門　事業計画書、施策　: 目的、概要、事業目標、サービス・業務フロー　等　　　　　　　　
 ● マーケティング部門　画面指示書（IA書）　 : 目的、ROI、画面の変更箇所　等
 
 ● エンジニア部門
 -　要件定義書　：　
 　　- 基本情報　　： 前提情報、条件等
 　　- 依頼内容：上記事業計画書、施策　、画面指示書（IA書）について
 　　- 対応方針：　対応範囲、箇所、対応内容
 　　- インターフェース：　外部サービスとのインタースがある場合に記載
 　　- 効果測定方針：　目標値、測定方法　等
 　　- 概算見積り：　要件定義〜設計・実装・テスト〜QA・リリース　
 　　- スケジュール：　着手〜ビジネス/マーケティング部門での確認〜サービスイン
 　　- 検討事項　：　
 　　※ツール：SpreadSheet/Strap、Confluence、Figma
 

Tips①
 エンジニアとしてのバリューを出すことを意識する ● 事業/施策での目的をどう理解するかによって、システム化の範囲、アーキテクチャを含めた
 対応方針を決めて行く
 　サービスのロードマップ、週次、月次での事業KPIチェック、社内留学
 ● バリューを出す
 ・実現手段、概算工数/工期の算出
 ・技術検証（データ分析、機械学習、ChatGPT）
 
 
 

Tips②
 ● システム投資対効果をにらんで、ビジネス検証を行うことが大半であり、スモールスタートを目指すこと が多い
 　　簡易実装で先に検証を行うこともある。本格的対応はその仕組みを捨てて構築。判断は
 エンジニアで行い、関係者間で合意形成しながら進めて行く
 
 ● システム費用対効果が見えにくい場所については、外部ツールの選択、代替案を出す
 ・Googleフォームなど既存ツールでのサービス開始
 ・NoCodeツールなどの簡易ツールでのシステム提供
 　　・システムを完全に完成させた上での提供以前に、手集計での情報提供
 
 　エンジニアとしての代替案を出す 

Tips③ 
 ● 事業・組織・会社が長期間に渡って、成長・変化して行くことを踏まえて、システムアーキテクチャーを検 討しておく
 
 ・医療従者向けのtoC領域システム、医療機関向けtoB領域のシステム：　
 　Vue.js＋RubyOnRailsを基本形事業・サービス毎にWebアプリケーションシステムを展開
 ・キャリアコンサルタント・営業向けのSFA/CRM
 　Salesforceを中心に、MAツール、マーケティングツールを組み合わせて対応
 →　共通機能ライブラリ化、DevOpsツール統一、データ共通基盤構築
 　未来を見据えたアーキテクチャーを検討する 

最後に
 ご清聴ありがとうございました！
 https://open.talentio.com/1/c/m3career/requisitions/1742