学びを結果に返るアウトプット大全

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

読了した。 基本的にはエンジニアの知的生産術と似かよった内容が書かれていたが書かれ方がよりわかりやすくなっていたので失礼な言い方をするならば下位互換といえる書籍だろうと思う。 エンジニアの知的生産術がソフトウェアエンジニアを対象としているのに対し、こちらは特定の職業に限定していない点で読みやすさはこちらの圧勝という感じがする。

この本を敢えて手に取った理由だがこれはかなり明確で最近インプット過多気味であるのにそれに比例したアウトプットを出せていないなと感じていたのが発端。 以前から近所の本屋で目立つように置かれていたのだがエンジニアの知的生産術を読んだので恐らくそれ以上には刺さらないだろうと思っていたことから手にとることがなかった。 たまたま時間が30分ほど空いたので目次をパラパラとめくってたところ、印象に残る項目がいくつかあった。

気になった項目は「2週間に3回使った情報は、長期記憶される」「インプットとアウトプットの黄金比は3:7」「ぼんやりが脳の働きを活性化」の3つ。 他にもいくつか気になったものはあったが購入を決意したタイミングはこの3つの項目に注目したからとなる。

読み終えたいま振り返ると多分この本を購入する原動力になったのは、当時アウトプットの量が激減していたがインプットなくしてアウトプットも出来ずどうバランスを取るのか?に関するヒントが欲しかったこと。 もう1つが体感的にインプットよりもアウトプットの比重を多くするほうが学習効率がよいと感じており、その理論的な補強で自分自身を納得させる材料とするためだったように思う。

Kindle版を購入したのでおおよそ1400円前後だったことを考えると元は取れたかなと感じている。 ちょうどこの時期に学習効率を上げるために書かれた本をいくつか買っており、それぞれの共通項目と似ているが微妙に異なる表現や考え方捉え方を読み比べることが出来、これによってある程度効率の良い学習方法とはなんであるか?が自分のなかで道筋がたったように思う。

同じような本を3冊読むとよいと書いていたのはエンジニアの知的生産術だったかそれ以外だったかははっきりとしていないがどこかで見た記憶があるのだが今回はじめてその効果を実感した。 (エンジニアの知的生産術で同じ本を3度読むとよいと書いていたのは記憶している)

今回ぼくが読んだ本は「エンジニアの知的生産術」とこの「アウトプット大全」、そして「たいていのことは20時間で習得できる」という3つの本になる。

たいていのことは20時間で習得できる

たいていのことは20時間で習得できる

最後の本に関してはTEDの動画でも有名なので本を読まなくてもその動画をみてもいいかもしれない


The first 20 hours -- how to learn anything | Josh Kaufman | TEDxCSU

それぞれターゲットとするところが異なっている。

エンジニアの知的生産術のターゲットは当然ソフトウェアエンジニアとしてより活躍する人を。 たいていのことは20時間で習得できるは出来るだけ時間を書けずにスキルを習得したと言えるレベルを目指す人、つまりは未経験から初心者へのステップアップを目指す人。 そして最後にアウトプット大全はより汎用的なアウトプットの質を高めたい人をターゲットとして設定していると考えている。

それぞれのアプローチが微妙に異なる点があるのはターゲットが異なるためその手段や方法が異なるためなのだが共通項目をいくつかあり、その共通項目は効率の良い学習を行う上で外すことの出来ない必要条件なのだと理解した。

この本でぼくが得られたと感じている点はいくつかあるが購入する際に期待したものはほぼほぼ達成できたと考えている。 一方で想定していなかったが得られたと感じた(というよりは実体験の理論的補強がなされたというほうが近い)こともいくつかあった。

そのうちの1つが「インプット→アウトプット→フィードバック」の体験サイクルを回すというものだ。 独学で困ることの1つにインプットは頑張ればできる、アウトプットに関しても昨今はなんとかなる素地があるが最後のフィードバックに関してはまだまだ整備がされ尽くしてはいないと感じていてこのフィードバックが得られるかどうかが独学におけるハードルの高さを表しているのではないか?と改めて感じさせた。 特にいまは春先なのでプログラミングのオンライン教室などでインプットとアウトプットは出来るようになったがフィードバックが足りていないか、されていない人を見かけることが多いように感じているのも一因としてあると思う。

もう1つ重要なのがアウトプットする時間を区切る、「ブログを書く」ではなく「30分でブログを書く」とコミットメントすることを意識するというものだ。 いままでは趣味レベルのブログなのでそこまで意識せずにいたが確かに文字を書くことも推敲も無限に時間が吸われていくため、この意識がないとアウトプットに対するフットプリントが上がってしまう要因になるなと感じたため、今回のブログを書くに当たり30分以内で書ける範囲を書くという自分の中の制約を作って書いている。 (いまのところ、まだ時間範囲内だが書き始め段階で想定していたタイムキーピングからは少し遅れが生じている。)

