• 日本語
  • English
  • 中文
MENU
CREATE A PLATFORM FOR DIVERSITY
Web, Game, App, Illustration
https://monstar-lab.com/
Blog
2017/07/01
アプリ事業開発を失敗させないプロトタイピング

Manager analysiert das Unternehmen

(編集部注*2014年6月4日に弊社運営メディアSEKAILAB TIMESで公開された記事を再編集したものです。)

近年、新規事業開発をする上でスマホアプリやWebサービスといったデジタルプロダクトを開発したいというお問い合わせを多く頂戴しています。2014年頃に比べると大手企業様も含めて新規事業開発=デジタルプロダクトというパターンが多くなってきているように感じます。その一方で過去にデジタルプロダクトを利用した事業開発の経験がある方々はテスト・検証で発覚する不具合とその対応にお困りになったこともあるかと思います。そういった苦い思い出をお持ちのまま新規事業開発の担当になった際には、デジタルプロダクトの開発会社選定に慎重になるかと思います。

mistake-1966448_1920

テスト・検証で発覚する不具合の30~40%は、仕様書段階での「抜け・漏れ」「認識齟齬」が原因と言われています。

もしあなたが開発会社から仕様書を渡されたとき、自分は事業開発の担当でシステムやプログラムのことはよくわからないから…、プロが作ったから大丈夫だろう…といった考えでいると、事業開発自体に影響を及ぼすような取り返しのつかないことになってしまうかもしれません。しかし、こういったテスト・検証のタイミングで発覚する数々の問題は事前に気をつけるポイントを知ることによって発生確率を大幅に下げることが可能で、ひいては事業開発の成功確率を上げます。そこで、今回は事業開発の担当でシステムやプログラムのことが全くわからない人でも「落とし穴」を見つけられる、仕様書を読むときに気をつけたい3つのことを紹介します!

1. 説明文が簡潔で一意的になっていることを確認する。

computer-2048983_1920

多義文という言葉をご存知でしょうか。多義文とは一つの文が文法的に多様に解釈できる文章のことです。例えば「黒い目のきれいな女の子」という文は、8通りの解釈をすることができます。同じ文を読んだのに、人によって捉えた意味が違うというのはとても恐ろしいことで、認識齟齬が発生する原因になります。他にも、二重否定(〜ないわけではない)婉曲表現(〜しなくてもよい)、様々な形式のある言葉(日時, 数字表現)などの曖昧な表現には注意しましょう。

こういった日本語の曖昧表現は、1人で読んでも気づかないものです。そこで、ペア・プログラミングならぬペア・リーディングをしましょう。事業開発チームメンバーや開発会社の人間と仕様書を読みながら、怪しい部分は「声に出して」確認することです。自分の頭の中で勝手に解釈し納得せず、お互いに確認することが大切です。これは開発の仕様書だけではなく事業開発やもっと小さいプロジェクトでの意思疎通にも言えることですね。

2. 要求に対する説明に「抜け・漏れ」がないかを確認する。

Design Team Planning for a New Project

例えば、ECサイト案件にて「自社DBに入っている商品画像を引き出して表示して欲しい」という要求があり、あがってきた画面仕様書には正方形の枠に「貴社DBから該当する商品の画像を表示する」といった説明文のみがあったとします。一見、これで良いように思えますが、

  • 正方形の枠のサイズに対して、商品画像が大きい場合はどうなるのか、小さい場合はどうなるのか。
  • 商品画像が正方形ではなく長方形の場合はどうなるのか。(長辺合わせなのかトリミングされるのか)
  • 商品画像がない場合はどうなるのか。

といった項目を確認する必要があります。もちろん、「我々は事業開発に注力したいから細かい部分は開発会社に全て任せる。後で文句は言わない」スタイルであれば構わないのですが、そうでなければ細かい部分まで確認してください。「◯◯の場合はきっとこうなるだろう…」と頭の中で考えるだけでなく、書いてあること以外は何も決まっていない、という体で疑問があればどんどん口に出しましょう。口うるさい人だな、と思われたくないかもしれませんが、最も回避すべきことは仕様の「抜け・漏れ」による事業開発の失敗です。どんどん質問しましょう。相手がいいサービスを作りたいと思っている開発会社であればあるほど、その方が嬉しいはずです。

3. 仕様書を信じ過ぎない。

hand-65688_1920

ここまで書いておいてなんだそりゃ!となるかもしれませんが、完璧な仕様書を書いたとしても、認識齟齬が発生する可能性はゼロではありません。仕様書通りに開発し、テスト・検証で実際に触ってみたときに「なんだか思っていたのと違う…」となってしまっては手遅れです。そこで私は、プロトタイピングをオススメします。

特にスマートフォンアプリの場合は、ドキュメントで仕様やデザインを見て確認しても、実機で見てみると印象や使い勝手の違いを感じることがあります。その違和感が問題にならないものであればいいのですが、事業開発における核の機能だった時には目も当てられません。そこで、まずはプロトタイピングをして確認しましょう。ペーパープロトタイピングであれば、そこまで多くの時間や費用はかからないはずです。仕様策定の段階でペーパープロトタイピングを、開発が進んだら機能毎にプロトタイピングしたものを触らせてもらい、逐次フィードバックし認識合わせをすることで、大きな落とし穴に落ちずに事業開発を進めることができると思います。

ここで、直感的でわかりやすい!ペーパープロトタイピングの制作に役立つWebサービス(基本無料)を紹介します。

POP

pop

 https://popapp.in/

[browser-shot url=”https://popapp.in/” width=”810px” height=”405″]

 

Flinto

flinto

 https://www.flinto.com/

Prott(日本語対応)

prott

 https://prottapp.com/

InVision(PCも可能)

InVision

 http://www.invisionapp.com/

[browser-shot url=”http://www.invisionapp.com/” width=”810px” height=”405″]

 

FileSquare(PCも可能)

FileSquare

 http://filesq.com/

[browser-shot url=”http://filesq.com/” width=”810px” height=”405″]

 

以上が、仕様書を読むときに気をつけたい3つのことです。とにかく大事なことは「頭の中だけで考えて納得せず、必ず相手と確認をとること」と「自分がユーザーまたは運営側になったときのことを想像して読むこと」です。それでは、皆さんが良いアプリを幸せに開発できますように。

執筆:岸  泰弘/編集:竹内 英人

 

Archives