新規事業向けシステム開発の要件定義の極意 Part5【システム化の範囲を定める】〜【データ量を予測する】

前回に引き続き架空のシステム開発を例に、新規事業のシステム開発における発注者が行う要件定義の準備について解説していきます。

• 新規事業のためにシステム開発を行う
• システム開発で絶対に失敗したくない
• 発注者が要件定義の前に何をすべきかを知りたい

そんな方は、ぜひ最後までご覧ください！

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。


これまでにサービス内容の具現化と業務フローを決めるところまで解説しました。

今回は、「システム化の範囲を定める」「機能を考える」「サービスの利用者と行動パターンを推測する」「管理機能の利用者と利用タイミングを考える」「データ量を予測する」について解説します。

今回も過去の投稿と同様に、「フードコート座席順番待ちアプリ開発」を例に解説します。

システム化の範囲を定める

システム化の範囲を決める作業で行うことは、システムがどこまでの業務範囲を行うかを決めることです。今回の「フードコート座席順番待ちアプリ開発」のこれまでの解説において、サービス内容の具現化、業務の洗い出しの段階では、あえて範囲の明確化に拘る必要はないとしていました。最初から範囲を絞り過ぎると、いいアイデアであっても「これは範囲外だから」と言う理由で埋もれてしまう可能性を排除したかったからです。

しかし、開発に入るに当たっては、プロジェクトには予算も期限もありますから、おのずと範囲を決める必要があります。一方で、要件定義の準備段階ですから、余程開発経験が豊富でない限り、どこまで作ればどれだけコストがかかるのかなど分かりません。

よって、この段階で決めるべきは事業として・業務として必要な範囲を考えます。今回の例においてはサービスをこのように考えていました。

これについて、検討を深めたところ「外国人向け対応は不要」という結論となりました。実際、外国人観光客は多いのですが、データを分析してみると、外国人で且つ子連れのお客様は数パーセントに過ぎなかったのでした。そのために翻訳やサポートコストをかけるだけのメリットがないと判断し、当初は範囲から外すことにしました。

また、クーポンが利用できる店舗は日によって変わることを考えてたのですが、テナントのショップに話しをしたところ、子どもとは無関係なショップはこの企画に前向きではなく、参加するショップが限定されるため、ショップは日によって変える必要はないとのことから「クーポンが利用できる店舗は日によって変わる」というサービス要件は不要となりました。

機能を考える

アプリの機能を考えるにあたり、2つの視点が必要となります。1つは、当然ながらアプリの機能。そしてもう1つは管理機能です。

開発者側とすれば当たり前な考えですが、発注者側からすると世の中に存在するアプリは目に見えても、その裏側に何が隠れているか分かりません。アプリだけで処理が完結するような時計アプリ・計算機アプリのようなものでない限り、管理機能は必ず存在しています。発注者はこの管理機能に気が付かなかったために、予算オーバーなどに繋がることも少なくありません。

では、アプリの機能と管理機能はどのように考えるかというと、サービスの具現化で挙げた内容と、業務フローから導き出します。サービスはお客様に対するものであるのでアプリの機能、業務フローは管理機能と関連付けて考えます。

サービスを機能に置き換えるとこうなります。

この内容を機能面からまとめ直すとこうなります。

具現化したサービスが、アプリの機能としてまとまりました。次に管理機能を見てみます。管理機能では業務フロー図に着目します。業務フローのうち、どこをシステム化することで省力化・効率化できるのか、あるいはシステム化せざるを得ないのかを考えます。

今回のシステムでは業務として、お客様サポート業務、座席順番待ち管理業務、クーポン管理業務の3つの業務がありました。まず最初に、お客様サポート業務を見てみます。

サポート業務は電話を前提としていました。(→参照：新規事業向けシステム開発の要件定義の極意 Part4【業務フローの作成】業務フロー図の作成)
もちろん、電話だけではなくお問い合わせフォーム、SMS、さらにはAIチャットのような選択肢もありますが、解説を単純化させるために電話のみとしています。

ひとつひとつのプロセスを追っていくと「システムの会員の状況を参照」というプロセスがありました。これは、その後のサポートを行うにあたって、会員がシステム上どのような状態にあるのかを確認するものです。そのため、システム化をせざるを得ない部分です。

例えば、クレジットカードのサポートセンターに問い合わせしたことはあるでしょうか？最初に、名前、カード番号、住所、登録電話番号、誕生日などを聞かれます。それによって、本当の顧客かどうかを特定しています。クレジットカードのサポートセンターは実際に見たことはないのですが、その情報を聞きながら、システムで顧客情報を検索しているのは間違いありません。

システムに対するサポートでは、システムに登録されているお客様の情報を確認できる機能は、必ず必要なものだと思ってください。