最後にこの本ではいくつかSNSに言及する項目が存在する。 その中の文脈に「SNSでは本当に困ったときに助けてくれるひとはいない」や「SNSで匿名や実写でないと現実世界でメリットにならない」というような書かれ方がされており、この点に関してソフトウェアエンジニア界隈が如何に異端な存在であるかということを改めて実感させてくれた。

最近でいうとぼくはGraphQLについて調べていたのだがユーザ認証や制限をかけることをGraphQLでどう扱うのか?がわからず、また他に優先することがあったため、その時間をとることも出来ていなかった。 ところが知人がその困った状況を知ったのか、わざわざブログに内容を書いてくれ、また参考としたTechブログのURLも記載してくれていたため大いに助かった。 この辺りはソフトウェアエンジニアにおけるTwitterという1つのエコサイクルが非常に異端な業態として運用されている好例かなと感じることだった。

もう1つに匿名や実写でないと現実世界にポジティブな影響を及ぼすことが難しいという話しだが最近だとTwitter転職などの話もあり、SNSというのは現実世界と仮想世界をつなぐインターフェイスの1つであると認識されているのだなと思うとかなり面白い現象が発生しているなと感じるきっかけになった。

さて、そろそろ時間なので締めるとするがこの本を手に取ってほしいなと読んでいるときに感じたのは異業種からの転職で若いとは言い難い年齢になっている方、新人でより活躍したいと考えているかたがいいのではないかなと思う。

逆にある程度業界年数が長かったり、すでに初心者の壁は超えられているひとにはエンジニアの知的生産術のほうがよりディープで刺さる内容だと思うのでそちらをオススメしたい。 そんな感じでだいたい30分なのでこれでおしまいとする。 お疲れ様でしたー。

1社員であるエンジニアにとっての採用参加の意味へのアンサーソング

tbpgr.hatenablog.com

↑を読んでちょっとそれはどうかなー?と疑問に思ったことがいくつかあったのでアンサーソングとしての書き出し。

エンジニアがHRに関わることに関する自分をポジションの中心に据えたうえでの発言になります。

採用への協力を「好き」とこたえている

  • 採用活動への協力に対してポジティブですか?ネガティブですか?という質問のほうがよかったのではないか?
    • 同じチームメンバーとして働くので無関心ではいられない、小さい会社、小さいチームだとより顕著だし影響度でかい。
      • 一緒にいてイライラするような人と同じ空間にいるのはキツい
    • そもそも採用活動を好き嫌いの二元論で語るのは少し違う気がしている
      • 大事だと思うし、協力できることならしたいと思ってる。でも好きでも嫌いでもない。
      • 採用はチーム全体で行う一種のモブプログラミングみたいなものだという意識があるので好き嫌いは関係ない気がする
      • 採用活動自体は大事だし、興味がある
        • 人事ニアとか興味ある。人事そのものというよりエンジニアリングで改善できる余地とその改善によるパフォーマンスが大きそうなところで興味がある。
        • いろんな人のコンテクストに触れられるのはいい意味で刺激を受ける
        • 好き嫌いはあってもよいがそれでコミットの有無を決めるのは仕事ではなく趣味という切り分けをしているので違和感がある
    • 採用に協力的なエンジニアは会社に対してのオーナーシップを持っている傾向があると思う。
      • 仮に呼称するならHRオーナーシップとかなんだろうか?
      • いまのチームや会社に足りないものを把握していないとそもそも個人の好き嫌いに採用が左右されてしまう
        • 好き嫌いだけで判断するのはよくない傾向だと思う。
          • カルチャーマッチとしての好き嫌いは別。
        • スキルマップをチームや会社で共有して「おれたちがもとめる人材はこれだ!」みたいなコンセンサスが取れてないと正直難しい。
          • Issueのゴールが曖昧なので明確にする必要があると思う。
        • 上司からの「こういう人材がほしい」に応えるだけだと採用に主軸をおいていないエンジニアには判断できる幅が少ない
          • 予めどういう人材が一番ほしくて、次点はこう…みたいな自身のなかで腹落ちしていないと面接してるときに応用が効きにくい

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

エリック・エヴァンスのDDDにずいぶん苦しんで読んでいたせいかめちゃくちゃ早く読み終わった。 写経は今回スキップしている。

理由としてはReactを覚えるのが目的として読んだわけではなくプロダクトからReactに入ったのでどこまでがReactなのかきちんと自分の中でわかれていないと感じたこと。 あとReactの基礎的なことがどこまで理解できているのかがわからなかったというのが目的だったから。

なので写経は必要があればあとからやるつもりだったが必要ないことが判明したのでスキップ。

