自分のIDを変えた

suzan2goというIDでずっとやっていたんだけど、男なのにスーザン??みたいな疑問と自分で「スーザン2号です」みたいに名乗るのはずいなということに大変今更ながら気が付きまして、 suusan2go (すーさん2号)にした。

もともと何で suzan2go にしたかというと、

suzan部分は以下からできていて、

  • 大学院のとき、研究室でスーさんと呼ばれていた
  • 留学生が「スーさん」って「スーザン」みたいだね、面白いあだ名だ、みたいなことを言っていた

2go部分はうろ覚えだけど、以下のようなことをtwitterに登録するときに思い出したからな気がする。

  • 高校のとき同じ部活に鈴木がいて、二号みたいな弄られ方をした

このタイミングで ksuzuki とか、 kszk とかに変えてもよかったんだけど、どちらもGitHubで既に取られていたので断念しました。 余談ですが、 無難すぎるかなと避けていてた ksuzuki というID、会社の同僚から amatsuda みたいですねと言われた瞬間に、なんか悪くない気がしてきて自分って単純だなと思いました。取られていて残念。

ありがとう suzan2go。IDを変えられなかったサービスの中で生き続けてくれ。(はてなIDとかな!)

コーヒーアレルギーになったかも

この一ヶ月ほど、軽い頭痛と吐き気と目眩みたいなのに襲われる事が多い。

夏バテか脱水症状かなにかかと思ってたんだけど、コーヒーを飲んだ後に体調を崩すことが多いのに気がついて、会社のslackでそのことを呟いたところ「コーヒーアレルギーじゃないですか?」と言われた。

coffeemecca.jp

コーヒーアレルギー自体知らなくて、最初は冗談かと思って聞いていたんだけどどうやら本当にあるらしい。 遅延型(数時間〜数日で症状が現れる)というところも合致してて(夕方4時くらいに飲んでるとちょうど帰宅時間くらいに目眩とか吐き気がくる)、コーヒー原因説が濃厚になってきた・・・

昔からコーヒー飲み過ぎるとこういう症状が出ることは自覚してたんだけど、最近は一杯くらいでもこういう症状が出てるので何か体の閾値を超えてしまったのかもしれない。 (もしくはアイスコーヒーなのでガブガブ行けすぎてしまう・・・というのはあるかもしれない)

しばらくコーヒーは控えよう・・・

って奥さんに話したら、「病院に行きなさい」と言われました。 はい。

2017年上半期の振り返り

年始にはこんなことを書いていた suzan2go.hatenablog.com

やったことの振り返り

1〜3月

引き続き、新規サービスの立ち上げに関わっていた。正直結構しんどかったけど、一緒に仕事をしたエンジニアはみんな尊敬できる人たちだったし、とても良い経験になった。スピードも出しつつ、品質も落とさないよい開発が出来ていた気がする。 結果が芳しくなかったのはとても悔しい。

4〜6月

久しぶりに会社の創業時からある年季の入ったサービスに戻ってきた。久しぶりに触るコードはかなりレガシーに感じたが、入社時に見たときは追えなかったロジックが追えるようになっていたり、「ここはこうするべきでは?」みたいな思考が出来ていたので相当成長を感じた。 決済回りのコードを変更していて結構緊張感があったけど、致命的なバグは起こさずにそこそこ大きな機能を足せたのはよかった。

自画自賛になるけど、約1年半以上ぶりにサービスに携わってソースを読んでいる自分がチームの中では一番コードの流れを理解できている感があって、自分はコードを追う力は結構強いのかなって思った。

今年の抱負の進捗

社外の人に合う

これは割と出来てる。3月くらいからは少しずつイベントにもいっていたし、いくつかイベントにも登壇できた。 ただどちらもRailsではない。

speakerdeck.com speakerdeck.com

http://www.amazon.co.jp/exec/obidos/ASIN/4873116384/hatena-blog-22/

刺激を受けて基礎的なところを改めて勉強し始めたりした。

suzan2go.hatenablog.com

いまこれを読んでいる。

実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版

機械学習で何か作る

進捗だめです

変化

ブログを沢山書くようになった

