書籍『カスタマーサクセス実行戦略』

 私にしては珍しく、畑違いの書籍を紹介してみます。

カスタマーサクセス実行戦略

カスタマーサクセス実行戦略




開示情報
(1) 私は著者の山田氏とは旧知であり、氏の卓越した理解力と洞察力に敬慕の念を抱いております。本を開く前から「これは良い事が書いてある本に違いない」との思いを持っていますから、本日記で紹介する内容には、そういったバイアスが掛かっている可能性が含まれることを予めお断りしておきます
(2) 私は著者の山田氏とは旧知であり、氏の(略)。本を開く時から「てきとーな事書いてごまかしてたら承知しねーぞ」との思いで向き合っているので、(1)と程よく相殺されているものと思われます
(3) 私は、「カスタマーサクセス」という用語に非常に否定的です(後述)。ただ、考え方については得るものがあると考え、名前と切り離して述べるために、本日記では カスタマーサクセスのことを CS と表記することにします。

あたりまえを体系化したCS

 本書内で著者も述べているとおり、CSは「当たり前」のことを並べているに過ぎない、とも言えます。曰く、一回つかまえたお客さんには長く使ってもらえるようにして、解約率を減らす努力をしましょう、曰く、適切な人に適切なタイミングでコンタクトを取りましょう、曰く、わかりやすい情報を開示しておく(セルフコンテンツ)と自分達もお客さんも手間が減ってハッピー、曰く、お客さんに共感しましょう...etc.
 ひとつひとつは当たり前のことでも、これらを体系的に整理し、評価方法についても提案している点が、CSのCSたる所以なのでしょう。
 筆者は、CSのマネージャーになるために必要な資質として、以下の8つを提示しています。

1. 分析思考
2. 積極性
3. 共感性
4. 粘り強さと情熱
5. チームプレイ
6. コミュニケーションスキル
7. 高度な専門性
8. 戦略思考

 ストレングスファインダー(SF)の「資質」の分類と似ている部分があると思い、比べてみると、以下の感じになります。面白い。★のついているものがCS資質に完全またはほぼ一致しているものです。★のついていないものは、SFの中で言えばこれかなと私が感じたものを紹介。

1[分析思考]★
2[活発性][競争性]
3[共感性]★
4[達成欲][信念][自己確信]
5 人間関係構築力資質群 全般 /[社交性][公平性][規律性]
6[コミュニケーション]★
7[学習欲][最上志向]
8[戦略性]★


 こうして見ると、非常に幅広い資質が求められているように見えます。

 私見ですが、元来商売というものは、相手が助かるようなモノ・コトを提供し、そのお礼としての対価を受け取るものであり、対価以上のことは提供しない、提供された以上の対価は払わない、ということを、ある程度のバッファを持ちながらもお互いのメリットを最大化するよう誠意を持って交流をする、という事だと考えています。これが、近代の「商売」では、仕事が細分化されました。お客さんにでたらめな事を言って適当な仕事を取ってくる担当、謝りに行く担当、モノを作る担当、お金の計算をする担当 etc... 。細分化の弊害として、本来は組織全体でひとつの「商売」をしているはずなのに、自分の担当部分以外には関心がない所謂タテワリになっている組織が、多く見られます。右足が前に出ているのに、左足が出てくれないおかげで前に進めないとか、ひどい時には右手が右の頬を殴っているかのようなケースもあります。
 歴史というのは波打っているものですから、そういった「誤った細分化意識」を揺り戻す動きが、CSの本質たる「ちゃんと全体を見ようぜ」なのかなと、私は解釈しています。

この本で印象的だったところ

 なんと言っても、4ページ強に亘る「はじめに」でしょう。著者のCSに対する思いが伝わってくるとともに、「この本を読んだらどんなノウハウが私に伝授されるのだろう」とわくわくさせてくれます。たんなる熱意だけでなく、整然とした説明は、まえがきを読んだだけでCSをとりまく背景と現在の状況を一望できた気分にさえなります(もちろん本文には、より詳細かつ具体的な記述が沢山あるわけですが)。

 もう一点は、CSの指し示す意味について私が根本的な勘違いをしていたことに気づかせてもらった点です。CSはその親和性の高さから、サブスクリプションモデルとセットで語られることが多い気がします。そのためか、サブスクモデル専用の手法というか、もっと極端に言うとサブスクモデルをうまく回すことがCSなのだ、というくらいの印象を持っていました。 本書では勿論サブスクモデルとの親和性についての言及はあるのですが、全体としては寧ろサブスクモデルを意図的に無視しているのではないかと感じるくらいに、CSの適用範囲を広く捉えさせるような工夫を感じました。「本を読んでそのまま手を動かせる人をつくる」というよりも、「本を読んで、実際に自分の頭で考えられる人をつくる」ことを意図しているようで、この、本質を伝えようとする姿勢に、好感を持ちました。

