この記事は、NFLaboratories Advent Calendar 2022 2日目の記事です。

NFLabs.の稲積です。

NFLabs.では、「世の中で必要とされるセキュリティエンジニアを増やしていきたい」という思いのもと、2022年7月より「セキュリティトレーニングプラットフォーム」の開発を始めました。この記事では、開発スタートからの半年間を振り返るとともに、開発チームで行った取り組みについて紹介します。また、素早く開発を進める上での時間対効果をもとに、筆者の視点から見たチーム開発でのお役立ち度もお伝えします。

プロダクトビジョンボードの作成
インセプションデッキの作成
ユーザーストーリーマップの作成
スクラムによる開発
社内トライアル
さいごに

プロダクトビジョンボードの作成

当初は「セキュリティトレーニングプラットフォーム」というテーマこそ決まっているものの、チームメンバーそれぞれが「〇〇のようなものが欲しい」「××ができるようにしたい」という意見を口々に言う状態で、全体としてイメージが漠然としていました。

そこで、チームとして開発の方向性を決めるため、2時間の打ち合わせで プロダクトビジョンボード を作成しました。プロダクトビジョンボードでは、一枚のオンラインホワイトボードにプロダクトが目指すビジョンを中心に、ターゲット層やニーズ、競合、コスト要因などを列挙し、チーム全員で話し合いました。

完成したプロダクトビジョンボードの図

これにより、プロダクトの方向性を具体化するとともに各メンバーの考えを共有でき、漠然としたイメージを口々に言う状態がやや解消できました。しかし、開発が進んでから見返して役に立った場面があまりなかったため、お役立ち度は星3つです。

お役立ち度：★★★☆☆

インセプションデッキの作成

次に、インセプションデッキ を作成しました。効率的に進めるため、まずは筆者自身で「我々はなぜここにいるのか？」「エレベーターピッチ」「技術的な解決案」のほか、「やらないことリスト」「あきらめるべきものをはっきりさせる」といった内容すべてをたたき台としてまとめた後、チーム内でレビューの時間を設けてディスカッションを行いました。ディスカッションでは、早い段階で社内に見せてフィードバックをもらえる状態にするため、3か月間で完成を目指す項目についても検討しました。

完成したインセプションデッキの図

具体的な開発計画に踏み込んでいることもあり、何を優先するかでディスカッションはやや錯綜しましたが、メンバー各自の意見を共有することで、最終的にはある程度までまとめることができました。

インセプションデッキは、開発が進むにつれて当初の目的に立ち返る際にも役立ちましたが、どちらかというとこれから何を進めるかを具体化する点での効果が大きかったと思います。作成の労力が大きいこと、メンテナンスによって得られるものが少ないこともあり、お役立ち度は星2つです。

お役立ち度：★★☆☆☆

ユーザーストーリーマップの作成

さらに、3か月での開発項目を整理するため、 ユーザーストーリーマップ を作成しました。あらかじめ二名で架空のユーザ像である「ペルソナ」の候補を5つ作成しました。そして、打ち合わせの前半でチームメンバ全員による投票により「ペルソナ」を一つに決定し、このペルソナを前提とした「プロダクトゴール」を決定しました。打ち合わせの後半では、ペルソナがプロダクトを利用する一連の場面を時系列で整理し、それぞれの場面で「できるべき項目」をメンバ全員で列挙しました。最後に、Minimum Viable Product（MVP; 最小実用製品）として3か月間で優先的に取り組む開発項目を決定しました。

完成したユーザーストーリーマップの図

本来はチームメンバで列挙した項目すべてがスクラム用語でいうところの「プロダクトバックログアイテム」となるのかもしれません。しかし、今回はMVPに含めた項目のみをバックログアイテムとしました。これは、チームが少人数であるため、全体として優先すべき項目をわかりやすくするため、そしてバックログアイテムの管理負荷を軽減するためです。残りの項目は、バックログアイテムに取り組む際に参考とする形で活用しました。まだ動く状態の完成物がなく想像による項目が多い段階だったため、現時点でこの方針はよい方向に働いたと思っています。