Reactってなんなの?という人が最初に読む一冊としては良さそう。 但し2016年の本なのですでに時代遅れ感は否めない。React Hookとか書いてないし。

普段触っているReactのコードのこの部分が関数合成されているんだなとかこの部分は初期化されているからInitialStateが云々…みたいな実装されたコードの背景がわかるようにはなった。 根本的に自分が理解できていないのはFluxを含むデータの流れがまだ把握しきれているというわけでないことが判明したのでFluxのドキュメントとか読んで書いていけばそのうちマシになりそうという感じがある。 (フロントエンドの開発が明らかにぼくだけ遅いという問題が現実に発生していた)

書く量がまだまだ足りていないというわかりやすい結論に到達したのでひとまずこの本は終了。 正直良い本か?と言われると現時点では悪くはないがという評価になってしまう。とはいえ基本的な部分を抑えるには十分な内容だとも思うので気になる人は手にとって知らない単語が2割くらいあったら買うみたいな姿勢で良いと思う。

Kyoto.rb Meetup 20190316

kyotorb.doorkeeper.jp

ずいぶんお久しぶりという感じだったのですが久しぶりにKyoto.rbに参加しました。

決め手になったのは↓

自己紹介の時に、気になっているテーマや、キーワードをそれぞれ簡単に紹介。 その中から2つテーマを選んで、それぞれが持っている知識や経験を話したり、誰も知らない場合は、みんなでその場で調べたりして、知識を深めます。

今回はいつものもくもく会ではなくテーマが設定されていたこと。 そして直近ですこし困ってることがあって相談したいなーと考えていたタイミングにドンピシャだったので参加を決意してポチッとなしました。

結果からいうと……めちゃくちゃ良かったですね! 「自分、こんなところで困ってるんですけど…」みたいな相談が出来たのが良かったと思っていて、他のひとがどう解決しているのか?というベストプラクティス的な部分を知ることができたので良かったです。

特に id:onkさんにはいろいろ教えてもらって大感謝です! ……懇親会で完全におっさんがonkさんを独占していて良くなかったな(もっと若い人が話したかったんじゃないかって後から気づいた)って思ったので次回は離れた席に座るようにしますw

あと話すというのは結構大事だなと思っていてコンテクストの異なる人に対して説明できない→きちんと自分の中で抽象化できていないということだと認識しているんですがしばしば会社の中だとコンテクストが通用してしまうので自分の中で飲み込めないままになってしまうことがありました。 その点、今回はキチンと伝えられなかった→まだ自分の中で問題の抽象化ができていないという気づきを得ました。 あとは単純に似たようなケースの場合どうされているのか?を知ることが出来たので「自分の考え + α」な形に持っていけたので良かったなと思っています。

客観視、大事。

また今回は話題のMoneyForwardさんの京都オフィスで開催だったこともあっていつもより参加者が多かったのが印象としてあります。 初心者が多い&いつもより参加者が多いという事情から初?の試みとして初心者向けとそれ以外という形でグループをわけました。

初心者向けがこちら↓ scrapbox.io

それ以外がこちら↓ scrapbox.io

ベースは話したいテーマから人気のあったものの中から選ぶ感じで進めました。 f:id:luccafort:20190316163944j:plain

話しながらScrapboxに書いていくという感じで進行していたのですが議論というか説明に集中すると書くのが止まってしまうのが難点で話した内容がシュッとScrapboxに投稿されると最高だなーって感じですね。

AWSとか使えばやれなくはないと思う。

以下、楽しんでいた空気です。

たーのしー!

Instagram post by るっかふぉーと • Mar 16, 2019 at 9:06am UTC

例のやつ、撮ったどぉ!!!

次回開催がすでに決まっていて4/13(土)なので次回までにgraphql-ruby触って知見を持ってる人に質問してみたいなと思ってます。

トマルバ Lv.0 から Lv.1 になりました!

sansan.connpass.com

Legacy Meetup Kyotoに参加してきました。 元々はこのイベントでの参加ログを書くつもりだったんですがそこであった発表の中に「yahoo!で働くようになってまだ半年なんですが…」という一言に影響されてこのエントリを書いています。

ぼくが株式会社トマルバに実際に入社したのは去年の5月からなのでまだ1年経ってはいないのですが副業の開始時期が去年の2月頃からだったのでまあちょっと多めにサバ読んでだいたい1年として見積もって、いろいろなことがあったこの1年を振り返ろうと思います。

構想段階でポエムが長文になるなという感じなのでサラッと目を通すくらいの気持ちで読んでください。 (書き終えたら1万字とかいってた、ヤバい…)

イベントの参加ログとしてのエントリはまた後日気が向いたら書く…かもしれない。

