HTMLコーダーのリスクマネジメントの話

コーディングの仕事中、「あ、これはまずいな」と感じるときがあります。

しかしコーディングまで回ってきた段階では既に決定事項であったり、期限が迫っている等の理由で上流工程へのバックがきかない状況になっていることが少なくありません。

コーダーというのは実装――つまり下流工程に位置しているため、作業の遅れや上流工程での想定不足といった部分の煽りを食らってしまいがちです。

そういう場合どうやって危険を察知するのか、そしてリスク管理するのか、というのが今回の記事の主題です。

目次

リスクを察知する5つの方法

1. 危ないパターンに対する経験値を溜める
2. プロジェクトに関わる人の情報を把握する
3. 要素の目的を自分なりに推測して、その是非を考えるようにする
4. 視点を切り替えて考える癖をつける
5. 危険なワードのストックをする

危ないパターンに対する経験値を溜める

これに関して言うと、正直なところゲームで言う『死にゲー』みたいなものでして、何度も何度もプレイすることで死ぬポイントを体感で覚えるというそれに近いです。

しかし言っておいていきなりですが、

• 社内で運用のディレクター経験があり
• 同じディレクター・デザイナーと何度も組んだことがあり
• クライアントの業種も毎回ほぼ同じ

という条件が重なったことによるところも大きく、仮に他の業種のサイト制作を担当したらあまり役に立たないのかも知れません。

プロジェクトに関わる人の情報を把握する

人に基づくパターン把握と予測はそれなりに有用です。

情報収集の方法としては、

• クライアントとのやりとりのメールを見る
• 電話の声のトーンに意識を傾ける
• ディレクターやデザイナーの癖を蓄積する

といった具合です。

同じ人は同じことを繰り返す傾向があります。

癖を理解していれば予測も立てやすいですし、先手を打てる場合も。

また、コーダーは直接折衝することはありませんが、クライアントのタイプを大雑把にでも把握していると、リスク回避に役立つことも多いです。

要素の目的を自分なりに推測して、その是非を考えるようにする

デザインの勉強を少しずつしていく内に、サイト要素の配置は論理の積み重ねだということが少しずつわかってきました。

• このバナーがここに配置されているのは推したいコンテンツだろうか。
• 推したいコンテンツはこれで、だからこの配置なのだろうか。
• この部分のテキストの色が違うが別の部分より目立たせたいのだろうか。
• ボタンがこの位置にあるが導線をこう確保したいのだろうか。

などなど考えると大体の流れや目的がわかったりすることも多いのですが、そこに馴染まないものが紛れ込んでいて違和感を覚えることがあります。

違和感というのは私の場合、

• クライアントの発言から推測される目的が達成できそうにない
• 要素が整理されていない
• そもそも目的の推測さえできない謎の要素がある

という辺りから発生しているようです。

具体的な例を挙げると、

• コンテンツの順番や配置が不合理
• ざっと目を通しただけでもまとまりのない文章だと感じる
• リンク先指示さえない、押してなにが起こるか不明な謎のボタンがある
• 導線がはっきりしない
• デザインがしっくりきていない
• 項目が異様なほどたくさんあるが整理がされていない
• リストの種類などがいくつもあるが『その装飾はどういったときに使うのか』の基準がよくわからない
• 仕様がはっきりしない

といった、危険信号がいくつもあります。

一見小綺麗なサイトでもカンプを見てこういった嫌な感じがすると、やはり異様に修正や追加が多いなどの難航案件になることが多いです。

視点を切り替えて考える癖をつける

ロールプレイをするつもりで『若い女性だったら／年配の男性だったら／親だったら／クライアントだったら』……など、他人の視点でサイトを眺めます。

大体1～5分くらいでざっくりと（サイトは開いて数十秒しか閲覧されないケースも多いので）トップページを上から下まで眺めながら、ボタンや要素の位置をざっと見て『サイトを閲覧する目的を達成できるか？』を考えます。

