この章では、情報がバラける・探せない・途中で分からなくなる・誰かとぶつかる、という四つの困りごとを、データベースという発想から見てきました。どの困りごとも、担当者の能力や注意深さの問題ではなく、情報の置き方という設計の問題として捉え直せることが、この章を通じて見えてきたはずです。原因を人に帰属させるのをやめると、対策は自然と設計の話に変わっていきます。最後に、四つのつながりを整理し、明日からの動き方につなげます。
四つの概念のつながり
一ページ目で見たように、この章の四つの単元は、「情報は一箇所に」という一つの原則の異なる断面でした。正規化は、事実の置き場所を一つに決めるという、いちばん土台になる考え方です。同じ住所や名前を何度も書き写すのではなく、マスタという一箇所を作り、他の場所からはそこを参照する。これができていないと、そもそも「一箇所」がどこなのかが定まらず、残りの三つの概念を積み上げる土台がなくなってしまいます。取引先マスタや顧客台帳のように、「これが正解」と呼べる場所を一つ用意することが、情報整理のすべての出発点になります。この土台がぐらついていると、どれだけ索引を整えても、どれだけ更新の手順を工夫しても、探した先にある情報自体が信用できないという状態からは抜け出せません。
インデックスは、その一箇所にたどり着くための道筋を整える考え方でした。情報を一箇所にまとめても、探すたびに全部を見返す必要があるなら、一元化の恩恵は半分しか受け取れません。よく使う軸であらかじめ道筋を用意しておくことで、一箇所にまとまった情報を、実際に使える形にします。索引の軸は、情報を作る側の都合ではなく、後から探す側の記憶の仕方に合わせて選ぶ、という視点も見てきました。どれだけ立派なマスタを作っても、そこにたどり着く道筋が用意されていなければ、結局は一件ずつ手探りで探すという、元の状態に逆戻りしてしまいます。
トランザクションは、その一箇所を更新する作業そのものを、安全に完結させるための考え方でした。複数の手続きが絡む更新を、中途半端な状態のまま放置しないこと。やり切るか、無かったことにするかのどちらかしか許さないことで、一箇所にまとまった情報が、常に辻褄の合う状態を保てるようにします。出張精算や在庫の引き当てのように、複数の項目が絡む更新ほど、この考え方が効いてきます。どこまで進んだら後戻りできないのか、という境界をあらかじめ決めておくことで、途中で条件が変わったときにも、迷わず対応できるようになります。マスタと索引が「情報の置き方」を整える話だったのに対し、トランザクションは「情報の直し方」を整える話だという違いにも、改めて注目しておいてください。
ロックと編集権限は、複数人が同じ一箇所に関わるときの、交通整理の考え方でした。誰が今触っているのかを分かるようにし、誰がそもそも触ってよいのかを役割で決めておくことで、一箇所にまとまった情報が、誰かの誤操作で壊れないようにします。ロックは「今この瞬間の衝突」を防ぎ、編集権限は「役割としての衝突」を防ぐという、二つの異なる軸を組み合わせて使うことも見てきました。見ることと直すことを分けて考える、という整理も、複数人が関わる情報を扱う上での基本的な足場になります。
四つを並べてみると、「置き場所を決める」→「そこへの道筋を作る」→「安全に更新する」→「複数人での関わり方を整える」という順序で、情報を一箇所に保つための土台が積み上がっていくことが分かります。どれか一つだけを整えても、残りが欠けていれば、別の形で同じような混乱が再発してしまいます。
一つの場面を通して、この積み上がり方を見てみましょう。顧客からの問い合わせ対応を例にとります。まず正規化の発想で、顧客の基本情報を顧客台帳という一箇所にまとめます。次にインデックスの発想で、過去のやり取りを顧客名や案件番号で探せるようにします。ここまでは、この章の前半で見た「情報の置き方」の話でした。問い合わせへの対応記録を追記するときは、トランザクションの発想で、対応内容の記録と状況区分の更新を一つのまとまりとして扱い、片方だけ記録されて区分が更新されない、という中途半端な状態を避けます。複数の担当者が同じ顧客を担当する場合は、ロックと編集権限の発想で、誰が今対応中かを共有し、対応記録を書き換えられる人を担当チームに限定します。一つの業務の中に、四つの考え方が自然に組み合わさって使われていることが分かるはずです。
四つのうちどれか一つが欠けていると、この一連の流れのどこかで綻びが出ます。台帳がなければ探す軸そのものが定まりませんし、索引がなければ台帳があっても探すのに時間がかかります。記録の更新が中途半端であれば、状況区分と実際の対応内容がずれていきますし、編集の管理がなければ、複数担当者の間で記録の上書きが起こります。四つはそれぞれ独立した技術というより、一つの業務を最後まで滞りなく回すための、ひとそろいの部品だと捉えるとよいでしょう。
同じ構造は、契約手続きや在庫管理、人事異動といった、この章で取り上げた他の場面にもそのまま当てはまります。場面ごとに登場する情報の種類は違っても、「置き場所を一つに決める」「そこへの道筋を作る」「更新を安全に終わらせる」「複数人の関わり方を整える」という四段構えの骨格自体は変わりません。自分の職場で新しい業務の型を作るときにも、この四段構えをチェックリストのように当てはめてみることができます。どの段階が抜けているのかに気づくだけでも、将来起きたはずの混乱を、事前に防げる可能性が高まります。
明日からできること
この章で見た内容は、専用のデータベースソフトを導入しなくても、共有フォルダや表計算シートの運用の中に、少しずつ取り入れることができます。まずは、今いちばん困っている情報の重複を一つ見つけ、どちらを正とするかを決めることから始めてみてください。正が決まれば、次はその正への道筋、つまり探しやすい軸を整えることを考えます。更新の作業が複数の手続きにまたがっているなら、どこまでを一つのまとまりとして扱うかを言葉にしてみてください。そして、複数人が関わる情報については、誰が編集中かが分かる合図と、誰がそもそも編集してよいかの線引きを、一度は明文化しておくとよいでしょう。
四つすべてを一度に整えようとする必要はありません。一つずつ手をつけるだけでも、次に同じ混乱が起きる頻度は着実に減っていきます。情報の扱い方を変えることは、大きな予算や特別な権限を必要としない、今日からでも始められる改善です。明日の会議で「この数字はどこが正解ですか」と誰かに聞かれたときこそ、この章を思い出す最初の機会になるはずです。
どこから手をつければよいか迷ったときは、「直近で実際に困った出来事」を思い出すことから始めるとよいでしょう。どの数字が正しいか分からず会議が止まった経験があれば正規化から、探し物に時間を取られた経験があればインデックスから、手続きが中途半端なまま放置された経験があればトランザクションから、誰かとの上書き事故を経験したことがあればロックと編集権限から、それぞれ着手するのが自然な流れです。理屈から入るよりも、実際に困った記憶から逆算した方が、どこに手を入れるべきかの優先順位はつけやすくなります。
また、四つのどれを整えるにしても、最初から完璧な仕組みを作ろうとしない、という姿勢が長続きの鍵になります。まずは小さな運用ルールを一つ決め、実際にしばらく使ってみて、うまくいかない部分があれば直す。この繰り返しの方が、最初から完璧な設計図を用意しようとするよりも、結果として長く機能する仕組みに育っていきます。データベースという言葉の響きに構えすぎず、「情報をどこにどう置くか」という、ごく日常的な判断の積み重ねとして捉え直してみてください。
この先へ
ここまで三部にわたって、自分のOS、仕事のアルゴリズム、チームのアーキテクチャという切り口でCSの単元を仕事に翻訳してきました。情報は一箇所に、という今回の話は、チームのアーキテクチャという部の締めくくりにふさわしい単元です。属人化を防ぐにも、会議や報告の型を決めるにも、土台には「どこに何を置くか」という情報の設計が必要になるからです。誰か一人しか知らない情報をなくすには、まずその情報を一箇所に書き出し、誰もが参照できる場所に置くという、この章で見た発想が欠かせません。会議体や報告の形式を整える話も、突き詰めれば「決定事項という情報を、どこに、どんな形で残すか」という設計の一種です。チームのアーキテクチャという部で扱ってきた三つの章は、すべて情報の置き方という土台の上に成り立っていた、と言い換えることもできます。
次はいよいよ最後の章です。これまでの十二の章それぞれが、どんな症状にどう効くのかを地図として整理し、この先も学び続けるための入口を確認します。一冊を通じて見てきた考え方を、明日からの仕事にどう持ち帰るか。その総仕上げを、次の章で行います。序章で触れた「CSの教科書を仕事の言葉に翻訳する」という方法論が、最後にどこへたどり着くのかを、あわせて確認していきます。
持ち帰り
- 正規化・インデックス・トランザクション・ロックと編集権限は、
「情報は一箇所に」という一つの原則の四つの断面である
- 置き場所を決める→道筋を作る→安全に更新する→関わり方を整える、という順で土台が積み上がる
- 一度にすべてを整える必要はなく、今いちばん困っている一点から着手すればよい
- 完璧な設計より、小さく始めて使いながら直す方が長く機能する
やってみる
この章で扱った四つのうち、自分の職場でいちばん困っている一つを選び、今日中にできる小さな一歩を一つだけ実行してみてください。実行した内容は、翌週にもう一度見返し、うまくいったかどうかを確かめてみましょう。うまくいかなければ、やり方を変えて続ける。それも、この章で見てきた考え方の一部です。