ついでに告知をば。 つい最近、というかまさに昨日知ったのですがWantedlyの求人ページができていたので紹介しておきます。 残念ながらまだエンジニアやデザイナーとしての募集エントリーはないようなのですが常に人と時間とお金は無限に足らないのでもし興味があればTwitterのDMでもお知らせください。 肉か寿司が出るかはわからないですがまあ「飲み行くぞ!」みたいな感じで話すのは可能です、Skypeとかのリモートでちょい話し聞かせてくんろ!とかもOKやで。

tomaruba.me

www.wantedly.com

閑話休題

入社前と入社後の期待とその結果

入社前に現CTOと面談していてそのときのために書いていた「株式会社トマルバに入社することでぼくが期待すること」メモがあったのでそれを元に入社前後でその期待がどうなったのかを振り返ってみます。

ぼくが当初期待していたことは大きく2つあってそれは「個人としてスキルアップできる環境か?」ということと「英語の語学力向上」を掲げていたのでまずはその経過報告から。

個人としてスキルアップできる環境か?

この「スキルアップできる」という表現が非常にふわっとしているけどぼくが当時考えていたのは開発する技術周りの向上を期待していました。 株式会社トマルバ(めんどいので以下弊社)ではサーバーサイドにRuby on Rails、フロントエンドにReact(ジョインする直前はVueだった)を採用しています。

当時からいまに至るまでぼくはあまりフロントエンドの技術にあまり興味が持てないというのもあり、苦手意識があります。犯人はだいたいIE6とかいうやつのせいです。

入社前の段階のぼくの状態としては「個人でRails Tutorialsやってる(未完走)」、「個人でVue触っている」くらいの温度感です。 プログラミング教室を出たての人よりはマシかもくらいの状態です。その当時までは主戦場がPHPだったのでね。

なので「Railsエンジニアを名乗っても恥ずかしくないレベル」であること、「苦手なフロントエンドをメインではないにせよ仕事としてこなせること」というのを期待していました。 Railsに関しては仕事としては最近あまり触れていないのですが一応「Railsの案件あるんだけど…」と言われても「ものにもよるけど出来るんちゃう?」と思えるくらいには成長できたかなと思ってます。

苦手領域のフロントエンドですがこちらはまだまだだなというのが正直な感想ではあるもののサポートしてもらえればなんとか担当チケットを(理想的なコードではないものの!)実装可能くらいにはなったなと思っています。 とはいえ長らくJavaScriptに苦手意識を持っていたせいで基礎的な部分がスコーンと抜けてしまっているのでReact入門を読んでまず基本を抑えようかなという感じです。

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

ここ最近のぼくに対して期待されているスキルとしてはマネジメントの知識、DDDのようなドメインの知識、そしてソフトウェアアーキテクチャ設計のような設計関連での知識が求められている感じです。

マネジメント(の一部権限が移譲されてるだけ)に関しては正直いままでやりたくないと思って逃げていたことなんですが逃げ切れずここ数年向き合わざるを得ない感じになってきたというのが正直な感想です。

とはいえ、マネジメントを嫌々やっているわけではなくぼくらが今目の前で抱えている問題を解決するにはプログラムだとかソフトウェアアーキテクトというレベルでは解決できないことのほうが多く、今日参加したイベントのスライドにあった「おそうじガイド: 合意」におけるステークホルダーとの合意、開発メンバーとの合意、そして更に弊社の場合はホテルの運営業務が主となるビジネスなのでその運営業務メンバーとの合意が必要になってきます。

大変。とても大変……。 (これでもまだマネジメントの一部なんだよなーとたまに絶望しそうになることがまれによくある感じですね。)

speakerdeck.com

DDDに関しては名称だけは常々…という感じだったのでまずはエリック・エヴァンス氏のDDD本を少しづつ心を折られながら読み進めています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

一旦一通り目を通し終えてからもちこちゃん本と一緒にドメインとはなにか、どうあればよいのかを考えていきたいなという感じでいまは進めています。 とりあえず現段階の感想としてはエリック・エヴァンス氏とは仲良くなれそうにないな、ということです。

booth.pm

ソフトウェアアーキテクチャ設計に関しては現在読んでいる技術書が多すぎるの意図的に読まないようにしてるんですがClean Architectureが良書っぽい感じかつオススメされたのでDDDが一段落したらガッと読み進めてしまおうと考えています。 DDDは後回しにすると永遠に読まない感じが非常にしており、読みたいけど読めないみたいな状態になっています。ぐぬぬ

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

英語の語学力向上

良くなった点はルー大柴みたいな英語でも躊躇せずに「これは○○だからI don't careなんだよね!」とか臆面もなく言えるようになったのは成長かなという気がします。 あと発音を無駄に気にするのがマシになった気がするのもよい。

