こんにちは、コーディングファクトリー部の田中です。
去る9月29日、大崎ブライトコアホールにて開催された CSS Nite LP58「Coder’s High 2018」。そこに参加して感じたのは、開発者としてだけではないコーダーの役割の変化と、現場での理想と現実でした。
 

CSS Nite LP58「Coder’s High 2018」

前回もレポートしましたこのイベント。昨年に続き、今回も参加してまいりました。

セッションのラインナップは以下でした。
各セッションの内容をひとつひとつ説明すると長くなりますし、いずれ本家のフォローアップも公開されますので、詳しいことはそちらや他のレビュー記事をご覧いただくことをおすすめします。

イベントについては、タイトルと私の感想を簡単に併記します。（敬称略）

CSS Nite LP58「Coder’s High 2018」
http://cssnite.jp/lp/lp58/

基調講演：技術トレンドとの向き合い方
中村 勇希（トゥーアール）

電車の遅延により、私は聞くことができませんでした。日々更新されていくトレンド情報。そのキャッチアップの仕方からどのように学習するかまで、わかりやすく解説されていたようです。聞きたかった。

コーダーとデザイナーの溝を埋める、業務改善のタネ
水越 佑介（リーグラフィ）

コーダーにとってデザイナーとのコミュニケーションの改善は業界に入ってすぐに、そしてその後も度々ぶつかる問題です。そしてそれはデザイナーにとっても同じこと。作業の切り分けやコーダーで関われる範囲、目から鱗でこれからのヒントになりました。

実案件から学んだフロントエンドにおけるアクセシビリティ対応
植木 真（インフォアクシア）、秋山 豊志（コンセント）

対応しようとすると工数もかかる為、難しく考えがちなアクセシビリティ。ですがこれだけWebが普及した今では対応が避けられないものでもあります。対応しているつもりでも正確性を欠きがちな技術でもありますが、非常にわかりやすい解説で、どうにか取り入れられないか思わず考えてしまいました。

コーダーも知っておきたい解析事情 2018
井水 大輔（エスファクトリー）

GAなどの解析ツールの組み込みは通常業務でも行いますが、詳しい中身まではあまり考えたことがないと気づきました。またセッション中に出てきたコーダーとしての価値が上がる配慮のひと言には、コーダーの新たな役割への変化を感じました。

Webサイト表示速度改善手法
阿部 正幸（モチヤ）
フロントエンドでサイトスピードUP！
佐藤 あゆみ（ism／PentaPROgram）

２連続で速度改善のセッション！いかにこの分野がアツく、もはや対応して当然のようになっているかが伺えます。はじめはなぜ遅いか？の調査について、次のセッションではスキルレベルの高くないコーダーでも今すぐ取り入れられる速度改善のノウハウについて。必見と言っても過言ではない内容でした。

現場で役立つCSSアニメーション
伊藤 由暁（まぼろし）

ここでやっと「見た目の実装」に関わるセッション。CSSに限らず、アニメーションは言葉だけでやりとりしても折衝しにくいもの。自分たちなりのレシピ集のようなものがあると、色々とスムーズになりそうです。

もう一歩踏み込んで現場で使うCSS Grid
鹿野 壮（ICS）

話題のCSS Gridも対応ブラウザが増え、いよいよ現場でゴリゴリ使う日も近づいてきました。今回はより具体的に実際の案件例も見ることができ、現場で使うイメージが固まりました。

クロージングトーク：UI開発者の生存戦略
木達 一仁（ミツエーリンクス）

開発とは何か？哲学ではありませんが、短いようで長い歴史を感じながら、そんなことを考えてしまいました…。

どれも明日から、むしろいますぐ使える・使いたい内容で、現実の現場に即したノウハウが得られました。

そして同時に、あることにも気がつきました。
 

コーダーの役割の変化・現場の理想と現実
デザインとしてのコーディングから、プログラムとしてのコーディングへ

