2021年振り返り

年の瀬なので振り返っていく。

仕事

振り返ると充実してたように思う。脳をいっぱい回転させたし学びも沢山あった。あといろんなことをやり切れた実感がある。でも正直、大変なことも沢山あった😇

昨年末にロジレスに転職したので、今年はロジレスで正社員として過ごした一年だった。

ロジレスではCTOに次ぐ2人目エンジニアかつ、社員数も少ない状態だったので、本当に色んな役割で仕事をしたように思う。元々はSREをメインのロールとして期待されていたのでそこは当たり前にやったのだけど、コードも結構書いたし、事業戦略から逆算してシステムや開発組織がどうあるべきかを考えたり、人が増えていく中での開発フローを考えたり、Job descriptionを書いてエンジニアの採用を進めたり、振り返りを推進してたり、メンバーやCTOと1on1したり、カスタマーサポートをやったりなど、本当に色々手を出したなーと感じるが、必要に応じて都度役割を変えることが一番自分のパフォーマンスが出ることだとも思っていたし、実際に成果も出たので良く頑張れた1年だったのではないかと思う。

特にSRE系の業務が意思決定含めてとりあえず僕に任せておけばいいという状態になったのは良かったと思う。プロダクトの仕様を考えるところから実装やカスタマーサポートまでずっとCTO一人でやってきた中で、最近はバックオフィス系の業務やプロダクト開発の組織や評価者としての役割まで求めらるようになり、明らかにキャパオーバーなのは状態ではあったので、完全に手離れするものを一つ作れたというのは地味だが大きな進捗だったように思う。

あと今年は人の背中を沢山押した一年だったようにも感じる。

ロジレスはプロダクトがすこぶる順調に伸びていて、それ自体はとても嬉しいことである一方、組織や個人としては変化が求められることが多かったように思う。

こうした変化には不安やハレーションは付き物で、これらを回避するためにどうしても現状維持やその場しのぎを選択してしまいがちだが、その選択は多くの場合問題の先送りでしかなく、むしろより大きなツケとなって後に支払わされる時がくる。

そうならないようにするため、現状維持の誘惑に抗いながら都度変化していく必要があるのだが、これを一人で実践するのはとても難しい。なので1on1などを通してなるべく伴走することを意識した。

具体的には、話を聞き、共感し、不安を可視化し、対策を一緒に考え行動可能な状態にして、また課題にぶち当たってもらい話を聞き…を繰り返すといったこと行ったが、これが後押しになって起きたアクションが沢山あったように感じるので、結果的に個人や組織の変化を促すことができた実感がある。(同じくらい上手くできなかったと感じ悩むこともあった)

こういう取り組みは、時間もマインドシェアも奪われがちだし、僕らはまだ人数の少ないスタートアップなので、他者の変化やアクションを促すよりも自分自身がその部分を巻き取ってしまうことの方がコスパが良い瞬間もあると思う。ただ、僕はこの巻き取りによって、メンバー（特に初期からいるカルチャーを形成しているような人）のtry&errorの機会を奪うのはイケてないと思っている。今後どんどん優秀な人が採用されていった時に昔からいる人ほど優秀な人とのギャップに悩み居場所を失うからだ。カルチャーの核になっている人がいなくなった時に組織が受けるダメージは想像以上にでかい。あとは個人的な思いとして初期からいた熱い思いを共にした人が離脱せざるを得ない状況に追い込まれるのは単純に寂しいという思いと、今いる人達が変化出来ない組織が未来では変化できる理由ってある？という思いがある。

優秀な人とのギャップに悩むことになるのは多くはタスクアイデンティティの喪失であり、タスクアイデンティティの喪失は実務スキルが新しい人に比べて相対的に劣ることや、代替ポジションが無いことから生まれる。こうしたギャップが生まれた時に環境を変えることは一つの手だが、先に挙げたとおり強固な組織組成のためにはカルチャーの核になっている人が残れるに越したことはない。その一方でここへのフォローはあまり発生しないことには個人的に違和感がある。

もちろん致し方ないケースというのも多々あると思うが、カルチャーの重要さ、カルチャーが何によって構成されているかの理解不足、スタートアップとはそういうものだという固定観念や生存者バイアスなどから、安直に「お互いにとって退職がベスト」に繋がってしまっていないか？というのは常に気にしている。この判断もまた極めて難しい。

タスクアイデンティティは根本的にはその人のスキルが支えている。なので成長が必要であり、成長に必要な変化への抵抗をいかに無くするかが大事だ。多くの人は何が変化への抵抗になっているのかを自分1人で気付けない。もしくは気づいていても一歩を踏み出せない。だから他者からフィードバックされる場とそれを受け止めれるだけの信頼関係が必要だ。

少数ではあるが自分の周りに居る人達にはこういった場を提供できて、かつ一定成果がでたことはとても嬉しかった。あとこうした「背中を押す」スキルが上達した実感があったのはとても良かった。

2021年、自分の使命は果たせたのではないかなーと思う。

個人

娘

1番のトピックは娘が生まれたことだ。娘は本当にただひたすらに可愛い。同時に働き方や時間の使い方について改めて考えるようになった。界隈でもしばしば話題になるが、家族との時間を増やしていきたい気持ちがある一方、自分の成長が鈍化することへの不安はやっぱりある。僕の場合、仕事のマインドシェアの割合が高い状態であることによって、モチベーションが高く保てていた側面が大いにあるので、その割合が低くなったときにどうしていくかはまだ探り探りな状態だ。もう少し今の生活に慣れてくるとまた違ってくるかもしれないのでtry&errorしていきたい。

学び

今年見た本は以下のような感じ。

  • 恐れのない組織
  • 良く分かるACT
  • あなたのチームは機能していますか
  • １兆ドルコーチ
  • DMM.comを支えるデータ駆動戦略
  • プロダクトマネジメントの全て
  • 技術の創造と設計
  • 失敗から学ぶRDBの正しい歩き方
  • ユニコーン企業のひみつ

人の悩みを聞く中で、心理的安全や対人リスクが組織にどう影響を及ぼすのか、良い状態に持っていくためには何が必要なのか。悩みに悩んでネガティブな状態から抜け出すためには何をする必要があるのか。あたりの解像度をあげたかったのと、自分が所属しているチームや組織がどうあるべきなのかの解像度をあげたくて手に取っていた物が多い。この辺の話は今年一年でグッと理解度が上がったと思う。

特に、人間は他人の命がかかっている状況下でも対人リスクを避けてしまうことを優先するのだから、対人リスクを甘えであると考えるのは筋が悪い(自分自身が対人リスクを感じて何かできなかった時に甘えた行動であると辛くなっていた)と感じれたこと、人間のメンタル悪化は不安の無限ループから発生するから如何にループを止めるかを考えること、悩みは無限に湧いて出てくるものだから取り除くことを考えるのではなく上手く付き合う手段を考える方が良いということ、コーチャブルでは無い人間(厳密にはコーチングが効かないフェーズにいる人間)が世の中にはいるということ、あたりを知れたことは良い学びになったと感じる。

一方で技術的な学びは少なかったかもしれない。特段技術力を必要とする機会が少なかったこともたり、良くも悪くも手持ちのスキルでやれてしまった感がある。技術に関しては少し世の中にビハインドしてきている気もするので、来年はもう少し学びを増やしたい。

趣味

キックボクシングを始めた。大分太ってきたのと普通のジムにちょっと飽きたので何か新しい刺激を探してみたところ近所にキックジムがあったので入会してみたのだが、これが自分の中で大ヒットで今めちゃくちゃハマっている。フィットネスなのでスパーリング的なものはやらないのだが、サンドバッグやミットを思いっきり殴ったり蹴ったりするのがベンチプレスやスクワットには無い爽快感があったのと、練習していくに連れて徐々に自分のキックが強くなっていくことに達成感があるのと、程よく難易度があるのがちょうどいい。

僕の最近のYoutubeの検索履歴は「ミドルキック 蹴り方 ~~~」で埋め尽くされている。

来年はかっこいいハイキックを打てるようになりたい。

来年は

引き続き、家族と仕事どちらも楽しい時間になるように尽力していきたいと思います！

2020年 振り返り

今年も年末がやってきたので振り返る

今年はどういう年だったか？

2020年は良いことも一杯あったが、メンタル的にきつい時期が多かったなぁという印象だ。 新しいxxxというのが多くて、適応に苦戦したというイメージだ。

振り返りのために過去ツイートを眺めてたらこんなことを書いてた。いやー本当に今年は生きてるだけで偉かったと思う。

仕事

今年の初めはフリーランスで手伝っていたロジレスという会社で、色々活躍できたように思う。元々去年までは２社手伝っていたのだが、今年の初めからはほぼここ１社になっていて、やれることの幅が広がり集中できたので、楽しさが増したことが要因だったと思う。 ron4321.hatenablog.com

一方で去年の後半からEMとしてマネジメント一本で戦えるようになっていきたいという思いと、フリーランスという立場だと色んな所で線引きをしなければいけない感覚が煩わらしかったというのがあり、どこかの組織に根を張って活動したいと思っていて、EMというロールで働ける先を探していた。

EMとして働くにしても小さい組織での0->1を作るポジションだと今までとあまり変わらないので、今回は少し規模の大きめの会社でマネージャーとしてのフィードバックをもらえるような組織をもっていそうな会社に行こうかと思っていた。

いくつかカジュアル面談を受けていたら、意外とトントン拍子で話が進んで、4月にはフリーランスでお手伝いしてた会社を終了し、5月からはアカツキのEMとして入社した。

アカツキに入社を決めたのは、フィードバックをしっかりもらえそうだったこと、EMが複数人いて同じ目線で議論できそうだったこと、感情を大事にするカルチャーが好きだったこと、自分自身がゲーム業界の事業ドメインは詳しかったので貢献もしやすそう、PjMの知識や経験が積めそう、というところだった。

入社後は正直、大分苦戦したように思う。苦戦した要因は色々あるが、一番の要因としては、リモート環境で入社した中で信頼関係がうまいこと積み上げられなかったことにあると思う。 人と打ち解けたり、仕事上での関係性を作るみたいな部分はどちらかというと得意な方だと思っているのだが、考えてみると僕のソレはほとんどが物理でのコミュニケーションに依存していたし、リモート環境でどうやって担保すれば良いかは蓋を開けてみるとサッパリだった。色々悩みつつTryしてみたが中々パキッとは解決せず、現況だと時間をかける必要がありそうだと感じた。またチームや組織にとっても全員フルリモートは未曾有のチャレンジであり、そうした状況も複合して難しかったように感じる。 フルリモートワークはとっても難しい。

そういった苦戦はしつつも、CSMの研修を受けたり、ゲームのバージョンリリースのスケジュールやタスク計画を引いてリリースを主導したり、SREエンジニアの採用を要件定義から契約まで一気通貫でやったり、チームと組織に対してオンボーディングに関するフィードバックを行ったりと、楽しい瞬間も沢山あったように思う。

とまぁそんな感じでアカツキでEMやっていきだったのだが、実は11月にアカツキを辞め、12月からロジレスで正社員として働くことになった。

入社して半年程度しか経っていないアカツキを辞めて、ロジレスで働こうと思ったのは、

  • 元々、良い会社があればまたどこかでスタートアップには行きたいと思っていた。
  • 10人くらいのあらゆるものが整っていない今入るのが一番面白そうだった（もう半年たってしまうと面白さが半減してしまうかもしれなかった）
  • 毎週ロジレスのCTOと1on1をしていたので、入ったあとに活躍できるイメージもプロダクトが成長していくイメージもあった。腹を割って話せてたので信頼関係も積み上がっていた。他の経営陣ともちょくちょく話せたので、この人たちとなら0->1の組織を作ってみたいと思った。
  • 経営陣以外の今いるメンバーの人達も好きだし信頼感があった。優しい、利他的、他者や他職種との違いを意識したコミュニケーションをとれる人たちというイメージで、居心地の良さがある
  • ファイナンス面もある程度安心できた（資金調達もできてるし、売上もちゃんとついてきてる）ので、家庭へのリスクも少なそうだった
  • こんな良い状況での転職はまたと無いんじゃないかと思った

といったあたりだ。 一言で言うと「全然辞める気はなかったが、千載一遇のチャンスが来てしまった」からだ。 世がコロナじゃなかったらもっと迷ってたかもしれないし、選択しなかったかもしれないので、本当にただただ入社して半年後にタイミングが来てしまったというだけだった。アカツキはめちゃ好きだし応援してます。

ロジレスではCTOに次ぐ二人目のエンジニアなので、開発もガンガンやるつもりだし採用も組織づくりにも全てに手を出していくつもりだ。やらねばならないことが無限にあるし、課題もいっぱいあるが、着実に対処していけば良い未来が来るのが分かってるので前向きに楽しくやれている。

2020年は転職の決断を2回もしたそんな一年だった。

個人

個人的には、良く本を読んだ年だったように感じる。正確には数えてないが20冊くらいは読んだのではないだろうか。 読んで良かった本としては、

  • 「良い戦略 悪い戦略」
  • 「ザッソウ」
  • 「他者と働く」
  • 「なぜ弱さを見せ合える組織が強いのか」
  • 「アジャイルな見積もりと計画づくり」
  • 「マンガでわかる認知行動療法」
  • 「イシューからはじめよ」

このあたりだ。

特に「良い戦略 悪い戦略」「アジャイルな見積もりと計画づくり」「イシューからはじめよ」あたりは、仕事の役割上、計画を考えることが多かったのもあって学びが多かったように思う。

この二つの記事もとても参考になった。

aboutproduct.jp

megalodon.jp

実際の仕事でも、何か戦略であったりその計画を立てる時には、何が問題であるのかを正しく分析できるかが大きな変数になるので、何か課題を解決したい場合にも何事も現状を正しく把握することから始める。という振る舞いを強く意識するようになったように思う。 「推測するな計測せよ」は名言だなと改めて思った。

「ザッソウ」「他者と働く」「なぜ弱さを見せ合える組織が強いのか」「マンガでわかる認知行動療法」あたりは、リモート環境下でコミュニケーションや信頼関係の作り方に課題を感じていたことがきっかけで読んだ気がする。 細かくは色々あるが、得意な部分も苦手な部分も自己開示していくことが大事だということと、自分の強いところや弱いところを正しく理解することが大事だと感じた。つまるところいかに期待値をズラさない状況を自分の意思を介在させずにつくっていくかということだと思った。

来年はどうありたいか？

来年も公私共に新しいチャレンジが多そうである。ロジレスをめちゃくちゃよくしていきたい気持ちもあるが、同じくらい家庭も良くしていきたい。 きっとバランスに悩むので、関係する人たちと相談をしながらペースを作っていける、そんな状態を作っていきたいと思う。

来年も楽しく働くぞー

CSM(認定スクラムマスター)研修を受けた

CSM研修を受けてきたので、レポと感じたことを書く

なぜこの研修を受けたのか？

  • しばらくPMというかスクラムマスターというか、チームをサポートする仕事をすることが増えそうだった
  • 会社のEMの人たちがスクラムの話しを良くしているので、その輪の中に入りたいと思った
    • 個人としても良いプロジェクトマネジメントとは何か？について考えることが多かったので、良く知っている人たちと議論したかった
  • 軽いノリで受けてもいいか聞いたらOKをもらえた
    • まだ入社して２ヶ月弱の試用期間も試用期間という身だったので、懐の深い会社で本当にありがたいと思ってる