「カスタマーサクセス」という用語について

 冒頭で述べたとおり、私は「カスタマーサクセス」という用語に対して、非常に否定的な評価をしています。「顧客を俺たちが成功させる」という意味のこの言葉は、なに? 成功させてやる だぁ?てめぇ一体(いってぇ)何様でぃ! と悪態をつきたくなるくらいの傲慢な響きを持っています。客は「自分で」成功を目指します。サポートは期待しますが「成功させてやる」と言って近づいてくる人には怪しさしか感じませんし、他人の財布に勝手に手を突っ込んでくるかのような感じです。自社内でのスローガンとして「顧客を成功させるぞ、おー!」と言っている分には素敵な話ですが、打ち合わせで出された名刺に「お客様を成功させる部」なんて肩書きが書いてあったらもうお前馬鹿かレベルです。
 考え方の発祥であるアメリカの用語をそのまま取り込むのではなく、この分野を国内で牽引している一人である山田さんのような人が、本質的理解に近い場所にいるというポジションと能力を活かして、日本語でも受け入れられやすい用語を発明されることを願っています。

ということで改めて本書をお勧め

 本書は、著者が自らのカラダを動かして集めた情報を、自らのアタマを使って理解・再構成し、自らの時間を使って実施するというプロセスを、何度も繰り返したことで得られた「本質」を、惜しげもなく訊かせてもらえる本です。 著者の人柄どおりに、この素晴らしい考え方をどうにかしてみんなにも理解してもらいたい、伝えたい、という誠実な姿勢が感じられる本です。まだ若いこの分野で、現場で実践してみた人の話を聞けること自体も大変貴重です。書名で「カスタマーサクセス "実行" 戦略」と銘打っている通り、机上のお勉強話だけでない部分が、本書の魅力と言えるでしょう。 この分野に興味がある人には、その人の置かれている状況や目指しているものによってマッチする/しないはあるでしょうけど「とりあえず読んでごらん」とお勧めしたいです。



余談

 本書の中には、CSを実践した会社の方やキーマンの方へのインタビューが含まれています。これ、山田さん、やりたかったんだろうなぁ、楽しかっただろうなぁ、そして書くときにはえらく気を使って大変だったんだろうなぁ、とニヤニヤしてしまいました。
 私も14年ほど前に作った本で、どうしてもやってみたくて、インタビューを入れたのですが(その節は各社様、ありがとうございました)、先方が伝えたいものと自分が紹介してあげたいものを会話の中で探り合い、記事の完成形をイメージしながら補いたい情報を追加で質問したり、それはそれは楽しかったです(笑)。

この本:

超・極める!MySQL

超・極める!MySQL

MySQLリリースノートを読む会を開催してみました(8.0.21)

 2回目の「MySQL リリースノートを見てわいわい言う勉強会」を開催しました。今回は MySQL 8.0.21版。

mysql.connpass.com


 過去2回の知見、および今回得た情報の一部をメモとして書いておきます。

MySQL リリースノートのセクション

  • いくつかのカテゴリに分かれて解説されている
  • カテゴリは、一番下のほうに 「Functionality Added or Changed」と「Bugs Fixed」の2つがある。昔はこの2カテゴリしかなかった
  • 上部にあるカテゴリ解説は、上記2つのカテゴリの中から、特に解説したいものがある場合にピックアップして詳細に説明している、という位置づけっぽい
  • ピックアップされたものは「Functionality Added」「Bugs Fixed」からは除外される模様

