2015年10月16日金曜日

@soudai1025がまほろば工房との想い出を語る

実は今日は最終出社日です。
@soudai1025、仕事辞めるってよ。」から2年と4ヶ月。
気がつけば早いもので株式会社 まほろば工房に来てそれだけの時間が過ぎました。
publicな場所で自分の職場を堂々と言える会社ってのは初めだったので今思うと良い転職だったなぁと思います。
そんなわけで感慨深いものがあるのでちょっと想い出語りします。

まほろばの想うところはいっぱいあるけど個人的に一番好きなのは

コミュニティ活動に対して積極的な支援があること


ですね。
僕はコミュニティが大好きだし、コミュニティに育ててもらったと思ってます。
そのコミュニティに対して会社が理解ある&支援があるってはもう仕事中にビール飲めるみたいな感覚です。
(ちなみに弊社は実際に仕事中にビール飲んでも問題無いです)
エンジニアの会社って言う会社はいっぱいあるとと思うけどまほろば工房は本当にエンジニアの会社です。
社長自体もJANOGの元会長だしNetWorkコミュニティのすごい人もいっぱいいます。
なので必然的にコミュニティ活動は重要な活動として支援してくれます。



このツイートとか社風をよく表していて例えばCROSS 2015は会社に交通費と宿泊費を出して貰いました。
ただ会社で行く場合は建前上、報告書とか必要です。
これは社長の方針として上手くネゴすることもスキルの一つと言うことかららしいです。
ちなみに出張報告書と言っても経費精算みたいなもんです。
JPUGの予算稟議の方が数倍厳しいです(それでも普通の会社の稟議より超緩いですが)
なので平日の勉強会参加は勿論、気軽に遠方の勉強会参加が出来るようになったのは本当に嬉しかったです。
更に凄い所は自分が「イベントやりたいけど金無いんで協賛オナシャス」に即答でスポンサーしてくれたこと。
実際に




の2回協賛してもらいました。
特に合同DB勉強会は





って事があったので本当にスポンサーしてもらってよかったと感謝しています。
コミュニティ活動をしたい、楽しみたいって人にとっては最高の環境だと思います。

あと好きなのは

裏福利厚生が充実してること


これは転職サイトとか会社ホームページからではわかんないですよね。
実際には





があります。
まぁでもエンジニアとしてやっぱ知りたいところは開発環境ですかね。



基本的に自由です。
Windowが多いですけどMac使ってる人もいます。
あと自分のノートPC持ち込んだりも出来ます。
実際に僕はキーボード(Realforce)やマウス(ロジクール)やモニタ(MITSUBISHI)を持ち込んでます。
そもそも会社でAmazon受け取りOKなので本などは会社に着くようにしてたりします。
ちなみに実際に使うことが多いのは


  • Linux(CentOSもUbuntuもあります)
  • PostgreSQL(僕の権限によりPGですがMySQLもあります)
  • PHP(フレームワークはFuelPHP使ってます)
  • ヤマハルータ(あとVyOS)
  • VM Wear(KVMとXenはちょろっとある)
  • Git(VCSはgitbucket)


ってな感じです。
僕はアプリケーションより下のレイヤーはまほろばに入って本当に鍛えられたと思います。
Linuxの基礎的な知識やカーネル周りの挙動は詳しい人が多いので勉強になります。
最近だとコンテナ化もやったりしました。
勿論デメリットもあります。



