データ可視化のデザイン

可視化には 2 種類あるよ

これはなるほどなと思った。

• 探索型(Exploratory): 中立的
  • (経営)指標の定点観測
• 説明型(Explanatory): 意見が明確
  • レポーティングとか
  • メッセージ性

ベンフォードの法則

世の中に存在する数字の最大桁の数字 1〜9 の分布はだいたい決まっているとの事。
聞いた事がある気もするけど全く意識してなかったのでメモ。

1. 30.1%
2. 17.6%
3. 12.5%

• 増加する数に関して成立
• 自然界一般で成立
• 桁が繰り上がった直後から次の桁までに最上位がどの数字に長く滞在するかを考えれば直感的にはなるほどと

データを確認する観点

このまとめ方はなるほどなと思わされる。

• 上層部
  • 対象: 組織・部署の管理職
  • 内容
    • 目標に到達しているかどうかが分かる情報
    • 順調かどうか
• 中間管理職
  • 対象: マネジメント層
  • 内容
    • どのように目標を達成するかを考えるための情報
    • チームが上手くいっているのかどうか
• 現場
  • 対象: 部員
  • 内容: オペレーションのための詳細な情報(顧客情報・取引情報 etc.)

フィードバックの必要性

• できるだけ複数の立場からもらう
• 受けた上で取り入れるかどうかは自分の頭で判断する

失敗から学ぶ RDB の正しい歩き方

過去履歴が無い

過去履歴を持たず最新の情報を更新し続けるケースで起こる弊害。
これは気付かなかった。

• 消費税
  • キャンセルの発生時に整合性が取れなくなる
  • ex.
    1. 購入: ¥100 x 5個 x 1.08 = ¥540
    2. 消費税率変更: 1.08 -> 1.10
    3. 1 個だけキャンセル: ¥100 x 1個 x 1.10 = ¥110 (本当は¥108)

過剰な CHECK 制約

更新日時(updated_at)に実行日時以降の制約を付与するケースで起こる弊害。

• テストデータの作成でエラーの可能性あり
• バックアップのリストアでエラー
  • これは確かに

バックアップ運用

見直しのタイミング

• 関連する DB が増えた
• OS や DB のバージョンアップ
• 一度も復旧の実行をした事が無い

リストア実行

「障害時に初めてオペレーションを実行」するのはほぼ無理。

失敗するパターン

• 作業が属人化している
  • 特定の人しか作業が出来ない
  • 手順書が無い
• 設計・実装者がいない
• 定期的な訓練をしていない
  • 定期的な素振りが必要ですw
  • チームで活動している場合はトラックナンバー 1 を避ける意味でもかなり有効だと思う

バックアップのタイミングで自動的にリストアをステージング環境に実行するというのはなるほどと思った。
チームで訓練する際もステージング環境を作成するというのはかなりありだなと。