Slide 1

Slide 1 text

ٕज़తෛ࠴Λ ๷͙ʹ͸ ԣ ߐ ʢ Α ͜ ͑ ʣ ͔ͨͱ·φΠτ-5ʂ

Slide 2

Slide 2 text

自己紹介 • 名前:横江(よこえ) • Twitter: yokoe24 • ラブグラフ(好きな場所で👉のような 
 写真を撮ってくれるサービス)のCTO • 好きなもの:人と話すこと • 今回の資料は G's ACADEMY の 
 生徒さんを意識して作成しました

Slide 3

Slide 3 text

G ' s A C A D E M Y と は

Slide 4

Slide 4 text

G's ACADEMY • このイベントの主催 • 「起業」をゴールとする人にもフォーカスした 
 プログラミングスクール • 2015年にデジタルハリウッド 
 株式会社が設立 • カミナシのCEO諸岡さんも 
 G's ACADEMY卒業生

Slide 5

Slide 5 text

起業に絡む技術的問題 • 最初のMVP(Minimum Viable Product)が作れない • G's ACADEMY がサポート • 最初のエンジニアが見つからない • CEO自身がコードを書けることですぐには困らない • 採用時、いいエンジニアかを見分けられる G's ACADEMY で学ぶことで解決! すごい!

Slide 6

Slide 6 text

起業に絡む技術的問題 • 最初のMVP(Minimum Viable Product)が作れない • G's ACADEMY がサポート • 最初のエンジニアが見つからない • CEO自身がコードを書けることですぐには困らない • 採用時、いいエンジニアかを見分けられる • 技術的負債で開発速度が低下 • 経験が足りないとこれは避けにくい

Slide 7

Slide 7 text

技 術 的 負 債 と は な に か

Slide 8

Slide 8 text

技術的負債とは 将来のことを考えずに実装した結果、 あとでしっぺ返しをくらうこと。 具体的には、開発スピードの低下や インフラコストの増加が起こりやすい。

Slide 9

Slide 9 text

技術的負債とは 将来のことを考えずに実装した結果、 あとでしっぺ返しをくらうこと。 具体的には、開発スピードの低下や インフラコストの増加が起こりやすい。 → 会社の成長スピードが低下!!

Slide 10

Slide 10 text

負債の発生の仕方例 • 開発時間が足りず、将来の拡張性を考えずに実装 • 企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった • 機能を削除したのにコードを一部残したままに • コードにコメントを書かない • ライブラリのバージョンを上げることなく数年経過 • ストレージ容量をとりあえず大きめに契約 • データベースの知識が薄く表示速度の遅いページ作成

Slide 11

Slide 11 text

それぞれ何が起こるか 1 • 開発時間が足りず、将来の拡張性を考えずに実装 
 → これを繰り返した結果、コード量が多くなり、 
 新入社員エンジニアのキャッチアップスピード低下 • 企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった 
 → PMと相談すればマストではなかったとわかる実装 に時間をいっぱいかけた上、あとから読む人にとって 意図のわかりくいコードがいっぱいに・・・

Slide 12

Slide 12 text

それぞれ何が起こるか 2 • 機能を削除したのにコードを一部残したままに 
 → あとから見た人にとって消していいかわからない コードが残り続け、コードの可読性が低下 • コードにコメントを書かない 
 → 複雑な処理を読み解くのに時間がかかったり、実装 背景のわからないコードが残って後任が困惑したり • ライブラリのバージョンを上げることなく数年経過 
 → バージョンアップは差分が大きくなるほど困難に

Slide 13

Slide 13 text

それぞれ何が起こるか 3 • ストレージ容量をとりあえず大きめに契約 
 → AWSのEBSやRDSのストレージ容量は増やすのは簡 単だが減らすのは難しい。無駄コストがかかり続ける • データベースの知識が薄く表示速度の遅いページ作成 
 → N+1問題と呼ばれる、データベースに大量のアク セスをしてしまってページ表示が遅くなる問題が起こ る。ユーザーの不満増加、管理者画面の操作効率低 下、開発スピードも低下が起こる

Slide 14

Slide 14 text

で も 技 術 的 負 債 は し ょ う が な い

Slide 15

Slide 15 text

技術的負債は生まれる 1 • 開発時間が足りず、将来の拡張性を考えずに実装 
 一番最初に書いたこちら、実はベンチャーにとっては 正義です! 
 作った機能をなくす結果になることは多々あります。 
 「せっかく作ったのにもったいない!」なんて気持ち になることを避けるためにも、拡張性はあまり考え ず、とりあえずで実装するのが正解です!

Slide 16

Slide 16 text

技術的負債は生まれる 2 • 企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった 
 企画側と相談すればもっと単純に実装できたはずの 
 ものに時間をかけるのはギルティーですが、 
 開発的にちょっと負債になりそうでも、それが顧客を 幸せにできる特殊な実装ならするべきです。 
 ときには技術的負債を生んででも、プロダクトの価値 を最大化するのが開発チームの価値です。

Slide 17

Slide 17 text

今 す ぐ で き る 技 術 的 負 債 の 防 止

Slide 18

Slide 18 text

負債を作らない第1歩 • 1週間後の自分が読んでわからなそうな場所に 
 コメントを書くようにしよう! • タスクに取りかかる前に、それが何日かかりそうな 
 タスクかをあらかじめ概算する習慣をつけよう! 
 → 大きな実装を小さな部品ごとに分けて考える習慣が 
   身につき、きれいにコードを書けるようになります • ページャーの機能を必ず実装するようにしよう!

Slide 19

Slide 19 text

ページャーの機能 • 全てのデータを1ページで表示しようとせず、 
 ページャーを実装して、50件ごと表示するような 
 画面を作ってあげてください • これがあるだけで、表示の遅すぎるページが 
 だいぶ生まれにくくなります • Rails でも Laravel でも 
 かんたんに実装できます!

Slide 20

Slide 20 text

最後に いろいろ言ったけど・・・ 深く考える以上に完成させるのが1番大事!!