ATQの要件定義 | ATQの「つくりかた」vol.2
こんにちは!ATQデザイナーのトラです!
今回はデザイン制作の『要件定義』についてです。デザインプロセスの中でも重要性が高く、プロジェクトの根幹となる工程です。
正直、他の会社さんってどんなワークフローなんだろう?と気になったことってありますよね?でも、公開している会社は多くありませんし、そもそも知る術が全然ない!
なら、せめて自分たちのフローを公開してみよう!と言った気持ちで書き始めてみました。ATQではこんな考え方で、こんな進め方をしているよという参考になれば幸いです!
ATQのワークフロー
要件定義について詳細な内容をお話しする前に、まずはATQのワークフローの全体図から確認していきましょう。
ATQのワークフローは以下の4つのフェーズで構成されています。
ATQでは、これらのフェーズ毎の目的を達成するために、具体的なタスクに細分化したものをワークフローとして使用しています。
ワークフローについて詳しくは別の機会でお話しできればと思います。
要件定義とは
要件定義は『1. 企画・提案フェーズ』でクライアントとの事前ヒアリングの後に行う、プロジェクトの全体像を把握するための重要なプロセスです。
事前のヒアリングをもとに、プロジェクトを進める意味や、達成すべき要求、スムーズな制作・進行のために必要な情報を多角的にまとめ共有します。
ATQではコーポレートサイトやECサイトなどのweb制作がプロジェクトの大半を占めているため、今回はweb制作の要件定義を前提にお話ししていきます。
ATQの要件定義
ATQではプロジェクトを担当する「営業」「ディレクター」場合によっては「デザイナー」が同席してクライアントとの事前ヒアリングを行います。
ヒアリングの内容から、必要な情報を精査しFigmaで管理している独自のコンセプトシートに書き込み要件定義を進めています。
その後、チーム全体で要件定義の内容をレビューし、提案資料に落とし込んだものをクライアントへプレゼンしています。
以下は要件定義の際に取り扱っている情報と、具体的な確認事項についてです。
a. 依頼背景
プロジェクトが発案するに至った背景についてです。依頼のきっかけや、ATQに求める事柄、営業プロセスなど、プロジェクトの発生状況の整理になります。
b. 課題確認
クライアントが抱える課題の確認です。ヒアリング内容や依頼背景から、クライアントが抱える現状の課題や、望ましい変化について抽出します。
クライアント自身が課題に感じていることは勿論、我々がもしかしたらこれも課題なのでは?と感じた仮説なども同時に確認します。
c. 要求定義
課題とは別にプロジェクトに求める要望についてです。要求の確認と実現性の検証が主な目的です。実現不可能な場合は提案時にその旨の説明をしています。
ATQではプランを複数案用意する場合が多いのですが、主に制作内容の違いと、満たせる要求の違いによって複数のご予算やスケジュールをご提案しています。勿論、課題の解決はマストなので解決に関しては全ての案に組み込んでいます。
d. 情報整理:why / who / where / what / when / how much
プロジェクトの概要情報を5W1Hの項目に分解して整理します。この段階で把握している情報に抜け漏れがないかや、クライアントとの認識のズレが生じていないかの確認の意図が大きいです。
また、チーム内での正確な情報共有のためにできる限り具体的に詳細にまとまっている状態が好ましいです。
e. 解決方法:how to
『b. 課題確認』に対する具体的な解決手段の提示です。前述していますが、ATQはデザインの受託制作を主軸としていますが、ただ作るだけでなく、課題の解決に繋がる制作を心がけています。
そのため、『b. 課題確認』『c. 要求定義』が確定して次に考えるのは具体的な制作物についてではなく、この項目になります。
「課題解決をするための制作」なので解決手段が先、制作物は後になるのは必然ですね。
クライアントの状況や、『d. 情報整理』に合わせて最適な解決手法を模索し、デザインや制作物に落とし込みます。
既存のプロダクトの課題点・改善点から探る場合や、デザイン以外のマーケ領域などの手法を用いて解決を試みる場合など、プロジェクトによって毎回異なるアプローチとなるので一概に「これをする」とは言い難いですね。
f. 想定されるボトルネック
プロジェクトの進捗に直接的に関わる問題要因の洗い出しです。「これが起こると進捗がまるっきり止まってしまう。」「これを解決しないとそもそもプロジェクトが破綻する。」など、案件進捗の根本的に影響を与える要因を事前に想定し、回避策を持っておくことが目的になります。
多少の問題やエラーはどうしてもつきものですし、都度対応でもなんとかななるので全てを対策する必要はないかと思います。しかし、プロジェクトの存在自体を脅かすような問題は事前に把握しておく必要があります。
依頼された以上、「想定していなかった」は責任に欠け、クライアントとの信頼や関係性に大きく影響してしまいます。事前の把握・想定も勿論大切ですが、回避策の用意と合わせて最重要項目だと考えています。
g. クライアント情報
クライアントの事業内容について理解を深めることが目的です。主に「事業内容」「強み / 特徴 / 差別点」「商品 / サービス」「主な取引先 / エンドクライアント」「規模感」「本社 / 拠点」の6項目から事業理解を深めています。
クライアントワークおいてクライアントの事情を事細かに知っておくことは非常に重要なポイントになります。
課題に対し、一般論的な解決手段ではなく、クライアントの特徴を踏まえたパーソナルな解決手法を模索することができるので、情報は多いに越したことはありません。
ご依頼の際は、ぜひ皆さんの事業についてお聞かせください!
h. 関係者情報
プロジェクトの担当者や決済者の性格や特徴についてです。事業内容と同じくらい関係者への理解も重要になります。
制作会社の独りよがりな進行では意味がありません。1つのプロジェクトを共に進めるチームとして関係性を築く必要があります。
特に決裁権の有無や、web / デザインへの知識具合に合わせてより分かりやすい提案・進捗手法を取ることができます。
また、引き付きや担当の変更の際にスムーズにやり取りを進めることが可能になります。
要件定義の運用目的
要件を詳細に定義する目的
詳細な要件定義する目的は「グレーゾーンを無くすため」です
要件定義の主な役割としては以下が挙げられると思います。
これらに共通して言えるのは、確定していることに意味があることだと思います。デザイン制作やコンセプトワークには一定のグレーゾーンも必要かと思います。
しかし、要件定義においてはこの先全ての工程に深く関わってきます。頼るべき指針であり、道筋であるはずの要件定義が曖昧ではプロセス全体がぼやけてしまします。
どれだけ緻密な計画を練り、高尚なコンセプトを掲げてもそれを体現できるのは、アウトプットとなるデザインでしか答えることができません。
こちらに関しては、 Shhh inc.の重松佑さんも以下のように言っています。
運用のルール
要件定義を行う際に、気に留めたいことが2点あります。それが「 適切な情報の区別」と「ボトルネックの想定と対策」です。
要件定義はプロジェクトの全ての工程に深く関わってきます。そのため「正確性」と「確実性」が求められます。
ATQでは要件定義の運用ルールとして以下の2点を設けています。
今回は私たちが普段プロジェクトで使用しているコンセプトシートをもとに要件定義についてまとめてみました。「要件定義にはこんな役割がある」や「こんないいやり方もあるんだぞ」などのアドバイスなどあればぜひ教えてください!
ATELIER-Qは、戦略立案のご提案から設計・制作・運用を手掛けるデザインチームです。
ATELIER-Qはコンセプトワークや戦略立案を主軸にクライアントに最適なご提案を行っています。主にビジネスシーンでのデジタルデザインや、トータルブランディングなど総合的なクリエイティブサービスを提供します。
皆様からのデザインのご依頼やご相談をいつでもお待ちしております!
HPやtwitterなどからお気軽にお声がけください!
この記事が気に入ったらサポートをしてみませんか?