エンジニアから営業まで、社員全員がSQLを使うデータドリブン組織はどのようにできたのか。コラボレーションツールに記録された実データから辿るケーススタディ。巻末には、今すぐ学べるSQL練習帳も収録。未経験の方でもブラウザだけで簡単に練習できます。

1. How Livesense Works #1
営業さんまで、社員全員がSQLを使う
"越境型組織" ができるまでの3+1のポイント
Yukihiko Kawarazuka, Engineer of Livesense, inc
kawarazuka@livesense.co.jp

2. ある日、営業さんから来た依頼

5. あるある

6. わりとざっくり仕様。
※反響=お問い合わせのこと

7. でも

9. あるある

10. その8ヶ月後

15. これはほんの一例

16. なぜ？
なぜ、営業さんもSQLを書くのか
なぜ、営業さんにまでデータベースアクセス権を開放しているのか
なぜ、SQLを学習しようと思ったのか
なぜ、学習を完遂できたのか
なぜ、学習にとどまらず実運用に耐えるスキルに昇華されたのか
なぜ、このような協業文化ができ、根付いたのか

17. 私は前職で「怠惰で横柄で直感頼りな営業」にしびれを切らし、*1
開発をやりつつ自分で営業もしていたので
「なぜ？」を越えて「ショック」だった。
*1 切らしたのはしびれだけではなかったが

18. 営業 「データベース？そんなよくわからんもの営業には関係ない」
シス管 「DBにアクセスできる人数は、最小限にすべき。
技術コンタミを防ぐために、部署外の人間はアクセス禁止」
マーケ 「昔いた〇〇さんはSQLでやってたみたいだけど、、
はてどうやるんだっけ」
プロマネ「いいものを開発しよう。
いいものを作れば営業が売ってきてくれる。
どう売るか？知らないけどそれは営業が。」
開発 「えっ外注して作ってもらったの？
それうちの部署でツール化してたのに。」
私が前職でよく聞いた声

19. 本質的な課題とは
無関心
責任範囲の
固執
意図しない
秘密主義

20. 責任範囲への固執（セクショナリズム）
原因:
自分が与えられた責任を全うしようとする、責任感に起因。
責任を全うするのは、当然重要。
しかし部分最適になっていないか？
「セキュリティのため、DBにアクセスできる人数は最小限にすべき」
「技術コンタミを防ぐために、部署外の人間はアクセス禁止」

21. 無関心
「データベース？そんなよくわからんもの営業には関係ない」
「いいものを開発しよう。
いいものを作れば営業が売ってきてくれる。
どう売るか？知らないけどそれは営業が。」
原因:
(1)自分の持つ強み（技術・ノウハウ）のみで仕事を捉え、それを一般化してしまう。
(2)事業やサービス全体を俯瞰した視野が持てておらず、
自分の業務外の部分を吸収しようとしない。
”責任範囲への固執”から生まれていることも多い。

22. 意図しない秘密主義
原因:
(1)本当はちゃんと皆に共有したいが、置き場がないため口伝の世界に
(2)他に必要な人、あると嬉しい人がいることを知らない
その結果、人が目に届かないところに成果物がおかれ、意図せずに秘密主義化する。
“無関心”から引き起こされることも多い。
「昔いた〇〇さんはそうやってたみたいだけど、、はてどうやるんだっけ」
「えっ外注して作ってもらったの？それうちの部署でツール化してたのに。」

23. 無関心
責任範囲の
固執
意図しない
秘密主義
そんなよくわからんもの営業には関係ない
お客様の情報が入ったデータを
だれでも触らせるわけにはいかん
昔いた〇〇さんは
そうやってたみたいだけど

24. 各々が各々を引き起こす因果関係にあり、
組み合わさると、ひどい悪循環に。

25. こんな悪循環にしないために、
なにができるか。

26. #1 「意図しない秘密主義」から「共有カルチャーの醸成」へ
・情報共有するためののインフラを用意する
・情報共有マインドを醸成する
#2 「無関心」から「学習を通じた相互理解」へ
・関心を引く資料を共有し、それを実現するための技術要素の提示
・身近な題材を用いた教材の用意
・学習の見える化による相互作用
#3 「責任範囲への固執(セクショナリズム)」から「越境する組織」へ
・職種を越えるための環境の整備
・越境者には伴走を
・越境したら伝道を

27. 無関心
責任範囲の
固執
意図しない
秘密主義

28. 学習
越境
共有

29. 組織や職種という範疇を越境して協業を行い、
その事例を共有し、
その共有事例がさらなる学習意欲を生むことで、
より組織や職種を超えたコラボレーションが生まれるサイクルが理想的

30. 営業さんもSQLを書くようになるまでの事例

31. #1
「意図しない秘密主義」から
「共有カルチャーの醸成」へ
学習
越境
共有

