2016年07月31日

仕様とはルール


初めての方はこちらを「はじめに

今回は仕様を検討する際の根本的な考え方について述べます。

思い付きは仕様なのか


思い付きで決めたようなものは自分的には仕様とは呼んでいません。そういうものはまさしく「思い付き」と呼んでいます。では思い付きでは無い仕様というものは何なのかと言えば、一言で言えば
理由がある事
です。
つまりただ感覚的に「こんな感じかな」と思い付きで決めたものでは無く、論理的に「○○で△△だからこう」という明確な理由が存在するという事です。仕様を決める作業は結局多数存在する候補の中から一つを選ぶ作業だと言えます。その時に何故それを選んだのかが「なんとなく」ではとても仕様とは呼べないという事です。仕様の内容の話ではありません。例えばUIに関する仕様には感覚的な要素が必要です。幾ら理屈を並べても「使いづらい」ものは使いづらいですから。そこでは無くて仕様を決定するプロセスの話しという事です。
プロセスなので内容としては「適当」な仕様を決定する時もあります。今回その仕様はどの様なものに決まったとしても将来も含め何の問題も発生しないと判断出来た様な時です。その様な場合に検討に時間を割く事は無駄です。考える必要はありません。数学で言う不定のような感じです。方程式を解かない、解けないのではなく解いた結果どの様な値でも良いという答えだという事です。

仕様とはルール


思い付きを排除するとようやく仕様の中身、質について論じられます。仕様とは何かと問われれば以下のように考えています。
仕様とはルール
ルールと言うのは仕様が何かしらの規則に従っているという意味です。
例えば以前画面系の仕様のレビューに審査する立場で参加した時の話ですが、あるダイアログでふと気になってリサイズが出来るかどうかを質問しました。
すると担当者は「ここは操作が○○なのでリサイズさせます」と答えました。
次に別のダイアログの時にやはり同様にリサイズするか尋ねました。
すると今度は「これは特に必要ないと考えています」という答えが返って来ました。
どうも良く分からないのでどういう基準でリサイズする、しないを決めているのかを質問しました。
すると「基本的にはリサイズしたくなるところ」という答えが返ってきました。
操作に関するものなので感覚的なものは重要です。しかしそれは出来上がった仕様の妥当性を検証する時に用いるべきもので、仕様を決める際に一つ一つのダイアログに対してリサイズするべきかどうかを決めて行くという事をするべきではありません。
この場合の期待値としては、例えば「テキストボックス(文字入力)があればリサイズする」とか「部品にスクロールバーがあればリサイズする」とかなんでもいいのでルールを答えて欲しかったのです。一つ一つのダイアログ毎に決めるのではなくてルールを定めて全てのダイアログがそのルールに従った結果の仕様として欲しかったのです。そうして全てのダイアログの仕様が決まった後に使い易さを検証すれは良いのです。その結果「やっぱりここでもリサイズしないと使い難いな」と思ったらルールを追加したり修正したりすれば良いのです。

何故ルールなのか


では何故ルールとして考えるべきなのでしょうか。
以下に主な理由を三点挙げて説明します。

一貫性

一番顕著な事は一貫性を確保し易いという事です。
一貫性というのはここでは大まかに言えば同じ仕様で統一されている事を指します。
例えばブラウザの最小化ボタンや最大化ボタン、閉じるボタン等は右か左の端にあると思いますがこれがどのウインドウでも同じ位置にあるという事が一貫性があるという意味で、ウインドウを開く度にボタンの位置が反対側になったりしないという事です。あまりに当たり前の事で気にかけた事は無い人が多いかもしれませんがこれはウインドウマネージャーという所に仕様としてルールが存在していて全てのブログラムがそのルールに従った結果自身のウインドウの仕様として統一的なものになるという仕組みになります。こういうUIの様に目に見える形の仕様は分かり易いので誰でも統一感が無いと気が付くものですが、データ処理の様に目に見えないものの仕様になると難しくなったりします。また画面の様な物でもバージョンアップ時に後から新たに付け加えたものになるとそこだけ食い違いが発生したりもします。

実際にあった話しでより具体的に説明をしたいと思います。
以前あるシステムを開発するプロジェクトに途中から参加したのですが、後から加わったのでそのシステムの全体の仕様を勉強する事にしました。その時にシステムのメニュー名が以下の様な感じになっていて非常に気になりました。
○○出力
△△の印刷
□□一覧表
  :
「出力」と言ったり「印刷」と言ったり、そもそも動詞が無くてただ「一覧」だったり...
とにかくバラバラなのです。多分それぞれの機能を検討する段階で一つずつ名前を付けて行った結果だと思うのですが、驚いた事に全体像が出来上がった時点においても誰一人として気にしている様子が無くそのまま製品として出荷されそうだったのです。自分の担当とは全くかけ離れた場所だったのですが直接エンドユーザーの目に触れる所でありシステムの顔とも言えるような部分なだけに流石に見過ごす訳にもいかず勝手に整理に乗り出しました。
まず以下の様な感じでルールを定め
文字数:○○文字以内
文字種:全角
構文:目的語+述語(「の」は入れない)
基本的な述語
 表示
 印刷
 更新
  :