MySQL リリースノートの見かた

  • 気になる機能等があれば、まずそれで検索(私の場合は "spatial"。人によっては JSON だったり)
  • deplicated なものは一応チェックしておいて損はない。Deprecation セクションがある場合はそこを見たり、そこ以外でも "depreca" とか "remove" とかで検索するとよさげ
  • 正しくない結果を返す系の変更(修正)を知りたければ "incorrect", "wrong" あたりで検索
  • サーバが落ちる系の問題については、"crash"という言葉はあまり使われないようで、"exit", "assert" あたりをキーワードにするとよさげ
  • Bug番号のうち 8桁の番号のものは、オラクル社内のみ閲覧可能なバグ管理システムの番号。オモテで一般人が見ることができるのは、6桁までの番号のもののみ(ついこの前、6桁に突入しました!)。セキュリティ関係や契約ユーザからの報告である関係など色々事情はあるようですが、コミュニティユーザとしては、修正後、あるいは修正後に1つ次のバージョンがリリースされたら、等のタイミングで、チケットを公開してほしいと思うところであります。
  • リリースノートは、公開後に変更(更新)されることがあることが、今回発覚! リリース直後には2項目しかなかった "Security Notes"が、今回のイベント当日時点では3項目に増えていた!(私は、リリース直後にリリースノートをPDFでダウンロード) この増えた項目は、もともと "Functionality Added or Changed" にあったもので、3項目に増えたあとは、"Functionality...." からは項目が消えていました(上部にピックアップ移動した扱い)。

f:id:sakaik:20200816231725p:plain

今回 (8.0.21)の話題から

  • マスター/スレーブ の名前を今後少しずつ変えていくよ!とリリースノートの冒頭でアナウンス
  • MySQL Shell の新機能、Backup/Load が速いやつ、気になる
  • 今回の Deplication は パーティショニング関係にひとつ。もともと あまり使われていない感じ?
  • JSON_VALUE() 関数が追加。シンタックスシュガーだという理解でいいのかな。
  • オプティマイザ・スイッチ subquery_to_derived 追加。良さげなときに、サブクエリをJOINに書き換えて実行してくれるスイッチ。デフォルトはオフ。 速くなるものとそうじゃないものがあるので「テスト用」とのこと。

会の進行方法に、まだ迷っている

 主催者&進行役 として、進め方等について、正直まだかなり迷っています。こういった会合は、単なる雑談会になってしまうと、分かる人だけで話が盛り上がって、何の話か分からない人が置いていかれるという状態になりがちです。なのでなるべく、どの部分の話をしているのか、何の話(前提知識等)をしているのかが共有できるようにと意識をしているのですが、逆にそれが全体の自由な流れを阻害してしまっているなぁとの感覚もあります。 進行役が介入しすぎるのは、この会の目指す方向と照らし合わせても、あまり良い状態ではないので、(前半の発表の部は今まで通りとしても)後半部分は、会の参加者の流れに自由に任せてみるという形式を次回は試してみたいと考えたりしています(開催までにまた考えが変わるかもしれません)。
 昔、私がよく参加していた勉強会(非IT系)では、「それなに?」「どうしてそんなことが?」「背景は?」などと、質問する人が一番偉い人、という事にしていました。もちろん、自分が本当にそれを知りたいから、詳しい人へのリスペクトを以てその解説をお願いする、というスタンスであり、相手を試そうとするものだったり、興味もないのに手間をかけさせたりするようなものではないことは、言うまでもありません。詳しい人は説明したがりであって欲しいし、そういう人に(その分野では)詳しくない人が気軽に教えを請うような、そんな場ができたら良いと思っています。

 また、今回 MySQL Shell のリリースノートを挙げた方がいて気づいた事もありました。本イベントは、MySQL本体のリリースノートでわいわい言うことを念頭に企画していたのですが、周辺ツール群はそれぞれにリリースノートがあるので、そちらも、興味がある人がいれば、当然話題にして良いことにします。MySQL Shell とか Workbench とか。特に誰も話題に取り上げなければ、MySQL本体のリリースノートを中心に話を進めます。


 ということで今回もたくさんの方のご参加、ありがとうございました。「車座」の雰囲気をまだ実現できていないところが一番の改善点でもあるので、今後は全員、自己紹介と気になるリリースノートの項目をひとつ挙げてから始めるなど、工夫をしていきたいと思います。

当日の模様(動画)

www.youtube.com

Re: MyISAMで第2カラムのAUTO_INCREMENTを使ってるテーブルを洗い出すSQL

yoku0825 さんが、面白そうなブログを書いていました。
yoku0825.blogspot.com


 MySQLの auto_increment 列は キーカラムである必要がありますが、このキーは複合キーでも構わない。ただし 複合キーの場合は、InnoDB ではキー指定のうちの1つめのカラムである必要があり、MyISAMなら2つめ以降のカラムでも良い、という違いがあるそうです。