今回のCSS Niteを聴講してよりはっきりと自覚したのは「コーダーの役割の変化」。
実際にCFでも、クロスブラウザでも耐えられる、1px単位でデザインを実現するコーディングから、AjaxやJSONを用いてほぼシステムのような機能を実装していくコーディングへと案件自体が変化してきています。
また、Gulpなどタスクランナーの登場により、Koalaなどコンパイラに頼っていたあの頃から制作環境も変化しました。

そして。速度改善・アクセシビリティ・解析への配慮…「自分が書いたコードが何を扱っているのか、与える影響は何か」。様々なクライアントとのやりとりを通して、これを考慮してサイトコーディングを設計していくことが、コーダーの仕事の当たり前になってきていると感じています。
Webというのは常に過渡期の世界。その早い時流の中で、私が働くCFでも様々な「理想と現実」が出てきました。

理想と現実①プロジェクトへの関わり方の変化に対する体制の難しさ

長きにわたり、多くの場合コーディング工程はウォーターフォールで行われてきました。
ディレクターが仕様を決定し、デザイナーが見た目と動きを設計し、コーダーはそれを現実のものにする。
私が入社したての頃は、単純な量産でない限りデザインが入稿されないとコーディングに着手できませんでした。デザインの実現が主な仕事だったため、「上流工程」からの指示がなければ何を正として進めればいいのかわからなかったからです。

今はどうでしょうか。先日の記事のように、CFにご相談いただく案件の性質自体が「どのブラウザで見ても崩れのないデザインの実現とちょっとした機能実装」からすでに変化しています。

そこで出てくる第一の問題は、一つのプロジェクトにおけるコーダーの関わり方と体制の問題です。
例えば全国の店舗検索のような機能をフロントエンド側で実装するとなった場合、その実装にどのような技術が必要で、具体的にどれくらい時間や人員＝工数が必要なのか、ディレクターやデザイナーが正確かつ精密に把握してコーダーに指示することを求められるでしょうか？また、コーディングフェーズに降りてきてから実装を進めつつよくよく精査してみたら、実はバックエンドで実装した方が小工数かつ高機能なものを（安く）実現できた、ということもままあります。

このように、フロントエンドの本当のところは「書ける人」にしかわからないことも多いのです。ウォーターフォール的進行をしてしまうと、コーダーが入る前に上流工程でがっちり設計してからそういうことが発覚してしまい、クライアントにとっても制作側にとっても、いろいろと決める段階から入れたらよかったのに…と感じることもありました。

そこまで言うならその通り、設計段階から入ればいいのでは？はい、ごもっともです。
そこに体制の問題があります。フロントエンドの本当のところがフロントエンド開発者にしかわからないのと同じように、ディレクターやデザイナーの仕事には、コーダーは知らないことが多いのが現状。上流工程に参加しても、わけも分からぬままリソースを割いてしまい、モチベーションも下がり成果を出せず、結果プロジェクト全体の生産性の低下に繋がりかねません。
Webサイト制作のプロジェクト進行の変化に対して、まだまだ体制が変わりきれていないことがあります。Webサイトを動かす「プログラム」としてのコーディングのプロとして、ウォーターフォールでもなくリソースの無駄な消費も防げるような、そんなプロジェクトへの関わり方の模索は、今後も大きな課題となるでしょう。

CFではコーダー自身がコーディングディレクションも担当し、自らのソースコードに責任をもつ仕事の進め方をしていますが、こういった案件の仕様やフローの複雑化があり、コーディング以外の面でより高度な知識や制作進行スキルを求められるようになりました。
現在は、これまで培ってきたディレクション能力を生かす形で、アジャイル進行などウォーターフォールに限らずあらゆる進行体制に積極的に関わっています。また、サーバーサイドやバックエンドなどの技術、コーディング以外のディレクションにも知見を持ったスタッフを育成することにより、より上流の段階からクライアントのご相談に対応し、お互いにとって良いプロジェクト進行ができる体制づくりを進めています。

理想と現実②スケジュールへ影響しない工数・リソースの確保

