株式報酬SaaS事業を展開するNstock株式会社は、ISMS（※）の国際規格である「ISO / IEC 27001:2022」の認証を取得しました。

一般的にセキュリティ等の外部認証は「守り」の施策であり、現場にとっては「面倒な作業が増える」「ルールで縛られる」と受け取られがちな側面もあります。

しかしNstockでは、今回のISMS認証の取得を単なる取得のための整備ではなく、事業を加速させるための「成長の基盤づくり」と捉えて推進してきました。

今回は、ISMS認証の取得プロジェクトを主導したコーポレートITの東 耕輔（以下、higashi）、CTOの田中 清（以下、tanakiyo）、そして共同創業者の高橋 昌臣（以下、macha）が集まり、プロジェクトの裏側やNstockの「王道を行く」セキュリティ文化について語りました。

※Information Security Management System、情報セキュリティマネジメントシステム

形式だけの取得はしない。あえて時間をかけて「王道」を選んだ理由

── まずはISMS認証の取得、お疲れ様でした。そもそも、なぜISMS認証を取得したのでしょうか？

macha：私としては、前職SmartHR時代の経験もあり、SaaSとして信頼を得るために第三者評価を得るのは「やって当たり前」という感覚があります。そもそもISMS認証がないとサービス導入の検討をしてもらうことすら難しくなってしまう。

特にNstockのユーザーは、上場を目指すスタートアップから上場企業まで多岐にわたります。エンタープライズ企業への導入が増えるとSOC2（Type2報告書）の開示なども求められるでしょう。今の段階でしっかりとした土台を作っておくことは必須だと考えました。

higashi：そうですね。コーポレートエンジニアとしても、SaaSやツールを採用する際に第三者評価がないと、なんでないの？と思ってしまうのが正直なところですね。それくらい最近のサービスはどこもしっかりやっている印象です。

higashi：今回はNstockの祖業である株式報酬SaaSを対象に、約1年かけて取り組みました。スピーディに進める選択肢もありましたが、私たちはコンサルティング会社にもサポートいただき、あえて時間をかけて「王道」のアプローチで進めることを選びました。

tanakiyo：僕たちが一番避けたかったのは、形だけ整えて実態が伴わない運用になってしまうことです。杓子定規なルールを作って、現場は「なんでこんな無意味なことやらなきゃいけないの？」と疲弊する……みたいな状況はしんどいですよね。

取って終わり、ではないんです。全社で一定のセキュリティ意識を持つレベルに持っていかないといけない。

全社で「当たり前のこと」として運用できるレベルを目指しつつ、いかに省エネで回せる仕組みを作るか。自分たちの業務フローの中に自然とセキュリティ対策が組み込まれている状態を作りたかったんです。

higashi：まさにその通りです。ISMSという規格自体は、セキュリティをやっていく体制をつくり、維持していますよという証明です。なので、審査では規格の要求事項に則っていますか？ということが確認されます。

その要求事項が、実はとても抽象的なんです。「情報資産を特定しなさい」「リスクを管理しなさい」とは書いてありますが、具体的にどうやるかは組織に委ねられています。こうした中で、近道をするのではなく、王道を歩む方が運用まで含めると結果として早いと考えました。

表面的な体裁を整えるのではなく、自分たちの手でリスクを洗い出し、議論し、Nstockの実態に即したルールを一から作り上げる。そこにこだわった結果、1年という期間が必要だったんです。

スタートアップの武器を損なわない「リスクベースアプローチ」

── 具体的に、どのようにルール作りを進めていったのでしょうか？

higashi：セキュリティ対策って、やろうと思えば無限にコストをかけられるんですよ。性悪説ですべてをガチガチに固めれば安全にはなりますが、それをやるとスタートアップの最大の武器である「機動性」や「柔軟性」が完全に損なわれてしまいます。

そこで重要になるのが、「リスクベースアプローチ」という考え方です。

tanakiyo：すべての情報を同じ強度で守る必要はない、ということですよね。

