テクニカルディレクターとして気を付けているコト

テクニカルディレクターというのは技術領域に精通したディレクターです。Web業界でのテクニカルディレクターはWebディレクターと同じくクライアントの要望と向き合いつつ制作チームの指揮をとる必要があります。そこで今回は私なりに気をつけているディレクションのポイントについて書いてみたいと思います。

社内会議は最低限

キックオフなどで関わるメンバーの顔合わせという意味で関係者全員が最初に集まる事はありますが、それ以降は全員集まったところで一部のメンバーしか話さない事になりがちなので、個々のメンバーと1on1で対話するのがといいと思います。集めたとしても3人程度で十分ですし、少ない方が会話が弾むものです。頻度は制作の状況にもよりますが最低で週次、最高で日次といった所ではないでしょうか。以前日に数回進捗を報告をさせている方を見かけしましたが少しやりすぎな印象でしたね。

エンジニアは極力製造に集中

エンジニアは作り込みにパフォーマンスを発揮していただく必要があるため、途中で悩む事がないよう要件定義や外部設計は事前にディレクターが取り決めます。要件は基本的には言語化して外部設計など伝わりにくい事は図を用いて資料を残します。時間的な制約でキッチリした資料を残せないケースは手書きでも有るのと無いのでは大きな違いなのでスマホで写真をとってデータ化して渡すのもアリだと思います。

丸投げはしない

サーバサイドエンジニア・フロントエンドエンジニア・インフラエンジニア・デザイナーと実に様々な職種の方たちと向き合う事になりますが、丸投げで業務が回るようならディレクターは不要です。現場の業務を全ておさえられなくても大枠は理解して、タスクを洗い出しスケジュールを組んで、前項でも触れたとおり各々がパフォーマンスを発揮しやすいようサポートする必要があります。また課題が見つかったらヒアリングして共に解決していく姿勢も必要です。現場でなんとかしてくれというスタンスではディレクターとして信頼は得られないでしょう。

スケジュールは現場の合意を得る

テクニカルディレクター自身の経験則に基づきスケジュールを組む事があります。工数にバッファをとったとしても各メンバーに確認を取りつつ必要なら微調整します。合意なきスケジューリングは不信感を生む原因にもつながります。工数が想定よりも大幅に膨らむならエンジニアのみが気付いている課題があるかもしれないので、早期にヒアリングしてキャッチアップするべきです。