私の知らない推し本をあなたは知っている

なんのこっちゃとなったかた、京アジャ・ビブリオバトルに参加しませんか?というお誘いでございます。 詳細は↓

connpass.com

ビブリオバトルとはなんぞや?という方もいると思う。 ぼく自身も名前をとあるライトノベルで知り、図書館にいった際にたまたま同時期に目にしたため覚えていたくらいだ。 ジャンルとしては非常にマイナーなものだと思う、読書好きな方などにとっては噴飯モノかも知れないが。 (ビブリオバトルというものを知るきっかけになったライトノベルがこちら↓)

とまれ、名前は知っているがどんなものかわからない…connpassみてるとどうやらROM専でもいいらしいということで参加してきた。 すでに過去何回かされているらしいが知名度が低いので今回京アジャとタイアップ?協力のもとビブリオバトルを開催した、という経緯のよう。

ビブリオバトルの公式サイトがあってこのレギュレーションに基本従っているのだそう。

www.bibliobattle.jp

結論:

ビブリオバトルめっちゃ楽しい。 これは定期的にやっていきたくなる面白さがある。

ビブリオバトル推し本紹介

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

生活する地域や国、人種などなどコンテキストの違いはどうしたって存在していてそれを理解するためにどうするのか? ひいてはそれが他人を評価することに繋がるという点で紹介された推し本。

元々気になっていていつか読む本リストには登録されていたが優先順位が後回しになっていたので思い切ってその場でポチッとな!した。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

今年読んだベスト推し本と言われて思いついたのがこれだった。 次点で「リモートチームでうまくいく」を上げるつもりだったがこれによって自分の中の考え方や価値観が大きく変わったと思っているので上げさせてもらった。 あとはてなブログに書いたらぷち炎上したといったらその場でブログを公開されて公開処刑されたうえでコメントまで表示されてうわああああああってなった。 うまく本の魅力が伝えられなかった(元々ROM専のつもりだった)ので次回があればその辺「なにがよいと感じたか」「どうしてそう感じたのか」あたりを理路整然と伝えられるようになりたい。 この辺は発表者とかの場数、経験値が不足しているように感じたのでやっていき。

ぷしゅ よなよなエールがお世話になります

ぷしゅ よなよなエールがお世話になります

コンビニやスーパーでも見かけることが多いので知ってる人もいると思うが有名なよなよなエールのお話し。 2000年代初頭の地ビールブームからよなよなエールが世に出るまでに経験してきたチームビルディングのお話しがメイン。 ぼくたちとは異業種ながら抱えている問題や解決していく手法が興味をそそられる。

なお今回のビブリオバトルのチャンプ本でもある。

ユースケース駆動開発実践ガイド

ユースケース駆動開発実践ガイド

少々古い本ではある、という前置きから始まったが個人的に非常に気になっている本。 良いお値段がする本ながら「DDDやOOPなどで最初の取っ掛かりで詰まったときの助けとなる1冊」という言葉に心が惹かれた。 設計やコーディングはやはり古い書籍のため若干のレガシーさは否めないそうだが、それまでの思想的な部分などは今でも最前線で活きるレベルの良さらしいので気になっている。

実際にいま会社で読書会をしているとして紹介された推し本。 ライティングやカメラが主体になりがちな初心者向けUnity本においてゲームを作るというのはどういうことか?が書かれていて非常に良い、とのこと。

なお最新版はこちら

なによりも驚いたのは実際にこの推し本を読んで開発したアプリを紹介されたこと。 やっていきの精神がすごい!

一時期すごいWeb界隈などで話題になったDeepLearning本。 ノンプログラマーがゼロから作ることを目指して書かれた本…だそうだがノンプログラマーがこれ読んでDeepLearningを学ぶのはかなりハードルが高いんじゃないか?とのこと、デスヨネー。 行列や微分積分などの高等数学を思い出す必要はあるが機械学習とはなんぞや?を手元にあるPCで基礎から学ぶことが出来る1冊とのこと。 個人的にも気にはなってたけど「でもどうせ難しいのでしょう?」と斜に構えていたがそうでもないらしいので購入予定。

