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