そーだいなるらくがき帳

そーだいが自由気侭に更新します。

問題を小さいうちに解決させるってチームにとってとても大切ですよね

妻が実家に帰省中で、長男の面倒見ながら家事をしてそう思ったのでメモ。
例えば洗濯や食器の洗い物は貯めない方が手を付けやすいし、すぐ終わります。
すぐ終わるというレスポンスは次のハードルをまた下げてくれるので好循環を生みやすいです。
掃除やゴミ捨てだってそうです。
特に家事はマルチタスク処理を求められるので問題が大きなり、時間がかかると着手しにくくなります。
またすぐ子供から割り込みが来るので小さい問題を常に解決した方が全体として効率が上がります。
だからもし大きなタスクの場合は問題を細分化する必要がありますし、そもそも問題を小さいうちに解決していくことが大事だなと感じたわけです。
小さな問題の解決を世の中では割れ窓理論って言ったりハインリッヒの法則って言ったりするのでみんなも概ね賛同してくれると思います。
うちのチームでもプロダクト開発時に生まれた小さな問題を割れ窓と言ったり、リリース後の小さな問題解決を落穂拾いと言ったりします。

でもこれって家事以外でも言えるよね

ちょっと前に人が成長するためには問題解決する経験が必要で、そのためには適切なサイズの問題を用意する必要があるってことを考えたことがあります。

soudai1025.blogspot.jp

これとは逆に小さいうちに解決したほうが良い問題もあります。
例えばチームマネージメントと言うか、チームの不満とかは小さいうちに解決したほうがいいでしょう。
大きくなると歪みを生み、場合によっては派閥が生まれたり意図しない弊害が生まれて取り返しのつかない状態になります。
チームは当たり前ですが人と人の座組の結果ですから、勿論相性がありますし、相性が合わない事も多々あります。
チームが大きくなったり、長く所属してたり、座組に変化があったりなどのトリガーで大小の不満が生まれることはあります。
そんな感じでチームというのは生き物なので環境に合わせて常に変化しています。
ですのでチームの問題としていち早く察知し、素早く手を打てるか?と言うのはとても大切なマネージャーの仕事の一つです。
とは言え、チームの規模が大きくなれば全体を見るとどうしても細部が見えづらくなります。
そこで1on1をやったり、飲み会やったり、ランチミーティングしたりしてなんとかして小さな不満を探そうとするわけです。

本当に問題(不満)を見つけれてるのか

さて小さいうちに問題を解決したほうが良いこともそれがチームのために必要なこともわかりました。
どの経営者やマネージャーに聞いてもそれは理解を得られると思いますし、そのための努力をしていると言うでしょう。
しかし本当にチームの問題を汲み取れているでしょうか。
僕はマネージャーとプレイヤーを両方経験して思うのは、マネージャーが思っている以上にプレイヤーは不満を口にしません。
正確には「マネージャーの見える範囲」に出しません。
マネージャーの多くは直属のプレイヤーの評価者ですし、多くの裁量を持ちます。
ですのでプレイヤー自身のマイナスになる場合は不満を口にしないのです。
そして多くのシーンで「不満を口にする」のは意見具申ではなく、ただの愚痴として評価され、マイナスになると考えているのではないでしょうか。
特に不満先がマネージャー自身や組織自身にある場合は尚の事、組織批判やマネージャー批判と取られるので表に出づらいと思います。
その結果、不満が露呈するのは退職という形でであったり(そこでも多くの場合は本当の不満を口にせずに去っていくでしょう)チームの破綻によって気付かされるというのが最悪のケースです。

不満を言える雰囲気を作るには

