Crew Blog：アプリ、ウェブサイト、ロゴなどなど、何かを作り始めるときに重要な役割を果たすのがプロジェクト概要説明書です。概要説明書は、明快、正確、簡潔でなければなりません。

頭の中でアイデアが浮かんだ瞬間から、概要説明書作りは始まっています。あとは、その思考を紙面にすればいいだけなのです。

概要説明書とは、あなたを終着点に導くトレーニングプランだと思えばいいでしょう。ひとつひとつの細かいステップまで書く必要はありませんが、望み通りの結果が見えないときにいつでも戻れるようにしておかなければなりません。

さらに、概要説明書を読むのは自分だけではありません。一緒に働く仲間がプロジェクト全体のビジョンを把握できるようにしておきましょう。プロダクトの最終的な姿だけでなく、そこに至るまでにすべきことが一目瞭然でなければなりません。それを明確にしておかなければ、物事が予想通りに進まなくても文句を言うことはできません。

概要説明書は、簡潔なアウトラインだけのものから詳細な文書までさまざまです。どちらを選ぶかは、創造のプロセスをどの程度自分でコントロールしたいかにかかっています。以下に、2つの代表的な選択肢を紹介しましょう。

「ルーズ」な概要説明書でクリエイターに裁量を与える

プロジェクトメンバーにできるだけ多くの裁量を与えたければ、あまり具体的な指示で選択肢を狭めるのではなく、さまざまなルートを取りうるような、自由度の高い概要説明書を作るといいでしょう。

たとえば、当社のウェブサイト「crew.co」のリデザインをしたとき、これまでに考えたことのないデザインコンセプトを試してみたかったので、「ルーズ」な概要説明書を作りました。

ルーズな概要説明書とは、以下のようなものです。

この「ルーズ」な概要説明書の目標は、デザインの方向性に影響を及ぼさない範囲で、ホームページに用意すべき要素を説明することでした。

概要で「メンバーは大幅な裁量をもってクリエイティブに取り組むことができる」と断っているのも、参考サイトへのリンクがないのもそのためです。

私たち好みのスタイルを持つデザイナーを1人選び、方向性はすべてお任せしました。なぜなら、当社のデザインに対する新たな視点がほしかったから。細かい概要説明書で、可能性を狭めてたくはなかったのです。

「タイト」な概要説明書でクリエイターの裁量を制限する

過去に同様のプロジェクトに取り組んだことがあり、顧客または何らかのデータのおかげでプロダクトのアイデアが明確な場合は、「ルーズ」なタイプの概要説明書で裁量を与えすぎるのは得策ではありません。

そのような場合、より「タイト」な概要説明書を作って、プロジェクトに従事する専門家に、できるだけ明確な方向性を示す必要があります。この種の概要説明書の目的は、あなたの知識を共有すること。そうすることで、あなたのビジョンを実行に移すための正しい洞察力を、プロジェクトメンバーに持ってもらうのです。

以下に、当社の「How to Build an Online Business」シリーズの設計開発のために作成した「タイト」な概要説明書を紹介しましょう。

「How to Build an Online Business」には、すでに特定のスタイルがあったので、概要説明書に「一貫性を保つため、当社サイトに既存の『Stories』セクションと同様のスタイルの使用が望ましい」と記載しました。

また開発環境については、CSSおよびJSファイルの圧縮・非圧縮バージョンでの納品やコードパターン（OOCSS）や望ましいプリプロセッサ（SASS）など、具体的な要件を記しました。

「タイト」な概要説明書は、「ルーズ」な概要説明書よりも、細かく定義されたタスクの実行に焦点を当てています。

スケジュール、予算、支払い

概要説明書には、要件のほかに完成までのスケジュール、予算、支払い方法などを記すのが通常です。

スケジュール

機能やデザイン要件が複雑なプロジェクトの場合、具体的な日付よりも、おおざっぱな時間的枠組みを見積もっておくのが適しています。たとえば、「5月19日までに完了すること」ではなく、「約1カ月で完了することが望ましい」といった具合です。

機能の実行や整合にはたくさんの方法があり、それぞれの機能の構築にかかる時間は同じではありません。

発注するアプリまたはウェブサイトに複雑な機能が含まれる場合、プロジェクト着手時に正確な納期を定めることは困難です。プロダクトのすべての機能と要素の整合性を取るためには、さまざまなルートを試す必要があるのです。

