OKRの本はメンバーが読むには最適の本

感想

記事タイトル通り、導入する会社側が読むのもいいとは思うが、どちらかというとメンバー側がOKRがどういうもので、何をやっていけばいいのかなーという全体的な流れやそれによって自分たちが今と何を変える必要があるのか/ないのかを考えるには最適な本だと思った。サマリはみんな共有できればいいと思うんだけど会社でなにか勉強会的なものやるのかな。それともやったほうがいいかな |д゚)チラッ

OKRを導入する目的、手法、どうやってトラッキングしていくかという一通りのことが書いてあった。今までの会社では目標と実際の仕事と評価が乖離するということは多々あって、過大/過小評価されることが多かったが自分の中ではこの手法は現実的にしっかり評価できるイメージが湧いた。決める・ワークさせるところが恐ろしく大変そうだけど。

自分が一番共感できたのはプロダクト・チームのOKRのところ。うちも職能のチームとプロジェクトチームのクロスファンクショナルチームになっているので、OKRを決めたら板挟みになる(優先度P1のタスクが並行して2つある)みたいな感じになるので、どうすんだ?という話になるところの明確な解が出てた。ただし、自分プロダクトチーム以外の人事にも関わっているのでそこはどうすんべか。去年はここの優先度付けを間違えた気がするので改善していきたいところ。

また、OKRを立てるためのスケジュールの章では最初に「全員に次四半期に追求すべき目標を出してもらう」とあったが、オープンに会社の数字やプロダクトの状況、課題を見えるようにしてないと自チームだけ、自部署のみの狭い目標しか出てこない気がするがそれは微妙な気がしているので、OKRの最初に立つためにも色々仕込みは必要そうな気はした。

あとやっぱり iPadMini + ApplePencil 便利やわ。メモアプリに全部書いて色々思考をまとめられる。本の文章を書き写しているのでメモを公開すると著作権的に引っかかる可能性はあるので公開するとはしないけど見直すのに便利だ。

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

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

管理ゼロで成果は上がる を読んだ

管理職=マネジメントとなりがちだけどこの本を読んで違うんだなぁと再確認した。

全体的に読んでて自分も管理職の存在に疑問符を持っている(が、一応現職管理職なんだけどw)ところに、少し光明が見えたが、うちだとどう当てはめられるんだろうなぁという疑問符も新しく出てきた。

作業ではなく、仕事をしてもらうことによりメンバー各自が考えて行動をするというのはすごい難しいんだろうなぁと思う。色々な会社はベクトルが広すぎてみんながバラバラになりやすいので、管理職というのが置かれていると思っている。なので、ベクトルを狭くすれば管理職をなくせるのではないか?と思うが、会社としてベクトルを狭くするというのは難しいんだと思う。

ただ、管理職をなくすというよりも、どのように気持ちよく働いてもらえるかという指針にはなったのかなぁと思う。例えば評価も今はevaluationになってるものをassessmentにしたり、期待値を合わせたり。

振り返りの方法もやったこと、わかったこと、次にやることもきちんと筋道立てて示されて自分の中できちんと言語ができておらず空白になってた部分を補ってくれた。

あと、管理よりも採用コストに割いているというのはすごいなーと思った。確かにそちらのほうが初期コストは高いかもしれないけどトータルコストは低い気はする。ただし、一人あたりのコストは高そうだ...それこそもっと採用にタッチする人を増やさねば。また、人を見極める4つの指針(Technique, Intelligence, Personality, Speed)がきちんと可視化されてるのはすごいと思った。

そういう意味で管理するのではなくメンバーのモチベーションなどをマネジメントしていくのは必要なんだろうと思う。

色々メモってるけどなんかうまく文章にまとめられないので気になった部分が会話できればいいと思う。結構自分は部署をまたいでガンガン行くタイプ(というか、全部知りたい)なので、その動き方で間違ってない、正しいんだ。と勇気づけられる本でした。

