はじめに
本記事では、
要件定義をするときにはお客さんの「どんな悩みを解決するのか」を真剣に考えよう
という学びについて共有します。
営業の現場から少し距離があるシステム担当が、
お客さんのためになる、価値あるシステムを作る
にはどうしたらよいかを考えていきます。ここでは、実際に私が悩んだ実例をもとに共有します。（実例自体は、大幅にぼかしています）
要件定義初心者の方は、参考にしていただければ幸いです。
（ベテラン開発者の方は、アドバイスいただければ助かります。）
マイクロサービスアーキテクチャで活用されているAPI
突然ですが、今回、話題の中心になる API（Application Programming Interface) について述べておきます。
ご存じの方は#フロントエンドからの相談事項をAPIで解決したいまで飛んでください。
マイクロサービスアーキテクチャ
近年注目されているマイクロサービスアーキテクチャでは、「あるサービスを実現するための機能は、でっかく１個作るのではなく、小さい機能の集合にしよう」と言われています。
このとき、小さい機能どうしのデータのやり取りは、基本的にAPIを利用して行われます。
マイクロサービスアーキテクチャの各コンポーネントサービスは、他のサービスの機能に影響を与えることなく開発、デプロイ、実行、スケールできます。各サービスは他のサービスとコードまたは実装を共有する必要が一切ありません。コンポーネント間の通信はすべて正確に定義された API を通じて行われます。 ーマイクロサービスの概要 | AWSー
APIとは
APIの定義としては、「システムとシステムがやりとりをするための一連の決まり事」になります。
ポイントは、
データの構造やシステムの中身を理解していなくても、IF仕様さえ理解すれば必要なデータが取れるということです。
API を使うと、他の製品やサービスがどのように実装されているかを知らなくても、利用中の製品やサービスをそれらと通信させることができます。 ーAPI とは | application programming interface | Red Hatー
APIの種類
APIには以下のような種類がありますが、ここでは一般的に利用されているREST-APIについて考えます。
REST-APIはWebAPIの一種で、以下の特徴を満たします。
- HTTPで通信できる
- REST原則に従っている。
- 詳細は割愛しますが、「ステートレス」であることは押さえておくべきです。
- ステートレスとは、要求が同じであれば、何度やっても同じ結果が変えること。1度目の要求を覚えておいて2度目の要求のときに使う、といったことはしない。
フロントエンドからの相談事項をAPIで解決したい
ここで要件定義の話に戻ります。
APIで情報を返却するシステム
私が担当しているシステムでは、REST-APIを使ってフロントエンドシステムに情報を提供しています。
事業価値の高いAPIを作成することを宣言し、そのためのポリシーとして
- わかりやすい
- たくさんの人が使える
ということを掲げています。
ユーザ情報の一覧を出したい
ある日、フロントシステムから相談が来ました。ここからは例え話になります。
私がNet〇lixのバックエンド担当で、Net〇lixのユーザに関するAPIを提供していると仮定します。
ここで、フロントエンドの担当者が、以下のような相談を持ち掛けてきた状況です。
- 高校が生徒にアカウントを払い出してまとめて利用してくれているから、学校ごとに利用者の一覧が出せる画面を作ることにした。
- 学校によっては生徒が10000人いるところもある。
- 出したい情報は以下のイメージ。
- 項目名を押すとソートしたい。
- 加入月、無料期間終了日、プランで検索できるようにしたい。
HOWから考えがちだけど、それってビジネス目線が無いよね
とりあえずAPIの提供方法を考えてみる
提供しているAPIは、単一のお客さんが自分のユーザ情報を見るためのものなので、そのままじゃ使えないな
と思ったので、どうすれば実現できるのかを考えてみました。
①普通にAPIを使う？
ログインしてから4本のAPIを10000回ずつ呼び出すのは現実的ではない。（並列処理で頑張るとしても、ある程度時間がかかるのは免れない） 呼び出した後、画面側でソートや検索するのも大変。
②画面専用のAPIを作ってあげる？
検索はSQLでするのが良いので、言われた通りに検索するAPIを新たに作成してあげることも可能。
学校向けの画面の利用者数はたかが知れているし、そこにお金をかけるのはどうなのか？今あるものを使ってコスパ良く開発できないものか。
③バックエンド側でファイル作成して返却する？
①案のAPIのデメリットを改善したバージョン。 APIを10000回呼び出すのをバックエンド側で実施する。
時間がかかるので、フロントエンド側からは非同期の処理として取り扱う。
画面側でソートや検索をするのも大変なのは同じ。 しかし、ユーザが画面の目の前にいる状況で、いつ返却があるかわからない非同期は難しい。。
④データベースごと送ってしまう？
いろいろな条件で検索したいのであれば、1日1回と決めてデータベースごと渡してしまうか。しかし、「わかりやすく」はなくなってしまう。
無料期間の算出は、データベースから単純に抽出すればよいわけではなく、複雑な計算が必要であり、計算ロジックを画面が保持するのはメンテナンス性が悪い。また、サービス仕様の変更で無料期間を延ばしたい場合、フロントエンドシステムの修正も必要になってしまう。
いろいろ考えたましたが、
- 画面の前のユーザを待たせず
- 検索やソートを自在にして
- わかりやすくフロントエンドに提供する
を満たす解は思いつきませんでした。
早々に詰んだので、ベテランを数名つかまえて相談しました。 （相談できる環境ってありがたいよね）
何をしたいかによってAPIに求められる機能も変わる
相談した結果、
「この一覧画面はどんなお客さんのために使いたいのか？お客さんのどんな困りごとを解決したいのか？それによって、解決方法は変わるのではないか」
とのアドバイスを受けました。
お客さんの「どんな悩みを解決するのか」を真剣に考えよう
先ほど、私は10000人の情報を取得したいという要望を素直に受け止め、どうやってやれば良いだろうと、HOWを考えていました。
一方で、先輩たちはWHYを考えていました。
システム部門の使命は、システムをつくることではなく
「ビジネスに貢献すること」
です。今回は業務支援システムのフロントエンドを取り扱っており、「自身の高校の契約をまとめて管理する、お客さんの何らかの悩み」を解決することが目的のはずです。そのため、システムの目的・ゴールとして、「お客さんのどんな悩みを解決するためのシステムなのか？私たちはそのためになにができるのか？」を明確にし、期待に応えることが、システム屋としてのビジネス貢献につながります。
作ろうとしているシステムが、お客さんの「どんな悩みを解決する」のかを考えた
今回は、例えば以下のような観点で利用システムを理解を深めることにしました。
そもそもの目的
- そもそもお客さんにどうなってもらうためのシステムなのか？
- 高校の一覧画面は、お客さんがシステムにログインしてからファーストビューとして表示するのか？
- それとも、明確な意図をもったお客さんだけが見に来る画面なのか？
各仕様の、実現によって期待されること
- 加入月、無料期間終了日、プランで検索できるようにしたい。
- 各項目でソートしたい。
という仕様について、
- 10000人の生徒から検索して、そのあとどうするのか？
- プランで検索するのはどういう場面なのか？
- ソートは何のためにするのか？
フロントエンドシステムの担当者と議論した結果
当然ながら、画面の設計をしているメンバー（今回の依頼者）は、目的やゴールを理解しているはずなので、聞いてしまうのが最も早いです。
担当者と議論すると、目指しているものが見えてきました。 ※本節もフィクション多めです
お客さんのどんな悩みを解決するのか
- 「情報照会」と、「契約追加」の2点をサポートするシステムを作りたい。まずは「情報照会」のサポートを優先で始めたい。
- 学校の担当者は、生徒分の契約をまとめて実施していても、全体を確認することができない。現状、手元に全契約分のユーザIDを控えておく必要があり、不満の声が上がっている。
- Net〇lix社としても、お客さんの手間を減らすことで、学校へのシェアを広げていきたい。そのために、同じ条件の契約を、複製して追加することができるようにする計画がある。
システムに必要なこと
- お客さんログイン後のファーストビューとして、一覧（ぽいもの）を見せたい。TAT（Turn Around Time）が早いことが重要。
- 言われてみれば、ファーストビューではどの20件が表示されていてもいい。
- 検索機能は「情報照会」と、「契約追加」にも必要となる機能であるから、応答に時間がかかっても正確なものを表示したい。
- ソートは明確に使い道が決まっていないかも。
- ただし、無料期間の終了と同時にプランを見直したいという声も多いことから、無料期間はソートする人が多いと考えられる。
- お客さんの手元の管理簿もすぐには無くせないので、CSVダウンロードさせてあげたい（←new）
かなり具体的になりました。
画面の求めるものを理解した上で、提案したもの
画面の求めるものを理解できると、「外してはいけないポイント」「手を抜いてよいポイント」が見えてきます。すべての指標（応答性能や情報鮮度、維持コストなど）が理想的になるシステムを作るのは難しいため、システムの価値を最大化できる塩梅を見つけに行きます。
ここまで考えてきた結果をふまえると、フロントエンドがAPIに求めることとして、
- ファーストビューは複数のユーザ情報をそれっぽく早く出したい。
- 検索は全件で検索したい。
- CSVダウンロードもさせたい。
の3点が挙がりました。
これをもとにチームメンバーと議論した結果、バックエンドシステムとしては以下の機能を提案することにしました。
- バックエンドで保持する情報を、フロントエンドが使う情報に変換して、1日1回送信する。
- ユーザID、ユーザ名
- ユーザID、加入月、無料期間終了日、プラン
- ユーザID、視聴履歴
- フロントエンドシステムは、受け取った帳票をDB保持して、画面からの要求に応じて検索・ソートして利用する。
この機能を提供することになった判断のポイントを以下に示します。
- お客さんが画面の前で利用する機能なので、応答に何分もかけることは難しい。
▶フロントエンドシステムがデータベースをSQL参照できれば、TAT（Turn Around Time）はある程度良くなる。 - 検索の用途が重要である。
- 今後、お客さんの反応を見ながら、検索項目を柔軟に変更したり、ソート機能を充実させたりすることが予想される。
▶変更するたびにバックエンドシステムに開発を依頼しなくてはならない状況は、柔軟性・コスト面から避けたい。よって検索機能やソート機能はフロントエンド側に寄せる。 - 情報を一覧で見ることが目的であるため、最新情報であることの優先度は低いと判断できる。（最新の情報が必要なユースケースが発生する場合は、1回線ずつ確認する画面を別でこしらえることも可能。）
▶バックエンド側データベースの変更は、1日1回の連携にとどめる。 - わかりやすいデータを提供するというポリシーは守りたい。
▶バックエンドのデータベースを公開する方式はとらない。
フロントエンド側に提案する際は、すべての事柄において、利用するお客さんにとって、どうかを論点にしました。
フロントエンドの担当者から「そこまで考えてくれるんだ・・・！」と言わんばかりの顔をしてもらえたのが、少し嬉しい（言われたわけではない）。
さいごに：マーケティングスキルは誰にとっても重要
ビジネス価値と顧客目線を忘れない
「ビジネスにどう貢献するか考える」「ビジネス価値の高いものをつくる」「お客さんがどう感じるかを設計する」という思考は、当たり前にできていなくてはいけないのですが、
意外とシステムの設計・納期・コスト・その他しがらみとずっと向き合っていると、忘れてしまうものです。
企画部隊は別にいることも多いので、フロントエンドの開発者ですらも忘れがちかもしれません。1回学んだだけではダメで、どんなときでも「価値」を考えて試行錯誤することが重要だと感じます。
ビジネスを考えるということは、「お客さんにとって何が最善か」や「どうしたら儲かるのか」という
正解のない問い
を考え続けることになります。正解の無い問いへの回答を、周囲と意見をぶつけ合って磨いていける環境が大事ですね。マーケティングスキル、身に着けよう
今回、私が先輩たちに相談したときに真っ先に言われた
「誰のどんな悩みを解決するシステムなの？」についてですが、マーケティングの世界では頻繁に言われている言葉のようです。
誰のどんな問題を解決するのか | データベース・マーケティングの診断とその治療法 | コラム | マーケティングキャンパス
マーケティングとは何か？定義と基礎をわかりやすく！ | MarkeTRUNK
余談：基礎をわかりやすくまとめている記事。ありがたや。
【ブログ記事の書き方講座】記事を構成する要素をわかりやすくプロのブロガーが解説！｜hitodeblog
※余談：ブログ界のトップ層の1人であるヒトデさんのサイト。声が好きでいつもラジオを聞くのですが、ためになるWebマーケティングの話を非常に多くされています。
また、「システムの価値」を常に考えるということも、マーケティングで言われる「顧客に提供するベネフィットは何か？」と同じ話です。
「顧客は電動ドリルが欲しいのではなく、ドリルで開けた穴（＝ベネフィット）がほしいのだ」という有名なやつです。
このように、常に顧客を・ビジネスを考えて仕事をするためには、マーケティングの知識が必要そうですね。特に、事業会社のシステム担当は、今後避けて通れなそうですね。
まとめ
- システム部門だからこそ、要件定義のときは「お客さんのどんな悩みを解決する」ための仕事なのかを考えよう。
- システムのビジネス上の価値を作り出そう。正解のない問いを考え続けよう。
コツコツ自分の仕事をやるだけでなく、会社の利益を考えていけると仕事が楽しくなる気がします。マーケティングを一緒に勉強してくれる人は頑張りましょう。
ちなみに#画面の求めるものを理解した上で提案したものの章で提案したものが採用されたかどうかは、機会があれば続編を記載したいと思います。
