フロントエンドのテクニカルディレクションに求められるスキル

フロントエンドの多様化が進む中で昨今重要視されているのが「テクニカルディレクション」のスキルセットです。

会社の規模や職域、ビジネスモデルにより求められるスキルセットは異なりますが、中小のWeb制作会社を前提に話をいたします。

ディレクター/フロントエンドエンジニアの作業分担

ケースとしては以下のようなパターンが考えられます。

アサインされたディレクターがテクニカルディレクションを行い、フロントエンドエンジニアが実装を行う
アサインされたフロントエンドエンジニアがテクニカルディレクションとフロントエンド実装を行う
アサインされたSE/テクニカルディレクターがテクニカルディレクションを行い、フロントエンドエンジニアが実装を行う。

個人的には2のケースでアサインされることが一番多いですが、最近の案件では3のケースで1年ほどテクニカルディレクターとして案件を行なっておりました。

多くのプロジェクトでは1のケースで人員配置されることが多いのではないかと思うのですが、一般的なWebディレクターは技術的なバックグラウンドやスキル、知識を持っていない人も多く、結果としてフロントエンドエンジニアがテクニカルディレクションの一部もしくは全部を行わなくてはいけなくなります。
(一般的なバックエンド実装でも同様ですが、とくにフロントエンドに関しては技術的なバックグラウンドがない人が要件のどこがプロジェクトのボトルネックになるか検討がつかないケースが多いので)

テクニカルディレクションの作業内容

多くのプロジェクトの場合はプロジェクト開始のタイミングから以下の工程を通るかと思います。

プロジェクト要件の把握
プロジェクトメンバーのスキルセットの把握
技術要件の選定
トラブル可能性が高い工程の洗い出し
作業工数の算出(バッファ含む)
作業工数からの対応スケジュールの設定
対応スケジュールと納期に矛盾が生じる場合は以下の対応
- プロジェクト要件の調整で対応可能かどうかの確認
- プロジェクトメンバーの変更で対応可能かどうかの確認
- 作業工程の見直しで対応可能かどうかの確認
- 納期の延長で対応可能かどうかの確認
プロジェクトの進行管理
プロジェクト進行中に発生する追加要件とプロジェクト進行への影響度を把握
- プロジェクト進行に影響がある場合は何か調整
プロジェクト進行中に発生する技術的な不足事態とプロジェクト進行への影響度を把握
- プロジェクト進行に影響がある場合は何か調整
品質チェック
テスト

特に技術的なバックグラウンドやスキル、知識が必要な箇所に関しては太字で記述していますので掘り下げて解説します。

技術要件の選定

技術要件としてはプロジェクト要件とかぶる箇所と自由に選定できる箇所があり、プロジェクト要件として定めるべきであるのに定まっていない事や自由に選定できる箇所について選定をしていきます。

プロジェクト要件として定めるべきであるのに定まっていない事に関して多いのが対応ブラウザや検証ブラウザの選定です。他のプロジェクト要件や各ブラウザシェアなどを考慮した上で対応ブラウザを決めていきます。HTML5 APIなどを利用する場合は各機能のブラウザの実装範囲なども視野に入れなくてはいけません。

自由に選定できる箇所に関しても、すでにプロジェクトメンバーがアサインされている場合はスキルセットを考慮しなくてはいけません。たとえばバージョン管理システムにGitを採用したのにプロジェクトメンバー全員がSubversionしか使った事ない場合、慣れるまでの時間ロスを前提にプロジェクトを組み込まなくてはいけません。(逆のケースもあります)

Gitなどは習得コストが高くないので慣れる事を前提に導入するのは難しくないですが、MV*フレームワークにAngularJSを導入したがプロジェクトメンバーがだれも使った事がないとかだとトラブルの予感しかしません。

トラブル可能性が高い工程の洗い出し

スキル、知識だけでなく経験がものをいう作業ですが「トラブル可能性が高い工程」を事前にピックアップする事ができたら、それに応じて予算やスケジュールにバッファを設ける事ができます。

事前に検証などを行いトラブルの要因を消す事ができるだけでなく、事前にクライアントに「トラブル可能性が高く解決策を見出せないケースもある」ことを伝えておく事で、トラブル発生時に「更にスケジュールにバッファを設ける」や「要件を変更する」などの対応が比較的容易に行う事ができます。

作業工数の算出(バッファ含む)

作業工数の算出(見積もり呼ばれることもある)が重要な作業になります。

バッファを含まずに算出してしまえば極端に言ってしまえば文言変更がくると見積もりと工数の調整をしなくてはいけません。

予期せぬトラブルや他の工程の遅延、予期せぬ仕様追加や仕様変更をある程度吸収できるバッファを含んでいれば、バッファ内の作業であれば調整は不要である程度柔軟に対応する事ができます。

とはいえどれぐらいバッファを含めば適切かは経験が物を言い非常に難しいところですね。

作業工程の見直しで対応可能かどうかの確認

見積もりの段階から対応スケジュールと納期が矛盾している、つまり納期に間に合わないといういきなり炎上予感。

基本的にはプロジェクト要件の見直し、つまり作業内容を縮小して対応するのが一般的ですが、必須要件などが多い場合は作業工程の見直しを行います。

よくあるパターンとしてはウォーターフォールではなくパラレルで作業を行うパターンがあります。ええ、ほんとうによくあります。

本当だったらデザインが全量できてからHTML/CSSコーディングを行い、並行してAPIの開発、API開発とHTML/CSSコーディングが終了したタイミングでJavaScript実装を行うが理想ではありますが、できたページ(パーツによってはできていない)からコーディングを行い、JavaScript実装もスタブなどを利用して実装できることから対応していく。

純粋に作業期間が増える上に、進行管理が非常に複雑になり、仕様が未定/甘い箇所も発生しやすく手戻りが大きくなっていくパターンです。

このパターンでは、フロントエンドのみでのスケジュール調整は難しくプロジェクトの全体像や他の工程のスケジュール感、仕様の確度など様々な要件を考慮して、要件や工程の調整を行なっていきます。

プロジェクト進行に影響がある場合は何か調整

プロジェクト進行中に発生する追加要件や技術的な不足事態がプロジェクト進行つまり納期にインパクトを与えてしまうケースというのもあります。

追加要件に関してはインパクトの少ない代替案を提示することや、要件の工数を算出して追加工数として計上してもらう対応が必要です。

技術的な不足事態に関しては早めにアラートを上げることが重要です。「Android 4.3でAの機能の実装が上手くいかない、調査に時間がかかりそうだ」と早めにクライアントや上流に伝えることで、納期の調整がしやすくなったり、Android 4.3でAの機能は不要にするなどの要件調整ができます。ギリギリに伝えても何も良いことはありません、少しでも怪しいと思ったら早めに伝達して対応策を練りましょう。

ディレクションは生き物でありプロジェクト要件に合わせて千差万別の対応をしなくてはいけませんが、基本的にはトラブルの元を事前に潰すことに行き着きます。

ぜひ一度、フロントエンドのテクニカルディレクションに求められるスキルに関して考えてみてください。