RubyとRailsの学習ガイド2019は初学者のための世界地図だ

一緒に働いている 五十嵐 さんから頂いたので読んだ。

初めてRuby,Railsを使う人向けの地図だった。1ツールだけであればGettingStartから読んでドキュメントを読むが、Ruby,Rails(というか昨今のWebアプリケーション)は本当にやることが多く、どこから手を付けていいか途方にくれることがよくある。その中で世界地図になる本だった。

各地方地図は各専門的な内容は既に著名な本が出ているのでそれらを紹介しつつ、Webアプリケーションを作るために抑える技術を網羅してあった。また、初学者は細かい字でズラズラと書いてあるとつかれるので比較的大きな行間で書かれていた。以前頂いた五十嵐さんの共著 ゼロからわかる Ruby 超入門 はじめてのIT技術講座 も本当に初学者が疲れないように書いてあったので、本当に気にしているのがよく分かる本だった。

なので、これからRailsを初めようという学生さんや、ちょうど4月なので新人研修をする人が、まず自分たちが踏み込んだ世界の一部を見るためには本当に良い本だった。まぁ、本書に書いてある内容地図はワンピースでいう「東の海」であり「偉大なる航路」ではないので、ラフテルへの到達方法は各自で探せる楽しみは残っている

10年ぶりぐらいに洗濯機を買うときに便利だったもの

ついにドラム式選択乾燥機を買ったがそのときに便利なものがあったので残しておく。 お店でゲットできるこの設置スペース確認シートだ。電気屋にあって、パナソニック、日立は出していた。シャープは見つけきれなかった

f:id:hs_hachi:20190414103825j:plain
設置スペース確認シート表紙

ちょっと画像汚いが、シートの中身はこの様になっていて各型番ごとに必要な長さが メジャー付きで 書いてある。

f:id:hs_hachi:20190414104001j:plain
シートの中身

何が便利かというと

  1. 当然、購入前の下調べに必要なサイズを測る必要があるのではいる・はいらないの確認ができる
  2. 実際に業者さんが取付時に取付可能か確認するときに実際の製品スペックと取り付け場所を比べるときに便利
  3. これはまだ確認してないが、おそらく引っ越時にも使えるだろう

ということで、カタログだけではなくむしろこっちの紙をもらって保証書と一緒に保管しておくと良いと思う。

iPad mini 第5世代を買って読書が捗る

今まではiPad miniの第2世代を使っていてストレージサイズが足りなくなってきたり、動きがもっさりしてたので、先日発売された ApplePencil 対応の iPad miniを買った。

www.apple.com

iPad Airを買おうか少し悩んだけど自分が持ってるボディバッグにもラクラク入るので結局miniにした。当初は動画を見るのを中心に考えていたが、(そのために画面に集中しやすいフレームが黒いスペースグレイを買った)、思ったよりも読書する時間が増えた。

今まで電子版の本を読んでもその辺のノートに書いたりDropbox Paperに書いたり色々していたが、ApplePencilを買ったことでデフォルトのメモアプリに統一した。(ちなみにGoodNoteも使ってみたが、MaciPhoneiPadで楽に同期を取ることを優先したので使ってない。)どうせ一度に読める量はたかが知れてるので、下のキャプチャのように半分は本、半分はメモにしてる。キーボードで打つよりも自分の手で書くほうが自分は記憶に残るので今の所このスタイルが合ってるぽい

iPadMini画面

Railsで検索条件を指定するときはプレースホルダーではなくHashにしたほうがいい

文字列の場合

下記の場所で タイムゾーン考慮処理と、 DateTime#to_s を呼び出しているので時間まで残る

def quoted_date(value)
  if value.acts_like?(:time)
    zone_conversion_method = ActiveRecord::Base.default_timezone == :utc ? :getutc : :getlocal

    if value.respond_to?(zone_conversion_method)
      value = value.send(zone_conversion_method)
    end
  end

  result = value.to_s(:db)
  if value.respond_to?(:usec) && value.usec > 0
    "#{result}.#{sprintf("%06d", value.usec)}"
  else
    result
  end