主な研修内容

受けたのはこの研修で、研修内容としては大きくこんな感じでした。

  • 事前学習
  • グループディスカッション/ワークショップ
    • スクラムの基礎を理解するためのディスカッション
      • セルフアセスメントシートをグループでディスカッションする
      • その他いくつかのテーマでディスカッション
    • チーム編成や組織編成を考える（コンポーネントチーム、クロスファンクショナルなチームの違いを理解する）ワークショップ
    • プロダクトバックログリファインメントのワークショップ
    • スクラムレファレンスガイドのクイズを作り、回答するワークショプ
    • LeSSを体験するワークショップ
  • ワークショップの補足的な説明
    • 講師の実体験からの説明
    • 動画での説明
      • マシュマロチャレンジ（経験主義の大切さ）
      • チョコレート工場で作業員がひた隠しにする（局所最適化の弊害）
      • etc...
  • アフターパーティー（任意参加）
    • 研修が終わったあとに時間がある人はどうぞというスタンスのQ&Aコーナー
    • 研修内容についてというより、現実世界での悩みに関して有識者に聞く場という感じだった
  • 認定試験
    • 研修後に行う
    • 50問のオンラインテストでちゃんと研修を受けて理解していれば難しくない
    • 日本語の翻訳がおかしくて分からない問題が2~3問あった

主に、事前学習で得た知識の理解をディスカッション/ワークショップ、講師からのフィードバックによって深めていく。ということ目的としていそうで、 座学のような時間はかなり短く、ほとんどがグループでのワークショップおよびディスカッションでした。（体感90%くらいはディスカッションでした）

コロナの影響によりオンラインでの開催で、ZoomとMiroを使って実施されています。

感じたこと

  • 解像度がグッとあがった
    • 用語の理解、各プロセスへの理解、思想、TDDやXPなど他のアジャイル開発手法との関連性などなど
  • スクラムは開発手法であり、思想であり、新しい働き方だった。
    • スクラムは経験主義に特化させたフレームワーク
    • 経験主義の実現には、クロスファンクショナルなチームをいかに作るかというのが、肝な気がしている
    • コンポーネントチームが主流な世の中とは、方向性が全然違う
      • 結果として、評価、組織設計なんかも合わせて変えないとワークしづらいと感じた
      • 世の中とズレているということは、そのチームに属した人のキャリアや市場価値が世の中とズレるということ -　既存の組織にあてはめる時にはそういう難しさがあるんじゃないかと思った
  • プロダクトバックログのリファインメントの難しさ
    • 「適切な単位（INVESTが満たされている）」のストーリーを作るということが肝になりそう。なのでリファインメントはかなり重要そう。
    • 「適切な単位」を作るには、かなり横断的な知識が求められるのではないか？
      • POがスーパーマンを求められる問題が出てきそう
      • ここをいかに関係者でサポートするかという課題がありそう
  • スクラムは個人的に目指したいものに近かった
    • 僕にとっての最高のチームの定義は、チーム全員が働くことへのモチベーションが高く、十分な給与が発生するだけの売上がたっており、不毛な争いが発生しなく（発生したとしても適切に対処できるスキルをもっている）、それらが持続的であること。
    • このために経験主義的なアプローチは必要不可欠だと考えていて、スクラムは一つの選択肢になり得ると思っている。少なくとも参考にできる点はかなり多いはずだ。
    • ので、これからもスクラムを継続的に学んでいくぞという気持ちだ

おすすめか？

  • スクラムについて用語はちょいちょい知ってるけど全体としての解像度はそんな高くない。くらいのレベルの人までにはオススメな気がする。それ以上だとやや退屈かも。
  • どの職種の人にとっても普遍的かつ有用な知識だと思うので、エンジニアに限らず、ビジネスサイドの人にオススメしたい。
    • この研修では多少エンジニア文脈の話しも出てくるが、大勢に影響は無いと思う

同じ研修を受ける人へのアドバイス

  • 事前学習はしっかりしよう
    • この研修は事前学習で得た知識の理解を深めることを目的としていそうでした。そのため、事前学習は前提条件になっているので、怠ると明らかに学習効率が落ちそうです。
  • セルフアセスメントシートは事前になるべく早めにやって送る
    • MJさんがベストエフォートで理解が間違っているところを指摘してくれます。
    • （僕は期限ギリギリで送ったので、ベストエフォートの範囲外になってしまったようで、特に指摘はしてもらえませんでしたw）
  • 正解を出すことではなく、理解を深めることを目的とする
    • 抽象度が高く、前提が定まっていない(正解が無い)ワークショップが多いですが、テスト問題のような形式で出されるのでどうしても回答を出すことや正解を出すことに捉われがちです。
    • この研修の目的はスクラムの理解を深めることだと思うので、なぜこの回答が正解とされているのか？などのディスカッションに注力するのが良いでしょう。
      • 特に短絡的に正解が出せてしまう問題について議論が発生しづらかったと感じました。
  • アフターパーティーに出よう
    • より実践的で生々しい内容について聞けます。すでに実践している、しようとしている中で課題を持っている人なんかは、研修内容よりこちらの方が学びが多いかもしれません。

※研修内容が変わる可能性はかなりあると思うので、あてにしすぎない方がよいです！

