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

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

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

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

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

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

技 術 的 負 債 と は な に か

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

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

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

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

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

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

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

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

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

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

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

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

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