end

rails/quoting.rb at e53430fa9af239e21e11548499d814f540d421e5 · rails/rails · GitHub で呼ばれているメソッドより抜粋

Hashの場合

こちらは DateTime#to_date を呼び出しているので、時間は切り落とされて日付だけが返却される

def cast_value(value)
  if value.is_a?(::String)
    return if value.empty?
    fast_string_to_date(value) || fallback_string_to_date(value)
  elsif value.respond_to?(:to_date)
    value.to_date
  else
    value
  end
end

rails/date.rb at e53430fa9af239e21e11548499d814f540d421e5 · rails/rails · GitHubより抜粋

いつから入ったのか?

どうもこれっぽい。

github.com

本来はどうあるべきなのだろうか

MySQL5.7で検証しているが 2019-02-132019-02-13 00:00:00 にしても検索結果はヒットする。しかし、しかし、MySQL5.6時点の MySQL :: MySQL 5.6 リファレンスマニュアル :: 9.1.3 日付リテラルと時間リテラル を見ると 2019-02-13 == 2019-02-13 00:00:00 とはどこにも書いてない。Date型は日付だけを持っており時間を持っていないので当たり前だが。

DBという固く設計・実装すべき方に合わせるほうが良いので、プレースホルダーの方を日付型にすれば良いと思ったが、下記で話をされている通り、そちらはカラムの型を持っていないのでDatetimeなのかDateなのかわからないため変換ができない。

github.com

アプリケーションエンジニアができることはなんだろうか?

テストかけ

Classi Angular Night #1 を開催しての感想

connpass.com

Angular日本ユーザー会との共催で開催しました。関係者の皆様改めてお礼申し上げます。

身内だからというのも若干あるんですが わたる (@kasaharu) | Twitter が事例を話してくれて、派手さはないけど、正しく、奇をてらわずに作ってくれていることへ対してみんなが反応してくれていたのが一番印象に残りました。

難しいのはわかるけどそれをやらないと何年後かの自分たちが絶対に苦労するのは目に見えている(実際現在進行系で苦労してるし...)ので、自分たちがやっていることが決して間違っていないということを再認識しました。そういうのがきちんと評価したいし評価されたいですね。

帰り道にlacoさんとお話していて(酔っていたので若干異なってるかもしれないですが...) 仕事でAngularがこれだけ使われていて安心して使える。そしてどういうケースはAngularが適しているのかという事例を出していきたいですねーという話をしてくださいました。

仕事という実戦の中でエンジニアの技術力は磨かれていくと思っているので(もちろんそれだけではないけど)、仕事で個人の技術力上げる→ よいプロダクトを提供する→その知見をコミュニティに還元する みたいな循環ができれば、個人、企業、コミュニティともにwin-win-winになると思っています。

一例だと今のリプレイスプロジェクトはmultiple projects を採用してるのですがこれはng-japan 2018(at Google)で知ったものです。今はmonorepoで作るというのと将来的にはマイクロサービスとして分割していく可能性は非常に高いのでそこを意識して機能ごとにパッケージは別けたいというのはシステム作成時の制約として決めていました。

しかし、当時は最良の解決策を持っていませんでした。発表を聞いた直後にGoogleの食堂で二人で「いける?」「いけそう」というのを試してたのは今でも覚えています。

また、そのときに初めてAngular日本ユーザー会へ会社がスポンサーをしてくれたのですが、そこでうちに興味を持ってくれた学生が4月から社員として入ってくれる事になりました。もちろんAngular以外で作っているシステムもあるのでそういうのも知った上で入ってくれますし、大変なところも承知した上で入ってくれます(多分)。

そういう事例を作って循環の輪を作っていければいいなぁとは思います。