見せ方を変えると、欠陥が見える: UI設計と敵対的レビューをつなぐ発想

「使いやすい画面」と「性能の高いコード」は、別々の設計問題に見える。だが実際には、どちらも同じ失敗から生まれる。見えている一つの解釈を、現実そのものだと思い込むことだ。

地図にピンを表示する画面を考えてみよう。そこにあるのは単なる地点の一覧ではない。ユーザーは距離、分布、近さ、空白地帯を読み取る。カレンダーなら時間の連続性を、タイルなら対象の比較可能性を、一次元リストなら順序と検索可能性を読み取る。同じオブジェクトでも、並べ方を変えた瞬間に、ユーザーが判断できることは変わる。

コードも同じである。実装を一人の開発者、一つの設計、一つのテスト結果だけで眺めると、重要な欠陥は見えない。そこで敵対的レビューが効く。別の視点が、同じコードを別の順序、別の関係、別の失敗条件のもとで見直すからだ。

ここから導ける問いは深い。

良い設計とは、正しい答えを一つ選ぶことなのか。それとも、異なる見方を比較できる状態をつくることなのか。

私たちはしばしば設計を「答えを出す作業」と考える。しかし本当に重要なのは、答えを出す前に、何を並べ、何を見せ、何を疑えるようにするかである。UIのコレクション設計と敵対的レビューは、この共通原理を異なる場所で実践している。

画面は情報を表示するのではなく、判断の形をつくる

オブジェクト指向のUI設計では、まず現実に存在する対象を考え、その対象の集合をどのように提示するかを設計する。店舗、予定、写真、タスク、顧客。ユーザーが扱う対象を「オブジェクト」として捉え、その一覧をどの形式で見せるかが、体験の性格を決定する。

例えば、同じ十件の店舗情報でも、形式によって意味は変わる。

• 地図形式では、立地、距離、分布が主役になる
• カレンダー形式では、時間の重なりや空きが主役になる
• 一次元リスト形式では、順序、検索、絞り込みが主役になる
• タイル形式では、視覚的な比較や個別の魅力が主役になる

これは装飾の問題ではない。ユーザーが行う問いそのものが変わるからだ。「近い店はどこか」と「今週空いている店はどこか」は、同じデータから生まれても異なる問いである。地図とカレンダーは、同じ情報を異なる判断装置に変換している。

したがって、コレクション形式には固有の認知的な偏りがある。リストは順位を自然に感じさせる。地図は距離を重要に感じさせる。タイルは画像や短い特徴を比較させる。カレンダーは時間の制約を中心に据える。UIは情報を中立的に置く容器ではなく、ユーザーの注意を配分する仮説なのである。

この視点を持つと、画面設計でよくある議論の見え方が変わる。「カードとリストのどちらがモダンか」「地図を入れると便利そうか」といった問いは、本質からずれている。問うべきなのは、「ユーザーは何を比較し、何を発見し、どの関係を見落としてはいけないのか」である。

コードレビューの本質は、別のコレクションをつくること

敵対的レビューは、相手を打ち負かすためのレビューではない。実装を異なる観点から再構成し、最初の見方では見えなかった問題を表面化させる方法である。

一人で書いたコードは、通常、一つの物語を持っている。要件を読み、設計を決め、実装し、テストを通す。その過程で、コードは作者の頭の中にある前提に沿って整然と見える。変数名も関数分割も、想定した使われ方の範囲では自然に見える。

しかしレビューする人は、別の物語を持ち込む。例えば、次のような問いを立てる。

• 入力が空だったらどうなるか
• 同じ処理が同時に二度呼ばれたらどうなるか
• 権限のない利用者が直接呼び出したらどうなるか
• 通信が途中で切れたら、状態はどこまで進むか
• 将来、データ件数が百倍になったら、どの部分が破綻するか
• 正常系ではなく、利用者が誤解したときに何が起こるか

これは単なるチェックリストではない。コードを「作者が意図した手順」の集合から、「起こり得る状況」の集合へと変換している。最初の実装が一次元のリストだとすれば、敵対的レビューは地図、カレンダー、タイルを追加するようなものだ。別の配置にすることで、隣接していなかった問題が見えるようになる。

例えば、注文確定処理があるとする。正常な流れは「在庫を確認する、決済する、注文を作成する、メールを送る」である。この順序だけを見れば、実装は妥当に見える。しかし、同時実行という観点で見ると、在庫確認と注文作成の間に別の注文が入り込む可能性がある。再送という観点では、メール送信の失敗によって注文全体を再実行し、二重決済が起きるかもしれない。権限という観点では、注文番号を知っているだけの利用者が詳細を閲覧できるかもしれない。

同じコードでも、見るためのコレクション形式を変えると、欠陥の分布が変わる。

レビューとは、コードを評価することではない。コードが置かれる世界を増やすことである。

この点で、敵対的レビューはUI設計と深くつながる。優れたUIが、対象をユーザーにとって意味のある配置で提示するように、優れたレビューは、実装を失敗条件にとって意味のある配置で提示する。

本当の敵は、見落としではなく「一つの見方への固定」である

UIの形式選択を誤ると、必要な情報が存在していても、ユーザーは判断できない。地図上に置くべき情報をリストに押し込めば、距離や分布が見えなくなる。時間の衝突をカードで表せば、個々の予定は見えても、全体の空きは見えにくい。

