「ジェフ・ベゾス 果てなき野望」を読んだ

ジェフ・ベゾス 果てなき野望

積んでた本を読んでみたシリーズ。きっかけは、この本を本棚から引っ張り出した娘が「パパ！パパ！」と言ってきたから。

どんな本か

Amazonの企業としての歴史を振り返り、社内でどんな事が起こっていたかが実際に社員(もしくは過去社員だった人)からのインタビューを中心にしてまとめられている。

最初の方のAmazonの成り立ちというか起業秘話みたいなところはふーんって感じでしかなかったんだけど(だからそこで止まってた)、以下のエピソードは面白かった。

• 取り扱う商品をどのように広げていったのか
• プライムがどう始まったのか
• Kindleがどのように生まれたか
• AWSがどのようにして生まれたのか

感想

とにかくベゾスすげーなということに尽きる。自分で大きなビジョンを描いたらそれを達成するために手段を選ばないという感じが本当にすごい。最近では自前で運送もやりはじめているらしいけど、この本を読んだあとだと全く違和感がないというかそりゃやるだろうな…という感じがする。Kindle fireとか個人的には何でAmazonがこれ作る必要があるんだ？と思っていたけど、この本を読んだあとだ全く違和感がないというか、そりゃやるだろうなー・・・という感じだ。

ただAmazonで働いてみたいかというと、結構しんどそうだなーと思った。本当に猛烈に働き続けなきゃいけない感じで、最近よく聞く心理的安全性とか微塵も無さそうｗ(あくまで本を読んでの感想です。もしかしたら最近は or 部署によっては違うのかもしれない) 一番きっついなーと思ったエピソードは、会議でベゾスに「サポートに電話をかけると何分で繋がる？」と聞かれて、サポート担当のマネージャが「1分くらいです」と適当に答えたら、ベゾスがその場でサポートに電話をかけ始めたという話。数分たっても電話が繋がらず、ベゾスは真っ赤な顔でそのマネージャを罵りまくったとのこと。

とにかくこのベゾスは滅茶苦茶キレる(怒る)人のようで、各エピソードで一回以上はブチ切れてる感じだった。それでも最近は一通りブチ切れた後「でも、よく頑張ってくれた」的なことを言ってくれるらしいが…(改めて読み返してみたらそういう記述が見つけられなかったので、もしかしたら<そうであってほしい>という自分の妄想かもしれないｗ)

参考

AmazonからGoogleに移ったエンジニアのぶっちゃけ話。前もこれは見たことあったんだけど、本を読んだあとだとｱｰﾔｯﾊﾟｿｳﾅﾝｽﾈという感じだ。 anond.hatelabo.jp

「ヨチヨチ父」という本を読んだ

ヨチヨチ父という本を読んだ。

ヨチヨチ父 とまどう日々

これ今気がついたんだけど、「もうぬげない」と同じ作者だったんだなぁ。

もう ぬげない

きっかけ

たまたま書店で見かけてちょっと立ち読みしたら凄く共感することが多くて、衝動買いしてしまった。 いい本見つけたなーと思ったんだけど、うちの奥さん曰く結構話題になっていたらしい。

どんな本？

父親の目線で育児について書かれているエッセイ集？みたいな本。

よかったところ

母親の人が書いた育児マンガやエッセイは結構色んなものが出てる気がするけど、父親目線で書かれている本って意外とない(主観です)。この本で父親目線で書かれているエピソードや思いはとても共感することが多くて、読んでいると子供が生まれてからこれまでの嬉しかったこと辛かったことが思い起こされて、結構ぐっと来た。

特に、育児における父親の大変さを書いてくれているところが凄く良くて、自分以外の父親も子供が生まれてからの環境の変化に対して戸惑っているし、同じように大変なんだということが分かった。それを知ることができただけでも、なんていうか心が軽くなった感じがする。

もしかすると、子供が産まれる前に読んでもあんまりピンとこないかもしれない。 子供が生まれてからの環境の変化に戸惑って、疲れて、モヤモヤしているお父さん方におすすめしたいなー。

自分の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版

機械学習で何か作る

進捗だめです

変化

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

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

suzan2go.hatenablog.com

早く帰るようになった

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

Golangに再入門した

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

メンターやった

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

suzan2go.hatenablog.com

Write Code EveryDay

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

体重

はい

下半期の抱負

機械学習やるぞ

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

アプリリリースするぞ

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

隣の芝？

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

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

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

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

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

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

隣の芝？

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

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

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

「ELASTIC LEADERSHIP」を読んだ

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

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

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

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

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

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

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

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

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

コミットメント言語

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

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

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

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

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

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

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

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

いい兄貴

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

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

まとめ

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

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