何百とあるメニュー名を全て洗い出して、現状のものと新しくルールに則ったものと両方を一覧にして関係者を集めて会議を開き問題提起をしました。その結果ルールの内容についての意見は色々出ましたが「ルールに従う」という考え方自身は合意に至って、メニュー名を修正する事になりました。
この様にルールに則って仕様を決めるという事は一貫性の確保にも繋がります。

効率性

上のメニュー名の例の様に複数の仕様の間の整合性は特に何も考えなければ保たれないでパラバラになるのが普通です。従ってその間で整合性をとって一貫性を確保する為には手間暇がかかる事になります。それを個々の仕様を突き合わせて検討するとなると、時間がかかるのもさることながら着地点を探す事はまるでパズルでも解いているかの様でなかなかな大変な作業です。特に仕様の数が増えてくれば膨大に時間がかかるか部分的に整合性は諦めるかのどちらかになります。それがルールを決めるという作業ならば一つだけで済みます。仕様の数には関係が無くなって非常に効率が良い事になります。

拡張性

目に見える事柄ではないので分かり難いですが実は最も効果の大きい事柄だと考えています。ルールを考えるという事は個々の具体的なものを考えるのではなく、一段抽象的なものを考える事です。一段抽象的になる事で汎用性が確保されて将来機能を拡張して新たな仕様が加わる場合でも新たに検討する必要が無い可能性が大きくなります。上のメニュー名の例で、もし数が少なくて十個や二十個くらいならば全部並べてバランス良く整合性の取れた仕様を考えられるかもしれません。しかしその時に本当に重要な事は「将来メニューが追加になる」かどうかなのです。もし企画上のコンセプトとしてメニューの構成は変わり得ないという事ならばその様に並べて決めても良いかもしれません。しかし後のバージョンアップでメニューが追加される可能性がないとは言い切れないならばルールとして検討するべきなのです。ルールとして検討していない場合はバージョンアップで追加しようとするメニュー名と最初に決めたメニュー名との間で整合性が取れずに一貫性が崩れる可能性があるのです。目の前の十個、二十個を相手に決めた仕様なのでそうなる可能性は大きいのです。これがルールを決めておげは今後のメニューの追加に対しても整合性を悩むどころか基本的には考える必要すら無いのです。

取り組み方


もし利点だけだとしたら世の中みなこの様なやり方をしているはずですが残念ながらそうではありません。つまり欠点もあるという事です。それは検討が難しいという事です。
先程の通り将来の仕様を検討する必要が無いという事はそれだけ多くの仕様を事前に考慮に入れて検討しているという事でもあります。多くの具体的な仕様からエッセンスとして抽象化したルールを導き出しているのです。
概念的な例で説明すると、例えば要求として図形の円があったとします。
計ってみたところ半径が1でした。
そこで仕様としては半径1の円として「X2+Y2=1」を考えました。
これが直接的に仕様を決めるというプロセスです。
この時に
「半径は1だけれどもこの先変わる可能性もあるな」
と思い至って、
「という事は仕様はX2+Y2=R2で、パラメーターとしてR=1を設定するべきだ」
という一段抽象化したところまで発想できて初めて次に半径2の円の要望が来ても何の労力も要らなくなるのです。
53N016_001.jpg
抽象的な思考というのは必要な事ですが一般に難しい事です。

要求工学という観点からは(要求)仕様についての一貫性の検証が求められます。それはコードのバグと同様に一貫性の欠如は仕様のバグとでも言えるようなものだからです。しかしそれはあくまで「テスト(検証)で品質を確保するべき」と言うだけであって「ルールによって定義すべき」という踏み込んだものではありません。実際周りを見渡してもそういう検討の仕方をしている人間は居なかったですし、世の中の製品を見てもそういう考え方で全ての仕様を検討したと思えるものはあまり見当たりません。確かに一般論として「ルールによって定義すべき」とするのは難しい事だと思われます。しかし個別に仕様を決める事に比べてルールの場合は蓄積する事ができます。例えばある開発時に決めたリサイズのルールは次に別の製品の開発時に使えるのです。新しく適用する時にもしもルールが不足しているならばルールをバージョンアップすればいいのです。そうして資産として蓄積して行く事が可能なのです。資産として蓄積する事で「開発能力の構造」で示した様な組織の開発能力の底上げに繋げられるのです。なので少しずつでもルールで定義をする努力をして行くべきではないかと思います。

一覧


メニュー


記事を広める



posted by 善 at 16:29 | Comment(0) | TrackBack(0) | 仕様 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック