$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

「初速思考」再読した

最近仕事で新しい領域のことをやり始め、新しいことの連続で全然思考が追いついてない。思考が追いついていないためか、うまく仕事から学べていない実感もある。これはいけないと思って、そういえば知識の定着の方法として参考になるよと紹介されて読んだ本があったなと思い出したので「初速思考」を再読した。表紙から見ると「The ビジネス書」って感じだが、今だからこそ参考になる良いことが書いてあり、読んで良かった。


まずこの本で紹介されている一行振り返りという習慣が非常に良い。これは自分が経験したことから学ぶために、仕事をやっての振り返り(ここが良くてうまくいった・ここは改善するともっと良くなるなど)を少なくとも毎日一行は書くというもの。振り返りを頑張ってしようとしすぎると大変でやらなくなることも多いが、一行なら2~3分で終わるし継続できるでしょと書かれていた。

また、例えば1~2週間に1回など定期的にこの一行振り返りを見直して、自分でカテゴリ分けしてアクションリストのようなものにまとめ直すと良いと書かれている。これにより特定の業務(例えば1on1とか)に対する自分の工夫がまとまるようになり、その後その業務を行う前に該当のアクションリストを読むことで仕事の質が上がるという。

確かにこのようなことをすると経験が言語化されて、その後時間が経ったとしても再現可能な状態にすることが出来ると感じた。しかも前回読んだときに少しだけ一行振り返りを実践していたらしく、それを読み直したらまさに「知見」という感じだったので、この習慣は実践したいなと感じた。


またこの本で、新しい種類の業務を始めるときは自分が得意 & 結果を短時間で出せるタスクをまずやれと書かれていたのも印象に残った。とにかく初速を出すのにこだわれ、新しい業務になったとしても以前の経験が活きる場所を見つけ結果を出せという感じ。新しい業務に取り組む時には早めに何か見える結果がある方が、自分のモチベーションも上がり上司からの信頼も得られて動きやすくなると書かれていて納得した。今後意識したい。


以上二点がこの本で印象に残ったことでした。今の時期に読めて良かった。

読書ノート

  • とりあえず1日一回はリマインドが入って、今日のうまくできたこと、改善できそうなこと、すごいと思った出来事からをキックに振り返るというのをやりたい
  • 1週間に一回くらいカテゴリ分けしてアクションリストにしたい
  • まず見える結果を出すことが大事!信頼感が生まれる
  • 成功を振り返り、成功要因を分析して、ラッキーもラッキーで終わらせない 1024
  • 状況と行動と結果でメモすると良さそう
  • 仕事のやり始めは、短時間で終わり結果が出る(結果の量に問わず)ものにフォーカスする。自分の得意分野が活かせるものにする。また優先度は上司と間違ってないか確認して進める 1525
  • はじめて経験する仕事は、すでにやった人に助けを借りる。最初に何をしましたかは良い質問 1573
  • 経験知を言語化しておかないと忘れて再現不能になるよなーと再認識。言語化しよう
  • 組織の変革をするときは、急激に方針を変えすぎない 1984

ISUCON8予選を突破した

id:hitode909id:takuya-aとチーム「ディメンジョナルハイソサイエティぬれねずみ」としてISUCON8に参加し、40867点で本戦に行けることになった。ISUCON初参加でいろいろ不慣れではあったが、なんとか本戦に行けて嬉しい!

サーバ複数台構成かつボトルネックになる箇所が結構面白いところが多く、非常に楽しめました。運営の皆様ありがとうございました。

振り返りとして、チームでやったこと・良かった進め方をまとめてみる。

チームでやったこと

開始直後は役割分担して作業していった。言語は勉強がてらgolangにしようと思ったこともあったが、せっかくなら勝ちたいし慣れてるperlにした。

  • shiba_yu36: 鍵置いたりコードのバックアップしたりなどといったオペレーション周り
  • 他二人: アプリケーションの挙動を確認し、作戦を立ててもらう


以下が最初のオペレーションでやっていたこと。


