【注意】システム開発要件定義書に書いてはいけない危険な表現99選

今回の投稿では要件定義書に書いてはいけない危険な表現について説明します。

要件定義を制する者はシステム開発を制すなどと言っている私ですので、「要件定義はもうお腹いっぱい」と言われたとしても、まだまだ続けます。

• これから要件定義を行う
• 要件定義を行っている
• 要件定義書が納品された

そんな方は、ぜひ最後までご覧ください！
そして、本投稿にある様々な危険な表現が、要件定義書に書かれていたなら！開発の前に、見直してください。

しかし、実はこのように書かれていたから即NGというわけでもありません。その理由も解説していますので、最後まで是非ご覧ください。

とてもたくさんの危険な表現例を並べています。後から見返して頂けるよう、ファイルにまとめたものをダウンロードできるようにしてありますので、そちらも併せてご覧ください。
>>要件定義書に書いてはいけない！危険な表現99<<

では、要件定義書に書いてはいけない危険な表現をご紹介していきます。

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。

UI/UXに関する危険な表現

まずは、UI/UXに関する危険な表現について解説します。

ユーザーフレンドリーなインターフェースを提供する

もっともらしいですが、ユーザーフレンドリーとはなんでしょう？システムのユーザーフレンドリーとは？分かりそうで分かりません。発注者の求めている要件はなんなのでしょうか？

最近は見かけない気もしますが、WEBサイトを開いたら朝の時間帯は「○○さん、おはようございます。」、昼の時間帯は「○○さん、こんにちは。」というメッセージが表示されるという仕様です。

システムが挨拶してくれるというのは、果たしてユーザーフレンドリーなのか？謎の要件です。これがもし以下のようになっていれば、要件は明確になっています。

ただし、挨拶メッセージがユーザーフレンドリーであるかという良し悪しは、今回別の話として受け取ってください。

ユーザーが満足する使い勝手であること

もちろん、ユーザーが満足できない使い勝手にしようと思うエンジニアもいないでしょうが、エンジニアが頑張って考えて、これなら満足できるだろう！と設計・開発しても、「これじゃあ満足できない」とユーザーに返されたら一環の終わり。

「どうしたら満足してもらえますか？」と聞けばいいのでしょうか？いやいや、違います。10人で居酒屋で宴会コースを飲み食いしたら、満足する人もいれば、量が足りないとか、味が濃すぎるとか、満足できない人もいるように、満足は人によって違うもの。ITベンダーが満足するシステムはユーザーにとって満足とは言えません。具体的な機能、仕様を定義しなければなりません。

ユーザーが直感的に理解できるUI

直感的に理解ですから、悩まずに理解できる画面になっているということでしょう。
しかしこれもまた、完成後に「あなたは理解できるのだろうけど、私は理解できない。もっと素人でも理解しやすくしてくれ！」というクレームを秘めていそうな要件です。

利用者が限られている場合、例えばエンジニアだけが使うツールのようなものであっても、スキルレベルの違いもありますし、システムを利用する全ての人が理解できるユーザーインターフェースなど極めて困難な話です。

ならば、どのように定義するのか？最初から、万人が満足できることを諦めます。そのうえで、曖昧さを無くすには次のような表現にします。

万人が満足できることはありえないと理解したうえで、では一体どれくらいの割合の人が満足するなら良しとするのかを数値で表現すればいいのです。そうすれば、自分は直感的に操作できる、いやいや自分はできない、の議論はなくなります。

一貫したユーザーエクスペリエンスを提供する

そもそもユーザーエクスペリエンスって何？ということもあります。UXと書かれることもありますが、これは、製品やサービスなどを利用して得られる「ユーザー体験」のことです。

いかにもベンダーが提示する提案書に書いていそうな言葉で、何となく響きがいいので、うんうんと納得しそうですね。「これをそのまま要件にしてしまおう」と思ってしまいがちですが、当然NGです。

これを定義し直すとこのような感じになります。

帳表は見やすいデザインにする

エンドユーザーは、「いま使っている帳票は見ずらいので、今度は見やすくしてほしい」というような表現をしがちです。これも主観的な表現です。もしかすると、その担当者だけが見ずらいのであり、他の担当者は何の違和感もなく使えているかもしれません。

いきなり具体的にすることも難しいでしょうから、まずはサンプルを作成し、このフォント、これ以上のフォントサイズ、要件として定義する際には具体的にMSゴシックで12ポイントなどと指定します。

帳表なら他にも以下のようなことが考えられます。

最初に紹介した5つはUI/UX、つまりユーザーインターフェース/ユーザーエクスペリエンスに関することでしたが、これらを含めUI/UXの曖昧であり危険な表現は、以下のようなものがあります。

保守・運用周りに関する危険な表現

次に、保守・運用周りに関する危険な表現について解説します。

システムは柔軟に変更できること