問題解決のための高速思考ツール

問題解決のための高速思考ツール

こちらも古い本ではあるがポストイットを使ってFOGに物事を分割して問題を本当に意味あるものへ分割していく手法を学べる…推し本。 個人的に今日紹介されたなかでどれがベストブックか選べと言われたら非常に悩ましいがこの本をぼくは推す。 それくらい気になった1冊、残念ながら昔の本であり在庫も少ないらしい。

自律神経どこでもリセット!  ずぼらヨガ

自律神経どこでもリセット! ずぼらヨガ

実はぼくも持っていて毎朝ではないが出来るだけやるように心がけている推し本。 Twitterで一時期すごい話題になったので画像をみれば「あーこれか!」となるひとも多いと思う。 ヨガというよりはストレッチの紹介が主にされているが徐々にこのストレッチが最終的にこのヨガのポーズに繋がる…みたいな話しがあったり ストレッチやヨガってそんなに頑張らなくてもいいんだぞ!みたいなゆるい雰囲気を出しているので継続しやすい感じがGood。 気分転換や眠気覚ましによいらしい。

場外乱闘編:

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

つい最近「人類と小麦」みたいな画像まとめがTwitterで上げられていたので紹介するのをやめたというもの。 個人的には読み物として読んでみたい、面白そう。

togetter.com

℃りけい。 コミック 1-7巻セット (ヤングジャンプコミックス)

℃りけい。 コミック 1-7巻セット (ヤングジャンプコミックス)

内容はいわゆる日常ものらしいがかなり濃い理系ネタが笑いどころに上げられているらしく中々チャレンジングな漫画。 あまり知っているひとがいないらしいがもっと広まってほしいとのことで紹介、なお完結済みらしい。

エラスティックリーダーシップがかぶったら紹介しようと思っていたやつ。 漫画紹介していいんだったらぼくはこれ紹介するつもりでしたって言おうとしたらブルージャイアント面白いよね!と先に言われてしまいくやしー!!!ってなったとかならなかったとか。 題材がジャズなんだけどもとにかく中弛みすることが本当にない、素晴らしい漫画。 マンガ大賞は絶対こっちのほうが受賞すべきだったとキモオタぶりを遺憾なく発揮しておいた。

インベスターZ(1)

インベスターZ(1)

妹にブルージャイアントをオススメしたんですよ、という会話の流れから子供に株のことを覚えるのにいい教材として読ませているらしいと紹介。 ネタ的なものはいくつかネット上でバズったので知っているが実はきちんと読んでない。 今度読んでみたいと思います。

まとめ:

ビブリオバトルは名前しか知らない、よくわからんイベント」、知り合いも id:daiksy さんしか知らないという状況だったが非常に楽しめた。 もともとROM専でみんなの発表を聞くだけにしようと思っていたが「俺の推し本はこれだ!」というアツい思いが溢れてしまった結果2番手で発表することになっていた。 どうしてこうなった…感が否めないが逆にそれが良かったのかもしれない。

ビブリオバトル終了後の雑談でも「王様達のヴァイキングと響けユーフォニアム!を読むとなんかこのままじゃダメだ!ってなってやっていきの精神が芽生える」といったところ笑いが起こったけどぼくのやる気バロメータが枯渇したときのカンフル剤は割りとマジで王様達のヴァイキングユーフォニアムだったりします。

なんかこう「このままじゃダメだ、もっとうまくならないと!!!」みたいな焦燥感にかられて積みタスクや積ん読消化する意欲がモリモリ湧いてくるんですよね。

とまあこんな感じでビブリオバトルというか単に「俺の好きな推し本を喰らえ!!!」というアツい思いを投げたり投げられたりという感ではあったのですが 自分が興味を持たない、あるいは知ることが難しそうな推し本がいくつもあって楽しいだけじゃない、非常に有益な時間を過ごせました。

今回の件で積ん読がまたしても増えてしまったので次回ビブリオバトルに参加する際に「これが俺の今回の推し本だ!」って言えるように積ん読消化と新たな推し本を探していこうな!って気持ちになりました。