『プロジェクトマネジメントのトリセツ』を読んだ

読んだので読書感想文を書く。

なぜこの本を読もうと思ったのか？

どんな本だったか？

タイトル通り、プロジェクトマネジメントの全体像について書かれている本で、 プロジェクトマネジメントとはどういうもので、特にウォーターフォールモデルで実施する場合に、どういうフェーズに分かれ、何をすれば良いのか？が説明されていたように感じる。 説明とストーリーが入れ替わる形式で読み手としては入ってきやすい構成だったので、本当に「入門編」という内容だ。

所感

入門書としてはオススメ

一通り知っている内容だったので、正直、内容自体には目新しさや感動はなかった。もう少し実践的なHowな部分に言及されてる本だとフィットしたかもしれない。 一方で、網羅的かつ平易な本なので、入門書として誰かにオススメはしやすそうだ。

PERTやそれに変わる何かへの興味が増した

進捗管理的な話の中で、ガントチャートやWBSへの言及があり、その中でPERTについても話されていた。 私が今までいた職場でもガントチャートやWBSは良く使われていて、タスクの依存関係が分かりづらいというデメリットを何度も耳にした記憶があるが、思い返すとPERTを使うという話しになったことは一度も無かった。 そもそも情報処理試験以外でPERTを聞いたり見かけたりしたことが無いので、久々に聞いた単語という感じだった。

アジャイル開発が増えている昨今だが、ガントチャートやWBSを使いたい。というシーンは確実にあると思っているので、その時のデメリットを解消するための手段であるPERT図はなぜ使われていないのか？ 自分の観測範囲内だけの話しなのか、実践的ではないのか。ただ難しいだけなのか、ツールでうまいこと作れたりしないのかなど、そのあたりを知っていきたいと感じた。

大事なのは「情報の非対称性」をどう埋めるかをチーム規模や性質によって変えていくことなのではないか

この本に書かれているようなウォーターフォール的なアプローチでは手戻りが発生することが大きなリスクになる。 なので、誰が見てもわかるように、プロジェクト活動を分かりやすい単位で分割し、それらの役割、目的、必要性などを言語化し、ズレが出ないように定期的に認識を合わせる。といったことにコストをかける価値があるしやっていく必要があるのだと思った。

逆に小さなチーム/プロジェクトであれば、ここまで大袈裟にやる必要は無いはずなので、現状のチームの規模に応じて「情報の非対称性」の取り扱いを考えるべきなんだろうなと感じた

株式会社ロジレスでフリーランスをしたので振り返りを書く

振り返り ロジレス フリーランス

2019/04-2020/04の約一年間、株式会社ロジレス でフリーランスとしてお手伝いをさせてもらったのでその振り返りを書いていく。

お手伝いすることになったきっかけと関わり方

元々創業メンバーの方とのご縁で奥さんが働いており、奥さん経由で「ウチの会社のエンジニアがAWSで困っている」みたいな話を聞いたのがきっかけだったと思う。一度話を聞いてみたら、Aurora移行、DB設計、クエリチューニングあたりの相談相手がほしいということだったので、その辺りであればある程度力になれるかもと思いお手伝いさせていただくことになった。

当時はフルタイムの正社員だったので アドバイザリー + スポットで一緒に作業をする など副業的な関わり方からはじめ、その後フルタイムの会社を辞めフリーランスとなったタイミングで、週2程度オフィスでSRE業務のオペレーションをするようになり、最終的には週3になり、同時期にメンバーが増えてきたこともあり今までの仕事+チームビルディングにも関わるようになった。

どんなことをやったか？と振り返り

ということで、SRE業を軸に、採用戦略や中長期的な技術戦略の提案、チームビルディング系施策の提案と実施等々、幅広く色んなことをやらせていただいた。具体的には下記のようなことをやった。

SRE

セキュリティ系

  • VPN（Pritunl）の導入
  • SSM経由でEC2にログインする
  • AWSのRootアカウントでのログインの廃止 + Switch Roleでログインできるようにする
  • AuroraのAudit logの有効化
  • AWS WAFの導入
  • VPC/Security Groupの見直し

運用系

  • 開発/本番デプロイの自動化
  • クエリのパフォーマンスチューニング
  • WebサーバーのLaunch Template化
  • RDS for MySQLのAurora化

監視系

  • Cloudwatchベースの監視基盤の構築
  • NewRelic、DataDog、Mackarel等のManagedなサービスの比較検討
  • Datadogの導入
  • 監視すべきメトリクスの設計
  • ダッシュボードやアラートの整備

サーバーサイド開発系

  • PHP5.6から7.3への移行サポート
  • Datadog APMの導入
  • ローカル環境開発環境としてのDocker導入
  • ローカルデバッグの提案、導入

その他

  • オフィスネットワーク環境の構築
  • Saving PlansやRIを使ったコスト最適化
  • 主にSRE的な側面での中長期的な技術戦略の相談

SREの仕事はしっかり価値を提供できたのではないかと思う。 元々本業としてやっていたからというのもあるが、会社やプロダクトのフェーズ的に、特定のソフトウェアやサービスへの使いこなしよりも、無限に存在する未整備エリアを幅広く整え底上げしていくことの方がレバレッジが効くフェーズで、そういった仕事が私の得意領域でもあったのが大きな要因だったと思う。これがk8sでMicroservicesしてるアプリケーションのService Meshが煩雑になってきたからどうにかしてくれ。みたいな要件がメインだったら、コスパの悪い人感は否めなかっただろう。得意領域でアプローチするのは大事だ。