higashi：そうです。私たちが持っている情報は多種多様です。お客様の未公開の資本政策に関わるような「機密情報」もあれば、社内のランニング部の活動記録のような「漏れても事業インパクトがない情報」もあります。

これらすべてを最高レベルの強度で守ろうとすると、業務が回りません。情報の重要度とリスクの大きさに応じて、セキュリティレベルにグラデーションをつけることが重要なんです。

macha：なるほど。FISC（金融情報システムセンター）の安全対策ガイドラインでも、その考え方は重視されてますよね。

higashi：おっしゃる通りです。金融ドメインに関わる私たちにとって、FISCの考え方は非常に参考になります。リスクベースアプローチは、セキュリティの「王道」であり、最も合理的な手法なんです。

今回のプロジェクトでは、プロダクトチームやビジネスサイドのメンバーも巻き込んで、「この業務にはどんなリスクがあるか」「この情報はどれくらい重要か」を徹底的に洗い出しました。その上で、規格の要求事項を埋めるだけでなく、自分たちのリスクに対する現実的なルールを合意形成していきました。

tanakiyo：その「合意形成」が大事ですよね。一方的に「こうしてください」と押し付けるのではなく、「ここはリスクが高いから、ここまではやろう。でも、ここはリスクが低いから利便性を優先しよう」という議論ができた。

だからこそ、現場も「やらされ仕事」ではなく、納得感を持ってルールを守れるようになったと思います。

macha：専門家がいないと、どうしても「全部ガチガチにする」か、逆に「何もかもザル」か、極端な方向に行きがちですよね。higashiさんが入ってくれて、リスクベースで整理してくれたのは本当に大きかったです。

higashi：ありがとうございます。スタートアップとしてのスピード感を損なわずに、でも守るべきところは守る。バランス感覚を大事にしていきたいですね。

「セキュリティ担当が孤立しない」全員が高い意識を持つ文化

── セキュリティ強化を進める上で苦労したことはありましたか？

higashi：一般的に、セキュリティ担当や情シスは「正論でぶん殴る」役になりがちなんですよ（笑）。「これは危ないですよ、やめてください」と言い続けて、現場から「あの人が来ると仕事がやりにくくなる」と煙たがられ、社内で浮いてしまう……というのは、よくある話です。

個人的にはなるべく実例を添えたりすることで、「よくわからないけど危険なんだな」じゃなくて、「なるほどそういう危険性があるのか」と納得してもらうことを心がけています。

tanakiyo：伝えるときの温度感って難しいですよね。話し手と受け手のリテラシーに差があるとなかなか伝わらない。

higashi：まさにそうなんです。

ここまでが一般的な話で...... Nstockでは本当にスムーズでした。

macha：うれしい！それはなぜだと思います？

higashi：最大の理由は、経営陣はじめ全員が「信頼がビジネスの根幹である」と深く理解しているからだと思います。 私たちは金融ドメインでビジネスをしています。事業を進める上で守らなければいけないルールが共有されているので、「なぜこのセキュリティ施策が必要か」という説明が腹落ちするんだと思います。

tanakiyo：確かに。「面倒くさい」という感情よりも、「事業を守るために必要だよね」という納得感が先に立ちますよね。

higashi：そうなんです。Nstockが複数の金融事業を営んでいくために必要になった取り扱い情報の分離の仕組み（ファイアウォール）を構築する時もそうでした。今年6月にホールディングス体制へ移行する過程で、親会社であるNstockホールディングスと子会社であるNstockの間で情報を適切に分離する仕組みが必要になったんです。

特定の情報にアクセスできる人を制限するために、Slackのチャンネル設計やNotionの権限管理を厳格化したのですが、これって絶対不便なんですよね。

でも、Nstockのメンバーは「インサイダー情報を扱っているのだから当然だよね」と、その背景にあるリスクを理解して、新しいルールにスムーズに適応してくれました。

