はじめに

このシリーズでは、プロジェクトの企画段階から案件に関わることも多くなったフロントエンド・エンジニアが、よりプロジェクトを円滑に進める方法を考えます。

第1回目は、そのようなプロジェクトが増加した背景を踏まえ、フロントエンド・エンジニアができることは何か、また円滑な進行のために、何を知らなければいけないのかを解説します。

参加段階の変化

現在、フロントエンド・エンジニアの活躍の場は実装フェーズだけでなくなってきています。

多くの場合、フロントエンド・エンジニアはプロジェクトの企画、デザインが完了したあとに参加し、それを実装する作業を担当するという流れでプロジェクトが進むかと思います。

もう少し早い段階から関わる場合は、デザイン段階から参加することもあるでしょう。作られたデザインに対して「実装できる」「実装しやすい」「このようにしたほうがよい」といったことを意見します。ただ、プロジェクト全体としてはどちらかというと後半を担当するというのが普通でしょう。

ところが、ピクセルグリッドではプロジェクトの初期から相談を受けることが多くなりつつあります。フロントエンド・エンジニアがプロジェクトの企画段階といった、本当に最初の段階から参加するのです。

その背景には、最近は、企画のWebへの展開をフロントエンドの技術やUIを中心に考えることが増えているということがあげられます。新しい技術を活用した表現や機能を提供する場合、どうしてもフロントエンド技術の知識が必要になっています。企画の段階でそういった技術の判断を行うことで、プロジェクトをスムーズに進行させることが可能になります。

ディレクターが判断すればよい？

プロジェクトの初期段階からそのような判断を行うのは、エンジニアが出て行かなくても、技術に詳しいディレクターがいれば大丈夫だと思われる方もいるでしょう。

しかし、現在フロントエンドの進化速度はかなりのスピードで、情報がきちんとまとまっているわけでもないため、なかなか体系立てて勉強することも難しくなっています。表現ひとつとってもHTML＋CSS、Flash、SVG、Canvas、WebGLなど、ひとりでは追い切れないほどの選択肢があります。

そうなると新しい技術を使いたいと思っているプロジェクトほど、日々技術に触れているフロントエンド・エンジニアが打ち合わせに参加し、直接判断するほうがよい結果を生みやすくなります。

企画と実装の変化

少し前まではサーバー側の言語やフレームワーク、あるいはCMSを選ぶといったことから企画が始まることが多いと感じていました。「WordPressを使ってコストを削減しつつクライアントが更新できる環境を」、「Ruby on Railsを使ってモダンな開発環境で」というようなプロジェクトは現在も多くあると思います。

JavaScriptが多くのサイトで当たり前のように使われるようになった現在では、ほとんどクライアント側で処理を行い、サーバー側の処理はJSONを返すAPIがあるだけといった構造をとるサイトやWebアプリケーションが増えてきています。

そのような構成で制作を進める場合は、どのようなAPIが必要かといったこともフロントエンド・エンジニアが関わることになります。つまり技術的な設計は、すべてフロント側を中心に行われるのです。

そのようなプロジェクトでは、フロントエンド・エンジニアが初期から参加することに意味があります。

プロジェクトの初期から相談を持ちかけられた場合にフロントエンド・エンジニアがどのように動くべきなのか、実際にピクセルグリッドで行っていることをお話します。

プロジェクト初期のエンジニアの役割

企画の段階で、フロントエンド・エンジニアにできることは技術的な判断です。プロジェクトを成功させるために、まずはそれが実現可能なのかどうか、できるとすれば必要な技術を提案していきます。

このような初期の段階ではフロンエンドの知識だけでなく、サーバーやインフラについてもある程度知っておいたほうが判断をする上で有利です。ほかにサーバーやインフラが得意な人が参加している場合は、その部分を任せてしまってもよいでしょう。

具体的には次のようなことを行います。

• 特定の技術を利用した事例を紹介する
• 問題に対してフロントエンドで解決できそうな場合は方法を提示する

どのように儲けるかといったビジネスの企画をあげたりといったことは求められていませんし、必要ないと思っていてよいと思います。が、技術的な判断をする上でプロジェクトの位置づけと関連するビジネスの理解はしておく必要があります。

ビジネスを理解する

「ビジネスを理解する」といっても、クライアントと自社の制作費の話ではありません。もちろんそれはそれできちんとしておく必要がありますが、ここでは当該のプロジェクトがクライアントのビジネスにとって、どのような役割を果たしているのかということです。

例えばコーポレートサイトのリニューアルであれば、クライアント企業の営業的な部分を担っている場合もあれば、扱っている製品のサポートがメインの場合もあります。Webアプリケーションを作るのであれば、それが何のためのものなのか、誰が使うのかといった情報を把握する必要があります。それを使うことでクライアントがどこからお金を得るのか、または節約するのかということがプロジェクトの目的になります。

このような、何ができればプロジェクトの目的が達成できるのかを理解することで技術の判断も的確にできるようになります。例えば営業的なコンテンツにおいて、JavaScriptで派手に動かす代償として検索エンジンにクロールされなくなるといった手法は採用すべきではないでしょう。

曖昧なプロジェクトをクリアに

参加したプロジェクトできちんと目的が明確になっていればよいのですが、場合によってはビジネス自体が決まっていないなんてことがあります。

これが決まっていないといくら技術的によい提案ができたとしても、結局プロジェクト自体がなくなったりというようなことが起こります。

特に参加したプロジェクトの目的を次のような言葉で説明をされた場合は要注意です。

「HTML5で新しいものを作りたい」

新しい技術を使うこと自体が目的になってしまっているか、クライアントが夢を見すぎている可能性が高いです。技術は目的を達成するために選択する手段であり、それ自体が目的になっているとうまくいかないことが多いです。

もちろんこのような説明を受けたとしても、よく話を聞くと別の目的があったりということが多いです。また目的によっては、そもそもHTML5である必要すらなかったりします。

「使いやすい革新的なUIにしたい」

まず、何かを作るのにあたって使いやすいUIにする、それを目指すことは当たり前です。HTMLを仕様通り正しく書くのと同じぐらい当然のことで、プロジェクトの目的にはなりえません。

このような依頼の場合、競合製品が存在している場合が多く、そちらをよく見て、なぜそれが使いにくいのかをきちんと確認する必要があります。

また使いやすさと一口に言いますが、誰にとっても使いやすいというのはありえないものです。さらに機能が多ければ多いほど使いやすくするのは難しくなります。ユーザーを明確にして機能を絞ることで、ほかと違った使いやすいものを作ることはできるかと思います。けれどたいていの場合やりたいことがすべてできて、誰もが使いやすいといった不可能なものを求めている場合が多いです。

対策

曖昧なプロジェクトだった場合はどうすればいいのでしょうか？　フロントエンド・エンジニアの役割からは多少外れるかもしれませんが、クライアントと一緒にインセプションデッキを作成するのがオススメです。

インセプションデッキとは何か？　また、どのように作成すればいいのかに関しては、次回解説します。

まとめ

フロントエンドを中心に構成されるサイト・Webアプリが増えてきて、フロントエンド・エンジニアが早い段階からプロジェクトに関わることが増えています。

初期から関わることでうまく知識を提供できれば技術をきちんと活かした方向へもっていくことも可能になり、また目的をきちんと理解して実装することで、なぜこの技術を使うのか納得いくかたちでプロジェクトを進めることができます。

次回は、目的が曖昧なまま進もうとするプロジェクトの改善策として、インセプションデッキを取り上げ、解説します。