技術的な意思決定に関しても、うまくサポートできたと思っている。 例えば、

  • IaCは今のチームにとってはラーニングコストや運用の複雑化から発生するデメリットに対してメリットを享受しづらいから暫くやる必要はなさそう
  • 監視はAPMが入ったマネージドな物を使うとトラブルシューティング等の運用コストが劇的に下がるので特にメンバー数や選任のインフラエンジニアがいない今だからこそ多少のコストは許容して導入しよう
  • Auto Scaling/Healingによる高可用性、リソース効率の最適化によるインフラコストの抑制、セキュリティパッチのあてやすさなんかはBtoB SaaSとは相性が良いはずだし、Deployフローがオーケストレーションツールのレールに乗れることや、プロダクトを開発するエンジニア側がなるべくインフラをコントロールしやすい環境を作るのは運用の負荷を確実に下げてくれる等々、コンテナ化は複雑だけどそれなりのリターンもあるので投資する価値がある

という意思決定があった。他にも細々とした意思決定はあったが、どれも議論を通じてリーズナブルな結論を出せたと思っている。この意思決定自体が正解かどうかは神のみぞ知る。と思うが、ちゃんとメリットデメリットを考えて議論をして決めれたので、軌道修正の議論もしやすいはずだ。こういった議論のカルチャーを持ち込めたのも個人的にはポイントが高いと思っている。

それなりに成果に満足はしている一方で、上記のような機能的な状態になるまでやや時間を要してしまったことには課題感を感じている。そりゃあ機能的になるまでには時間はかかるものではあるが、その時間をもっと短縮することはできないのか？とは思うのだ。

結局機能的になるまでには何が必要だったのか？を振り返ってみると、一番大きな変数としては「対等に議論ができること」だったのではないかと思う。対等に議論ができるようになり始めると、本質的な課題について話し始めるようになるので比例して成果も大きくなる。逆に初期は局所最適的な議論が多かったように思う。これはつまり心理的安全性ってやつなので、改めて心理的安全は大事だよなぁと思っている。

では、なぜ対等に議論するまでに時間がかかるのか？だが、個人的には以下２つが大きな要素なんじゃないかと思う。

  • 相手にどう思われるか推測できない不安（無知/無能だと思われる不安、邪魔している/ネガティブだと思われる不安）から保守的なコミュニケーションをとってしまい、結果的に信頼関係の積み上げペースが遅くなる
  • 持っている情報に格差があることが要因でお互いの主張が噛み合わなかったりその認識合わせに時間がかかったりする。その失敗体験から議論自体を避けがちになってしまう
    • 例えば、プロダクトの売り上げを上げるためには？というお題があったときに、プロダクトの全体像を知っている人と全く知らない人とでは主張が変わるし、噛み合いづらい。そこでギクシャクしてしまうと次は権威を持っていない側がYESマンになってしまう的な話し。

つまり心理的安全性と情報の非対称性ってやつである。この二つを解決するためには、組織側、個人側どちらからのアプローチも必要だが、組織側としてはオンボーディングをちゃんと設計しましょうという話しになっていくと思う。が、今回は個人としての振り返りなので割愛する。

個人の動きとしての振り返りとしては、相手を信頼し、分からないことや不安なことは率直に聞く に尽きるなと感じた。 具体的なHowとしては、この時間がかかる構造を理解し相手に伝え理解してもらうことや、情報格差による無駄な衝突や認識合わせを防ぐために、MTG時にちゃんと論点が分かるアジェンダを作っておくこと、Working Out Loudしていくことが大事かなと思っている。

ただし、ここで注意しなければいけない、かつ難しいのは、率直に聞く = 伝え方が攻撃的/否定的であっても良い ということではないということだ。自分が相手のことを知らないように、相手も自分のことを知らない。相手に届く伝え方というのは選ぶべきだ。「自分のパーソナリティが理解されていないと本当の意図が伝わらないメッセージ」は使ってしまいがちでリスクが高い。

まとめ

  • Keep
    • 相手を信頼し率直に話す
    • 得意領域を見定め提供する
    • プロダクトや会社の目的を意識した技術提案をする
  • Problem
    • 機能的な状態になるまで時間がかかってしまった
  • Try
    • 相手を信頼し率直に話すが、伝え方には気をつける
    • MTGする際に論点をまとめたアジェンダを作る
    • Working Out Loudしていく

採用/開発組織

  • エンジニアの採用戦略の相談
  • 採用イベントへの参加
  • 開発人員の雇用形態等の相談
  • 中長期的な技術戦略の相談

採用/開発組織系は、相談にはのるものの、SRE業務がメインなことやフリーランスという立場上、私自身が推し進めるのが難しい側面も多く、情報のインプットが中心になりあまり大きな影響は与えられなかった。また実務としてはかじった程度というものも多かったので、インプットした情報自体も実体験が伴っていないようなものは説得力に欠けるというのもあったような気がする。

