外注時技術ガイドラインのドラフトを公開してみます。

2016年12月6日

こんにちは、榊原@rdlaboです。
いよいよ12月に入りました。師走です。坊主も走り回るシーズン、皆さんいかがお過ごしでしょうか。

弊社は、webアプリ開発は変更が多いので中でこなしますが、webサイト制作はデザインからHTMLコーディングまでの作業は委託することの方が多いです。もうなんだったらクライアント様に「地元のデザイナー知り合いいないんですか?」というレベルで(デザイン面では何かと顔を合わせる方がスムーズにいくことが多いので)

で、その中でお願いしているところとしばし技術的なすり合わせが必要になります。多いのは「ドラフトできました」とソースコードをzipでいただいて「あれ?」となることですね。Gitじゃないの?と。それをツイートしたところ

 
という反応をいただきましてふと思い立ったので、まだドラフト段階ではありますが弊社で作成中の外注依頼時の技術シートについてご紹介します。

ガイドラインのドラフト

1. Git縛り

Gitの非公開レポジトリを利用してソースコードを共有いただきます。zipもしくはFTPでの共有は、バージョン管理ができず、また変更点の確認が困難なためご遠慮いただいております。

 
まずは、Gitでのシェアをお願いしております。正直なところ、初稿版作成だけでしたらzipでもFTPでもいいのですが(いや、嫌ですが)、それからの変更をサーバにFTPでつないで・・・とかしておりますと、確認に手間がかかってしょうがない。そもそも、脱FTP、Git導入って受注側にメリットしかないと思うんですよね。

  • サーバが死んでもデータはGit上に残ってる
  • 予期しない工数がかかっても、作業自体を進めてることは履歴でアピールできる
  • 完成後にあーやこーやいわれても「Gitでシェアしてましたよね?」といえる(基本確認不足側が悪いと思ってる人)
  • GitHubだったら草を生やせるw

ブランチを分けてチケット管理して、までは求めず、masterブランチ1本でいいのでGit。せめてGitの導入をお願いしています。

2. CSSフレームワークを推奨

CSSフレームワークの利用もしくはスタイルガイドの作成をお願いしております。

 
まぁ、スタイルガイドでもいいのですが。オレオレCSSフレームワークも私はきらいではないのですが、微修正する時とかに結構癖があることが多いんですよね。
あと、input[type=’text’]のパターンは用意していても、ドラフト時にはなかったinput[type=’radio’]のパターンがなかったり。正直なところこういうパターン漏れがオレオレCSSフレームワークではよく起きます。ですので、CSSフレームワークの利用を推奨しています。その上で、パターンガイドがあったらさいこー( 水交デザインオフィスさんのお仕事はこのパターンでした )。
 
どうしてもCSSフレームワークつかえないならせめてスタイルガイドを・・・と思うんですが、どちらかをお願いするとCSSフレームワークを採用いただけてるので、スタイルガイドを納品いただいたことはないですw

3. SCSSでの納品のお願い

CSSはSCSSでのコーディングをお願いしております

 
これは弊社の都合で恐縮なのですが、SCSSでお願いしています。厳密にいうと、CSSでも別にいいんですが、こっちでさわる時はSCSSにして保守することが多いのです。
で、新しいデザインパターンをお願いしようと思った時に「SCSSってなんですか?」だと大変都合が悪い。どの案件とはいいませんが、SCSSからコンパイルされたCSSを上書きしてきた方がいらっしゃいまして、ここらへん意思の疎通コストをかけるのがつらいので最初から「SCSSでお願いします」といってます。
いや、BEMで納品してくれといってるわけじゃないので良心的ですし!
 

4.ユーザ環境について

スマホ対応(レスポンシブ対応)をお願いしております。モバイルファースト推奨。また、ブラウザは最新版のみとし、後方互換は必要ありません。

 
2016年に一番大きな舵取りした部分として、モバイルファースト推奨にしました。「レスポンシブで要素を隠してモバイル対応だ!」よりは、「モバイルに最適につくったあと、ラップトップでどう表示をレスポンシブにするか考える方がいいです」と。エンジニア・デザイナーともに、フルスペックを発揮できるのはラップトップというのは重々承知しながらも、ラップトップ前提にすると結局「メニューはハンバーガーメニューで隠す」みたいなことになってしまうので。モバイルファーストの方が世界は広がるなと。
あと、もうブラウザの後方互換は業界的にやめましょうよ・・・(ただiPhone Safariだけは対応をお願いしています。つらい)
 

5.その他は実績とGit管理

よくあるガイドラインとして「HTML5通りのマークアップをしましょう」「命名規則はこうしましょう」などがありますが、それは「ガイドラインにあるから受注非受注を決める」「命名規則はポリシーを捨てて言われたとおりにする」というのはなんか違うなと思っておりまして、基本的には制作実績をいただいてソースコードをみて「人」で判断しています。なので、フリーランスであったり、数人チームの会社に受注をお願いすることの方が多いです。
で、もう契約しましたら、そこからはGitで相手のコードを読んで、コメントするぐらいの方が生産的だなと。
 

まとめ

今、少し悩んでるのは、例えば環境構築。Vagrantで共有してくださいね、とか、Dockerにしましょう、とかも少し悩んでるんですが、私個人としてはMAMPも好きですし、WordPressレベルだとPHPのバージョンで大きなトラブルも起きないのでわざわざ記述する必要があるかなとか。あとは、デザインレベルで「基調色の選定納品」とか、「モジュールデザイン(AtomicデザインのMOLECULESレベル)での納品」とかいろいろ段階をつくるのもこれからwebアプリのデザインを外注する上では有効だなと。
 
昔よくみたような「相手を縛るガイドライン」ではなく、「気持ちよく協業する上でたたき台になるガイドライン」。ぜひ皆さんも考えてみてはいかがでしょうか。
それではまた。