2024.12.03
セキュリティ製品を入れても検出されず…被害事例から見る最新の攻撃トレンド 不正侵入・悪用を回避するポイント
リンクをコピー
記事をブックマーク
石原一宏氏(以下、石原):畠山さんありがとうございます。
見えない仕様を可視化する、できないことを考慮する、図表を活用する。上流工程のひと手間で手戻りリスクは大きく減ることをお話ししていただきました。先ほどもありましたが、範囲が曖昧、条件が複雑、全体像がわからない、書いていることの箇条書きだけを見ても全体像がわからないんですよね。
一方で全体像がわかっても、細かいところが見えない逆パターンがあります。できることしか定義していない、チャットにもありました。Never・MustでNeverしか書いていないことが多いんですよね。「非機能を考慮していない」、そうですね。仕様書にはだいたい機能系の正常系、Mustしか書いていない。非機能のNeverなんて書いていないんですよね。
書いていなければテストをしなくてもいいのかというと、ぜんぜんそんなことはないよという話です。「非機能要件に関してもちょっと知りたい」とコメントされた方がいましたね。それについてちょっとお話をしておこうと思います。
対象の一例ですが、私たちは文字をできるだけ図表化していきます。範囲が曖昧であれば数直線を書いて境界値を明らかにしたり、先ほどのデシジョンテーブルにしたり。全体像がわからない・細部がわからない。書いているものが全体かというとそうではないので図にしてみるとけっこうわかるよという話がありました。
あとはMust・Neverの考え方。これは応用範囲が広いです。そのシステム丸ごとのMustとNeverはなにかと考えることもできるし、機能単位・画面単位・モジュール単位のどんな小さなものでも正常系のMustと、異常系のNeverはなんだろうとセットで考える癖を付けておくとすごくいいですね。仕様書に書いてあろうがなかろうが、正常系のMustに対して異常系や準正常系のできないことが正しいというNeverをテストしなければいけないという発想(は必要です)。
テスト担当者は、仕様書がなくてもテストをしなければいけないと骨身に染みているので、仕様書があろうがなかろうがこういうふうに読んでいくという考え方がすごく大事です。ほかにも非機能系に関してコメントをすると、「非機能要件も見ておいてね」とお客さまや上司から言われることが多いのですが、「非機能ってなんだ?」という話ですね。意外と範囲は広いぞという話です。
仕様書を読み込む中で、ここは抜けがちなんじゃないかな、やばいんじゃないかな、テストをしておいたほうがいいよなというところを見ていくわけです。こういうのを毎回全部埋めなくてもいいのですが、デシジョンテーブルを使ってみたり、MustだけではなくてNeverはなにかを書いてみたりをテンプレート化するだけでも随分違ってきます。
あとは非機能の話でしたね。これは有名なISO25010、通称SQuaREです。ISOが決めた、ソフトウェアの品質が良いとはどういうことか。機能性の他にも、使用性とか信頼性とかセキュリティとかありますが、この中で非機能はどれかというと、8個ある中の7つが非機能です。つまり機能以外は全部非機能なんですね。「これを全部仕様書に書いていますか?」というと、まだらにしか書いていないですよねという話です。
「Never・Mustとかは大事ですか?」「そういう考え方を持っていない人はどう考えればいいんでしょうか?」という質問もけっこういただいていますね。これは本当に九九みたいなものなんですよね。九九ってみなさんも使っていますよね? 九九を使わずに日常生活や仕事をするのはなかなか難しいと思います。
それと同じでテストをする時も品質で考えないといけません。こういうカテゴリがあるよね、それからNever・Mustという考え方があるよね。一例ですが、ECサイトで考えるのであれば横軸にNeverとMustを考える。縦軸に機能性、信頼性、使用性などのカテゴリーを考える。それで機能性のNever・Mustとはなんだろうという話。
上流の要件定義が増えたら、さらに付加価値があるなと横軸にWantも出したりするんですけどね。だいたい仕様書にはここぐらいしか書かれていないですよね。機能性のMustしか書かれていないですよねという話です。でもテストでは使用性のNever・Mustも考えなければいけません。スマホ、タブレットで各種ブラウザーからアクセスできるかとか、レスポンスタイムで時間がかかったら頭にきますよねというところがあるので、使用性は書いていないけれどやらないといけません。
信頼性でのNever・Mustももちろんあります。例えば想定の10倍以上のアクセスがあったとしてもシステムダウンしないために負荷テストをしなければいけないし、24時間365日使えなければいけないからシステムダウンはしちゃダメだよねという話。仕様は意外とここしか書かれていないんですよね。そういうかたちで俯瞰して見ることが大事です。
ただ3×8の24マスのうち、仕様に書かれているのは1マスだけだったということはけっこうあるんですよ。これはけっこう大変で、全部埋める必要はありません。でも、例えば使用性で考えないといけないことは確かにあるよなとか、そう考えていくと書かれていようがいまいが考えなければいけないところはけっこうあるよねという発想を持つことが大事なんです。
(コメントを見て)「縦軸はこんなに重要なんですか?」。こんなには必要ないです。みなさんの開発であったところでかまいません。ただ、使用性やセキュリティはあったほうがいいし、細かいですがバージョンアップをたくさんするのであれば、保守性と仕様書に書いていなくても書いておいたほうがいいです。
サーバーの増数が考慮されているか、ホテルのデータベースのカテゴリ追加を想定しているか。これは想定しているかしていないかで、メンテナンスやデグレードが天と地ほど変わってくるじゃないですか。こういうマトリクス的な発想があると、「仕様書に書いているところはここだよね。書いていないけれど、こういうところは注意しないといけないよね」ということがメンバー間やプログラマー間で話ができるんですよね。
「ごめん、今回は本当に時間がなくて使用性や信頼性がぜんぜん書いていないんだけど、これは実装段階で考えてくれないかな」と一言PMがプログラマーに言うだけでけっこう違ってくる。書かれているところしか見ないというのは人間の性なので、「書かれていないけどこのあたりもあるからね」とリマインドを始めるところからちょっとやってみる。
「こんなにたくさんの大きな表なんか作れない!」というのであれば、まずはNever・Mustを横軸、縦軸は機能とそれ以外でかまいません。これだったら2×2のマトリクスで済むでしょう。でもやはり書いてある1に対して4の領域を見なければいけないところがあるので、そういうところをちょっと考えてもらうだけでも随分違うのかなと思います。
(コメントを見て)「このドキュメントほしい」(笑)。これはあげられないかな。ちょっと覚えて帰ってください。Never・Mustが横軸、縦軸に機能性・使用性。意外と考えない領域が広いよねというところは、こういうところから話をしています。
先ほどお話ししましたよね。このイメージですね。本当に書かれているのはこの黄色のごく一部で、書かれていなくてもやらなければいけないことはこれだけ広いです。これはけっこう質問もいただいたのでお話をした次第です。
というわけで、いったん私のパートはこれぐらいにしてQAコーナーに持っていけたらなと思っています。
司会者:石原さん、畠山さんありがとうございました。
「仕様を100にするべきだ」ではなく、本当に少しのひと手間で後工程が抑える具体的な事例を紹介いただきました。ありがとうございました。鬼気迫る質問がたくさん来ておりますので。
(一同笑)
司会者:さっそくですがQAに移っていきたいと思っています。ではここからのファシリテーターは、グループ開発事業推進部の篠原さんにお願いできればと思います。
篠原新治氏(以下、篠原):では私、篠原が進行したいと思います。始まる前はQAが来なかったらどうしようとドキドキしていたのですが(笑)。勉強会中にたくさん質問をいただきましてありがとうございます。
「仕様の充実化に向けて特別な訓練が必要でしょうか?」という質問が来ています。「仕様を書く人が仕様を正しく理解していなかったり、ドキュメント化することが苦手だったりします」というところについて、まず石原さんお願いできますでしょうか。
石原:「テストのコツ、レビューのコツはなんですか?」と聞かれるのですが、地道ですがやはりMustはなんなのか、それに対してNeverはなんなのかをまず考えるのが一番の基礎の基礎だと思います。それらをワンセットで考えることがすごく大事だと思います。
例えば、みなさんがふだんから使っているシャープペンシルでも、あるいはテレビのリモコンでもいいんです。Mustがなんだろう、そしてNeverがなんだろうと目の前のものでやってみるトレーニングをやるだけでもぜんぜん違ってくると思います。いきなり難しい対象ではなくて簡単なものからやってみる。
仕事以外のものだとリアリティが湧かないというのであれば、画面単位やボックス単位、メッセージボックスの単位の中でなにがMustでなにがNeverなんだろうかと小振りにすることですね。本当に3分ぐらいで考えられるところがあります。考えてみてこれでいいかなと2人以上で見せ合ったりすると意外と一致していないところが多いんですよ。
先輩と後輩でやると、自分の視点がすごく偏っているのがけっこうわかってくると思います。それを地道に繰り返すことが、1つのポイントですね。3分自分で考えてみて、他の人と見比べ合うのはお互いにとって相乗効果がすごく高いです。うまい人のテクニックなりを盗むのであればまずは自分で考えてみる。それから共有するということをやるだけでも随分違うかなと思っています。
それをやると意外と「それいただき! 盗んじゃおう」と考えられたりするので、そういうふうにちょっと楽しみながらできるといいかなと思っています。畠山さんはどうでしょう?
畠山塁氏(以下、畠山):そうですね。やはり身近な事例でやるのはけっこういいかなと思っています。私たちも電子レンジで考えたりしますね。電子レンジのMustとNeverを考えてみる。Mustは分数を設定して、ワット数を指定して、スタートすると温め開始とか、時間が経つと止まってお知らせするとかです。
Neverのところで、途中でドアを開けたらどうなるかというところで人によってズレが出てきて、そこがまたおもしろいんですけど。見せ合ったりすると観点が違うので、いろいろ身近なところでMustとNeverの観点を考える。親しみやすい事例から入って、そういう思考の癖を付けていくのはけっこう有効かなと思います。
石原:今の畠山さんの話で思い出したのですが、新人さんはなかなかNeverを出せなかったりするじゃないですか。初めて金融の業務に携わった人にNeverを出せと言ってもなかなか難しいですよね。
畠山:そうですね。
石原:仕様を理解してもらうことももちろん重要ですが、「こんな不具合が過去にあったんだよ」と不具合を共有することを私もよくやっています。あとから入った人にも「こんな不具合があるんですね」と思ってもらう。それが仕様の理解につながることもけっこうあるので、そういうことはけっこうやっていますがいかがでしょうか?
畠山:そうですね。過去の事例も非常に参考になりますし、新人でも人によってけっこう観点が違うので「バグを見つけてやる!」という新人もたまにいるんですよね(笑)。細かいところを突っつくことで他の人の参考になったり、全体の底上げになったりするところはあるかなと思います。
石原:そうですね。新人さんの、ベテランには持っていない発想はすごく大事ですし、ベテランや業務経験者だけが持っているありがちなあるある不具合は良い刺激になるので、こういうのを共有し合うのはすごく文化としても良いと思います。「昔こんな不具合があってひどい目にあったんだよ」という話を共有していく、過去事例から導いてみるというのはチームメンバーにとってもけっこう良いと思います。
「ヤバそうなところはどこ?」という話ですね。私はけっこうキャンプが好きなんですが、危険地帯を知っておくのは大事です。ここは滑落しやすいとか、雨が降ったらここは滑りやすいとか。そういうところを共有しておくことがNeverを未然に防ぐことにけっこうつながったりすると思っています。
篠原:ありがとうございます。コメントやチャットにも「やっていこう!」といただいているので大変うれしいですね。
(次回へつづく)
関連タグ:
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える秘訣 「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2024.12.02
給料や人間関係が良いだけでは部下は満足しない メンバーの「働きがい」を育む5つのステップ
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.29
やたらと多い自慢話、批判や噂好き…「自己重要感」が低い社員の特徴 管理職が知っておきたい「一生働きたい職場」の作り方
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.12.02
大企業での肩書を捨て、起業家になる決心をした背景 キャリアの中での「最後の1勝」を取るために立ち上げた事業とは
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