こんにちは、エンジニアの江熊です。普段はマネーフォワードMEというWeb/スマホアプリで提供されるサービスに関わる様々な開発や取り組みを実施しています。
今回は、システムを作るための情報のまとめかたについて紹介します。ここで紹介するまとめかたは、僕自身普段の業務の中で、開発に関わる様々なことを円滑にすすめるために実践しているものです。また、開発が思うように進んでおらず悩んでいるメンバーによくおすすめしているまとめかたでもあります。
先日、僕のこのまとめかたを言語化し、チームに共有したところ、好評な意見をいくつかいただいたので、今回ブログ記事にすることにしました。
この記事に書くこと
どんなシステムであれ、それを作るためには、なぜ、なにを、どのようにつくるのかを明確にしなければなりません。明確でない場合、必ず手戻りが発生したり、ユーザが求めていない機能を届けてしまうことに繋がります。
ということで、この記事では、ユーザーフォーカスしながらシステムを作るには、どのように情報を整理すればよいかということについて、僕自身がよく使っているまとめかたについて書きます。 特に、エンジニアがシステムの設計（≒どのようにつくるかを決める作業）に着手するまでにどのように情報を整理するかを扱います。
いつ情報をまとめていくか？
今回紹介するまとめかたは、システムを作る前に実施すべきものになります。主に下記のようなときに実施すると良いと考えています。
- 自分が開発に関わる作業を開始するとき
- 差し込みなどによって前提が変わったとき
具体例を出すと、僕のチームはスクラム開発をしているので、例えば下記のようなタイミングで実施しています。
- チームでリファインメントをするとき
- リファインメントをチームができるように準備をしているとき
- ストーリーの開発に着手するとき
- 何らか状況変化によって、ストーリーに記載されいている内容・前提が変わったとき
また、これ以外にも、直感的にこのまま開発をすすめる中でなにかしらの不安を感じてしまっているときや、解像度が上がっていないな感じる点を見つけてしまったときにも実施しています。 もやもやを感じたまま開発をすすめると、手戻りが発生したりして残念なことになることが、僕個人の経験的にわかっているためです。むしろ、これがもっとも「いつ情報をまとめていくか？」の答えに近いかもしれません。
どのように情報をまとめていくか？
システム開発に関わる情報を上流から下流の工程に向けて整理することが、基本的な情報のまとめかたの方針となります。つまり、要求・要件・仕様の順にまとめていきます。上流の工程からまとめていき、その中で決まっていないことが明らかになれば、都度チームメンバーやステークホルダーと会話を行い決めていくというプロセスを繰り返していきます。
概要図を書き起こすと、下記のようになります。
Step1. 要求をまとめる
まずは、「ユーザがシステムに対してどんなことを実現してほしいと思っているのか」をまとめます。弊社の場合、チームのOKRが記載されている資料やユーザインタビューの議事録など、様々な形式のドキュメントに書かれていることがあります。システムを作るにあたっては、どの要求を満たすのかをしっかり認識するために自分でまとめなおすことがあります。
このような情報を箇条書きでまとめるのであれば、 1. なんらかの要求を出している登場人物を洗い出す 2. それぞれの人物の要求を洗い出す
という手順を踏みます。
登場人物とは、例えばマネーフォワードMEでありそうな例で言えば、下記のようなイメージです。開発するシステムや扱う要求によって、対象も粒度も大きく変わってきます。
- マネーフォワードMEユーザ
- Web版利用ユーザ
- アプリ版利用ユーザ
- 社内向けWebアプリ利用ユーザ
- 社内のある部署の方々
- etc...etc...
要求をまとめるためのテンプレート
要求をまとめるにあたって、下記のテンプレートにまとめることが多いです。特に、「〜してほしい」「〜してほしくない」語尾を意識してまとめています。
- (登場人物1)
- してほしいこと
- (要求1)できるようにしてほしい
- (要求2)できるようにしてほしい
- してほしくないこと
- (要求3)できないようにしてほしい
- (要求4)できてほしくない
- (登場人物2)
- してほしいこと
- ...
- (登場人物3)
- ...
Step2. 要件をまとめる
次に、「システムが何を満たせばよいのか」をまとめます。箇条書きでまとめるのであれば、 1. システムに関わる登場人物を洗い出す 2. それぞれの人物がシステムでなにができるのかを洗い出す 3. 非機能要件がないか検討する
という手順を踏みます。
また、この時点で可能であれば、非機能要件としてシステムができること、できないことは何かということも考え始めます。しかし非機能要件についてはすべて洗い出すには難易度が高いため、先に下流の工程へ進み、見つかった時点でこの工程に戻ってくることが多いです。
要件をまとめるためのテンプレート
要件をまとめるにあたって、下記のテンプレートにまとめることが多いです。特に、「〜できる」「〜できない」という語尾を意識してまとめています。
- 機能要件
- (登場人物1)
- できること
- (要件1)できる
- (要件2)できる
- できないこと
- (要件3)できない
- (要件4)できない
- (登場人物2)
- できること
- ...
- (登場人物3)
- ...
- 非機能要件
- ...
Step3. 仕様をまとめる
そして、「システムが要件を満たすために、どのような振る舞いをしなければならないのか」をまとめます。箇条書きでまとめるのであれば、
- システムに関わる登場人物と、それに価値を提供するものを洗い出す
- それぞれのものがなにができなければならない/できてはならないかを洗い出す
という手順を踏みます。
価値を提供するとは、例えばマネーフォワードMEでありそうな例で言えば、具体的なものであれば、Androidアプリ、iOSアプリ、webアプリ、社内向けwebアプリなどがあります。まとめている時点で抽象度が高い場合は、マネーフォワードMEユーザが操作するもの、システム、バッチなどの抽象度の高い表現でも良いです。
仕様をまとめるためのテンプレート
仕様をまとめるにあたって、下記のテンプレートにまとめることが多いです。特に、「〜できなければならない」「〜できてはならない」という語尾を意識してまとめています。
- (価値を提供するもの1)
- できなければならないこと
- (価値を提供するもの1)で(仕様1)ができなければならない
- (価値を提供するもの1)で(仕様2)ができなければならない
- できてはならないこと
- (価値を提供するもの1)で(仕様3)ができてはならない
- (価値を提供するもの1)で(仕様4)ができてはならない
- (価値を提供するもの2)
- できなければならないこと
- ...
- (価値を提供するもの3)
- ...
Step α. まとめたあとにさらにまとめる
ここからさらに、プラットフォームごと（サーバサイド、Android、iOS）に関係する情報を抜き出しまとめなおします。プラットフォームを横断して抽象的な議論していた状態から、プラットフォームごとにより具体的な議論する状態になったとき、見落としていたものが見つかりやすくなるためです。
例えば、サーバサイドで提供するAPI仕様をまとめることについて考えてみます。「このAPIに悪いリクエストを送ってみたらどうなるだろう」と思いを馳せることで、APIが満たすべき非機能要件が見つかったりします。このとき、要件をまとめるという工程に改めて立ち戻り、このAPIではできないことをまとめます。こうすることで、APIの仕様としてステータスコードが4xxになるパターンの洗い出しなどができるようになります。
まとめかたのまとめ
以上になります。まとめかたのまとめをするならば、下記のようになります。
- いつ情報をまとめるのか？
- 開発をすすめることに不安を感じたり、解像度が低いと感じているとき
- どのように情報をまとめるのか？
- 上流工程から下流工程に向けて整理することが基本方針
- 決まっていないことが明らかになれば、都度チームメンバーやステークホルダーと会話を行い決めていく
- それぞれの工程のまとめかた
- 要求は、「関わる登場人物が〜してほしい/ほしくない」という箇条書きにまとめる
- 要件は、「関わる登場人物が〜できる/できない」という箇条書きにまとめる
- 仕様は、「価値を提供するものが〜できなければならない/できてはならない」という箇条書きにまとめる
- そしてさらにプラットフォームごとにまとめる
最後に
僕がこのまとめかたを実践できるようになったとき、下記のような数々の良いことがありました
- 設計やコードのレビューで指摘される事項が圧倒的に減った
- 開発の手戻りが圧倒的に減った
- 下流工程実施時に前提条件を忘れることが減った
- 既存の実装に関する知識に引きづられずに、非エンジニアの人と会話することができるようなった
- スクラム開発での Story 分割作業のスピードが上がった
- etc...etc...
また、チームメンバーに横展開することで、僕と同じような効果が得られているようにも感じています。
今回紹介したまとめかたは、僕自身が今まで働く中で多くの先輩方から教えていただいたことを数年間実施してきたことです。この記事を書くにあたって改めて僕の言葉で、自分がどうやっているのかを言語化してみました。この場を借りて、今まで僕に様々なことを教えてくださった先輩方に感謝申し上げます。
マネーフォワードでは、エンジニアを募集しています。
まずはカジュアル面談でお話しませんか？皆さんのご応募お待ちしています。
