飯野賢治さんのBlogによい話が載っていたのでメモ。 きみとぼくと設計。　〜最終回「仲間との開発」〜

例えば、なにか議題となる題材があったとして、それを誰かが投げる。

すると、僕が「うーん」と考える。場合によっては誰かに訊いたりする。 訊かなくても意見が出たりして、それに対して、僕が応えたりする。 最終的に、「こうしよう」というのを、僕が決める。

たったこれだけのことでも、どういうプロセスを踏んで どう僕が迷って、悩んで、それを、どういうふうに伝えて、そして その背景にはどういう理由があって、など全部伝わる。

というのと、結果の仕様だけ伝わる というのでは、僕は、ぜんぜん開発の最終形が変わると思います。

効率ではなく、結果を求めて、そのような形で進めたほうが 最終的には、実は効率がよくなる、のです。

効率だけを求めると、そこからこぼれ落ちる要素もある、と。

（全員参加のミーティングが）週に１〜２回ですから、ぜんぶで１００回以上......もっとかな？ あったと思うのですが、僕は、毎回毎回、「異なるお菓子」を用意しました。

なるべく、違うお店で買って。もちろん、美味しいお店で買って。

たぶん、３〜４回は、忘れててダブったこともあると思いますが いつもいつも、テーブルの上には、いつもと違うお菓子が、人数ぶん置かれていました。

どんなに忙しいときも買いにいきました。 お店を選んで、どのお菓子が良いかを考えて、季節なんかも気にしたりして。

そんなことが、「面白いものを作ろう」「ちょっとでも楽しくしよう」という ゲーム開発にとって、ものすごく大事な「考え」というものに入れ替わって みんなに伝わっていったと、僕は思っています。

飯野さんは日常のちょっとしたことろに、「遊び」の要素を入れるのが抜群に上手い人という印象があります。このお菓子のエピソードも、毎回違うお菓子を用意することでミーティン参加者が「今日のおやつは何だろう！」という気持ちになって、ミーティングに参加するのがちょっと楽しくなりますもんね。

僕の所属するWEB制作会社は人数がいないので大規模サイトの案件はあまりやらないのですが、ここ最近立て続けに大規模サイトのリニューアルのお仕事が来たので、気がついたことをメモしておきます。

（09/04/08：プログラマの友人からアドバイス＆指摘があった箇所を追記しました。）

1. サイト全体を俯瞰する資料を作るべし。

いわゆるサイトマップとかディレクトリ構成表とか呼ばれるものです。大規模サイトになるとこの手の資料を見やすく作るのはなかなか難しいですが、見やすい資料があればプロジェクトメンバー全員が同じ完成系をイメージしやすくなります。

※追記：資料を作るのにマインドマップを利用してはどうかというアドバイスをもらいました。今まではExcel、プレゼン要素が大きい場合はillustratorで作っていましたが、「FreeMind」などのマインドマップツールを利用して簡単に作って情報共有するのもアリですね。
【マインドマップ → 全体を把握しやすい】という特長があるので、【全体を把握する必要があるもの → マインドマップで作る】ということです。

2. クライアントがどのように更新するか。

クライアント自身が更新業務を行う場合、そのWEBリテラシーに応じて、
・普通のHTML+CSS
・DreamWeaverのテンプレ機能
・WordPressといったCMSを使う
といった、どの技術でサイトを構築するかを決めておきましょう。それぞれのメリット／デメリットをクライアントに説明しておくことも必要です。

3. 全ページのモックアップを作るべし。

ナビゲーションデザインやページ遷移、インフォメーションデザインを意識して作りましょう。
1ページのデザイン案だけでは分からない、サイト全体を見た上での問題をこの時点であぶり出しておくのが大事。
全ページ作るのがポイントです。そうしないと潜在的な問題点が制作後半まで分からないままになります。

4. グリッドを定義するべし。

PhotoshopおよびCSSでも、明確なグリッドデザインのルールを決めておく。そうすれば複数人で制作してもデザインやHTMLソースにブレが少なくなります。

5. 原稿を管理するべし。

クライアントからもらった原稿や逐次入る修正内容をチーム内で共有しておくのに、「GoogleSites」を使うと良さそうです。（まだ使ったことはないです。。）
メールでのやり取りだと情報が散らばってしまい、情報共有のコストが無駄にかかってしまいます。
また、GoogleSitesは上記(３)のモック制作にも使えそうです。
→GoogleSitesを使って制作プロジェクトをハックしよう

6. 全体のToDoリストをまとめるべし。

ToDoは細かく設定しておくこと。例えば「問い合わせフォームを作る」にしても、それがPHPなのかPerlなのか、フォームの項目は何か、入れる文章をどうするか等....
細かく設定しておかないと、見通せない部分が出てきます。

※追記：プロジェクト管理に「バックログ」がいいんじゃないかと。まだ試していないので何とも言えませんが、ユーザインターフェイスはいい感じです。

7. 早めに技術検証をしておこう。テストファースト。

使用する技術が本番環境でキチンと動くかどうかを、初期段階でテストしておくこと。後々になってダメでしたでは、泣きを見ます。

※追記：テストファーストじゃなくて、単なる「技術検証」じゃね？と指摘されました。僕の中でテストファーストという言葉が一人歩きしていました。。でも、「技術検証」を最初にやっておくのは大事ですよ！

8. ディレクターはディレクションしかするな。

案件の規模にもよりますが、ディレクションをする人が制作までやってしまうと、どうしても全体を見ることが難しくなるのでよろしくないです。 ディレクターは社内へのインプットと社外へのアウトプットをちゃんとフィルタリングする必要があるので、そこに精力を注ぎましょう。

9. 公開前のチェックをすべし

→サイト公開前に役立つ２５のユーザビリティチェックリスト:phpspot開発日誌

こちらのリンク先にチェックリストがまとまっていますが、公開前に気づいても遅いよ！というのが幾つかありますね。。画像のALTは以外と間違えちゃっていることが多いので、気をつけましょう。

10. 運用のガイドラインをまとめるべし

サイトの更新を社内でやるのかクライアントがやるのか、はたまた社外でやるのかによりますが、サイトを運用する上で、見出しに使用しているフォントや、写真データ・PSDデータを分かりやすくまとめておきましょう。CMSを組み込んだ場合は、使い方をまとめておきましょう。