「残り1秒」が終わらないのはなぜ？ ── 進捗バーと残り時間の仕組み

進捗率は作業量の割合、残り時間は予測、完了は処理結果です。この違いを使って、終わらない表示の確認方法と、誤解を招かない進捗表示の設計を説明します。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全9件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

ファイルのコピー、アプリのインストール、動画の書き出しで、「残り1秒」のまま30秒以上たつ、「99％」から進まない、「残り10秒」が「残り79秒」に増えることがあります。なぜこのような表示になり、何を確かめれば処理の状況を判断できるのでしょうか。

この記事で扱うのは、進捗表示の読み方と確認の順序です。同じ表示でも、見積もりの外れ、別工程への移行、画面更新の遅れ、実処理の停止を区別する必要があります。特定の障害の根本原因を断定する記事ではありません。

対象環境

作業量や工程を画面へ通知する処理を対象にします。WindowsのコピーAPIと進捗コントロール、WPFの画面更新、.NETのキャンセルを説明の手がかりにし、Webの進捗要素も参照します。これらがすべて一つのアプリで使われるという意味ではありません。

特定バージョンのエクスプローラーの内部アルゴリズムは解析していません。2004年のコピー時間の解説も、現在のWindowsの計算式を示す仕様書とは区別します。数値例と比較デモは仮想処理であり、PC・ディスク・回線の実測値ではありません。

実際の処理を調べる手順は、利用しているアプリの画面・ログ・利用手順を確認できる範囲で行います。管理者権限を付与したり、処理中のファイルを変更したりする手順ではありません。比較デモの操作にはJavaScriptが有効なブラウザーが必要ですが、本文の説明や計算例はデモを動かさなくても読めます。

回答・解決方法

「残り1秒」は、今後の処理も見積もった速度で進む場合の予測であり、1秒後の成功を保証しません。 進捗率の分母、予測速度、現在の工程、表示と実処理の更新を順に確かめます。「99％」やアニメーションだけで、正常・故障・取り外し可能のいずれとも決めないでください。

定義

進捗率は「どれだけ終えたか」、残り時間の見積もりは「これからどれだけかかりそうか」、完了は「必要な処理が成功したか」です。進捗バーは、その情報を画面へ示すための表示であって、時計ではありません。

flowchart TB
    accTitle: 進捗率と残り時間と完了の違い
    accDescr: 処理済み量から求める割合、速度を仮定して求める残り時間、成功結果による完了を別の情報として示します。
    A["処理済み量と総量"] --> B["進捗率"]
    C["残り量と予測速度"] --> D["残り時間の見積もり"]
    E["必要な処理の成功"] --> F["処理全体の完了"]

図1: 割合・予測・結果は、同じ情報を言い換えたものではありません。

本記事では、測れる作業量の割合を進捗率、表示する棒を進捗バー、秒数の予測を残り時間の見積もりと呼び分けます。見積もりが出せなくても、測れた進捗まで分からなくなるわけではありません。

進捗率が数える単位

100件の書類のうち99件が短いメモで、最後の1件が分厚い契約書なら、「99件終わった」は正しくても「時間も99％終わった」とは限りません。進捗率も、分母を何にするかで意味が変わります。

役割

進捗表示の役割は、何を処理していて、どれだけ進み、何がまだ分からないかを利用者へ伝えることです。利用者は待機やキャンセルを検討する材料にし、開発者は観測した事実と予測を分けて届けます。

WindowsのCopyFileExで使う進捗コールバックは、ファイル全体のバイト数や転送済みバイト数を渡します。これは作業量の情報であり、未来の秒数を直接渡すものではありません。アプリはその情報から割合を表示でき、残り時間を示すなら別に予測が必要です。[S1]

件数とデータ量を併記する価値は、どちらかが間違っているからではなく、互いに見えていない面を補えることにあります。同様に、秒数を出せないときでも、工程名と処理済み量を伝える意味は残ります。

構成

本記事で提案する進捗画面は、現在の工程、測れた作業量と総量、根拠がある場合の残り時間、成功・失敗・キャンセルの結果を別々の情報として持ちます。これは設計例であり、特定製品の内部構成を示すものではありません。