作戦会議の結果、まずはget_event周りのN+1クエリをなんとかする、またサーバ構成はDBがボトルネックっぽいし普通にapp二つとdb一つで良さそうということになった。

  • get_eventのN+1クエリ直す diff
  • サーバ構成を変える。DBボトルネック感あったので、app2台、DB1台に。isucon01をdb、isucon02をapp、isucon03をnginx + appにし、ベンチは03に向ける。
    • diff1
    • diff2
    • ここでGRANTの設定がおかしくて他サーバからDBにアクセス出来なかったので、init-user.shを参考にGRANTをした
    • /initializeがDBサーバと同居な前提だったため、これだけisucon01に固定で行くように。今から考えると、これはinit.sh周りを修正するだけで良さそうだった diff


さらにpt-query-digestsで集計して発見した遅いクエリを調整したり、sheetsのメモリキャッシュをしたりした。

  • N+1クエリ直した後のクエリにインデックス効かせるように diff
  • ORDER BY RANDやめる -> diff
  • reservationsのuser_idにインデックス -> diff
  • sheetsをメモリキャッシュ -> diff


このあたりでISEによって負荷レベルが上がらないという事態に遭遇する。エラーログを見ているとデッドロックが原因に見えた。そこで出来る限りロックを取らなくてすむようにFOR UPDATEいらないところは外してはと会話した。特に/api/events/{id}/sheets/{rank}/{num}/reservationでのロック範囲を最小限にするためにクエリを二回に分けてはどうかというid:hitode909のアイデアが良くて、これによってスコアが安定した気がする。


ただFOR UPDATEを外すというのをやったことにより、全体レポート生成(/admin/api/reports/sales)が同時に動くことが多くなり、その結果アプリケーションプロセスがOOM Killerで殺されるということが起こってしまった。これは辛いけどFOR UPDATEでロックは取りたくないねということでMySQLのGET_LOCKを使って並列度を下げてみることに( diff )。これによりOOM Killerに殺されることがなくなった。

/admin/api/reports/salesがメモリを異常に食ってしまう問題があったので、その修正に取り掛かる。アプリでソートをしているのをやめてみたり、オブジェクトを作らないようにしたり、文字列連結を少なくしたり、最初に領域確保してみたりということをしてみたが、あまりうまく行かなかった。


このあたりで残り30分くらいとなったので、ログ周りをoffにして、再起動試験をした。ここでfinish。うまくいくと40000ちょっとくらいになっていたので、行けるか行けないか微妙なところだなとなっていた。


終結果は40867点。両日3チームを除いた上位12チームに入っていたので本戦に行けることになった。

良かった進め方

  • 開始前に出前で寿司とったのが良かった。途中で寿司を食べながら一旦落ち着いて作戦会議できて、次の対策が思いつくなどの出来事があった
  • 開始後やることまとめておいたのが良かった。
    • f:id:shiba_yu36:20180917011739p:plain
  • rsyncデプロイにしたのはかなり良かった。git commitしなくてもデプロイ出来て素早さが増した
  • 1時間くらいアプリケーションを観察しながら、アイデアリストをホワイトボードに書いていき、いろいろ出揃った後に良さそうなものをピックアップして進められた。結果、最初に効果的な対策を打てた
  • ベンチマーク結果のログをちゃんと読み込むことで、負荷レベル上げられない理由から潰すことができた
  • 3並列でボトルネック解消ってそこまで出来ないと判断し、コード書くのは2並列にして、片方はペアプロするとした。ペアプロすると変なハマり方を減らせ、高速化していたので良かった
  • 15:00くらいに一回再起動試験をしてみたことが良かった。やってみるとisucon01以外のサーバでアプリケーションがenableされてなく、再起動するとプロセスが立ち上がらないということがわかった。もし終了直前だった慌てて原因が見つけられたか分からない。

最後に

改めて運営の方、非常に楽しい問題を作ってもらってありがとうございました。これまでISUCON出てなかったのもったいなかった、今後は絶対毎回出ようと思えるほど楽しかったです。本戦も頑張って優勝したい。

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

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

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

読んだ。OKRのエッセンスについて短時間で学べたので良かった。前半にOKRを導入したら一回失敗して、その後やり方を変えたら成功したという小説仕立てのストーリーがあり、失敗する理由と成功する理由を実感を持って学ぶことができる。その後、後半ではOKRのフレームワークについての詳細の説明があるため、前半の具体例と紐付けて理解することができた。

印象に残ったのは、OKRと人事評価を密接に結びつけるなという話と、導入するときは必ず一度は失敗するから小さく始めろというところかな。

この本ではOKRでの目標設定と、人事評価を密接に結びつけるなと書いてあった。それ自体はある程度納得できるが、その場合評価制度の中のレーティングの役割はどこに持たせたら良いか悩むなーと思った。上司が部下の給与をある程度の裁量を持って決めるようにすると、OKRが評価に関わらなくてもうまくレーティングできそうかな?もしくは成果による評価割合を減らし、会社の行動指針やスキルでの評価を重めにするとかの方法も考えられるかもしれない。

導入ガイドも書いてあったけれど、もし導入するなら必ず一度は失敗するので、特定チームに適用するなど小さく始めると良いと書かれていた。どんな取り組みも小さく始めて早く失敗するのが大事だよなと再認識。

OKR勉強になりました。OKRすごくいいなーと思いつつ、MBOの制度が浸透している状況でOKRにシフトしていくのどうしたらいいかな〜と思ったのであった。

読書ノート

* OKRの基本 1347
	* Oは人を鼓舞するような定性的なもので、かつ期限付き(3ヶ月)、
	* KRは定量的な測れるものを3つ。ただし達成できるかどうか半々くらいに
* OKRは毎週の定例に組み込み、自信度を50%に調整し続ける 1431
* OKRの実行を習慣に 1519
	* 毎週月曜にOKRをチェックする。今週の優先事項3~4つ、OKR自信度状況確認、健康・健全性指標の確認
	* 金曜はウィンセッションで出来たものを褒め称え、モチベーションを上げる
* OKRを決めるときの問いかけ集 1604
* KRはポジティブになるようにする 1629
* チームOKRを作る際に、メンバーに先に自分が考えるチームOKRを考えてもらうと、自分ごと化される 1650
* OKRの本質は継続的な学びのサイクルなので、達成できなかったらその理由を学び、達成できすぎてしまったらもっと厳しいゴールは何かを考える 1668
* OKRの最初の挑戦は必ず失敗するので、失敗したときのリスクを少なくするアプローチを取る。例えば以下のものがある 1687
	* 全社のOKRを1つだけ決める
	* 全社の前に1チームでだけOKRを利用する
	* OKRを1プロジェクトで適用する
* OKRを使った週次情報共有フォーマット 1778, 1819
	* チームのOKRと自信度、優先タスクと達成されたか、来週の最優先事項3つ、リスクや障害、メモ
* よくある失敗 1820
	* 四半期のゴールが多すぎる -> ゴールは一つだけ、全従業員が覚えている明確なものに
	* Oに数字を入れてしまう -> Oは人々を鼓舞するような定性的な目標に。数字はKRで
	* 自信度レベルの設定を忘れる、追跡を忘れる -> 自信度を50%に保つことが大事。週次でも確認
	* 金曜日に厳しい話をしてしまう -> 金曜はあえて楽しくやったことを褒め合う。厳しいことは月曜に
* OKRを使ってゴールの持つ力を高めるには 1880
	* ゴールを達成したかが評価に密接に関わると、従業員は天井を低く見積もるようになる。なので評価とは切り離し、ゴールで可能性を最大化できるようにする
	* 成果の達成はリアルタイムで見ておく。さらにゴールは身近な存在にする。そうしなければみんなゴールを忘れ、方向がぶれたり、実行されなくなる。
* OKRの活用のヒントいろいろ 1927