仮説検証型アジャイル開発を行うアイミツ開発チームの技術的負債への向き合い方

アイミツ開発チームでエンジニアリングをしている deliku といいます。

以前開発チームの取り組みについて下記ブログで紹介しましたが、今回はより具体的な開発フローについて紹介したいと思います。またタイトルにあるとうに技術的負債を蓄積しないように考えていることもお伝えできればと思います。

爆速開発を実現するアイミツ開発チーム

仮説検証型アジャイル開発とは

仮説検証型アジャイル開発とは、ユーザーのニーズを理解し、プロダクトがユーザーにとって価値のあるものかどうかを検証しながら、プロダクトを開発していく手法です。具体的には、まずユーザーのニーズを仮説として立て、その仮説を検証するために、プロトタイプを作成したり、ユーザーテストを行ったりするなどの方法で、ユーザーの反応を測定します。ユーザーの反応を測定した結果に基づいて、仮説を修正したり、プロダクトの機能を追加したり、削除したりしながら、プロダクトを開発していきます。

アイミツ開発チームのスクラムの様子

スプリントは１週間で区切っています。

1週間のサイクルは実際に開発していてどうなのか？

1週間は短いです。なので開発に充てる時間を他のことで消費しすぎないように意識しています。例えば企画が大きい（開発する機能の量が多いなど）ものだと、仕様を調整したり認識合わせをするのにどうしても時間が取られてしまいます。このとき開発する時間がなくなってしまいスプリントの達成が難しくなることが何度かありました。とはいえ仕様をある程度つめないと、ストーリーポイントがブレることで、次以降のスプリントの達成の見通しが悪くなる可能性が上がります。最近は時間をかけすぎす、ストーリーポイントにブレがあることをある程度許容するかたち（不確実性が高いとして、ポイントを増やす）で運用することとしています。

企画会議

サイト開発の企画メンバーが、企画を持ち寄り "Why / What" の説明を行い、プロダクトオーナーから企画承認やフィードバックをもらう会議となります。最初のうちはエンジニアは任意参加でしたが、"Why / What" の説明を聞き、疑問があればその場で確認するほうが効率が良いことが分かったので、現在はエンジニアも参加しています。

設計会議

企画会議で承認された企画を、エンジニアと企画オーナー（企画を起票した人）で "How" の認識合わせや 企画の深掘りを行う会議となります。また、メインの担当エンジニアをつけ、細かい要件の調整は別途個別にやることとしています。企画内容によって話が間延びしたり議論が伸びてMTGの予定時間を超過することがあったためです。

仮説検証を組み込んだ開発フロー

仮説を検証して妥当性の裏付けがされた機能を実装していく形になります。
そのため企画会議では、why / what の説明が重要であることと、どのようにその仮説を検証するかについて説明がされます。

• 検証タスク

  • 仮説を検証することを目的とします。そのため検証するために必要最低限の開発に留めます。ここで大事なことは 作り込みすぎない ということです。例えば本来機能化するならDBへテーブル新規作成したり、十分なテストコードを準備したりするところをケースバイケースでシンプル（configに定義する、Featureテストで正常系を通すなど）とします。

• 本実装タスク

  • 検証タスクは 検証するために必要最低限の開発 でしたが、本実装タスクは、あるべき機能を提供するための開発 となりますので、設計をきちんと行います。

• 戻しタスク

  • 効果測定の結果、仮説が間違っていた / 期待する効果を生まなかった場合、検証で開発した機能は残したままにしておくと技術的負債になるため、明確にタスクとして管理しています。放置しておくと戻しづらくなる（（Pull Request Revertで機械的に戻せなくなる））ので、早めに対応するようにしています。

  • 明示的にプロダクトバックログで管理されていることで、視覚的に戻しタスクが増えてきたことがわかるようになり、誰でもプロダクトオーナーと優先度の調整がしやすい効果があります。

技術的負債の解消に明示的に固定枠を設けるHowもある

ログラス社の事例のように、最初から新規開発と負債解消対応のストーリーポイントを分ける方法もあるのでこちら紹介しておきます。負債解消がなかなか進まないといった場合に、最初から負債解消の時間を確保するというのは有効な手段だと認識しています。

技術的負債への向き合い方

私は「そもそも蓄積しない、させない」ということを意識して開発しています。技術的負債が蓄積されていくと、開発者体験が悪くなり結果としてユーザへの価値提供が遅れてしまいます。

アイミツは過去に技術的負債の蓄積から開発速度が低下し、システムリプレイスを行った過去がありますので、二の舞にならないよう今開発に携わっている自分たちが今以上の品質をキープし続けることが大切であると考えています。

▶ 【PR】ユニラボ に興味がある方へ

今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！

herp.careers 【エンジニア職】カジュアル面談応募フォーム

PRONI株式会社

募集要項をみる