こんにちは、Assured事業部の岩松です。先日、Visionalグループとしてクラウドリスク評価「Assured(アシュアード)」を正式にリリースしました。本記事ではこの新規事業がどのように仮説検証を進めてきたのか、技術観点でどのような取り組みをしてきたのかご紹介します。ここで紹介する技術や仕組みは、新規事業という文脈において「やらなくても良いのではないか」「悪手なのではないか」と感じられるものもあるかもしれません。

Startups are very counterintuitive.

~ Before the Startup

「スタートアップは極めて直感に反する」というY Combinator創業者Paul Grahamの言葉通り、スタートアップもしくは急成長を目指す新規事業においては、一見うまくいかないと判断される反直感的な選択が正しい場合も多いのではないかと考えています。そこで「逆説のスタートアップ思考」という書籍に倣い、正式リリースまでを振り返って「役に立っている」「うまくいっている」　と感じることができている「逆説的」な技術選定をご紹介させていただきます。ここで紹介する具体的な技術自体は必ずしも他のケースでうまくいくとは限りませんが、その選択へと導いた考え方が参考になれば幸いです。

「Assured」とは

昨今「DX(Digital Transformation)」が声高に叫ばれる中、企業がクラウドサービスを利用する機会は増え続けています。同時にクラウドサービスの利用をきっかけとしたセキュリティインシデントのリスクも年々増加しており、企業は社内でどのようなクラウドサービスを利用しているのか、それが本当に安全なのかを把握するために多くのコストをかけるようになりました。具体的にはセキュリティチェックシートと呼ばれるExcel等でまとめた監査項目をクラウドサービス事業者に送付することが多いのですが、クラウドサービスの利用企業やクラウドサービス事業者どちらにとっても負荷の高い業務となっている実情があります。また、社内にセキュリティの専門人材が充足している企業は多くないため、セキュリティチェックシートを集めたとしても適切に評価、活用できないという課題もあります。

「Assured」は、そうした企業にクラウドサービスのセキュリティ評価情報を集約したデータベースを提供しています。統一されたフォーマットで集められた情報をCISA等の資格を持つ専門チームが評価することで、企業がより安全、安心なクラウドサービス利用を促進し、世の中のDXを加速させようとしています。

Assuredの概要
Assuredの概要

「Assured」立ち上げの軌跡

昨年(2021年4月)Visionalグループのビジョナル株式会社は上場しました。この上場の際に見えた課題から、セキュリティチェックシートを介したクラウドサービス利用企業、クラウドサービス事業者の両側に社会として大きな課題があるのではないかということで仮説検証をスタートさせています。

事業初期でもモノを作る

クラウドサービス利用企業におけるセキュリティ担当者やクラウドサービス事業者の開発責任者、セキュリティ領域における専門家等、100人以上の方からお話を聞いていく中で、多くの企業で飛び交うセキュリティチェックシートには基となるものがあるとわかってきました。それは経済産業省や総務省が提示しているチェックシートであったり、そのベースとなっているISO/IEC 27001やISO/IEC 27017といった標準規格、NIST SP800-53といったセキュリティガイドラインでした。文章表現はそれぞれ異なりますが、本質的に確認したいことは共通しているため、統一されたフォーマットのセキュリティチェックシートで既存の確認フローを置き換えられるのではないか、ひいては、お客様が我々の提供するデータベースを利用していただけるのではないか、と考えました。国内外問わずセキュリティのガイドラインを読み漁り、セキュリティの専門家の力を借りながら、Excelを用いてセキュリティチェックシートのプロトタイプを作り上げたのですが、作業を進める中でいくつかの課題が見えてきました。

要は編集作業が人の手には余るということですが、これはコード管理およびデプロイの課題と同じなのではないかと気づきました。こうした課題を解決するために、エンジニアに馴染みの深いツールを用いてセキュリティチェックシートのデプロイワークフローを構築しました。

GitHub を用いたセキュリティチェックシートのデプロイフロー図
GitHub を用いたセキュリティチェックシートのデプロイフロー図

こういった仕組みやシステムを作るのはエンジニアにとって楽しいことですが、一般的には避けるべきとされています。

失敗したスタートアップのなんと74%が、初期段階で「プロダクト（解決策）の検証」に時間を割いている。

~ 起業の科学 スタートアップサイエンス

この段階で事業として求められるのは「課題が存在するか証明すること」であり「解決策を検証すること」ではありません。しかし、このまま手作業でセキュリティチェックシートを作り続ければ「解決策の検証」に時間を割きすぎてしまうのではないかと考えました。したがってシステムを構築することこそ、逆説的に課題の検証を早められるのではないかと判断しました。また、数多くのヒアリング経験から、セキュリティチェックシートはこの事業領域の根幹と感じており、文言改善の効率化やデータの構造化に早期から取り組むことで、中長期的な運用コストに見合うことはもちろん、そうして洗練されたセキュリティチェックシートが事業の強みとなるはずだという確信もありました。

実際に作ってみた結果は大きな成功だったと言えます。セキュリティチェックシートの精度を継続的に上げられるようになったため、もともとExcelでセキュリティ評価を行っていたお客様から見ても「Assuredのセキュリティチェックシートはわかりやすく網羅的だ」と高い評価をいただけ、既に運用されていたセキュリティチェックシートを代替できるようになったからです。また直近では非エンジニアであるセキュリティ監査チームにもセキュリティチェックシートをGitHubで直接編集してもらうことで、改善効率がより高まってきています。

MVPの構築にKubernetesを採用する