macha：そうですね。開発の優先度を考える際にも、このセキュリティ意識の共有は大事だと思っていて。

全員がセキュリティは重要だ、という認識を持っているから、セキュリティ対策に開発リソースを割く判断がスムーズに出来ているんでしょうね。

tanakiyo：特に営業からすると、トップラインを伸ばすために「攻めるための機能開発」の優先度を上げてほしいと思うのが普通だと思います。その中で、セキュリティの重要性を認識してもらえているのは本当にありがたいですね。

higashi：この「話の通じやすさ」は、セキュリティエンジニアとして働く上で本当に幸せな環境だと思います。「孤立しない」というのは、言葉以上に大きな価値がありますよ。

目指すのは、全員が「セキュリティに自信がある」と言える組織

── Nstockのセキュリティは、今後どのようなフェーズに向かうのでしょうか？

tanakiyo：金融領域の事業も増えていきますし、扱う情報の重要度も上がっていきます。なので、しっかりとしたセキュリティ対策が必要不可欠です。

ただ、他社がやっているからといって同じ施策をとりあえず導入したり、形だけ整えたりしても意味がありません。将来必要になるレベルを見据えつつ、今のフェーズに最適な投資判断をしていくことが重要です。

higashi：そうですね。具体的には 「プロダクトセキュリティ」の強化が急務 です。

機能が増え、システムが複雑化するにつれて、アタックサーフェス（攻撃対象領域）も広がっていきます。それらを継続的に洗い出し、脆弱性を評価し、対策を打っていく。

年に一度の脆弱性診断はすでに実施していますが、専任のスペシャリストを迎えて、より専門的かつ継続的に取り組むべきフェーズに来ています。

macha：そうした高い要求に応えつつも、プロダクト開発に携わるメンバーに限らず全員が「自分たちはセキュリティ意識をちゃんと持っています！」と胸を張って言える状態を作っていきたいですね。

これからNstockのセキュリティエンジニアになる方へ

── 最後に、Nstockに興味を持たれたセキュリティエンジニアへメッセージをお願いします。

higashi：Nstockの魅力は、コミュニケーションコストが圧倒的に低いことです。その日居合わせたメンバーで、職種もごちゃ混ぜでごはんに行けるような軽やかさがあります。その中に代表の宮田さんがいたりもする。

セキュリティを推進するのにお金や体制も必要ですが、いちばん大事なのはコミュニケーションだと思っています。関係値を0から1にするハードルが低いので、会話をベースにして組織に合ったセキュリティを作っていける環境です。

tanakiyo：間違いないですね。補足すると、私達はセキュリティエンジニアの方に「丸投げ」したいわけではないんです。

QAエンジニアに近いイメージなのですが、「専門家で全てやってね」ではなく、開発チームがセキュリティを意識して作業をしていく中で、そのガードレールを作ったり、旗振り役をしてくれたら嬉しいなと思っています。

macha：事業会社でセキュリティをやる面白さは、「結果を見届けられる」ことだと考えています。

コンサルタントやベンダーの立場だと、限られた期間での提案や納品で終わってしまうことも多いと思うのですが、事業会社なら、自分が構築したセキュリティ基盤がどのように事業成長に貢献したか、あるいはインシデントをどう防いだか、その後の運用まで責任を持って見届けることができます。

事業会社にチャンレジしたい方にも、ぜひNstockを考えてほしいですね。

higashi：自分たちが守ったプロダクトが成長し、お客様に価値を届けていく様子を一番近くで見られるのは、エンジニア冥利に尽きます。「セキュリティ担当は孤独だ」と感じている方にこそ、ぜひNstockの環境を見てほしいですね。

tanakiyo：セキュリティエンジニアとしての専門性を発揮しながら、事業や組織づくりにも深く関われる、非常に面白いフェーズです。少しでも興味を持っていただけたら、ぜひお話ししましょう！

お知らせ

Nstockでは、事業の成長を「信頼」で支えるプロダクトセキュリティエンジニアを募集しています。