⏱️ 1つの時刻判定で気づいた、待ち時間に「進捗」を見せる怖さ

待ち合わせの相手が到着したと連絡してきたのに、駅の時計はまだ数分前を指していたら、どちらを信じるか迷います。

あなたは今こうなっていませんか？

• 待ち時間を見せるため、実際の処理とは関係なく進捗バーを動かしている • 画面を描く処理の中で、その都度「今何時か」を直接読んでいる • 本当に進んだ量と、見た目の動きを同じものとして扱っている • lint の指摘を消すことだけを考え、なぜ止められたか確かめていない

先に結論を言います。

画面の表示は、あらかじめ受け取った値をもとに決め、進捗バーは実際に分かっている進み具合と結びつくときだけ動かすほうが信頼につながります。

今回の修正は小さなものでしたが、ひとりで作っていると、画面の静けさを埋めるために「進んでいるように見せる」誘惑があると気づきました。

この記事では、時刻で画面を切り替えようとして lint に止められたこと、タイマーが記録した時刻で判定する形に直したこと、そして進捗バーを動かさないと決めた理由を書きます。

「今何時か」で分けたいだけでした

画面の切り替えは、小さな条件分岐のつもりでした

今回直していたのは、時刻によって表示を切り替える部分です。

ある時間を境に、画面に出す内容を変えたいと思っていました。

条件は単純です。境目より前ならこちら、境目を過ぎたらあちらを表示する。

それだけなら、短い分岐で済むと考えていました。

私は、画面を描くときに現在時刻を確かめればよいと思っていました。

画面が表示されるタイミングで「今」を読み、条件に当てはめるイメージです。

ところが、その書き方をすると lint に止められました。

lint は、コードに気になる書き方がないかを確認する仕組みです。

指摘されたのは、表示を作っている最中に現在時刻を直接読むことでした。

「時刻を見て表示を選ぶだけなのに、なぜ問題なのか」と、最初は少し戸惑いました。

一行で済むと思っていたところで、書き方そのものを考え直すことになったからです。

小さな修正ほど、前提を疑わずに進めてしまいがちです。

同じ画面を描くはずなのに、結果が変わります

画面を作る処理は、一度呼ばれたら終わりとは限りません。

状態が変わったり、画面を更新したりするたびに、同じ処理が呼び直されます。

そのたびに「今」を直接読むと、読み取る時刻が少しずつ変わる可能性があります。

特に、条件の境目に近いときは気になります。

たとえば、表示を作っている途中で境目の時刻をまたいだらどうなるでしょう。

ひとつの画面を描いているつもりでも、判定に使う時刻が途中で変わるかもしれません。

実際に必ず表示が壊れるという話ではありません。

今回の指摘が教えてくれたのは、画面を作る処理に「その時点で変わる値を取りに行く仕事」まで持たせている点でした。

表示を作る仕事と、時刻を確かめる仕事を分ける。

そう考えると、lint が止めた理由を少しずつ飲み込めました。

「今の時刻で表示を決めたい」という要望そのものが悪いわけではありません。

問題は、どのタイミングで時刻を読み、どの値を画面へ渡すかでした。

指摘を消すだけでは、気持ちが落ち着きませんでした

lint に止められたとき、最初に浮かんだのは「この程度も書けないのか」でした。

作業を早く終えたいときほど、警告を消すことが目的になりやすいです。

書き方を少し変えて警告が出なくなれば、ひとまず先へ進めるかもしれません。

でも今回は、指摘の意味を考えずに済ませると、時刻の扱いが曖昧なまま残る気がしました。

いま表示するための時刻と、画面を描くための材料を、私は同じものとして扱っていました。

その混同が、つまずきの入口だったのだと思います。

コードの話に見えて、実際には「画面が何を根拠に表示を決めるか」の話です。

そこを整理してから、直し方を考えることにしました。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順

時刻を読む仕事を画面の外へ移しました

タイマーが時刻を記録する形にしました

修正後は、タイマーが時刻を確認し、その値を state に書き込む形にしました。

state は、画面が使う値を一時的に持っておく場所です。

画面は現在時刻を自分で探しに行きません。

タイマーが記録した値を受け取り、その値を使って表示を決めます。

流れを言葉にすると、まずタイマーが時刻を確認します。

その結果を state に保存し、画面は保存された値を使って描かれます。

時刻を読む役目と、画面を作る役目が分かれました。

表示を組み立てている途中で、画面がその場の「今」を読み直すこともありません。

利用する人から見れば、画面の見た目は大きく変わりません。

同じ条件で同じ表示を選びやすくするための、裏側の整理です。

短い修正のつもりが、どの値を誰が持つのかを考えることになりました。

でも、そこを決めると「時刻を直接読んでいた」という問題の形が見えてきました。

表示の条件は、届いた値で決めます

タイマーが記録した値を使えば、画面側は受け取った情報に沿って判断できます。

画面を作るたびに、時刻の確認までやり直す必要はありません。

大事なのは、時刻を確認する処理を増やすことではありません。