結論、経営者やマネージャーが「メンバーと真摯に向き合う」としか僕はまだ答えを持ってません。
会社の金で飲み会や社員旅行をしても、モヤモヤボードを導入しても、マネージャー側に問題を解決する意志が無ければ形骸化するでしょう。
実際に現場では小さな問題の糸口はマネージャーの居ない喫煙所やランチ、会社からの帰り道で見つかる気がします。
これはやはり不満を言う事にメリットが無く、しかし不満をうちに溜め込むことが難しいからでしょう。
同僚に不満を口にするのは次の点があるかもしれません。

  • 同僚は評価者では無いため、デメリットが無い
  • 同僚がもしかしたら解決するためのアイディアを持っているかもしれない
  • 多くの同僚の同意を得られると噂話のような形でマネージャーに問題が伝わるかもしれない

これらはマネージャーの気持ちからすると「そんな遠回しな手順を踏まなくても直接言ってほしい」と思うかもしれません。
しかしあなたに直接伝えるメリットをプレイヤーが感じていないからこのようになるのです。
働くという字は人が動くと書いて働くですが、人は「自分のために動く」のですから当然そこにデメリットしかない場合はこのような結果になります。

また人手不足を声高に言う会社は多いですが、本当に今いるメンバーと向き合えているでしょうか?
新しい人を3人雇って2名辞めるチームは人の入れ替えのコストが高く、健全とは言えませんし、ブルックスの法則から見ても生産性が高いとはいえないでしょう。
心当たりのある経営者やマネージャーはそこから見直しをしてみては如何でしょうか?

じゃあSoudaiさんはどうしてるの?

会社では私は今はプレイヤーの立場で仕事をしており、マネージャーではありません。
ですがマネージャーの小さな問題を知りたいと言う気持ちを知っていますし、プレイヤーがマネージャーに伝え難い気持ちもわかります。
ですのでそこを上手く橋渡ししたり、情報収集して上手くマネージャーに提案することを意識してます。
また雑談を大事にしてます。
先程の喫煙所やランチタイムの例のように雑談には色んな本心が隠れています。
ですが雑談がなければそもそも情報収集する場もありません。
ですので雑談が少ないと感じれば雑談する場を作れば良いと思いますし、話を聞きたい人があれば食事に誘うなどの色んな方法があります。
リモートワークの場合はこの雑談がより難しくなるので工夫が必要だと思いますし、だからこそ色んなチームがビデオチャットを導入したり、社内Slackに趣味チャンネルや自分用のチャンネルを作ることを許容するのでしょう。

そして最近、もう一回プレイヤーに戻ってきて感じるのですがこれがデマルコの言う触媒のポジションなのかもしれません。

※デマルコと言えばピープルウェアですがデッドラインは本当に読みやすいのでオススメです

触媒というポジションは私の適正あるポジションの一つかもなと最近感じています。

まとめ

ということで問題を小さなうちに解決することは大切だと思います。
しかし実現するためには

  • 経営者やマネージャーが問題解決をするぞという意志
  • 小さい問題を集める仕組みやポジション
  • プレイヤー側の伝える工夫

などが必要で一筋縄ではいかないということがわかりました。
ですのでそれぞれのポジションが意識する必要があります。
またこれは普段の生活から意識すること多くの問題を解決すると思います。
まずは私もそーだい家と言うチームの長ですので家族と言うチームメイトの問題を解決するぞと言う強い意志を持って家族と成長したいと思います。

SourceTreeを実際に使ってエンジニア以外の人にGitを使って貰った話

タイトルのことを第21回 Tokyo Atlassian ユーザーグループで話してきました。

augj.connpass.com

登壇資料はこちらです。

speakerdeck.com

ざっくり言うとエンジニア以外の人にGitを使ってもらうにはGUI大事って話と僕たちは問題を解決したいわけで、なのでツールはそのための手段なので手段が目的になるのは駄目とは言わないけど本質は見失わないようにしましょうって感じです。

もうちょっと具体的に話すと、Gitというとコードを管理するモノってイメージ強いと思いますけど、実は色々と便利になります。
例えば定例MTGの議事録だって良いと思うし、手順書だってテキストで管理していいと思います。
そこにGithubやBitbucketを組み合わせると履歴が可視化されるし、プルリクエストを使うとより差分が明確になります。
こういうエンジニア向けの技術を柔らかくして、エンジニア以外の人にも使ってもらうことで全体の効率を上げることができるので、みなさまも是非チャレンジしてみてください!!