しかし、開発メンバー間で上がっているアイテムの認識が合っていなかったり、各自思い思いに新しいアイテムを追加する状況が発生したりと、開発の優先順位を決める上で機能していない状況も発生したことから、お役立ち度は星3つです。

お役立ち度：★★★☆☆

スクラムによる開発

ようやく開発です。開発では手法としてスクラムを採用し、プロダクトオーナーとスクラムマスターを決定しました。そして、スクラムマスターが2週間というスプリント期間とスクラムイベントのスケジュールを決定し、スプリントごとに開発を進めました。

GitLabによるバックログ管理の図

チームが少人数であることから、プロダクトオーナーが開発者兼務となったり、次に取り組む項目が二転三転したりもしましたが、6スプリント過ぎたころにはそのようなことも少なくなりました。一方で、プロダクトバックログアイテムの分割やストーリーポイントの割り振りについてはたびたび議論が紛糾しました。この問題についてはまだこれといった解決策が見えていませんが、筆者個人の視点からはスクラム手法の形式にこだわりすぎないほうがよいように感じています。

また、各メンバが今回取り上げたプロダクト開発以外の業務を行うことがたびたび発生しました。これについては、相談の結果、明示的にバックログアイテムとして管理に加えることにしました。その結果、毎朝のデイリースクラムで扱える話題の制限が緩くなり、チーム内での状況共有がしやすくなったように思います。

一方で、スクラム自体に理念的な内容が多く、その理想通りに行うことが難しい場面もしばしばありました。スクラムのためだけの作業が増加するなど自己目的化に陥りやすいという側面もあり、今後の改善は継続しつつもお役立ち度は星3つです。

お役立ち度：★★★☆☆

社内トライアル

開発スタートから3か月後の9月末、MVPに含めた開発項目がほぼ完了しました。一部開発が完了しなかったものについては代替手段を取ることとし、10月上旬に完成物を2週間の期間で社内にトライアル版として公開し、フィードバックを依頼することにしました。

3か月という短い開発期間のため、この時点で完成した機能は十分とは言えません。そこで、フィードバックを集めるにあたり、三つの工夫をしました。

1. 実際の社内部門に合わせてテストアカウントを作成する

完成物に現実感を持たせるために、社内の各部門を1チームとし、各チームに三つのユーザアカウントを作成しました。部門ごとにコミュニケーションを取りながらフィードバックしやすくしたり、アクセス制御等の不備を探しやすくすることが目的です。

2. 説明資料に想定するフィードバックの例を記載する

1と合わせて、社内トライアルの説明資料に、各部門から見たフィードバックの視点を記載しました。今後、全社的に活用できるプロダクトとするため、各部門で実際に行っている業務に近い視点を挙げることで、全体としてのフィードバックの敷居を下げることが目的です。

3. フィードバック項目のカテゴリを分割する

ひとことにフィードバックと言っても、既存機能が使いにくいといったものから、プロダクトに今後欲しい機能、セキュリティ上の問題の指摘までさまざまなカテゴリが考えられます。そこで、どのような人でもフィードバックを書けるようにExcelファイルを用意し、「セキュリティレビュー」「トライアル体験感」「機能要望」をそれぞれ別個のシートとして作成しました。また、サポートは別途チャット上で受け付けるようにしました。

Excelファイルを使用している理由には、フィードバックの敷居を下げる目的に加え、他の社員のフィードバックも含めて順に見えるようにすることで、網羅性を高めるのが目的です。また、トライアル期間の終了まで回答は行わないようにしました。これは、質問や相談の場ではなく、完成物を対象とした主体的なフィードバックの場であることを明確にするのが目的です。

最終的に、社内の協力のおかげにより、多数のフィードバックを集めることができました。また、実際にシステムの運用を行ったことにより、運用面での機能要望も考えることができました。

集まったフィードバックの図