【現場で当たり前に使う知識】要件定義/設計/デザイン編

※前回の記事を先に読むと理解が深まります。

「仕事の流れはなんとなくわかったけど、具体的にどうやるんだろう？」

「このまま現場に入っても大丈夫かな？」

そんな不安を感じてはいませんか？

ここでは現役エンジニアである筆者が当たり前のように使っているノウハウをお教えします。

もちろん自分で実際に経験して慣れていくことは必要ですが、

知ってるのと知らないのとでは雲泥の差があるでしょう。

今回は前編として要件定義/設計/デザインの3つを解説していきます。

１．要件定義
まずはどんなサイトにしたいのかをヒアリングし、文章や資料にしていきます。

・どんな人が利用するのか(性別、年齢、居住地域、好みなど)

・いつ利用するのか(朝の準備中、昼休み、夜ゴールデンタイムなど)

・なんのために利用するのか(悩みを解決したい、生活基準を上げたい、緊急で必要など)

基本的には上記のような、所謂5W1Hを基にヒアリングします。

また、雑談から思わぬヒントやサイトの根本となるべきテーマが見つかる場合もあります。

例えばビールの新商品LP案件で、「この商品、ドイツの○○ってビールと味が似てるらしくて…」というような雑談が出た場合、

「本場ドイツの○○ビールのような味わい」というキャッチコピーを見出しやバナーに入れたり、ドイツの国旗や現地のビアバーの写真素材を使ったり…という提案が出来たりします。

２．設計
お客様から聞いた要件を、具体的にどう作っていくかを設計します。

例として一般的な会員登録画面を想像してみてください。

画面としては「入力」「確認」「完了」の3つ。

入力画面の機能としては「初期表示」「エラーチェック」「確認画面への遷移」

確認画面は「入力項目の表示」「入力へ戻る」「登録して完了画面へ遷移」

完了画面は「データの最終チェック」「データベースへの登録」「完了メッセージ表示」

この辺りが最低限上がってくると思います。

上記のように、プログラムをどういう構造で、どういうパーツ(機能)に分けるのか。
各パーツはどういう機能を持たせて、どういう時に使うのかを考えていく作業が設計です。

プログラミングはプログラム言語で書きますが、設計は日本語で書きます(考えます)。

プログラミングはハードルが高いかもしれませんが、日本語であればできるはずです。

一般的なサイトを参考に骨組みを考えていき、クライアントの要件を満たすような設計をしていきましょう。

３．デザイン
概要の記事で、基本はノータッチですと書きましたが、可能であれば携わりたい工程でもあります。

理由としては、最初の要件定義でクライアントからいくら要望を聞き尽くしたとしても、実際にデザイナーがデザインした画面を見ると、細かい要望が新たに出てくる場合がほとんどだからです。

プログラマー視点だと、要件定義から設計を考えていたのに、デザインを見たら聞いてない仕様が追加されている…プログラマーあるあるです(笑)。

人間は言葉や文章だけよりも画像や模型がある方がイメージがつきやすい生き物なのでこれは仕方ありません。。

逆を言えば、要件定義の際にも、ある程度の画面イメージや操作方法などが資料としてあると、認識のズレが起こりづらくなります。これを専門用語でプロトタイピングといいます。

４．プロトタイピング

私の経験上、大規模な会社や老舗企業はプロトタイピングをやりたがらないです。

理由はいくつかありますが、主に社員の役割分担がきっちりしている弊害でしょう。

要件定義はディレクターがやるもの、デザインはデザイナー、開発はプログラマーとなると、要件定義の段階でデザイナーやプログラマーを同席させづらいのです。

今私はフリーランスで主に個人でやっているので、このあたりは流動的にやっています。

最初の依頼がメールやチャットで来て、ある程度のイメージが浮かんだらもう簡単な画面と疑似サイトを作ってしまいます。

そしてそれを基に本番の要件定義を行うのです。まさにプロトタイピングですね。

そうするとお互いのイメージが統一され、クライアントからの要望も出やすくなり、誤解も減ります。

もし今後入社する企業でこういった手法が取られていたら当たりだと思っていいでしょう。

まとめ

・要件定義

・設計

・デザイン

・プロトタイピング