Webディレクターに知っておいて欲しい!エンジニアがされたら困る7つのこと

システム開発の案件をディレクションする時はどのタイミングで何を確認したら迷うことも多く、エンジニアを困らせたり、怒られてしまったことがある方も少なくないではないでしょうか。

今回はそんなWebディレクターの方向けにどんな事をされると困るのかをエンジニアに聞いてみましたので紹介していきます。

エンジニアはどのようなことをされると困るのか

エンジニアを困らせてしまうことはいろいろありますが、大きな項目としては

• 仕様が固まっていない
• 決めて欲しいことを丸投げされる
• 開発後に仕様変更が繰り返される

などです。ディレクションする側にシステムの理解が不足していると、いつまでに何を決めて渡さないといけないのか、変更が入った際の影響範囲などが分からずにエンジニアの方を困らせてしまうことになります。

エンジニアが困る7つのこと

ここからはさらに具体的に紹介していきます。

1）実現したい機能が固まっていない

システムはプロジェクトオーナーが実現したい機能を元に設計をしたり、サーバーの仕様などを検討します。

例えばCMSを構築するというプロジェクトであれば、CMSの対象となるコンテンツは何なのか、どういった入力項目があるのかといったことを設計していきます。この時にCMSが必要ですとしかオーダーされなかったとしたら、どういった機能を実装するのかを検討することができません。なので、

• ニュースコンテンツを更新できるようにしたい。
• 公開前に社内で確認しする承認フローが必要。
• 指定した時間にタイマーで公開したい

といった具合に具体的に実現したい機能を決めていく必要があります。

「公開前に社内で確認しする承認フローが必要。」といった具合に要件をもらえれば、エンジニア側から「承認フローは何段階必要なのか？」といった具体的な質問をすることができ、システムの仕様をスムーズに決定していけるようになります。

2）フロント側で決めて欲しいことを丸投げしてくる

例えば「お問合せフォームをつくってください」と言われても、入力項目はどうするのか、管理者画面は必要なのか等、色々と決めなくてはいけないことがあります。

それを確認しても「よくある感じのやつでよろしく」といった依頼がされることもあります。入力項目などはお問合せを対応する人がどういった情報が欲しいのか、対応は誰がどういったフローで行うかなど、運営面によるところも多いので、開発側では検討が難しいのです。

システム的な要件は分からないとしても、どういう用途で使われて、誰がどのように運用するかはヒアリングできると思いますので、まずはユースケースを明確にできるようにしましょう。

3）必要書類のフォーマット等を後から指定する

システム開発を行う場合は設計書が必要になります。設計書を作成し、それにそって開発を進めていきます。この設計書は決まったフォーマットがあるわけではなく、開発会社側が作りやすいように作ったり、顧客側が指定する場合もあります。

設計書を作成後にフォーマットを指定されたり、掲載する内容を指定されると手戻りが発生します。必要書類のフォーマットが決まっている場合は、あらかじめ提供してもらい、開発側で作成する場合は何点かサンプルを提示してイメージをすり合わせておくことで無駄なくスムーズに進められます。

4）何度も仕様変更を繰り返す

顧客側と要件定義を行った後、設計書を作ったら顧客側に提案し、承認されたら実際にシステム開発に入っていくのですが、システム開発に入ってから設計の部分で変えてほしいといった連絡が入るケースがあり、ひどい時には設計以前の機能面から変更したいと言われる場合もあります。

クライアント側も必ずしもシステムに精通しているとは限らないので、どの段階で何を決める必要があるのか、変更することが難しいのかときちんとアナウンスしながら進行し、大幅に要件が変更になるような依頼があった際は納期や費用に影響があることの理解を得てから進めることが重要です。

5）着手後に開発環境が指定される

開発後に言語を指定されることはさすがに多くないかと思いますが、フレームワークやJSライブラリなど、セキュリティ上の都合などで使用がNGと言われるケースがあります。

開発後の変更となると大幅に手戻りしてしまいますので、エンジニアや先方のシステム部門などを交えて事前に開発環境を決めておく必要があります。

6）システムを組み込んでからのデザインの変更

Webアプリを開発する際には機能部分とインタフェースは分けて作ることが主流ではありますが、それでもシステム組込後に大幅にデザインが変更になったり、ページ構成が変更になると効率的ではありません。

デザインでOKになっていても実際に触ってみてから気づく点などもありますので、システムに組込む前のHTMLの段階でもレビューしておくことで、こういった変更を最小限にすることができるでしょう。

7）データベース設計後のデータ構造の変更

システム構築する際にはデータベース構築も必要になるケースが多いです。データベースはシステムの要件にあわせて複数のテーブルを用意して連携できるような設計を行います。

必要なデータの量や種類にあわせて構造を決めますので、設計後に大幅な変更が入ると、設計をやり直さなくてはいけなくなったり、用意したのに使用しない項目ができたりといったことが起こります。

またプログラムの中にデータベースを操作する指示も書いてありますので、データベース設計後にデータ構造が変わるとデータベースだけでなくプログラムの方にも影響を与えますし、設計書も更新が必要になります。

まとめ

システム開発は非エンジニアからすると未知の領域が多く、デザインのようにパッと見では気付けない問題も多いのでディレクションに苦労することも多いでしょう。ですがデザインのように感覚的な部分は少ないので、順を追って丁寧に進めていけばスムーズに進行することができます。

慣れない人には取っ付きづらい領域ではありますが、システムに強いディレクターは活躍の機会も多くなるので、エンジニアと連携を取って上手にディレクションができるようになっていきましょう。