反省点としては推し本紹介するときにアフィリエイトリンクを渡しておくとお小遣いがチャリンチャリンするのでいいというのと、 紹介する推し本の紹介の仕方が下手過ぎた(元々説明が苦手)ので次回は推し本を軽くでいいのでパラパラ読んでおくのと「どこがいい」のかを簡潔に伝えられるよう少しトーク内容を考えたほうがいいかもしれない。

やっていくぞ!

2017年上半期に買ってよかったもの

お題:

忘れる前に今年の上半期に買って良かったものをリストアップ。 転職やらなんやらでいろいろと動きが例年に比べても多かった上半期だと思う。

よかったものリスト:

  • 無線
  • リモコン付き
  • ランニングやジョギングしても簡単に外れない

という上記の3つの条件を満たしてくれたのが↑のイヤフォン。 元々は以前に紹介したが #rebuildfm で紹介されていた IE20 を愛用していたが以下の問題点のため乗り換え先を探していた。

  • よく混線する
  • ジョギング中に耳から外れやすい(走らなければそんなに酷くない)
  • 防水でない
  • まれに充電しているとリモコン部分が異様な熱さになっていることがあった
    • 1度それで煙が出た、さすがにそれは捨てたが。
  • 壊れた(恐らくリモコン部分に汗がついてそれで中の部品が通電してショートしたっぽい)

最後の壊れた、が致命的で仕方なく元々のiPhoneに付属していたイヤフォンを使ったり、有線であまり最近使っていなかったものなどいろいろ試したが メインがジョギング中に音楽を聞くため、だったため有線だとどうしても鬱陶しい気持ちになってしまうことがありIE20の後継になるものを探していたら ちょうどいい感じのものがあったので購入。

いまのところ概ね満足している。 ただ不満がないわけでもない。

  • 本体がスリープ状態、接続が切れている状態でリモコンから再生を押すと本の数秒だが本体のスピーカーで再生されてしまう
  • 購入当初Bluetoothのペアリングが良くなかったのかジジジというノイズが片側のイヤフォンから鳴っていた、しかも購入初日から。
    • 問い合わせフォームから報告をしたところ完全にバッテリーが0にする、もう一度ペアリングする、完全に充電しきってから再度試すなどのいくつかの方法を教えてもらい試したところ、問題は解決した。ただたまにノイズが鳴ることがあるのでそのときはだいたいペアリングし直すと直る。
  • バッテリーがだいたい6時間くらいぶっ通しで聞いてるとなくなる
    • これはIE20もそうだったがこのサイズにしてはかなり頑張ってると思うので若干仕方ないと思ってる。
    • ただ仕事中にpodcastを聞くときにも使うのでやはり実測8時間持ってくれると助かる

自宅のオフィスデスクとオフィスチェアになにも敷かずにいたらフローリングに傷がついてしまったので(元からすこし傷がついてはいた)カーペットを買うかタイルマットを買うか悩んだ結果タイルマットを購入。 緑の濃淡のタイルマットで市松模様にしたらちょっとお洒落感出て家族からも好評。 ただ部屋中に敷き詰めるには枚数がかなり必要だということが判明、次に引っ越しする際には荷物搬入前に敷き詰める作業をしないといけないなと思った。 あとからやるとクッソ大変そう。


iPad Pro 12.9incをいれるためのケースを探していろいろ試した結果、これに行き着いた。

こちらも買って試したのだけどきちんとサイドポケットというのかサブポケットというのか不明だがApple Pencilを入れていたら傾けた際に中からこぼれ落ちてしまったので代わりを探していたら要件を全て満たすものが買えた。

個人的に2017年上半期のベストバイだと思う。 ジッパーで前のポケットにいろいろ入れられるし、背面にもジッパー形式のポケットがあり大容量。 落ち着いた色味の青なので主張もうるさくなく非常に満足している。


元々買おうとは思っていたが値段から二の足を踏んでいたが意を決して購入。 エアフロスが思いの外、ゴミを取ってくれてビックリしている。 電動歯ブラシのほうはしっかり汚れを落としてくれている感じでよい、ただいろんなモードがあるが基本ホワイトかクリーンしか使ってないので無駄感ある。