情報のインプットをするだけというのがそこまで悪いことだとは思わない（知らないことを知ることは重要だしいつか使う日に備えることも大事だと思う）が、エンジニア採用が進むと事業が加速することは目に見えていたので、インプットだけではなく実態も伴うようなフォローがしたかった。

これをしていくには、おそらく採用の全体像の解像度をあげることと、スタートアップのいつのフェーズでどんな人をとるべきかを理解することが必要そうな気がした。これらが分かっていると、必要性を説きグランドデザインを設計して提案することができる。

スタートアップの(特に初期の)人は、目先で捌かなければならないタスクが無限にあり、そのタスクを捌くことが圧倒的にROIに優れていることが多い。なので採用や組織系などの、重要だが緊急ではなくそれなりのコストが伴う性質のタスクに関して及び腰になりがちだ。この第一歩目をサポートできるようになりたいなと感じている。

まとめ

  • Keep
    • 情報のインプットはできた
  • Problem
    • 具体的なアクションには繋がらなかったことが多かった
  • Try
    • 採用の全体像の解像度あげる（実体験するのが一番早そう）
    • スタートアップに必要な人材とは？いつ必要？どうすれば採用できる？などの解像度をあげる

開発チームビルディング

  • DX Criteriaの実施と結果の考察/運用の提案
  • 朝会/定例MTG/振り返りの設計とlead

チームビルディング系は自分でも良くできたと感じるし、実際チームからの評判も良かったところだ。

細々としたものを含めると色んなことをやった気がするが、大きく影響を与えることができたのはDX Criteriaの実施と朝会や振り返りなどの会議体の設計だと感じている。

うまくいったきっかけはDX Criteriaの実施だと思う。これをCTOと一緒にやったことによって、組織としての課題感に共通認識が持ててて、その後の提案や議論の質がグッと上がったと感じる。CTOも「課題が可視化され明確になった」と絶賛していた。これからも定期的に実施して組織の状態をモニタリングしていこうとなった。

振り返りや朝会などの会議体の設計に関しては、どうすれば成功体験を得てもらえるかを事前に設計して臨めたことが主な成功要因だったと思う。特に、会議毎の役割、目的、なぜやる必要があるのか、心理的安全とはといったあたりをドキュメントに起こし丁寧に伝えたことと、tryの進捗を毎週追跡する形にしたこと、振り返りの振り返りをちゃんとやるようにしたことが上手く作用した印象だ。 実際に僕がやめたあとにも振り返りは実施されていて、振り返り自体の改善も進んでいるようだ。

CTO的にも振り返りをするカルチャーにすごくポジティブでいてくれているので、このまま会社全体にも浸透していきそうな気はするし、そのカルチャーの一旦を担えたというのは、めちゃくちゃ嬉しいことだし大きな成果だと感じている。

一方で、今回に関してはメンバーが振り返り自体にポジティブだったのでとても協力的だったし、そもそも1伝えたら10吸収して勝手に成長していく人たちだったので、正直、難易度としてはVERY EASYという感じだった。もう少し関係者の数や種類が増えていくと段違いに難しくなっていくような気はしているので、そういった環境でも価値を伝えられるように精進していこうという心持ちだ。

まとめ

  • Keep
    • 一緒に改善をしていく人と現状の認識を合わせる（DxCriteriaは良いフォーマットである）
    • 成功体験を意識した設計をする
  • Problem
    • 振り返りの難易度が上がったときにどうすればいいか分からない
  • Try
    • 事例にアンテナはっておくとか実際にやってみるとかした思い浮かんで無い

追記

この記事を公開した直後にすぐにお褒めのお言葉をいただいた…！(ちょっと盛りすぎですがw)

まぁでも、この記事にこれだけポジティブに反応してもらえるような関係性を築けたということが、何よりのKeepだなと思います。

EC2のSnapshotのLifecyclePolicyをコピペで設定するためのあんちょこ

AWS Tips

はじめに

EBSスナップショットのライフサイクルポリシーの作成は設定項目がそこそこ多いので、同じような内容で複数個設定しようとすると面倒だしミスも発生しやすくなります。

特に、IaC環境ではなくマネジメントコンソールで設定しなければいけない場合に大変です。 現在のお仕事先でもマネジメントコンソールを使って設定していて煩雑だったため、以降同じことをする時に楽なるようにコピペできるようなスクリプトを書いて見ました。

スクリプト

tagにサーバーのRoleが付いているという前提で、そのRoleに該当したEC2のスナップショットをデイリーで取得するようなポリシーを作る場合のスクリプトです。

# role名を書く
target_role=toraru_role

# 実際に作る
aws dlm create-lifecycle-policy \
--execution-role-arn "arn:aws:iam::$(aws sts get-caller-identity | jq -r .Account):role/service-role/AWSDataLifecycleManagerDefaultRole" \
--description "for ${target_role}" \
--state ENABLED \
--policy-details "$(cat << EOS 
{
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [
        {
            "Key": "Role",
            "Value": "${target_role}"
        }
    ],
    "Schedules": [
        {
            "Name": "Daily ${target_role} backup",
            "CopyTags": true,
            "VariableTags": [
                {
                    "Key": "instance-id",
                    "Value": "\$(instance-id)"
                },
                {
                    "Key": "timestamp",
                    "Value": "\$(timestamp)"
                }
            ],
            "CreateRule": {
                "Interval": 24,
                "IntervalUnit": "HOURS",
                "Times": [
                    "16:00"
                ]
            },
            "RetainRule": {
                "Count": 30
            }
        }
    ],
    "Parameters": {
        "ExcludeBootVolume": false
    }
}
EOS
)"