画面の判断に使う材料を、ひとつの値として渡すことでした。

「この時間になったら切り替える」という条件はそのまま残せます。

変わったのは、条件を判定するための時刻を、どこで用意するかです。

たとえば、買い物の合計を表示するとき、表示のたびに計算の途中値を直接取りに行くのではなく、確定した合計を画面へ渡すと考えられます。

画面は受け取った値を見せる役目です。

私は、時刻を条件分岐に直接書くのが一番素直だと思っていました。

今回は、その「素直さ」が処理の役割を混ぜていたと気づきました。

直ったあとも、表示の動き方を見直しました

lint の指摘に対応したあと、待ち画面の進捗バーも見直しました。

処理が終わるまで待ってもらう場面で、バーを動かす案がありました。

何も変化がない画面より、動きがあるほうが待ちやすく感じるかもしれません。

静かな画面を見ていると、止まっているのではと心配になることもあります。

ただ、バーが動くことと、処理が進んでいることは別です。

その場面では、実際の進み具合と連動しないバーを出すことになります。

画面の中ではバーが少しずつ伸びていきます。

でも、その動きから裏側の処理がどこまで進んだかは分かりません。

それを「進捗」として見せるのはやめることにしました。

動いているように見えるだけの表示は、いったん置かないと決めました。

待ってもらう人に安心してほしい気持ちはあります。

だからこそ、安心の根拠がない動きを付けてよいのか、考え直しました。

バーを動かさないと決めた理由

動きがあると、進捗だと思ってしまいます

進捗バーが少しずつ伸びていくと、見る側は「処理が進んでいる」と受け取りやすいです。

動きには、何かの変化が反映されていると思うからです。

表示の動きが実際の処理とつながっていなければ、バーは状態を伝えていません。

待っている人に渡す情報として、正確とは言いにくいと感じました。

「見た目だけでも退屈しないようにしたい」という考えは分かります。

私も、止まった画面が少し心もとなく見えることは分かっていました。

それでも、何が進んでいるか確かめられないのに、進んでいるように見せる。

そのほうが、あとから不信感につながる気がしました。

これは、大きな不具合を見つけたという話ではありません。

小さな表示の動きを、見る人がどんな意味として受け取るか考えた話です。

待ち時間より、説明のない動きが気になります

待ち時間があると、画面を見る人は「いま何が起きているんだろう」と考えます。

何も表示されなければ、止まっているのか、時間がかかっているのか判断しにくいです。

だから、待ち画面に何かを出したくなるのは自然です。

短い文章や変化のない目印でも、状況を伝える助けになります。

一方で、実際には測れていないものを測れているように見せると、説明が逆になります。

表示が親切そうに見えるほど、そこから読み取られる意味も強くなります。

バーが半分まで進んでいたら、処理も半分ほど済んだと思うかもしれません。

残りがわずかなら、もう少しで終わると期待するかもしれません。

実際の状態と関係がなければ、その期待には応えられません。

待っている側の期待だけを動かすような表示は避けたいと思いました。

動かない表示にも、伝えられることがあります

今回の画面では、バーを動かさない判断をしました。

動きがないことは少し地味でも、そこに進捗の意味を持たせずに済みます。

何も示さないことがいつも正解だとは限りません。

処理が進んでいることを実際に測れるなら、その値を表示する意味はあります。

反対に、進み具合を測れないなら、いま処理中であることだけを伝える方法もあります。

終わったときに表示を切り替えるだけでも、状態が変わったことは分かります。

画面の選択肢は、動くバーだけではありません。

何を伝えたいかを先に決めれば、言葉で伝える、静かに待ってもらうなど、別の形を選べます。

「動いているふり」をやめるのは、少し勇気がいりました

画面を埋めたくなる気持ちはありました

画面が静かなままだと、作る側は「これで大丈夫かな」と心配になります。

何か動きを足せば、丁寧に作った感じが出る気もします。

特に、ひとりで作っていると、画面を自分で何度も見ます。

その画面に変化がないと、手を抜いたように感じることもあります。

私も、待っている人に気まずい思いをさせたくありませんでした。

何かが動けば、少しは安心してもらえるのではと思いました。

けれど、作る側の気まずさを消すための動きと、使う人に必要な情報は別です。

この区別をつけるのは、思ったより難しかったです。

「親切そう」に見えるものほど、意味を確かめます

画面に表示を足す前に、そこから何を読み取ってほしいのか考えました。

進捗バーなら、どの状態を表し、どんな変化と結びついているのかを確かめます。

答えが曖昧なら、バーが動く意味も曖昧です。

見た目の気持ちよさだけで追加すると、実際より確かな情報に見えることがあります。

今回の見直しで、私は「動くかどうか」だけで考えるのをやめました。

「その動きは何を伝えているか」まで見るようにしました。

こう書くと簡単そうですが、実際には「少しならいいのでは」と迷いました。

待ち時間を埋めるための動きは、よく見る画面にも使われているからです。

それでも、今回は動かさないことにしました。

表示を減らす判断も、使う人に何を伝えるかを決める作業だと思ったからです。

