ビジネス
2018.03.12
要件定義を作る際の考え方とは。目的と手段をしっかりと見極めよう
新たなシステムを導入したけど、ぜんぜん活用されない。
また、ホームページを新たにリニューアルしたけど運用してみるとリニューアルの目的がそれほど満たされた感じがしない。
このような不満の多くは始めの要件定義が曖昧で失敗してるケースが多いです。
要件定義は発注側と開発側が同じ目的に沿って、プロジェクトを進める言わば羅針盤。
そろぞれ関係スタッフが同じ地図を持っていても向かう羅針盤の方角が少しでも違っていれば、開発時の判断に間違ったジャッジを行ってしまう可能性は否めません。
そこで今回は要件定義を作る際の考えかたを紹介したいと思います。
Contents
まずはじめに経営レベルで要件を整理してみましょう。
【経営レベル】
経営戦略としてどのような課題を解決したいのか？
■営業対応のスピード向上。
■顧客単価の拡大。
■顧客数の拡大。
■営業活動の効率化。
■販売機会ロスを無くす。
などなど
【業務レベル】
経営レベルの課題を克復するためには日常の業務レベルではどのような改善が効果的なのか？
■情報・ノウハウの共有化
■営業の属人化をなくし、組織的な営業体制に変える。
■営業マンの教育体制の強化。
■価格設定の見直し、商材の中身を見直す。
などなど
【仕組みレベル】
社内で定着させるにはどのような業務ルーチンに落とし込めば良いのか？
■商談内容のデータ共有。
■定期的な研修会を設ける。
■見積もり業務の効率化。
■シュミレーターなど商談ツールの開発。
などなど
【システムレベル】
業務ルーチンに合わせた経営課題をどのように具体的にシステム化するのか？
■どのような機能が必要なのか。
■どのようなデータを活用すべきか。
■どのようにアラートを発するべきか。
■どこまで単純化するべきなのか。
業務レベルでの要件が整理出来れば、今度は要件定義で必要な5つの定義項目に落とし込んでみましょう。
【1】システム化方針・リニューアル方針
どのような経営レベル・業務レベル上での課題を解決するためにシステム化・サイトリニューアルを行うのか。
システム化・サイトリニューアルの背景や目的、期待する効果などを示します。
例えば、それが販売機会ロスを無くすため、営業の対応スピードを向上させる事だったとします。
【2】解決すべき課題
現状の業務レベルで解決すべき課題に落とし込みます。
顧客の製品選びをスムーズにする事。
代替商品の即時提案が行える事。
デモンストレーションをその場で迅速に行える事。
消耗品の買い替え時期の把握。
などなど。
【3】課題の解決策
業務ルーチンを見直し、どのような業務を行うことで課題が解決するのか？
ケースバイケースによる製品選びを手助けするツールの開発。
代替品や適合オプション品の紐づけや関連付けを行う。
営業ツールとしてのデモ機の開発。
商品消費サイクルのデータ化。
などなど
【4】新しい業務の仕組み
経営課題を解決するためにはどのような業務ルーチンが必要なのか
また、どのような業務機能があれば経営課題が解決されるのか。
運用方法や、オペレーション、ルールなど。
例えばタブレットによるシミュレーション端末の開発。
営業フォロー対象の見える化。
などなど
【5】システム要件
新たな業務の仕組みを導入するためにどのようなシステムの機能、操作、端末が必要なのか？
データの入力方法、表示方法、データの関連付けのルールなど。
具体的なシステムの有り様を考えます。
目的思考で考えてみる。
目的思考とは物事の本質を見抜いて考える思考法です。
良くある例で例えるとホームページのリニューアル目的がアクセス数のアップだと経営幹部から言われたWEB担当者さん。
それって手段じゃないでしょうか？
本当の目的は広く我が社の製品を知ってもらうこと。
もっと言えば引き合いを増やす事。
さらにもっと言えば会社の売上を上げることがそもそもの目的。
アクセスが増えたから目的達成ではないんです。
また、展示会に出展して新規営業先のリストを増やしたのは良いけれど、その後、営業部門で上手くリストを活用されてないみたいな事ありますよね。
これもリストを集めるのが目的ではなく、新規顧客を発掘する事が目的です。
新規営業先リストを集めるのはその手段でしかありません。
デザイン思考で考えてみる。
デザイン思考はデザインを考える訳ではございません。
問題の本質を追求し、その課題解決策を再定義してみる事。
ん？やっぱり分かりにくい。
例えると、自社で取り扱っている商品の価格競争が厳しく、利益が薄くなってきている。
もっと仕入れ価格を抑えることが出来ないかと上司に言われたとします。
あなたは仕入れ価格を抑える方法を試行錯誤しますよね。
利益が薄いのなら量販店に下ろすのではなく、直販で利益を上げるはどうでしょうか？
もしくは付加価値をつけて、価格競争にならない方法を考えるべきでは。
利益が薄いのはそもそも価格競争に巻き込まれているからです。
これこそが問題の本質。
その問題を解決しないことには、周りの問題をいくら解決してもダメなんです。
これがデザイン思考なんです。
本当に解決すべき事は何か。
そしてその問題解決に今の行っている手段は必要な事なのか？
問題を俯瞰的に見ることと、様々なシュミレーションを考えてみる事が重要です。
なぜ、目的が果たせないのか。
なぜ、導入したシステムが上手く活用出来ないのか？
また、なぜ公開されたWEBサイトが活用出来ないのか？
皆さんはここまで読まれるともう分かりましたよね。
プロジェクトを進めるにあたって、いつの間にやら、「目的」が「手段・手法」にすり替わる事が原因です。
その他にも結局データが中々更新されないとか、入力されたデータに不備があるとか様々な問題が起き得る事も考慮する必要があります。
システム化したけど結局使い勝手が悪いとか効率化の成果が出ないって場合は概ね、開発段階でルール化の徹底が出来ていなかったり、社内業務との親和性、作業負担などの考慮が甘かったり、後々になって希望する機能の実装の技術的難易度とコストが合わなかったりするケースも多いですよね。
プロジェクトメンバーが本当の目的を見失わないよう、またその課題を解決するための根本的な問題とはをしっかり把握し、要件定義を煮詰めて、本当の課題解決をいたしましょう。