mysql> create table tt1 (c1 integer auto_increment, c2 integer, c3 integer, key(c2, c1, c3)) engine=innodb;
ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key

mysql> create table tt1 (c1 integer auto_increment, c2 integer, c3 integer, key(c2, c1, c3)) engine=myisam;                      
Query OK, 0 rows affected (0.01 sec)

mysql> create table tt2 (c1 integer auto_increment, c2 integer, c3 integer, key(c1, c2, c3)) engine=innodb;                      
Query OK, 0 rows affected (0.02 sec)

 MyISAMで作ったテーブルの中に、こういった「key 2カラム目以降auto_incre」があると、そのままではInnoDB化ができないために、どのテーブルで使っているのかを把握しておきたいという意図でしょうか(想像)。
テーマとして面白そうだったのと、ブログで紹介されていたクエリが直観的に「もっとシンプルになるはず」と感じたので、試してみました。

準備

 yoku0825さんのブログを見て、t1, t2, t3, t4 の4つのテーブルを作成します。
私は今回「test」スキーマの中に作りました。

テーブルを作ったあとは、とりあえず i_s をデフォルトスキーマにしちゃったほうがラクなので。

mysql> use information_schema;
Database changed

SQLあそび

とりあえず、キーの情報は STATISTICS テーブルにあるので見てみる。

SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME, s.SEQ_IN_INDEX
  FROM STATISTICS s
 WHERE s.TABLE_SCHEMA='test'
+--------------+------------+-------------+--------------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | SEQ_IN_INDEX |
+--------------+------------+-------------+--------------+
| test         | tripoint   | id          |            1 |
| test         | kanko      | c1          |            1 |
| test         | t1         | one         |            1 |
| test         | t2         | one         |            2 |
| test         | t2         | two         |            1 |
| test         | t4         | one         |            3 |
| test         | t4         | two         |            1 |
| test         | t4         | three       |            2 |
| test         | t4         | one         |            1 |
| test         | t3         | one         |            3 |
| test         | t3         | two         |            1 |
| test         | t3         | three       |            2 |
+--------------+------------+-------------+--------------+

とりあえず auto_increment の情報は、COLUMNS テーブルの EXTRA にあるので見てみる。

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, EXTRA
  FROM COLUMNS
 WHERE EXTRA LIKE '%AUTO_INCRE%';

+--------------+-----------------+--------------+----------------+
| TABLE_SCHEMA | TABLE_NAME      | COLUMN_NAME  | EXTRA          |
+--------------+-----------------+--------------+----------------+
| test2        | location_tweet  | id           | auto_increment |
| test2        | spot1           | id           | auto_increment |
| test2        | spot2           | id           | auto_increment |
| mysql        | component       | component_id | auto_increment |
| mysql        | time_zone       | Time_zone_id | auto_increment |
| test         | t1              | one          | auto_increment |
| test         | t2              | one          | auto_increment |
| test         | t4              | one          | auto_increment |
| test         | t3              | one          | auto_increment |
+--------------+-----------------+--------------+----------------+

 
 
とりあえずくっつけようか。
STATISTICS の右側に、auto_incrementである情報がついているくらいがちょうどよさげ。
結果は、見やすいようにテーブルごとに線を入れてみました。

SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME, s.SEQ_IN_INDEX, c.EXTRA
  FROM STATISTICS s
   LEFT OUTER JOIN COLUMNS c ON (s.TABLE_SCHEMA=c.TABLE_SCHEMA AND s.TABLE_NAME=c.TABLE_NAME AND s.COLUMN_NAME=c.COLUMN_NAME)
 WHERE s.TABLE_SCHEMA='test'
 ORDER BY TABLE_NAME, COLUMN_NAME, SEQ_IN_INDEX
+--------------+------------+-------------+--------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | SEQ_IN_INDEX | EXTRA          |
+--------------+------------+-------------+--------------+----------------+
| test         | t1         | one         |            1 | auto_increment |
+--------------+------------+-------------+--------------+----------------+
| test         | t2         | one         |            2 | auto_increment |
| test         | t2         | two         |            1 |                |
+--------------+------------+-------------+--------------+----------------+
| test         | t3         | one         |            3 | auto_increment |
| test         | t3         | three       |            2 |                |
| test         | t3         | two         |            1 |                |
+--------------+------------+-------------+--------------+----------------+
| test         | t4         | one         |            1 | auto_increment |
| test         | t4         | one         |            3 | auto_increment |
| test         | t4         | three       |            2 |                |
| test         | t4         | two         |            1 |                |
+--------------+------------+-------------+--------------+----------------+

 
 
