開発ディレクターの仕事とは？
はじめに
D’s Baseは、“アプリケーション開発” に携わるディレクターのノウハウ共有や、エンジニアの方々へのインタビューを通して、ディレクターとエンジニアが少しでも仕事が進めやすくなるような情報を発信しています。
今回は、D’s Baseのメンバーがこれまで経験してきたことをもとに開発ディレクターとはどのようなものなのか？というところを皆さんに知ってほしい、をテーマに記事にしました。
開発ディレクターの仕事とは？
皆さんが思う開発ディレクターの仕事とは、どのようなものでしょうか？
まずディレクターとは、制作メンバーの全体の指揮をとる現場監督のような役割の人を指すことが多いです。制作プロジェクトのスケジュール管理や各スタッフの進捗管理を行い、限られた納期の中で、質の高い成果物をクライアントへ納品するところまでを担ってます。
Webサイト制作でのディレクターの役割として、おおまかに以下の制作フローで進めることが多いかと思います。
ヒアリング：クライアントと打ち合わせ
↓
見積り
↓
スケジュール策定
↓
構成：機能設計 / クラウドサービスの選定 / ワイヤー制作
↓
デザイン：デザイン制作・管理
↓
開発：実装/テスト
↓
公開
その中で、開発ディレクターの場合は、「開発」フェーズ でのディレクションの比重が特に大きくなります。
今回は開発ディレクターとして、フェーズごとにどのような関わり方をして業務を進行しているのかを、詳しく説明していきたいと思います。
1 ヒアリング
まずクライアントと打ち合わせをし、要件について齟齬がないように認識を合わせていきます。
ここで大切なことは作業範囲の確認です。
この「作業範囲の確認」を疎かにしてしまうと、後々のトラブルの元になりかねるので注意が必要です。
「何を納品するのか」「納品物以外で必要な作業はあるのか」などの納期と成果物については、必ず確認しておきましょう。
打ち合わせの後は、ヒアリングした作業範囲を整理し、双方で認識を合わせます。
必要に応じてPowerPointなどで作業内容をまとめ、認識が合ったところで、次に見積りの準備を進めていきます。
2 見積り
見積り書を作成するには、工数の根拠となる材料が必要です。
この材料の調整もディレクターの役割であることが多いです。
例えば、
・作業を行う上で、進行や管理を行うための工数
・作業要件の中にある機能の実装に必要な工数
・機能を実装した後にテストをする工数
などの材料が必要となってきます。
特に開発ディレクターでは機能の実装に必要な工数を重点的に精査します。
実装者と密にコミュニケーションを取り、各機能に対してどのくらいの工数がかかるのかを詰めていきます。
また、この実装者が社内か外部の協力会社かでも進め方が異なってきます。
例として、外部の協力会社に依頼する際のポイントを挙げていきたいと思います。
まずは、要件によっては社内でないと実施できないケースも出てくる場合がありますので、必要な作業について社内ですり合わせをします。それらを整理したのち、外部に依頼する作業内容を明確化します。
ここで目的や納期も明確に伝えることがポイントです。また、明確な予算がある場合もあらかじめ予算を伝えておけるとスムーズです。これらが曖昧になると、費用にバッファが発生したり、認識齟齬など制作進行に重大な影響を及ぼす可能性が出てきます。
そうして、見積りに必要な各工数がまとまったら、見積り書を作成します。
3 スケジュール策定
見積りと併せてスケジュールを作成します。
次に、社内の関係者で打ち合わせやヒアリングをし「マスタースケジュール」を作成します。クライアント側での素材手配、いつまでに必要なのか等、社内だけでなく、クライアントや制作チーム、外部協力会社制作チームなど、案件に関わる全てのメンバーと細かくスケジュールを調整していきます。また、案件の規模によってはマスタースケジュールに加えて、開発実装者ごとの作業担当と各作業工程のタスクレベルで洗い出し、それぞれの期限を明確化したWBSも、開発ディレクターが準備するケースもあります。
このスケジュール管理は、案件進行において、とても重要な役割を担っています。精度の高いスケジュールを引くことで、効率良く安全にプロジェクト進行ができ、タスク漏れや全体の遅れを未然に防ぐことができます。
4 ワイヤーフレーム制作
ここからは受注も完了した後の、制作フローについてです。
まずはワイヤーフレームの制作です。クライアントと打ち合わせを行い、クライアントの理想のイメージを掴んでいきます。
コンセプト・目的、ロゴや、ボタンなどの「要素」の確認、想定の動きを中心にヒアリングを行います。このようなヒアリングを元に、文字や図を起こして設計図のようにコンテンツの配置を決定していきます。これがワイヤーフレームです。ワイヤーフレームにヒアリングした情報をしっかり落とし込み、図として具現化していきます。
ワイヤーフレームにヒアリングした情報をしっかり落とし込み、図として具現化していきます。
作成したワイヤーフレームをクライアントに共有し、問題なければデザインフェーズに入ります。
5 デザイン
そしてデザインのフェーズです。
ここでのディレクターの役割は、クライアントと制作者との相互理解をサポートする役割です。
「デザイン」は感覚的な部分が多く出るフェーズです。先にクライアント側の決定者を明確にしておけるとスムーズです。
例えば「担当者のAさんとBさんはOKだったが、新たに加わったCさんに方向性の異なるアドバイスをいただいて、振出しに戻ってしまう」というような事態を避けるためです。
6 開発
クライアントとの要件定義が終わり、開発に入ります。
ここでは協力会社の開発管理を行う際のポイントをいくつかご紹介します。
・システム概要の説明のしかた
・仕様書の作成
・開発スケジュールの作成
・試験の作成と実施
・ドキュメント管理
・コードのバージョン管理
◯システム概要の説明のしかた
まずは協力会社に制作するシステムの概要を説明しますが、そのときのポイントとして、「現状の問題点」「解決したい目的」「問題が起きた背景」「今後の展望」があります。
概要をしっかりと説明することで、協力会社とディレクターで同じ目標をもってシステム開発を行える状態を目指します。
なぜ目標の共有が必要かといいますと、大規模なシステム構築になるほど必要な記載を網羅した仕様書を作るのは難しくなり、また仕様書に齟齬が発生することも増えてきます。同じ目標を共有することで、協力会社側が仕様の抜けや間違いを判別できるようになるので、協力会社側からの指摘も入ることで納品物の品質の向上が望めます。逆に、目標の共有がうまく行っていないと、協力会社は仕様書通りに作るしかなく仕様の不備に気づくこともできません。お互い協力して品質を高められる体制を作ることをおすすめします。
◯仕様書の作成
概要の説明ができたら、作成する開発物を定義する資料である仕様書を作成します。
仕様書といってもシステムによって内容は様々ですが、基本的には
・システム概要（前述の内容： 問題点、目的、背景）
・具体的な機能（画面イメージとUIを操作したとき動作など）
を記載していきます。
特に具体的な機能の部分は、正常動作だけではなく、想定外の操作をした場合の動作、つまり異常系の部分もしっかりと定義します。このときに作った機能がどう使われるかのユースケースを整理できておくと、仕様の不足に気が付きやすくなります。
仕様書に記載されている機能以外は実装されないため、仕様の不備があるとスケジュールの破綻に直結する重要なフェーズです。協力会社とも仕様書のレビューができていると尚よいかと思います。また、協力会社に仕様書の作成を依頼した場合は、正常系・異常系どちらも必要な機能が全て定義されているかは、必ずレビューするようにしましょう。
◯開発スケジュールの作成
仕様書ができたら、それに沿って作業タスクを洗い出し、作業担当と期限を割り当てたWBSを作成し、協力会社と合意を取ります。作業タスクは細かい方が抜け漏れが防げるため品質が向上しますが、WBS自体を作成/運用する手間がかかるというデメリットもあります。
粒度は案件によって変わりますが、開発においては単体テストできる機能単位がWBSを引く際の最低限の粒度になってくるかと思います。
単体テストできる機能単位のタスクが完了した際には、自身で簡単なテストを行って品質を確認しておきましょう。
◯試験の作成と実施
スケジュール通りに実装が進めば試験のフェーズとなります。
品質を担保するため試験は丁寧に行う必要があり、協力会社側でも試験は実施されますが、ディレクター側でも試験書を作成してダブルチェックするのがベターだと考えています。
一般的に必要な試験は以下の3点かと思います。
・機能試験
・デグレード試験
・リリース後試験
機能試験は、作成したシステムが仕様書に沿って動作するか確認する試験です。
正常系だけでなく異常系の試験も必ず実施しましょう。
デグレード試験は、システムを作成/改修した影響で既存機能に不具合が生じていないか確認する試験です。リリースしたら影響範囲外と思っていた既存機能に不具合が発生した、という事はよく発生するので、リリース前に試験環境で既存機能の動作試験を実施して事故を防ぎましょう。
リリース後試験は、リリース後に機能試験とデグレード試験を実施することを指しています。開発環境と本番環境の違いで発生する不具合もあるので、リリース後にも確認が必要です。正常系の試験は一通り実施しておきましょう。
◯ドキュメント管理
成果物の保守性の担保の話です。
開発作業の中では「画面設計書」「DB設計書」「インターフェイス設計書」「デザインファイル」「議事録」など様々なドキュメントが作成されます。
これらのドキュメントを管理するために
・どこに集積するか（backlogのファイル? Google Drive?)
・どういうルールで保管するか（フォルダの分け方など）
・仕様変更が発生した場合、どこのだれがドキュメントを更新するか
を決めておきましょう。
以下のような事態が起こらないように気を付けましょう。
・システムが更新されたのにドキュメントは更新されない
・ドキュメントの格納場所に分散していて、どれが最新か分からない
また、必要なドキュメントが作成されていない場合もあります。開発前にどんな開発ドキュメントが必要かは、クライアントと協力会社とも相談しておきましょう。
◯コードのバージョン管理
こちらも成果物の保守性の担保の話になります。
中長期の案件では、成果物のバージョン管理をどうするかも決めておきましょう。
バージョン管理を怠っていると、どの機能をいつリリースしたか分からなくなり、不具合が判明したときにどのバージョンから発生していたか、などの追跡も難しくなります。
バージョン管理の基本は
・バージョン管理ソフト（github等）でリリースタグを打っておくこと
・リリースした機能をbacklogなどの課題にまとめておくこと
です。
そのプロジェクトでどういったバージョン管理が適切か、協力会社に相談するところから始めましょう。
7 公開
ここでのディレクターの役割は、公開作業の指揮をとるだけでなく、事前に公開手順を開発チームと協力して準備しておき、クライアント側と認識を合わせておくことまで含みます。
公開作業は制作の最終工程であり、最も重要な工程のひとつです。ここでミスをしてしまうと、今までの努力が水の泡という事も・・・。
事前にやることは明確にしておき、安全に公開日を迎えましょう。当日は落ち着いて細心の注意をはらって作業を行ってください。
おわりに
制作物によって細かな部分で違いは出てくるとは思いますが、大筋はどんな制作物でも似たフローになってくるかと思います。お読みいただいた方の何かヒントになれば幸いです。