この記事は、tacoms Advent Calendar 2024の23日目です!
他メンバーのAdvent Calendarはこちらからご覧ください！👇
はじめに
どうもー！株式会社tacomsのSREのMorixです！
もうだいぶ年末感が出ている今日この頃、みなさんいかがお過ごしでしょうか。
私は子どもにもらった風邪が一向に治りません。無限に鼻水です。
さて、私がtacomsに入社して1ヶ月ちょっと経ちます。
まず最初にやったことは「tacomsのSREの課題の整理」です。
課題の整理は現状の理解にうってつけなタスクだと思います。
それは整理の過程で次のようなことが学習できるからです。
- 現状のシステムの構成と弱点
- その会社のSREの関心領域・責任範囲の把握
どのように整理していったかを紹介したいと思います！
0.課題を整理する前の状態
tacomsのSREの担当領域に関する課題は主に次のところに集約されていました。
- GitHubのissue
- SRE開発ロードマップ
私が入社する前に情報を整理していただいてたようで課題の把握がとてもしやすかったです！
本当に助かりました。
これで充分じゃないかと思ったのですが、tacomsのSREチームはまだ発足したばかりで今後やりたいこと（ロードマップ）や課題をどう進めていくかが整理されてない状態でした。
まずはやることの交通整理をして3〜6ヶ月の開発計画を見通せるようにしようと思い、整理を始めました。
1.課題の内容理解
まずはCTOやSREのメンバーに説明をしていただきながら課題を1つ1つ理解していきました。
SREメンバー全員で課題の内容理解を進めていったので、とても良いチームビルディングになったと思います。
みんな優しくて些細な疑問もどんどん答えてくれる・・・感謝！！
2.tacomsのSREチームのミッションの定義
tacomsのSREチームのミッションは次の4つが定義されていました。
| ミッション | 説明 |
|---|---|
| サービスの信頼性向上 | tacomsが提供するサービスの信頼性を向上させる |
| プロダクトチームの開発生産性向上 | プロダクトチームが安心安全に開発・デプロイできる環境を作る |
| コスト効率の改善 | インフラやSaaSなどの利用コストを最適化する |
| インフラが関わる開発ロードマップのサポート | プロダクトチームが策定する開発ロードマップをインフラ面で支援する |
課題やロードマップもこれら4つのミッションに紐づくことを理解できましたし、前職でもこの4つが主なミッションだったので違和感がありませんでした。
ミッションはこのまま維持することに決めました。
3.ミッションをもとに見えない課題の洗い出し
次にまだ課題として挙がっていない課題を見つけることをしました。
思いつきで挙げていくのもいいのですが、なにかフレームワークがあったほうが整理しやすいなと思いました。
そこでISO/IEC 25010:2011を参考にしてみることにしました。この規格はソフトウェアの品質に関する国際標準規格です。
品質を重視するSREには相性がよいものだと思い、我々のミッションと関連付けてみました。
なおミッションの一つである「コスト効率の改善」は品質特性に当てはまりません。
| ミッション | 品質特性 | 品質副特性 | 意味 |
|---|---|---|---|
| サービスの信頼性向上 | 性能効率性 | 時間効率性 | 処理のレイテンシやスループットは適切か |
| - | - | 資源効率性 | システムのリソースを効率よく使えているか |
| - | - | 容量満足性 | 想定されるデータ量を十分に処理できるか |
| - | 信頼性 | 成熟性 | 障害発生時に停止しないか |
| - | - | 可用性 | システムをいつでも利用できるか |
| - | - | 耐障害性 | 障害発生時に機能制限付きで継続動作が可能か |
| - | - | 回復性 | 障害発生後、発生前の状態に戻せるか |
| - | セキュリティ | 機密性 | 許可されたデータだけにアクセスできるか |
| - | - | インテグリティ | 不正なアクセスを防止できるか |
| - | - | 否認防止性 | 事実を記録・改ざんできないようにできてるか |
| - | - | 責任追跡性 | 操作や事象をあとから追跡できるか |
| - | - | 真正性 | （認証などを）本物であると証明できるか |
| - | 互換性 | 共存性 | 複数システムが他に影響を与えず環境やリソースを共有できるか |
| - | - | 相互運用性 | 複数システム間の連携が適切に行えるか |
| プロダクトチームの開発生産性向上 | 保守性 | モジュール性 | 適切な構成要素に分解されてるか |
| - | - | 再利用性 | 既存の構成要素を再利用できるか |
| - | - | 解析性 | 影響範囲や修正・問題箇所を特定できるか |
| - | - | 修正性 | 品質を保ちつつプログラムを修正できるか |
| - | - | 試験性 | テストの実施が容易で安定しているか |
| - | 移植性 | 設置性 | インストールやデプロイが効率よく行えるか |
| - | - | 置換性 | 新しいバージョンに容易に置き換え可能か |
| インフラが関わる開発ロードマップのサポート | 機能適合性 | （割愛） | アプリケーションの機能は十分か |
| - | 使用性 | （割愛） | ユーザーにとって使いやすいアプリケーションか |
これらの品質特性を向上させることが我々SREのミッションと言えそうです。
とはいえすべてを網羅的にやっていくのは厳しいです。短中期で注力する品質特性を決める必要があります。
tacomsはデリバリー注文一元管理サービスのCamelというBtoBサービスを開発・運営しています。
つまりお客様は企業です。1つ1つの契約が重いのです。
一度失墜した信頼を取り戻すのはとても困難なので、信頼を失墜させないようなシステムを目指さないといけません。
当然我々はスタートアップですしビジネスの拡大のためにスピード感をもって機能開発を進めていくのは必須ですが、しかし足元を固めてシステムの信頼性を高めることも急務だと思います。
そのため直近1年で注力すべき品質特性を定めました。
| 品質特性 | 品質副特性 | なぜ注力するのか？ |
|---|---|---|
| 性能効率性 | 時間効率性 | アプリケーションのパフォーマンスが悪いことでユーザーの信頼を損ねるため |
| 信頼性 | 可用性 | デプロイやメンテでシステムが止まることを許容できないため |
| - | 回復性 | 障害によってシステムが止まることを許容できないため |
| セキュリティ | 機密性 | 情報漏洩による信頼失墜を避けたいため |
| - | インテグリティ | 情報漏洩による信頼失墜を避けたいため |
| - | 責任追跡性 | 情報漏洩されていることを検知するため |
| 保守性 | 解析性 | 障害発生を未然に防いだり障害復旧時間を短縮するため |
今まで挙がった課題をこの品質副特性に当てはめていくと、課題が少ないor挙がっていない品質副特性がありました。
その特性で課題がなさそうかを自分で確認したり周りの方に聞いて、新しい課題を発見することが出来ました。
4.ミッションからプロジェクトへの落とし込み
一通り課題が洗い出せたので、次にロードマップや課題をどう進めていくかを考えました。
ロードマップはtacomsがやりたいと思ってることです。数ある課題の中でもより注力すべき課題も含まれますし、新たなプロダクトの開発計画も載ってきます。
このやりたいことから具体的にやることを考えプロジェクトとして落とし込み、メンバーにアサインしていく必要があります。
このやりたいことをストラテジーと名付けました。なぜわざわざ名前をつけたかというと、やりたいこと＝プロジェクトとはならないからです。
例えば「この時期までに〇〇というイベント時のアクセススパイクに耐えられるようにしたい」というやりたいことがあった場合、色々やりたいことが思い浮かびます。
- アプリケーションのあの部分のパフォーマンスをあげたほうがいい
- インフラのこの部分のスケーラビリティをあげたい
- 過度なアクセスは待機画面にしたい
これら一つ一つが重く、ひとつのプロジェクトに収めたくないと思いました。
なのでこれらはすべてプロジェクトとしてそれぞれメンバーにアサインしたいわけです。
しかしプロジェクトロードマップだけ引くと、「なにを目的としたプロジェクトなんだっけ？」と忘れてしまいます。
そこでこのやりたいことをストラテジーと名付け、次のような3層構造でプロジェクトを管理するようしました。
- ミッション
- ストラテジー
- プロジェクト
このようにすることでプロジェクトの目的をわかりやすくしました。
ちなみになぜストラテジーという語を使ったかというと、ストラテジーというのは施策という意味があるのと同時に、「戦略」という意味もあります。
プロジェクトを「戦術」とみなすと、戦略と戦術で親子関係が成り立ち、自分の中でしっくりきたからです！
5.課題を再整理しプロジェクトに分類
課題を1つ1つ見ていき、次のような分類をしました。
- 重要な課題で注力品質副特性に当てはまるもの
- -> ストラテジープロジェクト（ストラテジーに紐づいたプロジェクトの意）
- 重要な課題だが注力品質副特性に当てはまらないもの
- -> バックログプロジェクト
- 軽い課題
- -> バックログタスク
注力すべきはストラテジープロジェクトですが、ストラテジープロジェクトばかりやっていてはメンバーも疲れてしまいますし、積み上がった課題が消化できません。
なのでストラテジープロジェクトとストラテジープロジェクトの間に1ヶ月程度間を空け、その間にバックログプロジェクトやタスクをやってもらうようにしようと思っています。（もちろんプロジェクトと並行して依頼などのバックログタスクをこなしています）
業務のうち◯％はそういうタスクに当てていいよーという制度が弊社にもありますが、週のうち◯％そのタスクに当てるというのは現実的に無理です。
なのでこういうやり方で重要度の低い課題をやろうとしています。
6.ロードマップの見直し・プロジェクトにメンバーアサイン
今までの課題の整理の結果、やりたいこと（ストラテジー）も増えてきたので、SREの開発ロードマップを見直しました。
ストラテジーをやりたい時期で線を引いたものを「ストラテジーロードマップ」とし、そこからプロジェクトに落とし込んだものを「プロジェクトロードマップ」にしました。
SREのメンバーは基本的にプロジェクトロードマップを見てもらえば良く、私やCTOはストラテジーロードマップでコミュニケーションをするようにしました。
そしてプロジェクトにメンバーをアサインして、直近3ヶ月なにをするのかが明確にわかるようになりました！！
めでたしめでたし・・・ではなく、俺達の戦いはこれからだ！！！
まとめ
新しいチームにジョイン後に課題整理をするのは、チームの責任範囲やシステムの把握に役立ちます。
チーム全員で整理することでチームビルディングにもなります。
チームのミッションを定義し、そこから見えてる課題をカテゴライズしたり、システムの品質特性をもとに見えてない課題を洗い出すことができました。
ミッションをもとにストラテジーが生まれ、そこからプロジェクトに落とし込み、プロジェクトの目的を忘れないように出来ました。
そして課題をプロジェクト化し、そこからロードマップにまとめ、開発計画を作ることが出来ました。
Discussion