ペルソナは大体下記のような感じで、サイトのコンテンツに合いそうな属性を適当に入れています。

• 23歳女性
• →社会人1年目、ネットはスマホメイン、趣味ネイル
• 28歳男性
• →社会人5年目中堅、ネットはじっくり見るときはPC、外出先はスマホ、趣味スポーツ

他、クライアントの視点作りには日頃からメールのやりとりなどを見ておいて、どの変にこだわりを持っているのかなどある程度の嗜好や性格を把握するよう努めておいたりもします。

こういう風に視点を切り替えて見ていると、年配の男性にはちょっとわかりづらそうだなとか、連絡先がすぐに見当たらないなとか、この部分はクライアントがあとで追加要望してきそうだなあとか細々気づくことがあります。

デザインカンプを受け取った際、あまりに各視点で使いづらさや見づらさを感じるもの、クライアントの目的に会っていなさそうなもの、性格的に好みそうでないものがあればあたりをつけおきます。

そういうところは高確率で後々修正が入ったりしますし、作業着手はしないまでも仮に改善するとしたら、と簡単にでも案と工程を考えておくと役に立ったりします。

危険なワードのストックをする

たとえば一般的なところでいうと、なるはや、優先、緊急対応などのワードが入り始めたら警戒を始めます。本当ならどれもあってはならないからです。

その他『この人の名前が出たら難航しやすい』という社内ローカルなものまで、これが出たら危険なワードというのをひっそりストックしています。

下流工程なりのリスクマネジメント

サイト実装という工程の最下流を担当していると、リスク回避の手法としてできることはそこまで多くありません。

冒頭で述べた通り、『既に決まってしまっていて上流工程にバックできない』という状況であることが多々あるからです。

これには締め切りが決まっていてバックする時間がないということも含まれます。

しかし手をこまねいていても仕方がないので、できる範囲で下記ようなことをしてリスク回避を試みています。

上流工程の動向を把握する

上流工程の部分で調整するのが一番効果が高いので、できる場合は以下のようなことをやっています。

• 上流工程の動向を見ておいて、違和感のある場合確認を入れてみる
• 何度も修正が来る場合は言われた修正をただ行うのではなく、再度依頼がきたタイミングで提案をする
• クライアントの依頼の原文を見て、依頼の内容との齟齬を確認する

コーダーまで情報が流れてこない場合も多々あるのですが、そもそもなぜやるか、どうしてそうなったのかを知っているのと知らないのとではだいぶ効率も変わってきます。

作業者が陥りやすいことですが、言われたことを理由や流れを理解せずに言われたままにやるのは、それ自体がリスクです。

時間や状況的にできないこともありますが、可能な限りは上流工程の動向を見ていると色々把握しやすくなります。

あえて作り込まない箇所を見極める

今はCSS3がかなり使えるようになってきているので、画像を使わずに再現できる範囲は広くなってきています。

メンテナンスしやすくなるので、特にテキストなどの変更が多そうな箇所は作りこんだ方がいいのです。本当は。

しかし、コーディングでの作りこみはそれなりに手間がかかります。

下手をすると単純にPC／スマホ／タブレットで別々の画像を準備するより時間が必要です。

しかも再修正依頼がきたら、作り込みに要した作業時間がそっくり無駄になってしまいます。

加えて『またやり直し』というのは精神的にも、時間的にもダメージが結構きてしまうもので……。

それを回避するために、下記のような箇所は、あえてコーディングでは作りこまず簡単な方法で実装するという手段を取ることがあります。

明らかに短期的にしか掲載しない箇所

たとえば突発的なイベントのバナーや、ちょっとしたお知らせや注意書きの付記などがそれにあたります。

こういう部分を更新が容易なよう作り込みしてもいずれは消えることがほとんどですし、htmlファイルから該当箇所を削除してもCSSにコードが残ったりと、CSSファイルを肥大化させる原因にもなります。

そういう場合は、