ただ全体としては期待したほどは向上してなくてこの原因は明らかでぼく自身が英語を話していないからということに尽きる。 とはいえ、いきなり話せ!とだけ言われても無理ゲーなのでまずは会話英語のフレーズとかパターンにもっと触れないといけないなと思っていてその上で単語だったり文法だったりを覚えていかないと正直モチベーションが保たない。

ということで最近英語字幕をつけてAnime Crime Divisionsを0.75倍速で毎日みるようにしています。 まずは英語の苦手意識とフレーズのある程度のパターンとイメージを脳内に意識つけるのが大事だと思ってやっています。


How we made ACD Season 2, Pt. 1

書籍としては「ITエンジニアが覚えておきたい英語動詞30」がいい感じでした。 英単語としては中学英語のときに習うありきたりな動詞ばかりなのにこういう表現の仕方があるのかと思いました。 また日本人が英語で困るときというのは多分だいたいみんな同じで教科書に乗っている例文のような英語しか思いつかないので単語がわからないと話せないということだと思ってるんですがそういう意識とかイメージをもっとシンプルなものに置き換えてくれるなという気がしています。

似たような本に「会話もメールも英語は3語で伝わります」という書籍もありますが個人的にはこちらよりも「ITエンジニア〜」のほうがしっくり来たという感じです。

ITエンジニアが覚えておきたい英語動詞30

ITエンジニアが覚えておきたい英語動詞30

会話もメールも 英語は3語で伝わります

会話もメールも 英語は3語で伝わります

成長

エンジニアとしての目にみえるスキルということであればまずRailsエンジニアとして必要最低限のレベルには到達したかなと感じています。 ただエンジニアとしての成長よりも実感している成長としては「ヒアリング能力」「Issueを察知する能力」がほぼゼロだったので経験を得て成長できたなと感じています。 これは課題図書としてオススメしてもらったユーザストーリーマッピングが大きく貢献していて、読んでから実践を何度かやったので少しずつマシになってきたなと感じています。やったぜ!

なお今まではプランナーや営業さんにお任せコースみたいな感じでヒアリングをきちんと技術の1つとしてみたことがなくて属人性の高いスキルだと思いこんでました。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

あとデザイナーとプログラマーのみの2人しかいないチームですがそのチームビルディングみたいなことをしていて四苦八苦したのでそのあたりの能力というか知識や経験を得て成長できているなと思うことがあります。

特に良くなったなと自他ともに感じることが増えたのはヒアリング能力とチームビルディングのための知識や経験だと思っていて ここ最近だとデザイナーとうまく意思疎通ができていないなと感じていたのですが「いちデザイナーがチームビルディングのために何ができるか?藤本 貫二郎さん / レバレジーズ株式会社」というスライドに書かれていた「弱音を吐く会」というのをオマージュして(パクって)毎朝10分〜15分ほど困っていることや相談したいこと、サポートできることを1on1で話し合う時間を作って1ヶ月ほど試してみたのですが「プログラマーが考える理想のチームってどんな形?私はそれにどう協力できるの?」という質問を引き出すことに成功できたので成長できたな!と思うと同時にやったぜ!!!みたいな気持ちになりました。

note.mu

www.slideshare.net

またどれくらいこのことが影響してるのかわからないですがCTOとデザイナーが1on1したときに以前よりも意思疎通がスムーズになっていたと報告を受けていて、仕事というくくりの中で雑談を潤滑油にしながらコミュニケーションを行ったのが影響してるんじゃないか?とポジティブな評価をしてもらえてめちゃくちゃ嬉しかったです。

なおこの毎朝のMTGによってぼくの出社時間は30分早くなりましたし、最初のほうは全く手応えがなく不安と苦痛がいっぱいでした。 「こういうのは継続するのが大事だよ」と事前にアドバイスしてくれた id:daiksy さんありがとうございます、仰るとおりでした!

入社以降にスキルアップのために始めたこと

Railsがわからない2人で開発していたのでRailsとしてのベストプラクティスを知る必要があり、その際に非常に勉強になったのがTechRachoの週刊Railsウォッチでした。 本当に頭が上がらない感じで投銭したい気持ちです。KyashかAmazonのほしいものリストが公開されてたらめちゃくちゃお菓子とか送りつけたい。

techracho.bpsinc.jp

あとはTechRachoで知ったのかAjitofmで知ったのか忘れてしまいましたが八木さんのブログエントリも気になったものや自分たちが使っているものに関係している場合できるだけ時間をとって読むようにしています。 最近はあまりできていないですがRailsに触り始めたときはどういうコードを書くのか、どういう書き方がベターとされているのかがわからなかったのでコードを読む時間を意図的に多くとっていたということもあって頻繁に目を通していました。

y-yagi.hatenablog.com

