「フリーランスエンジニアが受託案件をスムーズに進めるために心がけてること」西塚 豪

2018年2月2日に行われたDIST.19 「フリーランスの生存戦略」のスライドです。

■概要
近年、雇用関係によらない働き方として、フリーランスに注目が集まっています。Web制作業界では、このような関心の高まりよりもずいぶん前から、フリーランスとして活躍しているデザイナー、エンジニア、ディレクターが多数います。

特定の組織に属さず、専門的なスキルを生かして、多種多様なプロジェクトに関与する……というと、理想的な働き方にも聞こえますが、実際にはそう簡単ではありません。凡庸では務まりませんし、会社員に比べると、営業、経理、事務など間接的な仕事量も増えます。当然仕事がなければ収入はゼロです。このような厳しくも楽しい？環境に身を置き、フリーランスとして活躍する人々は、次の時代を生き抜くヒントを持ち合わせているのかもしれません。

DIST.19では、実際に長年フリーランスとして活躍しているスピーカーのみなさんをお招きし、実際にどういう仕事をどういう風に進めているのか、その実態について迫ります。

■DISTについて
DISTは、職種や技術の垣根を越えてWebに関わるすべての人を結ぶクリエイティブコミュニティです。

Web制作関連をテーマとした勉強会を、2ヶ月に1回程度のペースで開催しています。デザイナー、エンジニア、ディレクターなどあらゆる立場の方に参加していただき、その知の共有、研鑽ならびに参加者同士の交流を目的としています。

■公式サイト
http://dist.tokyo

■GitHubリポジトリ
https://github.com/448jp/dist

Transcript

