WEB制作における心得というかポイント。
WEB以外にも置き換えられますけど、まぁシステム周りからデザインまで網羅的な分野が関わるということでWEB制作ということにしておきます。社会人になるにあたって1つテーマとしていたことは、WEB制作全般に関して受注側から発注側になることで相互に抱えていた諸問題を解消できればと考えていました。諸問題を言及すると仕事の愚痴になってしまうので詳しいことは割愛しますが、諸問題によって手戻りが起きたり、なかなか効率的にプロジェクトが進まなかったり、やたらと属人的な運用が残っちゃったりします。（表向きはなんてこと無いよって感じですが）
発注側に回ったことで多少諸問題を解消できるかどうかうにゃうにゃと考えていたのですがなかなか解消されないので正直なところです。そんな中で品質管理的な外部講習を受けることができ、そこでのレクチャーやディスカッションで、勉強になった部分もあれば、「結局無理だよねー」と解消されなかった課題もありました。とはいえ、ある程度考え方がまとまった気がしたのでいくつか「心得」としていくつかポイントをピックアップしておこうと思います。
1.まず「目的」と「目標」を立てる
企画書段階で「このプロジェクトのコンセプトは～」という流れがありますが、コンセプトってつまるところ「目的」と「目標」をたてることそのものだと言えます。「目的」は言い換えるとそのWEBサイトの存在意義になります。タグでいうところのヘッダのディスクリプションに書けるような一文がそれにあたります。「目標」はというと、例えばプロモーションサイトであれば「PVを○○までに△△を達成する」ですとか、EC系のサイトであれば「1年後に売上○○達成する」ですとか、具体的数値を用いたものになります。営業計画（目標）そのものとも言えますし、予算の規模にも関わってきます。受注側であれば企画書に具体的な数字が入っていなければバシバシ突っ込んでもいいと思います。
そして、思いつきで制作が進行していないようにするためにも、「目的」と「目標」常に意識できるようにMTG資料には必ず盛り込むですとか、ホワイトボードがあれば張り出しておくのも良いと思います。
2.中間生成物の作成を惜しまない
プロジェクトに関わる人間が多ければ多くなるほど意識・理解の食い違いはどうしても発生します。言葉の齟齬も多々あります。そこでその間を埋めるためには「中間生成物」（資料）が必要になります。映画でいえば脚本や絵コンテのようなもの。モックや状態遷移図であったり、特に発注者側がWEBに詳しくない時はあらゆる手段で意識・理解をすり合わせることが重要だと思います。で、発注者側はその中間生成物に対して「どこまで突っ込んでいいのか分からない」といった時がありますが、（もちろん段階に応じてその中間生成物のレベル感もまちまちですから）基本的には疑問に思ったところはすべて受注者側にぶつけて良いと思います。受注者側が判断してタスクを整理すればいいことですし、今いうことじゃないでしょ的なリクエストがきてもリマインドにもなりますし。
3.お互いの実力を知っておく
発注者側からいうと、依頼先のメーカーの実力というのもありますし、プロジェクトに関わるメンバーの実力・経験・スキルを把握しておくことが重要だと思いました。実績を見ることでだいたい把握することができます。ただし、経験豊富なメンバーに仕事が集中してしまい属人的になってしまう懸念もありますが、逆に足りない経験やスキルも分かるので、教育計画にも繋がっていきます。
4.形容詞だけを使わない
これはレクチャーの時に聞いて目から鱗でした。発注者側にも受注者側にも教訓として言えることです。とかく「もっと速く」とか「ここはかっこよく」とかリクエストしたり説明しがちですけども、数値化きるものはとことん数値で管理していく方が意識・理解の差異を小さくすることができます。数値化できないものはどうするかというと、専門家に任せるまかせるしかありません。で、あまり文句は言わないこと。素人のコメントでも、受注側はあくまでもクライアントの意向をくみ取るのが仕事ですし頑張ってくれます。そもそもそこで気に入らないのであれば、発注先の選定を間違えていることになりますから、ちゃんと実績を見て選びましょうということになります。
5.大人数でのアジャイルはやめた方がいい
プロジェクトメンバーが少人数でないとまず無理かなと。具体的にいうと下請け含めても5人以内。それ以上の人数が関わる場合はちゃんと管理していかないと後々苦労します。あくまでアジャイルはあくまで短期間に開発するための手段のようなものなので、２～３ヶ月以上かかる場合はそもそも選択肢としてはあり得ないですし、もっとメンバーが多くなります。大規模なんだけど速い開発がしたい場合は、規模を縮小するという選択をとった方が先決だと思います。それが難しい場合はスーパープログラマーなんかと捕まえるしかありません。
個人の制作やプロジェクトは1人であったり気心しれた友人同士で行うことが多かったので、プロセスをあまり気にすることはありまりませんでした。（正確に言うと、プロセスは習ったり調べたりして知識としては知っていましたが、大枠のフローは守るものの、がっつり設計してからがっつり制作するよりは、作りながら修正していった方が断然速かったですし、方法論に縛られすぎて窮屈な思いをしたこともあります。）社会人になってから痛感した5つのポイントということになります。