32. 導入している情報共有インフラ
Redmine(現在はJIRAに移行中)
Confluence
Hipchat
Cybouzu
GoogleApps
基本は社員に対してオープンアクセス
必要に応じて制限するポリシー

33. Redmine
（※現在はAtlassian JIRAに移行中）
すべての業務フローを一つのシステムに集約。
営業さんからのSQL発行依頼から
プロダクトの仕様決定まで、
後から見返し経緯を知ることができる。
→新しく入社しても、創業初期からの経緯を
知ることができる

34. Atlassian Confluence
トップページは人気順。
企画・エンジニアリングから
「本当に難しいショートケーキ」まで、
フラットに並ぶ。

35. Atlassian HipChat (チャット)
事業別ROOM(必須参加)と、
要素別ROOM(任意参加)を用意。

36. 情報共有インフラの導入
≠
情報共有カルチャーの醸成

37. 情報共有カルチャーの醸成 ＞ 情報共有インフラの導入

39. 情報共有カルチャーの醸成 ＞ 情報共有インフラの導入

40. #2
「無関心」から
「学習を通じた相互理解」へ
学習
越境
共有

41. 関心を引くレポートと、その共有

43. 調査レポートにSQLクエリが併記されることで、
関心事と要素技術がつながる
再現方法があることで追試を行える、真似できる

44. 身近な題材を用いた教材: SQL100本ノック

46. 自習の見える化と相互作用

48. #3
「責任範囲への固執(セクショナリズム)」から
「越境する組織」へ
学習
越境
共有

49. 「職種を越えるための環境の整備」
非エンジニアへの分析用DB公開

50. 「セキュリティのため、DBにアクセスできる人数は最小限にすべき」
技術による制約の回避

52. 個人情報マスキングプログラム
本番系DBに格納された個人情報を保護(マスク)し、
社内スタッフが触れるようするにためのプログラム。
DBマスキング処理を簡単に記述できるよう、
よく使われるマスキングパターンを基本プログラム側で用意している。
テーブル名とカラム名を指定すれば即マスキング対応可能。

53. パターン マスキング処理内容
氏名 「山田 太郎」「ヤマダ タロウ」「ﾔﾏﾀﾞﾀﾛｳ」「やまだ たろう」のどれかに変更
住所 「東京都渋谷区南平台町16-28」に変更
ビル名 「グラスシティ渋谷 2F」に変更
メールアドレス
“@”とトップレベルドメイン以外をハッシュ化。ただしデバッグのため自社メ
ールアドレス(*.livesense.co.jp)はハッシュ化しない
口座番号 半角7文字の乱数で埋める
銀行コード 半角4文字の乱数で埋める
銀行支店番号 半角3文字の乱数で埋める
その他 「このカラムはマスキングされています。」に変更
企業名 「株式会社マスキング」「カブシキガイシャマスキング」のどれかに変更
電話番号 半角12文字のユニークな乱数で埋める
基本プログラムで用意しているマスキングパターン

54. その上で

55. まずは再利用から

57. エンジニア主導のトレーニング
「越境者には伴走を」

58. 若手(入社1~2年目相当)2名
教材作成(SQL100本ノック)
&実地でのトレーニング
教えるかわりに、他の人へも教える約束

59. 実地でのトレーニング

63. ：
：
指摘されたところをもう一度ミス

65. ：
：

66. 難しいところはExcelで乗り切る

67. その後、慣れてきた頃に

68. 400万件のフルスキャン

69. 重いクエリでDBサーバ止まる

74. “ー “未来企業 レジリエンスの経営とリーダーシップ” 94ページ
協働を最大限に促すために
1 責務の透明性を高める
2 サイバー空間で信頼を高めながら親睦を深める
3 コミュニケーションを欠かさない
4 思いやりの重要性を理解する

75. その後、各チームでの伝道師的な活動
「越境したら伝道を」

76. 各メディアごとの100本ノックの作成

77. 伝道師的活動

78. アルバイトスタッフにも

79. アルバイトスタッフ向け勉強会資料

81. 全員がSQLを書くようになるまでの事例はここまで。

82. ー “戦略サファリ” 258ページ
組織学習の基本原則
1 失敗から学ぶ
2 絶え間ない再検証
3 直接体験による学習
4 知識の流動性を保つ
5 外界に目を向け、知識を吸収する
“

83. One more thing…

84. 学習
越境
共有

85. 学習
越境
共有
知識創造

86. 学習
Internalization
(内面化)
越境
Socialization
(共同化)
共有
Externalization
(表出化)
知識創造
Combination
(連結化)
多くの “知識創造企業” で
見られる
“SECIモデル”

87. “
組織的な知識創造は
個人レベルから始まり、
メンバー間の相互作用が、課、部、事業部門、
そして組織という共同体の枠を超えて
上昇、拡大していくスパイラル・プロセス
ー “知識創造企業” 108ページ