t1とt4は、SEQ_IN_INDEXが 1 のものに auto_increment がついているのでOK。
それ以外の t2 と t3 を出したい、というのが今回の課題。
 
 
ここまでくれば簡単ですね。
一番単純なのは、グルーピングすることかな。

SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME, MIN(s.SEQ_IN_INDEX) sq
  FROM STATISTICS s
   LEFT OUTER JOIN COLUMNS c ON (s.TABLE_SCHEMA=c.TABLE_SCHEMA AND s.TABLE_NAME=c.TABLE_NAME AND s.COLUMN_NAME=c.COLUMN_NAME)
 WHERE s.TABLE_SCHEMA='test'
   AND c.EXTRA LIKE '%auto_incre%'
 GROUP BY s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME
 HAVING sq>1
 
+--------------+------------+-------------+------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | sq   |
+--------------+------------+-------------+------+
| test         | t2         | one         |    2 |
| test         | t3         | one         |    3 |
+--------------+------------+-------------+------+

 
 
 WINDOW関数を使ってシャレてみたけど、あんまり賢いクエリの書き方のような気はしない。。上記 GROUP BY が最良かも。

SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME, s.SEQ_IN_INDEX sq
  ,MIN(s.SEQ_IN_INDEX) OVER (PARTITION BY s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME) x
 , CASE WHEN (MIN(s.SEQ_IN_INDEX) OVER (PARTITION BY s.TABLE_SCHEMA, s.TABLE_NAME, s.COLUMN_NAME))<>1 THEN "←こいつです!" ELSE "" END kit
  FROM STATISTICS s
   LEFT OUTER JOIN COLUMNS c ON (s.TABLE_SCHEMA=c.TABLE_SCHEMA AND s.TABLE_NAME=c.TABLE_NAME AND s.COLUMN_NAME=c.COLUMN_NAME)
 WHERE s.TABLE_SCHEMA='test'
   AND c.EXTRA LIKE '%auto_incre%'

+--------------+------------+-------------+----+------+----------------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | sq | x    | kit            |
+--------------+------------+-------------+----+------+----------------+
| test         | t1         | one         |  1 |    1 |                |
| test         | t2         | one         |  2 |    2 | ←こいつです! |
| test         | t3         | one         |  3 |    3 | ←こいつです! |
| test         | t4         | one         |  1 |    1 |                |
| test         | t4         | one         |  3 |    1 |                |
+--------------+------------+-------------+----+------+----------------+


 
  
 最後のSQLも、ややゴチャゴチャしていますが、はじめからスキーマ指定での前提なら、TABLE_SCHEMA の出力や結合の処理を省略して、もうすこしスッキリしたクエリになります。

 面白いテーマをありがとうございました。

MySQL徹底入門第4版出版記念イベント on ニフクラエンジニアミートアップ

既報のとおり、7月上旬に『MySQL徹底入門第4版』が出版されました。ありがたいことに、出版記念のイベントを求める声もちらほらいただいていたのですが、主に私自身が MySQLユーザ会のイベントを多く主催したりしていることもあって、ユーザ会として自分たちの本の宣伝めいたものを開催するのは、やや気が引けるなぁと悩んでいました。折しも、ニフクラさんが定期的に開催している「ニフクラ エンジニア ミートアップ」としてやったらどうかとのお誘いをいただき、その中でやらせていただくことができました。#nifcloud_emup のみなさま、どうもありがとうございました。

fujitsufjct.connpass.com


 内容は、
