技術的負債を防ぐには / What is the Technical Debt

2023/02/24（金）に開催された
『【初心者歓迎！】気になるテクノロジー 語り出したら止まらNight（略してかたとま）』( https://oweb.connpass.com/event/271924/ ) でおこなったLT登壇の資料です。

技術的負債がなぜ起こるのかを説明しつつ、
プログラミング初心者に向けた、技術的負債を防ぐ最初の一歩についてご紹介しています。

Transcript

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

   View Slide

2. 自己紹介
   • 名前：横江（よこえ）
   
   
   • Twitter： yokoe24
   
   
   • ラブグラフ（好きな場所で👉のような
   

   写真を撮ってくれるサービス）のCTO
   
   
   • 好きなもの：人と話すこと
   
   
   • 今回の資料は G's ACADEMY の
   

   生徒さんを意識して作成しました
   

   View Slide

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

   View Slide

4. G's ACADEMY
   • このイベントの主催
   
   
   • 「起業」をゴールとする人にもフォーカスした
   

   プログラミングスクール
   
   
   • 2015年にデジタルハリウッド
   

   株式会社が設立
   
   
   • カミナシのCEO諸岡さんも
   

   G's ACADEMY卒業生
   

   View Slide

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

   View Slide

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

   View Slide

7. 技 術 的 負 債 と は
   
   
   な に か
   

   View Slide

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

   View Slide

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

   View Slide

10. 負債の発生の仕方例
    • 開発時間が足りず、将来の拡張性を考えずに実装
    
    
    • 企画側（PM）が作った設計書に従って、
    

    変な分岐が増えるのにそのまま実装してしまった
    
    
    • 機能を削除したのにコードを一部残したままに
    
    
    • コードにコメントを書かない
    
    
    • ライブラリのバージョンを上げることなく数年経過
    
    
    • ストレージ容量をとりあえず大きめに契約
    
    
    • データベースの知識が薄く表示速度の遅いページ作成
    

    View Slide

11. それぞれ何が起こるか 1
    • 開発時間が足りず、将来の拡張性を考えずに実装
    

    → これを繰り返した結果、コード量が多くなり、
    

    新入社員エンジニアのキャッチアップスピード低下
    
    
    • 企画側（PM）が作った設計書に従って、
    

    変な分岐が増えるのにそのまま実装してしまった
    

    → PMと相談すればマストではなかったとわかる実装
    に時間をいっぱいかけた上、あとから読む人にとって
    意図のわかりくいコードがいっぱいに・・・
    

    View Slide

12. それぞれ何が起こるか 2
    • 機能を削除したのにコードを一部残したままに
    

    → あとから見た人にとって消していいかわからない
    コードが残り続け、コードの可読性が低下
    
    
    • コードにコメントを書かない
    

    → 複雑な処理を読み解くのに時間がかかったり、実装
    背景のわからないコードが残って後任が困惑したり
    
    
    • ライブラリのバージョンを上げることなく数年経過
    

    → バージョンアップは差分が大きくなるほど困難に
    

    View Slide

13. それぞれ何が起こるか 3
    • ストレージ容量をとりあえず大きめに契約
    

    → AWSのEBSやRDSのストレージ容量は増やすのは簡
    単だが減らすのは難しい。無駄コストがかかり続ける
    
    
    • データベースの知識が薄く表示速度の遅いページ作成
    

    → N+1問題と呼ばれる、データベースに大量のアク
    セスをしてしまってページ表示が遅くなる問題が起こ
    る。ユーザーの不満増加、管理者画面の操作効率低
    下、開発スピードも低下が起こる
    

    View Slide

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

    View Slide

15. 技術的負債は生まれる 1
    • 開発時間が足りず、将来の拡張性を考えずに実装
    

    一番最初に書いたこちら、実はベンチャーにとっては
    正義です！
    

    作った機能をなくす結果になることは多々あります。
    

    「せっかく作ったのにもったいない！」なんて気持ち
    になることを避けるためにも、拡張性はあまり考え
    ず、とりあえずで実装するのが正解です！
    

    View Slide

16. 技術的負債は生まれる 2
    • 企画側（PM）が作った設計書に従って、
    

    変な分岐が増えるのにそのまま実装してしまった
    

    企画側と相談すればもっと単純に実装できたはずの
    

    ものに時間をかけるのはギルティーですが、
    

    開発的にちょっと負債になりそうでも、それが顧客を
    幸せにできる特殊な実装ならするべきです。
    

    ときには技術的負債を生んででも、プロダクトの価値
    を最大化するのが開発チームの価値です。
    

    View Slide

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

    View Slide

18. 負債を作らない第１歩
    • １週間後の自分が読んでわからなそうな場所に
    

    コメントを書くようにしよう！
    
    
    • タスクに取りかかる前に、それが何日かかりそうな
    

    タスクかをあらかじめ概算する習慣をつけよう！
    

    → 大きな実装を小さな部品ごとに分けて考える習慣が
    

    　 身につき、きれいにコードを書けるようになります
    
    
    • ページャーの機能を必ず実装するようにしよう！
    

    View Slide

19. ページャーの機能
    • 全てのデータを１ページで表示しようとせず、
    

    ページャーを実装して、50件ごと表示するような
    

    画面を作ってあげてください
    
    
    • これがあるだけで、表示の遅すぎるページが
    

    だいぶ生まれにくくなります
    
    
    • Rails でも Laravel でも
    

    かんたんに実装できます！
    

    View Slide

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

    View Slide