更にプロセスを進めると「処理を代行」がありました。電話でサポートしているわけですから、実際に会員の端末を操作できないので、代わりに操作をする機能が必要なことが分かります。会員登録後の操作だと、ログインの代行は無いとして、「登録されている会員情報を参照する」「登録されている会員情報を変更する」「退会処理をする」が該当します。同様に、「順番待ちに関する問い合わせ」「クーポンに関する問い合わせ」でも代行処理があるはずです。

その後、FAQに未登録の場合、登録できるようにする機能も必要なことが分かります。このように業務フロー図を見ていくことで、管理機能に必要な機能が浮かび上がってきます。

さて、ここで大切なことをお伝えしておきます。もし、「こんな機能の洗い出しなんてできない」と思ったあなた。

いいんです。できなくても。完璧でなくても構いません。いまは要件定義ではなく、要件定義の準備作業をしています。

以前、要件定義では曖昧な表現はしてはいけないと述べましたが(→参照：新新規事業向けシステム開発の要件定義の極意 Part2【要件定義の重要性と、その具体的な準備方法】)、準備段階ですので、まだ曖昧さも残っています。この準備をもってして、開発するエンジニアと議論すればいいのです。

サービスの利用者と行動パターンを推測する

このサービスを利用する人がどんな人なのか、ペルソナを作成します。ペルソナの作成はマーケティング部門が担うかと思いますが、特に担当部門がない場合であれば、要件定義を担当している人がこのアプリを利用する人の仮想的な人物像を考えてください。

アプリを使うのは父親なのか、母親なのか？どれくらいの年齢？子どもは何人？子どもは何歳？この仮想的な人物像、つまりペルソナがどのように関係するのでしょうか。

最も分かりやすい例を挙げてみましょう。例えば、「ペルソナは50代の男性サラリーマン、通勤時間帯にスマホで情報収集をしている」と簡単に設定してみます。そしてその相手に対してアプリをこれから作るとした場合です。

20代、30代の開発者ならば見逃すかもしれませんが、50代ならば60％以上の人が老眼です。そうすると、文字サイズに配慮が必要ですし、文字サイズが大きくなることで1画面に表示できる要素も少なくなるため、若者向けアプリとはユーザインタフェースに一工夫が必要となってきます。

では、今回のアプリに当てはめてみます。利用者のペルソナとして、両親とも利用するが主に父親が使用。父親は30代前半のサラリーマン、子どもは2人おり、1歳と3歳。
(※ペルソナの作成目的によっては、さらに細かい設定が必要になりますが、今回はこの程度にしておきます。)

行動パターンとしては、週末・祝日の11時前後に来店→1時間くらいショップで買い物を済ませて→お昼近くにフードコートへ足を運ぶ。データを見ると、フードコートは11時50分から13時20分までがピークで常時満席、以降は並ばずとも座れるくらいの空きが出てくる。

管理機能の利用者と利用タイミングを考える

業務フロー図から機能を洗い出した際、座席案内完了機能が必要であることに気付きました。これまでの考えでは、出てこなかったものです。

しかし、座席の順番待ちをした会員の順番が来て、テーブルにどのように誘導するのだろうか？アプリでテーブルが指定され、自分で指定されたテーブルを使うという考え方もあるものの、最初は案内する人がいて、案内を終えたら座席案内の完了を行う必要があるということが分かりました。これによって、管理機能はオペレータだけが使う想定から、テーブルの案内係の人も利用者に含むことが分かったのです。

では、利用タイミングはどうでしょう？業務プロセスの作成の際、それぞれ次のようになっていました。

データ量を予測する

データ量を予測すると述べましたが、特別なことだと思わないでください。
「フードコート座席順番待ちアプリ開発」においては、一日の来店者数、フードコートの時間帯別の人数実績、今後の予想数、問い合わせがある時間帯、曜日別の予想問い合わせ数などのアプリの利用者、管理業務における業務量を予測しておきます。

新規事業の場合などは特に、実際にやってみなければ分からないことも多いでしょう。しかし、ピーク時の利用者数が2桁なのか、3桁、4桁なのかという数字はシステムを構築する際に重要な要素となります。

「ここは予想値に近いはず」、あるいは「予想は100だが、倍にブレる可能性も否定できない」などでも構いません。むしろ、どの数字の精度が高く、どれが精度が低いかを明確にしておいてください。

まとめ

新規事業のシステム開発における要件定義の前準備として、

• システム化の範囲を定める
• 機能を考える
• サービスの利用者と行動パターンを推測する
• 管理機能の利用者と利用タイミングを考える
• データ量を予測する

この5つについて、解説いたしました。

機能を考える部分など、難しいように考えられた方もいらっしゃるかもしれません。しかし、いまは要件定義ではなく、あくまで要件定義の準備作業です。準備段階ですので、曖昧さが残ったりして構いません。完璧である必要もありません。

それでもこの作業を行っておくことで、間違いなく要件定義がスムーズに進むようになりますので、心配無用です。

次回も、さらに詳しく要件定義の進め方について解説していきますのでぜひご覧ください。