• 可能な限り汎用的なClassを組み合わせて対処する
• 単に画像を貼るだけで済ませる
• インラインCSSで済ませる

等の対処で『その部分』しかソースコードを残さないようにしています。

違和感を感じる箇所

依頼やデザインを確認して、サイトの構成として奇妙だと感じることがあります。

『とりあえず見たいから作ってくれ』と模索のために気軽に依頼してくるから起こることも多い問題なのですが、結果、何度も何度も修正に付き合わされることも少なくありません。

しかしながら、こういった『とりあえず』と『デザイン模索』全てに全力で応じていたら、残念ながらリソースが圧迫されてしまいます。

そういう訳で、違和感が残る内は*1コーディングでの作り込みはせず、画像を貼るだけなど一番楽な実装方法で済ませてしまいます。

どう考えても画像で掲載した方が良さそうな箇所

CSSでできる範囲は広がりましたが、残念ながら万能ではありません。画像で表現した方が良い場合というのは確実にあります。

そういう部分は無理にCSSで対処せず、画像での表現に任せることにしています。

修正内容を見越して準備しておく

来るとしたらどういう修正になりそうか、あらかじめ予測して準備しておきます。

量産フェーズに入る前に、特にコーディングの根底に関わりそうな部分はなるべく修正が楽なようにしておきます。

期限の調整

なるべく複数案件の締め切りを重複させない

複数案件の締め切りが同じ時期に重複するのは、それだけでリスク要因です。

Web制作はどうしても波のある仕事だと思います。波の発生原因は色々ありますが、いずれにせよ実装担当は遅れの吸収をしなければならないことが多い役割です。

また、締め切り間際に思わぬ作業が舞い込んだりすることもよくある話で。

なので依頼締め切りが重複した場合、期限の調整をお願いするようにしています。

ずらさなかったとしても普通に間に合いそうな場合もよくありますが、それでも可能なら調整を申し出ます。

いつでも最速・最短を見越して予定を立てるとトラブル時リカバリーがききませんので、余裕はできるだけもらっておくに越したことはありません。

状況によっては作業が完了してもあえて手元に置いておく

仕事が終わったらできるだけ早く報告すべきではありますが、あえてすぐ報告せずに手元に置いておくこともあります。

それは以下の場合。

• 五月雨で追加依頼が来る
• 『なるはや』や割り込みが常習化している

これは『割り込み頻度をこちらでコントロールする』ことを目的にしています。

作業はまとめてやった方が効率がいいし、割り込みが増えると単純に集中が切れやすくなって良いことがありません。

また、作業の『なるはや』や割り込みが常習化するのも避けるべき事態です。

本来ならディレクション側で行うべきことでもあるのですが、それが期待できないときは頭に入れておいても良い方法と思います。

ストックを増やす

ソースコードのストック

これは他の人もやっていることではないでしょうか。

コーディングをしていると、「前も似たようなことを書いたな」ということがかなりあります。そういう場合、部品別にソースコードを参照できるようにストックしておくと楽になります。

また、CSSで再現している見出しスタイルをまとめたサイトなどもストックしておくとそのままでは使えないとしても「こういうことはできる」というのはわかるので、有用です。

プラグインのストック

よく使うスライダー、入れてくれと頻繁に求められる機能は、すぐに入れられるように調整した上でストックしておきます。

また、使えそうなプラグインも暇を見てストックに入れたりもします。

調整まで済ませておくと、いざ追加や修正依頼がきたとき手早くできます。

案件終了後にテンプレートを見直して改善する

コーディングをする人なら、大抵基本のワンセットをまとめたテンプレートを作っているのではないでしょうか。

私の場合だと、

• 基本のひな型htmlファイル
• 古いブラウザ対応用のプラグイン
• リセットCSS
• 基本設定や部品を入れたCSS
• よく使うjQueryセット

……をまとめておいて、これを案件毎にコピーして使用します。

比較的シンプルにして余分な要素は省いています。

そして案件が終わったときに元々のテンプレートの使いにくかった点を細々修正して、マイナーアップデートを繰り返します。