ということで今回AUGで久々にDB以外の話をしましたがこういうのも楽しいですね!
機会があれば他のイベントにもガンガン登壇したいと思いますのでお気軽にお声掛けください。

ほんとAtlassian、ユーザライクでコミュニティの楽しみ方知ってて大好きな会社です。

SoftwareDesignの連載をはじめました。

タイトルそのままにSoftwareDesignの連載をはじめました。

gihyo.jp

RDBアンチパターンと題してRDBの設計についてお話していきます。
なかなか胸に刺さる話となってますので今後の内容にもご期待ください!!

寂しかったのでブログ書きました。
現場からは以上です。

PostgreSQLで排他制約がめっちゃ便利!!

中国地方DB勉強会っていう控えめに言っても最高の勉強会があるんだけどそこで排他制約について教えてもらいました。

ikkitang1211.hatenablog.jp

排他制約って雑に説明すると重なりを拒否する制約です。 僕は使った事なかったのですが勉強会の中で事例紹介を受けて、めっちゃ便利だったのでここでご紹介します。

どんなときに使うの?

実際にはどんなときに重なりを制御したいかというとよく使うのは次の2つ。

  • 図面の重なり
  • 時間の重なり

1つ目は幾何学的な図面を表現するときです。 実際にPostgreSQLは円や四角をSQLで表現できます。例えば地図上で特定の座標から半径100メートルの円を書き、その中に特定の円(場所)があればErrorにするような制約が書けます。 そもそもSQLで位置計算もめっちゃ便利なので是非使ってみてください。

soudai1025.blogspot.jp

そして2つ目が時間の範囲での重なりの表現です。 PostgreSQLには範囲型というのがあります。 これは時間や数値の範囲を1つのカラムで表現できます。 例えば有効期限を表現する時、一般的にはstart_atとend_atのそれぞれのカラムを作成するのではないでしょうか。 この場合、 今日が有効期限に含まれるかどうか の点と線の比較は簡単ですが 特定の期間が有効期限に含まれるかどうか という検索は非常に面倒です。 しかし範囲型を使うと 5 <@ int4range(1,7) のように <@ で範囲と範囲の含有が簡単に検索できます。このように色んな演算子を用意しているので簡単に表現できます。

soudai1025.blogspot.jp

9.19. 範囲関数と演算子

実際の使い方

さて、ここまで読んで範囲型めっちゃ便利!!と思っていただけたと思います。 そこで例えば会議室の予約システムを作る時に範囲型を使うと次のように表現できます。

CREATE TABLE schedule
(
    schedule_id SERIAL PRIMARY KEY NOT NULL,
    room_name TEXT NOT NULL,
    reservation_time tsrange NOT NULL
);

demo=# SELECT * FROM schedule;

 schedule_id |  room_name  |               reservation_time
-------------+-------------+-----------------------------------------------
           1 | soudai_room | ["2017-04-16 11:30:00","2017-04-16 12:00:00")
           4 | soudai_room | ["2017-04-16 12:00:00","2017-04-16 12:30:00")
           5 | soudai_room | ("2017-04-16 12:30:00","2017-04-16 12:40:00")
           8 | soudai_room | ["2017-04-16 14:30:00","2017-04-16 16:00:00")
(4 行)

demo=# SELECT * FROM schedule 
          WHERE reservation_time @> '2017-04-16 15:30:00'::timestamp;

 schedule_id |  room_name  |               reservation_time
-------------+-------------+-----------------------------------------------
           8 | soudai_room | ["2017-04-16 14:30:00","2017-04-16 16:00:00")
(1 行)

demo=# SELECT * FROM schedule
         WHERE
    reservation_time && '[2017-04-16 11:45:00, 2017-04-16 12:10:00]'::tsrange;

 schedule_id |  room_name  |               reservation_time