flowchart TB
    accTitle: 観測値から進捗画面を組み立てる
    accDescr: 現在の工程、測定した量、予測できるときの残り時間、最終結果を分けて表示します。
    A["処理から得た情報"] --> B["現在の工程"]
    A --> C["測れた量と総量"]
    A --> D["条件がそろった見積もり"]
    A --> E["成功・失敗・キャンセル"]

図2: 観測できたことと予測したことを、画面でも区別します。

たとえば「検証中：400 / 1,000件、残り時間は計算中」と表示すれば、秒数を出せなくても現在の工程と報告された進展が分かります。段階ごとの割合を一つに合成する場合の「転送80％・検証20％」という配分は、設計上の重みであって、今回の時間配分の保証ではありません。

更新時刻を出すなら、「最後に進捗が増えた時刻」と「画面が通信できた時刻」も分けます。後者だけが更新されたことを、作業が進んだ証拠として見せない設計にします。

アクセシビリティでも、分かっている範囲を反映します。Webのprogress要素はvalue属性を省略すると不確定な進捗を表せます。[S10] 独自のARIA進捗表示でも、値が不明ならaria-valuenowを省略し、何の進捗かを示す名前を付けます。見た目の割合だけでなく、読み上げに渡す情報にも同じ区別が必要です。[S11]

仕組み

割合の計算、時間の予測、工程の終了、画面への反映は別々に進みます。数字が変わらない理由を調べるときは、どの段階の情報を見ているのかを確かめます。

総量の確定と不確定進捗

割合を出すには、分母となる総量が要ります。しかし「フォルダー全体を処理する」と指示した瞬間に、その奥にある全ファイルを列挙し終えているとは限りません。「準備中」が長いのは、対象の総量を調べている場合もあります。

仮に100件あると思って80件まで処理し、その後さらに100件見つかったら、同じ80件でも80/100から80/200に変わります。表示は80％から40％に下がりますが、終えた仕事が消えたわけではありません。未確定の総量を確定値のように見せると、利用者の期待とのずれが生まれます。

flowchart TB
    accTitle: 総量がまだ分からない段階の表示
    accDescr: 対象を調べている間は割合を確定せず、総量が分かったら処理済み量と合わせて進捗率を表示します。
    A["対象を調べる"] --> B{"総量が分かったか"}
    B -->|"まだ"| C["工程名と発見件数を表示"]
    B -->|"分かった"| D["割合を表示する"]

図3: 分母がない状態と、進捗が0％の状態は違います。

Windowsの進捗コントロールにも、値の分かる表示と、不明な間に動作中であることを示す表示があります。[S4] 本記事では、列挙中は「対象を確認中：1,200件を発見」と示し、総量が決まってから割合を出す設計を提案します。残り秒数が出ないこと自体は、何もしていない証拠ではありません。

転送完了と処理全体の完了

説明用に、アプリの処理を「転送 → 検証 → 結果を確定」の三段階に分けます。転送した内容の検証が必要な設計なら、転送が終わっても処理全体は終わりません。すべてのコピーやインストールがこの順序であるという意味ではありません。

flowchart TB
    accTitle: 転送完了と処理全体の完了
    accDescr: この仮想アプリでは転送の後に検証と結果の確定があり、転送済みバイト数だけでは全体の成功を判断しません。
    A["転送"] --> B["検証"] --> C["結果を確定"] --> D["全体の成功"]
    A -.-> E["転送100％はここまで"]

図4: 何の完了かを明示すれば、100％の後に別工程があっても説明できます。

全体の棒を99％に固定して「残り1秒」と出し続けるより、「転送完了・検証中」と工程を切り替えて示すほうが誤解を減らせます。MicrosoftのデスクトップUIガイドも、実処理が終わる前に全体の完了を示さないよう求めています。[S5]

書き込みと媒体への反映

Windowsでは通常、ファイルの書き込みにキャッシュが使われます。アプリから書き込んだことと、記憶媒体への反映は、設定やAPIの条件によって境界が異なります。[S6] FlushFileBuffersは、指定したファイルのバッファ済み情報をデバイスへ送るためのAPIです。[S7]

