リリースに消極的だと、スケジュールに余裕が生まれない
はじめに
業務システム開発の現場で、メンバーから「スケジュールに余裕がない」という声が出ることがあります。
私は内心、こう思っています。それはリリースに消極的だからではないか。リリースすれば余裕が生まれるのではないか、と。
これは精神論ではありません。ソフトウェア開発の構造的な話です。
アジャイル宣言の原則からの丸パクリ
前述の話しは私の「野生の勘」であって培ってきたモノです。
そこで、2001年に発表された「アジャイルソフトウェア開発宣言」の背後にある12の原則を調べてみました。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
「早く継続的に」「できるだけ短い時間間隔で」。20年以上前から、リリースを早くすることの重要性は明確に示されていたんだなと改めて認識しました。
これはアジャイル特有の話ではありません
「それはアジャイルの話でしょう？うちはウォーターフォールだから」という声が聞こえてきそうですが、そうではないと思っています。
要件がある程度固まっている現代の一般的な業務システム開発でも、同じ構造が成り立ちます。
リリースしない期間が長くなるほど、未確定事項が蓄積します。蓄積した不確定性は、作業量と心理的負荷を指数関数的に増加させていきます。
「忙しい」「余裕がない」という感覚の正体は、実はこの蓄積された不確定性なのではないでしょうか。
逆に言えば、リリースという区切りを先に打てば、その瞬間に余裕は生まれます。これはプロセス論ではなく、ソフトウェアという「変更が本質にある存在」に内在する構造的な真理だと考えています。
昨今の受託開発でも同じ傾向があります
昨今、受託開発においてもアジャイル的なアプローチが広がりつつあります。東京都（は、予算があるのでいつも先進的）のように自治体開発なのにアジャイル型開発を推進する発注者も出てきています。
しかし、受託開発では契約形態の制約もあり、「一括納品」の呪縛から逃れられないケースも多いのが実情です。だからこそ余計に、リリースを先延ばしにすると余裕がなくなるという構造を理解しておく必要があると感じています。
契約上の最終納品が1回だとしても、内部的には小さく区切って動くものを作り、社内統合テストを早期に回すことはできます。その意識があるかないかで、プロジェクトの余裕は大きく変わってきます。
外部を先に、内部は後で
最近の業務システム開発でも、私の上記の肌感と「だろう」という感覚的な話しからちょっとプチ炎上を経験しました。
外部仕様（UI、I/O、特にデータ構造）はすでに固まっています。にもかかわらず、メンバーが内部から綺麗に作り始めてしまい、外側が進まないという状況が見受けられたかなと。
本来、外部が決まっていれば内部は後からいくらでも入れ替えられます。外側さえ動けば統合もテストもレビューも早く回せますし、心理的負荷も減ります。
それなのに内部を先に完璧にしようとし、外側を後回しにしてしまう。結果としてリリースが遠のき、未確定要素が蓄積し、「余裕がない」という感覚が生まれる悪循環に陥っていました。
これはまさに、開発における 「順番の逆転」 が引き起こす代表的な問題です。
なぜ内部から作ってしまうのか
開発者には「内部を今きれいにしないと、後で直す時間はもらえないのでは？」という不安があったんだなと（自戒）。
過去に「後で直す」と言われて直せなかった経験。スケジュールが逼迫すると内部改善は後回しになるという経験則。これが積み重なると、「今ここで完璧にしないと二度とできない」という行動原理になってしまいます。
その気持ちは、よくわかりますが計画に組み込んでいなかった。
リファクタリングタイムは明言せよ——自戒を込めて
「内部はいったん仮でいい」「後でまとめて整える時間を取る」
私にとってこれは当たり前すぎて、わざわざ口にするまでもないことでした。
しかし、それが間違いでした。
明言しなかったせいで、開発者は「今すべてを完成させなければならない」という心理的圧迫にさらされていたのです。「後で直す時間がもらえるかわからない」という不安が、内部を先に完璧にしようとする行動を生んでいました。
リファクタリング時間は暗黙ではなく、「ここで必ず内部を整える時間を取る」と明言し、スケジュールに組み込まなければなりません。
当たり前だと思っていることほど、ちゃんと計画に落とし込まないとダメですね。これは本当に反省しています。
「内部は後で必ず直す——その約束がなければ、誰も外側から作れない。」
戦訓
今回の事象から得た教訓を整理します。
- リリースを遅らせること自体が、余裕を失わせる最大の原因である
- 外部仕様が固まっているなら、開発順序は「外→内」
- リファクタリング時間は暗黙ではなく明示してスケジュールに組み込む
- スタブ・仮実装文化を導入し、「内部は後」を実現可能にする
- これはアジャイルに限らず、業務システム開発でも同じ原理が成り立つ
おわりに
「リリースに消極的である限り、スケジュールに余裕は生まれない。」
そしてもう一つ。
「内部は後で必ず直す——その約束がなければ、誰も外側から作れない。」
これらを原理として明確にし、順番を整え、心理的安全性を担保しなければ、開発は自然と「内部へ逃げ込み、外側が進まず、リリースが遅れ、不確実性が増え、余裕が失われる」という流れに飲み込まれてしまいます。
現場で同じ問題に直面している方の参考になれば幸いです。
PROMPT-Xについて
東京・鹿児島・高知の3拠点で、商用時系列データベースCLOUDSHIPと可視化ソフトRealBoardを軸としたIoTプラットフォーム向けソフトウェアの開発・販売を行うメーカーです。IoT関連の開発支援サービスやソリューション開発も提供しています。鹿児島・高知での開発エンジニア採用を強化中で、PROMPT-Xで働きたいと思える情報発信に努めています。
一緒に働きたいと思ったら！
鹿児島・高知での開発エンジニア採用はこちら！