要件定義のリスク管理-システム部門から営業部門に「できないこと」を伝えるコツ

2022/6/05

(最終更新: 2022/6/05

要件定義のリスク管理-システム部門から営業部門に「できないこと」を伝えるコツ

はじめに

システム部門のメンバーの必須スキル

システム部門以外の人たちに、開発内容を理解してもらうこと!!

について、最近教えてもらったことを語ります。

システムの仕様を知らない営業部門メンバーと、「何を開発し、何を開発しない」を決めるのは、想像以上に大変です。

携わっているプロジェクトで、システム開発スコープの明確化と、営業部門との意識合わせに参加した際、プレゼンの達人にたくさんのアドバイスをもらったので、

システム部門から営業部門に「できないこと」を伝える心構えとコツを記録します。

結論としては、大事な点は、以下の2点になります。

心構え

理解してもらえない説明は、説明してないのと同じ

コツ

  • これまでと何が変わるのかを明確にする。
  • できないことよりできることを強調する。

なぜ「できないこと」を伝える必要があるのか

システム開発は、たいてい営業部門や企画部門の「これをやりたい!」から始まります。

ただ、実際にシステム仕様に落とし込むとなると、「どこまでやるの?」が課題になります。

情報粒度のイメージ 情報粒度のイメージ

システム部門は、お客様満足度と開発費のちょうどよい塩梅を見つけて、開発スコープを決めないといけません。 営業部門からの

ふわっとした要求を明確な開発スコープに落とし込み、合意するプロセス

が必要です。

開発費とお客様満足度

システム部門から営業部門に、「できないこと」を伝える難しさ

何ができて、何ができないか、を伝えることは、システムの世界ではとても難しいです。

実際の例を使って話そうと思います。自分の会社の例を出すわけにはいかないので、設定は大幅に変えていますが、イメージは伝わると思います。

Amazon の購入時、「一定の条件」を満たせば配送料が無料になります。

このとき -¥410  を画面に表示したいとします。

営業部門からの要求:「配送料無料の人には、配送料の割引額を画面に表示してよ!」

Amazon の画面でたとえるとこんな感じ Amazonの画面でたとえる

システムが複雑すぎる

大規模で歴史の長いシステムの場合、「一定の条件」がものすごく複雑です。

  • 配送料無料にも種類がいろいろある
    • お急ぎ便の追加料金だけが無料になる
    • 配送料自体が 0 円になる
  • 無料にする条件が以下のように 100 個ある
    • 買ったものが本以外
    • 小学生以下
    • 10%オフキャンペーンを使ったことが無い
    • 商品サービスコードが"A"で始まるものは対象外
    • ・・・
  • 100 個すべての判定ロジックを把握している人は誰もいない(設計書を漁るしかない)
  • 100 個のうち 70 個は、昔作ってそのままになっているだけで今は使っていない
  • 配送料が発生しないような注文だったら、値引きはしない(=配送料が発生するかどうか/配送料がいくらになるのかも判定しないといけない)
  • 通常は配送料 410 円だが、離島など一部の人は配送料 910 円の場合もある。どちらにしても条件に当てはまれば配送料は無料になる。

などなど。

また、システム開発を依頼してきた「営業部門」と「配送料無料の条件を決める部門」は全然別のメンバーということもポイントです。

「営業部門」と「配送料無料の条件を決める部門」

システム制約も複雑になる

システム部門で話し合って、

  • 30 個の条件は、ちゃんと判定しないとお客さんに誤解を与えるデメリットが大きいからお金をかけて調査して、判定機能を作ろう。
  • 使っていない 70 個の条件は判定ロジックは作らないでおこう。
  • 小学生以下の条件について。お客さんの年齢は取得できるが、小学生かどうかは注文確定するまで取得できないから、12 歳以下かどうかで判定しよう。
  • 離島の人は判定ロジックの難易度が高く、コストに見合わないから対象外とする方向で相談しよう。

となったとします。

これを馬鹿正直に説明しようとするとどうなるかというと…

使ってない 70 個の条件は判定ロジックは作らないでおこう。

  • 商品サービスコードが"A"で始まるものかどうかは判定しません。
  • 10%オフキャンペーンを使った履歴は 2018 年以降のものしかないので、2018 年以前は判定できません。
  • ・・・これが 70 個続く

小学生以下の条件について。お客さんの年齢は取得できるが、小学生かどうかは注文確定するまで取得できないから、12 歳以下かどうかで判定しよう。

  • 小学生以下の条件がありますが、12 歳以下かどうかで判定します。

離島の人は判定ロジックの難易度が高く、コストに見合わないから対象外とする方向で相談しよう。

  • 地域コードが XX,YY,ZZ の人(離島の人)は配送料が無料になるかを計算できません。

繰り返しになりますが、営業部門の人は配送料のビジネス仕様は全く知りません。ポカンとされること間違いなし。。。

システム制約を伝えるコツ

心構え:理解されなければ伝えていないのと同じ

当たり前やろ!と言われそうですが、複雑な既存システム仕様調査をやりすぎて、頭がシステム一色になっていると忘れがちです。

わからない説明をされて「全然わかりません!」と言ってくれる人は、少ないです。

もちろん上司とか教育係であればしっかり指摘してくれますが。他の部署の人の場合、ほとんどの人は、何も言ってくれず、会議が盛り上がらずに終わります。

結果、リリース後に問題が起こったときに

「聞いてない!!!!」

「事前に言ったじゃないか!!!」

ともめることが容易に予想されます。これでは伝えてないのと同じです…。

ということで、システムの中身を知らない人にも「できること」「できないこと」を伝えて、合意まで取り付ける必要があります。

コツ ①:これまでと何が変わるのかを明確にする

初めに、私が最初に作った悪い例を示します。(あくまでイメージ)。

悪い例(1枚目) 悪い例① 悪い例(2 枚目) 悪い例②

プレゼンの達人のコメント

  • 今より良くなるのか悪くなるのかわからない。
  • やらないことが、どれくらい困るものなのかがわからない。

仮に、今すでに別のシステムを使って配送料無料かどうかを判定していて、何らかの理由で別のシステムでの判定に変える場合は、明確に旧システムとの差分が制約事項(できないこと)になります。

別のシステムでの判定に変える場合

一方で、今回のように今できていないものができるようになるのであれば、ベースとなるものは特にありません。つまり、「今より悪くなること」は基本的にありません。

今できていないものができるようになる

このときは、「これはできるけど、これはできません」という言いかたではなく、

こんなことができるようになります。 ただし、利用上の注意があります。これとこれとこれです。

というポジティブな言葉で伝えると良いです。

薬に例えると以下のような感じです。

  • この薬は、腹痛を直します。
  • ただし、副作用があります。熱が出るかも。(利用上の注意 ①)
  • ○○ の薬とは一緒に飲まないでください。(利用上の注意 ②)

これらを踏まえ、以下のように修正しました。(イメージ)

修正後スライド 修正後スライド

色々考え、すっきり 1 枚にまとめました。

今はできていないことができるようになることが一目でわかるようになりました。

また、やらない事実を書くのではなく、利用する上で注意することを明示しました。

コツ ②:できないことよりできることを強調する。

悪い例の再掲です。

悪い例(2 枚目) 悪い例②

これでも、「できないことだけにならないように、しっかりできることは主張しよう」と思って書いています。。

プレゼンの達人のコメント

  • やることとやらないことがイーブンに見える。
  • できません!→ 困る!→ 無駄にスコープが増える。ということをやりたいわけじゃないよね?

システム部門としても、1 ヶ月くらい、果てのない現行システムの仕様調査を行ない、パートナーに向けて要件定義を書いて、試験して・・と大変な思いをして作り上げる機能です。

「これくらいしかできませんよ」とあえて小さく言う必要は無く、「すごいことができるんだ!」という内容を強調するほうが良いです。

できること8割、できないこと2割の割合を意識します。

そこで、改めて、やることとやらないことの本質を整理すると、以下のようになりました。

やることとやらないことの整理

  • そもそも、判定条件を何個やるか、はシステムの話。使っていない 70 個の条件を判定しようがしまいが、お客さまには影響しないので 言う必要なしと判断。
  • 離島に対応するかは誰にも約束しておらず、勝手に自分で日本全国に範囲を広げていただけなので、「本島」にスコープを絞って宣言する。(少し例が悪くて暴論のようになっていますが、実際はもっと常識的なスコープの絞り方をしています)
  • 配送料が発生しない人にも割引額が表示されてしまうのは、お客さまからのクレームにつながる可能性もあるので、しっかりと合意しておく。

結果、1 枚にまとめた状態になりました。

修正後スライド(再掲) 修正後スライド

伝えた結果どうなったか?

営業部部門に、こちらのスライドをもとに説明しました!

  • 伝わっているかどうか?⇒ 相手の顔であったり、質問がちゃんと出たことから、ある程度伝わったと感じました。
  • 利用上の注意(配送料が発生しない人にも割引額が表示されてしまう)についてはかなり引っかかったようで、誤解を与えないようにどうしていくか、が継続協議になりました。

私は画面システムの担当ではなく、判定するシステム側(修正後スライドの「今回作成」の部分)の担当なので、営業部門と話すのは初めてでした。 業務部門とのやりとりを経験することができて、自信につながりました。

伝える時期が遅かったかも

今回は、開発が佳境を迎えた時期(今から大幅な仕様変更は難しい)時期にこの説明を実施しました。ここで「いや、これじゃ困るよ!」と言われても、方針の大幅変更は難しい状況です。

本来であれば予算や納期を決める段階でこの話ができれば、「これじゃ困る」意見はしっかりとスコープに組み込むことができたと思います。

ただ、実態としては現行システム調査や、具体的な設計をすべてやりきってから予算・納期を決めるなんてことはあり得ないので、今回のような進め方になるケースが多いです。ある意味腕の見せ所だと思います。

一般的には、大きな方針は早めに、細かい方針は具体的な調査が終わってから…と、情報を小分けにしていくべきです。

まとめ

この記事では、システム部門として営業部門にシステム開発で「やること」「やらないこと」を伝えるコツを、体験談をもとに記載しました。

  • これまでと何が変わるのかを明確にする。
  • できないことよりできることを強調する。

システム部門の中だけでなく、今後も機会を見つけて営業部門や企画部門の人と関わっていきたいです。



個別連絡はこちらへ→Twitterお問い合わせ

プロフィール

プロフィールイメージ

はち子

事業会社のシステム部門で働きはじめて5年目の会社員。システム企画/要件定義/システムアーキテクチャ等。

Twitter→@bun_sugi

過去の記事について

はてなブログに掲載の記事(主にプログラミングメモ)についてはこちらに掲載しております。(本ブログに移行中)

タグ一覧

関連記事

Copyright© 2023, エンジニアを目指す日常ブログ

お問い合わせ|プライバシーポリシー