flowchart TB
    accTitle: バッファを使う書き込みの概念図
    accDescr: バッファを使う場合、アプリから受け付けた書き込みと記憶媒体側への反映を同じ出来事として扱わないようにします。
    A["アプリから書き込み"] --> B["バッファに保持"] --> C["記憶媒体側へ反映"]

図5: この図はバッファを使う場合の概念図で、個々の製品の完了条件を表すものではありません。

「99％で止まる原因は必ずキャッシュの書き出し」とは言えません。 検証・書き出し・別の待機のどれかは、アプリの設計や記録で確認する必要があります。進捗の数字から、USBを抜いてよいか、電源を切ってよいかまで推測しないでください。

画面更新と実処理の進展

WindowsのWPFアプリでは、UIスレッドのDispatcherが画面の仕事を処理します。そのスレッドを長時間占有すると、画面更新や入力への応答が遅れます。実処理と、その結果を画面に出す処理は分けて考える必要があります。[S8]

flowchart TB
    accTitle: 実処理と進捗表示の経路
    accDescr: 実処理から進捗通知が出ても、UI側で更新を処理できなければ画面には反映されません。
    A["実際の処理"] --> B["進捗を通知"] --> C["UI側で更新"] --> D["画面に反映"]
    E["UIスレッドの詰まり"] -.-> C

図6: 表示の停止は、実処理の停止と同じとは限りません。

逆に、アニメーションを実処理と独立して動かす設計なら、処理が待っていても丸い表示は回れます。「動いているから正常」「動かないから故障」という二択では足りません。件数・データ量・工程・ログの変化と組み合わせて確認します。

速度を平均しても予測誤差は残る

もっとも単純な残り時間の見積もりは、残りの作業量を予測速度で割った値です。

残り時間 ≒ 残りの作業量 ÷ これからの処理速度の見積もり

難しいのは割り算ではなく、これからの速度をまだ観測できないことです。そこで過去の速度を使って予測します。MicrosoftのRaymond Chenも2004年の解説で、この未来を予測する難しさを説明しています。これは現在のWindowsの内部実装仕様ではありません。[S2]

一瞬の速度変化を全部反映すると、数字が忙しく上下します。一方、開始時からの平均だけを使うと、最初に速かった影響が残り、その後の持続的な減速になかなか追いつきません。

たとえば過去の速度80 MiB/sと最新の速度10 MiB/sを半分ずつ混ぜれば、予測速度は45 MiB/sです。最新の10だけを使う場合より表示は滑らかになりますが、本当に10の状態が続くなら、しばらく楽観的になります。滑らかさと変化への追従は同じ目標ではありません。

flowchart TB
    accTitle: 速度をならすときのトレードオフ
    accDescr: 最新の速度を重く見ると変化に敏感になり、過去の速度を重く見ると表示は滑らかでも変化への追従が遅くなります。
    A["速度の観測値"] --> B["最新を重く見る"]
    A --> C["過去を重く見る"]
    B --> D["変化に敏感だが揺れる"]
    C --> E["滑らかだが追従が遅い"]

図7: 数字が落ち着いていることと、予測が当たることは同義ではありません。

これは予測方法を考えるための例で、特定製品の実装ではありません。本記事では、開始直後や工程の切り替え直後は無理に秒数を出さず、観測がそろってから「約1分」のように見積もりとして示す設計を提案します。根拠のない「あと1秒」を維持するより、残り時間を再計算中だと伝えるほうが誤解を減らせます。

具体例

次の二つは説明用の仮想コピーです。数値の変化を追い、予測速度の問題と、数える単位の問題を区別します。MiBは1,048,576バイトです。

速度が80 MiB/sから10 MiB/sへ下がる例

総量1,000 MiBを、まず80 MiB/sで2.5秒転送し、その後の1秒だけ10 MiB/sに低下したとします。残り時間の計算には、直前の観測区間の速度をそのまま使います。

1秒間で仕事は進んでいます。それでも、残りの仕事をこなす速度の予測が8分の1になったため、見積もりは長くなります。残り時間が増えたことは、仕事が後戻りしたことを意味しません。

