via Changes to site permalink page on Flickr – Photo Sharing!

なぜ必要かと言えば、プロジェクトメンバーと意識を共有するためです。これがずれていると、プロジェクトの進行方向が徐々にずれていってしまいます。そうならないよう、初志を書き出しておくことで、定期的に見直し、改訂してプロジェクトを進めていくのが重要です。

そこで今回は私がWebの企画書（自分用ではなく、他社への提案用）を作る際に注意している項目を書き出してみました。実際は、これらを必要に応じて削除/追加したりします。

□ コンセプト

最も大事ですね。端的な言葉でサービスの概要を言い表す必要があります。

□ サービス名

これは二番目に大切です。といってもまだ決まっていない場合もあるので、その場合はプロジェクトAとか適当に…。

□ 概要

こちらはコンセプトの詳細です。とは言え長ったらしく書くと理解に苦しむので分かりやすく。

□ ターゲット

ターゲットユーザ層を明確にします。性別や肩書き、職業、年齢その他条件をできるだけ絞り込みます。そうすることで自分たちがどういった人を相手にWebサービスを提供するのか再認識できます。

□ 特徴

Webサービスの特徴を書き出します。

□ 機能

Webサービスの主な機能を書き出します。

□ キーワード

サービスのコンセプト内で使われている用語などで、サービスのキーになる単語を書き出します。これを使ってSEMを考えたり、競合サービスを明確にしたりします。

□ 利用メリット

サービスのメリット（使い手）を書き出します。これがよく分からないようだとサービスとしてどうなのでしょう、となります。

□ 予算

リリース前、リリース後の概算の予算を出します。金額が分からない場合は○○円でとりあえず項目だけ挙げておきます。

□ 収益予測

予想される収益ラインを想定します。

□ 開発体制

リリース前の体制図です。情報伝達方法や決裁者も明確にしておきます。

□ 運用体制

リリース後の体制です。こちらも開発体制同様に、連絡先や利害関係者を明確にします。

□ 主なコンテンツ

Webサービスで提供する主なコンテンツをリストアップします。

□ リリース時のコンテンツ

リリース時点でのコンテンツ（とその量）を書き出しておきます。言わばリリース目標です。

□ 運用時のコンテンツ

運用時のコンテンツ拡充方法です。これによって運用体制や方法が決まってきます。

□ パブリッシング

パブリッシングを行う先やその方法です。ターゲットユーザによって異なります。

□ タイムライン

プロジェクトのタイムラインです。何があるか分かりませんが、とりあえず決めておきます。

□ セキュリティ

情報漏洩防止策、運用管理方法などの注意点を定めておきます。

□ 法律

Webサービスをリリースする上で関わってくる法律とその対処法をリストアップしておきます。

□ 対応言語

Webサービスの言語（日本語、英語など）です。

□ 開発言語

プログラム関係の話です。これによって開発体制が異なってきます（逆に開発体制がこれだから、言語が決まるという場合もあります）。

□ ハードウェア

調達先や設置場所、配置図を考えます。

□ ネットワーク

ハードウェア同様です。

□ SEO/SEM

SEOは業者を使うか否か、同様にAdWordsやOvertureといった広告をどう扱うかになります。SEOは一からコンテンツを積み上げる場合、いきなり結果が得られづらいので、パブリッシングや事前のコンテンツ拡充などが必要になります。

□ 集客

サイトへの集客方法です。SEOや口コミ、ブログからの誘導、電話、広告、FAX…などなどです。

□ オフラインの捉え方

オンラインだけでなく、オフラインに対してどうアプローチするか考えます。

□ ターゲット環境（モバイル/PC等）

Webサービスのターゲット環境を想定します。

□ デザイン

デザイン上の注意点を書き出します。ターゲットユーザを意識して行う必要があります。

□ 競合

競合サイトをリストアップします。

□ マーケティングデータ

Webサービス企画を押し進める上での第三者データがあれば書きます。

□ 権限

Webサービス内に存在する権限を書き出します。

□ ビジネスフロー

Webサービスを含めたビジネスフローを定義します。

□ プロジェクトの進め方

企画が通ったとして、プロジェクトをどのように進めていくか書いておきます。

□ 備考

その他備考や注意点をリストアップします。

