2018年10月

10

水曜日の投稿

児嶋 いずみ
投稿者:児嶋 いずみ
(コーディングファクトリー部 部長)

2018年10月10日

コーディングファクトリーの制作現場の変化について、洗い出し精査をしてみました。

コーダーのあーだこーだ

児嶋 いずみ
投稿者:児嶋 いずみ(コーディングファクトリー部 部長)

こんにちは。コーディングファクトリー(以下、CF)の児嶋です。

ここ2年くらいの間で、CFの制作の現場がだいぶ変化してきました。が、ここしばらく「状況の変化」と「それに対する認識」に少しズレを感じるようになり、モヤモヤしています。そのモヤモヤの正体を見つけるべく、具体的にどんな変化があったのかを洗い出し、考察をしてみました。

インプットの充実だけではまかないきれない、というモヤモヤ

昨年7~8月にかけて、『速く正確なWeb制作のために現場で本当に必要なことは何か?』というセミナーを開催したのですが、その時に、「Webの制作現場を取り巻く環境は、ここ数年の変化が目まぐるしく、制作内容が多様化したことで、より専門性が上がり、かつ役割が細分化・分業化することで、制作が複雑さを増しています」というお話をしました。

そこでは、具体的に、「制作内容の変化」「開発環境の変化」「制作体制の変化」「制作フローの変化」について触れ、企画で実現したい要件(上流工程のアウトプット)と、実装に必要な情報(下流工程のインプット)が正しく紐づくように、各工程で適切にアウトプットリレーをすることが重要なのではないか、ということと、すべての工程のアウトプットは、フロントエンド工程に集約されるから、この工程に必要なインプットを洗い出せば、制作に必要な素材・情報が網羅できるのではないか?ということで、インプットシート(確認すべき仕様等を網羅したカルテのようなもの)の提案をしました。

インプットシートの項目に沿って、漏れやすい仕様などの確認や認識の擦りあわせができれば、ある程度誰でもが迷うことなく、後から致命的な問題が発生することも回避でき、制作を進めることができるのではないか、と思ったのです。

CFでは、基本的に案件に入る段階で、制作担当メンバーがこのシートを活用しています。また、セミナーの参加者で、このシートを自社にあった形にアレンジして使ってくださっている会社様から、その効果がうかがえる声をいただいています。

「何はともあれ、インプットが肝」と思っていた私にとって、これがあれば、八割がたのことは解決するのではないかと思っていたのですが、それでも想定外に制作の時間がかかったり調整することがまだまだあって、それは何なのか?なぜなのか?モヤモヤが募りました。

算出工数と予算/算出工数と実工数が合わない、というモヤモヤはつづく

インプットのモヤモヤと前後して、初回見積(概算見積)時の算出工数とお客さまのご予算が合わない案件や、初回お見積時と実際に制作がはじまってからの実工数が合わない案件が散見されるようになりました。
ヒヤリングの詳細度を上げているにも関わらず、当初の想定と実際の着地点がなぜそんなにずれてしまうのか?なぜお客さまと認識が合わないのか?というモヤモヤが膨らみました。

制作現場の変化の洗い出し精査へ
レスポンシブ(以下RWD)制作初期と現在の変化を比較

これらの課題(モヤモヤ)は、CFのサービスを担っている5部署の月例会議で議題に上がり、なぜなのか?どうしたらいいのか?について、あれこれ議論をしたのですが、まずは、制作の現場で具体的にどんな変化が起きたのか、シンプルに洗い出してみよう、という話になりました。

ということで、「レスポンシブ(以下RWD)制作初期(2014~2016)」と「現在(2017~2018)」の2つの時期での違いを洗い出してみました。

  レスポンシブ制作初期
(2014~2016)
現在
(2017~2018)
カテゴリ おおよその
追加工数
01 SPとPCの切替は、リロード時の挙動のみの保証で十分だった。 ブラウザをリサイズした際、SPとPCのレイアウトが崩れないリキッドレイアウトのサイトが多い。 仕様 1h~
02 SPとPCのRWDの場合は、タブレット対応は基本行っていなかった。 SPとPCのRWDの場合でも、タブレットでPCレイアウトが収まるのが一般的な仕様として認識されている。 仕様 2h
03 RWDで対応可能なデザインをクライアントも模索中のため、複雑なレイアウトの案件がなかった。 ブラウザがサポートするcssやJSが増えたり、UI/UXの成熟で、複雑なレイアウトも実現できるようになった。 デザイン 1.2倍
04 アニメーションやパララックス(視差効果)の実装は少なかった。 部分的にアニメーションや視差効果を実装することがよくある。 デザイン 2h~
05 ユーザーの環境にないであろうフォントは、テキスト画像を使用する。
フォントサイズは、pxや%での指定が多い。
Webフォントの実装がよくある。基本的にテキストはデバイスフォントで実装。
vwなどビューポートの幅に合わせてフォントサイズを変える仕様も増えてきた。
フォント 1.2倍
06 ロゴなどのSVG対応はなし。 ロゴはSVG対応が一般的。 画像 0.5h
07 基本文章は横書き。 縦書きのレイアウトが時々ある。 フォント 2h~
08 PhotoshopかIllustratorでの入稿がほとんど。IllustratorはPSDに変換して対応。
時々Fireworks(PNG)がある。
左記に加え、Sketch、XDでの入稿が増えてきた。 ツール 1.2倍(新しいツールの導入時の学習コスト)
09 タスクランナー、プリプロセッサ、テンプレートエンジンは基本使用しない。 gulp、Sass、gitを使用した制作が基本。EJSやpugを使う案件が時々ある。
クライアントの制作環境を引き継いで対応することがある。
ツール 1人日~
10 コーディングガイドラインはCFのガイドラインを使用することが多い。 BEMやFLOCCS、SMACCS、OOCSSなど、CSS設計や独自のガイドラインを指定されることが多い。 仕様 1人日~
11 高解像度(Retina)対応はSPのみ行っていた。 PCの液晶が高解像度になり、PCでも高解像度対応を求められることがある。 仕様 1.2倍
12 アクセシビリティの対応は殆どない。 アクセシビリティ適合レベルA、AA、AAAの対応を求められることがある。 仕様 2倍
13 OGPタグの対応はあまりない。 OGPタグの対応を求められることがよくある。 仕様 0.5h~
14 入稿~納品まで、ベーシックな制作フロー(主にウォーターフォール)から大きく外れることはない。 入稿~納品まで、制作フローどおりに進まないことが多い。
案件ごとに制作フローが大きく異なる。
仕様 1.5倍
15 仕様やデザインが、マークアップ着手時にほぼ確定している。 仕様が未確定で、プロトタイプ作成後、デザインを制作するような案件もある。 仕様 2倍~

