CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

【デバッグ効率化①】デバッグにかかっていた2,500時間を削減する話

初めましてクルーズ株式会社、社長特命執行部執行責任者の松島です。

CROOZに2012年入社後、諸々紆余曲折ありまして、現在は本社で技術上がりのなんでも屋をしています。

 

今回自分からは当社が運営しているファッションECサイト『SHOPLIST.com by CROOZ』にて自分がオーナーとして取り組ませてもらっているプロジェクト、「本当に必要な実装の時間を確保するために、無駄なデバッグ時間を削減」の話をしていきたいと思います。

◆先に結論を書いてしまうと…

今現在SHOPLISTでは某クライアント型テストツール、Autify、nodejs、puppeteerを使用してデバッグ時間を削減する取り組みを実施しています。絶賛取り組み中です。

今現在絶賛取り組み中のため対応が完了したところまではお話できないのですが、それぞれをどんな意図と経緯で使うことになったのか?導入をしてみてどうだったのか?等を一通りお話しできる範囲で話せればと考えています。

 

なお、この記事においては非エンジニアに向けての内容も多く含まれるものとなるため、特に非エンジニア職の人にも見て頂ければ幸いです。

◆本当に必要な実装時間って何?

「本当に必要な実装の時間」とはつまり「新しい開発や既存の改善」を行う時間です。

 

ECサイトであるSHOPLISTの開発業務には大きく以下の2つの業務があります。

【業務1】日々の運用業務

【業務2】新しい開発や既存の改善

 

上記の2つの業務のうち

「【業務1】日々の運用業務」に大きく時間を割かれ…

「【業務2】新しい開発や既存の改善」にも大きく時間を割かれ…

結果として時間が足らなくなり「開発のスピードが超鈍化」するという問題が発生していました。

 

この「開発のスピードが超鈍化」問題を改善するために「本当に必要な実装の時間を確保するために、無駄なデバッグ時間を削減」するというのが今回の趣旨です。

なお、最初に話が降ってわいたこの時の自分の感想としては「なんでそんなにデバッグに時間かかってるの?」という疑問符しかないところからのスタートでした。

◆開発の速度を加速するための2,500時間

ではまず、「無駄なデバッグ時間」とはどれぐらいあったのか?でいうと、まずプロジェクトスタート当初の集計ではSHOPLISTのデバッグ時間は開発部全体で2,500時間/月が発生していました。

・1人1月の稼働時間が160時間(8時間x20日)

・2,500時間/月は人数に直すと約15人/月分

これは会社としては大きなコストとなりますし、さらにエンジニアでしか対応ができない内容となっていた場合非常に不毛な2,500時間の稼働になります。

正直2,500時間も無駄な事やってるぐらいなら他の事したい!って思いますよね。

 

シンプルに言ってしまえば15人月分のコストをデバッグの時間として使わず、さらに追加開発ができるなら、

・【メリット1】サービスとしてユーザーに対して改善できる

・【メリット2】開発として開発体制に対して改善できる

・【メリット3】会社として新たなビジネスへの挑戦ができる

当然ですが2,500時間のデバッグ時間を他に使えるようにすれば、「本当に必要な実装時間」に変えられることができればメリットは数えきれないほどあります。

デバッグ時間を削減するためにする事

デバッグ時間を削減するには単純な話、如何に手作業を減らすか?という点につきますが、解決方法としては単純に3つです。

・解決策1.そもそもデバッグがいらないようにする

・解決策2.自動でエラー検知されて常に自動でデバッグされるようにする

・解決策3.手作業でデバッグしていたものを自動でデバッグされるようにする

当たり前の話ですが、究極目指すべきは解決策1のみです。

解決策1だけだと当然サービスが回らないので解決策2が必要となります。

解決策2までやっても新規開発等の際のデバッグは常に発生するため解決策3となります。

◆次回は…

今回は主にデバッグで話す話の全体像、課題、課題解決時のメリット、解決策、を一旦お話させてもらいました

自分(松島)がディレクター、プランナー、フロントエンドエンジニア、サーバーエンジニア、アプリエンジニアと様々な経験を持つ異色の経歴のため、一般的な解決策と異なり職種をまたがった解決策を次回以降お話できればと思います。

 

具体的に解決策が分からないと意味ねーじゃんと思うこともありそうですが、各課題の解決への筋道が思いのほか長く面倒だったため、細かく書くために複数回に分けさせてください。

 

次回はAutifyの導入関係についてお話していく予定です。