88. このスパイラルが回り出すことで、
より組織や職種を超えたコラボレーションが生まれる

89. 営業さんもSQLを書くようになった頃に

94. SQLクエリを登録しておき

95. ExcelのWebクエリ機能で、データを取得・更新

96. 各種分析をExcelベースで行えるように

97. そしてその結果は、デイリーチャートとしてチームに共有

98. まとめ

99. 学習・共有の環境を整えた上で、
「越境」を促すことで、
職種を超えたコラボレーションを行うことができる。
SQLはその一例。

100. 自分の仕事の領域を決めすぎず学ぶこと
相手の仕事の領域を敬意をもって侵すこと
うまくいったことを、具体的に共有すること
うまくいったスパイラルの伝道師となること

101. そして、
このサイクルを通じて皆が一緒に、
良い仕事・良いサービスを作っていこうとすること

102. その先にある、「創造型組織」を目指し続けること

103. “ ー “イノベーションのDNA” 53ページ
イノベーティブなアイデアは、さまざまな
人たちの多様な経験が交わる場所で花開く。
歴史を通じて、偉大なアイデアは文化や
経験の交わるところで生まれている。

105. 付録
今日から社内で使えるSQL10本ノック

106. リブセンス社内で使われている実際の「SQL100本ノック」のうち
10本を厳選し、
教育用途として扱いやすいようにスキーマをカスタマイズしたものです。
DB環境がなくとも、ブラウザがあれば実施できるように準備しました。

107. 題材は「アルバイト求人情報サイト」
(※貴社に馴染みのある題材に変更してお使いください)

108. 応募テーブル、店舗テーブル、都道府県テーブルの構成

109. テーブル説明::entries(応募)
カラム名 説明 例
id ID 23
name 応募者氏名 木村太郎
birthday 生年月日 1995-03-02
mail メールアドレス foo@bar.net
date 応募日 2013-02-21
adopt_status
採用確定時に1、
不採用確定時に2、
そうでなければ0
1
adopt_date
採用・不採用確定日
未確定のときは0
2013-02-27
client_id 店舗ID 3
device_type
応募時に利用した
デバイス
SMARTPHONE/PC

110. テーブル説明::client(店舗)
カラム名 説明 例
id ID 3
name 店舗名 井村商店
pref_id 都道府県ID 13

111. テーブル説明::pref(都道府県)
カラム名 説明 例
id ID 13
name 都道府県名 東京都

112. http://sqlfiddle.com/
環境
ベースSQL（DBスキーマ）
http://bit.ly/1D7WARF

113. http://sqlfiddle.com/ にて、ダウンロードしたベースSQLを投入

114. まず、テーブル内の件数を出してみましょう
動作確認
Run SQLを押して、件数が出れば成功です。

115. それでは10本ノック、行ってみましょう

116. 2013年2月の応募数

117. SELECT
COUNT(*)
FROM
entries
WHERE
entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
;

118. 2013年2月の採用数

119. SELECT
COUNT(*)
FROM
entries
WHERE
entries.adopt_status = 1
AND entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
;

120. 2013年2月の不採用数

121. SELECT
COUNT(*)
FROM
entries
WHERE
entries.adopt_status = 2
AND entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
;

122. 2013年2月に応募があった店舗数

123. SELECT
COUNT(DISTINCT client_id)
FROM
entries
WHERE
entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
;

124. 2013年2月の応募数前年比

125. SELECT
SUM(entries.date between '2013-02-01' and '2013-02-28 23:59:59') /
SUM(entries.date between '2012-02-01' and '2012-02-29 23:59:59')
AS ratio
FROM
entries
WHERE
YEAR(entries.date) IN (2012,2013)
AND MONTH(entries.date) = 2
;

126. 2013年2月の東京都の応募数

127. SELECT
prefs.id,
prefs.name,
COUNT(*)
FROM
clients
INNER JOIN prefs ON clients.pref_id = prefs.id
INNER JOIN entries ON clients.id = entries.client_id
WHERE
entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
AND prefs.name = '東京都'
GROUP BY
prefs.id,
prefs.name
ORDER BY
prefs.id,
prefs.name
;

128. 2013年2月の都道府県別応募数ランキング上位３位

129. SELECT
prefs.id,
prefs.name,
COUNT(*)
FROM
clients
INNER JOIN prefs ON clients.pref_id = prefs.id
INNER JOIN entries ON clients.id = entries.client_id
WHERE
entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
GROUP BY
prefs.id,
prefs.name
ORDER BY
COUNT(*) DESC
LIMIT 3
;

130. 2013年2月のデバイス別応募数

131. SELECT
device_type,
COUNT(*)
FROM
entries
WHERE
entries.date BETWEEN '2013-02-01 00:00:00' AND '2013-02-28 23:59:59'
GROUP BY device_type
;

132. 以上で問題終了です。

133. 解いた事例は共有してもらましょう！