2ヶ月の育休を機にエンジニアチームのトラックナンバー・権限管理を見直す

Kurashicom Tech Blog

2022年3月15日 09:47

こんにちは。テクノロジーグループの佐々木です。

タイトルにも記載していますが、2022年1月に第一子が生まれ、2ヶ月ほど育休をいただいていました。

2ヶ月というのはお休みをいただく期間としては当然短くありません。というか、こんなに仕事を休んだことはなく。自分の感覚としては、変な言い方ですが退職に近いです。

チーム内では最古参のエンジニアとして、今までの経緯によって自分に依存している業務が存在していたり強めの権限を有しているわけですから、何もせず休みに入るわけにはいきません。

そこで、どうしたら残るメンバーが不自由なく業務を行うことができ、自分自身がスムーズに戻れるか考え、行ったことを紹介させていただきます。

まず何を考えたか

まずは以下の棚卸しを行いました。

自分だけが恒常的に抱えているタスク
自分だけが強い権限を持っているサービス

また、次の点においても検討をしました。

権限移譲の必要性はあるか
他メンバーに伝えておく必要のある開発・ドメイン知識はあるか

前者はトラックナンバー、後者は権限管理の観点から整理しました。一つずつ見ていきます。

トラックナンバー

トラックナンバーとは、トラックに轢かれるといった急な事故などによってプロジェクトが立ちいかなくなったり継続が難しくなったりする人数のことを指します。システムの言葉で言い換えれば、トラックナンバー1の状態は「単一障害点(SPOF)」と同じようなものです。

今回は、自分がトラックナンバー1の状態で抱えているものがないかを改めて確認し、不在になってもサービス・業務が止まらない状態にすることを考えました。

チームでは普段からトラックナンバーが少ない状態を避けるよう運用しているため、幸い今回は引き継ぐ必要のあるものは多くない状態でした。あったとしても、簡単なスクリプトを渡したり、自動化を見直すことで負荷を低く解消できています。

ただ、育休復帰後に発覚したのですが、オーナー権限と支払いの権限が別になっているSaaSがあり、対応リストから漏れてしまっていたのでそこだけ反省点でした。

また、SaaSによってはオーナーは一人しかなれないものもあります。

そういったSaaSを使用している場合、マシンユーザー（人間ではないユーザー）のアカウントを別途用意して、最小の人数がそのアカウントを使用できるよう厳密に管理するのがトラックナンバー1を回避しつつリスクを低減する一つの方法になるかと思います。マシンユーザーの利用は、自動化する際のGithubリポジトリのアクセス管理などでも使用を推奨されています。

チームの権限の考え方

トラックナンバーの解消はできたので、今度はチームが動きにくい状態に陥らないかを権限、開発知識などの観点から確認します。

まず権限について。

自分が主に開発領域として携わっているインフラを始め、コード管理をしているGitHubやSaaSなどシステム全般の権限に関しては、必要以上の権限は付与しないという最小権限の法則を念頭に置いて運用を行っています。

最小権限の法則は、必要以上の権限を有していることによって、突発的な障害や不正を防ぐことが目的です。権限がないことで、各メンバーの判断でできることに制限はできてしまいますが、ここが適切に設計できていないとリスクが高まります。

上記のような考え方で運用するとなると、特権を持てるメンバーには自然とシステムに対する理解度が求められるようになります。また、特定領域のエキスパートであっても、入社直後などチーム内での信頼関係が未成熟なままで権限を付与するのには、ほとんどないことかもしれませんが「不正」という観点からもリスクがあります。

こういった理由から、チームのエンジニアは7人と少人数ではありますが、各自の権限には差があります。そしてどうしても、古くからいるメンバーに権限や動いているシステムの内情についての知識が片寄りがちなので、知識の片寄りが大きいときは少しづつ解していく必要があります。

権限移譲・知識のエクスポート

クラシコムではIaC(Infrastructure as Code)を進めており、AWSをTerraformで管理をしています。自分が育休に入る前は、主にTerraformを変更するのは、自分含め3人。しかし、3人のうち1人には強い権限を与えていませんでした。

Terraform導入のときからずっと行っていることなのですが、Terraformの変更を本番環境に反映する作業は、何かあったときすぐ対処できるようにするという目的から、最低2人でオペレーションを行うこととしています。

そのため、これまで大きく問題になったことはないのですが、休みに入るタイミングで権限を付与しないと、チーム全体の作業上辛くなりうることが予見できていました。仮に付与しなかった場合、Terraformに精通しつつも強い権限を持ったエンジニアが1人だけの状態になるわけですから、変更の反映時そのエンジニアが必ず入らないといけない状態になります。「そのエンジニアがいないと対応できない状況」というボトルネックの可能性とリスクが生じます。

権限を付与していなかったメンバーはスキルがないわけではありませんでした。Terraform自体は1年以上書いており、アプリケーション側の変更もバリバリ行えるため、安心して育休に入る前に権限を付与しました。

また、単純に開発メンバーが一人減るわけですから、Terraformにあまり触れたことのないメンバーにはどんどんTerraformに触ってほしいということをお伝えしました。

どんな変更をこれまで行ってきたかはGitHubに溜まっている
現状動いているAWSリソースはほとんどTerraformで管理できてきている

以上から、細かい仕様を確認しつつコードを見ればなんとなくは掴める状態にできつつあります。

あとは実際に動かしてみる必要がありますが、その時のプロジェクトで必要となっていた検証環境を作ってみるよう伝えました。

インフラリソースはローカルに作れないので多少心理的ハードルはありますが、現状のチームであればサポートもできる環境になってきているし、Terraformの反映は2人で行うという体制にもなっているので、良い機会になるのではないかと考えました。また、本番環境の変更ではないということも、失敗しても痛手は少なく心理的ハードルを下げると考えていました。

そして育休から戻ってきたとき、ほとんどインフラに触れていなかったメンバーがガシガシTerraformのコードを書いて、反映して、動かして、直してというのを繰り返しておりとても頼もしかったです。

まとめ

以下、ここまでのまとめになります。

トラックナンバーを意識する
リスクを考慮し最小権限の法則で運用する
権限は適宜見直しと整理を行っておく
IaCを進めレビュー、変更が見える、サポートできる環境作りをする

これらは一足飛びにできることではありませんが、チームのメンバーでコツコツと作ってきた環境が、変化に対応しやすく育休を取りやすい環境にしてくれていました。

この記事は育休を機に行ったこととして文章を進めていますが、ある程度の権限・役割を持った方であれば通るプロセスでもあるかと思いますので、そういった方の参考にもなれば幸いです。

最後に

クラシコムでは人生の変化を前提とした制度と徹底した業務効率化で、暮らしも事業成長も追求する働き方を実践しています。実際、2019年以降男性の育休取得率が100%で、平均して45.3日の取得実績があります。（2021年7月期）

大事な家族との暮らしを大切にしつつ、チーム・システム・サービスをより良くしていくことに興味のあるメンバーを探しています。どうぞご応募ください。