「仕様書」とはWebサービスやアプリを作る上での開発者に対する説明書となるものです。開発の肝であり、作成の際に苦労する企画者やディレクターも多いかもしれません。
さらにオフショア開発の場合には、言語や距離の問題により、依頼者と開発者の間の「阿吽の呼吸」というものを期待することは難しいため、仕様書の重要性はさらに高いと言えるでしょう。
逆に言えば、これさえきっちりと行えていれば、オフショアでも難なく開発を行えるということでもあります。
そこで、今回のコラムでは、オフショア開発のプロジェクトマネージャーを担当し、さらに「Pho娘」という自社サービスの開発にディレクターとして携わった筆者が、両者を経験した上で大切だと感じた、仕様書作成に置ける注意点をお伝えしたいと思います。
まず過去の案件を振り返り、悪い仕様書、良い仕様書を分析していきましょう。
こんな仕様書は嫌だ！！
プレゼン用のパワポ資料（企画書？）しかない
「こういうことをやりたい!!」というのはわかりますが、何を作りたいのかという具体的なイメージは湧きません。
図がない
オフショア開発で言葉の壁を乗り越えるためには、視覚的に訴えることが大切です。
→例えばPho娘では、仕様書の全画面に、図を用いて作成しました。
画面遷移のイメージがない
画面遷移はユーザビリティに直結する大切な部分です。また遷移では様々なケースが想定され、それにより、設計自体も影響を受けます。あらかじめ遷移のイメージを持つことは大切です。
すごくざっくりしてる
オフショアでコミュニケーションコストと品質のリスクを削減するなら、ここでできるだけの要件を詰めておく必要があります。普通の開発なら、行間を読んで勝手に処理してくれるという場合もあるかもしれませんが、オフショア開発にこちらを期待するのは難しいです。ですので出来る限り最初の段階から要件を詰めておくことが大切です。
この仕様書はすごかった！！
イメージ画像が入っている
「イメージ画像」という記載のみの場合と、本当にイメージ画像が入っている場合とでは、アプリやサービスのイメージが変わってきます。
→例えばPho娘では、イメージ画像をこのように入れて作成しました。
遷移図がめちゃくちゃしっかりしてる
遷移図をしっかりと書くことは、ユーザーの行動をすべて把握する上では必須になります。ここで時間をかけていろいろなパターンを考えておくことは、後に想定外のことができるだけ起こらないようにするために必要です。
シーケンス図までつくってある
ユーザーがどういう行動を起こすかという部分についてはソフトウェア開発上では非常に大切な部分になってきます。ここはある程度作っておくと、後々、開発上の認識の相違が生まれないために、役立つでしょう。
APIの使用箇所、APIの分類についても詳細にまとめてある
開発で必須になってくる裏でのデータのやりとりは、あまり重要視されませんが、開発者が最も気にする部分でもあります。
文字数制限などについても説明がある
これはあくまで一例ですが、こういった細かい部分まで気が使えている仕様書は大変開発がしやすく、開発中のコミュニケーションコストも削減されます。
ポップアップのメッセージ、バリデーションの文言まで決められている
ここまで決めている人はなかなかいないですよね笑
これが使える！仕様書のためのお役立ちツール！！
では実際に書く際にどうすれば良いのかといったことを紹介していきましょう。
ワイヤフレームを書くときに使えるツール
ワイヤフレームを書くときの定番ツール「Moqups」
「これはアイコン」、「これは背景画像」、「これはファイル選択ボタン」ということが簡単に設定できます。これをうまく使えば、エンジニアとのやり取りはかなり円滑になります。こういった細かい部分の認識が違っていると、例えばラジオボタンがチェックボックスになって実装されているなどの問題が起きてしまいますので。。
※Pho娘でもこのサービスを用いており、詳細なワイヤーフレームを作成する上で大変役に立ちました。
Pho娘の場合、Moqupsに加え、フリー素材を用いて仕様書を作成しました。これでデザイナーとのやり取りにおいても、イメージを共有しやすくなりました。
動作の確認のために使えるツール
プロトタイプアプリの決定版 「Prott」
仕様書になかなか書けない部分もあります。例えばスワイプした時に次の画面にどのようなエフェクトで遷移するのかといったことです。これを解消するのが、プロトタイプ作成サービスです。これは遷移のみならず、「動き」についても表現することが可能で、オフショア開発において、仕様についての共通の認識を作る上で非常に有効なツールであることは間違いないです。
※プロットについての詳しい記事はこちら→Prottはオフショア開発でも役立つスマホアプリ開発ツールの決定版
仕様書が何故プロジェクトの成否に関わるのか！？
仕様の定義が曖昧な場合、成果物に対して認識の齟齬が生まれます。
仕様書とは、開発において、絶対とすべき存在です。エンジニアもプロジェクトマネージャーもこの仕様書を元に開発するので、この仕様がまとまっていないプロジェクトはあまりいいプロジェクトとは言えません。
仕様が曖昧だと、途中の仕様変更などが生まれやすくなり、工数が増える場合があります。
仕様変更は発注者が考える以上にコストがかかる作業です。できるだけ仕様変更が減らせるように、あらかじめいろいろなパターンを想定しておく努力が必要です。
仕様書の記述が不十分な場合、要件定義に時間がかかります。
もちろん技術の部分がわからないと難しい部分はありますが、ユーザーはこういった順序で登録して、次はここに遷移してということをあらかじめ落とし込めている場合と何も用意がされていない場合とでは実装までにかかる時間がだいぶ変わってきます。スタートが大切な開発において、あらかじめ用意できる部分は用意しておくことをお勧めします。
※仕様書をつくる楽しみ/醍醐味
仕様書を作る醍醐味は実際にアプリやサービスができたときのことを想像することではないでしょうか。こういった機能があったら便利だと考えることであったり、それを実際にどういった仕様で作るのかというところまで落とし込んだりと、仕様書作成はアプリやサービスの成功の大きな鍵を握っている部分であるという気持ちで行いましょう。
まとめ
オフショア開発でいい仕様書をつくるための３つのポイント
1.できるだけ詳細に書く
2.図や実際のイメージ画像を使う
3.遷移やデータの扱い方などあらゆる場合をできるだけ想定する
オフショア開発の仕様書の注意点
1.なんとなくは通じない。
エンジニアがなんとなくやってくれるだろうは、通用しません。必要な情報はすべて載せれるように努力しましょう。
2.後からのやり直しは工数が大きくなる
上流の工程の中でできるだけ、問題をなくしておく、その過程を仕様書作成の中で行えるようにしましょう。
以上が、オフショア開発にプロジェクトマネージャーとディレクターとして携わった私がお勧めする、仕様書作成術でした。
オフショア開発は難しいと思われている方もいるかもしれませんが、多くの問題は、上記のように最初のステップでいつもより少し力を入れて仕様書を作成することで、解決ができ、思った通りのサービスが作れると思っています。これが現地で実際に自分のサービスを作ってみてわかったことです。
今回の記事で何点か例としてあげさせてもらっていた、「Pho娘~ベトナム美女が食レポ!?~」というアプリがリリースされています。このような仕様書で作成したアプリをぜひダウンロードして見てみてください。
もしくは「Pho娘」で検索！
アプリを作ることになったら読むe-Book「アプリ開発AtoZ（企画〜発注編）」
スマホアプリを企画中の方向けに、アプリの企画・設計・発注までをまとめたe-Bookを作成しました。実際にアプリ開発の現場で使われているノウハウが満載です。無料なので、この機会に是非ダウンロードしてみてください。もっと詳しい内容をみる