bon now

会社のブログに書いたとおり、2022/6に自社のサーバー環境をHerokuからGCPへ完全リプレースした。
移行の際は[レポート] SmartHR が少人数で Google Cloud へ（ほぼ）全移行を完了させた方法 ＃GoogleCloudDay -DevelopersIOの記事と記事中のSmartHRさんの取り組みを参考にさせてもらった。
さらに自社オリジナルの移行を敢行した部分もあるので、そのへんの意思決定やスケジュール感や実際にGCPで検証しながら戦略を考えていった流れをプロジェクトマネジメントの立場として語ってみる。久しぶりに技術(と入ってもマネジメントの…)っぽい記事。

仕事的な部分は別途弊社の技術ブログを見てほしい。

個人的目標

個人目標は2つ。

まず僕がこのプロジェクトを進める上で個人的に目標にしていたことは「プロジェクトの完遂をチームの成功体験にする」である。
僕自身前職でプロジェクト自体は上手くいったけど、チーム開発の成功体験を与えられなかったという経験があるため、 チームがどれだけ一眼となって成功体験を感じてもらえるかに集中しようと決意。

また、チーム全体の挑戦心やり抜く力っていう、スキルよりももっと根幹なところをもう少し強化できないかなーと常々思っていた。 そこで「チームメンバー各人がプロジェクトを通して何かしら成長する」という点も目標にした。

チームの詳細な状況

今回のプロジェクトのチーム構成は、フルコミットが2名、0.1〜0.5コミットが3名。メンバーの特徴を羅列するとこんな感じ。

• PMが少しでき、インフラも少しわかる+リプレース案件経験者（僕）: フルコミット
• Terraformおじさんになってインフラ勉強したいエンジニア: フルコミット
• 自社システムの仕様に詳しく全体像を把握しているRubyエンジニア: 0.5
• GCPリプレース経験者兼Rubyのコミッター(業務委託): 0.3
• AWSの知見を持つベテランインフラエンジニア(業務委託): 0.1

ほぼ無敵の布陣である（笑）
これで成功しないほうがおかしいので、PMとしては正直余裕こいてた。
実際、僕の大方の予想通り要件まとめから実装までを2ヶ月で終え、無事オンスケでリリースすることができた。
リリース後も大きなトラブルはほぼなく、皆何かしらのスキル(と知識)を習得できたんじゃないかと思う。

それと同時にもう一つの目標であった自信や挑戦心、やり抜く力みたいなところもある程度は強化できたんじゃないかと思う。
他にも自社のミッション・バリューに徹底的に則したプロダクトへの向き合い方みたいなところも学んでもらえたんじゃないかと勝手に思っている。このあたりは詳細を後述する。

プロジェクト成功のために実はXXしました

無策で挑むには心もとないので、もちろんちゃんと目標が実現できるような施策を講じた。
ただし、あまりこのあたりを表立って口にしていないので後出しジャンケンみたいになってしまうのは否めないが、せっかくなので書く。

草野球感を大事にしました

会社のブログにも書いたとおり、今以上の性能の確保やリファクタリングはやらないことにした。
建前は「不確実性の排除」なんだけど、もう一つ 「無駄なプレッシャーとスケジュールの制約で仕事の縛りを生みたくなかった」 ってのがある。 何を隠そう、僕がこのプロジェクトでやってみたかったのは 「プロ野球」ではなく「草野球」 だ。

