「まずは動くものを作ろう。」
開発現場ではよく耳にする言葉です。
特にアジャイル開発では、完璧を目指すよりも早く価値を届けることが重視されます。そのため、「まず動くものを作る」という考え方自体は間違っていません。
しかし、この言葉を都合よく解釈してしまうと、後から大きな技術的負債となって返ってきます。
今回は、私自身が現場で経験したことも踏まえながら、「まず動くものを作る」という考え方との向き合い方について考えてみます。
「まず動く」を「雑に作る」と勘違いしていた
以前関わっていたプロジェクトでは、納期が非常にタイトでした。
「まずリリースを優先しよう」
そんな方針のもと、最低限動く実装を短期間で作り上げました。
そのときに後回しにしたものは少なくありません。
- 命名の見直し
- 重複コードの整理
- テストコードの追加
- エラーハンドリングの改善
- コメントやドキュメントの整備
当時は「後で直せばいい」と考えていました。
しかし、その「後」はほとんど来ませんでした。
半年後、開発速度が明らかに落ちた
数か月後、新機能を追加しようとしたときに違和感を覚えました。
ちょっとした変更でも影響範囲が分かりません。
似たような処理があちこちに存在します。
修正するたびに別の不具合が見つかります。
レビューでも、
「ここも同じ修正が必要です。」
という指摘が何度も続きました。
リリース直後は素早く開発できていたはずなのに、半年後には変更に時間がかかるシステムになっていたのです。
問題は「まず動く」ではなかった
振り返ると、問題は「まず動くものを作る」という考え方ではありませんでした。
問題だったのは、「後で直す前提なのに、直す時間を計画していなかったこと」です。
技術的負債は、意図的に背負うこと自体が悪いわけではありません。
短納期や緊急対応では、一時的に最適な判断になることもあります。
ただし、その負債を返済する計画がなければ、負債は積み上がる一方です。
アジャイルでも品質は軽視していない
「アジャイルだから、とりあえず動けばいい。」
そう思われることがありますが、実際は違います。
アジャイルマニフェストでは、「継続的に優れた技術と優れた設計に注意を払うことで俊敏さが増す」とされています。
つまり、継続的に価値を届けるためには、保守しやすい設計や品質を維持することが重要だという考え方です。
スクラムでも、完成の定義（Definition of Done）をチームで決め、一定の品質を満たしたものだけを「完成」とします。
「動くこと」と「完成していること」は、必ずしも同じではありません。
「後で直す」は予定に入れて初めて成立する
この経験以降、チームでは少し運用を変えました。
例えば、
- リファクタリングをプロダクトバックログに登録する
- 技術的負債も見積もり対象にする
- レトロスペクティブで負債を定期的に確認する
- スプリントごとに改善作業の時間を確保する
こうした取り組みを始めてからは、「後で直す」が口約束で終わることが減りました。
結果として、新機能の追加もしやすくなり、レビュー時間も短縮されました。
「まず動く」はゴールではなくスタート
今では、「まず動くものを作る」という言葉の意味を少し違って捉えています。
「まず動く」とは、価値を早く届けるためのスタートラインです。
そこから改善を続けられる状態であることが重要です。
もし改善できない状態になってしまえば、それはアジャイルではなく、単に負債を積み重ねているだけになってしまいます。
まとめ
「まず動くものを作る」という考え方は、アジャイル開発において非常に重要です。
しかし、それは「品質を犠牲にしてよい」という意味ではありません。
- 後で直す前提なら、直す予定も立てる
- 技術的負債を見える化する
- 改善をバックログに載せる
- 品質も継続的に育てる
こうした取り組みがあって初めて、「まず動く」がチームの武器になります。
私自身、「後で直せばいい」と考えていた時期がありました。
しかし実際には、「後で」は予定に入れなければ永遠に来ません。
もし最近、「開発速度が以前より落ちた」と感じているなら、一度振り返ってみてください。
その原因は、新しい機能の多さではなく、「まず動く」の解釈にあるのかもしれません。
所属会社（エンジニア積極採用中）
ITエンジニアに、IT業界に貢献する企業
株式会社ONE WEDGE
株式会社ONE WEDGEは、Webシステム開発・SES・AI/DX支援を行うIT企業です。生成AIを活用した業務効率化や次世代システム開発にも注力しており、企業の課題解決だけでなく、エンジニア一人ひとりの成長にも本気で向き合っています。また、技術は「一人で学ぶもの」ではなく「仲間と成長するもの」と考え、社内外でのコミュニティづくりにも力を入れています。