$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

ハトネコエ

February 27, 2023
Tweet

More Decks by ハトネコエ

Other Decks in Technology

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. 負債を作らない第1歩
    • 1週間後の自分が読んでわからなそうな場所に

    コメントを書くようにしよう!


    • タスクに取りかかる前に、それが何日かかりそうな

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

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

      身につき、きれいにコードを書けるようになります


    • ページャーの機能を必ず実装するようにしよう!

    View Slide

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

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

    画面を作ってあげてください


    • これがあるだけで、表示の遅すぎるページが

    だいぶ生まれにくくなります


    • Rails でも Laravel でも

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

    View Slide

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

    View Slide