完全にソフトスキルズの影響。ちゃんとアウトプットしていこうと思うようになった。

suzan2go.hatenablog.com

早く帰るようになった

4月以降、これは家庭の事情的なところも大きいんだけど、奥さんにメニエール病の症状が出てかなりつらそうだったので、できるだけ家事・子育ての負担がかからないようにしてた。 3月くらいまではかなり祭りな感じのプロジェクトにいたのでなかなか難しかったんだけど、4月以降は意識的に早く帰るようにした。 子育てが厳しいほど奥さんに目眩の症状が出ちゃうこともあったので、フレックスを利用して16:00に帰宅したり、午前中リモートのち午後休みにして家族のサポートに回った日も結構ある。柔軟な勤務体系がとれるとこういうときに有難い。

Golangに再入門した

一年前に挫折したんだけど再入門。他の言語を学ぶことで自分の幅が広がるなーという感想です。 suzan2go.hatenablog.com

メンターやった

新卒の子のメンターをやっていた。新卒といっても半年以上アルバイトで来ている子だったので、一から教えるという感じでもなかった。 毎週1on1をやって一定彼のためになる時間を提供出来たたという感覚はあるものの、後半ちょっとマンネリ化した感じは否めない。

suzan2go.hatenablog.com

Write Code EveryDay

4月下旬から毎日コード書いている f:id:suzan2go:20170713230343p:plain ただし結構privateなものもあったりするので、厳密にいうとやれてるとは言えないかもしれない・・・

体重

はい

下半期の抱負

機械学習やるぞ

腰を据えて本を読み、手を動かしていきたい

アプリリリースするぞ

こっそり react-native で家庭内日記アプリを作っている。APIGolangで書いている。 まだ expo 上で自分と奥さんにしか配信しかしてないので、ちゃんとApp Store とかに出していきたい。

隣の芝?

最近、某スタートアップの人たちとお話する機会があって、自分がミドルウェアに関してすごく表面的な知識しか持っていないことに気付かされてしまった。

自分は幾つかのサービスの立ち上げ経験もあるしRailsJavaScriptはかなり書いて来たほうだと思うし、テーブル設計・モデル設計もそれなりにやってきたつもりだ。

でも残念なことに?、どちらもめちゃくちゃアクセスがあるとか、大量のデータを使うとかそういう感じではなかったので、AWSやHerokuなどのマネージドなインフラを普通に使って困ることもなくここまで来てしまった。 要は、Railsの裏側で動いているミドルウェアについて表面的な知識しかもっていなくても何とかなってしまっていた。

ちょっと危機感を覚えてまずはちゃんとMySQLについて勉強し直そうと思い、高トラフィックなサービスの運用経験がある同僚に、どんな本を読んで勉強したかなどを教えてもらった。

いくつか既に持っていて、ちょっと読んだだけの本もあったので改めてちゃんと読もうと思う。 これとか。

実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版

隣の芝?

この話をしたときに、意外だったのはその同僚から「隣の芝じゃない?」と言われたこと。 要はミドルウェアはマネージドなところにおまかせでたいてい何とかなってしまうようになってきてるんだから、それはそこに任せてアプリケーション開発のスキルをためた方が良いんじゃないか、という意見だった。(その同僚は自分の持っているミドルウェアの知識なんてもう不要になってきている気がするとも言っていた)

確かにそういう面もあるのかもしれないけど、自分はそういった裏側をちゃんと理解しているかどうかが、何というかその人の地力になると最近は感じている。そういうスキルを持っている人は、例え言語や使うフレームワークが変わっても強いイメージが実感としてもある。 物事をパターン認識(こういうときはこう)でしか理解していないのか、裏側の仕組みから導出できているかの違いなのかなと思うんだけどどうなんだろうな。

というわけでがんばっていきます。

「ELASTIC LEADERSHIP」を読んだ

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

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

最近急に意識が高まって本を読みまくっている。

この本は、色んな人が既に感想やまとめを書いていらっしゃるので個人的によかったところまとめる。

フェーズに応じてリーダーがとるべき振る舞いは違う