以上。 転職したばかりでお金ないはずなのに気づけばそこそこお金使っててこれだからお金が貯まらないんだって思った。

【京都開催 feat.はてな】Cookpad Tech Kitchen #11

参加してきた。 実は東京にいたときに何度もCookpadさん主体のイベントに参加したいと思いながらスケジュールの問題などで実は一度も参加できておらず 今回始めて京都で開催ということもありかなり勢い込んで参加してきた。

cookpad.connpass.com

結論からいうと非常によいイベントだったと思う。 その中でもQ&Aセッションが個人的に非常によかったと思っている。

各セッションの内容ももちろん素晴らしいものだったのだけどぼくが今回の参加で一番評価したのはこのQ&Aセッションだ。 事前にポストイットを配布し、セッション聴講中に気になったことを書き出してあとでまとめて読み上げる、というものなのだがいわゆる「会場の雰囲気で質問しにくい」問題に対してかなりよい施策だと感じた。

セッション自体の進行もスムーズに進められるし、聴講者側としても「こんな質問してもいいのかな?」と思いつつ書いてポストイット貼るだけなら心理的ハードルも低くなって活発な議論や質問が出る効果が見込めそうで非常に気に入った。 今度会社でも真似してみようと思っている。

どれも魅力的なセッションではあったのだけど今回ぜひとも聞いてみたいと思って実は参加したという経緯がある。 そのセッションは「巨大アプリにおける新規開発とチームビルディング」だ。

今の会社に入っておおよそ10月で5ヶ月目に突入したのだけどその短期間でもチームの問題や組織の問題がでてきており、これをなんとか改善したいなと思っていた。 そのモチベーションはもちろん自分が楽をしたいから、つらい環境で働きたくないからというものなんだけどCookpadではどうやってそれらの問題を克服していってるのか、文化を築いていくうえで大事なことはなにか?をせめて一端でも学べればと思って参加を決定したところが大きい。

結果からいうと参加して非常に良かったと思っている。 一番聞きたかったセッションも聞けたしQ&Aセッションでは貼り出した2つの意見がどちらも読み上げてもらえて嬉しかったし、非常に学びがあった。

セッション時にこれは重要そう、あるいは心に響いたぞ!と思ったことをkobitoを使ってメモしていたのだけど何故かスリープした際にデータがクラッシュしたのか書いていたメモ書きが消えていた。 割りと長い時間メモしており(都度ファイルの保存もしていたはず)消えてしまうというのがちょっと信じられなかったがイベントで公開されたスライドは全て後日公開されるそうなのでそのとき改めてもう一度読もうと思っている。

そして今回一番驚いた点がイベントで出された料理の数々だろう。

料理すげー!さすがクックパッドや。

撮る前に食べてしまった

いつもこういう懇親会などで出される料理というのは出前寿司かピザであることが多いと思う。 もちろんそれらに不満があるわけでは全く無いのだけど今回のイベントでは料理を作られた方がいらして料理の説明やどう食べると美味しいのかなどのレクチャーをイベント開始前にしていただいて大変いつもと違う空気感があって楽しかった。 そしていただいた料理はどれもこれも大変美味しくてさすが料理のサービスを運営している企業さんはこだわり方が違うなと改めて実感した。

本来なら懇親会までいてぜひとも ryo_katsuma さんにマネジメントやチームビルディング関連の真面目な質問したり yoshiori さんに「なんで赤髪なんですか?」という雑談レベルの質問をしたいと思っていたのだけど当日の朝からどうにも体調が芳しくなく大変残念ながらQ&Aセッションが終わると同時に退席させてもらいました。

めちゃくちゃもったいなくてすごい凹む。 「今回のイベント次第ではあるが今後も関西でCookpadのイベントをやっていきたい」というようなことを仰っていたので是非ともまたイベントが開催されることを期待したいですね。 文化の違いなのか、地域性なのかわからないけども関西のイベントと関東のイベントは少しセッションで話す対象が違っていることがあると感じていて 今回のCookpadさん側の発表がなかなか新鮮な気持ちで聞けたのが非常にやっていき感が高揚して気持ちが良かったので大変だとは思いますが是非またできれば京都に来ていただきたいですね!

