こんにちは。Sansan Engineering Unit Data Hubグループの北澤です。2021年に新卒入社し、エンジニアとしてSansan Data Hubの開発に携わっています。
Data Hubグループ内セキュリティーチームのリーダーとして、ロードマップ運用の改善について取り組んだので、その紹介をさせていただきます。
背景
Sansan株式会社ではプロダクトごとに、将来的にどのような施策を行っていくかを書いた内部向けのセキュリティーロードマップが存在しています。このロードマップを用いて、情報セキュリティ部とも連携を行いつつ、プロダクトを開発しているグループがどのような対策を行っていくかを定めて運用しています。
改善を行う前のSansan Data Hubのロードマップはいくつかの課題を抱えていました。
- ロードマップのメンテナンス性がかなり低い
- 運用保守がセキュリティーチーム内にクローズドになっている
- 対策における開発はグループ全体で行っているが、今後どのような対応していくのかがメンバーからは不透明
- セキュリティーチームメンバーへの依存度がとてつもなく高い
改善策としてロードマップをセキュリティーバックログとしてリビルドし、それをNotionに移行して運用していくという取り組みを試みました。
ロードマップの再構築
まず行ったのは旧ロードマップを捨て去ることでした。
旧ロードマップは表計算ソフトウェアで作成されたファイルに記載されておりBoxで管理されていました。状況や期の変わりでシートを作りなおす必要がある、同時編集するのが難しいなどの問題を抱えていました。
そこで新しいロードマップをNotion上に新規で作成することにしました。Notionを選択した理由は、全社的にも導入され日々の業務で利用しているというのもありますが、見やすさと使いやすさがかなり良かったからです。具体的に行ったこととしては、データベースを作成し、そこに今積んでいるセキュリティー施策をアイテムとして記載していくようにしました。
このままだとただのバックログなので、アイテムのプロパティに期間を加えた後にビューを設定し、ロードマップとしても扱えるようにしました。またバックログ構築作業と並行してセキュリティー施策の再検討を行い、アイテムとして積む作業を行いました。
いろいろと試行錯誤し、最終的にできたものは以下のようなものになりました。リアルなデータベースはお見せできないため、ダミーのページを用意しています。
ロードマップとして利用する場合にはタイムラインビューをよく利用しています。
ロードマップの周知
なにかを作り直すとそれだけで満足しそうになりますが、ここからが重要です。「セキュリティーバックログとセキュリティーロードマップを作りました！！！」と周知しなければ、グループに対しクローズドな状態のままになってしまいます。周知することでロードマップへの取り組みを知ってもらうと同時に、メンバーの開発時のセキュリティー意識向上も狙えると思いました。
とにかく徹底して周知を行いました。具体的にはSlackへの投稿、月2回のグループ全体定例でのアナウンス、週1回のプロダクトのプランニングの場でロードマップのアイテムについて共有するといった複数のことを行いました。社内のLT会に登壇し、今回のロードマップ再構築について話すということも行いました。
また定例で定期的にセキュリティーバックログの状況について報告する時間を設けるようにしました。とにかく、何度も何度もロードマップについて話すようにしました。
セキュリティーバックログの運用整備
アイテムを積むことと周知までの段階で最初の勢いづけは終わりました。ここからはこの取り組みを継続して何年も行っていけるように整備する必要があります。
セキュリティーバックログに積んだ後どのように開発に進むのか、棚卸しはいつするのかといった運用をセキュリティーチーム内で検討し文章化を行いました。積んだアイテムを決めた流れに沿って実際に進め、問題があった運用は改善を行いました。まだ運用が固まっていない部分はありますが、醸成していくための土台は十分作れたのではないかなと思います。
効果
これらのことを行ったことで、いろいろと良い効果を得ることができました。
まず旧ロードマップを捨てて再構築したことでメンテナンスがかなり楽になりました。期の変わりで新しく作成する必要がなくなったことで過去対応したものも保管しておくことができ、過去～現在～未来のセキュリティー対応状況が一目で分かるようになりました。
Notionが全社利用されているということもあり、既にあるデータベースと新設したセキュリティーバックログを関連付けることが可能になりました。具体的にはロードマップに紐付けたタスク管理が行えるようになったり、既に管理されていたプロダクト側のバックログのアイテムと紐付けることが可能となるといった良さもありました。
セキュリティーバックログに積んだ後は、具体的な要件まで落とし込んでプロダクトの案件化、その後プランニングの場でチームをアサインするという一連の流れになっています。Notion上の関連付け機能を利用したことで、アサインまでの一連の流れがデータ上でも表現できるようになったのは運用設計面でもかなり良かったなと思います。
また今回の取り組みで、メンバーのセキュリティー意識がさらにプラスになりました。メンバー目線でのセキュリティー対策の透明度が上がったことで、開発メンバーの方から「こういった対策をした方が良いのではないか」「これセキュリティーバックログに積みませんか」というセキュリティー対策に関する意見が出てくるようになりました。勿論、これはもともとあるべき姿だとは思います。ですが、クローズドな状態の時にはあまり行えていなかったことだったので、意見を貰えた時はかなり嬉しかったですね。
もう一つ良い効果がありました。データベースに施策を追加する際に「なぜその施策を行うのか」をアイテムのページに記述するようになりました。残念ながら人間は忘れやすい生き物なので、ロードマップにタイトルだけ記述されていると「なぜこれを私たちはやらなければならないのか？」という状態になってしまうことがあります。過去の経緯等をアイテムに書いておくようになったことで、今やる必要がある/別の案件で解決されたので実は必要ないということを早く判断できるようになりました。記録が残っている状態であるということ自体にも価値があると思います。これはルールとして明示したわけでは無かったのですが、チームで運用していく中で自然とこの流れになりました。厳格に決めなくてもこのような流れになったのは、個人的には嬉しかったですね。
最後に
些細なことではありますが、現状の課題に対して改善を行えた。そして大きな効果を得られたというのは良いことだと思います。
新ロードマップを長く使っていくには、まだまだ運用は足りていないと思いますが、そこは今後も改善し続けていく予定です。
