---
title: "【b→dash #06】半年後に差が出る、非エンジニアのための要件定義３つのポイント"
description: b→dashの導入・運用に対してお悩みをお持ちのマーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。
image: https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2306.jpg
---

 7月 29, 2024 [ umbrElla編集長 ](https://umbr-ella.jp/ja/blog/author/about-執筆者umbrella編集長)

# 【b→dash #06】半年後に差が出る、非エンジニアのための要件定義３つのポイント

[b→dash](https://umbr-ella.jp/ja/blog/tag/bdash)

![Picture of umbrElla編集長](https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2306.jpg)

##### Share

- [** ](https://www.linkedin.com/shareArticle?mini=true&url={url}&title={title})
- [** ](https://www.facebook.com/sharer.php?u={url})
- [** ](https://twitter.com/intent/tweet?url={url}&text={title})

b→dashの導入・運用に対してお悩みをお持ちの  マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。

 

| ABOUT 執筆者：umbrElla編集長 累計50社以上のb→dashプロジェクトを支援。クライアントは、金融・不動産・アパレル・食品・スポーツ球団・化粧品・人材・店舗ビジネスなど業界業種を問わず、企業規模も創業まもないベンチャー企業から大手上場企業まで幅広く担当。多種多様な観点からの助言や、豊富な経験をもとに先回りした提案を強みに、b→dash初心者がつまずきがちなポイントを強力にサポートしています。 |
| --- |

 

第6回は、非エンジニアのマーケターのための『半年後に差が出る 要件定義*３つのポイント』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。  
*要件定義：システム開発などのプロジェクトを始める前の段階で、必要な機能や要求をわかりやすくまとめていく作業のこと

 

|   b→dashのことならumbrEllaへ！   多くのSaaSサービスが 「簡単」「誰でも使える」ことを謳っていますが、 確かに”使うだけ”なら問題ないでしょう。 ただ、多くのSaaSサービスにおいては 「そういうことは先に言ってよ～」 ということが プロジェクトを進める中で沢山でてきます。 そういった「共通する失敗」を避けるためには 信頼できるパートナーが必要不可欠です。 「代理店に頼むと高いしな...」 「とはいえ、社内に適任者もいない...」 「誰に頼んだらいいかわからない…」 このようなお悩みをお持ちの方は、 まずはお気軽にumbrEllaへ無料相談してみてください。   とりあえず無料相談してみる   |
| --- |

 

 

非エンジニアであるマーケターのための半年後に差が出る要件定義のポイントを解説するにあたり、そもそも「要件定義」という非エンジニアにとって聞きなれない言葉について説明していきたいと思います。※ここでは、一般的なシステム開発ほどの高度な要件定義には言及せず、あくまでb→dashにおいて必要な最低限度の要件定義についてお伝えします。

私も完全未経験からb→dashの世界に飛び込んだ際に、この「要件定義」なる取り組みには本当に手を焼きました。基本的に、b→dashにおける要件定義は以下の流れで進みます。  
１．要求の確認  
２．課題や目的の明確化  
３．アウトプットイメージの明確化  
４．機能要件定義  
５．非機能要件定義  
６．要件定義書の作成  
７．（データ設計）

まず、「要件」と「要求」の違いを簡単にお伝えすると、後者（要求）は「こういうことがしたい」という抽象度の高いビジネス上の目的を端的に表したもので、前者（要件）は「要求を充たすために必要となる条件」を表します。従って、「要求の確認」とは、新たに行う分析や施策において、何を達成したいのかをざっくりと確認します。

次に、より詳細に「要求」が解決したい課題や目的を明確にします。なぜならば、課題解決や目的達成の手段（＝要求）は１つではないからです。より経験豊富な担当者になれば、課題解決・目的達成のためにもっと効果的な要求を引き出してくれるかもしれません。

次に、上記を充たすためには、どのような分析用データ・施策用データが必要かを決めていきます。Excelなどを使って、実際のレポート画面のイメージや、メール配信シナリオなどを描き、最終的に必要となるデータにズレが起きないようにします。

次に、アウトプットイメージに沿って、どのようにデータを加工していけばいいかを明確にしていきます。例えば、「売上」という金額があったとしても、税込みで見たいのか、税抜きで見たいのか。値引き後の金額で見たいのか、送料はどうするのか、などを決めていく必要があります。

次に、「ｘｘ時までにレポートが最新化されてほしい」「ｘｘ時には、メール配信用のデータが最新化されて、自動で毎朝ｘｘ時にメールを配信したい」など、非機能要件（ユーザビリティ、性能、拡張性、セキュリティなど）を決めていく必要があります。

最後に、これまで決めたことをドキュメントに落とし込み、双方で検収を行います。

百聞は一見に如かず（ひゃくぶんはいっけんにしかず）という言葉通り、この文章を読んでもいまいちわからないと思いますので、ぜひおまけ資料を請求してみてください。

それでは、上記の流れを踏まえた上で、半年後に差が出る要件定義３つのポイントを見ていきましょう。

 

 

| ### 半年後に差が出る要件定義のポイントとは？① |
| --- |

まず何より大事なことは、『ヒアリングの型を作ること』です。

ウェブサイトの構築などのシーンでも「ヒアリングシート」というものを用意することがほとんどだと思います。予めどういった内容をクライアントに確認をすれば、社内に確認をすれば、抜け漏れなく要件定義ができるかということをヒアリングシート（ドキュメント）に落とし込んでおくことが重要です。新しい要求が生まれるたびに、また一から思い付きでヒアリングをしてしまっていては、いずれ絶対聞き漏らしたポイントが出てきて、やり直しが発生し、プロジェクトが停滞してしまいます。

ヒアリングシートなどの型が予めあれば、誰が要件定義してもある程度の品質は担保できるようになります。ヒアリングをする側も楽ですし、ヒアリングをされる側も「毎回これは聞かれるから事前に決めておかないといけないな」という感じで事前準備をすることができるようになり、品質だけではなくスピードも向上することが可能となります。

但し、型を作りさえすればいいというものではありません。そこには適切なコミュニケーションが必要となります。まず間違いなく「これ埋めておいて」だけでは相手には正しく伝わらず、雑に記入したヒアリングシートが戻ってくるだけです。また、ヒアリングシートにおいて大事なのは「解釈の余地を残さないこと」です。b→dashに限らず、仕事において起こりがちなのが「ｘｘｘだと、思っていました」という思い込みによるやり直しです。主観的な「思っていました」ではなく、「誰がどう読んだとしても、同じ理解に至る」ような型であったり、書き方であったりする必要があります。そして、そのような書き方となるよう、時には読み合わせをしながら一緒に埋めていくことも必要となります。

 

 

| ### 半年後に差が出る要件定義のポイントとは？② |
| --- |

次に重要となるのが、『考慮漏れを如何に防ぐか』です。

考慮漏れにはいくつかのパターンがあります。  
・データの考慮漏れ：想定していなかったデータが存在した（例：「男」「女」しかデータ上は存在しないと考えていたが、「不明」というデータが存在した）  
・顧客行動やシステム処理の考慮漏れ：Ａというプロセスのあとは、Ｂというプロセスしか存在しないと考えていたが、実はＣというプロセスが存在した（商品購入後は、キャンセルというプロセスしかないと考えていたが、返品というプロセスが存在した）  
・将来的な拡張性の考慮漏れ：今はＡという分析がしたかったが、あとからＢという分析がしたくなってしまった（例：年齢別で分析ができればよかったが、年齢だと細かすぎて年代で分析がしたくなってしまった）  
など

考慮漏れを防ぐには２つしかありません。**事前のデータやビジネスプロセスの調査・洗い出し**と、**経験則による補完**です。  
想定していないデータについては、思い込みや一部のデータだけ見て判断するのではなく、データベースの仕様書などを情報システム部やシステム開発会社から取り寄せし、事前に確認しておくことが重要です。また、ビジネスプロセスについても同様で、システム上あり得るプロセスは仕様書などで洗い出しを行うとともに、普段顧客対応等をしている部門の方からも追加でヒアリングを行うことが重要です。  
そして、それらを以て（もって）しても叶わないのが将来的な拡張性の考慮漏れです。こればっかりはb→dash初級者ではどうにもならないため、ベテランのエンジニアの方などを頼るか、信頼できるパートナー企業を探して依頼するかしかありません。但し、[第3回の記事](https://umbr-ella.jp/ja/お役立ちブログ/blog-0003)でお伝えしたように、**基本的にはアジャイルの発想を持つことが大事**です。作り直しは往々にして発生します。要件定義や設計に必要以上に時間を割いてしまわないように気を付けましょう。

 

| ### 半年後に差が出る要件定義のポイントとは？③ |
| --- |

最後が『要件定義した内容はドキュメントに残し、バージョン管理を適切に行うこと』です。

一般的に、要件定義後（最中）は、要件定義書に決定事項を落とし込んでいくものです。しかし、このドキュメンテーションにおいて起こりがちな失敗がいくつかあります。  
・改修が発生した際に、要件定義書が更新されていない  
・要件定義書が担当者のパソコンのローカル環境で管理されており、最新の要件定義書がわからなくなる  
・改修内容が適切に管理されておらず、前回のバージョンから何がどう変わったのかがわからないなどです。

これらのドキュメンテーションにおける不備を避けるためには、ドキュメンテーションの業務プロセスを定義し、適切に運用されているかを逐次管理する必要があります。こういった面倒なバージョン管理は、非エンジニアにとっては慣れない作業であり、どうしても滞りがち、後回しになりがちです。一方で、エンジニアの方々はGitと呼ばれるソースコードや変更履歴を管理するために使われるバージョン管理システムを用いるのが一般的であるため、違和感のない作業となっています。

私も数多くのクライアント、特に引継のプロジェクトにおいてこれらのドキュメンテーションの運用が適切に行われておらず、実態の調査に多くの工数を費やしたことがあります。急がば回れです。あとから振り返った時に必ず役に立ちますので、要件定義書の管理は適切に行っていきましょう。

 

いかがでしたでしょうか？全12回の連載のうち、今回は『半年後に差が出る 要件定義３つのポイント』というテーマでお伝えさせていただきました。もし少しでもb→dashの初期導入における要件定義に不安を感じていらっしゃる方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。

 

最後までご覧いただきありがとうございました。

「問題はわかったけど、じゃあどうしたらいいの？」と思われたかと思います。続きが気になる方は以下の資料で「明日から使える３つのアクション」を解説しています。ご興味を持っていただけた方は、ぜひお気軽に資料請求をしてみてください（しつこい営業は一切行いません。※同業他社の方からの資料請求はお断りしておりますので予めご了承ください）。

|   明日から使える３つのアクション   半年後に差が出る要件定義の特徴はわかったけど、 「じゃあどうしたらいいの？」 という方のために 明日から使える３つのアクションをまとめました。 ぜひ併せてお読みいただき、 日々のマーケティング活動の一助にしていただければ幸いです。   とりあえず資料請求してみる   |
| --- |

 

#### ABOUT AUTHOR

[umbrElla編集長](https://umbr-ella.jp/ja/blog/author/about-執筆者umbrella編集長)

**関連記事を読む**

[![](https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2301.jpg) ](https://umbr-ella.jp/ja/blog/blog-0001)

## [ 【b→dash #01】停滞しがちなマーケティング組織の特徴３選 ](https://umbr-ella.jp/ja/blog/blog-0001)

[ Learn More ](https://umbr-ella.jp/ja/blog/blog-0001)

[![間違いだらけのツール選定、押さえておきたい３つのポイント](https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2302.jpg) ](https://umbr-ella.jp/ja/blog/blog-0002)

## [ 【b→dash #02 】間違いだらけのツール選定、押さえておきたい３つのポイント ](https://umbr-ella.jp/ja/blog/blog-0002)

[ Learn More ](https://umbr-ella.jp/ja/blog/blog-0002)

[![これだけはやっちゃだめ、b→dashの利用が遅れる３大パターン](https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2303.jpg) ](https://umbr-ella.jp/ja/blog/blog-0003)

## [ 【b→dash #03 】これだけはやっちゃだめ、b→dashの利用が遅れる３大パターン ](https://umbr-ella.jp/ja/blog/blog-0003)

[ Learn More ](https://umbr-ella.jp/ja/blog/blog-0003)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "umbrElla編集長",
    "url" : "https://umbr-ella.jp/ja/blog/author/about-執筆者umbrella編集長"
  },
  "dateModified" : "2024-10-07T04:41:32.870Z",
  "datePublished" : "2024-07-29T07:09:00.000Z",
  "headline" : "【b→dash #06】半年後に差が出る、非エンジニアのための要件定義３つのポイント",
  "image" : [ "https://umbr-ella.jp/hubfs/umbrElla/umbrElla_%2306.jpg" ],
  "mainEntityOfPage" : {
    "@id" : "https://umbr-ella.jp/ja/blog/blog-0006",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://umbr-ella.jp/hubfs/umbrElla_logo_svg.svg"
    }
  }
}
```

```json
{
  "@context" : "http://schema.org",
  "@type" : "Corporation",
  "address" : {
    "@type" : "PostalAddress",
    "addressCountry" : "",
    "addressLocality" : "福岡市博多区祇園町",
    "addressRegion" : "福岡県",
    "postalCode" : "",
    "streetAddress" : "2-31 フィル・パーク博多祇園2F "
  },
  "alternateName" : "Lagom",
  "description" : "Lorem ipsum dolor sit amet, consectetur adipiscing elit",
  "email" : "",
  "image" : "",
  "logo" : "https://23730364.fs1.hubspotusercontent-na1.net/hubfs/23730364/umbrElla_logo_svg.svg",
  "mainEntityOfPage" : {
    "@id" : "https://umbr-ella.jp/ja/blog/blog-0006",
    "@type" : "WebPage",
    "description" : "b→dashの導入・運用に対してお悩みをお持ちのマーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。"
  },
  "name" : "株式会社 ORIGO JAPAN",
  "sameAs" : [ "https://www.linkedin.com/company/revivalpixel/", "https://www.linkedin.com/company/revivalpixel/", "https://www.linkedin.com/company/revivalpixel/" ],
  "telephone" : "",
  "url" : "https://umbr-ella.jp/"
}
```