こんにちは、ディレクションチームのリーダーを務めている西城です。

以前、「お客さまとの距離を知り、伝わる言葉を選ぶ」というお話をさせて頂きましたが、今回は制作側の、特に社内のコーダーへのコミュニケーションについてお話をします。
 

ゴールを共有する

ディレクターからコーダーに作業を依頼する際、まず初めにキックオフミーティングを開催します。キックオフミーティングとは、プロジェクト開始時に行なう会議で、プロジェクトの概要や目標、スケジュール、体制などを共有する場のことです。

キックオフミーティングではゴールまでのイメージを共有するために、主に次のようなドキュメントを用意します。これらを用意することで、これから始まる制作期間の中での認識のズレを防ぎます。

• プロジェクトの概要（リニューアルする企業の事業内容、サイト制作の目的、ゴールなど）
• サイトマップ
• ワイヤーフレーム（画面構成図）
• デザイン指示書
• サイト基本仕様（対象OS・ブラウザ、推奨画面サイズ、最低動作保証解像度、印刷時レイアウトについてなど）
• スケジュール
   

CMSが必要なサイトは下記の仕様書を用意します。

• フロントエンド（ユーザーから見える表示側）
• バックエンド（管理画面側）
   

※CMSとはHTMLやCSSなどの専門知識がなくても、Webサイトコンテンツの更新と管理を行うことができる仕組みのこと。

これらのドキュメントを用意する上で、気をつけていることがあります。
それは、コーダーが迷わず実装できるレベルのドキュメントに仕上がっているかどうか。ポイントは、誰が見ても迷わないか。人によって感じ方が異なると、本来辿り着くべきゴールから外れてしまう可能性があります。迷わせてしまうと、その分コーダーに負担をかけてしまうので、充分注意してドキュメントを用意する必要があります。
 

コーダー側のチーム体制を理解しておく

社内であっても、部署によって、チームの体制は異なります。案件を円滑に進めるためには、キックオフの前にまず、コーダー側のチームの体制、役割を抑えておく必要があります。

チームではどのようにプロジェクトを管理しているか、リソース、制作者のフォローなど、事前に踏まえておくことで、チームや制作者に合わせた個別のフォローアップができるようになると思います。

コーダーと直接やりとりを行っていると、ついコーダーになんでも相談しがちです。

実際、過去にコーダーに、コーダー側のチームのリソース状況を把握しないまま、追加要件を相談したことがあります。コーダー自身は相談にのってくれて、初期要件で見積もったスケジュール内で対応してくれようとしました。しかし、結果として、当初予定していたスケジュールでは収まらなくなり、
コーダーに負担をかけてしまいました。

そのため、初期の要件からクライアントの要望が膨らみ過ぎていないか、クライアントの要望が初期の見積工数の中に収まっているかを常に注意して、コーダー側に想定外の過度な負担がかからないようにして、ディレクションを行なう必要があります。

チームの体制を理解しておくことで、案件によってディレクションルールを変えるなど、柔軟に進めていくことが大切です。
 

「質問がない＝理解した」という思い込みを外す

キックオフミーティングに限りませんが、打ち合わせの場で、案件の説明に対して、ある程度説明した段階で制作者から質問が出てこないと、つい説明したことを理解してもらったと思いがちです。

しかし、そもそもの前提条件が違うなど、制作者がこちらの意図とは違った認識を持ったまま、制作がスタートしてしまうこともあります。

例えば、モノサスの案件では、WordPressやMovableTypeといったシステムを利用することが多く、基本的にはフロント及びエンドの両方の仕様書を用意します。

但し、基本機能を利用するようなレイアウトの場合は、フロントの仕様書のみを用意して、コーダー側とすり合わせながら行う開発もあります。

過去に、基本機能以外のレイアウトでしたが、フロントを用意せず、キックオフに臨んだケースがありました。問題なく進められるように見えましたが、開発終了間際になって、コーダーが具体的なイメージを描けていないことが分かり、自分のイメージの伝え方やフォローの方法が悪かったことを反省した経験があります。

当時、管理画面の仕様書を用意しなかった理由は、私の方でイメージしていた入力画面には足りない点があるように思え、もっと操作しやすい画面があるのではとの懸念があり、叩き台としては用意せず、確実なフロント側の仕様書のみを用意して、説明をしてしまいました。

今から思えば、不安材料含め、ディレクター側でイメージしているものをすべて形にして起こし、それを叩き台に議論したほうがコーダーの迷いは少なかったのではと思っています。
 

まとめ

今回は、初めて一緒に制作を行なう人（チーム）とのコミュニケーションについてお話ししましたが、いつも依頼する人（チーム）においても、これらのポイントを生かしていくと、より品質のいい仕事に仕上がるのではと思います。

そういえば、昔システム開発会社にいた頃に、あるプログラマーから教わったことを思い出しました。

設計書は誰が見ても分かるようなものでなくてはならない。
こんなことまで書かなくてもわかるであろうという思い込みが
一番危険である。

設計書だけではないですが、日常の思い込みを排除して、みんながストレスなく仕事ができるようにディレクションを行っていきたいと思います。