#ISUCON9 に一人チームで参加してきた

結果

2,410  うまいご飯が食べたい (一人チーム) で敗退でした

詳細

  • 10:40 サーバが10分立っても立ち上がらずに若干焦る。この間にレギュレーションの再確認
  • 10:50 ようやく3台立ち上がったので、gitとかsshを仕込む。
  • 11:00 3台あるので、2台APサーバ・1台をDBにしようと決意
  • 12:00 MySQLのbindの設定で5分ほどハマるが大したことはない
  • 13:00 APサーバの冗長化はできた(Redisを入れることを忘れてた)
  • 14:00 Redisがなぜか aptからうまく入らない...
  • 15:00 APサーバを単に冗長化すると画像がうまくとれないので、冗長化を諦める(ここは後で特定URLだけ1台にすればよかったと気づいた)
  • 17:30 コード改善を諦めてindexを貼る作戦に移行する
  • 18:10 終了。

感想

とにかく一人は手も、アイデアも全てが足りないということを再認識させられました。2年前にチームで出たのですが、個人戦だと全然違ってました。終わってからこうすればよかったと気づいたので、適度な休憩が必要でした。チームでの開発の大切さを再認識と同時に個人で全部やることの楽しさを実感。講評を見ずにどこまでコードのボトルネックに気付けるのか、直せるのか再度挑戦する予定。こういうイベントは非常にワクワクして楽しい。

運営の皆様ありがとう & お疲れさまでした

正しいものを正しくつくる を読んでいる

第3章まで読んだので一旦ブログをまとめる

前提など含めたまえがき

自分は15年弱ぐらいエンジニアやっていて最大でも10人ぐらいのプロジェクトでリーダーをやることが多かった。SIer〜自社サービスとやっている。また、アジャイルでのプロジェクトはあまり経験なくほぼ自己流でやっている。アジャイルコーチやスクラムマスターなどがいたプロジェクトにはいたことがない。

感想

1つの守・離・破の形としてはすごいいい本だと思った。自分がプロジェクトを進める上でできているところ・できていないところをトレースしやすく、このプロジェクトだとここはできてたな、このプロジェクトだと反対にうまくできてなかったなというのが考えやすい気がした。

第2章でのスクラムのコンセプトを推し進めるために5つの価値基準(確約、勇気、集中、公開、尊敬)があるというのが自分の中で印象に残っていて、よく振り返りでKPTで何を振り返ればいいのかよくわからなくなるときがある。(特にKeep)この5つの価値基準を軸にするといいかもしれないと思った。

第3章も自分ではなんとなく「こうしたほうがいいだろうな」と思ってやっていたところを言語化されていたり、ベロシティの計測などできていなかった部分が明確に気づいた。

自分が特にできてないなと思ったところ

  • スプリントの強度の高め方。成功体験は徐々にやっていったほうがいいというのはわかるがどこで強度を上げるか
  • 見積もりのやり方。相変わらず見積もりが下手くそ
  • 余白の使い方が下手なので、調整の余白の使い方は参考にしたいと思っている。広さと深さは意識するようにしたい
  • 言語化、単語化、メンバーに意識をしてもらうところが毎回うまくできてない。自分の経験値で進めてしまっているところが多々あるのでもう少し周りに単語化をして背景含めて明確にしたい

メモに色々書いたけどうまくまとめきれないので自分で書いたメモをまた読み返そう

AWS Solutions Architect - Associate に合格してきた

資格試験なんか 約1X年ぶりに受けたから緊張した

なぜ受けたのか

会社や前職でもAWS使っている(た)し、AWS Summitのラウンジで優遇されたいなーという思いから受けてきた。今年は幕張メッセだから少し萎えてるw あとは都合で時短勤務をせざるを得ない状態なので勉強する時間ができたというのが理由

勉強時間

大体1ヶ月ぐらいだと思う。ただし常に勉強できるという状態ではなかったので毎日はやってない

試験を受けての感想

試験受けて合格したときはホッとしたけどこれをうまく使わないと&アップデートしないとなぁという思いが湧いてきた。結局AWSとかしょっちゅうアップデートされてるからその時の知識はその時の知識としていいと思うんだけど追従しないと腐っていく知識が多い。(実際に問題集とか見たときには古い情報とかあったし)まぁ「他の人よりは俺AWS好きだよ」ぐらいに捉えておいてもいいと思う。

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. これはまだ確認してないが、おそらく引っ越時にも使えるだろう

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