2012年3月15日木曜日

非エンジニアがどのようにエンジニアに指示を出すべきか

出張中の飲料水333
非エンジニアにとって、プログラムはそれ自体がまったくわからない外国語のようなものといえるでしょう。エンジニアにどう指示を出せば、自分が思う様なアプリが出来上がるのか想像もできないのです。

過去に仕事でエンジニアと関わることがあったり、開発会社に外注依頼をしたことがあったりすると、ちょっとは要求定義の仕方が分かっているかも知れません。ですが、自分で直接エンジニアに指示を出すとなると、SEが間に入ってくれる外注仕事とは違い仕様を自分できめる必要があります。
もちろんすべてをきちんとエンジニアの要求とおりに仕様決めすることはできないでしょう。私もできません。では、どうすべきか。
私見ですが、少なくともメインとなる機能の動きを事細かにシミュレートして、絵に描けるくらいにまで分解しておけば、エンジニアがどのようなコードを書けば実現できるか想像できる仕様書に落とせると思います。

以下は、私の実例です。
私はSEが作る様な仕様書は書けません。何度かチャレンジしたことはありますが断念しました。仕様書を書く代わりに、主にワイヤーフレーム(画面遷移図)やフローチャートを作ります。それとそのアプリがどんなことをどのように実現するかの企画書で、フローチャートでは表せない「中身」を事細かに書いておきます。

ワイヤーフレームは自分で思いつく限り、細かく遷移を書きます。どこに何をどう入力し、どこにどんなボタンがあり、ボタンを押すとどの画面に移り、そこで何が起こるか。すべてのインターフェイスに対し起こせるアクション毎に、その先の画面や出力内容を書いていきます。画面遷移に表せない裏側の処理などは、吹き出しで該当するところに細かく記入していきます。
ワイヤーフレームを作るときは、最初は手描きでもいいでしょうが、できればなるべくツールを使ってパーツなども実物に近いイメージで作ると良いでしょう。私は以前はパワポやVISIOを使っていましたが、今はcacooを使っています。cacooにはiPhoneやAndroidのパーツがステンシルとして登録されているので、アプリのワイヤーフレームを作るのにはとても適していると思います。
手描きからcacoo等で清書してみると、ボタンや他のパーツの配置が意外と大変なことに気が付きます。手描きだと描きながら都合のいいようにパーツを勝手にデフォルメして配置しがちですが、往々にして、そのままではユーザビリティが最悪になります。コーディング時に「こんな筈じゃなかった」と後悔しないように、なるべく早い段階で実物を想定したワイヤーフレームを作ることを強くお勧めします。

可能であれば、その段階でプリントアウトしてプロトタイプを作り、データを入力したりボタンを押して(もちろん真似だけ)、画面が遷移する場面でその画面の紙にしたりしながら、ユーザビリティのチェックをするべきです。できれば第三者にも協力してもらって忌憚の無い意見を貰っておきましょう。

どうしてもワイヤーフレームに落とし込めない、またはどのような画面にすれば実現できるか思いつかないものは、何をどうしたいかをなるべくこまかくフローチャートに整理しておきます。そして実際の制作段階に入る前に、素直にそれを見せて、どうすればプログラムでそれが実現できるか、エンジニアと相談してください。
間に営業さんがいる場合には、その営業さんに事前に相談するといいでしょう。開発会社の営業にはエンジニア出身の方が結構いらっしゃるので、もしそういう方がいればどんどん相談してアドバイスももらっておくと、後の工程がスムーズにいくと思います。

そうしてエンジニアには企画書とワイヤーフレームとフローチャートなど作った書類をすべて渡して、自分がどんなことをやりたいのかを理解してもらいます。そのうえで質問があれば(普通あると思います)質問をしてもらい、お互いが理解できたところで制作に入ります。

今まで程度の違いはあれ、ほとんど以上のような流れでエンジニアと仕事をしてきました。
おそらく足りないところを都度都度エンジニアさん達が補完してくれていたので、これでもなんとかなっていたのだと思いますが、なんとかなっていたのは事実なので、他の方でも応用できると思います。

さて、どんなサービス(アプリ)を作りたいか分かったところで、次は、開発言語や開発環境はどうするの?ということになると思います。
もしかすると、ここで「ん?何それ?」となる非エンジニアがいるかもしれないので、次はその辺を書きますね。

0 件のコメント:

コメントを投稿