チームの状況に応じてリーダーがとるべき振る舞いは違うよねという話。本書ではチームの状態は以下のように説明されている。

  • サバイバルフェーズ
  • 学習フェーズ
  • 自己組織化フェーズ

これからの時代はサーバント型のリーダーだ!みたいなことをよく聞くわけだけど、当然それはチームの状態によって異なるよねという話。サバイバルフェーズ(チームに余裕がない状態)では、指揮統制型でリーダーがチームの取るべき方向を示し引っ張っていくことが大切だとのこと。

また例えばチームが学習フェーズであっても、過ちを正すのに沢山の時間がかかる場合には指揮統制型で望むべきだともあった(例えば、「Gitととかよくわからないし、ファイルサーバで管理しましょう!」みたいなことをチームが言い出したとき、バージョン管理されてないがゆえのデータ削除なんかの間違いが起きてからリカバリするのはしんどいよね)。

こういうリーダーシップ論って極端な話が多い気がするんだけど、現実に即して振る舞いを変えるべきだということが書いてあってとても納得した。

コミットメント言語

これは 「XXを△△△までにやります」 ということをチームのメンバーにコミットしてもらうようにする、と言うものだ。これは他の方のブログでは結構炎上していたけど、意図がちゃんと伝わってないのではと思う。

このコミットメント言語には前提がある

  • チームがサバイバルフェーズではない(チームに学習するだけの余裕があるといこと)
  • コミットメント言語では制御下にあるものを対象とする(コントロールできないことはコミットメントしない)
  • メンバーがコミットメントできない(コントロールできない)ことを言ったら、リーダーはコントロールできるものに変更するように依頼しなければならない。

コミットメントをするのは、メンバーに期日や約束を絶対に守らせるようにする!!といった精神論的な話ではなく、コミットメントをすることで、問題を可視化する ためだ。

「今週中にやろうと思ってるんですけど難しいかもしれませんねー」みたいなタスクがずっと宙ぶらりんになってしまった経験はないだろうか。今思うと、こういったタスクは振り返りでもあまり進捗が悪かった原因が話し合われない気がする。

コミットメントしようとしたときに、「XXまでに実施する」といった断定的なことが言いにくい場合には以下のような課題が見える。

  • 実は他チームのタスクを抱えていてそれを実施する余裕がない
  • タスクの粒度が荒すぎて / 難しすぎて、何から手を付けるべきか迷っている

コミットメント言語は上記のような課題を早めにあぶり出すためのものなのだと思う。

いい兄貴

この本には途中から日本人開発者のエッセイが収録されているんだけど、なかでも伊藤直也さんの話がよかった。チームを良くすることだけに集中して技術や事業の問題に向きあっていないと、本当に組織が困った時(事業が伸びない、プロダクトが使われない、技術的に困難な課題に躓いてしまった)に役に立たないリーダーになってしまうというようなことが書いてあった。

リーダーというとどうしても組織づくりみたいなところに目がいってしまうけど、文字通りチームを技術的に・プロダクト的に「リード」できる人間であり続ける必要があるんだなと再確認した(大変だな…)

まとめ

前に友人のエンジニアと飲んでたときに、「今後のキャリアを考えたときに、マネージメントか技術かどっちに進んだらいいんだろうなー」という話をしたことある。そのときに「suzan2goさんは、マネージメントっていうよりはリーダーシップとかプロジェクトを引っ張ってくとかそっちな気がするなー」ということを言われた。

当時はあまりピンと来てなかったんだけど、この本を読んでいくらかそれがどういうことなのかクリアになった気がする。相変わらず「マネージメントをする」と言われるとちょっと身構えてしまうけど、「リーダーをやる」ということにはこの本を読んで少し抵抗がなくなった感じがする(単純に言い方だけの話だと思うw)。

「リーン顧客開発」という本を読んだ

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

積んでた本をちゃんと読んだ。 前回読んだときは、想像していた中身とちょっと違っていて、最初の数十ページ読んで積んでしまっていた。しかし、改めて読み直してみると現在会社でやっているユーザーインタビューに対してかなり知見を与えてくれそうな本だったので、一気に読んだ。

どんな本?