マネジメントに関してはいろんなものの影響を受けているので代表例だけ。 主にメルカリ、はてなクックパッドのマネジメント手法や思考、思想などに大きく影響を受けています。 あとはぼくはGoolgeの文化が好きなのでGoogleにも大きく影響を受けているといっても良いかもしれません。

あとマネジメントというとかなり大仰だと思っていてぼくが四苦八苦しているのはまだ開発部署内のみでうまくチームがワークする環境とその下準備をしているという感じです。 この下準備というのは仕組み的なものではなく属人性によるコンテクストのバラつきを減らすみたいな感じで本来は仕組みでうまくフィットするようにするのがベターだなと思ってるのですが ぼくにはまだ難しいというのが現状であり、また根本的に解決したいと強く思えるだけの熱量をまだ持てていません。

あくまでこれらは「ぼくが働く上で楽でありたい」というのが動機の大きな要素であり、そのためにマネジメントの真似事が必要だし、一番効果的なので取り組んでいるという感じです。 ぼくらはスタートアップ企業で人が少ないということもあり、今後人が入ったときにいまのままだとスケールしない組織やチームになってしまうのでそういう点でも気をつけている、という感じです。

ぼくにとってこれらのチームは理想であり、今後、如何に彼ら彼女らに追いつくために頑張らないといけないかみたいなポジティブな気持ちがあります。 まだまだ山頂が遠いのですがぼくらなりの最高のチームプレイとそのありかたを模索していく上で参考にさせてもらいあわよくば踏み台にしていくぞ!という気持ちです。

tech.mercari.com

developer.hatenastaff.com

techlife.cookpad.com

マネジメントではないですが最近読んだエントリに感化されていて、こういう関係を構築できていなかったという反省とこういう関係を作れるようにやっていかないとな!みたいな気持ちになっています。

blog.sushi.money

これに対するアンサーソングがこちら。めちゃくちゃいい関係性を気づいててエモさが高まリングでした。 こういうアンサーソングが返してもらえるように振る舞っていきたいなと考えています。

blog.pastak.net

期待以上だったこと

価値観や文化のフィット

これは思いもよらなかったことという感じなのですが…。

組織、会社全体が非常にフラットで階層構造を意識することがない…というよりは階層構造を意識しないことが正しいという価値観と文化が浸透していて個人の価値観と非常にマッチしていて働きやすいなと日々実感しています。 そしてその環境はただ口開けてれば黙ってても餌が投げ込まれるという感じではなく、みんなでいろいろ工夫したり協力したりして作り上げているのでポジティブに「よっしゃ!じゃあぼくも協力するか!」みたいな気持ちになれてよいです。

その分ちゃんとやらないとそれはそのまま自分に返ってきてしまうのでいわゆるセルフマネジメント能力が重要になってくる部分が大きいです。 また会社としてのOKRやMission/Vision/Valueを現在刷新するということでよりこれらの裁量と求められるものが大きくなりそうです。

この会社の価値観や文化が期待した以上にフィットしたことは弊社に入ってよかったなと思うときにまず最初に思い浮かぶことの1つです。

プロダクトに誠実に向きあう

前職が受託メインの会社だったことも多少なりとも関係しているのかもしれないですがぼくには受託開発という仕組みではプロダクトに対して愛が感じられず、やりがいとかモチベーションの管理という面でマイナスでした。

なので転職する際に自社サービス開発であることを絶対条件の1つとして設定していました、期待するのは「プロダクトに愛が持てるかどうか」というところになるかなと思います。

実際に入ってから感じたのは「愛が持てる」ではまだ足りなくて「愛情を持って育てていく覚悟」が必要だと痛感しました。 ぼくたちが今作っているサービスは正直まだまだ足りないものだらけですし、もっと根本的に改善していきたいことなどもたくさんあるのですが「このプロダクトがどうすれば正しい成長ができるだろうか?」ということが改善案や問題が発生したときに度々議論の訴状に上がります。

「いま困っていることは○○だが本質的にこれを解決することが正しいのではなくてこの問題点を解決してもそれはただの暫定対応でしかないよね」という話が部署を問わずにいろいろなところで聞くことができます。 「プロダクトに愛を持つ」のはむしろスタート地点で「どうすれば正しく成長させられるのか?」と真摯に向き合わないといけないということが結構な頻度で発生しています。 これは非常に嬉しい状況であり、ぼくとしてこういう環境に身を置きたいと考えていたこともあって期待以上の結果が得られていると感じています。

愛を伝える

ぼくとは少し表現の仕方が違うんですが弊社CEOがことあるごとに愛という表現でHRTを伝えてくれます。 口だけ言う人を何度も見てきたので最初は正直なところ懐疑的に見ている面が半分、信じている部分が半分という感じでした。

