2015年2月26日の【ヒカ☆ラボ】にご登壇された株式会社Goodpatchの右寺氏のプレゼン資料です。

1. 1
プロジェクトの炎上を防ぐために
フロントエンドエンジニアとして
できること
株式会社グッドパッチ
フロントエンドエンジニア
右寺 隆信
@migi

2. 2
自己紹介

3. 3
右寺 隆信 (ミギテラ タカノブ)
今まで、いろんな会社で
いろんなことをやってきました。
ウェブサービス企画→法人営業→ウェブデザイナ→
ウェブディレクタ→フロントエンドエンジニア→
ソシャゲディレクタ→ゲームデザイナ→
フロントエンドエンジニア(←いまここ)
器用貧乏です。

4. 44
趣味は、ポーカー・人狼・ボドゲなど
去年、CodeIQさんで人狼の記事書いたので
興味がある方はどうぞ。
https://codeiq.jp/magazine/2014/03/6714/

5. 5
について

6. 1. Goodpatch : 会社概要
日本で数少ないUIデザイン専門の会社。デザインによって、企業の価値やブランドをあげることを目指している。
webサービスからスマートフォンアプリケーションまで、上流から下流までUX・UIの企画設計、実装を行う。
大手メーカー様から、新規スタートアップ企業様までクライアントは多岐に渡る。
http://goodpatch.com
6

7. 1. Goodpatch : ビジョン 7
人々のハートを揺さぶる
Design&Productを生み出し
世界をより良い方向に前進させる
Move people s hearts with
Great Design and Products
to push the world forward.
VISION

8. 1. Goodpatch : 実績 8

9. 1. Goodpatch : 実績 - Gunosy
Gunosy App (iPhone Ver.2.0)
ニュースレコメンドサービス「Gunosy」の初期からiPhone App (Ver.2.0)までのデザインを担当。
サービス開始直後GunosyにUIデザインを提供し、サービス成長に大きく貢献。
UI設計 / UIデザイン
http://gunosy.com/iphone
9

10. 1. Goodpatch : 実績 - Money Forward
Money Forward App (iPhone)
アカウントアグリゲーションのサービス「Money Forward」App全面リニューアル。高機能かつ複雑なアプリケーショ
ンの機能を整理し、ユーザーレビューで高評価を獲得。2014年度グッドデザイン賞 受賞(主催：公益財団法人日本デザイン振興会)
https://moneyforward.com
http://memo.goodpatch.co/2014/08/moneyforward_redesign/
UI設計 / UIデザイン
10

11. 1. Goodpatch : 実績 - Prott (自社サービス)
prott UI設計 / UIデザイン / コーディング
https://prottapp.com
11
モバイルアプリ向けのラピッドプロトタイピングツール。Goodpatchの自社サービスとして2014年4月にリリース。
利用ユーザー数は1万6000人を突破（2015年1月時点）。
大手ウェブサービス企業にてEnterpriseプランの採用実績多数（Yahoo! , DeNA , GREE , Recruit , Excite）。

12. 1. Goodpatch : 実績 - Prott (自社サービス) 12
コンセプトデザイン、サービスデザイン、ゲーム開発など幅広い分野で導入

13. 13
グッドパッチにおける
フロントエンドエンジニア
の立ち位置

14. 14
フロントエンドエンジニア
コーダー
デザイナー
ディレクター
フロントエンドエンジニアとコーダーは兼任
デザイナーはコードは書かない
専任ディレクターもいるがデザイナーやフロントエンドエンジニアがディレクターをすることもある
私はこのあたり

15. 15
本題

16. 16
この中で、
デスマーチ/案件の炎上を
経験したことのある方は
いらっしゃいますか？

17. 17
この中で、
デスマーチが好きな方は
いらっしゃいますか？