主立った項目としては以上でしょうか。もちろん、企画段階ですべてを決められる訳ではないので書けない項目もあります。が、単なるアイディアを書き出したところで会議の場で企画としては浅いと思われてしまうのがオチです。アイディアから企画へ押し上げることで、プロジェクトとして認可され、開発がスタートする可能性が上がってくるのではないでしょうか。

via 12 01 07 – My New Setup on Flickr – Photo Sharing!

もっとも重要な要素は人材です。特に責任者のプロジェクトにかける情熱が一番重要になります。

外部に開発を任せた場合、仕様を策定した時点で開発作業が開始され、内部からは状況が若干分かりづらいものになります。このとき、責任者の情熱が低く、外部任せにしてしまうと、期日近くになって出てきたものは予想を裏切るものになっているはずです。

「開発するのは外部？内部？」でも書いた通り、プロジェクト管理とはプロジェクトがビジネス的に成功したかどうかの判断になります。システムがみすぼらしくとも、予測を上回る収益をあげていたら成功です。逆にシステムがどれだけ立派であっても、収益が全く駄目であれば失敗です。

仕様策定はプロジェクト管理における4分の1がようやく終わったにすぎません。その後、開発→テスト→運用のフェーズに入ります（他の要素もありますが、それらは同時進行が可能なものもあるので）。そう考えるとこの時点で外部リソースに任せてしまうのは失敗の元になるでしょう。

責任者はシステム以外のプロジェクト管理も同時に進める必要があります。予算、リソース、宣伝＆広告、営業体制、会計…それらを全て一人でやるのは無理にせよ、適切に管理していく必要があります。これらは非常に大変な作業で、まさに情熱がなければ不可能です。

さらにリリース後の運用についても同様です。コンテンツの追加であったり、スパムや荒らしへの対応、改善点をみつけ、サービスをよりよくしていく必要があります。これらも責任者の情熱がなければ鳴かず飛ばずで終わってしまうことでしょう。

Webのインタフェースはコンピュータ上で書かれたHTMLを表示しているだけですが、その向こう側にある運営者の情熱が意外なほど伝わるものです。運営側が放置していると、サービス全体のパフォーマンスも落ちてきます。その点から見ても、プロジェクト（開発だけでなく）の成功可否を握るのは運営者の情熱であると言えます。

via Skype Reverie on Flickr – Photo Sharing!

これまで経験してきたプロジェクトでは、どちらかと言えば外部のリソースを使って最善の結果を得られたことの方が少ないように思えます。最も大きな原因は「プロジェクト」における両者のスコープの違いです。

外部のリソースにとってのプロジェクト管理とは、言わばプロダクト管理の範囲に収まります。つまり、開発して納品、検収をうけるまでがプロジェクト管理です。逆に内部の人にとってのプロジェクト管理とは、システムを実際に動かし、収益を黒字化することがプロジェクトになります。

外部のリソースにとってのゴールは、内部のリソースにとってみればスタートでしかありません。システムは箱であり、実際にそれを使わないと意味がないのです。その点の認識のずれが、プロジェクトの後半になるにつれてどんどん大きくなっていき、それが悪い結果につながることが多いです。

金額が大きくなればこのずれは埋められることもあるのですが、1,000〜5,000万円くらいの開発規模ですとずれの修正にかかるコストが大きく、どちらがそれを吸収するのかで外部と内部で軋轢を生みやすくなります。

Webの開発の場合、良きにせよ悪しきにせよ仕様の変更というのが良くおこります。数百億円のプロジェクトにおける数百万円の仕様変更と、1,000万円の規模における数百万円分の仕様変更ではうけるインパクトが大きく変わってきます。そして外部のリソースにおいては検収が第一になるので、とにかくはじめに決めた仕様でまずは検収をうけることが優先され、第一段階での仕様策定時からの市場の変化、状況の変化を見ないようになりがちです。

当たり前ですが、その結果作られたものは実際の運用にはあっておらず、使えない代物になります。内部の満足度も低く、お互いにとって嬉しくない結果に終わってしまうことが大抵です。

そういった事情をふまえると、個人的にはプロトタイプの作成は内部リソースで行うべきだと考えています。または柔軟に対応してもらえる外部リソースを求めるべきでしょう。そしてしばらく運用を積み重ねていった結果、見えてきた機能要件をまとめてから外部リソースを頼るべきだと思います。

とは言え、そうそう単純にいかないケースも多いとは思います。次回はそうした事情をふまえつつ、外部リソースの上手な使い方を考えてみたいと思います。