ビジネス上の価値がない業務システムは無駄
業務システムの新規開発やリプレースを実施するのにあたっては、ユーザーから現在の業務フローや必要な機能、不満点などをヒアリングして実際の機能に落とし込む「要求定義」と呼ばれる工程が実施されます。
しかしながら、定義された要求を闇雲に設計・実装していっても、その業務の売上高や利益の増加が見込めなかったり、結果として使いづらい UI／UX になってしまいがちです。そもそも業務システムの開発は投資活動であるため、開発・運用コスト以上に売上高や利益を押し上げるビジネス上の価値がなければ「真に役立つ業務システム」とは呼べません。
このようなズレは「ユーザーの意見は正しいから、彼らの要求を聞いて仕様を決めればよい」という受け身の姿勢から発生します。そもそもユーザーは自身の把握している範囲の業務フローや不満点からのジャストアイデアは出せますが、業務全体の効率化や新しい価値を生み出す方法について理解しているわけではありません。
真に役立つ業務システムを開発するためには、業務分析をしながら正しい要求をユーザーと共に「開発」していくスキルとマインドセットが必要となります。このようなニーズの高まりに対して、日本においては要求開発アライアンスが発足しており、世界に目を向けると、NPO法人 iiBA から BABOK と呼ばれる知識体系が発行されています。
要求開発とBABOKは厳密には異なる概念ですが、それらが目指すところは同じです。そこで今回は BABOK を読み解きながら、真に役立つ業務システムを実現するためニーズを引き出す方法についてご紹介します。
BABOKの定義と知識体系
BABOK とは Business Analysis Body Of Knowledge の略でNPO法人 IIBA が発行するビジネスアナリシス（業務分析）を行うための知識体系をまとめたものです。時代とともに改訂を重ねており、最新版は BABOK V3 となります。NPO法人 IIBA による「ビジネスアナリシス」の定義は以下の通りです。
ビジネスアナリシスは、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動である。
カタカナ語だらけで少しわかりづらいので、それぞれの定義を確認しましょう。
| 用語 | 意味 |
|---|---|
| ニーズ | 対処すべき問題または機会 |
| ステークホルダー | チェンジ、ニーズ、ソリューションと関係を持つ個人またはグループ |
| 価値 | あるコンテキストにおける、ステークホルダーに対する値打ち、重要性、有用性 |
| ソリューション | あるコンテキストにおいて、一つ以上のニーズを満たす具体的な方法 |
| チェンジ | ニーズに対応して変える行為 |
これを言い換えると以下のようになります。
| ビジネスアナリシスは、対処すべき問題または機会を定義し、関係各位に価値を提供する具体的な方法を推奨することにより、エンタープライズ（企業）によい変化を引き起こすことを可能にする専門活動である。 |
つまり、企業をあるべき姿に変化させるためには、問題を定義して関係者に価値を提供する具体的な方法を推奨するためのビジネスアナリシスが必要になるということです。
参照：iiBA日本支部「BA（Business Analysis）とは」
ステークホルダー要求とニーズは異なる
BABOK V3 ではビジネスアナリシスの各段階について以下の6つの知識体系が定義されています。
- ビジネスアナリシスの計画とモニタリング
- 引き出しとコラボレーション
- 要求のライフサイクル・マネジメント
- 戦略アナリシス
- 要求アナリシスとデザイン定義
- ソリューション評価
このうち、要求開発にまつわるのは「引き出しとコラボレーション」「要求のライフサイクル・マネジメント」「要求アナリシスとデザイン定義」の3つとなります。「引き出し」という言葉は耳慣れないかと思いますが、この言葉にはユーザー自身が気がついてないような潜在的なニーズを引き出して新しい価値を開発していくというマインドセットが表現されています。
ここで大切なのは、関係各位からの要求がすなわちニーズ（対処すべき問題または機会）とは限らないことです。ヒアリングの中で出てきた要望は「ステークホルダー要求」と呼ばれ、ビジネスアナリシスへの重要なヒントにはなるのですが、それを闇雲に目指すだけでは「あるべき姿」に変化させることはできません。具体的には下表の引き出し活動を行います。
| 引き出し活動 | 概要 |
|---|---|
| 協働型 | ステークホルダーへのインタビューやブレストなどを行ってニーズを引き出す |
| 研究型 | ステークホルダーが直接には認知していない資料または情報源の調査を通じて、潜在的なニーズを引き出す |
| 実験型 | プロトタイプやモニタリングを用いて暗黙知的なニーズを引き出す |
これまでの業務システム開発においては「協働型」の範囲で定義された要求を実装すれば十分だというマーケットインの発想で完結しがちでしたが、真に役立つ業務システムを構築するためには「研究型」「実験型」の引き出し活動によって、潜在的なニーズを引き出すプロダクトアウトの発想が必要となります。
例えば、現代の業務システムは膨大な監査ログの出力や履歴データの保存が義務付けられており、それらを分析するための基盤を比較的安価に用意できる技術も整っています。ログ分析やA/Bテストの活用によって、これまで暗黙知となっていたベストプラクティス、バッドノウハウ、利用されていない機能などを焙り出して、ユーザーからのヒアリングだけでは顕在化できなかった潜在ニーズを引き出して提案していくことが可能となります。
価値に基づいてソリューションスコープを策定する
ニーズを明確にしたとしても、それを実現するための具体的な解決策が明らかにならなければ絵に描いた餅となってしまいます。BABOKでは具体的なシステム設計手法や実装方法についてまで触れらていませんが、システム担当者としては腕の見せ所となります。
とはいえ、現実に使えるプロジェクトリソースは限られているため、適切な優先順位を決めてソリューションの範囲を決定する必要があります。優先順位を判断するために必要となる指標は「価値」です。ここで、NPO法人 iiBA による「ビジネスアナリシス」の定義をおさらいしましょう。
ビジネスアナリシスは、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動である。
ソリューションはステークホルダーに価値を提供するためにあります。価値の定義はステークホルダーによって異なりますが、第一に優先すべきは企業利益でしょう。企業利益を最大化するための観点は以下の通りです。
- 売上をあげる
- コストを減らす
- リスクを減らす
業務システムの改善による売上増加やコスト削減については、ビジネスインパクトへの理解を得やすいのですが、情報漏えいやシステムダウンなどのリスクを減らすための非機能要件的なニーズについても「想定被害金額ｘ発生確率」による定量試算を行って優先順位の俎上に乗せるべきです。
真に役立つ業務システムを開発するために
いかがでしたが、今回は BABOK のなかからニーズの「引き出し」を中心にご紹介しました。業務システム開発においては、ユーザーからでてきた要求を「正解」とみなして、そのまま開発タスクに落とし込んでいくと、互いに矛盾するような仕様になってしまったり、一部のユーザーのために大きな工数を消化してしまったりという問題が発生しがちです。
業務システム開発は投資活動であり、そのリターンは「価値」をもたらす変化です。有限なリソースを活用しながら、潜在ニーズを主体的に引き出してソリューションに落とし込むのは大変な作業ですが、同時にやり甲斐があるものと考えています。
ビジネスアナリシスについて個々の技術者が経験から学んでいくのには長い年月が必要でしたが、BABOKという知識体系に触れることで、「知の高速道路」に乗ることができます。これを機会に BABOK を手にとっていたいただけたら幸いです。
参照：フリーランスのITエンジニアとして長く活躍するコツを解説した記事はこちら
イラスト：ゆずりは さとし
この記事の著者
by 池田仮名
ITエンジニア／ブロガー
個人ブログ「太陽がまぶしかったから」を運営。
Twitter｜@bulldra
ブログ｜太陽がまぶしかったから
