自社サービスを評価されるということ
この記事は MICIN Advent Calendar 2025 の 15 日目の記事です。
前日は otezou さんの 「ユビキタス言語」と「機能の制御」の重要性 でした。
はじめに
今から私がお伝えすることは、とてもニッチな内容です。
ちなみに”ニッチ”の語源は「壁のくぼみ」であるという説が有力そうなので、25年の師走の私は積極的に壁のくぼみに身を寄せていこうと思っています。
私が書く内容は、恐らく日本の総人口のうちギリギリ50人くらいの人が「あるよね！そういうことも」と共感できる内容になりますので、以下のサマリーを読んで「僕・私には一生関係ないな」と思ったらソッとブラウザを閉じて街へ繰り出し、気の置けない仲間達と一杯酌み交わしながら日本国の行く末について憂い、そして希望を見出した方が100倍生産的な時間が過ごせるかと存じます。
あと、画像を一切配置しないストロングスタイルで書き切るので、目がチカチカすると思います。
お伝えしたいことのサマリー
- SaaSを（特に）toBで導入する際には、顧客からアセスメント（評価）というプロセスを受けないと、導入してもらえないよ
- ベンダーにとっても顧客にとっても、アセスメントはとても大変だよ。でもポイントがいくつかあるよ
- 大切なのは、日頃から記録をきちんと残し、アセスメントの際には曖昧に答えていくのではなく具体的に、そして相手方の体制をきちんと理解した上でアウトプットの量・質をコントロールして情報提供していくことだよ
- だから、アセスメントは怖くないよ！僕と友達になろうよ！！
です。
サービスのアセスメント(評価)とは
気づけば世の中には多種多様なSaaS型のサービスがあり、弊社もベンダー（提供者）として数多くの顧客・ユーザーにサービスをご利用いただいています。
SaaS型のサービスは導入が比較的に容易である一方、領域によっては個人情報や医療情報等を簡単に入力できてしまうため、特にtoBの領域ではシステムとしてのセキュリティの堅牢性や、そもそも法規制・ガイドラインに準拠したサービスであるか等々を厳しく顧客から問われます。
抽象度を上げると「このサービス、ウチの会社で本当に使って大丈夫なの・・？？」という問いに対してお答えしていくのが「アセスメント(評価)」と呼ばれる一連の営みになります。
インターネット上で「SaaS アセスメント」といったクエリで検索してみると多くのページがヒットします。（例：SaaSのセキュリティ評価を実施するには）
2,3ページでも見ていただくと、何となくアセスメントの輪郭が見えてくるかと思います。
一般的なtoBでのアセスメントの流れとしては、以下の通りとなります。
- 顧客から300項目くらいの質問表がベンダー（弊社）に送達される
- ベンダー側で質問表に記入し、お返しする
- 記入された回答に対して顧客側で疑義を出し、事前にある程度の疑義解消をオンラインで行う
- 実地ないしオンラインで、回答の根拠を詳細にご説明する”監査”を実施する
- 顧客側で監査の結果をまとめ、指摘事項を整理し、結果をベンダーに通達する
- 指摘事項のうち対応が必要なものはベンダー側で対応内容と期限を整理し、顧客に宣言する
- 対応が完了したらその旨を顧客にお伝えする
私はここ2年ほど、自分が担当しているサービスのアセスメント担当者として様々な医療機関や製薬会社からのアセスメントに対応してきましたので、この辺りで自分自身の棚卸しを兼ねて「アセスメントを受けるにあたって重要になってくるポイント」をつらつらと書いていこうと思います。
[ポイント1] 大前提として正直に、具体で、そして曖昧にしない
最初のポイントは
誤魔化さない です。
「納期」という言葉は、多くの人が忌み嫌う単語でしょう。
それは既成事実として真綿のように首を絞め、毎日着実に目減りしていく残り日数を睨みつけながら「何故もっと早めに動かなかったのか」「何故あそこであの判断をしたのか」と呪詛を呟きながら遠い目をして現実逃避する、そんな事態の元凶になりうるものです。
当然のようにサービスの導入にも納期があり、◯◯◯◯年◯月◯日までに稼働できる状態とする、といった決め事が多くのプロジェクトで存在しているはずです。
この「サービス稼働開始の納期」というパワフルな既成事実に対して、システムアセスメントというプロセスは不確実性が高く、場合によっては納期が2,3ヶ月遅れになるなど、プロジェクトの進捗を大きく左右する変数となってきます。
これは決してサービスの提供元（ベンダー）である弊社だけでなく、製薬会社や医療機関の先方担当者様にとっても当然喜ばしくないことであり、プロジェクトに関わる全ての人にとってアセスメントの営み次第でプロジェクトがアンハッピーな方向に進んでいくわけです。
ここで大事になってくるのが「誤魔化さず、事実をきちんと、求められる量できちんとお伝えする」ということになってきます。
ありえないケースですが、わかりやすく少し脚色して例示してみます。
問い：システムに記録されるデータは定期的にバックアップが記録され、複数世代のバックアップからの復元が出来るか？
という設問をアセスメントで問われたとします。
実は自社のサービスでは「バックアップは取られており復元も可能ではあるが、複数世代からのバックアップが行えない」という状況だったとします。（考えにくいことですが）
ここで大事な部分は誤魔化し、
回答：定期的にバックアップが取られており、復元が可能です。
と回答したとします。一見すると問題のない回答のように見えますが、この回答を受け取った顧客の担当者はこう思うはずです。
追加の問い：
定期的なバックアップとは、具体的な頻度としてどれくらい？
バックアップデータはどこの領域に保存されるのか？
復元が可能というが、複数世代からのバックアップはできないのか？
といった追加の疑義が発生し、結局はひとつの設問に対してのやり取りに繋がり、最終的な納期の遅延に繋がっていってしまいます。
後述しますが、特に顧客の中でグローバル側にも確認を入れなければいけないというように体制が多重構造になっている場合には、このひとつの設問の疑義解消だけに2-3週間かかってしまうこともあり、結果的に誰も望んでいない納期遅延の温床になってしまうのです。
[ポイント2] 先方の体制を理解し、アウトプットの量／質を調節する
次のポイントは
受け手が扱いやすいアウトプットを提出していく です。
最近多くのインプレッションを記録したNoteの記事で、ザックリとまとめると
顧客の担当者はこれ以外の色々な仕事もやってるし、あなたのアウトプットもわかりづらいし、だからあなたのSaaS導入は進まないのですよ
という記事があったことを記憶している方もいらっしゃるかもしれません。
仰る通りで、アセスメント対応においても
- 相手（顧客）の体制を理解する
- 相手が取り扱いやすいアウトプットを提供していく
が非常に重要になってきます。（アセスメントに限らず、全ての仕事に通ずるところですが・・）
まずは体制面の話。
特に、製薬会社であり且つグローバル製薬の場合は
私＞先方の担当者＞先方内の情報セキュリティの部署＞グローバル側の情報セキュリティの部署
というように、多重的に体制が存在するケースが多くなってきます。
こういったケースではグローバル側の情報セキュリティの部署がアセスメントの出元になっていることが多く、情報の出発点である”私”が提供した情報は何人もの人間を経由してグローバル側の担当者に到達する体制であることを理解した上で、アウトプットの量・質をコントロールする必要があります。
大切なのは「このアウトプットを誰がどのように使うか」を常に意識・想像していくことです。
例：
- 私が今整理して提供しようとしている自社システムの構成図は、まずは先方の日本側担当者Aさんに対して提供するものである
- Aさんは私が提供した図をまずは理解しようとした上で、別の部署である情報セキュリティの部署に対して自社内で説明を行うはずである
- 説明を受けた情報セキュリティ部署のスタッフは当然、不明点をAさんに投げかけるはずであろう（通常、図を見せて一回で終わるはずはない）
- Aさんはシステムの専門家ではないため専門的な内容には回答しづらく、恐らく私に対して質問内容が飛んでくるであろう
- 〜〜〜〜 この間も色々発生するが省略して・・ 〜〜〜〜
- ようやく日本側で整理された情報を元に、私が提供したシステム構成図がグローバル側の担当者に提示されるはずである。きっとその際には英語に翻訳されて提示されるであろう
- システム構成図を受け取ったグローバル側の担当者は、このシステムに対しての前提知識はゼロの状態から始まるので、ここでも様々な質問が出てくるであろう
上述のように、軽い気持ちで私が提出したシステム構成図は、幾重にも重なる多重的な担当者間を行ったり来たりしながら、本来の意図がしっかりと伝わりきるまでに多くの時間を要することになります。
ここでようやくアウトプットの量と質の話に戻りますが、意識する点としては例えば
- こんなに沢山の情報を提供しても、私が相対している担当者にとっては不要な情報も多く、余計な論点や疑義が生まれてしまうであろうから、必要な情報に絞る
- 私が提供するこの情報を担当者が英訳する手間を省くことでリードタイムを短縮できるはずなので、初めから日・英の併記で情報を整理する
- システム構成図のこの箇所は、日本の基準からすると大きな論点にはならないはずだが、EUの情報セキュリティ規制からするとほぼ確実に指摘が発生するので、先んじて情報を補強しておく
といった点を意識してアウトプットを提供するだけで、アセスメントの営み自体がスムーズに進んでいくはずです。
一瞬だけ吐き出しですが、別にこれはアセスメントに限った話ではありませんよね。
とにもかくにも自分のアウトプットを誰かがさらに別の誰かに説明し、そこには膨大なコミュニケーションコストと思考メモリーの消費が発生することを理解しようとしないで物事を進めようとする人は案外沢山いますよね。良くない。
[ポイント3] 残す、残す、とにかく残す
ポイント1と2はアセスメントに限らず多くの仕事に通ずる部分かと思いますが、ポイント3については医療系のSaaSならでは、といった箇所かもしれません。
3つめのポイントは
ひたすらに記録を残せる仕組みを構築しておく です。
アセスメントでは様々な観点でのQ＆Aが発生しますが、大別すると以下のようなカテゴリ分けになります。
- 以下について、それぞれ教えてください。
- 自社の事業規模や体制
- システムの概要
- システム開発のプロセスと、品質管理の仕組み
- システムの情報セキュリティ関連の、技術詳細
- 障害や災害が発生した際のプロセス
等々。
アセスメントにおいてとても大切になってくるのが
「それらはいつ、誰が考え、誰が作り、誰がレビューして、誰が承認したのか。そしてそれは承認後に変更が加わったか、いつ加わったか」
といった部分になります。
これはアプリケーションのソースコードは勿論のこと、何かしらの手順を定めた”手順書”にも当てはまりますし、品質管理等の手順そのものにも当てはまります。
アセスメントで問われやすいのは、それらが然るべき人によってレビューや承認が為されているか、そして承認されたものはロックされ容易には改変できないようになっているか、といった観点になってきます。
自社内で作成される全てのアウトプットに対して、
- いつ
- 誰が
- 作成者
- 更新者
- レビュワー
- 承認者
- 何をしたか
を記録できる仕組みを構築し、提示できる準備をしておかないと、いざアセスメント対応が発生した際に「記録が全然残っていませんでした」となってしまうのです。
大事なのは、その記録があるかないか、です。
本来記録を残さなければいけない事項が仮に10個あったとして、5個は重厚長大な記録が残っているが5個は全く残っていない、という状態よりも、重厚長大ではないが10個すべてに対して「いつ、誰が、何を」が最低限残っている、の状態がベターであると言えます。
「記録が全然残っていませんでした」ということは、アセスメントの結果システム導入が承認されたとしても条件付きであったり、最悪の場合はシステム導入自体が許可されないという事態が起きえることになってしまいます。
この辺りも、冒頭に述べたように納期という光り輝く目標の達成が危うくなる要因のひとつになりえますね。
[ポイント4] 全てを人間だけで回答しようとしない
最後のポイントは
任せられるものは機械に任せた方が早いし、正確である です。
最後だけ急に2025年っぽいポイントになりますが、要は生成AIを活用するのです。
アセスメントで問われる内容は前述の通り、だいたいの傾向（≒カテゴリー）は似たり寄ったりになってきます。異なってくるのは設問の聞き方や、日・英の言語や規制の違いくらいです。
例えば、以下のような問いは十中八九、どこのアセスメントでも問われる内容になります。
問い：ユーザーがシステムにログインする際、ユーザー名やパスワードを誤った場合にはロックアウト処理は発生するか？発生する場合には何回で発生するか、また、ロックアウトの長さはどれくらいか
仮にあなたが自社サービスのシステム導入担当者やエンジニアだったとして、自分達が提供しているシステムが何回でロックアウトするか、◯◯ミリ秒のロックアウトが発生するか、即答できますか？
これをいちいちシステムの要求仕様書や過去のやり取りを検索したり、この辺りの仕組みに詳しいであろうエンジニアに確認していたのでは日が暮れてしまいます。何なら納期がどんどん遅延していってしまいます。何故なら目の前の質問票には、これ以外にも300項目近い設問が私の回答を待っているのだから。
この回答スピードを上げるために「すでに整理されている情報を最大限に活用する」が重要になってきます。
- システムの要求・要件定義書
- 自社の組織図
- 主に営業が利用しているサービスの媒体説明書
- 過去に発生したアセスメントの回答一覧
- 社内Slackで過去に発生した仕様関連のやり取り
等々、量の差はあれど、大なり小なり様々な情報ソースが自社内に存在しているはずなので、それらを生成AIに学習してもらった上で、回答を即座に引き出せる仕組みを構築しておくのです。
もちろん間違いがあってはいけない領域なので、最後には人間の目で正誤を判定する必要はありますが、これだけで体感値としてはアセスメント対応の負担が30％くらいは低減されたのではと感じています。
振り返ってみるとこの4つめのポイントによって、呪詛をつぶやく回数は大きく減ってきたなと思います。
終わりに
数多くのアセスメントに対応することで、私のアセスメント筋力はだいぶ鍛え上げられてきたのでは、と感じています。
最初のうちはアセスメント対応に慣れず、いきなり英語で300項目の質問が送られてきてワヤになっていた頃と比べれば、様々なポイントを学習・改善することで脳も体も心もマッチョになってきた気がします。
とはいえまだまだ課題はあります。
- アセスメント対応ができる人間はまだまだ限られているため、どうやって属人化を脱却するか
- 年々変わってくる法規制やガイドライン/ガイダンスをどうキャッチアップしていくか
- とはいえアセスメント対応にまだ時間がかかってしまうのも事実であり、さらにリードタイムを短縮していける方策はないか
SaaS型のサービスを（特に医療分野で）提供している会社の中で、アセスメントに関わっている方はあまり多くはないかと思います。
そんなニッチで希少価値があるんだか無いんだか良くわからないが、日夜アセスメントに取り組んでいる同士たちに届くことを祈り、私の記事はここまでとさせていただければと。
Discussion