はじめまして！LayerXのカレー担当のN_Taisho（西井）です。
私は、もともと霞ヶ関の役人として、６年ほど地方財政支援、大規模災害の被災地の復旧・復興支援、国際協定交渉等に関わってきました。現在はLayerXに所属しながら、三井物産デジタル・アセットマネジメント株式会社（以下、MDM）にてProduct Managerとしてプロダクト開発に主に携わりつつ、会社立ち上げに係る様々な業務に従事させてもらっています。
このMDMは、「眠れる「銭」を、Activateせよ。」をミッションに、「Operation × Techでどうアセマネ業務をリデザインするか」に取り組んでおりますが、その概要については以前、同じくLayerXに所属しながらMDMにコミットしている丸野が執筆した以下の記事が詳しいところなのでそちらをご一読いただければと思います。
今回は、プロダクト開発の経験がない私が、複雑な要件が絡まり合うアセマネ業務においてどのように開発要件を整理していったか、その考え方を中心に簡単に解説できればと思っています。実際に、要件を整理して開発を進める中で気づいた点・学んだ点もありますが、本文においてはその辺りも再度まとめ直した形でお伝えできればと思っています。
正直、私にとって要件定義とは、画面一覧、機能一覧、インターフェース一覧などの一覧系とその一覧に対応した機能系の大量のドキュメントという印象しかありませんでした。開発において要件定義の必要性は認識されていますが、そもそもの定義内容が明確ではないと物事を前に進めるのは難しいので、どのように進めて行こうかあれこれ思案をしていました。
参考にしたもの
経験豊富なメンバーに相談するのはもちろんのことですが、手法としてはRDRAを参考にしました。書籍としては以下のものが参考になりました。
RDRAとは
多くの解説記事等が出ているところなので詳細は譲りますが、単語としてはRelationship Driven Requirement Analysys（リレーションシップ駆動要件分析）の略称です。「網羅性」「整合性」「表現力」がキーワードとなっており、網羅性により要件定義に必要な情報の枠組みを決定し、整合性によって作業手順を決定し、表現力によって共通認識を確立していくものです。簡単に、システムの全体像を素早く把握し、整合性を保ちながらチーム全体で要件定義をしていくもの、と思っていただければと思います。
大事にしたこと
私自身、実は、当初は三井物産グループ内のアセマネ会社に出向し、アセマネ業務を学ばせていただいていたので、開発チームには後から参加する形となりました。なので、RDRAという手法を参考にしたとはいえ、これまでの開発チームのやり方であったり、はたまた個々のメンバーの特性もあるので、手法をそのまま取り入れるというより「考え方」の部分を大いに参考にしました。具体的には次のとおりです。
①全体把握と優先順位決めを最速で
RDRAは上述の通り軽く最速で要件定義を行うための手法です。一方、開発においてはいつでも時間は有限なので、素早く全体を把握した後には、枝葉の決め事は後回しにし、重要・主要なところを重点的に議論することを意識しました。
②共通のコミュニケーションツール・議論の土台とする
大前提として、経験のない自分が決め切ることはどう考えても不可能だと考えており、また、書面を作成することが目的化し、整合しない資料を量産しても時間の無駄だと考えていました。その上で、重要なことは、ドキュメントを作ることではなく、開発メンバーとのコミュニケーションのベースを作り、最優先に着手しなくてはいけないものを明らかにすることと考えました。そのため、Lucidchart、スプレッドシートなどに自分がアセマネ会社に出向して学んだ業務フローやデータの流れを可視化し、これを議論の土台にし、「議論しながらその場で作成・確認する」サイクルで進めることを意識しました。これにより、要件を決めるスピードが格段に上がったような気がします。なお、この際ドキュメントを複数作る場合において、当該ドキュメント間の整合性は強く意識しました。
今になって思えば、ふわっとしたことを形にしていく工程では、様々な要素が相互に関わり合うため、アウトプットが一度出てきても都度見直す必要があります。そのため、 早い段階で重要部分を把握・共有し、当該部分との整合性を図りながら要件定義・開発を進めることで不要な手戻りを減らすことはとても重要な気がしています。
③仮説ベースでも進めていく
アセマネ業務の経験があるメンバーのいない中での開発プロセスだったので、資料集めやヒアリングももちろん行っていました。ただ、入手した資料・情報は粒度も目的も様々だったので、それらを土台に分からないことをただ闇雲にヒアリングしても効果は薄いだろうと予想されました。なので、まずは事前に、手に入る資料や見聞きした情報から仮説を組み立て、それを元にヒアリングを行うことを意識しました。この辺りは、「動くものを作る」だとか「Demo Driven Development」というLayerXのカルチャーにも通じるところがあります。
具体的に何をしたのか？
ここまでは考え方というような、抽象論に終始してしまいましたが、お伝えできる範囲内で具体的にどのようなプロセスで、何をしてきたのかをご紹介できればと思います。
一般的にプロダクト開発は以下のプロセスで進んでいくかと思います。
①ユースケース・アクターなどの抽出
②BPMNなどのような手法を使い業務プロセスをモデリング（BPMNについても機会があれば紹介できればと思います。）
③ドメイン抽出（イベント、システムとの境界把握等）
④機能群の整理
この後、機能ごとにスケジュールを立てて、以下を実施します。
⑤画面の洗い出し
⑥データ設計（DBスキーマや状態遷移等の整理）
⑦ユースケース充当性確認
⑧アーキテクチャ設計やコードの設計議論
⑨実装
この中で、上記の考え方をもとに、①から⑤までを迅速に行い、議論の土台を構築しました。
例えば、以下のようなLucidchartの図を活用して、①から③を行い、
その上で、次のような図で④と⑤を素早く行いました。図自体は、証券会社が投資家に対して投資案件の情報を提供する機能を例としてイメージし、極端に簡素化した上で作成しております。
関連会社に出向していたこともあり、業務フローに一番精通していた自分が、業務フローからユースケースを詳細化し、プロダクトの価値の単位を大雑把に把握し、早めにチームに共有することで、
なぜこの機能が必要なのか、この機能の使われ方はこのようになる、などの議論ができたように思います。
また、機能を活用するユーザーにとって価値が提供されるものから着手すべきという考え方から、できるだけ早い段階から全体を見通しつつ、優先順位をつけて開発に移行できる単位を明確にする作業も行いました。具体的には、機能の全体図を描きつつ、機能ごとの依存関係の図示なども行い、被依存度の高い機能の優先度を上げるということをしました。「議論しながらその場で作成・確認する」というサイクルを意識することで、意思決定もチーム内で素早く実施ができたように思います。
ここで個人的に意識していたのは、
a. ビジネスロジックまで含めて精度の高い仕様を事前に整備しない
b. 情報や状態の遷移まで細かく把握していないので後回し（上記で⑥を含めてないのはここにも一因があります）
c. 荒い要件定義でよく、細かい仕様は議論・開発しながら
という点で、上述した「大事にしたこと」とも大いに関わってきます。
胸を張ってしっかりとできたと言えるとは思っていませんが、この辺りの意識も、重要なユースケースの洗い出し、全体像の合意、開発着手順の足場作りに大いに貢献するのではないかと、今では改めて感じております。
開発の面白さ
ドメイン知識・業務知識もほとんどない段階から始めたので、振り返れば、初期に作成した画面・機能は以後の検討でほとんど書き換えられ、最終的に残らないこともありました。ここには悔しさに似た気持ちもありますが、正確性に固執せず、まずは自分たちの理解する範囲で記述し、チームで議論するベースを作る、その後、自分たちの理解していること・議論の結果を足場にすることでヒアリング精度が上がったり、仮説が磨き込まれていく。この繰り返しで、正解に近づいて行ける感覚があります。初めてのことでも知識が繋がっていくこと、同じく誤解していたこと・勘違いしていたことがはっきりし正しい方向へ迎えること、これをチームで行えることに個人的には面白さを感じています。
以上ではありますが、簡単に自分が未経験でありながらプロダクト開発にあたり複雑な要件を整理する際にどのように考えてきたかを紹介してきました。
We’re hiring!!
最後になりましたが、LayerXは各職種（特にエンジニアの皆さん！）絶賛採用中です！ 私のように未経験分野でも挑戦する機会やそこをバックアップしてくれる頼もしい仲間がある環境です。 少しでも興味ありましたら一度カジュアルに話を聞きに来てください！
今回記事を書いている私が所属している三井物産デジタル・アセットマネジメントの求人情報はこちらです！ herp.careers
