こんにちは。Flatt Security執行役員の豊田 @toyojuni です。
今回のブログでは「セキュリティ診断」サービスに関するお知らせに合わせて、Flatt Securityがどのようにお客様の声とサービス改善に向き合っているかを具体的に紹介したいと思います。
Flatt Securityの「セキュリティ診断」サービスでMarkdown版報告書の提供を始めました。
まず、サービスに関するお知らせというのが「Markdown版報告書提供開始」です。
「セキュリティ診断（脆弱性診断）」とは
まず我々の提供している「セキュリティ診断」というサービスの概要を説明します。
端的に言うと、（巷ではホワイトハッカーなどと呼ばれることもありますが）セキュリティエンジニアがお客様のWebサービスやネットワークにハッキングされるような穴、脆弱性がないかを調査するサービスです。 「脆弱性診断」と呼ばれることもあります。
PDF版に加えて、Markdown版報告書の無償付帯を開始
我々は特にSaaSやスマホアプリ等のプロダクトを提供する開発者・開発組織をメインの顧客層として、セキュリティエンジニアの手動診断 + ツール診断のハイブリッドによる網羅性の高い診断を提供しています。
メインの顧客層は異なるかもしれませんが、この業界にはそれなりの数の競合ベンダが存在します。そして、自分の知る限り他社さんでも最終的なアウトプットは基本的に 報告書 であるはずです。
かつ、そのフォーマットは PDF であると認識しています。
このPDFというフォーマットが根付いているのには
- 慣習的にそうなっている（実際弊社も特に意図はなくPDF形式を採用しました）
- 診断の報告書は、例えばクライアントに提出する証左として用いられることがあるので、編集が容易でないフォーマットである必要がある といった理由があるのかなと推測しています。
ただ、このPDFというフォーマットには、脆弱性の改修を担当する開発者にとっていくつかの難点がありました。
- 指摘事項の内容をテキストデータとして管理したり、GitHubのIssueやタスク管理ツールに起票したりするのが容易でない
- 報告書内に記載されているサンプルコード（例えば脆弱性再現のためのシェルスクリプト等）のコピペが容易でない
例えばこういった課題ですね。
そこで今回、Flatt Securityの診断ではPDF版報告書に加えて、ご希望に応じてMarkdown版報告書を無償で付帯させることができるようになりました。
これによって開発者の皆様にとってタスクの起票や、指摘事項の確認がスムーズになることでしょう。是非ご活用ください！
改善は偶然や自然発生のものではない
今回のサービス改善は、結果だけ見るととても自然なものに見えます。
ですが、この改善は偶然や自然発生的に生まれたものではなく、明確な再現性のある改善のアクションから生まれたものです。
それゆえにこの改善にはもっと早く辿り着くべきだったし、もっと早く辿り着けたと思っています。また一方で、この改善のプロセスはブログでお伝えする価値のあるものだとも思っています。
ここからはなぜもっと早く改善できなかったかという要因分析と、改善に至るまでのアプローチを紹介しようと思います。
是非参考にしていただければ幸いです。
プロフェッショナルサービス事業部は顧客に向き合ったサービス改善ができていなかった
「セキュリティ診断」サービスは我々の組織内では「プロフェッショナルサービス事業部」において提供されています。
プロフェッショナルサービスとは、一つのパッケージを価値として提供するプロダクトとは対照的に、専門家の知見や技術を個別にカスタム可能な、自由度の高い形式で提供するものです。
実際に、アプリケーションの仕様に合わせたオーダーメイドのプラン提案は弊社が特に顧客から評価されているポイントの一つです。
プロフェッショナルサービスの「自由度の高さ」は諸刃の剣
しかし、そのようなプロフェッショナルサービスの特性、すなわち「自由度の高さ」は諸刃の剣でした。
運用やマンパワーによって多少の問題は克服できてしまうので、課題に対して根本的なアプローチを行うインセンティブが働かず、その場限りの課題解決を行なってしまいがちだということです。ソフトウェア開発においては当たり前な継続的なサービス改善とデリバリのサイクルも、明示的に導入しなければ決して生まれることはありません。
また、多くのお客様にとって診断というのはそこまで高頻度に行うものではありません（実は アジャイル開発に合わせた高頻度な実施事例 もあるのですが）。リテンションレートのような概念も短期的に測定可能ではなく、課題の存在が浮き彫りになることもありませんでした。
ユーザーヒアリングの欠如
このようなサービス性質に無自覚であり、改善の基本のキと言えるようなユーザーヒアリングすら実施できていないのが実情でした。お客様への事例インタビューは生の声を拾う機会として存在していましたが、これは広報・マーケティング目的だったのでサービス改善を前提として設計されていませんでした。
その結果、これまで診断結果の精度など技術的な要素ばかりを追いかけており、報告書という自分達の成果物がどのように扱われているのかを把握できず、PDF納品に扱いにくい部分があることに気づけていなかったのです。
もちろん、技術的な改善はセキュリティ診断というサービスにおいて特に価値の高いもので、我々はそこで信頼を勝ち取ってきたという自負もあります。しかし、顧客体験全体を俯瞰して改善タスクのバックログを形成できていなければ、スタート地点として理想的な状態ではないと自分は思います。
そのような状態では顧客目線での改善タスクが出てこず、結果として独りよがりなアクションを打ってしまうかもしれません。誤解を恐れずに言えば、我々は「顧客に向き合ったサービス改善をサボっていた」のでしょう。
改善のアプローチ
ここからは改善のきっかけから実装までを順に追っていきます。
サマリとしては、下記のようなステップで進み、また現在も同様のサイクルを回し続けています。
- ヒアリングを実施する
- 適切に優先順位をつけてバックログを形成する
- 実行するタスクを決定し、関係各所に改善タスクとしてフィードバックする
- 改善されたサービス提供を実施後、1に戻る
きっかけは事業部を跨いだ文化の輸入
ここまで書いたように、プロフェッショナルサービス事業部は自発的に顧客に向き合うアクションが起きない状態でした。
そんなプロフェッショナルサービス事業部にとって顧客に向き合った改善が走り出すきっかけとなったのは、診断とは別で弊社が提供しているプロダクト「KENRO（ケンロー）」と「Shisho（シショー） Cloud」の存在でした。先ほどソフトウェア開発の改善サイクルの話に触れましたが、これら両プロダクトではCTO米内とプロダクト事業部長小島の活躍によってユーザーの声を起点とした良い改善のサイクルが回っていました。
プロダクトの詳細はこちら。
弊社では様々なノウハウを部署やチームを跨いで積極的に取り入れて、「変化」することを恐れない文化が醸成されています。おかげで、プロフェッショナルサービスのような価値提供形式であっても同様の改善のサイクルを回さないといけないね、と事業部メンバーで共通認識を持つことができたのです。
改善のタスクフォースを設置し、ヒアリングを実施
まず行ったことは改善のための少人数のチームの組成です。
このタスクフォースにはCEOの井手自ら加わり、また新卒のメンバーも対等に議論をしながらその活動を推進していきました。まずは独りよがりな改善を脱して「本当に開発者にとって嬉しい診断サービスの提供形態とは何か？」を知ることを目的として定義しました。
次に、上記の目的を達成するべくヒアリングを設計しました。ターゲットであるインハウスの開発組織が診断をどのように発注し、それに関わる準備や結果のハンドリングをどうしているのかといった業務フローに対する解像度を上げるべく、ファクトをひたすら集められるようにしました。
こうしたヒアリングを行う際の定石ではありますが、「何か既存の診断サービスで困っていることはありますか？」と直接的な質問をするのではなく、診断依頼にまつわる作業フローをなるべく網羅的に聞き出すように設計しました。
例えば、納品後のフローに関しては以下のような質問を行いました。
- 診断結果は開発者全体に共有されていますか？
- 診断結果をどのような形で共有されていますか？
- 脆弱性のレポートの修正は誰がアサインしていますか？
- 脆弱性の修正はどれくらいの期間で行っていますか？
- 脆弱性の修正は誰がどうやって確認していますか？
- 複数回診断を受けた経験があるとき、同じ脆弱性が再発したりしていませんか？
既存の顧客の皆様にこういったヒアリングを実施させていただき、非常に多くのファクトを集めることができました。ご協力いただいた皆様には改めてこの場を借りてお礼をさせてください。
ヒアリングの結果をすぐさま社内ツールに実装
ヒアリングの結果、インハウスの開発チーム・開発者にとって「報告書の内容が再利用性の高いデータとして存在する」ことは複数の顧客に求められており、優先度の高い改善事項だと判断しました。
我々は診断にまつわるあらゆる作業を効率化する社内ツール「ORCAs（オルカス）」を開発しています。改善タスクフォースの判断を受けて、開発チームがすぐに「ORCAs」の機能に反映をしてくれました。
元からこうした社内ツールで診断業務・データをハンドリングしていたからこそ今回の改善もすぐにシステムとして実装に落とせたわけであり、開発チームには頭が上がりません。社内ではいつも「『ORCAs』無しでは生きていけない」という話をしています。
このスピード感で実装できたおかげで、お客様にとっても我々にとっても非常に嬉しいことがありました。
Markdown版報告書の出力機能の実装完了の直後に、ちょうど弊社で診断を実施していた Ubie株式会社 の水谷様より「テキストの報告書を提供してもらえないか」というご相談をいただいたのです（こちらからMarkdown版報告書の存在をお伝えする前です）。
早速Markdown版報告書をご提供させていただきました。 この改善がインパクトを生んでいくのはこれからの話ですし、Markdown版報告書自体にもまだ改善の余地はありますが、成果が早くも可視化されたことは大いに励みになりました。
まとめ
ソフトウェアの改善は板についている皆さんでも、それ以外の部分で同様に改善を回すのって意外と難しいということがあるのではないでしょうか。
しかし、本来こういった改善は提供サービスだけでなく、業務プロセス、組織設計など全てに対して行わなければ非連続的な成長に耐えうるものにはならないでしょう。我々も発展途上ですが、継続的な改善を実施すべく組織面等で引き続き取り組みを実施しているので、また別の機会にご紹介ができたらと思います。
Flatt Securityは開発者のためのセキュリティをますます改善・推進していきますので、よろしくお願いします！
弊社のセキュリティ診断にご興味のある方はぜひ公式ページをご覧ください。
お問い合わせは下記リンクよりどうぞ。
https://flatt.tech/assessment/contact
また、この記事を読んでセキュリティ診断にこんなサービス・オプション・そのほか付加価値があればいいなと思った方は記事のシェアと一緒にツイートして教えてください！ Flatt Securityでは引き続き開発者の皆様のセキュリティをサポートすべく様々な情報発信を行いますので、公式Twitterのフォローもお願いします🙏
ここまで読んでいただきありがとうございました！
