年度末進行で一番静かな時間は、リリース直前の確認タイムかもしれません。
みんなそれぞれのタスクを片付け、テストも通り、チェックリストも埋まり、「よし、いける」という空気が流れます。
でも、その空気の中で、ふとした違和感に気づく瞬間があります。
数字でもエラーでもない、仕様漏れでもない。
なんとなく「これでいいんだっけ」という感覚です。
大抵の場合、それは大きなバグではありません。
でも放置すると、リリース後にじわっと効いてくるタイプの違和感です。
年度末はだいたい、ここで一度詰まります。
今日は、その“あの違和感”の話と、直前5分でできる小さな確認のコツをまとめます。
目次
「なんか変」なのに、言語化できない
リリース直前の違和感は、だいたい曖昧です。
「ボタン位置が微妙に遠い気がする」「文言がちょっと冷たい気がする」「この画面、急に情報量が多くない？」というように、はっきりしたバグではありません。
しかも時間がありません。
年度末進行はスケジュールが詰まっています。
確認は終わっているはずですし、関係者もそれぞれ次の作業に移りかけています。
だから、多くの場合こうなります。
「まあ大丈夫か」で流します。
ここが詰まりポイントです。
違和感は小さいうちにしか拾えません。
リリース後は、仕様扱いになります。
私がやるようになったのは、最後の5分だけ“感覚チェック”を意識的に入れることです。
数値ではなく、体験として触る時間をつくります。
しかも一人でやります。
そのときに見るポイントは、たった三つです。
① 最初の1スクロールで迷わないか。
② 主ボタンが視線の流れに乗っているか。
③ 文言が「命令」になっていないか。
これだけです。
仕様チェックはすでに終わっています。
この時間は、ユーザーのつもりで触るだけです。
不思議なことに、この3点だけでも違和感は浮かび上がります。
そして浮かび上がる違和感のほとんどは、軽微な調整で直せます。
直せない場合は、来期バックログに入れる判断ができます。
違和感を無視するのではなく、扱いを決める。
それだけで詰まり方は変わります。
年度末あるある：「直す勇気」と「止める勇気」
年度末のリリース前は、なぜか改善欲が強まります。
「ここ、やっぱり直したいよね」という声が出やすい時期です。
でも直前の改善は、影響範囲が読みにくい。
軽いUI調整のつもりが、表示条件に触れ、テストが増え、確認が伸びる。
そしてスケジュールが押します。
だから私は、5分レビューで気づいた違和感に対して、必ずどちらかに振り分けます。
“今触っても安全な軽微修正”か、“来期に回す構造的改善”かです。
ここで迷ったら、触りません。
判断を保留にして、来期最初の改善候補に入れます。
年度末は、直す勇気より止める勇気のほうが価値があります。
実際にあった例を一つ挙げます。
最終確認で、あるフォームのCTA文言が「送信する」になっていました。
機能上は問題ありません。
でもサービス特性上、「申し込む」のほうが自然でした。
この違和感は5分レビューで気づきました。
影響範囲を確認し、文言差し替えのみで済むと判断できたので即修正しました。
一方で、フォームのステップ構造そのものが分かりにくいという違和感もありましたが、それは構造変更にあたるため来期に回しました。
この切り分けをするだけで、リリース直前の空気は安定します。
全部直そうとすると崩れます。
全部流すと後で後悔します。
“軽微か構造か”で分けるだけで十分です。
コラム｜あの違和感を無視した年の話
昔、リリース直前に「なんか変だな」と思ったことがあります。
トップページのヒーローエリアの情報量が多すぎる気がしました。
でも仕様通りでしたし、テストも通っていました。
時間もありませんでした。
私は流しました。
リリース後、数値に大きな異常は出ませんでした。
でも問い合わせが増えました。
「何をすればいいか分からない」という声です。
改めて触り直すと、やはり情報の優先順位が曖昧でした。
あのときの違和感は正しかったのです。
大きなバグではなく、体験の密度の問題でした。
それ以来、私は直前5分レビューを必ず入れるようにしました。
しかも、声に出して触ります。
「ここで迷うな」「ここで視線が止まるな」と独り言を言いながら操作します。
言語化できない違和感は、声にすると輪郭が出ます。
輪郭が出れば、軽微か構造かの判断ができます。
年度末は忙しいです。
でも5分は取れます。
5分で救える違和感は意外と多い。
詰まるのは、直前です。
でも直前だからこそ、拾えるものがあります。
リリース直前の違和感は、敵ではありません。
最後に残ったユーザー目線のサインです。
それを無視せず、扱いを決める。
それだけで年度末のリリースは、ぐっと安定します。
対クライアント案件で、私が迷う瞬間
年度末の対クライアント案件で一番迷うのは、承認済みワイヤーに違和感を覚えたときです。
ワイヤーは私たちの提案です。
それにクライアントが判断を出してくれている。
その状態で、「やっぱり少し気になります」と言うのは、正直に言えば怖いです。
「だったら最初から直した状態で持ってきてください」と思われるのではないか、と一瞬よぎります。
以前、キャンペーンLPの最終確認でファーストビューの情報量が少し重たいと感じたことがありました。
仕様通りですし、承認済みです。
大きなミスではありません。
でも触るたびに、一瞬だけ迷う。
CTAまでの心理的距離が少し長い。
ここで私がまず整理するのは、「これは設計ミスなのか、それとも実装後にしか見えない体験差なのか」という点です。
ワイヤー段階では、構造と優先順位を設計しています。
実装後は、視線の流れや情報の密度、実際のトーンまで含めた“体験”になります。
違和感の多くは、後者です。
つまり、設計をひっくり返す話ではなく、実装後に見えた体験の微調整です。
ここを自分の中で明確にしてから、クライアントに伝えます。
私はこう言います。
ワイヤー構造自体は適切だと考えています。
実装後の確認で、ファーストビューの情報密度がやや高く感じられました。
構造変更ではなく、CTAの視認位置を1ブロック上げる軽微な配置調整をご提案します。
承認済み設計を前提にした、最終体験の微調整という位置づけです。
ポイントは、三つあります。
設計は否定しないこと。
「実装後に見えた体験」と言語化すること。
構造変更ではないと明確にすることです。
これを怯えながらではなく、淡々と伝えます。
年度末だからこそ、完成度を一段上げたいという姿勢として出します。
実際、この案件ではCTAの位置だけを調整しました。
ワイヤー構造はそのままです。
フォーム設計自体に感じていた違和感は、来期改善として別提案に回しました。
全部を直すわけではありません。
全部を飲み込むわけでもありません。
承認済みワイヤーを否定するのではなく、「実装後の体験を最終確認している」と位置づける。
この整理ができると、対クライアントの違和感はかなり扱いやすくなります。
年度末進行では特に、このケアが効きます。
それでも「納期優先で」と言われたらどうするか
ここまで整理して提案しても、クライアントからこう言われることはあります。
「おっしゃることは分かります。でも今回は見た目より納期を優先してください」
これは責められているわけではありません。
合理的な判断です。
年度末進行ならなおさらです。
このとき、私は必ず一瞬迷います。
軽微修正だから滑り込ませられるかもしれない。
でも、クライアントが明確に“納期優先”と言っている。
ここでこっそり修正を入れることも、技術的にはできます。
軽微な配置調整であれば制作側で吸収できることもあります。
でも私は、原則として“勝手に滑り込ませる”ことはしません。
理由は単純で、年度末のリリースで一番大事なのは信頼だからです。
修正が小さくても、「優先順位を無視された」という印象は大きく残ります。
では、あきらめるのか。
ここで完全に飲み込むのかというと、そうでもありません。
私がやるのは、選択肢をもう一度整理して提示することです。
今回の修正は制作工数に大きな影響はありませんが、確認工程が1サイクル増える可能性があります。
納期優先の場合は現状維持で進め、来期改善提案として整理します。
もし影響を最小限に抑えた形で対応する場合は、配置調整のみで当日中に確認可能です。
ここで重要なのは、“判断を戻す”ことではなく、“判断材料を整える”ことです。
クライアントが納期優先と決めるなら、それは尊重します。
ただし、どのリスクを取るのかを明確にしたうえで決めてもらいます。
多くの場合、ここまで整理すると「今回は見送ってください」となります。
それでいいと思っています。
なぜなら、違和感を消すことよりも、優先順位を共有することのほうが長期的には価値があるからです。
私はこう考えています。
年度末進行では、“正しさ”よりも“合意の透明性”のほうが大事です。
滑り込ませる技術よりも、持ち越す判断の整理のほうが後に効きます。
そして持ち越すと決めた違和感は、必ずバックログに残します。
「いつか直す」ではなく、「来期初回改善候補」として明文化します。
修正を滑り込ませるか。
あきらめるか。
私の場合は、原則として滑り込ませません。
その代わり、持ち越す理由を整理し、来期で必ず拾います。
年度末は、完成度を100にする時期ではなく、合意を100にする時期だと思っています。
まとめ
年度末進行は、だいたいリリース直前で詰まります。
大きなバグではなく、小さな違和感で止まります。
だからこそ、最後の5分を感覚チェックに使います。
① 最初の1スクロールで迷わないか。
② 主ボタンが視線の流れに乗っているか。
③ 文言が命令口調になっていないか。
そして違和感を、軽微か構造かで振り分けます。
軽微なら触る。
構造なら来期に回す。
それだけです。
面白い記事を読んだだけのつもりが、実は明日から使える小さな習慣になっていればうれしいです。
