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

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

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だなと思います。