ひとりで作る画面には、作った本人の不安が映り込むことがあります。

不安だから足した動きが、使う人の不安を減らすとは限りません。

似た待ち画面を作るときの考え方

まず、動きと実際の処理が結びついているか見ます

待ち画面を作るなら、まずバーの動きが、実際に分かっている処理の進み具合と結びついているか確認できます。

結びついているなら、進捗として見せる意味があります。

結びついていないなら、どんな状態を伝えたいのかを考え直せます。

「処理中です」と伝えるだけで足りる場面もあります。

処理が終わったことを検知できるなら、完了した時点で表示を切り替える方法もあります。

進み具合を細かく見せなくても、待つ人が状態を把握できる場合があります。

今回の判断は、その場の画面に対するものです。どの待ち画面にも同じ答えが当てはまるわけではありません。

時刻で切り替える画面も、値の流れを見直せます

時刻による表示の切り替えで迷ったときは、どこで時刻を確認し、画面がどの値を使っているかを見直せます。

画面が自分で「今」を読み続けていないかを確かめます。

値を用意する処理と、値を使って表示を選ぶ処理を分けると、どこで何が決まるか追いやすくなります。

今回はタイマーが時刻を記録し、画面がその値を使う形にしました。

これは、細かいコードの書き方を丸ごと覚える話ではありません。

画面が使う判断材料は何か、その材料を誰が用意するのかをはっきりさせる話です。

画面を描くたびに変わる値を直接取りに行くと、同じ表示を作るための材料が見えにくくなることがあります。

まず値の出どころをたどるだけでも、整理のきっかけになります。

「その表示は何を意味するか」と問い直します

今回のような見直しで使える問いは、「この表示を見た人は、何が起きていると思うだろう」です。

進捗バーが伸びているなら、何が進んでいると受け取るでしょうか。

時刻で表示を分けているなら、画面はどの時刻を根拠にしているでしょうか。

表示から受け取る意味と、実際の状態が合っているかを考えられます。

問いにすぐ答えられないときは、表示を足す前に一度止まれます。

分からないまま動きを増やすより、伝えられることを絞るほうが安心につながることもあります。

ひとつの動きを足す前に、その動きが何を示すかを考える。

この問いは、待ち画面以外の表示を見直すときにも使えます。

小さな修正でも、信頼の話になりました

lint の指摘が教えてくれたこと

今回のきっかけは、時刻を直接読む書き方が lint に止められたことでした。

タイマーが state に時刻を書き、その値を画面の判断に使う形へ直しました。

同じ修正の流れで、待ち画面の進捗バーも見直しました。

実際の進み具合を示さないバーは、動かさないと決めました。

最初は、どちらもコードの細部を整える作業に見えていました。

けれど最後に残ったのは、画面が何を伝えるかという問いでした。

見た目の小さな動きでも、見る人はそこから状況を想像します。

その想像と実際の状態がずれていたら、画面は安心より疑いを生むかもしれません。

ひとりで作ると、見せ方の責任も自分にあります

画面を作り、表示を決め、待ってもらう時間を考える。

ひとりで進めると、その判断が自然に自分の手元へ集まります。

誰かが横で「それ、本当に進んでいる表示？」と聞いてくれるとは限りません。

自分で画面を見直して、表示の意味を確かめる必要があります。

これは、専門用語を知っていないとできない確認ではありません。

「この表示を見た人は、何が起きていると思うだろう」と考えるだけでも始められます。

進捗バーが伸びているなら、何が進んでいるのか。

時刻で表示を分けているなら、どこで時刻を確かめているのか。

その答えが分からないときは、画面に何かを足す前に一度止まれます。

止まって考える時間も、使う人への説明を整える作業だと思いました。

私は今回、画面の動きを増やすことより、何を根拠に表示するかを整理しました。

見た目より先に、伝えていることを確かめます

今回のように、ほんの短い条件分岐から考え直すことがあります。

大きな失敗というより、見過ごしそうな前提に気づいたという感覚でした。

時刻はいつ読まれるのか。画面はどの値を使うのか。バーの動きは、実際の何を表しているのか。

ひとつずつ確かめると、表示の意味が少し明瞭になります。

見た目だけで安心させるより、分かっていることをそのまま伝えるほうがよい場面があります。

AIを使って個人開発をしていると、画面を形にするところまでは速く進むことがあります。

でも、何を約束する表示にするのかは、自分で考えるところとして残ります。

私はこの修正で、「進んでいるように見える」ことと「進んでいる」ことを分けて考えました。

待ってもらう時間を飾るより、その時間に何が起きているかを誠実に扱いたいです。

もし今、待ち画面のバーを動かすか迷っているなら、その動きが実際に分かっている進捗を表すか確かめてみてください。

答えがまだないなら、無理に進んでいるように見せなくても大丈夫です。

静かな画面でも、伝える内容が正直なら、待つ人に向き合う表示になります。

仕組みの全部はこちらにまとめています。今回はその中の、ごく小さな時刻判定と待ち画面の話でした。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順