ソフトウェアデリバリーの本当の出発点はコードではない
あなたがこれまでに行ったすべてのデプロイは、どこかから始まっています。しかし、その「どこか」はプルリクエストでもブランチでもコードの一行でもありません。それはもっと前、多くの場合誰も書き留めなかった会話の中にあります。
こんな状況を想像してみてください。ユーザーが「保存ボタンが動かない」と報告する。チームミーティングの最後に誰かが「通知機能を追加すべきだ」と言う。エラーログにデータベースの接続が尽きていると表示される。これらの瞬間こそが、ソフトウェアデリバリーの本当の出発点です。コードが存在する前、パイプラインが動作する前に、誰かが決断しなければなりません。どのアイデアを実装し、どれを延期または完全に破棄するのかを。
非公式なやり方の落とし穴
小規模チームでは、この意思決定プロセスは自然に感じられます。誰かがアイデアを思いつき、チームメイトに話し、コーディングを始める。それは速くて効率的に感じられます。しかし、このスピードには隠れたコストが伴います。
十分に検討されていないアイデアは、時間を無駄にするコードになります。二人が同じ機能を、お互いが作業していることを知らずに作ってしまうかもしれません。良いアイデアが誰も書き留めなかったために失われることもあります。チームはコードをリリースしても、そのコードは実際の問題を解決していません。
私は、誰も求めていない機能をチームが何週間もかけて構築してしまうのを見てきました。単に当初のアイデアが曖昧で、コーディングが始まる前に誰もそれに疑問を投げかけなかったからです。コードは動きました。テストも通りました。しかし、その機能は使われずに放置されました。なぜなら、ユーザーが実際に必要としていたものと合致していなかったからです。
アイデアから追跡可能な作業へ
チームが成長し、プロダクトがより本格的になるにつれて、非公式な会話だけでは不十分になります。コードにする前に、アイデアを捉え、議論し、優先順位を付けるための仕組みが必要です。
ほとんどのチームは何らかの課題追跡システムを使っています。Jira、Trello、GitHub Issues、Linear、あるいは共有ドキュメントでも構いません。各アイデアはチケットになり、何をすべきか、なぜそれが重要なのか、時にはどのようにアプローチするかという説明が付与されます。チームはそれについて議論します。これは重要か？緊急か？今あるリソースでできるか？
この議論が重要なのは、チームの時間とエネルギーには限りがあるからです。すべてのアイデアを実装できるわけではありません。選択しなければならないのです。その決定は、ビジネス上の優先度、技術的な緊急性、あるいは誰が作業可能か、といった基準に基づくかもしれません。
スプリント計画ミーティングで次の作業サイクルに入るチケットを決めるチームもいれば、チャットでの非同期投票や定期的なバックロググルーミングセッションを行うチームもいます。形式よりも、誰かがコードを書く前に意思決定を明示的にする習慣の方が重要です。
コード以前の隠れた作業
ここで見落としがちなのは、この段階ではまだコードが存在しないということです。存在するのは、メモ、議論、そして決定事項です。しかし、ここが本当のデリバリーの旅の始まりなのです。優先順位が付けられたチケットが、次のステップであるコード作成へのインプットとなります。
多くのエンジニアやマネージャーは、誰かがエディタを開いてタイピングを始めたときにデリバリーが始まると考えています。それは正しくありません。最初のキーストロークの前には、コードをそもそも書くべきか、何をすべきか、どのようにアプローチするかを決定する一連の判断がすでに存在しています。
このフェーズをスキップしたチームは、結局使われないコード、的を外した機能、あるいは時間と士気を消耗するやり直し作業に直面することがよくあります。コード自体は技術的に優れているかもしれません。しかし、間違った問題を解決しているのであれば、技術的な優秀さは意味を成しません。
これがパイプラインにとって重要な理由
「これはプロジェクト管理の話であって、CI/CDの話ではないのでは？」と思うかもしれません。しかし、ここに関連性があります。
デリバリーパイプラインは、アイデアを安全かつ迅速に動作するソフトウェアに変えるためのものです。もしアイデア自体が貧弱に定義されているなら、あなたのパイプラインは悪いアイデアをより速く出荷する機械になります。間違ったものを出荷しているのなら、高速なパイプラインは役に立ちません。
これが、成熟したチームがコード以前のフェーズに投資する理由です。彼らはアイデアが明確で、優先順位が設定され、期待される成果が定義されていることを確認します。そして、パイプラインにその役割を任せます。つまり、明確に定義された変更を効率的に出荷することです。
コード作成前の実用的チェックリスト
次の機能や修正のために誰かがコードを書き始める前に、以下の質問を確認してください。
- これはどのような問題を解決するのか？ 技術的な専門用語を使わずに一文で説明できますか？
- 誰がこれによって利益を得るのか？ ユーザー、社内チーム、それとも単にエンジニアリングチームの都合ですか？
- これを構築しなかったらどうなるのか？ 答えが「特に悪いことは起こらない」なら、優先順位を再考してください。
- アイデアをテストするもっと簡単な方法はあるか？ 本格的な構築に着手する前に、手動プロセス、フィーチャーフラグ、プロトタイプで検証できますか？
- この変更について誰が知っておく必要があるか？ サポート、ドキュメント、QA、運用、または影響を受ける可能性のある他のチームは？
このチェックリストには5分もかかりません。何週間もの無駄な努力を節約できる可能性があります。
まとめ
コードはデリバリーの出発点ではありません。アイデアが出発点です。デリバリーの質は、コードをどれだけ速く出荷できるかだけでなく、そもそもどのコードを書くかをどれだけうまく決定できるかにかかっています。
パイプラインを最適化する前に、アイデアから決定に至るプロセスを最適化してください。間違ったものを出荷する高速なパイプラインは、時間を無駄にするより速い方法にすぎません。まずアイデアを正しくし、その後でパイプラインに本来の役割を果たさせましょう。つまり、その正しいアイデアを安全かつ繰り返し出荷することです。