地味なことですが、元のテンプレートをアップデートをしていかないと、使いにくい部分やミスが以降の案件でも発生し、また修正に時間を取られる……ということになってしまいます。

案件終了毎にテンプレートの見直しをするのは時間がかかりますが、長期的にはペイできているのではないかなと思っています。

つい最近大きく変えたことは、要素の横並びにflexboxを使用するようにしたこと。少し前はfloatで並べていましたが、それと比べると非常に楽です。

情報共有

弊社の場合基本的に案件は個人単位で完結してしまうのですが、担当中の案件の簡易な情報を共有メモに残したり、ファイルに関してはローカルに抱え込まず、他の人が見たときに最新ファイルがわかりやすいようにしています。

また、ソースコードには適宜コメントを残すように。

個人で仕事が完結してしまうことがほとんどなので、やらなかったとしてもあまり影響は出ませんが、万一ということがあるので習慣として行っています。

情報の記録・分析

やった作業やかかった時間、感想などを簡単にメモして残し、ときどき振り返っています。

上で述べたような、人の癖や傾向を把握する際役立ちますし、ストック作りのヒントや、そのほか全体として眺めると一定の傾向が見えたりします。また、自分の傾向を知るのにも役立ちます。

その際改善できそうな部分は改善に着手しますし、無理そうなら頭にだけ留めておくなど、記録を取っておくとなにかと便利です。

まとめ

フロントエンドエンジニアやコーダーは一体どうやってリスクマネジメントをしているのだろう、と思って調べた結果、あまりそういうことを書いている人がいないのがこのエントリーを書いた動機でした。

大体がコーディングを早くするとかツールを使うとかスキルを高めるとかそういう話ばかりで、確かにそれは大切なことなのですが、自分の求める情報ではないな、と思ったのです。

それで書いてみた結果、コーディングという枠にだけ閉じこもっていたらできることは少ないなあと感じた次第です。

ディレクションはディレクターの役目。

デザインはデザイナーの役目。

コーディングはコーダーの役目。

サイト制作の目標を決めるのはクライアントの役目。

……というのは分業化が進む昨今間違いではないのですが、それだと特に下流工程のコーダーは波に振り回されるだけになってしまいます。

職分を無理にはみ出すつもりはないのですが、リスクを察知する・回避するという視点に立った場合、『依頼をこなすだけ』という以上のことをどうしても考えざるを得ない訳で。

あれこれ本を読みながら、結局ディレクターのこと、デザイナーのこと、クライアントのことを知らないといけないのだなということに思い至って、拙いながら上記のことを考えながら仕事をしています。

余談：将来の仕事について

また将来を考えた場合、いずれコーディングの仕事は機械に取って代わられてしまうであろうと私は思っています。

現在でも既に（制限はありますが）直感的なUIによって部品を組み合わせるだけでサイトが作れるようになっていますし、この流れはもっと進むのではないでしょうか。

また、今のhtmlというもの自体ががらっと変わってしまうことも考えられます。

そうなると人間としてできる仕事は、『なにをするのか』『なぜそれをやるのか』『どうやるのか』を考えることがメインになると思います。

すぐという話ではないにしても、サイト制作というのは結局そういう方向に行きつくと思うので、リスクマネジメントとして『コーディングだけしかできない・しない』にならないように気を付けているという面もあります。

勉強用に読んだ本

HTML5/CSS3モダンコーディング フロントエンドエンジニアが教える3つの本格レイアウト スタンダード・グリッド・シングルページレイアウトの作り方

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

沈黙のWebマーケティング −Webマーケッター ボーンの逆襲− ディレクターズ・エディション

第一線のプロがホンネで教える 超実践的 Webディレクターの教科書

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

デザインの教室 手を動かして学ぶデザイントレーニング(CDROM付)

センスは知識からはじまる

問題解決に効く「行為のデザイン」思考法

*1:ただし提案できる場合は見本に作ることもある