コードでも、問題が存在しないのではなく、現在の見方では存在しないように見えているだけのことがある。単体テストでは通るが、複数ユーザーでは壊れる。型は正しいが、業務上の状態遷移は不正である。機能は完成しているが、利用者が誤った前提で操作したときに危険になる。

ここで有効なのが、設計とレビューを「表現の選択」として捉えるフレームワークである。次の四つの層に分けて考える。

1. 対象層

何を扱っているのかを明確にする。UIなら店舗、予定、商品、顧客などである。ソフトウェアなら注文、権限、決済、通知など、業務上のオブジェクトと状態を洗い出す。

2. 関係層

対象同士がどのようにつながるかを見る。UIでは距離、時間、順序、類似性が関係になる。コードでは依存関係、競合、所有権、状態遷移、再試行の関係が問題になる。

3. 失敗層

何が起きると判断を誤るのかを考える。UIなら、重要な差が見えない、優先順位を誤る、状態を理解できないといった失敗である。コードなら、二重実行、権限逸脱、データ不整合、回復不能な中断などが該当する。

4. 行動層

見えた情報をもとに、利用者やシステムは何をするのかを確認する。画面は観賞するためではなく、選択、移動、予約、削除を行うためにある。コードも計算するだけではなく、請求、公開、通知、削除といった現実の作用を起こす。

この四層を使うと、レビューの問いが具体的になる。「この設計はきれいか」ではなく、「どの対象を見落としているか」「どの関係が表現されていないか」「どの失敗が別の形式なら見えるか」「その見落としがどんな行動を引き起こすか」と問える。

敵対的レビューを、創造的な設計手法に変える

敵対的という言葉には、対立や攻撃の印象がある。そのため、レビューを人格批判にしない仕組みが必要になる。重要なのは、作者に敵対するのではなく、前提に敵対することだ。

実践では、レビューを役割ごとに分けるとよい。人間が複数人いなくても、役割を順に演じるだけで効果はある。

まず「利用者の視点」から、実際の操作と誤解を検討する。次に「データの視点」から、欠損、重複、順序の逆転、規模の増大を見る。その後に「攻撃者の視点」から、権限の抜け道や不正な入力を調べる。最後に「運用者の視点」から、障害発生時の検知、復旧、説明可能性を確認する。

この方法の利点は、レビューを「良いか悪いか」という一つの評価に閉じ込めないことだ。地図とリストを同時に眺めることで、距離と順位の両方を理解できるように、複数の視点を並べることで、設計の盲点を構造的に発見できる。

ただし、視点を増やせば必ず良いわけではない。情報を過剰に並べたUIが使いにくいように、レビュー観点を無制限に増やすと、重要なリスクが埋もれる。そこで、目的に応じてコレクション形式を選ぶ必要がある。

新機能の初期設計では、対象と関係を地図のように広げる。競合や依存を把握するためである。リリース前には、失敗条件をリスト化して優先順位をつける。時間制約のある障害対応では、カレンダーのように、どの状態がいつ発生し、どこで連鎖したかを並べる。利用者への影響を検討するときは、タイルのように、異なるユーザー像を並べて比較する。

つまり、レビューの質は、指摘の鋭さだけで決まらない。問題を発見しやすい表現形式を選べるかで決まる。

Key Takeaways

すぐに実践できる原則をまとめる。

1. 画面を選ぶ前に、ユーザーの比較対象を決める 「地図にするかリストにするか」ではなく、「距離、時間、順序、類似性のどれを判断させるのか」を先に言語化する。

2. コードレビューで、少なくとも三つの別視点を強制する 利用者、攻撃者、運用者など、作者と異なる前提を持つ役割を設定する。視点を変えたら、入力、状態、関係、結果をそれぞれ確認する。

3. 正常系を一つのリストとして扱わない 同時実行、再送、欠損、権限逸脱、規模の増大を、別々のコレクションとして並べる。正常な手順に沿っていることと、現実に耐えることは別である。

4. 指摘ではなく、見え方の変更を提案する 「この処理は危険だ」と断定するだけでなく、「同時実行の観点で状態遷移を並べると、ここで二重処理が起きる」と説明する。批判が再現可能な観察になる。

5. 情報を増やす前に、判断を変える情報か確認する 画面でもレビューでも、すべてを見せることは透明性ではない。重要な関係と失敗を、判断できる形で見せることが透明性である。

最後に、設計者の仕事は答えを描くことではない

良いUIは、データをきれいに並べる画面ではない。ユーザーが本当に必要な関係を発見し、適切な行動を選べるようにする環境である。良いコードも、作者の意図を正確に写したものではない。異なる条件のもとで意味を保ち、失敗したときにも現実への影響を制御できる構造である。

両者をつなぐのは、表現が判断をつくるという事実だ。見せ方は、理解の後に来る装飾ではない。理解そのものの一部である。レビューの視点も、実装の後に追加する検査ではない。実装が最初からどの世界を想定しているかを決める設計要素である。

次に画面を設計するとき、あるいはコードをレビューするとき、一つだけ問いを変えてみてほしい。「これは正しいか」ではなく、「これは、どの見方なら正しく見えるのか」と問うのである。

その問いを持てば、設計は一つの答えを磨く作業から、複数の現実に耐える表現を選ぶ作業へ変わる。そして本当に強いプロダクトは、最初から見落としがないプロダクトではない。見落としが見えるように、自分自身の見方を組み替え続けられるプロダクトなのである。