18. 18
まぁ、そうですよね、、、
(́・ω・`)

19. 19
案件が炎上して
デスマーチに突入することで

20. 20
身体を壊す
家庭を壊す
人間関係を壊す
精神を壊す

21. 21
＿人人 人人＿
＞ 緩慢な死 ＜
￣Y^Y^Y^Y￣

22. 22
普段の仕事では
簡潔で
わかりやすく
保守性が高く
堅牢で
効率が良く
無駄がない
そんなコードを書きたい

23. 23
これがデスマーチに
突入すると

24. 24
とにかく時間が無い！！！
↓
とりあえず、最低限動くものを………
↓
ウンコードの量産

25. 25
最低です

26. 26
精神衛生的にも悪いし
なによりエンジニアとしての
成長の機会も失われています

27. 27
炎上させたくないですよね…

28. 28
全てだとは言えませんが
炎上のほとんどは
PM/ディレクタの責任です

29. 29
しかし、
優秀なPM/ディレクタなんて
そうそういるものではありません
そもそも、優秀なPM/ディレクタって何さ？

30. 30
しかも、
プロジェクトが炎上して実際に苦しむのは
エンジニアである自分です

31. 31
自分の身は自分で守りたい

32. 32
では、どうするか？

33. 33
フロントエンドエンジニアに
できることは無いのか？

34. 34
少しでも炎上の可能性を減らすため
フロントエンドエンジニアとして
できること

35. 35
私は、あると思います

36. 36
具体的には、次の4点

37. 37
1. 契約内容を確認しておこう
2. 対応範囲を明確にしておこう
3. 技術選定は最初に合意を取ろう
4. スケジューリングには必ず関わろう

38. 38
1. 契約内容を確認しておこう
2. 対応範囲を明確にしておこう
3. 技術選定は最初に合意を取ろう
4. スケジューリングには必ず関わろう

39. 39
この案件は
どういう契約形態なのか？
契約書/見積書/発注書を
しっかり確認しましょう

40. 40
「成果物を期日までに納品すること」
「プロジェクトを進める上での人月」
クライアントが支払うお金は
どちらに対するものでしょうか？

41. 41
「最高の成果物を追い求めすぎて
仕様が膨らんでしまって
結局納期に間に合わない！！」

42. 42
後者のような契約形態で
スクラム方式でスプリントを
回していくような案件であれば
問題無いとも言えますが
前者のような契約形態だった場合は
確実に炎上に繋がります

43. 43
1. 契約内容を確認しておこう
2. 対応範囲を明確にしておこう
3. 技術選定は最初に合意を取ろう
4. スケジューリングには必ず関わろう

44. 44
最近、社内社外問わず
たまに聞くお話

45. 45
デザインを起こして
HTML/CSS/JSでモックを作る
までのお仕事

46. 46
と思っていたら…
サーバサイドはAPIで
jsonを返すだけなので
API繋ぎこんで
ルーティングまでさせて
処理は全部フロントエンドで！

47. 47
個人的にはこれは、俗に言う
フロントエンドエンジニア
やること多すぎ問題
の一種だと思っています

48. 48
フロントエンドでできることが増えた
↓
フロントエンドエンジニアは必死にがんばる
↓
でもディレクタは完全には理解できていない
↓
クライアントの方で思っている
「ここまでやってくれるだろう」という
実装範囲の齟齬が発生してしまう

49. 49
もちろん、ディレクタに
フロントエンド業務の全てを
理解してもらうのは無理です

50. 50
モダンなサイト構築において
「どのあたりを気をつければ良いか？」
ということを事前にディレクタと
共有するだけでも随分違うと思います

51. 51
可能であれば、クライアントとのMtgには
ディレクタと一緒に出席しましょう
無理な場合も、Mtg後でも
「どの範囲をやるのか？」という点について
しっかりと突っ込みましょう

52. 52
もはや、言わずもがなですが
対応ブラウザなんかも明確に…

53. 53
1. 契約内容を確認しておこう
2. 対応範囲を明確にしておこう
3. 技術選定は最初に合意を取ろう
4. スケジューリングには必ず関わろう

54. 54
ただでさえ忙しいフロントエンドまわり
最近は便利な
フレームワーク/ツール/メタ言語
がたくさんありますね？

55. 55
http://www.slideshare.net/t32k/i-wanna-bea-frontendengineer

56. 56
使いこなして効率的に案件を進めるぜ！

57. 57
ちょっと待って！！

58. 58
それ使うこと、
クライアントに合意取れてる？

59. 59
悲劇：その1

60. 60
最近いつもJade使ってるし
この案件でもJadeでさくさく作ったる！
(｀・ω・́)

61. 61
半月後、納品直前
「サーバーサイドはRuby on Railsで
実装するのでslimで
やって欲しいんだけど…」

62. 62
えっ！？書きなおすの……
(́・ω・`)

63. 63
悲劇：その２

64. 64
最近流行ってるし便利そうだし
AngularJSゴリゴリ使って進めるお！
(｀・ω・́)

65. 65
一ヶ月後、納品直前
「え？ウチの会社にAngularJS
分かる人いないし保守できなくなるから
止めてほしいなー」
「というか、SEO重要なサイトって
言ってあるけど、AngularJSで
ちゃんと対策考えてるの？」

66. 66
どうしよ…これ……
(́・ω・`)

67. 67
案件が始まる際に
クライアント側のエンジニアと
どういうツールを使ってやるのか
しっかりと合意を取りましょう

68. 68
1. 契約内容を確認しておこう
2. 対応範囲を明確にしておこう
3. 技術選定は最初に合意を取ろう
4. スケジューリングには必ず関わろう

69. 69
いつのまにかディレクタとクライアントの間で
スケジュールが出来上がっている
↓
工数的に絶対無理じゃん！！！
↓
揉める
↓
もう決まったことだから
↓
デスマ突入

70. 70
作業に対しての工数はしっかり見積もりましょう
スケジュール厳しいから
とにかくもう進めちゃって！
は後から苦しい状態しか生まないと思います

71. 71
というわけで

72. 72
社内のPM/ディレクタと上手く協力して
素敵なプロジェクトにしていきたいものですね

73. 73
以上、ありがとうございました。