ポイント

  • get-caller-identityを使うことでAccountIDを手動入力しなくても良いようにしています（そのためjqが使えることが前提です）
  • Shell ScriptでJSON内に変数を展開させるのは結構面倒で、試行錯誤した結果ヒアドキュメント経由が良さそうでした

2019年 振り返り

振り返り

年末ということで今年の振り返りをしていく。

2019年はどういう年だったのか？

今年は公私ともに色々と新しいことに手を出した年だったように感じる。

仕事

今年の前半戦はクラスター社でGoのAPIを書いてたりterraformを書いたりしていた。ここ数年はSREやマネージャーのような仕事が多かったので、かなり久しぶりにプロダクトのコードを書いたし、そのコードが本番に反映されていくのはやっぱりエモさがあって、プロダクトを作る楽しさってこういうことだよなぁというのを思い出せた気がする。 また、何かと不足を感じるなぁと思っていた書いていたGoも、少しこなれてきたら不足の部分よりも良さの部分を感じることが多く、Goという言語を好きになったのもこのあたりの時期だったと思う。

今年の後半戦は、そんな感じで働いていたクラスター社退職しフリーランスを始めた。

フリーランスでは２社ほど手伝っていて、一つはWebVR/ブロックチェーンなプロダクトを作るスタートアップ、もう一つは物流系SaaSのスタートアップを手伝っている。

WebVR/ブロックチェーンの方は、Webサイトのフロントエンド開発からインフラ環境までの技術的な決定と実装を主な責務として仕事をした（WebVRにもブロックチェーンにもほとんど関わっていない）。 この仕事では、ほぼ0ベースからアーキテクチャを考えたり技術選定をしたり基盤のコードを書いたりしてたので、0->1を作る時の勘所みたいなところは大分経験できた気がする。

また、創業者とは昔馴染みなこともあり、資金調達のためのピッチテックのレビューをしたり、VCに会いに行ってプロダクトの説明をしたり、地味なとこだと会社登記を代行したりとスタートアップ創業者じゃないと体験できない仕事を手伝ったりできたこともかなりいい経験だったと思う。

物流系SaaSのスタートアップの方は、主にAWSインフラのアドバイザリー+週一で手を動かす作業みたいな感じで手伝っていて、DBをAuroraに移行したり、デプロイの自動化の仕組みを用意したり、クエリのチューニングをしたりとSREっぽいことを多くやった。他にもエンジニアの採用の相談に乗ったり、オフィス移転した先の社内ネットワーク環境構築をやらせてもらったりとこちらもいろんな経験をさせてもらったと感じる。時間的にできないのでお断りしたが、プロダクトマネージャーをやってもらえないかという話をいただいたりもして、すごく光栄だった。

こんな感じで2019年は新しいことをずっとやっていた年で、精神的に辛い瞬間も結構あったが、その分エンジニアとしての地力はあがったんじゃないかと感じれる良い年だったと感じる。

個人

個人としても新しいことを始めた年だった。

特にやってよかったなと感じたことは、EOFにボランティアスタッフとして参加したことで、これがきっかけで、EM関連の人との繋がりが増えたりカジュアル面談にお誘いいただいたりと社外の人との輪が広がったと感じる。

開発コミュニティを通して技術的な知見が共有されて多くの課題解決が簡単になったように、EMの知見も共有されて良いチームが増えていく世の中になっていくと最高だと思うので、これからもEM界隈には何かしら貢献していきたい。

また、最近、ブログを書き始めたり、Githubに些細なコードをpushしてみたりとパブリックな活動をし始めた。

元々長いこと同じ会社で働いていたのもあり、知識や知見の共有は社内のドキュメントで満足していたし、そもそもネットの世界に対する心理的安全が０だった（間違った情報を出してしまったり、自分の意図をうまくつたえれなかった時の面倒さを考えると億劫で仕方なかったしそれを押してまで発信したいものは無かった）ので、特にパブリックな発信はしてこなかった。

ただ、転職したり手伝う会社が増えていく中で、あのノウハウ、あそこの会社のドキュメントツールにまとめたけど、（当たり前なんだけど）見れねー詳細に思い出せねーみたいなことが発生し始めて、これは会社だけじゃなく個人にも紐づけるようにしなきゃいけないなと強く感じ始めた。 なので、最初は個人で使っているesaにアウトプットするようにしていて、しばらくはそれで満足していたのだが、人から見られないところにアウトプットしているとどうしても雑になってしまうのと、自分はエゴサーチビリティが低い（スキルやパーソナリティが分かるような情報がネット上に少ない）なと感じたこともあり、少し勇気を出してパブリックな場所にアウトプットをしはじめた。 負荷になりすぎない程度にボチボチ継続していければと思う。

来年は？

来年は、

  • EMとして良い感じに仕事をする
  • 英語を結構本気で頑張る
  • 今のアウトプットを継続する

の三本柱でいこうと思います！