ただ回数を、それも頻繁に目にするし口にするしまたその語り口のときの熱量も伝わってきて「この人は本気だ、ちゃんとぼくらのことに真剣に向き合ってくれている」と感じました。 またCEOは愛という言葉で「尊敬、信頼、謙虚」を表現してくれているなと感じており、四畳半神話大系の小津のような「ぼくなりの愛ですわい」というような愛情を感じています。

人間というのは単純で愛を与えられるとそれに答えたくなる面があります。 ぼくもこのCEOやCTO、一緒に働くメンバーの愛に応えたいし、応えていくぞ!という機運があり、そういう意味でも気持ちよく働けています。

やらないように注意していること

タスクに着手する前に1ステップ置く

ホテル業界って実はかなりマイナスの意味におけるレガシーさがあって、Web業界としてはもう10年も20年も前に「デファクトスタンダードだよね」という感じで定着している文化や仕組みがまだまだ浸透していない現実があります。 弊社ではSlackを使ってのやりとりが多いのですが依頼の内容に緊急度がわからないものがあり、前職のときであれば「すぐに直します!」と返答していたのですが直せるとしても調査でまず留めるように注意しています。

これは人的リソースが2人しかないのでこの手の運用に問題があったために発生した不具合や運用でなんとかできるレベルのものであればそちらで対応願っています。 結果としてこれが1ステップ置く形になり、冷静な目で対応策を検討する余地を生むことになったりして開発としては良い面が出ています。

とはいえ直せるなら直したい…みたいなジレンマは出るのでいまは我慢を強いられてるし我慢を強いていると思っているので今後こういう対応にも素早く対応できるよう仕組みでカバーしたいと思ってます。 ぼくは「運用でカバーする」という言葉がめちゃくちゃ嫌いなのでこの単語の社内での使用率を0にしたいと思ってる。

運用でカバー、殺すべし。慈悲はない。

終業後の対応は出来る限りしない

本当に緊急で他部署の業務に深刻な影響がでていない限りは終業後や休日中の対応や調査は行わないように意識的にしています。 というのもぼくはあまりこの仕事のオンオフの切り替えがうまいタイプではないので仕事とプライベートがシームレスになっている部分があります。

結果として休日に気が休まらないことによって平日のパフォーマンスに影響がでることがあり、やりたい気持ちややろうと逸る気持ちを押し付けて営業時間内でやる!ということを意識的にしています。

この休日などに意識してしまうことで平日のパフォーマンスが劣化する現象は30歳超えてから自覚したので20代だったら気づかなかったかもしれないです。

その分、業務時間で集中的に行うということを意識するようになったのでこれは結果としてよい効果をもたらしたかなと考えています。 また出来るだけ残業というものをしないように努力していて、最小のコストで最大の結果を求めないとそれをサービスにも反映できないんじゃないかという思いがあり、ぼくらに求められているエンジニアリングとはそういうことだと認識しているので「与えられた時間内で最大の成果を出せる」ようにしたいと日々考えています。

あと仕事は無限に増えるのでそうしないとパンクしちゃうというのもあるし、基本的にぼくは「働かずに飯が食えるなら働かない」でいたい人間なので性質的にもそれがあってるという感じです。

で、実際どうなの?

日々めっちゃ充実してるね! もちろん課題は山程あるし、大変なことがないわけではない。

でも「楽しい include 苦しい」という感じで大半がいまの状況を楽しめていると実感できる日々を送っているので充実しています。 また弊社に入ってよかったと思うことの1つに成長を実感できるというのがありそれがぼくには非常に魅力的だということが言える。

以前「最近やった新しいこと」というタイトルで新しい技術や挑戦をしているということを書いていますが昨日参加したRegacy Meetup Kyotoでも同じようなことを山本寛子@ヤフー株式会社のかたがスライドに書かれていたんですがコンフォートゾーンの外にでるのは怖いんですがそこを超えるとめちゃくちゃ気持ちがよくてそれを会社内で継続的にさせてもらってる&ちょうどよいハードルがいくらでも転がっている状況というのはぼく自身が成長したいという欲求とそれに対して求める環境というところにめちゃくちゃマッチしていて入って良かったなと思ってます。

luccafort.hatenablog.com

前職ではある程度そういう仕組が出来上がっていたことや階層構造的な組織だったことなどなどの事情からここまでチャレンジングにするのは難しかったと思ってます。 もしそれを前職でやろうとするならぼくが経営陣全員追い出して「こうするぞ!」という旗振り役にならないと難しかったと思う、少なくとも個人の裁量と権限では手に余るのは間違いなくてボトムアップだけでは不可能だっただろうというのがぼくの見解です。

そういう意味では安心して成長できる環境があるという素晴らしい状況に身をおいているなと改めて感じるところがあります。

まとめ

