第37章

同じ失敗をデザインし続ける

チームが同じ間違いを繰り返す理由

今この瞬間も、どこかのデザインチームが、ナビゲーションはサイドバーに置くべきか、上部に並べるべきかを議論している。同じ会社は、3年前にもまったく同じ議論をした。誰かが調査し、判断し、公開した。思うような結果が出ず、決定は覆された。記録も書かれた。その後、詳細を覚えていた人たちが去り始めた。サイドバーを好む会社から、新しいデザイナーが入ってきた。今、何もなかったかのように議論が戻っている。また2週間を費やし、同じところに着地する。

チームが忘れるから、こうなる。賢いチームでも起きる。

知識は、人と一緒に去る

どの組織も、二種類の知識で動いている。一つは文書にある。仕様書、振り返り、デザインファイル、議事録。もう一つは、人の頭のなかにある。決定の背景、記録に入らなかった部分、何かを試してやめた理由の記憶。心理学者 Daniel Wegner は、これをトランザクティブ・メモリーと呼んだ。一人のなかではなく、集団に分散して蓄えられ、それぞれが、誰が何を知っていそうかをわかっている知識だ。

人が残る限り、この仕組みは機能する。Wegnerの研究では、メンバーが安定した集団は、人が入れ替わった集団より、思い出す課題の成績がよかった。専門知識の所在を示す地図が、内部にできていたからだ。ある人は、ユーザー調査の経緯を知っている。別の人は、前回のナビゲーションのリデザインで何が起きたかを覚えている。別の誰かは、CEOがモーダルのパターンを却下した会議にいた。その人たちがいる限り、チームには、使える記憶がある。

やがて、一人が去る。もう一人も去る。知識は、きれいに文書へ移らない。その多くが、役に立つ形では書かれていなかったからだ。サイドバーが失敗した理由は、当時のユーザー層、実装の技術的な制約、その後変わったプロダクト戦略が混ざったものだったかもしれない。どれも、変更履歴には現れない。Barbara LevittとJames March は、組織学習を次のように説明した。

過去から導き出したことを、行動を導く日常的な手順に組み込むこと。
— Levitt & March（英語からの翻訳）

経験から得たことを行動の型に組み込む人が去ると、その過程は途切れる。文書に残るのは、しばしば理由のない結果だけだ。

チームは忘れ、最初からやり直す

James WalshとGerardo Ungson は、人が去ると組織内の知識に何が起きるかを研究した。組織が知識を蓄えようとするさまざまな場所のなかで、最も細かなニュアンスまで持っているのは、個々のメンバーだ。そして、最も速くいなくなるのも、その人たちだ。

組織は、これをほとんど忘却とは呼ばない。この件の組織の記憶を失った、とは誰も言わない。新しい目で見直そう、と言う。またワークショップを開く。またプロトタイプをつくる。反復改善と呼ぶ。外から見ると、進歩に見える。実際には、同じ教訓をもう一度学ぶために、会社が費用を払っていることが多い。同じ使いにくいモーダルが、見た目だけきれいになって戻ってくる。

MySpaceは、同じ教訓を繰り返した

2005年、News Corporationが MySpace を5億8000万ドルで買収したとき、引き継いだプラットフォームには、実際の問題があった。遅い読み込み、広告だらけのレイアウト、モバイルでの弱さ。隠れた問題ではない。巨大なプラットフォームにある、目に見えるプロダクトの問題だった。

その後、何年も事業の改善を試みながら、根本の問題からは抜け出せなかった。サイトは雑然としたままだった。大量の広告は、体験の一部として残った。モバイルは、間に合ううちに強みにならなかった。それで、すべての問題が組織記憶の喪失から来たと証明されるわけではない。だが、なぜそうなったか、どんなトレードオフによって残されたかについて、明確な共通の記憶を持たず、古いプロダクトの負債を抱え続けると何が起きるかは示している。MySpaceは2011年、3500万ドルで売却された。

やり直す前に、これを聞く

対策は、一つの習慣から始まる。決定を問い直す前に、立ち止まり、これはすでに試したことがあるかを聞く。ほとんどのチームに必要なのは、文書を増やすことではない。またゼロから始める前に、会社がすでに何を学んだかを確かめる姿勢だ。

具体的に聞こう。サイドバーのレイアウトのユーザビリティテストは、誰がしたのか。前回、初期案内を変えたとき、何が起きたのか。2022年にツールチップを公開して、何がわかったのか。どこかに答えはある。誰かの頭のなかかもしれない。18か月、誰も開いていないNotionのページに埋もれているかもしれない。3年前の夏に働いていて、今もSlackにいる業務委託の人が、おぼろげに覚えているかもしれない。

デザインシステムは、答えの一部になる。Nielsen Norman Group は、デザインシステムを、チームや時期をまたいで同じ選択を議論し直す必要を減らす、共通言語として説明している。だが、デザインシステムに記録しやすいのは、調査にもとづく判断より、つくり方の判断だ。前回なぜそのパターンが失敗したか、ユーザーが何に苦労したか、どのトレードオフによってチームが引き返したかは、教えてくれない。

そのためには、誰かが覚えている必要がある。そして誰かが覚えているためには、チームは記憶を、新しい発想を邪魔するものではなく、資産として扱わなければならない。歴史を重荷のように扱い、その直後に繰り返すチームを、私は見てきた。最も長くいる人たちは、どんな仕組みよりも、本当のプロダクトの記憶を多く持っていることがある。

チームがする最も高くつくことは、同じ教訓を二度学ぶことだ。