-------------+-------------+-----------------------------------------------
           1 | soudai_room | ["2017-04-16 11:30:00","2017-04-16 12:00:00")
           4 | soudai_room | ["2017-04-16 12:00:00","2017-04-16 12:30:00")
(2 行)

しかしここで大きな課題として会議室は1つしかないので会議室の予約時間(reservation_time)が被ったらErrorになって欲しいですよね。 そこでお待たせしました排他制約の出番です。

EATE TABLE schedule
(
    schedule_id SERIAL PRIMARY KEY NOT NULL,
    room_name TEXT NOT NULL,
    reservation_time tsrange NOT NULL,
    EXCLUDE USING GIST (reservation_time WITH &&) ←排他制約を追加
);

demo=# SELECT * FROM schedule;
 schedule_id |  room_name  |               reservation_time
-------------+-------------+-----------------------------------------------
           1 | soudai_room | ["2017-04-16 11:30:00","2017-04-16 12:00:00")
           4 | soudai_room | ["2017-04-16 12:00:00","2017-04-16 12:30:00")
           5 | soudai_room | ("2017-04-16 12:30:00","2017-04-16 12:40:00")
           8 | soudai_room | ["2017-04-16 14:30:00","2017-04-16 16:00:00")
(4 行)

demo=# INSERT INTO schedule
  (room_name, reservation_time)
     VALUES
  ('soudai_room', '[2017-04-16 15:30, 2017-04-16 17:00)');
ERROR:  conflicting key value violates exclusion constraint "schedule_reservation_time_excl"
DETAIL:  Key (reservation_time)=(["2017-04-16 15:30:00","2017-04-16 17:00:00")) conflicts with existing key (reservation_time)=(["2017-04-16 14:30:00","2017-04-16 16:00:00")).

demo=# INSERT INTO schedule
 (room_name, reservation_time)
  VALUES
   ('soudai_room', '[2017-04-16 17:30, 2017-04-16 18:00)');
INSERT 0 1

ちゃんと弾いてくれてますね! これでUPDATEの設計にしてロックがアプリケーションパフォーマンスのボトルネックになったり、INSERTで表現する際のファントムーリード起因のbugとかを防ぐ事が出来ます。

まとめ

RDBに入っているデータは常に正しいといえる状態は精神衛生上もアプリケーションのロジック的にも平和なので排他制約使えるシーンは色々とあるな!と考えています。 とは言え僕も今回知ったばかりでまだまだ実務で使っていないので面白い使い方を模索したいと思います。

—- 2017/04/16 追記 —–

PostgreSQLで排他制約がめっちゃ便利!! - そーだいなるらくがき帳

CREATE EXTENSION btree_gist; して、EXCLUDEに (room_name WITH =, reservation_time ...) ってすると、同一room_name内で時刻が重複してたらはじくとかもできますよ!(room_nameが違えば通る)

2017/04/16 20:31
b.hatena.ne.jp

めっちゃ便利!!!!!

—- 2017/04/16 追記 2 —–

PostgreSQLで排他制約がめっちゃ便利!! - そーだいなるらくがき帳

単純な幾何学情報はともかく、地理的位置情報はPostGISも入れて扱うべきだというのはあまり知られていないのだろうか。

2017/04/16 22:05
b.hatena.ne.jp

みんなPostGISめっちゃ便利なのに知らない可能性あるのかって思ったので合わせて紹介します。

PostGISを使ってみよう | Let's Postgres

