2ヶ月でB2Bサービスをリリースしてみよう

Transcript

1. 2016/09/27 渋谷 亮 ２ヶ月で BtoB サービスを リリースしてみよう
2. 自己紹介 渋谷 亮 (@ryoff) 33歳 大学(生物) > 広告エンジニア > 広告エンジニア > MF
3. リリースしてみた 2015年3月リリース 開発期間：約３ヶ月 2015年10月リリース 開発期間：約１ヶ月
4. 目標 早い開発速度 予定通りリリース メンテナンス性の高さ 安定稼働 ＋
5. 実際にやってよかった ５つのこと 目標の達成のために
6. その１：リリース前確認シート 最初に作成 ↓ チーム内コード規約 ↓ レビュー観点の統一 コードの統一感 ＋ リリース直前に焦らない 【一部抜粋】
7. 【略さない】 部門ID dept_id / department_id 【具体化】 sub_info / mail_setting その２：和英辞書 【用語統一】 性別 sex / gender 手当 payment / allowance 苗字 family name / last name
8. その２：和英辞書 変数名 Class名 の表記揺れ解消 ↓ 誰が読んでも、意味のわかるコードへ ↓ レビューコスト減 & コードの可読性向上 (コードを書く時間 << コードを読む時間) 属人性排除 開発速度 & メンテナンス性の向上
9. その３：もくもく会 http://d.hatena.ne.jp/keyword/もくもく会 「喫茶店で各自がもくもくと勉強したり、もくもくと本を読んだりするだけの会」
10. チーム全員で、数時間同じ会議室で作業 ↓ 開発しながら議論 開発しながら相談 開発しながら共有 一人で悩む時間を減らす 情報共有のための会議を減らす 設計・開発の方向性を常に合わせる その３：もくもく会
11. 【確認シート】【辞書＆用語集】 【もくもく会】【レビュー】etc ↓ コード規約に落とす ☓ ドキュメントが欲しい？ ◦ レビューの感情対立回避 その４：コード規約
12. 「俺すげー」をしすぎない ↓ 「俺すげー」なコードは、 俺がすごすぎて、 俺にしか読めない ↓ 個人の開発速度 << チームの開発速度 その４：コード規約
13. 「やる事」を期限までにやる ではなく 「やる事の優先度」を常に考える その５：やらない意思決定
14. その５：やらない意思決定 参照元：「いくら長時間働いても仕事は終わらない」と語る上司 http://nzmoyasystem.hatenablog.com/entry/long_time_work_cannot_finish_tasks 「長時間仕事をしたところで、仕事が終わるなんてありえない」 「なぜなら、問題を解決するたびに、次の問題が見つかるのだから」 「常に苦渋の決断をしながら、優先順位をつける」 「システム開発のような知的労働は、いくら時間をかけたところで終わらないの だ」
15. その５：やらない意思決定 リリースまで残り１ヶ月 ↓ タスク量はちょうど１ヶ月 ↓ = オンスケ (?) 「１０の仕事を終えれば、新たに３の仕事が生まれる」 エンバグ / デグレ / 仕様変更 / 仕様漏れ
16. その５：やらない意思決定 不測の事態に備え、優先順位を意識 いつでも、やらない意思決定をできるように ↓ 「(みんなだいすき) デスマーチ」回避
17. 【エンジニアの方に質問】 Q：「デスマ中に書いたコードを、自信を持って見せれますか？」 デスマの怖さは、 デスマ自体よりも、 その際に生み出される負債 その５：やらない意思決定
18. その５：やらない意思決定 生み出された負債は、 サービスの安定性を、 数年に渡って損なわせる
19. ☓ 「今だけ苦しいけど、頑張ろう！」 ◦ 本当に苦しいのは、数年後の開発者 ベンチャーで一所懸命がむしゃらに働く ≠ とにかくコード書く その５：やらない意思決定
20. 引き続き、挑戦中! 早い開発速度 予定通りリリース メンテナンス性の高さ 安定稼働 ＋
21. Thank you!