Excelによってセキュリティチェックシートそのものを置き換えられるとわかったため、次にこれをシステム(データベース)に置き換えても問題ないかを検証しようと考え、MVP(Minimum Viable Product)の開発をスタートしました。MVPは「必要最小限の機能を持ったプロダクト」と表現されますが、単に必要最小限の機能を作るのではなく信頼性や使い勝手にも気を配らなくてはなりません。

特に、「Assured」は

という特性があり、この段階ではビジネスの検証結果次第でターゲットユーザや提供価値も変わり得るため、堅牢でありながら柔軟に構成を変えられる技術基盤が求められました。そこで選択したのがKubernetesです。

一般的にKubernetesは構成を管理しやすくスケーラビリティが高いため大規模なシステム運用に向いているとされています。しかし中小規模、特に新規事業においてはオーバースペックであり、学習コストや運用コストの面でオーバーヘッドとなる可能性が高くなります。またMVPは必要最小限の機能で実現すべきとされることから、構成管理をはじめとしたKubernetesの強みはNice-to-have(あればよい)な機能となり一般的には重視されません。ですが私たちはKubernetesが

といった性質を持つ点に注目しました。よって「Assured」のような事業特性ではKubernetesの機能が逆説的にMust-have(必要)な機能に変わり得ると判断しました。

実際にKubernetesを選択した結果、そうしたメリットを享受しつつ上手に運用できていると感じています。チームメンバー全員にKubernetesの経験があったため学習コストを一定抑えられた面もありますが、運用コストに関してはマネージドサービス(Google Kubernetes Engine)を利用することでさらに圧縮できたからです。例えば

といった、GKEが提供する機能を最大限に活用する事で、Kubernetesの運用に割く時間を減らせています。(Google Cloud Platformを選択した経緯についてはこちらの記事でもお話させていただいています)

デリバリー作業の負荷を上げる

こうしてMVPの開発を進めていき、2021年1月からβバージョンとして一部のお客様へ提供を開始できるようになりました。このMVPを検証するために、お客様にとって使える(もしくはなくてはならない)サービスとなる事が目標でしたが、当時のAssuredチームには開発を進める上で以下の課題がありました。

スタートアップや新規事業において不確実性が高く人手が足りないというのは当たり前の事ですが事業性質上、品質を下げる事はできないため、より効率的な開発フローにしていく必要がありました。そこで導入したのがFeature Flag(Feature Toggle)という仕組みです。これは機能を提供するとき、Feature Flagが有効となっている一部のユーザにのみその機能が提供されるように制御する仕組みです。逆にFeature Flagが無効となっているユーザには機能は提供されないため

といった事ができるようになります。しかし、これを裏返すと処理の分岐が増え将来的な負債となる可能性があったり、フラグを適切に管理しないと機能がQAされずにリリースされたり、画面の差異によってCS等のコミュニケーションコストが増大するという負の側面も見えてきます。これらのリスクに対しては

といった解決策が考えられますが、MVPの検証において重要なのは素早いデリバリーと変化です。よって一般的には運用上の制約を過剰に増やさないよう気をつけなければなりません。しかし「実装途中でもメインのブランチへマージできる」事によってタスクが小さくなり、ブランチのコンフリクト解消や大規模なQAといったビッグバンリリースが起こりにくくなります。また「機能の公開タイミングをデプロイから切り離せる」事でリリース時間の調整やブランチをマージする順番の考慮といった細かな制御が必要なくなります。これにより、運用の負荷を上げたとしても逆説的に素早いデリバリーと変化を実現できるのではないかという結論に至りました。

実際に運用してみて、前述したメリットによる恩恵を強く感じられています。大きな機能開発も小さな機能開発も並列して反映できるようになったため、開発の優先順位が突然変わったとしても問題なく対応できるようになりました。また本番環境でしか確認できないような機能や、いきなり全体には公開しづらい機能だったとしても、公開前に確認できるようになった事で大きな安心感を得られるようになりました。結果としてAssuredチームは安定的にリリースし続けられるようになり、ビジネス変化に強い開発フローを構築できていると感じます。また、Feature Flagのリスクに対してはコードを細かく整理したり、プロダクトマネージャーが中心となってフラグの管理を徹底することで対処しています。運用の手間が多少残ってしまいますが、やはりデメリットよりもメリットの影響が大きいと感じています。Feature Flagを導入するにはLaunchDarklyなどのSaaSを利用することができますが、前述の通り仕組み自体は単純なので「Assured」では自分たちで実装しています。

「Assured」のエンジニアチームが逆説的な選択をしてきた理由

新規事業において、「Assured」のエンジニアチームが非合理的、非直感的とも取れる仕組みや技術を選択してきたのは、目的意識の強さがあったからだと考えています。そしてその目的は常に「事業が成長するか、より成功に向かえるか」という点にありました。技術だけでなくビジネスや組織など、事業を取り巻くもの全てに関心を持った上で最適な実現方法を考える姿勢がチームの中にあります。

こういったチームメンバーが集まり事業づくりに邁進するAssured事業部ですが、事業としては始まったばかりであり、目指したい世界観を実現するためにはまだまだ力が足りません。もし本記事で「Assured」や開発チームに興味を持った方がいたら、ぜひ気軽にカジュアル面談してみませんか？「Assured」の採用サイトも用意しましたので、「Assured」をより深く知っていただければと思います。

また、チームメンバーへのインタビュー記事も別途作って頂いたので、こちらもぜひご覧ください。どのような想いを持ったメンバーが集まっていて、チームとして何を大事にしているのかお話させて頂いています。

Assured 採用情報

Assured エンジニアインタビュー

岩松 竜也
岩松 竜也

Assured事業部エンジニア。最近はカロリー計算と筋トレの事ばかり考えている。