flowchart TB
    accTitle: 作業が進んでも残り時間が増える理由
    accDescr: 残り量が減る効果よりも予測速度の低下が大きいと、計算される残り時間は増えます。
    A["1秒間で10 MiB進む"] --> B["残り量は減る"]
    C["予測速度が大きく低下"] --> D["残り時間は増え得る"]
    B --> D

図8: 残り時間が増えたことと、処理が後戻りしたことは別です。

「残り1秒」も同じです。直前の速度なら1秒で済む量でも、次の処理が遅ければ1秒では終わりません。観測の間隔や秒数の丸め方も表示に影響します。ただし、いつまでも同じ数字なら正常だと決めつけず、工程・画面更新・実処理の切り分けが必要です。

99個の小さいファイルと1個の大きいファイル

100個のファイルがあり、最初の99個は各1 MiB、最後の1個は901 MiBだとします。合計は1,000 MiBです。最初の99個が終わった時点では、件数なら99 ÷ 100 = 99％、データ量なら99 ÷ 1,000 = 9.9％です。残るファイルは1個でも、データの90.1％が残っています。

flowchart TB
    accTitle: 最後の1ファイルが大きい場合
    accDescr: 99個の小さいファイルの後に大きいファイルが残ると、件数の進捗とデータ量の進捗が大きくずれます。
    A["99個の小さいファイル"] --> B["件数ではほぼ完了"]
    C["最後に大きいファイル"] --> D["データ量は多く残る"]
    B --> E["同じ処理でも表示が違う"]
    D --> E

図9: 件数ベースの99％は、処理時間の残り1％を約束しません。

どちらの割合も正しく、数えているものが違うだけです。ただし、バイト数だけ見れば時間が分かるわけでもありません。SMBで小さいファイルを大量に送る場合は、ファイルの作成や要求の往復を何度も繰り返す負担があります。大きな1ファイルと同じ総バイト数でも、同じ時間にはなりません。[S3]

このため、「残り500 MiB」という測定が正しくても、その500 MiBの内訳が変われば所要時間は変わり得ます。件数とバイト数を併記して、それぞれが示す作業量を確認します。

デモで使う残り時間の計算

比較デモは次の関数で、残り量と観測速度から秒数を求めます。学習用の単純な予測であり、実用アプリの再試行・並列処理・工程別の予測まで実装したものではありません。

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

remainingとrateは、MiBとMiB/sなど単位をそろえて渡します。戻り値の単位は秒です。0は見積もり対象の作業量が残っていないという意味であり、アプリ全体の成功を意味しません。残り量が正で、速度が0または不明ならnullにして、「残り0秒」と取り違えないようにします。

手順

実際の処理を確認する手順と、仕組みをデモで確かめる手順を分けます。デモの観測値は実際の障害診断の証拠には使いません。

止まったように見える処理を確認する

対象アプリの名前、処理内容、開始時刻が分かる状態で行います。まずは画面やログを読むだけにし、権限変更・設定変更・実ファイルの書き換えは行いません。

Warning: 「残り1秒」や「99％」だけを理由に、強制終了、電源断、USBの取り外しを行わないでください。キャンセルを検討する場合も、先にアプリの手順と、途中の成果物がどう扱われるかを確認します。

1. 画面の表示と観測時刻を記録します。

   工程名、処理済み件数・データ量、総量、残り時間、開始時刻を、表示されている範囲で控えます。表示のない値を推測で埋めません。

   あとで比較できる最初の記録ができます。

2. 別ウィンドウに確認画面や操作待ちがないか確認します。

   確認画面がある場合は内容を読み、アプリの手順に従います。保存先の上書きなどの影響が分からないまま承認しません。

   利用者の入力待ちが見つかった場合は、その待機理由を記録できます。見つからないことだけでは正常と判断しません。

3. 同じ項目を後の時点でも記録し、件数・量・工程・ログの変化を比較します。

   アプリに想定処理時間や更新間隔の案内があれば参照します。ログには時刻、対象、エラーが記録されているかを確認します。対象プロセスのCPU・ディスク・通信は補助証拠にとどめます。

   数値が増えた、別工程へ移った、操作待ちがある、変化を確認できない、のどこまで分かったかを説明できます。CPU使用率の大小だけで停止や正常進行を断定しません。

