要件を書いても進まないのは、仕様以外のものが動いているから
セキュリティ要件は、条件の明確化であると同時に、責任と役割の再配置でもあります。
セキュリティ要件は、技術的には仕様として整理できます。何を禁止するか、どこを確認するか、どの条件を満たすか。そこまで書けていれば伝わるはずだと思いたくなります。
でも実務では、相手はそれを仕様だけでは読んでいません。作業がどれだけ増えるのか、誰が確認責任を持つのか、例外時に誰が判断するのか。そうした「仕事の変わり方」として受け取っています。だから要件が明確でも、合意形成としてはまだ始まっていないことがあります。
要件はちゃんと書いているのに、なぜ話が進まないのか
仕様のつもりで出したものが、相手には別のものとして見えている場面があります。
要件はちゃんと書いてるんだよ。何をやればいいかも明確にしてる。なのに、いざ出すと妙に反応が鈍いんだよな。
うん。でもそれ、相手は“仕様”として受け取ってるかな？
え？ 仕様じゃなかったら何なんだ。条件も対象も書いてるばい。
それ、相手にとっては“仕事の増え方”とか“責任の変わり方”に見えてるかも。
仕事の増え方？
たとえば確認作業が増えるとか、承認の持ち手が変わるとか、例外対応の判断を誰が持つかとかね。
あー……こっちは条件を明確にしたつもりでも、向こうは“何を引き受ける話か”として見てるのか。
そう。だからそれは仕様の話だけじゃなくて、責任分担と合意形成の話でもあるんだよ。
ここで噛み合わなくなると、要件が曖昧だからではなく、見ている対象が違うから話が止まります。出す側は条件を整えていて、受ける側は自分の業務の変化を見ています。
仕様に見えて、実際には責任の再配分が動いている
要件提示は、技術条件の提示であると同時に、誰が何を持つかの提案でもあります。
でもさ、要件って本来そういうもんだろ。必要な条件を定義して、それに合わせて動いてもらう。
うん、技術的にはそう。でも実務では、条件を満たすために誰が何を持つかが必ず発生するよね。
まあ、それはそうだな。
たとえば多要素認証を入れるなら、設定する人、利用者に説明する人、例外申請を受ける人、トラブル時に戻す判断をする人がいる。
ああ。仕様を一行足しただけでも、実際には役割が何個も増えるわけか。
そう。だから相手は仕様書を読んでるつもりじゃなくて、“この変更で自分の仕事がどう変わるか”を読んでるの。
それなら、要件が細かいほど重く見えることもあるな。
そうなの。精度を上げるほど、引き受ける責任範囲も広く見えやすいんだよね。
だから、セキュリティ要件を出すことは、仕様の提示であると同時に、仕事の再配分の提案でもあります。ここを見落とすと、「ちゃんと書いたのに伝わらない」が起きやすくなります。
必要なのは、条件の正確さだけではありません。誰が何を持つのか、どこまでが相手の責任なのか、こちらが何を引き取るのか。そこまで見えると、要件は“重い仕様”から“進められる合意”に変わっていきます。
要件を出すだけでなく、合意したい点まで先に示す
条件だけでなく、持ち手と合意点を一緒に置くと、話が前に進みやすくなります。
じゃあ、要件を出すときは何を足せばいいんだ。条件を書く以外に。
“何をお願いしたいか”と“何をこちらで持つか”かな。あと、“今回どこを合意したいか”も。
言い換えテンプレ
今回の要件は、〇〇のリスクを防ぐために追加したいものです。
対応範囲としては△△までをお願いしたく、対象整理と初期案はこちらで用意します。
現場側には、実運用に合っているかの確認と、例外が出そうな箇所の指摘をお願いしたいです。
今回の合意点は、「誰が確認するか」「例外時に誰が判断するか」「いつから運用に乗せるか」の三点です。
なるほどな。要件本文だけじゃなくて、合意したい論点まで見せるのか。
そう。相手が“何を読めばいいか”を揃えてあげる感じだね。
この形にすると、相手は単に仕様を読まされている感覚から抜けやすくなります。何を持てばよくて、どこに意見を出せばよくて、今回の論点がどこなのかが見えるからです。
要件を細かく書けば伝わる、とは限らない
技術的精度を上げるほど、相手には“責任範囲の拡張”として重く見えることがあります。
でも、雑に書くよりは細かく書いたほうが親切じゃなかね。
親切ではあるよ。でも、細かさだけ増えると、相手には“引き受ける範囲が広い”って見えることがある。
ああ、読むほど重くなるやつか。
そう。“伝わる”と“引き受けやすい”は別なんだよね。条件の精度と、合意のしやすさは同じじゃない。
文章量を増やし、条件を増やし、技術的精度を上げる。それ自体は悪くありません。ただし、それだけで相手が動きやすくなるとは限りません。むしろ、「責任範囲が広がる」「読んだ瞬間に重い」と感じさせることもあります。
要件を書くことと、合意をつくることは分けないほうがいい
仕様の精度だけでは届かないものがあります。
仕様を書いてるつもりだったけど、仕事の持ち方まで動かしてたのか。
うん。だから要件を書くことと、合意をつくることは、分けて考えないほうがいいんだよ。
なるほどなあ。条件を書く前に、誰の仕事がどう変わるかも見とかんといかんわけだ。
そうそう。そこまで見えると、要件が“読まれない仕様”じゃなくて、“進められる話”になるからね。