納期に柔軟性がないままプロジェクトの進行に合わせて指示を出そうとすると、納期に間に合わせるために最終プロダクトの品質を犠牲にせざるをえなくなるでしょう。

FacebookのデザイナーJulie Zhuoさんは、プロダクトデザインでやりがちなミスに関する記事において、「探求プロセスを制限することは、宝の地図を探索しないまま放棄するようなもの」と述べています。探求プロセスの時間を制限すれば、プロダクトのアイデアやソリューションに関する宝のような発見を失うことになるかもしれないのです。

もう1つの手法が、3重の制約と呼ばれるもの。ビジネスの目標を達成するために、予算、範囲、納期を定める方法です。ただし、プロジェクトを成功させるには、多少の妥協も必要です。

これをするためのもっとも簡単な方法は、プロジェクトにおいてフィックスする部分と、柔軟性を残す部分を決めておくこと。予算は固定なのか、ある程度はフレキシブルなのか。ローンチ日は決まっているのか。プロジェクトにとって何が欠かせないかを理解しておくことで、必要に迫られたときに何を犠牲にすべきかというタフな決断を下しやすくなるでしょう。

多くの場合、影響力が大きいのはプロジェクト範囲です。多機能モバイルアプリや一から作るウェブアプリなどの大規模プロジェクトには、オープンなスケジュールとフレキシブルな予算が必要になることが多いでしょう。

とはいえ、機能が比較的シンプルで明確に定義できる場合（「パスワードを忘れたとき」のような機能の追加やシングルページのウェブサイトのデザインなど）、納期を正確に定めることも可能です。

プロダクトの初期バージョンにこだわり過ぎて、あらゆる機能を盛り込もうとしてしまいがちですが、長い目で見たときに、初期バージョンが最終バージョンになることはほとんどありません。

たとえば、ロケーションチェックインアプリ「Foursquare」は最初の2年間で、何度もデザイン変更を繰り返しています。

立ち上げ当初のデザインの大半は、Apple iOSにデフォルトの要素を使ったものでした。しかし、勢いを得るにつれて、少しずつ自社ブランドのUI要素や新機能を使い始めます。2011年中ごろには、iPhoneアプリ専属のUIおよびUXデザイナーを採用できるようになりました。

これができたのは、Foursquareにとって時間が重要な要素だったからにほかなりません。デザインの範囲を犠牲にして、その分野で最初の企業になることを選んだのです。

予算

概要説明書には予算の概算を含むのが通常です。しかし、作業開始前にモバイルまたはウェブプロジェクトの見積もりを出すのは困難なので、最低でもある程度の幅を持たせることが必要になるでしょう。

そうすることで、プロジェクトメンバー全員がある程度の予想ができるようになります。予算1万ドルのプロジェクトと1000ドルのプロジェクトでは、検討する内容が変わってくるものです。

支払い

支払い条件は、お金の支払い方法を定めるものです。着手前に支払うこともあれば、プロジェクト完了時にパートごとに支払うこともあります。

Crewでは、プロジェクトをいくつかのパートに分け、パートごとにスケジュールと予算を割り当てることを勧めています。

たとえば、モバイルアプリのデザインプロジェクトなら、以下のようにタスクに応じて3段階に分ける方法があります。

• 支払い1回目＝30％：アプリのメイン画面のデザイン
• 支払い2回目＝30％：残り5つの画面のデザイン
• 支払い3回目＝40％：既存デザインの改訂／微調整

---

よい概要説明書は、プロジェクト全体の方向性を定めてくれます。地図と同じで、Googleマップのように曲がり角をすべて正確に指示するもよし、コンパスのようにルーズに方角のみを示し、探求の余地を残すのもよし。

全体として成功する概要説明書は、ビジネス目標（サインアップ数を増やす、必要最低限機能を市場投入して需要を試すなど）と最良の決断を下すための情報を、作業に従事するメンバー全員に理解させられるものです。

ウェブサイトやモバイルアプリプロジェクトを立ち上げたいなら、当社が概要説明書の作成をお手伝いします。

How to write a good project brief｜Crew Blog

Michael Sacca（訳：堀込泰三）
Photo by Shutterstock.