これまで同様、運用のことも考慮してテンプレート設計したり、ソースの視認性を上げつつ、複雑なシステム的実装も進めなければならない。言われなくても速度改善にも気を遣って、広告展開や解析にも配慮する。クライアントから直接指示を受ける以外にも、コーダー側でプログラム的な面において考慮することが増えたため、ページ制作にかかる「工数」がクライアントの希望スケジュールに対して膨らみがちになってきています。
CFでは案件相談時に現場経験のある専門のスタッフが工数算出しています。ただ、先にも書いた通り、昨今ではその段階ではまだ細かい仕様までは決めきれず、実際に制作に入ってからそこを精査していくため、想定していたスケジュールやリソースより工数が増えてしまいます。自らも制作しながら案件進行も行うため、その難易度によっては人員や日程の確保が遅れ、間に合わせるために連日連夜残業に徹夜までしてしまうこともあります。

コーディングは頭脳を使う仕事です。睡眠不足や体力の低下は侮れません。精神面での影響は成果物に少なからず影響を与えます。そのようなことを抜きにしても、十分な調査やテスト、品質管理を行うために確保したい時間と実制作の時間のバランスを取ることがどんどん難しくなっていきます。同時に、求められるクオリティの質が変化しているとも感じています。機能が重い場合はもちろん、デザイン重視のこともあれば、最低限のコンテンツが保証できていれば、納品までのスピードが大事なこともある。プロジェクトごとに「キモ」は様々です。
プロジェクト全体のスケジュールを把握しながら、クライアントと共に仕様を詰め、その制作のための十分な工数を確保しなければならない。そこにコーディング自体の難易度も上がってきていて、CFのコーダーに求められるスキルレベルはコーディング・ディレクション双方でどんどん高くなってきています。

CFではクライアントにプロジェクト全体の詳細なスケジュールをご提示いただくようお願いすることがあります。自分たちの作業はプロジェクトの流れの中でどんな位置にあるのか、前後にどういった工程があるのか。そこから、必要な対応期間やフィードバック対応などの想定されるスケジュールを詳細工数より逆算し、どのように制作を進めるか精査する為です。プロジェクト全体でのスケジュールがはっきりと決まっていない場合、こちらである程度の目星をつけた上でクライアントと一緒にスケジュール決定することもあります。
ここでのハンドリングがうまくいかないと、お互いにとって良くない結果になりかねないので、慎重かつ正確に進めていきます。
質問が多いと正直うんざりされることもあるかもしれませんが、ご協力いただけると助かります。また、気づいたことはどんどんご相談いただけると、非常に助かります。
 

「見た目を作る人」から「見た目も中身も考えて作る人」へ、さあ次は何だろう？
コーダーの変化と戦いは続く

CSS Nite 「Coder’s High」のいいところは、他の多くのイベントのように「これからコレが来るぞ！」ではなく、その時その時の現場の少し先、もしくは現在使える技術やノウハウを一通りサクサクと食べられるところじゃないかな、と思います。
「これからコレが来るぞ！」と言われても、現場では今すぐには使えなかったり、結局使わなかったりするモノもたくさんあります。それよりも現実的で、実際の「時流」を感じられる。世間では初心者向けと言われているようですが、経験を重ねたコーダーにとっても非常にいいイベントです。

コーダーの役割は「見た目を作る人」から「見た目も中身も考えて作る開発者」へ、もはや完全に変化したといっていいでしょう。
大変なこともありますが、やれることの幅がぐんぐん広がっていて、これまでより「開発者」として制作に携われる部分が増え、とってもわくわくしています。

本講演の「クロージングトーク：UI開発者の生存戦略」（ミツエーリンクス・木達 一仁さん）のお話にもあったように、私がWeb業界に入ったここ5年弱だけでも、これだけの変化があったのですから、本当に移り変わりの早い世界です。その中で開発者はどのように生き残っていくか。Webの世界を広く見て、これからも積極的に変化し続けていきたい。

さあ、次はどうなるのでしょうか？
来年のCSS Niteが、今からとても楽しみです。