「仕様書」はWebサービスやアプリを作るうえで開発者の説明書になるもの。開発の要となる重要な要素だけに、作成に苦労している企画者やディレクターの方も多いかもしれません。
特に海外で開発する場合は言語や距離の問題で依頼者と開発者の間の意思疎通が難しく、仕様書の重要性がさらに高まるでしょう。しかし、これは仕様書さえしっかりしていれば国内であれ海外であれ難なく開発を行えるということでもあります。
そこで本記事では、海外での開発においてプロジェクトマネージャーを担当し、「Pho娘」という自社サービスの開発に携わった筆者が、重要視している仕様書作成の注意点をお伝えていきます。
まずは、過去の案件を例に、悪い仕様書・良い仕様書を分析していきましょう。
目次
Webサービスやアプリの開発を進める際、「仕様書」という言葉を耳にすることが多いと思います。まずは、開発における仕様書の意味合いをおさらいしていきましょう。
仕様書とは「どこにどのような機能を持たせるのか」「どこからどのように遷移させるのか」といったプロダクトのあるべき姿を記載したもの。
受託開発の場合は受注側・発注側で一緒に協議しながら制作していくケースが多く、要件定義で定められた要求を満たしていることが求められます。
仕様書には複数の種類があり、「●●仕様書」のように目的や機能ごとの資料がさまざまな開発フェーズで展開されます。
「仕様書」と同様に、Webサービスやアプリの開発に欠かせないのが「設計書」。それぞれ意味合いや役割が異なるので、まずはその違いを整理しておきましょう。
「仕様書」は完成イメージを明確にした資料であるのに対し、「設計書」は完成するまでの制作工程を明確にした資料。
つまり「こんなWebサービスやアプリを作りたい」という要求に対し、仕様書は着地・結果を示すもので設計書は制作過程を示すものということです。
仕様書の意味合いを確認したところで、筆者の経験上「こういう仕様書は本当に困った」という“わかりにくい仕様書”の特徴を解説していきましょう。
Webサービスやアプリの開発経験が少ない人の場合、プレゼン用に作ったようなパワーポイントの資料(企画書)を仕様書と混同してしまっていることがあります。
「こういうことをやりたい!!」という戦略的な狙いは伝わりますが、これだけでは「どんなWebサービスやアプリを作りたいのか」という具体的なイメージが湧きません。
プレゼン時に制作した資料はあくまでも企画書としての役割で仕様書は別物ということをきちんと理解しておきましょう。
いくらミーティングでイメージを熱く語っても、メールやチャットなどのテキストベースで説明しても、イメージを深く共有することはできません。
「百聞は一見にしかず」とことわざにもあるように、図やビジュアルを用意して解説すれば相手にはっきりとイメージを伝えることができます。
特に海外で開発する場合、言葉の壁を乗り越えるためにも視覚的に訴えることが大切です。
例えば、筆者が手がけたアプリ「Pho娘」では、全画面に図とビジュアルを用いて仕様書を作成しました。下記に実際の仕様書の一部を掲載するので、ぜひ参考にしてみてください。
画面遷移はWebサービスやアプリを利用するうえでユーザビリティに直結する重要な要素。また、どのように遷移させるかという部分ではさまざまなケースが想定されることから、設計自体にも大きな影響を与えます。
あらかじめ遷移のイメージを持つことは非常に重要です。仕様書内に画面遷移図を用意してWebサービスやアプリの全体像や画面間の相互関係を明確にするといいでしょう。
仕様書の段階で不確定要素が残っているのはあまり望ましくない状況です。ざっくりとした曖昧な記述のままで開発が進んでしまうと、明確化しなかった行間の部分の工程で認識齟齬が生まれてしまう懸念があります。
国内で開発するのであれば、意図を汲み取って対応してもらえることもあるかもしれません。しかし、海外で開発する際に国内と同様の対応を期待するのは難しいです。
海外での開発においてコミュニケーションコストと品質低下のリスクを削減するためには、最初の段階から可能な限り要件を詰めておくことが大切です。
続いて、「この仕様書はやりやすかった」という“わかりやすい仕様書”の特徴を解説していきます。
「イメージ画像」と単に文字だけで記載している仕様書では、Webサービスやアプリの完成像を正しく伝えることができません。
あらかじめ仕様書内にイメージ画像を挿入しておくと、サービスの目指すべき方向性とビジュアル面のイメージ共有がより一層深まります。
「Pho娘」の仕様書では、下記のようにイメージ画像を挿入して仕様書を作成しました。
画面遷移図はリリース後のユーザーの行動・導線を把握するうえで重要な役割を担っています。事前にユーザーの行動パターンをしっかりと考えておけば、想定外のトラブルを起こりにくくすることができます。
念入りに画面遷移図を作成するのは工数がかかって大変ですが、のちのちのリスクを避けるためだと考えれば手を抜くことはできないはずです。
シーケンス図は、システムの設計を視覚的に把握するために用いられるもの。時間軸に沿ってクラス・オブジェクト間のやりとりを表現することができます。
ユーザーがどういうアクションをして、それに対してシステム側でどのように対応しているのかという一連の流れを把握しておくことはソフトウェア開発上で非常に重要です。
工数はかかってしまいますが、のちのち開発上の認識齟齬が生まれないように準備しておくことをおすすめします。
コンテンツの文字数制限、ポップアップ表示されるメッセージ、フォームの入力チェックの文言など、細かな部分まで仕様書に落とし込んでおくことも非常に有効です。
なかなか仕様書の段階で細部まで決めきれていることは稀だと思いますが、開発中のコミュニケーションコストの削減にもつながるので可能な限り確定している要素は仕様書内に落とし込んでおくといいでしょう。
ここまでわかりやすい・わかりにくい仕様書の特徴を解説してきましたが、実際に仕様書を書くときはどのようにすればいいのでしょうか?
筆者も頻繁に活用している定番ツールの紹介を通じて、仕様書の書き方を紹介していきます。
仕様書作成時に活用するワイヤフレームを書くときの定番ツールといえば「Moqups」。
ワイヤーフレームをブラウザ上で作成できるツールで、ドラッグ&ドロップが中心で操作性に優れています。
図形・アイコン・フォントの種類が豊富なので、「これはアイコン、これは背景画像、これはファイル選択ボタン」と配置すれば簡単にワイヤーフレームを書くことができるようになっています。
このツールを用いれば細かな部分まで認識をすり合わせることができ、エンジニアとのやり取りがかなり円滑に。「ラジオボタンがチェックボックスになって実装されてしまった」といった、ありがちな認識齟齬を防ぐことができます。
実際に筆者が「Pho娘」の開発に携わった際も、詳細なワイヤーフレームを作成するうえでMoqupsが大活躍。Moqupsに加えてフリー素材を活用して仕様書を作成したところ、デザイナーとの間でイメージを共有しやすくなりました。
仕様書に落とし込むのが難しい部分をカバーするのに便利なのが、プロトタイピングツール 「Prott」。
例えば、スワイプしたときに次の画面にどのようなエフェクトで遷移するのかといった「動作」を可視化することができます。遷移だけではなく、それに伴う動きや表現を確認できるのが最大のメリット。
仕様についての共通認識を開発チーム内で作る際に、非常に有効なツールです。
仕様とは、満たすべき要求事項のこと。その定義が曖昧になっていると成果物に対して認識齟齬が生まれてしまうため、仕様書は開発において“絶対的な存在”と考えた方がいいでしょう。
エンジニアもプロジェクトマネージャーも仕様書を基に開発を進めるため、あるべき姿である仕様がまとまっていないと良いプロジェクトとは言えません。
仕様が曖昧だと開発途中の仕様変更が生まれやすくなり、工数の増加につながります。さらに、仕様変更は発注者が考える以上にコストがかかる作業ということも見逃せないポイントです。できるだけ仕様変更が減らせるように、あらかじめいろいろなパターンを想定しておくことが肝心です。
もちろん技術的な知識が乏しいと難しい部分はありますが、ユーザーの導線を落とし込めているかどうかによって実装までにかかる時間が大きく変わることにも留意してください。
スタートが大切な開発において、あらかじめ準備できる部分は可能なかぎり整えておくことをおすすめします。
開発するアプリやWebサービスの完成した姿について、とことん思案できるのが仕様書を作る醍醐味。
「こんな機能があったら便利だろうなぁ」と思案したり、浮かんだアイデアを「どういった仕様で作る」という部分までしっかり落とし込むのはとても重要なことです。
アプリやWebサービスが成功を収めるための大きな鍵を握っている部分であることを忘れずに、しっかりと取り組みましょう。
★わかりやすい仕様書を作るための3つのポイント
① できるだけ詳細に書く
② 図や実際のイメージ画像を使う
③ 遷移やデータの扱い方などあらゆるケースをできるだけ具体的に想定する
お客様からのWebサービスやアプリの開発に関するお問い合わせ・お見積もりのご依頼を随時受付しております。
モンスターラボが提供するサポートの詳しい概要は、下記のボタンから資料をダウンロードしてください。
DX支援サービス紹介資料ダウンロード