4. アプリの手順に従って継続・キャンセル・問い合わせを判断します。

   必要な情報が得られなければ、アプリ名と版、処理内容、開始時刻、比較した記録、エラー、試した操作をまとめて管理者や提供元へ渡します。共有前にファイル名やログ中の機密情報を確認してください。

   .NETのキャンセルは、要求だけで即座に処理を止めるのではなく、処理側が応じる協調的な方式です。「キャンセルしています」と「キャンセル済み」は区別します。これはすべてのアプリが.NETを使うという意味ではありません。[S9]

   アプリが示す最終結果を確認するか、未確定の点を残したまま引き継げます。表示だけで決められる一律の強制終了時間はありません。

この手順の到達点は、原因を必ず特定することではなく、観測した変化と未確認事項を分けることです。成功・失敗・キャンセルの結果はアプリの通知や記録で確認します。

比較デモで表示の違いを確かめる

JavaScriptが有効なブラウザーで進捗バーの比較デモを開きます。利用者のファイルの読み書きやアップロードは行わず、ボタンで仮想処理の観測時点を進めます。実時間を待つ必要はありません。

同じ観測値を、件数の棒、転送量の棒、処理全体の状態へ渡して比較します。三つの別処理を同時実行するデモではありません。

flowchart TB
    accTitle: 比較デモの読み方
    accDescr: 同一の仮想処理の観測値を、件数、転送量、全体の状態という三つの表示に渡します。
    A["一つの仮想処理"] --> B["同じ観測時点"]
    B --> C["件数の割合"]
    B --> D["転送量の割合"]
    B --> E["処理全体の状態"]

図10: デモは三つの別処理ではなく、一つの処理の見せ方を比較しています。

1. 「比較するケース」で「99個の小さいファイルと1個の大きいファイル」を選び、「最初に戻す」で先頭へ戻します。

   すでに観測時点1 / 5なら、「最初に戻す」は無効になっています。そのまま次へ進みます。

   件数と転送量が0の、転送中の状態になります。

2. 「次の観測へ」を1回ずつ押し、観測時点2 / 5と3 / 5を比較します。

   件数はどちらも99 / 100で99％です。転送量は99 MiBから549.5 MiBへ増え、9.9％から54.95％になります。件数の棒が同じでも、転送は進んでいます。

3. 観測時点4 / 5へ進めて全体の状態を読み、さらに5 / 5へ進めます。

   4 / 5では転送量が100％でも「転送完了・検証中（まだ成功ではありません）」です。5 / 5で初めて「成功：必要な処理が完了しました」になります。

4. ケースを「残り10秒が79秒に増える速度変化」に切り替え、観測時点2 / 5と3 / 5を比較します。

   転送済み量が200 MiBから210 MiBへ増える一方、直前の観測区間の速度は80 MiB/sから10 MiB/sへ下がり、見積もりが10秒から79秒へ増えます。

件数・転送量・工程の違いと、仕事が進んでも予測時間が増えることを、同じ観測値から説明できます。確認後は「記事へ戻る」で本文へ戻れます。

確認

確認では、何が観測できたかと、何がまだ断定できないかを組にして記録します。実処理の進展と画面の応答を混同せず、割合が100％になったことを全体の成功の代わりにしません。

flowchart TB
    accTitle: 終わらない進捗表示を読む順番
    accDescr: 何の割合か、速度の予測が変わったか、別工程か、表示や実処理が止まったかを順に確認します。
    A["何の割合か"] --> B["予測速度は変わったか"] --> C["別工程が残っているか"] --> D["表示と実処理のどちらか"]

図11: 数字への不満を、確かめられる問いに分解します。

変化がない場合は「停止と確定」ではなく「進展を確認できない」と記録し、手順のログ比較や問い合わせへ戻ります。キャンセル要求を送っただけなら「キャンセル済み」とは記録しません。

デモでは、観測時点4 / 5の検証中と5 / 5の成功を区別でき、速度変化のケースで800 ÷ 80 = 10と790 ÷ 10 = 79を説明できることが確認点です。計算例が一致しても、実際のアプリの残り時間を正確に予測できたことにはなりません。

開発者は、総量不明、速度0、工程切り替え、UI更新の遅延、キャンセル要求中を別の確認条件として扱います。不明な値を0にせず、工程と結果を分けることで、秒数を出せない状態も説明できます。

