なぜ簡単に見える機能に時間がかかるのか — 開発スケジュールと技術的負債

2026年4月17日金曜日

読了 6分

企画者と開発者の間で、何度も繰り返しぶつかる場面があります。「これ、ボタンを一つ追加するだけなのに、なぜ二週間もかかるの」という質問です。尋ねる側には画面にボタンが一つ増える小さな変化に見え、答える側はその裏にずらりとつながった仕事を思い浮かべます。どちらも嘘をついているわけではなく、同じ仕事をそれぞれ違う角度から見ているだけです。

この記事では、なぜ簡単に見える機能が思ったより時間がかかるのか、そして開発スケジュールを話すときに必ず出てくる技術的負債とは何かを、コードなしで解きほぐしていきます。この全体像がわかると、スケジュールをめぐるもどかしいやり取りがずっと楽になります。

画面の小さな変化の裏では、複数の層が一緒に動きます #

たとえば「注文履歴の画面にキャンセルボタンを一つ追加してください」という依頼を考えてみます。画面だけ見ればボタン一つです。しかし、そのボタンが実際に動くには、目に見えない複数の層が一緒に動かなければなりません。

まず、ボタンを押したユーザーが本当にその注文をキャンセルする権限を持っているかを確認しなければなりません。すでに配送が始まった注文ならキャンセルを止める必要があり、決済を戻す処理も必要です。キャンセルされた注文はデータベースにその事実が残らなければならず、在庫も再び増やさなければなりません。ユーザーにはキャンセルが完了したという案内が見える必要があり、途中でエラーが出たらどう知らせるかも決めなければなりません。

ウェブサイトがフロントエンド、バックエンド、データベースという複数の層からできているという話は、非開発者のための IT 常識 #1で扱いました。ボタンを一つ加える仕事は、これらの層をすべて触ることが多いのです。目に見えるのは一番上のボタン一つですが、その下で手を入れるべき箇所がずらりとついてきます。

目に見えない仕事のほうが、見える仕事よりずっと多いのです #

機能を作る仕事は、コードを新しく書く時間だけで終わりません。むしろコードを書く時間は全体の一部です。

新しい機能をつける前に、既存のコードのどこを触るべきか、その変更が他の機能を壊さないかを確認しなければなりません。作ったあとは、きちんと動くかを試し、同僚がコードを確認するコードレビューを経て、実際のサービスに反映するデプロイまで進んで、ようやくユーザーの手に届きます。ここにスマートフォンとデスクトップのように画面サイズが違う環境、遅いインターネット、予想しないユーザーの行動まで考えると、確認することがさらに増えます。

氷山を思い浮かべると近いです。水の上に出ている部分が画面に見えるボタンなら、水の下に沈んだより大きなかたまりが、そのボタンを支える目に見えない仕事です。依頼する人は水の上だけを見て、作る人は水の下まで見ます。同じ機能なのに、それぞれが感じる重さが違う理由がここにあります。

技術的負債は、速い道が残した借金です #

ここに、開発スピードを左右するもう一つの事情があります。それが技術的負債です。

開発をしていると、時間に追われて、とりあえず速く動くようにだけ作っておき、きれいに整理する仕事は後回しにする場合が出てきます。急ぐときには、この選択は理にかなっています。問題は、こうして後回しにした整理が積み重なることです。整理されていないコードの上に新しい機能をまた載せると、その上に何かを加えるのがだんだん難しくなります。

これを借金にたとえて技術的負債と呼びます。借金をすれば今は速く動けますが、返さずに置いておくと利息がつきます。同じように、後回しにしたコードの整理は、時間がたつほど新しい機能を作るスピードを削っていきます。「前はすぐできたのに、最近はなぜこんなに時間がかかるのか」の裏には、この負債が積み重なっている場合が多いのです。

だから開発チームは、新しい機能を作るだけでなく、しばしば時間をかけて既存のコードを整理します。見た目には何も変わらないこの作業をリファクタリングと呼びます。目に見える結果がないので説得しづらいのですが、負債を返しておいてこそ、これからのスピードが保たれます。

だから、スケジュールの見積もりはいつも難しいのです #

ここまで来ると、なぜ開発スケジュールがよく外れるのか見当がつきます。作るべき仕事のかなりの部分が目に見えず、しかもその仕事には、やってみないとわからない不確かさが混ざっているからです。

ソフトウェアは、まったく同じものを二度作りません。一度もやったことのない仕事を見積もるようなものなので、予想より厄介な問題が途中で飛び出しやすいのです。使っている外部サービスが予想と違う動きをしたり、既存コードの隠れた制約が後から表に出たりします。

だから、熟練した開発者ほどスケジュールを、きっちりした数字ではなく幅で話します。「二日」ではなく「二日から四日、途中で詰まればもっと」と言うのは、逃げているのではなく、不確かさを正直に示しているのです。

なぜ非開発者が知っておくと仕事が楽になるのか #

スケジュールの会話がやわらかくなります。 なぜこんなに時間がかかるのかと尋ねる前に、画面の裏についてくる仕事を一緒に見積もれば、より正確なスケジュールの合意にたどり着けます。
依頼に背景を込められます。 急ぎの度合い、必ず必要な部分、後でもいい部分を分けて伝えれば、開発チームは何を先にやるか決めやすくなります。
整理する時間を認められます。 技術的負債を返すリファクタリングは、すぐ目に見える成果はありませんが、後回しにすると結局みんなのスケジュールが遅くなります。この時間をスケジュールに入れるのが、長い目で見れば得です。

まとめ #

簡単に見える機能に時間がかかるのには、はっきりした理由があります。画面に見える小さな変化の裏で複数の層が一緒に動き、コードを書く時間より目に見えない仕事のほうが多く、その間に積み重なった技術的負債がスピードを引き下げます。スケジュールに混ざった不確かさは、仕事を雑にやっているという合図ではなく、ソフトウェアを作る仕事の本来の性質に近いものです。

この全体像を一緒に見ていれば、スケジュールをめぐる会話は争いではなく協業になります。開発者が実際に一日をどう過ごすのかをもっと知りたければ開発者は実際に何をしているのかを、問題が起きたときの対応が気になればバグ、ホットフィックス、ロールバックを一緒に読んでみることをおすすめします。