ちょっと自分でもびっくりするくらい、人気あるこの記事。

Androidアプリ画面仕様書の書き方を提案したい
http://mesubuta.blog.jp/archives/36245870.html


「もうめっちゃ参考になりました!」とかって方がいたら申し訳ないんですが
正直、大したこと書いてねーなって思って。。。

なので、新たに提案します。


1.画面仕様書が重要なワケ

どこのプロジェクトもこうとは言い切れないですが、私が経験した職場だと
・そもそも仕様書がない
・テスト項目書に載ってる指示が仕様書に書いてない
・全部口頭、ドキュメントが残ってない
なんてことがザラでした。

複数の機能を持つアプリは、1画面の仕様がとにかく膨大になります。
表向きの機能が少なくても、入力制限があったり、キャッシュの有無で表示が変わったり。

例えばTwitter公式クライアント。

入力して、添付して、送信するだけの簡素なものに見えますが
実際は

・140文字制限
・下書き保存
・サムネイル表示
・ギャラリー、カメラとの連携
・他アプリ(Live配信)連携

など、考慮する点が沢山あります。

これらをイメージ通りに、正確に開発するために必要なモノが、画面仕様書です。



2. 誰が作るべきか 〜 "How to do it" is better question than "who do it" 〜

非常に悩ましい問題。

ディレクター、デザイナー、エンジニア、プランナー
それぞれに長所と短所があります。
その人の性格にもよるでしょうし、言及はしませんが
ここでの問題は「誰に任せても、イレギュラーケースなどの想定漏れは発生する」ということ。
しょうがないよね 人間だもの。

現実的なのは、Who?(誰が?)よりHow?(どうやって?)を探る方だと思います。
「誰か=作成責任者」を決めて叩き台を作り、会議を重ねて
ブラッシュアップしていけるのが望ましい。

それでも、開発工程に入ってからの「ねえ、これ、抜けてない?」は多いです。
そして、より良い画面仕様書作成の最大の壁がこの
想定漏れ・抜けによるエンジニア・デザイナーの手戻り、待ち状態の発生。

誰だって無意味な作業は極力減らしたいわけです。



3. 書き方の注意事項的なところ


社内に規定のテンプレートがある会社は少ないと思う、大手以外は特に。

ただ、最終的な作り手であるエンジニアからすると、正直読み方が統一されてさえいれば
よほどのこと(ぐちゃぐちゃで読みづらいとか)がない限り大丈夫です。

逆に困るのが、「前のページはこうだったけど次のページは違う」みたいなやつ。
「10桁未満」と「9桁以下」が入り混じってるのとかマジでもう、マジで。

そんなこと言うと「エンジニアって細かい」という声が聞こえてきそうですが
だいたいのエンジニアは「10桁未満」て言われたら hoge < 10 と書くし
「9桁以下」って言われたら hoge <= 9 と書きます。
だから入り混じってるとプログラム内で書き方が統一されなくて、こういうの
意外と不具合の元凶になりやすいです。



4. 実際どういうのがほしいのよ


実践の話。

AndroidもiOSも、基本「UI(見た目)」と「機能」をどやこやする方法が分離しています。
ざっくり言うと、XMLとAutoLayoutはUIを定義するもので
JavaやSwiftのプログラムファイルは機能面を定義するのがメイン。
プログラムでコンポーネントを動的にあれこれできるので、プログラムのほうが「何でも屋さん」です。

なので、同じ1画面の仕様書としては
・UI面についてのこと
・機能面についてのこと
両方が網羅されている必要があります。

また、エラーとして弾く条件や、イレギュラーケース(メンテ、サーバーダウンなど)についての情報も。

実例を挙げると、UI系の例なら
アニメーションの定義とか。
ここタップするとプルダウンで下にコンテンツが伸びて表示される、とか。

機能系だと
送信ボタンを押した時、入力文字数が少なかったらエラーを返してアラートを出すとか。
リフレッシュコントロール機能がある、とか。

これを、1画面のデザイン画が貼ってあるシートにずらっと書くのか
デザイン指示/機能指示でそれぞれ分けるのかはPJの方針によりけりかなあ。
形式はパワポだったりExcelだったりするんですが、個人的にはやっぱり、どちらでも良いです。

まとめ
  • 見た目についての仕様
  • 機能についての仕様
  • イレギュラーケースとして弾く条件
  • サーバーメンテナンス時の見せ方など、アプリ全体としての方針
が必要。


5. 最後に


アプリはウェブシステムと違い、担当エンジニアが少人数です。
厳密なフローチャートよりも、今書いているコードで品質を満たしているのか?の
確認項目のほうが役に立つことが多いでしょう。

実際のところは、自分のチームメンバーと相談しながら作っていくことになりますが
前提条件として参考にしていただければ幸いです。

すべてのエンジニアが定時で帰れる世の中になりますように。