$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

ストレングス・ファインダーをやった

book

自分の強みを改めて知りたいなと思ってやってみた。

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

Amazon


強みトップ5は次のものになった。

  • 1. 個別化: 個別化という資質を持つ人は、一人一人が持つユニークな個性に興味をひかれます。異なるタイプの人たちの集団をまとめ、生産性の高いチームを作ることに長けています。
  • 2. 学習欲: 学習欲という資質を持つ人は、学習意欲が旺盛で、常に向上を望んでいます。特に結果よりも学習すること自体に意義を見出します。
  • 3. 分析思考: 分析思考という資質を持つ人は、物事の理由と原因を追求します。状況に影響を与える可能性のあるすべての要素を考慮に入れる能力を備えています。
  • 4. 内省: 内省という資質を持つ人は、頭脳活動に多くの時間を費やします。内省的で、自分の頭の中で考えるのが好きで、知的な討論が好きです。
  • 5. 規律性: 規律性という資質を持つ人は、日課や秩序正しい計画に従うことを好みます。世界は自分が作った秩序の中に存在します。

いろいろ読んでみて強みを自分の言葉にまとめ直すと

  • 人の良いところを見つけられる。その人にあったタスクを割り当てたり、その人に合ったやり方を提案できる。
    • タスク差配やメンタリングは好きなので役立ってると感じる
  • 考えることが好き。学習が好き。特に書籍を参考にする。何かを始める前に時間をかけて準備をし、自分の中で納得したい。
    • 新しいことを始める時スタートダッシュが遅いが気づいたら自分の中でかなり体系化できているのは、このあたりの強みが活かされていそう。
  • 自分の中で緻密に計画を立てたい。やったことは標準化して再現可能にできるようにしたい。
    • 計画立てないと不安になるし、計画によってうまくやってきた気はする
    • また自分の通ったところはその後は誰でもできるように整備されているので、この辺の強み活かされていそう


なぜかあまり深く考えなくともうまくできるなと思っていたところが実際に強みとして言語化されるのが面白かった。より活かせるようにしていきたい。

「初速思考」再読した

tech book

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

[asin:B00F3851YE:detail]


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

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

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


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


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

読書ノート

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

ISUCON8予選を突破した

tech

id:hitode909とid: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出てなかったのもったいなかった、今後は絶対毎回出ようと思えるほど楽しかったです。本戦も頑張って優勝したい。