「3ヶ月でシステムを作れ」と言われたとき、あなたはどう感じますか。私がSEとして青果市場管理システムの開発を任されたのは2013年12月、納期は翌年2月末でした。体制20名、業務範囲はセリ・仕分け・出荷・卸売の全工程。普通なら半年はかかる規模です。短納期開発の現場には、教科書には載っていないリアルな判断と妥協の連続がありました。
短納期開発の現場で起きていたこと
青果市場という業界は、IT化が遅れている典型的な業界でした。朝3時から始まるセリ、鮮度が命の商品特性、手書き伝票と電話が主流の業務フロー。このすべてを3ヶ月でシステム化するというミッションは、最初から無理ゲーに見えました。
[EXPERIENCE: ここにTech-Tの実体験を300〜500字程度で入れる予定]
短納期プロジェクトでは、全員が最初から全速力で走り続けます。でもこれが最大の罠なんです。走る方向が間違っていたら、全速力で崖に突っ込むだけ。私たちのプロジェクトも例外ではありませんでした。
要求が日々変わる現場
市場の業務担当者は、システム化の経験がありません。ヒアリングで「これで全部です」と言われた翌週、「そういえば月末処理が」と新しい要件が出てくる。これが3ヶ月間ずっと続きました。
通常のプロジェクトなら、要件定義フェーズで時間をかけて洗い出すところです。でも3ヶ月しかない。要件定義に1ヶ月かけたら、開発期間は2ヶ月を切ります。かといって要件が曖昧なまま開発を始めれば、後で大規模な手戻りが発生します。
業界特有の専門用語との戦い
「建値で仕切る」「相対取引と競り取引の按分」「仲卸と買参人の区別」。青果市場には独特の用語と商習慣があります。私たちIT側がこれを理解できなければ、正しいシステムは作れません。
でも業務担当者は、これらを「当たり前のこと」として説明を省略します。「セリは分かりますよね?」と言われても、私が知っているのはテレビで見たマグロの競りくらい。青果市場のセリがどういう仕組みで、どんなデータを記録する必要があるのか、まったく分かりませんでした。
20名体制なのに進まない開発
人を増やせば早く終わる。これは短納期開発でよくある誤解です。実際には、体制が大きくなるほどコミュニケーションコストが跳ね上がります。
20名のメンバーが同じ認識で開発を進めるには、密なコミュニケーションが必要です。でも短納期だから会議の時間も惜しい。結果、各自が「たぶんこうだろう」という推測で開発を進め、結合テストで不整合が大量発覚する、という事態になりました。
短納期開発が失敗する構造的な理由
30年IT業界にいて、短納期プロジェクトを何度も経験しました。そこから見えてきたのは、短納期開発には構造的な罠があるということです。
時間がないから余計に時間がかかる逆説
短納期だからこそ、最初に時間をかけるべきところがあります。それは「何を作らないか」の合意形成です。でも現場は焦っているから、この議論を飛ばして開発に突入します。
結果、すべての要望を盛り込んだ肥大化した設計になる。開発途中で「これ、本当に必要?」という議論が始まり、手戻りが発生する。最終的に、最初に優先順位を決めていた場合より時間がかかってしまうんです。
私たちの青果市場プロジェクトも、最初の2週間でこの罠にハマりました。「市場業務のすべてをシステム化する」という前提で設計を始めた結果、画面数が100を超える巨大システムの設計書ができあがりました。これを3ヶ月で作るのは物理的に無理です。
業界知識のギャップが生む手戻り
業界特化型システムの開発では、業界知識が決定的に重要です。でも短納期だと、この学習時間を確保できません。
「とりあえず作り始めて、動かしながら修正する」というアプローチは、業界知識がある前提なら有効です。でも知識ゼロの状態でこれをやると、根本的な設計ミスを後から発見することになります。
青果市場の「建値」という概念を、私は最初「定価」だと理解していました。でも実際には、日々変動する基準価格のことで、これを基に個別の取引価格が決まります。この理解が間違っていたため、価格計算ロジックを丸ごと作り直すことになりました。開発2ヶ月目のことです。
品質を犠牲にする圧力
納期が絶対の制約になると、品質との天秤にかけられます。「テストは最低限でいい」「ドキュメントは後回し」「リファクタリングは贅沢」という判断が当たり前になっていきます。
短期的には納期を守れるかもしれません。でも品質を犠牲にしたシステムは、本番稼働後に問題を起こします。そしてその対応で、本来なら次のプロジェクトに使えたはずのリソースが奪われる。これが繰り返されると、組織全体が「火消しばかりで新しいことができない」状態になります。
現代の短納期開発を支えるツールとアプローチ
2013年の青果市場プロジェクトから10年以上が経ち、短納期開発を支える環境は大きく変わりました。私が当時「これがあれば」と思ったツールやサービスが、今は実用レベルで存在しています。
ローコード開発プラットフォームの実力
OutSystemsやMendix、Microsoft Power Appsといったローコード開発プラットフォームは、短納期開発の強い味方です。私が現場で使うなら、まず検討するのがこれらのツールです。
これらのプラットフォームの本質的な価値は「コードを書く量が減る」ことではありません。本当に価値があるのは「設計と実装の距離が近い」ことです。画面設計をそのまま動くプロトタイプにできる。業務フローの図がそのままワークフローエンジンで動く。この即時性が、短納期開発では決定的に重要なんです。
青果市場のプロジェクトで私たちが苦労したのは、設計書を書いて、それを開発者が実装して、できたものを業務担当者が確認するまでに2週間かかることでした。ローコードなら、設計と同時に動くものを見せられます。業務担当者の「あ、これじゃない」という気づきを、2週間後ではなく2時間後に得られるんです。
ただし、ローコードは万能ではありません。複雑な業務ロジックや大量データ処理には向かない場合があります。私の経験から言えば、画面数が50以下、利用者が100名以下、データ量が数万件程度なら、ローコードは有力な選択肢です。それ以上の規模なら、従来型の開発とのハイブリッドを検討すべきです。
業界特化型SaaSという選択肢
青果市場のような業界特化型システムなら、その業界向けのSaaSが存在しないか、まず調べるべきです。たとえば、物流業界ならLOGILESS、製造業ならCADDi Drawer、建設業界ならANDPADのように、業界の商習慣を理解した上で作られたシステムがあります。
「うちの業務は特殊だから、SaaSでは対応できない」という声をよく聞きます。でも30年現場を見てきた私の実感として、本当に特殊な部分は全体の2割程度です。残り8割は、同じ業界なら共通しています。
業界特化型SaaSを使えば、その8割の部分はすでに実装されています。あなたがやるべきは、残り2割の本当に特殊な部分だけ。これなら3ヶ月という期間でも十分に対応できます。
もし青果市場向けのSaaSがあったなら、私たちは「セリ」「仕分け」「出荷」という基本機能にかけた2ヶ月を、本当に市場固有の業務に使えたはずです。たとえば、その市場特有の配送ルートの最適化や、得意先ごとの特殊な伝票フォーマットへの対応に集中できたでしょう。
アジャイル支援ツールで優先順位を可視化
短納期開発で最も重要なのは優先順位の管理です。これを支援するツールとして、JiraやBacklog、Azure DevOps Boardsがあります。
私がこれらのツールで特に重要だと思うのは、バックログの優先順位を全員が同じ画面で見られることです。青果市場プロジェクトでは、Excelの要件一覧を各自がコピーして持っていたため、「どの機能を優先するか」の認識がメンバー間でずれていました。
Jiraのようなツールなら、プロダクトオーナー(業務側の責任者)がドラッグ&ドロップで優先順位を変更すると、全員の画面が即座に更新されます。開発者は常に「今、最も優先度が高い機能」に取り組めます。この透明性が、短納期開発では致命的に重要なんです。
また、スプリントの概念も短納期開発と相性がいいと感じています。3ヶ月を1週間×12スプリントに分割し、各スプリントで「動くシステム」を作る。毎週、業務担当者に動くものを見せて、フィードバックを得る。このサイクルがあれば、3ヶ月後に「こんなはずじゃなかった」という事態は避けられます。
30年現場にいた私が思うこと
青果市場のプロジェクトは、最終的には納期に間に合いました。でも「成功」と呼べるかは微妙です。当初想定していた機能の6割程度しか実装できませんでした。残りは「フェーズ2で対応」という名目で、実際には半年後に追加開発しました。
あのプロジェクトで学んだ最大の教訓は、「短納期開発は技術力ではなく、諦める力で決まる」ということです。何を作らないか。何を次のフェーズに回すか。この判断を、プロジェクト開始から1週間以内に明確にできるかどうか。
私たちが優先順位を明確にしたのは、開始から2週間後でした。そこまでに費やした2週間分の設計作業の半分は無駄になりました。もし1週間目にこの判断ができていたら、1週間分のリードタイムを稼げたはずです。
中小企業だからこそ取れる戦略
中小企業には、大企業にはない強みがあります。それは意思決定の速さです。「これは作らない」という判断を、現場責任者が即座に下せる。この強みを活かさない手はありません。
大企業のプロジェクトでは、機能の削減に稟議が必要だったりします。承認を得るまでに2週間かかる。その間、開発は止まるか、後で削除される機能を作り続けるかのどちらかです。中小企業なら、朝の会議で決めて、午後には方向転換できます。
ただし、この強みは諸刃の剣です。意思決定が速いということは、間違った決定も速く実行されるということ。だからこそ、小さく作って速く確認するサイクルが重要なんです。
明日からできる小さな一歩
もしあなたが今、短納期のプロジェクトを抱えているなら、明日の朝一番でやってほしいことがあります。要件一覧を開いて、各項目に「Must」「Should」「Nice to have」のタグをつけることです。
Mustは「これがないとシステムとして成立しない機能」。Shouldは「あったほうがいいが、手作業でも回せる機能」。Nice to haveは「将来的には欲しいが、今回は我慢できる機能」。この3分類だけで、優先順位は驚くほどクリアになります。
そして、Must以外は「作らない」と決める勇気を持ってください。ShouldもNice to haveも、いったん脇に置く。Mustだけを3ヶ月で完璧に作る。このほうが、すべてを60%の完成度で作るより、ずっと価値があります。
私が青果市場のプロジェクトで後悔しているのは、この判断が遅れたことです。2週間目に気づくべきだったことに、4週間目で気づきました。あなたには、同じ後悔をしてほしくありません。
短納期開発は、確かに厳しい戦いです。でも正しい優先順位と、適切なツール、そして諦める勇気があれば、乗り越えられます。現場で30年戦ってきた私が保証します。頑張ってください。
コメント