「柔軟に」も、よく使う表現の一つです。体が柔軟だと怪我も少なくスポーツができるので、システムも柔軟にしておけば怪我無く運用できるような感じですが、残念ながらそれは難しいです。

余談ですが、発注者側がITベンダーを選定する際「御社は柔軟に対応して頂けますか？」のような質問をすることがあります。この裏に隠れているのは「多少の仕様変更は無償で対応してくれるよね」ということであることは経験上知っています。ITベンダーが仕事が欲しい時は、ついつい頷いてしまいそうな言葉なのですが、お互いが後から痛い目をみることが多いやり取りです。

データは定期的にバックアップを行う

分かりやすいですね。定期的とは、毎日？毎週？まさか毎年ではないでしょう。これは設計で補うことも少なくないかもしれません。また他の要件とも関係することなので、この表現のみを定義し直すものではありませんが、定義する場合は、定期の単位は具体的にする必要があります。

最低限の人数で運用できる

運用に多くの人員を割きたくないという思いが現れています。しかし、最低限というのは1人なのか10人なのか。システムの規模、利用者にも依存するところですから、「最低限」の表現では発注者とITベンダーの互いの認識に齟齬がでます。

保守・運用周りの曖昧で危険な表現は他にも以下のようなものがあります。

データマネジメント・パフォーマンス・セキュリティに関する危険な表現

続いて、データマネジメント・パフォーマンス・セキュリティに関する危険な表現について解説します。

必要な情報を即座に取得できること

これは不明な単語が2つも並んでいますね。1つは「必要な」です。
必要な情報？誰がどんな情報を必要とするかは分かりませんし、データ分析をしたいとなると、必要な情報は変化することもあるでしょう。

2つ目は「即座」です。即座とは、1分以内？あるいは1時間以内なのか？「即座と言えば、直ぐに決まってるだろう！」と言う人は流行りのカスハラです。分からない情報をどれだけ短い時間で提供すればいいのか？と分からないだらけな表現になっています。

システムは高速に動作すること

高速道路での最高速度は時速100㎞ですが、新幹線は時速300km、旅客機は900kmというよに、基準が違えば高速の速度も違います。

「平均応答時間は、3秒以内である」とか、「登録系機能は登録ボタンを押してから完了メッセージまでは、2秒以内」という様に数値化しましょう。

セキュリティが強化されていること

ないとは思いますが、ウイルス対策ソフトすらインストールされていない企業が、ウイルス対策ソフトをインストールしたとしても、以前に比べれば強化です。一方で、一見完璧な対策が施されている企業では、何をもって強化なのか。強化前の基準の違いによって、一概には言えません。

実際、セキュリティには色々な視点がありますから、例えば次のように定義します。

データマネジメント・パフォーマンス・セキュリティ関連の曖昧で危険な表現は他に以下のようなものがあります。

その他、拡張性・可用性・信頼性などにおいてもこれらは曖昧で危険な表現です。

どうすれば適切な表現になるのか？

いくつか事例を挙げて、危険な表現をどのように修正すべきかを解説しました。既にお気づきかと思いますが、基本は定量化することです。

2秒以内と言えば、誰が見ても別の解釈はできません。一見、定量化が難しいような「満足」という表現であっても、「アンケートを取って80％以上が満足」というように定量化することができます。

今回ご紹介した99の表現についてすべてを解説するには至りませんでしたが、基本的な考え方はどれも同じです。

しかし、ここで一つ補足をしておきます。先の表現で書かれていたなら即NGという訳でもありません。NGではないケースは、発注者、ITベンダーの両者が合意のうえで決定を先送りしている場合です。例えば、「不正アクセスを防止する」の場合、「不正アクセスを防止する。詳細な要件は設計フェーズで決定するものとする」というような場合です。

だからと言って、何でもかんでも設計フェーズに先送りすると、予算オーバーや納期遅延に結びつきますので、ご注意ください。

まとめ

いかがでしたでしょうか。今回は要件定義で使ってはいけない危険な表現について解説をいたしました。

今回の解説で、嘘は申していませんが、解説した内容全てを適切にすべく実践してしまうと、また別の問題も起こるというジレンマがあります。その理由については、次回の投稿で解説しますのでぜひご覧ください。

なお、要件定義書に書いてはいけない危険な表現99はファイルにまとめてありますので、ぜひこちらからダウンロードしてみてください。
>>要件定義書に書いてはいけない！危険な表現99<<

資料は幾つかのアンケートにお答え頂くだけでダウンロードできるようになっていますが、営業目的ではありませんので、本人や会社を特定できる質問はありません。この投稿を続けるためのモチベーションと共に、参考情報として利用するものですので、ぜひご協力頂ければと思います。

資料をダウンロードして頂いて、自社で作成しようとしているシステムの要件定義書と見比べて、こんな表現が潜んでいないかどうか確認し、適切な表現に変更することをお勧めいたします。