リプレースは特定の時間帯や期間において、新旧のシステムが並行稼動するタイミングが存在する。 今回のプロジェクトでも並行稼動期間が確実に容認されるよう取り組んだ。
で、これが何を意味するかというと要は 「失敗しても移行期間中であればすぐに元に戻せる」 ということである。
もちろん切り替えのタイミングでDBのロールバックやら再バックアップやら必要にはなるだろうけど、たったそれだけである。 弊社のサービス規模であれば、エンジニア総出で頑張れば数時間以内で(多分)終わるような作業だ。サービス全体が死んで顧客に迷惑をかけるよりは遥かに低いダメージで済む。
そして、この失敗時のリカバリー作業すらエンジニアの一種のお遊び……もといスキルアップの場と捉えてしまえば、成功しようが失敗しようが何かしらの学びが生まれる。 つまり、顧客への継続的なプロダクト提供の重要性を認識しつつも、ことに仕事においては、プロでありながらもアマチュアとして技術で遊んでしまおうという場を作りたかったのだ。元MLB選手のイチロー氏の言葉を借りると 「プロ野球でそれなりに苦しんだ人間でないと、草野球を楽しめない」 というやつ。
その「遊べる技術」(今回の場合はGCP)に集中するためには、今既に存在している技術はとりあえず現状のままにしてあげるほうが不確実性は減るので効率が良いよな、と考えた。

山本五十六になりました

とりあえず、プロがアマチュアと何が違うのかを考える。
プロというのは仕事に最大限の責任を追い、目標を追いかけると定義すればアマチュアはその逆とする。 今回のプロジェクトにはプロ(ベテラン)勢が半数を占めているので、そのプロにもアマチュアな気持ちで楽しんでもらいたかった。 逆にプロじゃないメンバーに対しては、アマチュアな気分でプロになっていくことを経験してほしかった。

次にプロはどのようにしてアマチュアに技術を教えるかと言うのを考える。
僕は山本五十六さんの 「やってみせ、言って聞かせて、させてみて、誉めてやらねば、人は動かじ」 という言葉が好きなので、これを実践した。
具体的にはアーキテクチャ構成やネットワークについてある程度「これでいいんじゃない？」を提案しつつ、簡単な技術検証を手作業で進めつつそれをTerraform化する作業は丸投げする的なことをやった。
1つ1つの具体的な施策や意味付けはもちろん担当したメンバーに考えてもらうようにした。(つもり)

あと技術的に任せたいところは完全に移譲し、口を出さないことにも努めた。 「やっている、姿を感謝で、見守って、信頼せねば、人は実らず」 である。

ドキュメントを書かせました

リプレースはプログラムの実装のように、アーキテクチャの選定や仕様、パラメータや変数などの定義について、意図や背景をコードに残すことができない。Terraformにはある程度残せるものの、そこだけでは非機能要件や技術的に不可能だったことや制約事項などが抜け落ちてしまう可能性があった。
そのため 明日の俺たちにこのリプレースがなんで今の形になったかをタイムカプセルにしておこうぜ 的にドキュメントを書きましょう、書きましょうと週に3回以上は言ったんじゃないだろうか。

今の弊社はまだまだ事業として大きく成長する伸び代があるので、今後エンジニアの数が10倍になったとしたとき、このアーキテクチャに文句つけたり意味を知りたがったりする人は絶対に出てくる。 その際に 「今ならXXにしたほうがいいですよね」 という合理的な意見がすんなり出てくるかどうかは、今回作り上げるべきドキュメントに関わるだろう。そして、将来の生産性と意思決定の正当性に寄与するはずである。5年先も考えててえらい！

顧客第一を考えました

普段開発していると、一番顧客から遠い存在になりがちではなかろうかという不安が頭をよぎることがある。
実際顧客要件に対して問題解決の手段だけを検討し、いざリリースしたら顧客から「思ってたんと違うわ」と言われた経験のあるエンジニアは少なくないのではないだろうか。多分問題は「顧客に最大限に提供できる価値は何」という視点が漏れていたからだ。

自社のミッション・バリューもまた実装という工程に追いては漏れがちだと個人的に思っている。
これが漏れないよう、様々な議論の中で 「それって顧客のためなんですか？」(※)を問い続けた。 (※) 弊社のミッション…バリューについては別途確認してほしい

そして僕が思うのと違う答えについては「それってあなたの感想ですよね？」と答えた(嘘です）。

成果としては、リプレース時にサービスをどういう順番で止めるか、いつ止めるか、止めているときにどうすれば既存の顧客の機会損失を最小限にできるか……といった議論から、ある程度最適解を導き出せたと思っている。

逃げ道を作りました

先述通り、リプレースが失敗してもなんとかなるという逃げ道に加え、色んなところにショートカットを用意しておいた。

Terraformが案外難しく時間が足りねぇーとなったときは、手で作ればいいようにした。
技術的に困難で想定通りにできない……という状況になる前に、チャレンジ案と妥協案の2案を出しておくようにした。
例えば今回一番難所だなーと思ってたCloud RunでのSidekiqジョブの定期ジョブとBackgroundジョブの実行については、最悪GCE(or GAE)で頑張るという逃げ道を作っておいた。

そして、スケジュール通りに作業が終わらない……という状況についても、最悪僕が巻き取れるようにはしておいた。
ただ、僕じゃ解決が無理だったなと感じた技術的要件が2つほどあったので、結果的に間に合わないという状況にならなくてよかったなと安堵している(笑)
(1つはCloud Buildの依存関係の解決と、db:migrate処理の待機処理、もう1つはバッチ処理)

こんな感じで色々実は考えて動いていた。。。と、個人的には思っている。

個人的な反省

フルコミットメンバー以外の向き合い方

一番大きな反省点は、フルコミットメンバー以外の関わり方をもう少し良い感じにできたのではないかということだ。
ベテランのメンバーが揃っているのだからほとんどの要件はするすると決まっていくわけで、そこに楽しみやワクワクを持ってもらうにはやはり工夫が必要である。
少しリリース時期を延ばしてでも、敢えてベテラン勢がこれまでのエンジニア経験でやってこなかった技術領域を担当してもらうとか、 チャレンジ案を検討・提案してもらうという判断もあっただろう。ここは完全に僕のマネジメントの不届きであり、力不足な点である。

特に工数をフルに割けない業務委託の方との関わり合いというのはSI企業に所属していた頃にも見聞きしてきたし、実際に一緒に働いたときもあった。彼らを自分がマネジメントする側になったときに、マネージするノウハウを吸収してなかったのは大きな損失だったと気付かされた。
次はもっとベテランとジュニアとの関わり合い方を考えつつ、皆の目標や役割をキチッっと定義したうえで任せることを任せる、考えてもらうことに責任を持ってもらうということをやっていこうと思っている。

スケジュール優先になりがち

毎回のことながらスケジュールが第一優先になるところが自分にはあるので、スケジュールを遅延させてでもやるべきことはやるという判断を見誤らないようにしないといけない、と感じた。

後出しジャンケンしすぎ

こうやって「後出し」で自分の野心や目標を語るのもクセみたいになってるから、最初っから表に出しておけば？とは自分でも思った(笑)

情報共有

自分では頻繁に情報共有できてたと思っている反面、それの重要性について説明してないなーと最近感じている。
弊社はリモートワークがメインなので、どうしても非同期な情報共有が発生してしまう。
ある程度ドキュメントを書くことで補えることはできるが、例えばTerraformを実行すると手作業で各種GCPのサービス連携を検証していたり、特定のブランチ状態のコンテナで実装検証していたりすると唐突に環境がなくなってしまうという自体が発生する。
何気ないことではあるが、こういう「誰かに影響を与えちゃうかもね」っていう緊急性の高い情報をSlackなりバーチャルオフィス(弊社はGather)なりで共有してもらうとありがたいわけで……。
これについては仕事の切り出し方や情報共有の方法について再度考えるきっかけになった。

まとめ

• 仕事を楽しもう
• ドキュメント化大事
• ミッション・バリューを大切にしよう
• 状況をプラスに利用しよう
• いつでも逃げられる準備をしよう
• みんなで成長しよう
• リモートワークでは情報共有の手段・タイミング大事

以上、ちょっと妄想も入ってる気もするがこんな感じで仕事しました。楽しかったです。