・私から、MySQL徹底入門第4版のれきしと概要と裏話についての話
・各著者(ほぼ全員)から、執筆箇所の解説や、思いなどのミニ講演
・本書編集さんからのお話
・執筆陣によるトークセッション
となりました。
動画編集していて気づいたのですが、私、話しすぎている・・・・。そういや時計見てなかった(^^;。すいません。

 著者どうしも、特に昨今の新型コロナ騒ぎの影響もあって生顔、生声で会うことはほとんどなかったので、(ずっと一緒に作業をしていたのに)「おひさしぶり~」な気分でした。執筆期間中にはあまり聞くことのなかったエピソードや、それぞれの思いなどが聞けて、私自身も大変楽しませて頂きました。
 私の発表部分の資料と、イベント動画は、以下に公開していますので、よかったらご覧ください。MySQL徹底入門第4版の裏話、エピソード、思いなどをお聞きいただいて、本書に、より少しでも親しみを持ったり、少しでも多く活用していただけたら、この上ない幸せです。 更に、お知り合いの方3人くらいにも本書を勧めていただけたら、更にその上の最上級の幸せに感じる次第です。


 貴重な機会をくださいました ニフクラ エンジニア ミートアップ様に改めて御礼申し上げます。
 



■私の発表部分(冒頭の全体のお話と、自分の執筆部分)の資料は、以下 Slideshare で公開しています。

www.slideshare.net


■動画は、ニフクラ エンジニア ミートアップさんの YouTubeチャンネルと併せて、日本MySQLユーザ会チャンネルのほうでも公開しました(ニフクラさんにいただいた動画に、冒頭末尾の編集を少し加えたものです。動画ご提供ありがとうございました)
www.youtube.com


MySQL徹底入門第4版は、こちら

OSC2020新潟オンライン 参画

 オープンソースカンファレンス2020新潟オンライン(OSC2020 Online Niigata)に参加してみました。

ospn.connpass.com

 新潟でのOSCは、とにかくお酒とごはんのおいしさと、東京(上野)からも電車一本で行ける気軽さ故、毎年の開催を楽しみにしていたOSCのひとつでした。今年は長岡での開催が予定されていて、(新潟市まで行くよりもほんの少しだけ)近くなって一層気軽に参加できると思っていただけに、新型コロナの影響によるオフライン中止(オンライン化)は、ちょっと残念に思っていました。 

 でも、実行委員さんのご配慮で「新潟お酒セット」を購入できることに。なかなか手に入らないものも含めて3本セット。 どれもおいしく、OSC Niigata の前後数日で(私は家であまり呑まないのでその期間合わせても)2本程度をいただきました。 ただ、やっぱり現地に行ってみんなで、「自分はこれが好きだなぁ」「私はこっち」と言いながらいろいろな種類のお酒をいただける楽しみに比べると、雲泥の差があるので、はやくまたそうやって、おいしいおさけをみんなでいただける日が来ることを願っています。
f:id:sakaik:20200722212605j:plain



 こんな感じで、今年もオンラインではありながら、楽しい OSC 新潟でした。


・・・・あれ?


 OSC本体の話を書いていない。。


 OSC新潟では、他のOSCと異なり、ワントラック(ひとつの部屋にステージがひとつだけあって、そこで次々に色々なコミュニティがお話をしていく)かつ、持ち時間が15分だけというスタイルです。複数トラックの中から聞きたいテーマを選んで参加する場合と異なり、部屋に一旦入ったらそのまま強制的に(笑)いろんな話を聞かされるか、あるいは部屋を出て行くかしかないので、スピーカー側からすると、自分の講演テーマにまったく興味がない人、またまったくバックグラウンドを持たない人が聞き手にいることになります。
 そういう背景での開催なので、例年、「MySQLを知らない」「そもそもRDBMSを知らない」という人が聞き手の大半であるという前提で、セミナーの内容を考えてきました。今年はオンラインになって、出入りがしやすくなり、自分の興味のあるセミナー枠の時間帯だけ視聴するという可能性もあるので、どうしようかと迷ったものの、やはりここは「これが OSC新潟だ!」と私が思っている雰囲気を大切にして、従来通りの方針で挑むことにしました。少しでも、システムの中でRDBMSというソフトが頑張っていて、そのソフトに興味を持ってくれる人が増えたら嬉しく思います。

www.slideshare.net

 
 なお、発表資料の中で「MySQLPostgreSQLのどちらも真のOSSデータベース」と説明していますが、これは、日経XTECHの記事で『「特定ベンダーの管理下にあるソフトは真のOSSとは言えない」(LPI-Japanの成井弦理事長)』という誤った情報が掲載されていた(下図)ことに対して、正しい内容をお知らせするものです。MySQLOracle社という特定ベンダーが開発(管理)していますが、言うまでもなく「真の」OSSです。OSSに「真でないOSS」というものは存在しない(それは単に「OSSではない」と同義)ので、敢えて「真の」と付けなくてもOSSなのですが。
これを読んだ(あるいは資料を見た)方には、「MySQLは真のOSSとは言えない」というのは、LPI-Japanのみの独自見解であり、一般に認められた解釈ではないことを知って頂ければと思います。

f:id:sakaik:20200802152251p:plain
https://xtech.nikkei.com/it/article/NEWS/20110608/361171/

 自分の枠のあとは、何人かのお話を聞かせてもらって、夜の懇親会へ。
各地から参加していた人が多かったこともあってか、話題は一部を除き、あんまり新潟新潟していなかったかなーという印象でした。

OSCをはじめ、各地で開催されていた「地域イベント」がオンライン化することによって、空間的な垣根が取り払われました。私自身はこれにより、長期的には「地域イベントに地域性はなくなる」と感じているほうなのですが、これも人によって色々な捉え方をしているので、軽く議論すると非常に面白い。
 今は、今までその地域で出会った人たちにオンラインで会うことができ、その人たちがいることでその地域らしさを感じていますが、今後新しい人がどんどん参加してくる中で、そういう人たちにとっては主催者がどの地域かというのは実感がないものです。今後混ざり合っていった結果「発祥は各地域だし、それぞれに特徴はあるけど、特に地域を意識する必要はない」ようになっていくのではないかなと個人的には感じています。 積極的に地域の発表者を掘り起こし、積極的に沿った話題を取り上げていく場合はその限りではありませんが。
 という思いは持ちつつも、今まで全国のOSCを周り、いろいろな人と出会ったり地域を感じさせていただいたりしてきた身としては、イベントの均一化は寂しい事象でもあるので、イベントにおける地域性(地域名を関したイベント)というのは何なのだろう、ということを、今後も考えていきたいと思います。

 新潟に話を戻すと、この緩さ(参加者自身で作り上げていくイベントという感じ)は、唯一無二の新潟のOSCなので、今後もこの緩さを大切に(「頑張らない」をキープ)開催が続いてくれたらなぁと願っています。 そして、最後はオンラインの話を書きましたが、新潟こそは、顔をつきあわせて、おいしい何十種類ものお酒を一緒に楽しめる世の中でまた、リアル参加できることを心から楽しみにしています。

日本MySQLユーザ会会開催しました(2020年7月版)

 日本MySQLユーザ会会(MyNA会)と銘打つものとしては久しぶりに、イベントを開催しました。
いつものMyNA会は、そのタイミングでお話したいネタを持っている方に話していただくということで、多岐に亘る話題となることが多いのですが、今回はイベント全体にテーマを設けて開催してみました。その名も『連載と定期更新の著者に訊く贅沢な120分』。

mysql.connpass.com


 雑誌の連載記事、Web上の連載や定期掲載記事などでMySQLの話を目にすることは多いと思います。それ、書いている人がいるんです! 文章だけでは見えてこない思いや裏話、今まで書いた中でのご自慢の記事などを紹介してもらいたいと、企画しました。 予想通り、というか予想以上に各記事にそれぞれの思い出、思い入れ*1、苦労や涙があり、面白いお話を伺うことができました。 
 大事な話なので先に書いておきますと、著者って結構孤独なんです。頑張って書いた記事が、みんなにどのように届いたのか結構不安なのです(人にもよりますが)。 そして、公開した記事に対して驚くほど反応がわからないのです。なので、例えばWebの記事を読んで、これいいなーと思ったら、TwitterにでもURLをぺたりと貼って「これよかった」とか、もう少し頑張って書ける人は「○○は知らなかったなぁ」とか「紹介されている△△って機能、このまえ使ったわー」とか、感想を口に出して(というか指に出して??)ほしいのです。著者に届かないかもしれないし届くかもしれないけど、ちょっとした話題にしてみる、という行為が、著者さん達への応援につながります。なるほどな、と思ったらぜひ、やってみていただけたらと思います。


 さて、今回のイベント。

 という3つの連載/定期更新 を書かれている方に、登壇いただきました。 「梶山さん」だけ連載名ではなく人の名前のように見えるのは、梶山さんは多くの連載を抱えられていて(SoftwareDesign 誌、シェルスクリプトマガジン誌(終了)、OSS取り取り時報)、それらまとめて発表をお願いしたからです。

 以下、個人的に印象に残った(あるいは単に記憶に残った)お話をいくつか箇条書きで:

  • 編集さん重要!みんなとっても感謝してる!
  • 記事ひとつひとつに著者の辛かった思いが込められている、、と聞いて、読むのが辛くなった(笑)
  • 木村さんのお話、あまり今まで聞く機会がなかったけど、落ち着いた語り口でとっても分かりやすかったです。今後もご登壇ぜひ!
  • 今 明かされる「道普請」のおこりと、いつの間にか居なくなっていた初期著者たちの謎(笑)
  • 「Weekly」は月曜朝更新。日曜深夜に関係記事が公開されると拾えなくなってたいへん!(←編集作業後の記事は次週にまわしていただくので全然問題ないと思います!)
  • 案外知られていなかったそれぞれの記事、連載。だからこそ今回開催したことで、知ってもらうことの一翼を担えていたらいいなぁ。
  • もっと知られていなかった「シェルスクリプトマガジン」。Twitterの反応を見てみると、初めて知って興味を持った人もいるようだったので、よかった。このように、届くべき人のところに届くべき情報が届いていない(いわゆる「3届現象」)が発生しているのが現状なので、みんなでお互いに色々話題にしたりして、必要な人の目に届く機会を増やしていける空気ができたらいいなぁなんて考えています。
  • mysqlsh の記事は、Kindle化されている。日本で(世界でも)数少ない mysqlsh についてガッツリまとまっているものなので、必読(私もKindleのほうはまだ読んでないけど・・・)
  • 連載を始めると自分のブログの更新が減る(またはなくなる)、逆に連載やめたらブログの更新が捗るようになった人も。


 イベントの模様を、動画でそのまま公開しています。以下の 日本MySQLユーザ会チャンネルからどうぞ。チャンネル登録というのをしてもらうと、どんないいことがあるのかよく分かっていませんが、動画公開する人がよく書いているみたいなので、一応「チャンネル登録をお願いします!」と書いてみます(100人登録していただいて、URLの固有名を取得できたのですが、それ以上いる場合のメリットがよくわからない)。
www.youtube.com



 また開催します。日本MySQLユーザ会会では、MySQLに関するお話をしてくれるスピーカーを常に募集しています!twitter で #mysql_jp をつけてツイートしてくださいませ。

f:id:sakaik:20200719162528p:plain:w3

*1:似たような意味なのに、出入 という逆の文字が使われているのが面白いですね

メモ:MySQLの NOW() と SYSDATE()

 MySQLで、NOW()もSYSDATE()も、大雑把には「現在時刻を返す関数」なのですが、実はその挙動は異なります。
現在時刻とは何か、つきつめると「時間とは何か」という哲学的なテーマになるのですが、ここではそんな難しい話ではなく、さしあたって MySQL では、
 NOW() は、そのクエリ処理が開始した日時
 SYSDATE()は、その関数の処理が行われているまさにその日時
という話をしたいだけです。

mysql> SELECT NOW(), SYSDATE(), SLEEP(3), NOW(), SYSDATE();                                                                   
+---------------------+---------------------+----------+---------------------+---------------------+
| NOW()               | SYSDATE()           | SLEEP(3) | NOW()               | SYSDATE()           |
+---------------------+---------------------+----------+---------------------+---------------------+
| 2020-07-12 11:49:13 | 2020-07-12 11:49:13 |        0 | 2020-07-12 11:49:13 | 2020-07-12 11:49:16 |
+---------------------+---------------------+----------+---------------------+---------------------+
1 row in set (3.00 sec)

 なぜか私は逆に覚えていて(SYSDATEのほうが処理固定だと)、あれっとなったのでメモとしてこの日記を。

 
 時間というのは不思議なもので、その時々に応じて長さが変わります。皆さんも、退屈な30分の授業がなかなか終わらなかったり、逆に、重要な試験の最中に一瞬で2時間が溶けていたり、楽しい飲み会で「さっき20時だったのにもう23時!」なんて経験をしたことがあると思います。きっと、NOW()関数も、夢中になって処理をしてくれているうちに、時間が過ぎていることに気づかなかったのでしょうね。SYSDATEのほうはシステム的に常に冷静に今の時刻を把握していて、さすがだなぁといったところです。


時間とは何か 改訂第2版 (ニュートンムック)

時間とは何か 改訂第2版 (ニュートンムック)

  • 発売日: 2020/07/16
  • メディア: ムック