こんにちは。SmartHRの権限基盤チームでプロダクトエンジニアをしているhachimitsuです。この記事では、プレモータムという、プロジェクトや組織が失敗したと想定し、その失敗要因を逆戻りして考えるリスクアセスメント手法について書こうと思います。
背景
まずは、プレモータムを実施したプロジェクトの概要からご説明します。私たちは、従業員情報連携項目設定機能という、SmartHR基本機能と連携しているアプリケーション間で参照できる従業員情報の項目を設定できる機能を開発していました。
この機能を実現するためには、たくさんのプロダクトエンジニアが数年間にわたり育ててきたAPIに新たな機能を導入する必要がありました。APIにはすでに複数のレイヤーで権限制御機能が導入されていたこともあり、新たな機能の導入には多くの不安が伴いました。さらに、この変更はSmartHR APIを使用している既存のお客様にも影響を及ぼす可能性があったため、慎重に対応する必要がありました。
プレモータムを通じて、リスクを事前に洗い出し、対策を練ることで、プロジェクトの進行がスムーズになることを期待していました。
実施内容
実施方法は、オンラインホワイトボードを使用しました。まず、以下のカテゴリーを作成し、チーム全体で失敗要因を洗い出しました。
- プロジェクトが遅れる原因は何が考えられますか？
- 私たちが持っていないもので、このプロジェクトに必要なものは何ですか？
- このプロジェクトに必要なもので、私たちがすでに持っているものは何ですか？
- 過去のプロジェクトからどのような教訓を学びましたか？
- 心配なことは何ですか？
- わくわくしていることは何ですか？
その後、チーム内で最も重要と考える要因を選び、対策を決定しました。この手法は、Atlassianの事前分析プロジェクト管理戦略手順を参考にしました。
チームで洗い出したリスク要素の中で実際に掘り下げたものを2つご紹介します。
「心配なことは何ですか？」で以下の心配事が出てきました。
- 公開APIや既存機能で不具合がでること、特に見えちゃいけないものが見えてしまう系
- 連携先で見えちゃいけないものが見えちゃう
上記の不具合のリスクの対策について話し合った結果、チームですでにやっていた「可能な限り自動テストを書いて抜け漏れを防ぐ」という活動がリスク対策に繋がっていたことがわかりました。元々不足していた自動テストを実装したり、新たに必要なテストケースを追加することが、不具合発生の予防になっていました。今考えると、機能実装をしてる時間より自動テストの実装やテストケースの洗い出しに費やした時間の方が多かったと思います。
「私たちが持っていないもので、このプロジェクトに必要なものは何ですか？」では以下の必要なものが出てきました。
- 連携先チームとのコミュニケーションのあり方
上記のチーム間コミュニケーションのリスクについて話し合った結果、いくつかの重要な気づきがありました。まず、コミュニケーションが必要なチームは連携先のチームだけでなく、プロジェクト内で改修予定だった従業員APIをメンテナンスしているチームも含まれることが分かりました。また、コミュニケーションが発生しそうなタイミングが連携時以外にも存在することが分かりました。例えば、管理できる従業員項目が増え、制御が必要な項目が変わった場合や、新しく従業員APIが実装されて制御機能を導入する必要がでてきた場合などです。
効果
プロジェクトのリスクを可視化できたことで、チーム全体で共通の認識を持てました。さらに、リスク要素の中で最も深刻と考えられるものの対策を考えられたことも大きな成果でした。
また、各種アプリケーションと連携作業を進める時以外でも関係各所とのコミュニケーションが不可欠であることが明確になりました。対外的な開発ドキュメントを作成することで、開発中やリリース後にコミュニケーションのリスクを抑えられる事に気づけました。
不具合のリスクは、事前に自動テストを追加しておいたことで、次の実装を行なう際の安心感が増しました。同じリポジトリで複数チームが機能開発しているので、他チームの変更による影響を受けたかどうかをCIで確認でき、適切な対応も取れました。
最後に
今後も開発を進める中でチーム内の不安が多かったり、リスクが高そうなプロジェクトを進める場合はプレモータムを使っていきたいと思います。この記事を読んで「自分が参加してるプロジェクトで使えるじゃん」と思った方、ぜひ試してみてください。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