1. フリーランスエンジニアが 受託案件をスムーズに 進めるために心がけてること 　~ DIST.19 「フリーランスの生存戦略」 ~
2. 主にウェブサイト作ってます。 あとらす二十一 → SONICJAM → フリーランス
3. 受託案件をスムーズに進めるために 普段心がけていること、 「なるべく効率よく、他のメンバーにもや さしい実装方法」のお話。
4. ・チーム内でコーディング規約があり、メンバーがそれを守って開発を行う ・コードレビューを行なって品質を守っている ・毎日MTGを行い、情報や進捗を共有、コミュニケーション方法も統一 ・基本的に同じメンバー間で開発を行う Webサービス系企業の場合 すごくスマートな環境！
5. 受託案件(フリーランス)の場合 ・案件毎にルール、レギュレーションが違う、無い。やばいコードに出会うことも。 ・メンバーも毎回新しい人とお仕事をやる、スキルもまちまち。 ・コミュニケーションがメール、鬼電、修正ppt送りつけ、、、 ・クライアントまで何層も人を介したりして、情報の伝達が悪い。 すごくカオス！
6. メンバーでの仕事の進め方、意思の統一が出来ている かでその案件のスムーズ度が違う。 そして、案件ごとに毎回その土台作りが必要。 しかし、受託の特性上 全てをスマートな環境にするの は不可能な話なので、 出来る限り、スムーズに運べるようにする。
7. コミュニケーション編
8. コミュニケーション方法はかなり重要。 ここをきちんと整備出来るかで やりとりの工数や、ストレスが変わってくる。
9. とある作業の依頼メール・・・
12. 問題点 ・メールでのやりとりだと件名が「Re:Re:Re:修正の依頼」 のようになり、あとからメールの内容を検索しずらい、そ もそも何の作業依頼なのかが不明。 ・1つのメールで３つの依頼が来てしまっている。 さらにその中で複数の修正依頼があり、漏れる可能性 がある。優先度も謎。 ・更新する可能性のあるファイルが添付されているので、 色んなバージョンのものが散る可能性がある。
14. ヌーラボ社が運営している プロジェクト管理ツール
15. このツールを使用すると 先ほどの例は
17. 改善点 ・タスクが細かい粒子でリスト化されて、残っているタス クが一目瞭然 (子課題もたてられる)。終わったらタスク を完了にして、全部無くなったら終了。 ・作業担当者、タスクのステータス、優先度が可視化さ れた。 ・タスクごとにスレットが立てられたので、他のタスクとや りとりが混ざらなくなった。
18. スケジュール ワイヤーフレーム
19. 出来れば CACOOや、Googleスプレッドシートなどのオンラインツール を使って一元管理してもらうのが理想。 でも、クライアントやディレクターに強制するのは 難しいので、（セキュリティ的に無理です、等言われることも） その辺は適宜。
20. 何だかんだで現実的なライン、 Officeのファイルで管理して、 Backlogのフォルダに日付ごとにファイルを格納 メールで無限に添付してくると、どれが最新か わからないのでやめましょう！（やめて）
21. 燃える案件の座組み （ちょっと盛ってます）
22. お抱えのシステム会社 代理店 他部署の方々 偉い人(会長) デザイナー エンジニア A 担当者 ファイヤー！ フットワーク重い 意思の疎通無し あーしろ、こーしろ 公開してから確認 忙しい Webよくわからない 情報全然こないなー ディレクター
23. Backlogを クライアントにも 使ってもらって 円滑パターン
24. クライアント 制作 担当者 ディレクター システム 部長 デザイナー エンジニア B
25. ただし、ルールを決めてあげないと 割とめちゃくちゃになりがちなので、 ・キックオフMTGの際に使い方の共有 ・タスクの雛形を作ってあげる やりとりのコストがスムーズ！ 理想形
26. Backlogを 制作サイドのみで 使うパターン （大体これが多い）
27. クライアント 制作 担当者 ディレクター システム 部長 デザイナー エンジニア C
28. これだと、ディレクターの負荷は高い、 タスク登録しなおしたり、 技術的なやりとりに齟齬が生まれたりする。 ・専門的なやりとりはクライアントと直で ・なるべくディレクターに協力する ・タスクは制作サイドみんなで管理 進行はスムーズ
29. クライアント 制作 担当者 ディレクター システム 部長 デザイナー エンジニア C`
30. あとは、エンジニアに関して言えば、 ・モヒカンをやめる →エンジニアが「それわかんないでしょ・・・」、っていうよ うなワードを羅列して、ディレクターが「・・・」ってなってる ときがあるので、噛み砕いて説明してあげる。 ・文章を作ってあげる →技術的、専門的なやりとりをメールで送るとき、 ディレクターにコピペでそのまま送れるように 文章を作ってあげる。可能なら直でやりとりする。
31. 一番重要なのは、初回MTG時に コミュニケーションの方法やルールについてきちん とクライアント、メンバーと握っておくこと！ これがなぁなぁだと、ツールがあっても やりとりのコストがかさみ、良いものが作れない。
32. ちなみに、backlogの便利な機能 ・gitが内蔵されていて、タスクとコミットを連動出来る。 ・wikiをpdfにしてダウンロード出来る ・他もあるけど今回は割愛。
33. 内蔵されたgitに適切なコメントでpushすると、、、
34. タスクID コメント ステータス変更
35. Wikiに仕様などを細かく書いておいてPDFにして
36. このままクライアントに展開。
37. オールインワンで便利！！
38. 実装編
39. 80点を目指す ここにおける80点の意味とは、 ・個人の開発のしやすさだけを追求しない。 ・なるべくシェアが高い技術を使う。
40. HTML テンプレートエンジン の選定
41. 人気どころでいうと下記３つ
42. ・インデントベースでコード量が少ないから開発が早い ・include とか extendが便利 ・javascriptが使える。 ・開発が活発でシェアもある ・複雑に書くと、コードが読みづらい ・htmlとの親和性がよくないのでコピペしてくる、などは厳しい。 ・学習コストは他に比べて高め。
43. ・htmlベース ・includeが便利 ・javascriptが使える。 ・開発が活発でシェアもある ・htmlとの親和性が高い。 ・学習コストは低め。
44. ・誰でも触れる ・ページの量産がしんどい ・SSIで共通化する前提
45. (1).公開期間 短 長 Pug,EJS,は、nodeのバージョン依存や、プラグイン自体の 開発が止まる可能性があるので、短い公開期間向き。
46. (2).規模、ページ数 少 多 インクルードや、javascriptなど機能が充実しているので、 量産の時は便利。 ただあまりにファイル数が多すぎる場合は、htmlの生成 に時間がかかる可能性がある。
47. (3).開発人数 少 多 スキルもまちまちだと思うので、人数が多いほどシンプ ルで難易度が低いものを採用したほうが無難。
48. (4).クライアント側で運用する場合 クライアント側で、実装環境が用意できるなら、pug, EJSでも可。 出来ない場合は、納品後は、テンプレートエンジンとは完全に 切り離してhtmlベースで運用してもらう。 大きい規模の場合は全部、静的html納品だと運用側がキツイ ので「html + SSI 」の方が良い。 case by case
49. (5).組み込みがある場合 Wordpress案件など、組み込み側としては、 Pugで書かれると修正の際にgitでの差分が分かり辛い。 その場合は、ビルドされたhtmlもgitで管理してもらう必要が ある。(gitで管理するhtmlの数が倍になる。) やりやすさ
50. これは完全な愚痴なんですが、 Gulpとかpugを使う場合は、組み込みサイドとしては ビルドされたデータをgitでignoreしないで欲しい！ 修正があるたびにpull→タスクランナー走らせる、 とか狂気の沙汰かと。。 「Gulpなんて知らない」ってシステム屋もいるわけで。 それなら直接テンプレ修正して！！と思う。 最近は、フロント側に直接修正してもらいます。逆もし かりです。ありがとうございます。
51. CSS
52. VS
53. ・カスタマイズ性に優れていて、沢山のプラグインがある ・パフォーマンスが良い ・自由度が高いが、カスタマイズされすぎると属人的なコードに なってしまう。 より良いコードを突き詰めていくにはこちらがいいかも。 限られたメンバー内でCSSを書くことに向いている。
54. ・ユーザー数、コミュニティが大きい。 ・いい意味で枯れている、廃れる可能性は低い。 一通りの便利な機能が揃っていて、ユーザー数が多いので 不特定多数のメンバーと作業する時に向いている。 80点目指すならこちらが良い。
55. これはあくまで私の考え方なので、 違うよ！って方いたら是非。 大事な事は、 「自分がやりやすいことだけに走るのではなく、 それぞれの特性を考えつつ、技術を選んでいくこと」 だと思います。 そこまで考えられるエンジニアさんは ちゃんとお仕事くると思います、多分。
56. z-index:99999 組み込み後に デザイン修正！ 公開後 会長がやり直しを 命じる Bemでネスト深す ぎ！ 案件ペンディング！ なるはや！ Android 標準ブラウザ死 インクルードで！ IE9で崩れます！ スケジュールに連休 入ってる！
57. 今日もカオス おわりです