.../articles/

“誰かが決めた仕様の資料化”から脱するための要件定義

「あれ…?これ誰が欲しくて入ってる機能なんだっけ?」みたいなことを、どうしたら避けられるかな、というメモ。

案件をやる中で感じる「あれ…?これ誰が欲しくて入ってる仕様なんだっけ?」みたいなことを、どうしたら避けられるかな、というメモ。(ウェブサービスとかつくる前提で勝手に話します。)

埋まらないリーンキャンバスが意味すること

サービスを簡単にすばやく形にするため、リーンキャンバスを利用することがあります。
サービスを俯瞰するときに便利なこれは、ターゲットやニーズ、市場調査などができていなければ、埋めることはなかなか難しい代物です。

受注してつくるサービスなんかだと、クライアントに問いかけてはみるのですが得てして「これ!」という答えは返ってきにくい印象です。もはやこれは 埋められない ということを知ってもらうためのツールなのかもしれない、と最近感じます。
知らない、考えていないということを可視化するためのツール。

基本中の基本だけど、サービスを設計する上で大事なのは2つだと考えています。

  • ターゲットは誰なのか
  • 提供する価値は何なのか

ターゲットは誰なのか

まずターゲットを定めることです。当たり前のことではありますが、ユーザ理解のない機能は案外簡単に生まれてしまいます。
ユーザは使う側であってつくる側ではない、という意識は、言われれば思い出せますが、根気強く考え続けることができなければ実現しません。

それにはやはりターゲットを知るところから。

ニーズを叶えるサービスを作りたい
→ ターゲットを定めなければニーズが本当にあるのか分からない
  → ニーズがあるのかわからないと価値が定められない
    → 進まない……というループ

こういった負のループから抜け出すには、 「ユーザのことを知らない、知らなければ」という共通認識 が必要です。

ターゲットの定義は難しい課題ですが、結局のところ、解決したいこというのは生活の中に転がっているのかなとも思います。
面倒なことをやってくれる、めっちゃ早くやってくれる、言われる前にやってくれる、ずっと覚えてくれている……など。

こういった当たり前のことに困っている人、と考えると、身近にいそうな気がして考えられるかもしれません。

提供する価値は何なのか

ニーズを明らかにするためにユーザを具体化させるべし、というのが↑での主張ですが、機能開発をニーズから出発させると、 よくわからないモノが生まれがちです。これ何に使うの?みたいな。

は?言ってること違うじゃん。って感じですが、大事なのはターゲット像を明らかにし、一番大事な価値や体験を浮かび上がらせることです。ご意見番を作り上げることではありません。

なぜニーズから機能開発するとよくわからんのかというと、

コアとなるコンセプト、価値の欠如が起こりがち
→ 競合がある中で「少なくともこのニーズの人はこのサービスを使う」みたいな優れている点がない
→ どのようにその価値を知ってもらうか(シンプルな価値になっているか)という視点がない

「伝わる価値」になっているか、という視点が抜けると、上記のようなよく分からないけど客の要望は叶える 百徳ナイフ的サービス になりがちです。

百徳ナイフってなんやねん、って方は↓を。(なんか普通に話題にしたけどUIデザインしてる人しか百徳ナイフなんてもの見ないのでは、と思ってリンク探した。)
スマホUI考(番々外編) 誰得の100徳ナイフを買ったというお話 | fladdict


これら2つ(ターゲットは誰なのか、提供する価値は何なのか)を大事にしながら、以下のようにサービス設計を進めることにしています。

伝わる価値をつくる

使えるではなく、伝わる価値をつくる

サービスでは機能的な価値単体ではなく、 ユーザが理解・共感できるストーリーの中に 効果的な機能を置いていくのが大事だと考えています。

使い方が分かりつつ、価値がひと目・ひと言で分かる状態が良いのだ、と言うのが持論です。

これはリーンキャンバスで言う「 競合に勝てるポイント(独自の価値)」や「顧客が何に共感するか(サービスコンセプト)」に該当する部分でしょうか。チームで共通認識をつくることが大事だと感じています。

「簡単な」シナリオをつくる

共通認識をつくるためには、周辺情報が多い方がうまくいく気がします。
共感するシナリオを簡単に設定します。 簡単に行うこと が大事です。作り直しても良いくらいの手の入れ方が大事。

簡単なシナリオを具体化していくとカスタマージャーニーマップへを進化していきます。(多分)

↓のようなやり方だとイメージしやすいしみんなで進めやすそうです。

UXデザイン入門におすすめ!ユーザー体験を簡単に可視化・共有できる「いらすとやシナリオ法」|ばっこ|note

「簡単な」リーンキャンバスをつくる

いきなり全体ではなく、 基準点となるポイント を押さえることが大事だと思います。いろんな要素がサービス設計には入ってくるので、だいたいどこかには自信や根拠があって、どこかはそれが薄い、みたいなことが多いと思います。

  • ターゲット
  • 困っていること
  • 解決策
  • どうなるのか