制約

この説明は、特定アプリの「99％で止まる」原因や安全な強制終了時刻を特定しません。作業量・予測・結果の区別は確認の出発点であり、成功を保証する診断ではありません。アプリの設計、ログ、提供元の案内で確認する必要があります。

「残り1秒」が長いのは、コンピューターが1秒を数えられないからとは限りません。まだ起きていない処理時間の予測に、数える単位、対象の探索、最後の工程、画面更新の遅れが重なります。利用者は工程と変化を見て、開発者は測れた量と予測と結果を混ぜないことが重要です。

よくある疑問

数字やアニメーションだけから判断できる範囲を、次のように整理できます。

残り1秒なのに終わらないのは故障ですか？

表示だけでは決められません。見積もりの外れ、別工程、画面更新の遅れ、実際の停止を分けて確認します。「よくあるから大丈夫」と放置するのも、「1秒を超えたから故障」とするのも早計です。

99％なら残り時間も全体の1％ですか？

違います。割合の単位が件数でもバイトでも、その単位あたりの時間が一定とは限りません。全体の経過時間に1％を掛けて、残り時間を求めることはできません。

丸いアニメーションが動いていれば正常ですか？

動作中の表示と、実処理が進展した証拠は別です。処理済み量・工程・ログなどを組み合わせて見ます。アニメーションだけでは、正常終了まで進めることは保証されません。

残り時間が分からないなら、進捗バーも出せませんか？

総量と処理済み量が分かれば割合は出せます。予測の信頼性が低いときは秒数だけを省きます。総量自体が不明なら、不確定の表示と工程名・処理済み件数を使います。

参考資料

• [S1] Microsoft Learn, LPPROGRESS_ROUTINE callback function. コピーの進捗コールバックが提供するバイト数の意味。
• [S2] Microsoft, The Old New Thing, Why does the copy dialog give such horrible estimates?. 2004年の解説。現在のWindowsの内部実装仕様ではなく、未来の速度を予測する難しさの説明として参照。
• [S3] Microsoft Learn, Slow SMB files transfer speed. 小さいファイルの転送で繰り返し発生するファイル作成・通信の負担。
• [S4] Microsoft Learn, Progress controls. 進捗が確定できる場合と不確定な場合のコントロール。
• [S5] Microsoft Learn, Progress Bars. デスクトップアプリの進捗表示に関する設計ガイド。
• [S6] Microsoft Learn, File Caching. ファイルのキャッシュと書き込みの扱い。
• [S7] Microsoft Learn, FlushFileBuffers function. ファイルのバッファ済み情報をデバイスへ送るAPI。
• [S8] Microsoft Learn, Threading model. WPFのDispatcherとUIスレッドの応答性。
• [S9] Microsoft Learn, Cancellation in Managed Threads. .NETの協調的キャンセル。
• [S10] WHATWG, The progress element. HTMLの進捗要素と不確定状態。
• [S11] W3C, WAI-ARIA 1.2: progressbar. 読み上げに渡す進捗の名前と値の規則。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

残り1秒のまま長時間動かないのは故障ですか？

表示だけでは判断できません。速度予測の外れ、最後の工程、更新されない画面、本当の停止を分けて確認します。処理件数やログの変化、確認待ちの画面などを調べ、残り1秒という数字だけで強制終了しないでください。

99％なら、残り時間も全体の1％ですか？

いいえ。99％が件数・データ量・工程のどれを表すかで意味が変わり、それぞれの処理にかかる時間も同じではありません。進捗率は作業量の割合であり、残り時間そのものではありません。

丸いアニメーションが動いていれば処理は正常ですか？

正常に進んでいる証明にはなりません。画面のアニメーションと実際の処理が別に動く構成では、処理が待ち状態でもアニメーションは動けます。処理の進展を示す件数・工程・ログなどと区別します。

正確な残り時間を出せないなら進捗バーも出せませんか？

出せます。総量と処理済み量が分かれば割合を表示でき、速度が不安定なら残り時間だけを表示しない設計にできます。総量自体が不明なときは、割合を捏造せず、工程名や処理済み件数を表示します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。