洗い出しから見えてきたこと
各項目を眺めてみて、以下の3つのポイントが見えてきました。

(1)変数の多さ(主に、ツール・仕様)と、落とし込みまでのプロセスの変化

Webサイトが単なる情報発信目的だけではなくなり、機能・規模が多種多様になってきました。それによって、仕様もさまざまになり、開発内容にあわせたツールも数多く出現してきました。そんな中で、個々のサイト制作に最適なツールの選定や仕様の策定をするためには、テクニカルな知見やスキルだけでなく、つくりたいもの・やりたいことが何なのかニーズの理解と、数多くの可能性の中から最適な構成を組み合わせたり提案・調整するテクニカルディレクションの稼働と落とし込みまでのコミュニケーションが重要になっており、実際にその対応に多くの工数が割かれています。

(2)デザインの再現・調整の変化

css3+webフォントの普及によって、画像切り出しではなく、cssでデザイン再現できる領域が広がりました。また、UI/UXの成熟によって、複雑なRWDのレイアウトの画面が増えてきました。
これによって、cssで細かに調整することになったので、RWD初期に比べて2割くらい制作工数が膨らんでいます。また、css制作に高いスキルが求められるようになっています。

(3)デザイン・仕様書だけではキャッチアップしにくいものが増えたことによる制作フローの変化

(2)のようにスタティックな表示だけでなく、モーションやインタラクティブな機能実装、さまざまな画面幅やデバイスに合わせて表示が最適化されるようなつくりになってきました。モーションはデザインや仕様書で正確な動きのイメージを伝達しにくかったり、機能実装や画面幅による最適化表示については、仕様が複雑になってきていて、作りながらお客さまの考えるイメージとすり合わせて調整していく必要があります。また、作ったものを実際にさまざまな画面幅や条件で表示検証してみると、やっぱり細かいところで仕様が詰められていなかった点や不具合があぶりだされてきます。それらをひとつひとつ調整しながら完成度を上げていきます。

また、RWD初期までのウォーターフォール型(上流過程できっちり仕様を固めて、制作現場はその仕様通りに実装を進めていく)制作フローではなく、上流で基本仕様は詰めつつも、詳細は作りながらすり合わせ&調整しながら固めていくようなビルドアップ的な制作進行が主流になってきています。
制作の現場では、RWD初期に比べて、高いフロントエンドのスキルが求められているのはもちろんのことなのですが、提案調整をしながら制作を進めていくテクニカルディレクションスキルやコミュニケーションスキルも必要(というかもはや必須と言ってもいいかも)になってきた印象があります。
また、実制作工数だけでなく検証工数やコミュニケーション工数も膨らんでいることや、スケジュールという面でも完成までの時間がかかっていることがわかりました。

モヤモヤの正体と答え

ここで、やっとモヤモヤの正体が2つ見えてきました。

ひとつは、役割が分業化・細分化して専門性が求められている一方で、最適な提案や実装調整を行うためには、担当している専門分野の情報だけではなくプロジェクト全体像も俯瞰して把握しておく必要がある、という点です。

もうひとつは、分業化・細分化した関連セクションと連携をとるために、コミュニケーションが多く必要である一方で、それに対するスキルや工数が評価されにくい、つまり、やりにくさは認識しやすいが、やりやすさは認識しにくい、という点です。

ここでハッとしたのですが、制作内容の複雑化・多様化、役割の細分化・分業化・専門化が進んできたからこそ、

  • 専門性をより深めること=縦軸の充実
  • プロジェクト全体を俯瞰すること=横軸や領域の理解
  • コミュニケーション=縦軸と横軸をつなげ、まとめる力

の3つの要素がとても大事で、それらがバランスよくできるようになるほど、『速く正確で効率よくニーズに最適なWeb制作』に繋がるのだと思いました。

まさかの、「きほん」の「き」みたいなオチではありますが、答えは案外シンプルなところにあるんだなー、という感想と、この3要素とバランスを念頭におきつつ、「工数の見える化」「サービスの仕組」「スキルアップ教育」等々について、今一度見直し、調整をしていきたいと思います。

この投稿を書いた人

児嶋 いずみ

児嶋 いずみ(こじま いずみ)コーディングファクトリー部 部長

前部長からCFの徳光という称号をもらうほど、うれしいときとせつないときに号泣する十八番を持っています。コーディングファクトリー部の部長です。

児嶋 いずみが書いた他の記事を見る