そうです、残念ながら篠崎愛はいないんです(´;ω;`)ブワッ

まぁ冗談はこれぐらいにして技術者として学ぶことが多い職場だと思います。
僕はちょいちょい社内ツールや会社ページのリプレースなんかで新しい技術を導入しました。
そういう技術選定権限の自由さは前職にはなかったので上から下まで学べたなと思います。

ということでエンジニアとして学ぶには良い会社だったと胸を張って言える会社です。

あと社会人、まほろばのチームの一員として。

僕はチーム最年少です。
入社時は20代でしたが今は30なので会社に20代がいません。
これはまほろばの課題だと思ってます。
僕が退社後、数名入社予定ですがみんな30代です。
技術要求度とかスキルマップ的に年齢層があがります。
そこはわかるのですが世代交代や技術継承も考えていかなきゃいけない課題です。
まだまだ暗中模索してる感の強いところなので今後パワフルな若手とか入ると期待してます。

メンバーの一員としてみたらみんな優しくて風通し良い会社です。
直属の上司は女性だったのですが本当に良くしていただいたと思います。
私の悪い癖で時々感情的に批判的な言動をする時があります。
そういう時も冷静に諭していただいて大人の対応とは何かを学ばせていただきました。
こういう精神的な成長がこの2年間で一番多かった気がします。
若い人が多いチームはそれはそれで面白いです。
ですが社会人として先輩から学ぶこともまだまだ多いなと感じました。
勿論、若い人から学ぶ事も沢山あります。
ですので「他者から学ぶ事に年齢は関係ない」です。
ですが孔子も論語で言ってますが年齢によって変わる思想もあると思います。
そういった人間的な意味でもまほろば工房は良いチームだなと思います。


ということで振り返った結果、本当に良い会社だったなぁの一言に尽きます。

ちなみに今後は一応方針は決まっています。
ですがまだ未定な所も多いのでしばらくは多分フリーでダラダラしてます。
元々昼は自宅で食べてたし家でもコードは書けるので生活環境は大きく変わりません。
なので暫くはTwitterに居るのは変わらないとは思いますw
でもこうやって会社でブログを更新することもなくなりますね...
(今思えばこのブログの大半は会社で更新されてるわけですが)
と最後は少しセンチメンタルな感じになりましたが今後もまほろば工房をよろしくお願いします。

ということで取り敢えず干し芋置いときます。

私は真に驚くべき欲しい物を見つけたが、この余白はそれを書くには狭すぎる


2015年10月12日月曜日

2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた

第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。
内容は前に書いたエントリーの


を元に発表してきました。
と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。
実際の資料は下記のとおりです。
当日はビデオ撮影があったのでそのうち動画が上がると思います。

第32回 PostgreSQL 勉強会まとめ ~ togetter ~




流石に2時間は疲れました。
内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。
前半はMySQLとPostgreSQLの方向性の違いをメインにしました。
後半はMySQLは僕が実際にハマった事などをメインにしました。
個人的にはRDBの選択は適材適所以上の答えは無いと思ってます。
MySQLの並列処理性能やレプリケーションはPostgresSQLには足りないものです。
PostgresSQLの方が素晴らしいではなく住み分けだよと伝えたつもりです。
資料だけだとMySQLのDis話がメインなのですれ違いが無いようにここで補足しておきます。
実際にもっと深く知りたい人はMyNA会やPostgreSQLカンファレンスに来てもらえたらと思います。
ということでPostgreSQL勉強会デビューの話しでした。

####追記####



マサカリ訂正をいくつかいただいたので追記します。
間違った知識広がったらいけませんし。

1. トランザクションレベルのSERIALIZABLEの挙動の誤記
SERIALIZABLEの読み取りロックはNOって書いてますけどYESが正しいです。
PostgreSQLもMySQLもSERIALIZABLEにするとロックを獲得すると他トランザクションのSELECTに対してもロック待ちさせます。
SERIALIZABLEについては触れなかったので当日は誰も気づいてなかったぽいですが間違いです。

2. MySQLのInnoDBはREPEATABLE READはファントムリードしない
PostgreSQLはするのでそういうもんだと思ってました。
デフォルトのREPEATABLE READが堅いということになります。
MySQLすごい!!

3. @yoku0825さんからの指摘事項がいっぱい



















つまり、みんな@yoku0825をフォローしよう。
(いつもアドバイスありがとうございます)

#スライドの中で話題にした本並べときます







2015年10月6日火曜日

問題にチャレンジしてもらうために必要な事を考えてみた

私は人が成長するときは


  • 行動した時(そしてその最中)
  • 結果を振り返った時(失敗、成功を問わず)


の2つだと考えてます。
その2つを得るには問題にチャレンジすることが非常に重要です。
つまりチームやメンバーが成長していくためには如何にチャレンジを繰り返せるかです。
しかし元も子もない話をすると私は「崖から落とされたら勝手に這い上がってくる」タイプです。
ですから成長方法は基本的に崖から落とされて真っ向から突き進んで失敗したり解決したりして強くなってきました。
この手法を個人的にはサイヤ人ブートキャンプと言っていて、死にかけて強くなるので高速に成長します
ただし、用法用量を守らないと死にます(精神または物理で)
ですので他の人に勧められる方法ではないなと悩んでいます。
そして不幸な事に地球人が崖から落ちてしまう事もあります。
そんな時、助ける術も必要だなぁと最近良く考えているので整理してみます。

まず@razonさんが仰るとおり



がすべてを表しています。
私には階段が思いつきません。
そもそもこのツイートを見て「なるほど、階段って手があるのか!」と目からウロコだったほどです。
実際にはエレベータだろうが階段だろうが「そもそも登らない」だろうが選択肢はN択です。
なのでバカ正直に真っ向から登る必要は無いのですが私は真っ向から登って登れてしまうので発想が貧弱なのです。
「人間は経験したことしか想像できない」ものです。
だからこそ、このアウトプットを元に新たなインプットに期待してます。


と前置きが長くなりましたが本題。

アジェンダは


  1. チャレンジする人のメンタルモデル
  2. チャレンジの手法について
  3. 実際にチャレンジしてもらうには


です。
では早速本題に入ります。

1. チャレンジする人のメンタルモデル

チャレンジャーな人は活発的な人が多いとかそういうのは関係ないです。
ここは単純に

チャレンジした結果、成功した体験がある

って事に集約されると思ってます。
これは幼少期からこれまでの間の成功体験を元に問題解決を計ります。
大切なのは

成功体験の内容でチャレンジの手法が決まる

というところです。
これは2.に繋がるのですが冒頭でも触れた「人間は経験したことしか想像できない」というところにも繋がります。
逆説的ですが成功体験が無い場合、チャレンジをするメリットもわかりませんし、手法もありません。
これは卵が先か鶏が先かの難しい問題も秘めています。

2. チャレンジの手法について

1.でも触れたとおり、成功体験が重要です。
真っ直ぐ登って登れた人はまずは登ろうとします。
周囲に階段を作って成功した人を知っていれば階段を作り始めるかもしれません。
具体的には私は素直な子?でしたから問題については実力行使(物理)で突き進んできました。
ですので現在もよく崖から落ちたら真っ直ぐ崖を登り始めます。
これがチームの場合、大抵多くの人が「私には無理だ」と呆れてついてこれません。
これも過去何度も経験しました。
また素上りした結果、落石などのアクシデントやヒューマンエラーなどで何度も死にかけました。
その結果、最近は

  • 流石に素上り危ないから命綱を持とう
  • 一人では限界があるからサポートメンバーを持とう

などの選択肢を覚えてきました。
これが問題解決のノウハウとよべる部分です。
ですがこのノウハウは基本的には問題に真っ向勝負志向の人です。
階段派などにはこのノウハウを共有してもなかなかマッチしません。
つまりノウハウを共有しても必ずもすべての人に有益とは限りません。
そしてチームは多様性を持つべきですし色んな人がいます。
ですので往々にして多くの人にとって有益なノウハウとなりません。
これでは周囲はなかなかチャレンジできません。
ですのでビスマルクの

愚者は経験に学び、賢者は歴史に学ぶ

が大事だと思います。
つまりは他人の成功体験を知る
しかしこれは好きな女性が相手ならまだしもどうでもいいおっさんの場合は苦痛です。
しかも自分と考え方の指向性が違えば自分のノウハウとして蓄積しない(共感できない)ため尚更です。
なので情報収集のスタイルも十人十色だと思います。
ここでは私の代表的な情報収集スタイルをご紹介します。

・本を読む

ありきたりですが確実に情報を収集できます。
多くの手法を学ぶには一番手っ取り早いかもしれません。
また新書で出てることが多くちょっとした時間で読むことができます。
ただしデメリットが2つあって一つは基本的に良い話しかありません
罠や泥臭い話は映えないのでカットされがちです。
それと大分話を盛ってあることも多いので鵜呑みにすると痛い目をみます
誰もが若かりし青春時代、ニーチェを読み、ユングを読み、痛い厨二病時代があった思います。
また意識高い新卒にありがちなビジネス書や自己啓発本に毒されて応用が利かない時代もあったと思います。
人それぞれですが偏ると何事も毒になるので要注意です。

・飲み会に行く

基本的におっさんは自分の成功体験の昔話を若者にしたがるものです。
なので飲み会にホイホイ付いて行けば自然とその話を聞くこともできるでしょう。
これは自分に近い立場の人ほど自分に近い経験なので情報として有益です。
また成功体験と言ってもそのプロセスの詳細も聞けるので本には無い罠や泥臭い話も聞けます
ただしこのデメリットは


  • おっさんは酔っ払うと話がループする
  • 同じような話を毎回する
  • 途中から説教になる


があります。
なのである程度一通り聞いてしまうとそれ以上の情報収集は難しいです。
このリスク回避は非常に難しいのですが下記の方法を取ると評価を上げるチャンスになります。



もし会社の飲み会がつまらないなぁと思うなら上司の話を話半分に聞きながらやってみてください。
酔っ払いのおっさんほど効果抜群です。
20~30分前に行ってた事をオウム返しするだけでも十分です。
するとおっさんも「君は見込みがあるなぁ!」など言い出すでしょう。
そうなると次回の飲み代も出してくれるはずです。
今度はいい飲み屋知ってますよ!!とか言ってちょっと普段行かないお高いお店行ったりして有効活用しましょう。
おっと話が脱線しました。
会社の飲み会だけでなくエンジニアの集まる勉強会や地域の会合などにも同様の効果があります。
こちらは会社よりもメンバーの流動性が高いので多くの話を聞くことが出来るでしょう。
こういう場を上手く活用すれば現場の生の声を沢山得ることが出来ると思います。


私の場合はこの2つがメインの軸です。
なので機会があれば皆様の成功体験を聞かせていただければと思います。
また情報収集についても「こんな方法もあるよ」というのがあれば是非教えていただければと思います。


3. 実際にチャレンジしてもらうには

1と2の結論として


  • 本人(またはチームに)成功体験がある
  • その成功体験にマッチした手法がある


この2つが重要だと言う結論になりました。
しかしもう一つ重要な要素があります。

適切な大きさの問題

であることです。
みなさんもチャレンジする側が成熟していないのに大きい問題にぶつかり挫折する。
そんなシーンを見たことがあるのではないでしょうか。
この適切な大きさの問題については@snagaさんに面白い記事を紹介してもらいました。



ここでは成功体験の有無や手法など関係なく

適切な問題が生まれれば自然と解決する人が生まれる

という話題が出てきます。
これは私も経験があります。
つまりこの2つをまとめると


  • チャレンジさせたい人には適切な問題を与える
  • 解決したい問題を適切な問題に細分化し再配布する


これが成長するマネージメントのコツなのでは無いかと思います。
そうなると1の成功体験の有無は関係ないように見えます。
しかしこれは「自ら適切な問題は見出したり細分化する際に必要」なことなのです。
なので多くの成功体験を持った方がセルフマネージメントに長けた人になるのです。
また2の多くの成功手法を知る人が適切なチームマネージメントを行える人になるのです。
もっと視野を広げれば「適切な問題を生み出せる」事が経営者やリーダーとして適正なのではないでしょうか。

ということで以上の事を踏まえた上で私は今、「適切な問題を生み出す」とは何なのか考えています。