という感じで月ごと、下手したら週ごとに成長を感じることのできる環境に身をおいているので感謝と転職を決断した判断は間違ってなかったという思いがあります。 クソエモエントリですが、こんなところで締めたいと思います。

まだまだ成長するべきところは会社にも、チームにも、個人にもあると思っているんですがぼくらならやっていけるんじゃないかというポジティブな気持ちがあるので伸びしろしかないな!みたいな気持ちです。

もっと承認欲求を満たせるように会社でもそうですが会社外でもプレゼンス発揮していきたいなーと思ってます。 最近京都にWeb企業が東京から進出してきたり、スタートアップ企業やベンチャー企業が微増してるように思うのでもっと活気がでて若くて優秀な人に協力したり、協力してもらいたいですね。

余談

ところで最近これが気になってるので誰かください。もしくは使用感のレビューを教えてください。

OKR シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

前半はストーリー仕立て、後半が解説というか一般的なビジネス書ライクな内容となっている珍しい構成だった。 読書時間は2時間半から3時間ほど。 思いの外、さっくりと読めるので通勤などで毎日行き帰りで読んでいれば一瞬で終わる。

何故読もうと思ったのか?

もともとrebuildfmかなにかでOKRの話しを聞いて気になったのでKindleで購入だけはしていたというのが始まり。 購入はしたものの決して優先順位は高くなかったので放置されていたのだが先月、会社の月次MTGでMission/Vision/Valueをアップデートします!という報告があり、その一環としてOKRの導入を検討しているということを聞いたので直接的に読み始めた大きな理由。

当初考えていたことと実際読んだあとで感じたことの差分

当初読む前はOKRというビジネスフレームワークの話しなんだろうと考えていた。 アジャイル開発とかウォーターフォールとかスプリントとかカンバンとかの1種かなと思っていたのだけど実際読んでみるとビジネスフレームワークというよりは「目的を達成するためのフレームワーク」なのかなという印象を強く受けた。 スプリントだとかよりももっと広い範囲をカバーしてくれる柔軟なフレームワークだなと感じた。

会社やチームだけでなく個人の目標、例えば「今年ダイエットして痩せるぞ!」みたいな目標にもマッチするフレームワークだなと感じた、及川卓也さんの解説でも「個人的な目標達成にも大きな効果」という項目があり解説されているのでその印象は間違っていなかったと思う。

さらに読む前に勘違いしていたなと思ったのはこのOKRというフレームワークはぼくが考えている以上にシンプルで力強いものだった。 OKRはObjectives(目標)とそれを達成するのに必要なKeyResult(重要な成果)というシンプルな構成になっている。

本書を読むとわかるし、本書を読まなくても恐らくネット上にさまざまな情報が転がっていると思うんだけどこのOKRというフレームワークで大事なのは「常に計測し、目標に対して前進しているのか後退しているのかを定かにする」というだけ。 つまり「今期はこれを目標にするぞ!」というコミットメントに対してどういう成果があればその目標が達成できたとわかるのかを表す成果としてのKRを設定する、そしてそのKRの結果を振り返る。ただこれだけ。すごくシンプル。

シンプルと書くとイージーなのかと思う人が一定数いると思うのだけどこのシンプルを維持し続けないと意味がない、そしてシンプルを維持するの結構難しい。 またこのKRには挑戦、つまりコンフォートゾーンの外にでることが含まれるのでよく日本の大企業で「成長を実感できない」という嘆きをみることがあるんだけどそういう心配が減るのではないかなと思う。 OKRの本を読んで思ったんだけどこれはぼくのようなある程度社会人になってから時間が経っている人よりもこれから学んでいくぞ!という新卒だったり学生の方が効果が高いんじゃないかなという気がする。

OKRの詳しい内容は↓にGoogleがre:Workにまとめてくれているので本を買うのはなーという人はこれを読むだけでもいいかもしれない。 職場などで広めたいというときにもこのドキュメントはすごく役に立つんじゃないかと思う。

rework.withgoogle.com

$shibayu36->blog;の1on1テンプレートがめちゃくちゃ優秀でいいぞ!という話し。

blog.shibayu36.org

1on1でいつもメモをとっているのだけど以前読んだ id:shiba_yu36 さんのテンプレートシートを少しカスタマイズして使うようにしたところ、思いの外使いやすいのでみんな使ってくれよな!と思ったというお気持ち表明です。

カスタマイズした箇所としては「前回の1on1後にやるアクションの経過報告や結果」を最初に追加しただけ。

個人的には相談内容からの雑談派生が割とぼくは発生するので「話したいことなんでも」項目はなくてもいいかもしれないなぁと思ったくらい。 ただなくすにはもったいない項目だなとも思ってはいるので、なにか話したいことがあったときだけ追加するみたいなオプショナルな項目でいいかも。