今回はテクニカルな内容を書きます。
僕がこの業界に入ってきた頃は、まだtableコーディングって物が残ってました。
IE６という魔王が君臨し、スタイルシートも意味不明なハックで無理くり対応するというカオスな時代だったと思います。
過去の記事でも書いていますが、僕は小さな制作会社にいたので、デザイン希望で働いていましたが、デザインだけやっていればいいわけではなく、何でも屋さんとしてコードを書くという作業もやっていました。
ほんの３年前くらいまで、そこいらのコーダーより早かったという自信があります（笑）
ですが、一瞬です。現場から離れたら、ここ最近のテクニックの革新についていけなくなってしまいました。
常に携わられてる人たちからすると、何を今更と思われるかもしれませんが、まだまだ現状ってこんなことよく起こってるんじゃないか？と思い記事にすることにしました。
SassとGulpの台頭
今自分のチームの実装部隊は多くの案件で、Sassを使ったデザイン実装と、Gulpというタスクランナー（書き出しの自動化）の仕組みを使っています。
書き出しのルールはJavascriptによって自身でカスタマイズしていくことが出来ます。
Sassは、CSSの拡張系と言えばいいんでしょうか？
今までのCSSの記述ではできなかったような入れ子での記述ができたり、javascriptのように変数でデザインの見た目を定義しておいて、様々なところで使いまわしたりできるものです。
HTML+CSSでのデザイン実装は、ほぼ暗記で出来ていましたが、Sassをつかうとよりプログラミングに近い思考を使っておこなうというように変わっています。
今年に入ってから、一人その辺りの整備ができるスタッフを採用し、チームに周知を始めました。
その背景には、自分のチームが代理店さんが取り扱う大きめの規模の構築に参画することが多く、先方の実装チームとルールを揃えるためという理由がありました。
そのテクニックがないと、プロジェクトに参加できないというハードルがあったのです。
実装のテクニックは基本的に、効率化のために作られているといってもいいでしょう。
確かに、様々なものが自動化フローがあったり、コードの記述をシステマティックにまとめられたりと、効率をあげられる要因は多くあります。
実装を行うひとたちは、このような新しいテクニックが生まれたときに喜び、いち早く取り入れた人も多いのではないかと思います。
しかし、こういった技術革新は、現場においてひとつの弊害を生み出してしまったと、僕は危惧しています。
プロジェクトマネジメントとテクニックによる効率化の弊害
先の章で記載したことがそのまま弊害となります。
「テクニックがないと、プロジェクトに参加できない」
これは、実際にチームの中で起こったことです。
ある実装者が、任された案件の実装をGulpで環境を作り、Sassを使ってコーディングしていました。
彼は、リーダー格なので、復数の案件を同時に進行しています。
ひとつの案件で、想定以上の対応を求められ、彼自身のリソースが切迫してしまい、上記実装に遅延が生じてきました。
プロジェクトマネジメント上、遅延が発生した場合、進捗を保つために回避策を講じなければなりません。
プロジェクトマネジメントの鉄則として、スケジュールが遅延してきたり、問題が発生した場合の回避策が4つあります。
1.延期
これは最後の手段にしなければなりませんね。その工程を延期することで、他の工程も見直さねばならないだけでなく、最悪の場合納期を延ばし、クライアントに多大な損害を与えかねません。
2.リソースの追加
一人でこなせる作業量には限度があります。その為該当のフェーズにリソースを追加し、作業分散をすることで遅れを取り戻します。
3.リソースの転換
今回のように復数案件を回している場合、一方を別の人間が対応するようにアサイン自体を変えてしまい、途切れなく対応することでスケジュールを遵守します。
4.そもそも転嫁
3に似ていますが、プロジェクト自体を外に丸投げします。急に受けてくれる先も少ないでしょうし、金銭的なところでは躊躇しますが、自社で無理をして続けるリスクを考えると、リソースに余裕のあるところに転嫁するのは得策と言えるかもしれません。
しかし、今回の状況では、2，3，4の3つの回避法が使えなかったのです。
実装者から遅延のリスクを相談されたときに、まず2の提案をしました。
社内には他案件をやってはいますが、そこまで急ぎのものではなく、2日ほどであればヘルプに入れるスタッフがいました。
しかし、そのスタッフが、まだ完全にGulp環境とSassコーディングのテクニックを習得しきれていないため、手伝うことができなかったのです。
技術者である以上、テクニックを習得するというのは必至ですし、それが自身でできない以上、技術の道を志すことは出来ないでしょう。
しかし、ここ最近の革新のスピードは目まぐるしく、一人のスタッフが前戦で使えるようになるのに今まで以上に時間がかかるのと、より専門的なスタッフが必要になってしまったと言えるでしょう。
昔は、コーダーが手一杯になってしまったとき、デザイナーやサーバーサイドのプログラマが、一般的な知識のもと、簡単なところであれば量産を手伝ったり出来ましたが、できなくなってしまったのです。
同じ状況は、4の転嫁でもおこり、外への振り先が限られてしまう、または振り先がなくなり、行き詰まってしまうという問題が発生しています。
結局今回は、元の実装者が無理をして一人で対応するという選択にせざるをえませんでした。
作業環境の構築の人依存
もう一つの弊害があります。
それは、作業環境構築の人依存です。
昔は、ちょっとした環境は皆XAMPPっていう便利なGUIを使って手軽に作っていたと思います。
Gulp環境を作るには、macならターミナルから、winならターミナルもどきの「黒い画面」から、nodoなどをインストールし、処理のルールもちゃんとjavascriptで書かなければなりません。
プログラムに触れることが少ないスタッフは、そもそもこの「黒い画面」に拒否反応をしめします(笑)
しかも書き出しのルールは、間違えるとそもそもグダグダになり、使う意味すらなくなります。
要は、ちゃんとプログラムを分かっている人がチームにいなければならない且つ、その人に依存してしまうという問題をはらんでいます。
技術革新の中で変わらなければならない現場
僕が、業界に入った頃、このweb業界は意外にハードルが低く、未経験でも唯一入り込めるデザインの世界だったんじゃないか？って思います。
それは、まだまだ発展途上だったフロントエンドの技術のおかげだったのかもしれません。
だれもが手探りで可能性を探し、質の高いものも低いものも、入り乱れた混沌とした時代だったのです。
今その混沌は統一されつつあり、完全な専門分野として確立されつつあると思います。
今現場で、フロントエンドのリーダー格になっている人は、おそらく以前の混沌とした時代の生き残りが多いはずです。
彼らは、誰でもできるという分野が「あなた達しかできない」分野になった事を誇りに思うと同時に、一つの確立された行程を受け持つ責任と、チーム内だけでなくパートナーも含め、技術やテクニックを標準化するためのエバンジェリスト的なコミュケーション能力が求められます。
また、僕らのように全体をプロマネする立場の場合、最初からヘルプが必要そうになるようなことが予想される案件に関しては、少し効率を落としたとしても、従来のテクニックを使うように実装チームにアドバイスすることも必要なことと感じます。
あとは、各パートがより専門的になることで、チーム内での縦割り化が自然に起こってしまうことが危惧されます。
デザイン側から見て、実装の人が何やってるかわからない、ディレクターから見て実装者のスピード感が読めないでは、困ってしまいます。
周囲の人間も理解しようとすることが求められるでしょう。
そして、これらの人に紐付いたテクニックは、近いうちにアプリケーションによって誰でも扱える普遍的なものに変わっていくはずです。
その時にうまく立ち回れるかどうかが今の現場の行動に、一番求められているのではないかと思います。