農研機構最高だぜ!(久々の定期ポスト

雑に説明するとPostGISは良い感じに幾何学的なことを出来るようにするPostgreSQLの拡張ライブラリの一つです。 例えば地球は球では無く楕円なので緯度経度から距離を計算する時に近似値計算ではズレが生じます。 なのでそこを正確に計算するためにはアレをコレしてと大変なのですがそこを良きに計らってくれたりします。 つまり正確な地図を表現したり、例えば町田は東京都に含まれるのか?みたいな複雑な形の確認も表現出来るようになります。 というわけで正確な地図を表現したい時にPostgreSQLPostGISは最強なのでオススメです。 あと皆さんも知ってると思いますがMySQL 5.7からInnoDBでもGIS型をサポートしてます。 こちらは機能的にはまだまだPostGISほどでは無いものの、光る部分も沢山あるので将来楽しみな機能です。 ということで地図などで座標を扱う時にPostgreSQLめっちゃ便利ですのでこちらも合わせて覚えてください!!

Mackerel Drinkup #4 Tokyoでサービスメトリック便利ってLTしました

先日Mackerel Drinkup #4 Tokyoが開催されました。

mackerelio.connpass.com

サービスメトリックなので実際はPluginじゃないんだけどPlugin作るつもり始めたら落とし所がPluginじゃなかったっていう背景があるので許してください。
何かの参考になればと思うのでサンプルとしてコードも置いておきます。

speakerdeck.com


github.com

ドリンクアップには色んな方に来ていただけて交流できたので最高に楽しかったです!
次回もLTをするかはわからないのですがネタは色々思いついたので頑張っていきたいです。

とりあえずこれ使うとクエリの実行回数を明確に可視化できる!みたいな事思ったけどそもそもpg_stat_statementsのプラグイン書けって話ですね。
みたいな事を次回までにやりたいなーって思ってます。
定期的に開催していくのでMackerelユーザの人もそうでない人も是非遊びにきてください!

敢えてアウェーで戦う事に意味があるって話

YAPC::Kansaiで id:takesako さんからすごくいい話を聞いたのでみんなにおすそ分け。

yapcjapan.org

スピーカー控室。
多分10:00くらいの1時間、みんなセッションを見に行ってて竹迫さんと二人っきりになりました。

発端

僕はSECCONの人として竹迫さんの事を一方的に知っていて今回のゲストスピーカーのしかも基調講演ですし「うぉー二人っきりだ!どうしよ!!」ってドキドキの中、同郷をネタに話かけました。すると竹迫さんは柔らかく応えてくれました!
その中で色々と地元トークをしてる中で僕が「僕は今回東京に引っ越して右も左もわからないんですよね。今日もPerlのイベントで僕は普段からPerl書かないし、すごくアウェー感あります。」とボヤきました。そこで竹迫さんは「それめっちゃチャンスだよ!やったじゃん!!」とすかさず返してくれました。それからアウェーに敢えて飛び込みことについて教えていただきました。

アウェーで戦うということ

竹迫さんはアウェー、つまり自分が普段活動していないコミュニティに飛び込むことは沢山のメリットがあると教えていただきました。

  • メリット
    • 自分が普段いないコミュニティこそ新しい出会いの場所
    • 自分が普段通りの事をアウトプットしてもアウェーでは新しい風になる
    • 新しい場所に行くことは自分の成長に大きく関わる

みたいな感じの内容でした。僕は普段データベースのコミュニティにいてそこでアウトプットすると共感も得やすいし、コンテクストを共有する必要もなく本題に入れるので非常に楽で心地良いです。でもそこで「若者にデータベースに興味を持ってもらいたい!」って問題提起しても問題は改善しません。設計出来る人たちに設計の話をしても「うんうん、そーだいさんは正論マンだからな」ってyoku0825さんに諭されたりするわけです。だけどアウェーに飛び込めば新しい人達にデータベースを興味持ってもらえるかもしれないし、仕事で僕達DBAが苦労するような設計を減らすことができる可能性が増えます。そう考えると「アウェーに飛び込む」ということは何か伝えたいことがあるならばより大切にしないといけないことだと強く感じました。

セールスエンジニアとして

僕は今、はてなのMackerelチームでセールスエンジニアをしています。はてなのセールスエンジニアの定義は無限に広く、明確には定まっていません。ですので僕はエバンジェリストのような活動もダイレクトセールスもする必要があると思っています。そこでMackerelを知ってもらうためにこそ、はてなのネームバリューが届かないような世界に飛び込むことがとても大切だなと思ったりしました。

まとめ

僕はありがたいことに今回のYAPC::Kansaiでベストトーク賞をいただきました。これはあの時、竹迫さんに背中を押していただいたことがとても大きな要因になっています。あそこで「そうか今チャンスなんだから精一杯やろう」と気持ちを切り替えれなかったら、この結果になっていなかったと思います。そう考えると気持ちの持ち方というのはとても大切です。皆さんも「あぁここは苦手な分野だな…」「自分の住む世界と違うな」と感じたときこそチャンスだと思えればそれは本当にチャンスになると思いますし、それを掴めば大きなブレイクスルーになると思いますので是非とも色んな世界に飛び出してほしいです。




ということで今年は色んなコミュニティに飛び込みたいと思いますので是非色々お誘いください。
僕に出来ることなら精一杯お手伝いさせていただきます。

叱ってくれる人は大事だよねって話

会社のランチ中に色んな人と話が聞けて楽しいです。

その中で叱ってくれる人って大事だよねって話題が出たのでメモとして残しておきます。

歳を取ると面倒事を避けてしまう

賢い人ほどその傾向が強いと思います。 というか年関係なく若い人でも賢い人はスッと面倒事を避けますよね。 人生は有限なので当然です。 でその面倒事の一つに「他人に叱る」ってのがありますよね。 叱る行為が原因で相手に嫌な思いをさせることもありますし、それ起因でお互い感情的になっても得しないし、相手が怒ったりしたらそれこそ時間の無駄じゃんって事で争いを避けるのは必然です。 なので歳を取るとなかなか他人を叱るって行為をしなくなったりしませんか?

そもそも怒ると叱るの違い

  • 怒る = 感情を外に爆発させること
  • 叱る = 相手によりよい方法を教示すること

叱るだとまぁ部下だったり後輩だったり自分の子供だったりで叱ることもあると思います。 この叱るべきところで怒る人はまぁ駄目だなって思います。 とはいえ、感情的にならずにかつ相手に適切に叱るのは至難の業です。 なので最初は良かれと思って叱っててもなかなかコストが合わず叱らなくなるのではないでしょうか。

じゃあどんな場面で叱ってくれる人が必要なのか

ここで怒ってくれる人って言うのは友人を指します。 友人と知人の違いは人それぞれですが一部の意見では

  • 友人=本音で話する人
  • 知人=建前で話する人

と言われてました。 僕も大体そんな感じの認識です。 で本音で話出来る中でも自分を叱ってくれる人は超貴重です。 なぜならそれが無いと自分の常識が非常識であることに気付け無いからです。 特に社会人になると交流関係が固定化されるのが一般的だと思います。 そうなるとその会社の文化では常識のことが世間一般では非常識なこともあり得ます。 または単なる無知で損をするケースもあります。 その時に率直に叱ってくれる友人はとてもとても貴重な存在です。

でどうしてそんな事言いだした?

そんな本音で語れ、叱ってくれる友人が沢山居たとしましょう。 そこに利害関係が生まれたり、育ってきた環境の違いだったり、家族が出来たなどのステージの違いだったりで意外とアクティブな交流がある友人は減っていきます。 僕も若かりし頃から(現在進行系)色んな人に御指導御鞭撻頂いてきたのですが会わなくなって久しい恩人が増えました。 だからこそ、今こそそういう友人を大切にしたいなって思った次第です。

今のつながりだけでいいの?

新しいつながりも欲しいですよね。 だから僕は自分が友人だと思ってる人には積極的に本音でトークしたいと思いますし、場合によっては叱る側に立つことも大事だなって思いました。 また僕の場合、お酒が入るとめんどくさい系男子になってしまうのですがそういった時に叱ってくれる人を大募集中です。

おまけ

完全に表参道のOLがランチ中に言ってたセリフのパクリですが「相手を叱る(Disる)ときと下ネタを言うときはオシャレ大事」です。 オシャレな一言で場を和ませながらも鋭い発言。 周囲から信頼される事間違いなしです。 僕も相手を気遣いながらもお洒落な一言を出せるように日々精進したいと思います。

まぁなんていうか縁って大事ですね。