初めに
今回のエムスリーキャリア FY22 AdventCalendarは、初回に続き近藤（@atkondo）が記載させて頂きます。
内容としては、「要件定義におけるTips」とさせて頂きました。
私は22年4月中途入社で入社後1年半年経過しています。
当社のご説明を差し上げておくとエムスリーグループの一社として、医療従事者（主に医師、薬剤師）の方向けの人材紹介・派遣事業を中心に、近年では、経営支援・採用支援、産業保健・健康経営の事業を行っています。
エンジニア部門としては、「医療従者向けのtoC領域システム」、「医療機関向けtoB領域のシステム」、「キャリコンサルタント・営業向けのSFA/CRM」の開発を担っています。
当社では、50名のエンジニアがおり、概ね全てのシステムを内製しています。
テンポラリーで人手が不足している箇所等では業務委託の方にも数名ご協力を頂いています。
本日は、各システムの要件定義を行う上での、特にビジネスサイドとの関わり合いにおけるTipsをいくつか記載したいと思います。
同じような立場で働く方々への参考になればと思います。ご質問やご意見あれば頂ければと思います。
事業会社におけるエンジニアの要件定義とは？
要件定義に向けての仕事の進め方としては以下のような流れです。
- 開発要件のピックアップ
- 開発会議による開発要件の選定
- 要件定義、仕様調整
また、この要件定義、仕様調整を担当するのは、事業などによって若干異なります。
・ビジネス部門: 事業担当者
・マーケティング部門: IA(InformationArchitect)、PdM(Product Manager)
・エンジニア部門: PdM(Product Manager)、BDE(BusinessDevelopmentEngineer)
サービスフロー・業務フローに関する施策はビジネス部門/エンジニア部門の担当が、Webマーケティングの領域に関する施策はマーケティング部門の担当が牽引することが多いです。
最終的には、エンジニア部門の担当が、設計に落とし込めて、見積りが可能なレベルまで、要件を整理して行きます。
ビジネス部門、マーケティング部門との認識の擦り合わせが可能なレベルまでとなります。
要件定義のアウトプット
このフェーズでは次のような内容、形式でアウトプットでまとめられることが多いです。
- ビジネス部門
事業計画書、施策 : 目的、ROI、サービス・業務フロー 等 - マーケティング部門
画面指示書（IA書） : 目的、ROI、画面の変更箇所 等 - エンジニア部門
- 要件定義書 ：
- 基本情報 ： 前提情報、条件等
- 依頼内容：上記事業計画書、施策 、画面指示書（IA書）について
- 対応方針： 対応範囲、箇所、対応内容
- インターフェース： 外部サービスとのインタースがある場合に記載
- 効果測定方針： 目標値、測定方法 等
- 概算見積り： 要件定義〜設計・実装・テスト〜QA・リリース
- スケジュール： 着手〜ビジネス/マーケティング部門での確認〜サービスイン
- 検討事項 ：
エンジニアでは、基本的には、SpreadSheetで合意形成をとりながら、最終的には、Confluenceに落とし込むことが多いです。
デザイン はRDやFigmaといったデザインツールを使うことが増えて来ました。
Tips
ここから本題であるTipsとは3つほどご紹介しておきたいと思います。
- エンジニアとしてのバリューを出すことを意識する
事業/施策での目的をどう理解するかによって、システム化の範囲、アーキテクチャを含めた対応方針が決まって行くかと考えています。これがエンジニアとしての大切なバリューであると意識すべきでは無いかと考えています。
どこまで事業/施策の領域に踏み込んで行くかが難しいところではありますが、マネージャークラスはもちろんのこと、できる限り、リーダークラスも、事業/施策の背景や狙いが解像度高く理解できるように事業/施策へのコミットメントを行なっておく方が良いと考えています。
特に新しい事業/施策を行う上では、誰も正解が分かっていないことがあります。
そのような状況の中で、システム化の範囲、アーキテクチャを含めた対応方針を出して行くというのは大切な一方で、難易度が高いタスクとなります。
「社内に公開されている一次情報をなるべく当たっておく」、「社内の事業担当者に直接質問して行く」といったことがその支えになることが多くあります。
- エンジニアとしての代替案を出す
コアな企業の競争力の源泉となり得るシステムは当社内で作り込むべきではありますが、まだ、システム費用対効果が見えにくい場所については、外部ツールの選択、代替案を出す、ということも大きなTipsとなります。
当社ではシステム投資対効果を睨んで、ビジネス検証を行うことが大半であり、スモールスタートを目指すことが一般的です。
そのために場合によっては、NoCodeツールでシステム提供を行った上で、本格的対応はその仕組みを捨てて構築するという判断を行うこともあります。
こういった方向性について、判断はエンジニアで行い、関係者間で合意形成しながら進めて行くところが1つ大切にすべきTipsと考えています。
- 未来を見据えたアーキテクチャを検討する
一方で、事業・組織・会社が長期間に渡って、成長・変化して行くことを踏まえて、システムアーキテクチャーを検討しておくことも大切です。
当社の場合は、大きくは以下の方針を取っています。
・医療従者向けのtoC領域システム、医療機関向けtoB領域のシステム： Vue.js＋RubyOnRailsを基本形として、事業・サービス毎にWebアプリケーションシステムを展開
・キャリコンサルタント・営業向けのSFA/CRM： Salesforceを中心に、MAツール、マーケティングツールを組み合わせて対応
共通機能をライブラリと利用を進めて行くことや、DevOpsツールを統一して行くことは進めながら、NoCode化やマイクロサービス化も進めて行こうとしています。
最後に
エムスリーキャリアでは、積極的にエンジニアを採用しています。
カジュアル面談も行っていますので、是非、関心を持って頂きました方お話しさせて下さい。
・toC,toBシステムを担当する、Webアプリケーションエンジニア
・SFA&CRMの開発を手掛ける、社内システムエンジニア
・QAエンジニア