「顧客開発」というタイトルから、サービスのファンを如何につくるかみたいなマーケティング的な話を想像してしまっていたんだけど、中身はそういう感じではない(なので前回読んだときは途中でやめてしまった)。顧客と対話することで、どんな課題やニーズがあるのか、そもそもその顧客は作ろうとしているサービスのユーザーになってくれるのか、みたいなものを如何に見極めるかという話だった。

この本の殆どの部分は「ユーザーインタビューをどんな風に行ったらいいか」ということに割かれている。ユーザーインタビューで聞くべき質問から、インタビュー対象の見つけ方、どれくらいインタビューを重ねればいいかなど結構具体的だ、本のタイトルから自分はもっと心構えがどうといった抽象的な話が多いのかと思っていたので結構意外だった。

学び

「ユーザーの言うことをそのまま実装してもダメ。本当の課題が何か考えよう」みたいな話はよくあるし自分も思う所だけど、ユーザーとの対話を通して如何に課題を引き出すか・見つけるか、みたいな視点をあまり意識したことがなかったので新鮮だった。

自分はユーザーインタビューで得られた意見に対して「尤もな意見だけど少数派なのではないか」「不満は感じてないと言っているけど、システムに慣れてしまっただけなのではないか」みたいなことをよく思っていたし、どう判断すればいいのかよく分からないなと思っていたんだけれど、そこについてもこの本は色々書いてくれている。

結局は漫然とユーザーインタビューをしていても駄目で、「自分たちの持っている仮説を検証する」という心構えでインタビューの対象者選びをして繰り返しインタビューをしていかないと、得られるものも少なくなってしまうんだなと思った(これはどういう意図のユーザーインタビューだったかにも依るとは思うけど…)。

MVPについてはこの本のメインの部分ではないだろうけど、様々なパターンについて具体例を交えて書かれていて結構参考になる。「最終的な製品をどうするか決めて、MVPとして出すためにカットできる機能を検討する」は「よく耳にする起業家の間違い」とはっきり書いてあってアッ…ってなった。

まとめ

ユーザーインタビューにしてもMVPにしても、「どんな仮説を検証したいのか」ということがはっきりしていないと、それ自体が目的化してしまいそうなので気をつけたいと思った。リーンに開発していくぞ。

RubyエンジニアがGolangのどんなところに挫折して、どんな風に再挑戦したかという内容でLTをしてきた

LTしてきた

【Go言語LT大会! 「最近、Go言語始めました」の会】でLTしてきました go-beginners.connpass.com

speakerdeck.com

内容について

大体内容は前にブログで書いたような話で、 これからGolangを触る人向けに自分はこういうところで挫折した / 再挑戦してうまくいったよって話をした。

suzan2go.hatenablog.com

要約すると以下のような感じ

  • Golangで他のRuby(or 他のオブジェクト指向言語)のやり方を持ち込んでもうまくいかない事が多いよ
  • Golangの色んな先人の知見(ブログやGitHubソースコード)を参考にしたほうがいいよ
  • 書く量を少なくするためのハックよりも愚直に書いた方がいいコードになる気がするよ(個人の感想です)
  • 一度Golangの書き方に染まってみるときっと楽しくなってくるよ!

感想

  • インフラエンジニアっぽい人が多くて、アプリケーションエンジニアはあんまりいなかった印象でした(実際どうだったかは分からない)
  • Webアプリ作る時に参考にしたリンクが結構需要ありそうだったので、もうちょっとそっち方向でまとめればよかったなと思った。
  • ゲスト講演者のtenntennさんの標準パッケージ紹介が普通に勉強になった。Golangちょっと分かった気でいたけど標準パッケージでも全然知らないことの方が多かった。
  • 標準パッケージの内容読むの役に立つよって人が多かった。自分も読んでみようと思った。
  • 一緒に行った同僚の前職の後輩の人がいてビビった。更にびびったのはその人が自分のことを知っていてブログも読んでいるという事実。いぇーいXXXさん見てるー!?
  • 資料作っていると実は自分がよく分かっていないことが分かっていい。曖昧な知識で発表するのがアレだったので今回の発表内容は結構ふわっとした感じにしてしまったけど、次はもうちょっと突っ込んだ話をしていきたい。

現場からは以上です。