🧐

TDDを通して開発リードタイムを削減する

2023/02/15に公開

TL;DR

実務経験2年足らずの学生エンジニアが、実務を通して考えたことの雑記です。
若手エンジニアが高速で開発サイクルを回すために、TDDを交えて活用していくと効果的なのでは?といった内容になっております。新人エンジニアの拙作だと思って、優しく見守っていただければと思います。笑

自己紹介

  • 都内のスタートアップにて、エンジニアインターンとして働く学生
  • 2022年の1年間は休学しつつ、フルタイム勤務。今期から復学予定。
  • 大学3年→4年に上がるタイミングで休学。今期から復学予定。所属は文学部。
  • 仕事で触る言語等は、RubyOnRails, TypeScript, React
  • 最近の興味対象はGraphQL

スクラムの副作用

アジャイル・スクラム開発を基軸として動いている組織で働く中で、高速でタスクを消化することはやってのけて当然なことです。さらに、その組織が事業の不確実性が高い、スタートアップの開発チームであれば、ことさら重要な要素となってきます。私が所属しているチームでは、スプリントを1週間と設定し、チケット消化に励んでいるが、スプリントという期限とベロシティという数値が出る以上、焦りが生まれます。では、この焦りがもたらす結果は何でしょうか。私はこれに関しては、ポジティブな面とネガティブな面で、それぞれ高速開発技術負債を挙げます。

高速開発

スプリントという期限が明確に設置されることで、ダラダラと1チケットに時間を取られることなく、開発サイクルを回すことができます。週次などでストーリーポイントなどがきちんと消化されていると、やる気も上がりますし。(ベロシティの目的はあくまで見積もりであり、生産性の指標にすべきではないです。が、一定、チームへの貢献度を可視化する手段として、ベロシティはモチベーション向上に一役買ってくれると考えます。)

技術負債

ただ、開発の目的がストーリーポイントの消化となってしまっては本末転倒です。特に、何が負債となりうるのかを判断できないうちにスピードばかり気にしていては、とんでもないコードを産みまくることになってしまいます(私も半年前の自分のコードを見て、うっとなることが多々あります)。特にスタートアップは機能の出し入れが激しいので、蜜結合な設計のまま実装してしまうと、デプロイのたびにバグが発生する、なんてことも起き得ます。

ではどうすれば

「高速で開発・リファクタまでを行いつつ、負債対策は熟練エンジニアによるPR Reviewを行う」という意見もあると思います。が、経験上、リファクタリングがリファクタリングになっていないことは若手エンジニアの実装において必ずまとわりつくものであると感じています。かつ、実務初期は特に、実装及びリファクタの方針を上長などと擦り合した後にコーディングすることが良い気がしています。よって、動くものができた時点でレビュワーにPRを共有し、リファクタリング方針をfixするといった形が良いのではないでしょうか。

TDD

そして、この①動くものを作る→②リファクタリングをするという過程にぴったりな開発手法が、テスト駆動開発いわゆるTDDというわけです。下画像でいうGreenの矢印が終わったタイミングでPRを出すといった具合ですね。

cf) 画像のTDDの4象限に関してはこちら

終わりに

拙作でしたが、ご参考までに。これからもたくさん発信していきたいと思います。

Discussion