新規事業の要件定義、何から手をつけるか
――存在しない業務は、こう生み出す
「既存業務のヒアリングが」出発点にならない現場
要件定義のヒアリングでは、既存業務のヒアリングが出発点になることがよくあります。
現在の業務フローを聞き、そこにある課題を洗い出し、改善すべき点を明らかにしていく。これは、王道と言えるアプローチです。
しかし、この前提がまったく通用しない現場があります。
それは、新規事業の要件定義です。
私自身、ベンチャー企業に関わる仕事を多く経験してきましたが、Webシステムの開発は、そのほとんどが、新規事業に紐づくケースでした。そして、新規事業の要件定義には、既存業務のヒアリングとは異なる、独特の難しさがあります。
今回は、この「既存業務がない」という状況で、要件定義をどう進めればよいのかを整理します。
2つのパターン
新規事業の要件定義には、大きく分けて2つのパターンがあります。
ひとつは、既存業務が「手作業」で存在しているケースです。たとえば、これまでExcelや紙の帳票で回していた業務を、システム化するというケースです。この場合、業務そのものは存在しているので、これは既存システムのリプレイスに同じと考えていいでしょう。これまでお伝えしてきた内容の多くは、このパターンに当てはまります。
もうひとつは、既存業務そのものが「存在しない」ケースです。これまで誰も行ったことのない、まったく新しい事業やサービスを立ち上げるとき、その業務プロセスは、これから作られるものです。今回、特に取り上げたいのは、こちらのパターンです。
業務が存在しないと、何が起きるか
既存業務が存在しない場合、要件定義のアプローチは、根本的に変わります。
通常のヒアリングでは、「現在、どういう手順で仕事をしていますか」と尋ねることで、業務フローが浮かび上がってきます。しかし、業務そのものが存在しなければ、この問いは成立しません。聞く相手も、答えようがないのです。
このとき、SEに求められるのは、「聞く」ことではなく「作る」ことです。顧客の頭の中にある、まだ形になっていない事業の構想から、業務フローを一緒に組み立てていく作業が必要になります。
これは、簡単な作業ではありません。参考にできる「既存業務」がないため、SE自身が、その事業がどのように回るのかを、ある程度想像しながら、顧客と対話していく必要があります。
デメリット：業務を想像するのは、難しい
既存業務が存在しないことに対する最大のデメリットは、業務を想像すること自体が難しいという点です。
既存業務のヒアリングであれば、実際に業務をこなしている人に話を聞き、場合によっては現場を見せてもらうこともできます。目の前で行われている作業を観察し、そこから要件を引き出すことができます。
しかし、新規事業では、この「見て確認する」というプロセスがそもそも存在しません。顧客自身も、事業がどう回るのか、完全にはイメージできていないことが少なくありません。「こういうサービスをやりたい」という構想はあっても、「では、注文が入ってから商品が届くまで、具体的にどういう業務が発生するか」という細部までは、まだ考えられていないことが多いのです。
このとき、SEが業務フローを一緒に作ろうとすると、想像力に頼らざるを得ない部分が出てきます。似たような業種の一般的な業務フローを参考にしたり、顧客と一緒に「もし注文が入ったら、次に何が起きますか」と、ひとつずつ具体的な場面を想定しながら組み立てていく必要があります。
この作業は、既存業務のヒアリングに比べて、精度が出しにくいものです。しかし、それほど複雑な事業でない場合、逆に時間がかからないこともあります。参考にすべき既存の業務が存在しない分、確認や調整のプロセスが少なく済むためです。とはいえ、「実際に運用してみたら、想定していなかった業務が次々に出てきた」ということも、珍しくありません。
メリット：優先順位を、大胆につけやすい
一方で、既存業務が存在しないことには、メリットもあります。それは、優先順位を大胆につけやすい、という点です。
既存業務のシステム化では、「今の業務を、そのまま踏襲してほしい」という要望が、しばしば出てきます。長年その方法で回してきた業務には、それなりの理由や、関係者の慣れがあります。そのため、システムを刷新する際にも、「この機能は絶対に外せない」という、既存の運用に紐づいた制約が数多く出てきます。
しかし、新規事業には、こうした過去のしがらみがありません。「今までこうだったから」という前例が存在しないため、本当に必要な機能だけに絞り込みやすいのです。
これは、要件定義において、非常に大きなアドバンテージになります。優先順位をつける作業は、既存の業務や慣習に引きずられず、ゼロベースで「この事業にとって、本当に必要なものは何か」を問い直せるときに、もっとも効果的に機能します。
新規事業の要件定義では、まず最小限の機能でスタートし、事業を回しながら段階的に機能を追加していく、という進め方がしやすくなります。これは、既存業務がないからこそ実現できる身軽さです。
(補足:既存業務のシステム化において、「今の業務を、そのまま踏襲してほしい」という要望に、そのまま応えることが、必ずしも正しいとは限りません。DX(デジタルトランスフォーメーション)の観点から見れば、既存業務をそのままシステム化することは、非効率なプロセスをそのまま温存してしまうことにもなりかねません。業務のやり方自体を見直す好機を、みすみす逃してしまう可能性があるのです。
この点は、新規事業とは別のテーマになりますが、既存業務のヒアリングにおいても、「今のやり方を、そのまま再現すること」がゴールではない、ということは、心に留めておく必要があります。)
見落としてはならない、連携の視点
ここで、ひとつ注意しておきたいことがあります。新規事業だからといって、他システムとの連携を軽視してはいけない、という点です。
「新しい事業だから、真っさらな状態から作れる」と考えると、つい、その事業単体で完結するシステムを想定しがちです。しかし、実際には、新規事業であっても、既存の基幹システムや、会計システム、顧客管理システムなど、何らかの形で他のシステムと連携する必要があるケースがほとんどです。
たとえば、新規事業で発生した売上データは、最終的に会社全体の会計システムに取り込まれる必要があります。新規事業で獲得した顧客情報は、既存の顧客管理システムと統合される必要があるかもしれません。新規事業だからといって、これらの連携が不要になるわけではありません。
既存業務が存在しないという状況に気を取られていると、「この事業は新しいから、既存のシステムとは関係ない」という思い込みが生まれやすくなります。しかし、事業は独立して存在しているわけではなく、多くの場合、既存の組織や業務プロセスの一部として動いています。連携の可能性を、最初から視野に入れてヒアリングを設計することが重要です。
具体的には、「この事業のデータは、最終的にどこで、誰が、どう使いますか」という問いを、早い段階で立てておくことをお勧めします。この問いに答えていく中で、想定していなかった連携の必要性が見えてくることがあります。
私自身、こんな経験があります。デジタルコンテンツを販売するWebサイトを構築したときのことです。最初のスコープでは、決済は独立した機能として設計する予定でした。事業自体が新規のものだったため、決済処理もその事業単体で完結させる想定だったのです。
しかし、要件定義が終わりに近づいたころ、これまで関わっていなかった他部門が、急遽プロジェクトに参画することになりました。すると、決済情報を基幹システムと連動させる必要があることが分かり、スコープが大きく広がりました。
このとき痛感したのは、これは単なる「連携漏れ」の問題ではなく、ステークホルダー分析の問題でもあった、ということです。プロジェクトの初期段階で、決済情報を必要とする他部門が、ステークホルダーとして視野に入っていなかった。そのため、その部門が持つ要求も、当然ヒアリングの対象になっていませんでした。新規事業だからといって、関係者が事業単体で完結しているとは限りません。事業が形になっていく過程で、後から関わってくる部門が現れることもあるのです。
この経験から、新規事業のヒアリングであっても、「今、目の前にいる担当者」だけでなく、「将来、この事業に関わってくる可能性がある部門は他にないか」を、プロジェクトの節目ごとに問い直すようにしています。
想像力を鍛えるために、できること
既存業務が存在しない中で、業務を想像しながら組み立てていくという作業は、経験によってある程度鍛えられるスキルです。
私自身、いくつかの新規事業のシステム開発に関わる中で、意識してきたことがあります。似たような業種、似たような事業モデルの、既存の業務フローを、あらかじめ知っておくことです。まったく同じ事業ではなくても、「注文を受けてから商品を届けるまでの一般的な流れ」「顧客からの問い合わせに対応する一般的な流れ」といった、業種を超えて共通する業務パターンを知っておくと、新規事業の業務フローを組み立てる際の土台になります。
また、顧客との対話の中で、「もし、この場面でこういうことが起きたら、どう対応しますか」という、仮説に基づいた問いを重ねることも有効です。「なぜ」を聞く質問や、「他の人だったら」を想像させる質問は、既存業務が存在しない場面でも応用できます。「まだ実際には起きていないけれど、こういうケースが発生したら、どうしたいですか」という仮定の質問を重ねることで、顧客自身の頭の中にある構想を、少しずつ具体化していくことができます。
まとめ
新規事業の要件定義には、既存業務のヒアリングとは異なる難しさがあります。既存業務が手作業で存在するケースと、そもそも存在しないケースがあり、後者では「聞く」のではなく「一緒に作る」というアプローチが必要になります。
既存業務が存在しないことには、業務を想像することが難しいというデメリットがある一方で、過去のしがらみがない分、優先順位を大胆につけやすいというメリットもあります。なお、既存業務がある場合でも、それをそのまま踏襲することが常に正しいとは限りません。DXの観点から、業務そのものを見直す視点も忘れないようにしたいところです。
そして、新規事業であっても、他システムとの連携を見落としてはなりません。「新しい事業だから、既存のシステムとは関係ない」という思い込みは、後になって大きな手戻りを生む原因になります。「このデータは、最終的にどこで、誰が使うのか」という問いを、早い段階で立てておくことが重要です。また、スコープは後から広がることがあり、それはステークホルダー分析が不十分だったサインであることも少なくありません。