以上、参加レポートでした!

サーバーサイドを開発するモチベーションはどこにあるの?

発端:

先日、会社の同僚(フロントエンド開発者)に「サーバーサイドの開発を行うモチベーションってどのあたりにあるんですか?」と聞かれたがうまく答えられなかったので一晩寝てから改めて考え直してみた

概要:

あまり意識したことはなかったのだけどそういえば「そういったことを考えたことはないな」と思ったのでそのときに思いついたことを同僚には伝えた。

伝えた内容は以下のようなものになる。

  • 設計が綺麗に出来たときのシステマチックな美しさ
  • コードの美しさ
  • 「こんなこともあろうかと!」が出来たときの達成感

ただこれらは自分で言っておきながらなんだがいまいちしっくり来ていないと感じていた。 どれも別にサーバーサイドでなくても出来る内容だし、帰ってから「(´ε`;)ウーン…」となったのでとりあえず寝て起きたときに覚えていればそのとき考えよう、ということで寝た。

このときの心境は「起きたときに気になっていれば「考える価値」のある疑問だろうし、覚えてなければ然程気にならない疑問だろう」と思ったのが1点。

当日、最近では珍しく寝付きが悪い上に、朝早く目が覚めてしまったので眠かったのが1点。

そしてこれが超重要なんだけど翌日の朝一で劇場版響け!ユーフォニアムを見に行く予定だったのでさっさと寝ないと!って感じだったからだ。

ちなみに先程映画は観終わった。 端的に言って、響け!ユーフォニアムの映画は最高だった。 このブログは映画をみたあとで以前から気になっていたカフェでお昼を食べて食後のフレーバーカプチーノを飲みながら書いている(ドヤァ

eonet.jp

読書カフェに良さげなところ見つけたかも。

ナスと挽肉のキッシュ

フレーバーカプチーノ頼んだら予想もしないものが出てきたw

ユーフォニアムの感想はまた別のブログ記事として書こうと思ってる、めっちゃ「やっていき感」が出るのでマジおすすめ。 でもTV版の1期と2期みてからでないと端折られているストーリーがわからなくて十全には楽しめないかも。 TV版みて面白かったと感じていた人にとっては非常によい劇場版になっていると思う。 ぼくは原作も読んだしアニメも何度も見返すくらいには好きなので非常に楽しめた。

閑話休題

さておき、朝になってもこの疑問は頭にしっかり残っていた。 なのでもうちょっと本腰を入れて考えようと思ったのでブログに書きながら整理をしている。

そんな書きながら頭の中に浮かんだワードや考えを整理しているのでかなり支離滅裂というかむちゃくちゃな流れになっているんじゃないかと思うが許していただきたい。

最初に結論

そんなこんなでいろいろ考えたのだけどぼくの中で「サーバーサイドをやっていく!」というモチベーションはあまりないのではないか?というのがぼくの中での結論だと思っている。 少なくとも現時点ではこれが一番現実に即した答えに近いのではないかと思っている。

結論に至った経緯

ぼく自身はサーバーサイドが好きだし、これからも開発していくつもりだ。 だけどそれは別にサーバーサイドに固執しているわけではないように思う。

まず「自分が作りたいサービスを作る」がまず大前提としてあって、その表現方法がたまたまぼくの場合はサーバーサイドの開発であることが多いということなんじゃないかな。

なので「ゲームが作りたい!」ってなったらSwiftやAndroid触るし、フロントエンドでこれを表現したい!ってなったらReactやVue.js、Angularなんかも手を出すんじゃないかなーと。 ただその中で一番自分が得意なのがサーバーサイド開発で、それで表現することを楽しんでいるだけでモチベーションそのものはあまりないように思う。

その他に考えられる影響としては、ぼくが「インターネットが大好き」というのがあると思っている。 なのでインターネットを介したサービスを作りたいと思うことが多いのではないかな。

これは間違いなのかもしれないがサーバーサイドは妄想できる幅が恐らくフロントエンドよりも広いのではないかと思ってるところはあるかもしれない。 フロントエンドは書いたものがすぐさま画面に反映される。 逆にいうと妄想できる余地が少ない、というように感じているんじゃないかなと思う。

これはぼく自身のJSの理解力が低いからそう思ってるだけでJSの表現力は非常に広いと思う、だがその想像出来る範囲が狭いためいまいち妄想の余地が少なくなってしまっている、という可能性が大いに有り得ると思っている。 というか恐らくそうだろう。

かなりの期間JSに苦手意識があったことも手伝ってJSから身を潜めていたのだけど、最近のJSの書き方や思想、新しいAPIなんかはワクワクするものはある、と感じている。 ただじゃあそれを使ってなにかを実装したい!という欲求はサーバーサイドに比べて圧倒的に少ないのがぼくの実情である。

その点、サーバーサイドは「ここの部分をS3にして普段はキャッシュを参照させる」「ここの部分はスケールしやすいように設計をして必要なときだけこの部分に更新をかける」などの妄想できる範囲が具体的で、妄想が捗りやすくて楽しいと感じている。 この機能を実装したい、この設計に変更してパフォーマンスをあげたいなどなど。

サーバーサイド開発はとかく扱う範囲が広い。 コンピューターサイエンス的な合理性とシステマチックな解決策が用意されているのもぼくの好みに合っているのかも。

この辺はいくらでも理由が出るけど恐らく決定打ではない類の理由だと思う。 同僚に答えたのもここの部分での解答だったのでしっくり来なかったのかなと思う。

イシューではなく手段、メソッドで答えてしまったので芯を食った解答にならなかったのだと思う。

まとめのようななにか

なんだかだんだん脱線してきて支離滅裂になってきたが多分「妄想できる余地がある」「作りたいものがWebサービスに集中してる」というのがぼくの中でのモチベーションになってるんじゃないかなと思う。

なのでぼくの中で「サーバーサイド開発のモチベーションはほとんどない、ただ実現したいことがサーバーサイドで表現するのが一番面倒くさくない」というのが現段階での最適解になる。

この手の考えは変遷しがちなので半年後とかに改めて聞かれたら解答が変わっているかもしれない。 そのときはまたブログにでも書き出しておこうと思う。

Mackerel Drink Up #6 Osaka #mackerelio

mackerelio.connpass.com

Mackerel Drink Upに参加してきました。 あまり知り合いがいないので割りとドキドキしながら参加しました。

Drink Up系のイベントは初めてだったので普段の勉強会と違った流れに若干の戸惑いを覚えながらもいろんな話しが聞けて楽しかったです。 なによりいいと感じたのは「実際に使っていて困ったことを開発者に聞ける」という距離の近さが良かったですね。

以下良かったところ。

良かったところ

  • 開発者やMackerelチームに直接質問できる
  • 通常の勉強会のように片方が一方的に教える形でないため初心者が気軽に参加しやすい空気
  • Mackerel以外のことも聞けたり話してくれるので「Mackerelよくわかってないけど…」みたいな人でも質問しやすい
  • 会場のMotex Cafeが洒落乙、カフェというよりバーラウンジっぽい。オトナな雰囲気!
  • Mackerelメンバーが適度に会話に入ってくれたり、会話が途切れたときに話題を提供してくれたりして助かった
    • 話題の幅があまりないぼくのようなタイプの人間には非常にありがたいサポートでした
  • 景品をもらえた!
    • MackerelグラスやTシャツ、そしてなんと「Mackerelサーバ監視実践入門」にステッカーと「本当に無料のイベントなのか?」と思うくらいに大盤振る舞いだった
    • それを目的にしてほしくはないが嬉しいサプライズではあった、ジャンケンマスターが強すぎて景品のグラスもらえなかったのでステッカーをいただきました、感謝!
  • 著者陣にサインもらうために「Mackerelサーバ監視実践入門」持参したら来ていた著者の方々全員からサインもらえた、やったぜ!
    • 残りの著者がおよそ3人なんだけどロンドンにいるかたのサインはハードルが高すぎるというもっぱらの噂
  • id:papix さんのLTがわかりやすい&面白そうという空気感が伝わってきた
    • スライドが非常によくまとまっていてグラフアノテーションやPRのレビュー待ち、レビュー済みをMackerelで監視している話しが非常に興味をそそられた。
    • てっきりMackerelチームかと思ったらブログチームだった、HTTPS対応が大変そう。頑張っていただきたい。

追記:

寝ようと思ったらちょうどスライドあげたよ!って報告をTwitterで発見してしまったのでそのURLも貼っておく。

papix.hatenablog.com

いいところだけ書いて終わりでも良かったんだけど1フィードバックとして 次回また関西でDrinkUpなどのイベントするときの参考にしてよりよいイベントにして欲しいので 個人的に改善して欲しいなと感じたところを上げておく。

改善して欲しいところ:

  • 自分があまりMackerelを業務でガッツリ使っているエンジニアでなかったので最初にLTを持ってきてほしかった
    • どんなことが出来て、どういう機能があるかわかればDrinkUpのときの会話の糸口になったし、会話しやすくなったり質問しやすいように思う
  • 会場のビルの場所はわかったが目的の会場がどこかわからなくて何度もConnpass見てた、会場の階層とかは事前に知りたかったかも
    • 追記:Connpassのリマインダーメールにきちんと書いてました…orz
    • ぼくが早く着きすぎた問題もある、恐らくはてなのMackerelチームのかたが会場入りしたのとほぼ同じくらいの時間に着いてしまった
    • 京都からだと1本早めの電車に乗ると30分前とかに会場についてしまった、早めの電車でないと開場時間ギリギリになるというジレンマ
  • 次回は京都のはてなオフィスで開催してほしい
    • そのほうが移動が楽。あと当初何故関西でMackerelイベントを行うのにはてな京都本社じゃないのだろう?って思った、理由を聞けば納得した
  • Mackerelスタッフの紹介が欲しかった
    • せっかく「Mackerelサーバ監視実践入門」の著者がいるMackerelチームのメンバーがいるのだから簡単な自己紹介が欲しかった(サインもらうときにどなたに頼めばいいのかわからなかった)
  • サインもらうならサインペン用意しておかないといけない
    • 改善して欲しいというか戒めだがサイン本にするべく書籍は持ってきたがサインペンなくてご持参されたかたのご厚意でお借りした、大変助かった
    • 景品で書籍を手にされたかたが裏付けの部分にサインをもらっていた、次回から真似をする
      • 理由として裏付けの著者一覧が写ってるところにサインを貰ったほうがいいと思った、とのこと。なるほどー
  • もう1、2件LTの発表があると嬉しい
    • マイルストーンな話しでもいいし、Mackerelの紹介でもいい。とりあえずMackerelってなに?レベルの人向けになにかあるといい気がした

以上、感想終わり。

全体的にはよいイベントだったと思ってます、特にLTのスライドが非常にわかり見があって「なんかMackerel使ってこんなことできるんじゃないか?あんなことも出来る気がする!」みたいなやっていき感が出た。

MOTEXさん、会場をお貸しいただきありがとうございました! Mackerelチームの皆さん、本日はお疲れさまでした!&またの機会をお待ちしております。

今日の著者サインコンプリートした!

受託開発していて嫌なこと

自社サービス開発と受託開発の2つがあってどちらのほうが好きか?と聞かれたらぼくは間違いなく自社サービスを選ぶんですが 受託開発で何がそんなに嫌なのだろうか?と改めて考えたところ以下の点が死ぬほどクソで気に入らない、と考えているんだなと思い至りました。 他にも多分あるんだろうけど、自分の中ではかなりの部分がこれで占められているなと考えています。

「なにが受託開発を行っていて嫌なのか?」 「客先に対する無用な気遣いや遠慮が社内で行われること」

具体的にどういうことかというと「客先が休みじゃないから出社しよう」とか「客先の出社時間にあわせて出社しよう、ただし関係者だけな(自社の出社時間のほうが遅い)」とか「社内行事あってこの日仕事できないって言えないから仕事するフリをしよう」とかまあそういうアホみたいなクソいやつですね。

自社サービスだと残業だったり、早出しないといけないのは理由が明確で「そうせざるを得ない」理由があるわけです。 外的要因や理由によるブレや対応する必要があるのか?という疑問を挟む余地がないので「まあやるしかないよね」となって納得ができるので不満は(その部分では)ほとんど感じないわけです。

ところが納得できない理由でコントロールが効かないとそれ自体が不満で、結果として受託開発をしたくない、と考えるようになっていったのかなと思っています。

これを解決する方法自体は非常に簡単だとぼくは考えていて、それは「客先も含めて1つのチームとする」。 いわゆる客先を巻き込むというやつを行えば解決する問題だと思ってます。 客先がただのチームメンバーになってしまえば、そもそもその手の無用な気遣いをする必要やアホみたいな推測に基づく対応もしなくて良くなるわけでまあ少しはマシになってくれそうな気がしてます。

他にもいろいろ不満点はあるんですが、さほど致命的だと感じていないのでぼくの中ではこれが最大級のうんこだなって感じです。

意味不明な憶測と推測による不合理な理由による意味不明なルールがこの世から無くなってみんながハッピーになればいいのになっていつも思うんだけど世の中なかなかそうならなくてクソだなって思うのでどうしようもないクソから多少はマシなクソになるよう頑張っていきたいところ。

何がいいたいかというと自社サービスの開発がやりてえ。

信頼は仕事でしか得られない

副業先の人に「本業のチームがいまいち上手く回ってない感じがしてるんですけどなんでですかね?」みたいな話しを 1on1のようなものを開いてもらった際にこぼしたところ

「それはきみ、もしくはチームメンバーに対する信頼が築けていないからだ。そして信頼は仕事の中でしか生まれない」

というようなアドバイスをもらいました。

「うおお!なんか知らんがカッコいい!」となったんですが、この言葉が実はとある本の受け売りだということがその後、発覚しました。

そこで紹介してもらったのが以前ブログで感想を書いた「リモートチームでうまくいく」です。 元々気にはなっていたので即書店にいって購入、ついでに「納品をなくせばうまくいく」もあわせて購入しました。

その中で件の文脈が登場するのは 「飲みニケーション」で育むことが出来るのは「懇親」であって「信頼」ではない、というニュアンスでの登場の仕方をします。

もともとの話の流れとしては「リモートワークだと飲み会とか気軽に出来ないよね」という課題に対して 書籍内では「飲み会だけでは信頼関係は築けない。あと飲みニケーションに頼ったマネジメントは危険」と返しています。

これが実にぼくの中で得心がいって最近気に入っており、非常に良い言葉だと感じたのでタイトルに持ってきました。 実際にはそのままズバリな書き方はされていないので副業先の相談相手の言葉を選ぶセンスが良かったのだろうと思っています。

今ぼくが所属するチームではさまざまな課題が山積みになっています。 メンバーのことを人格的に嫌いというわけではないが、不信感や不満感をぼく自身が持っていて言語化出来ずに忸怩たる思いだったのですが これはつまり「ぼくがメンバーに対して信頼をしていない」ということなのだとわかりました。

確かに言われてみれば仕事上の関わりも薄く、技術的な話しや相談をすることも稀(プロダクト固有の知識や作法は別)だったり あまり件のメンバーが技術に対してポジティブというか積極的でなかったことなどから信頼をしていないのだと 改めて考え直してみたところ、実にしっくりときました。

今はまだメンバーとのこの信頼関係の改善は行えていないのですが、今の状態のままでいいとはぼく自身も考えていないので 少しづつ仕事を通して信頼関係を築いていこうと思っています。

相手が信頼しているかどうかはわからないですが、まずは自分が信頼関係を構築して信頼するところから始めようと思っています。

特にオチはないのでこれで終わりです。