上記のようなふわっとした情報を、具体化、詳細化するとリーンキャンバスへ進化します。(するのか?)

  • ターゲット
    • 顧客とは誰か(顧客セグメント)
    • 初期の顧客は誰か(アーリーアダプタ)
  • 困っていること
    • なぜ顧客は喜ぶのか(解決する課題)
    • 今、顧客はどうしているのか(既存の代替品)
  • 解決策
    • 顧客に何を提供するのか(機能、ストーリー)
  • どうなるのか
    • 顧客の反応をどうやって知るか(主要指数)
    • 顧客が何に共感するか(サービスコンセプト)
    • 競合に勝てるポイント(独自の価値)
    • なぜ顧客はこのサービスを選ぶのか(圧倒的な優位性)

コストや収益についてはここに含められてません。
持続してサービスを良くしていくためにも、そこらへんは今後の課題ですね。


途中ですがここまで。
こういった、「どう案件をまとめあげるか」という視点はどんどん社内で共有していきたい所存です。

.../articles/

Articles

記事

AWS AmplifyにmonorepoのNext.js(App Router)をデプロイする

AWS AmplifyにmonorepoのNext.js(App Router)をデプロイする

monorepo管理しているNext.jsをAmplifyにデプロイしようとした際にいくつか躓く内容があったのでまとめておきます。

リモートワーク・オンライン会議でも、スムーズに制作を進めるために大切なこと[資料編]

リモートワーク・オンライン会議でも、スムーズに制作を進めるために大切なこと[資料編]

コロナ禍の影響により、リモートワークの導入をおこなっている制作会社も多く、実際に弊社でも導入しています。

売れるECサイトデザインを作るために。参考にしたいおしゃれな事例の探し方。

売れるECサイトデザインを作るために。参考にしたいおしゃれな事例の探し方。

売れるECサイトのデザインは、「この形式」という決まりはありません。ECサイトで売り上げを上げるなら、しっかりとしたコンセプトと、コンセプトを決定するまでのリサーチが必要です。

制作会社の考える、業務効率化ツールのおすすめ。個人でも使いやすいサービスなど。

制作会社の考える、業務効率化ツールのおすすめ。個人でも使いやすいサービスなど。

新型コロナウイルス感染拡大の影響で、リモートワークが主流になり、弊社でも週のほとんどは各自宅で作業をしています。

Figmaでデザインのコミット履歴を残せるプラグイン【Thought Recorder】をリリースしました

Figmaでデザインのコミット履歴を残せるプラグイン【Thought Recorder】をリリースしました

Figmaを利用するWebデザイナーの助けになれると嬉しいです。使い方は本記事をご覧ください。

ECの構築方法、おすすめのECサービス。

ECの構築方法、おすすめのECサービス。

ファッションや家電、スーパーの買い物でさえもECサイトを利用することが当たり前になりました。加えて新型コロナウイルスの影響もあり、弊社にも「どんなプラットフォームを利用したら良いか」「どれくらいコストがかかるのか」などECに関するさまざまなご相談を頂きます。

FastAPIのスキーマクラスをOpenAPIから生成する方法

FastAPIのスキーマクラスをOpenAPIから生成する方法

PythonでAPIを構築する要件があり、フレームワークに比較的モダンなFastAPIを採用しました。FastAPIはバックエンドの開発を行えば自動でOepnApi定義を生成する機能が備わっていますが、今回はこれを使わず、事前に用意したOepnApi定義からFastAPIで利用するスキーマクラスを生成する方法を紹介します。

Laravel 日本一解りやすい全文検索のマイグレーション記載方法解説

Laravel 日本一解りやすい全文検索のマイグレーション記載方法解説

Laravel + MySQLで全文検索を実装する

とあるPythonのソースで sys.path.append としたく無かった話

とあるPythonのソースで sys.path.append としたく無かった話

とあるプロジェクトのとあるソースコードのレビューをしてた時、「ソースコードの参照がうまくいってなかったので修正しました」とレビュー依頼がきました。 ディレクトリ構造 ``` module L __init__.py L main.py L tests L __init__.py L test_main.py ``` ソースコード ``` python tests/test_main.py sys.path.append(os.path.abspath("..")) from main import fuga ``` 今まで案件でPythonに触れる機会も結構ありましたが、なんとなく使ってきた部分も多く、この書き方が良いのか悪いのか判別できなかったので、改めてPythonのモジュールのインポートに関して調べてみたのでブログにしました。普段PHPを書いている事が多くPythonに関して何も分からないので初心者向けの内容になっていると思います。

GiFT1号目新卒デザイナーの2021年振り返り

GiFT1号目新卒デザイナーの2021年振り返り

いつの間に、年末ですね。入社してもう、9ヶ月も立っていたようです。2021年の振り返りを記事にしました。

すべての記事

お問い合わせ