仕様という言葉について安易に使うべきではない理由とは？
こんにちは。
SHIFTのCATエヴァンジェリスト・石井優でございます。
(情報)統合型ソフトウェアテスト管理ツール「CAT」について 現在SHIFTが提供するCATとは、テストの実行管理に主眼を置いた正式名称「CAT TCM（Test Cycle Management）」という製品を指します。ケースと実行結果・エビデンスの管理、及びプロジェクトの進捗管理や品質分析を担うツールです。詳しいご紹介はぜひ製品HP をご確認ください。
今回はCATではなくて、サポートのときの言葉についてお話しします。
サポートメンバーや開発メンバーでのサポート業務において、プログラムの挙動の調査をすることは多々あると思います。
ユーザーから次のような問い合わせを発端にして内部を調査して回答します。
こういう挙動になっているけどどういった意図なのか？
不具合のように見えるが調べてほしい
その際、開発者やサポートメンバーが安易に使うとやけどをする言葉に「仕様」という言葉があります。
"これはプログラムの仕様です。"
この言葉をもしあなたが口にしようとした時はちょっと待ってください。
なぜならこの言葉はシステムに関わる人はけっこう言いがちなのですが、この「仕様」という言葉を正しく使えていないがために大いなる誤解を受けているケースがすごく多いと感じるからです。
またSNSを見ていると、たまにシステム界隈（サポートやエンジニア、ユーザー）でこんなやりとりを見ます。
よくみる投稿の例
- ユーザー： この動きってどうなっているの？
- 開発者： （調べた上で）これは仕様です
- ユーザー： え、そうなの？
- 開発者： はい、仕様です。
開発者は、明らかに悪い挙動なのに仕様です！としか言わない、融通が効かないな...！システム開発に関わるメンバーであれば多かれ少なかれこういったやりとりには遭遇したことはあるのではないでしょうか。
私はこういったやりとりの根本に、この仕様という言葉の使い方の誤りによるものが少なからずあるのではないかと考えています。
ではこの話を紐解いていきましょう。
仕様って何を指すの？
さて、仕様って言葉はどういった意味なのでしょうか。
辞書で調べてみましょう。手元の古ーい電子辞書から調べてみました。
広辞苑 第五版
しよう【仕様】
仕方。方法「返事の一に困る」
ちょっと違いますね。広辞苑第五版は1998年の出版と古くシステム開発における文脈の言葉が盛り込まれていないようです。
インターネット上に公開されているシステム開発系の用語解説を複数見るとどうやら次のような意味のようです。
"システムやアプリケーションの開発において要求を満たすべき機能や性能の要件"
そうですね、要求を満たすというあたりがキモかと思います。
反面要求を満たさない場合仕様ではないんですね。
また、私による業務上の解釈はこうです。
"何か明確な意図があった上で実装されているシステム上の挙動"
これはなにかの挙動に対して明確に意図があるものを指します。
例えば、
とあるボタンにホバーした際にはボタンの色が少し濃くなる
色を変えないとそこが押せるということがユーザーに伝わらないから
ホバーした際の色は緑色にする（ソフトウェアの基調から）
これは仕様です。
仕様なのかどうかを判断する場合一点考えやすい方法としては、あなたがその機能を作るとしてその挙動を仕様書に書くことが妥当なのか？を考えることです。
意図を持っているならば仕様書に書けるはずです。それが必ずそうであらねばならないことを記録して実装時に考慮する必要があるからです。
(システム開発の現場においては仕様書に書かない暗黙の仕様というのもあります。その際でも、仮にそこの機能についての仕様書があったとして書けるか？を考えることと捉えてください。)
システムには仕様ではない挙動というのもいっぱいある
しかしシステムには、ただ単にあまり意図や考慮をせず実装されてしまっている挙動というのがあります。
これは仕様書にも書かないですし、エンジニアの勘違いや考慮漏れで起きたものもあります。
例えば、とある画面のローディングに4秒ぐらいかかるとします。
一般的なアプリケーションであればユーザーはちょっと重い、めんどくさいなと思うぐらいの速さですね。
このとき、ローディングの挙動に対して4秒で行うこと、という意図を持っていることはそうそうありません。 （読み込みの時間の基準を設けていて大規模データであっても4秒以内に完結する、というコーディングポリシーがない限り）
先の仕様という言葉の定義からも、ユーザーの要求を満たさないのであれば仕様ではありませんね。
よく、この意図されていない挙動を「仕様です」と返していることを見かけることがあります。
これは先ほどの定義からすると大きな間違いです。
単に考慮漏れで作られてしまった挙動は、意図していないのですから仕様という定義とは外れます。
これを聞くと質問をしたユーザーに対して次のような誤解を与えることになります。
「こんなユーザーに不利益を与えるような挙動になっているのに、それがプロダクト提供者の意図したことなんですか！？ 本当に言ってますか？」
これが仕様です！という言葉を使った時によく起こる摩擦の真相だと考えています。
どうやって表現するべきか？
ではこのような意図していない挙動をどう伝えれば良いのでしょうか。
私は仕様という言葉を使わずに、想定される経緯などをある程度素直に伝えれば良いかと考えています。
先ほどの4秒かかるという事象ではこのように書きます。
(挙動に関する回答の例)
本画面ではデータ量に伴い表示時間に時間がかかる作りとなっています。実装した時点では本画面においては表示時間の保証を行っておりませんでした。そのため4秒程度の時間がかかる挙動となっています。
実装した当時の状況や経緯を伝えた上、こういう「挙動」になっていると伝えます。
その上で改修などが必要であればその手続きやリードタイムを記載します。もし改修が難しく回避策で対応してほしい場合はその旨を書きます。
たまに経緯がわからないこともあると思います。それであればそのことや推測されることを説明すれば良いと考えています。
(挙動の経緯がわからない例)
本挙動について調査をしましたが実装された当時の状況などが把握できておりません。またプログラムの確認などを行いましたが明確な意図がある挙動ではないと考えています。
（この上で回避策や改修案を提示します。）
この説明をせずに、仕様です！と誤った言葉で伝えるとユーザーとサービス提供者の間に大きな亀裂が生まれると私は考えています。
仕様という言葉を、単なるシステムの挙動を説明するのに使っていませんか？
上記のように仕様という言葉はすごく難しいものだと私は考えています。
またシステムの振る舞い、挙動を説明するために仕様という言葉を使う頻度というのは相当少ないと考えています。
ですから仕様という言葉を使うことがあれば、それは本当に意図された挙動を説明するのか？を立ち止まって考えるのが必要です。
余談ですがGoogle検索で「仕様です」 を調べてみると、概ねネガティブな言葉として捉えられているようです。やはり注意が必要な言葉のようですね。
ぜひシステムを取り扱う上でのコミュニケーションの時に考えてみてください。
ではでは！
参考資料 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典「仕様（しよう）」 URL: https://wa3.i-3-i.info/word1942.html
株式会社モンスターラボ「仕様書とは？成功する書き方・ポイントを徹底解説」 URL: https://monstar-lab.com/dx/solution/howto-specification/
e-words（イーワーズ）「仕様書」 URL: https://e-words.jp/w/%E4%BB%95%E6%A7%98%E6%9B%B8.html
CATエヴァンジェリスト、石井優の小話でした。
(宣伝)私の担当するテスト管理ツールのCATもよろしくおねがいします！
公式HP
執筆者プロフィール：石井 優
倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入及び大規模基幹システム移行への参画を経験し、2015年SHIFTへ入社。 CATエヴァンジェリストとして、ツールだけでなくプロジェクト管理プロセスに関する紹介や提案など幅広く活動中。CATやTDのことに興味があればいつでもご連絡ください！
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO:UnsplashのYoko Saito