- PR -

仕様書の主観は？

1|2 次のページへ»
投票結果総投票数：29
システム主観 15票 51.72%
ユーザ主観 6票 20.69%
使い分ける 8票 27.59%
気にしたことがない 0票 0.00%
その他 0票 0.00%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。
投稿者投稿内容
sawat
大ベテラン
会議室デビュー日: 2006/08/02
投稿数: 112
投稿日時: 2007-09-07 16:23
みなさんが仕様書（マニュアルではない）で機能説明をするとき主に以下のどちらの形式で記述しますか？

1.システム主観
（システムは）ボタンが押下されると、処理Aを実行し、結果画面を表示する。

2.ユーザ主観
（ユーザが）ボタンを押下すると、処理Aが実行され、結果画面が表示される。

理由もあれば教えて欲しいです。「使い分ける」の人はその基準も。
Fabulous
ベテラン
会議室デビュー日: 2007/08/11
投稿数: 51
投稿日時: 2007-09-07 16:45
「使い分ける」

基準は「説明を行う相手による」です。
使用する用語も相手視点に変更します。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-09-07 17:04
多くの場合、仕様書であればシステム主観 (プログラマ主観) です。 ユーザー主観なものはオペレーション マニュアルとして別途作成しています。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
BackDoor
ぬし
会議室デビュー日: 2006/02/20
投稿数: 831
投稿日時: 2007-09-07 17:14
普通はじゃんぬねっと様のコメント通りでしょう。
仕様書を何種類も創るケースが思い当たりません。
#　システム構築の中核じゃないですか。

引用:
sawatさんの書き込み (2007-09-07 16:23) より:

1.システム主観
（システムは）ボタンが押下されると、処理Aを実行し、結果画面を表示する。

2.ユーザ主観
（ユーザが）ボタンを押下すると、処理Aが実行され、結果画面が表示される。

1.は仕様書だし、2.は操作法説明書ではないのかと思いますが。
Fabulous
ベテラン
会議室デビュー日: 2007/08/11
投稿数: 51
投稿日時: 2007-09-07 18:00
補足です。

基本設計書等、ユーザーレビューを行うものはユーザー主観で記述。
理由は要件定義とのすり合わせの精度をあげる為と、開発側（詳細設計以降）のシステムの理解をユーザーよりにして齟齬を減らす為。

詳細設計書等の開発専用のものは、システム主観で記述。
ただし説明は極力ユーザー主観。

「どうなっている」は理解必須ですが、併せて「何の為に」にも重きをおきたいからです。

システム主観で説明するケースは、プログラミングをパートナーさんに説明する時（ユーザー主観での品質は自社責任）の場合や、ユーザー主観では理解しにくい新人相手の時などです。

※最初の回答は「機能説明をするとき」に釣られました。

[ メッセージ編集済み 編集者: Fabulous 編集日時 2007-09-07 18:16 ]
sawat
大ベテラン
会議室デビュー日: 2006/08/02
投稿数: 112
投稿日時: 2007-09-07 19:31
すみません、前提が抜けてました。
仕様書はユーザ（発注元）とレビュー等をおこなって、機能の内容の合意をえるためのものを主に想定していました。
正確には「機能仕様書」といった方がいいのかな？

>じゃんぬねっとさん、BackDoorさん
基本的にはその通りだと思います。
自分も普通はシステム主観で記述しますし。
だけど、システム主観の場合、ユーザの操作は「受身（〜される）」で記述することになると思うのですが、それだと書きづらい内容（されるが連発されたり）があったりしますし、ユーザに見せることを念頭においた場合、内容が直感的に理解しづらくなるようにも思います。
その辺について、ユーザ主観で割り切った「仕様書」を書いている人もいるのではと思って聞いてみた次第です。

>Fabulousさん
詳しい補足ありがとうございます。
つまり、ユーザにみせるものはユーザが理解しやすいユーザ主観ということですよね。参考になります。

ちなみにJoelの仕様書(やさしい機能仕様(パート1), サンプル)はユーザ主観になっていた気がしたのですが、探してみるとそうでもないような。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2007-09-07 22:57
「主観」って変じゃない？「主体」じゃないの？と思って、国語辞典を調べたら、「主観」と言う言葉は「主体」の意味を含んでいるんですね。

厳密に書こうとすると「システム主観」のほうが良いと思います。工数的には「ユーザ主観」のほうが楽ですが、仕様の記述としては漏れが出てくると思います。どっちでもいいよと言われたやっつけ仕事ならば、迷わず「ユーザ主観」を選ぶでしょう。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
Fabulous
ベテラン
会議室デビュー日: 2007/08/11
投稿数: 51
投稿日時: 2007-09-08 00:16
引用:

sawatさんの書き込み (2007-09-07 19:31) より:

つまり、ユーザにみせるものはユーザが理解しやすいユーザ主観ということですよね。

厳密に言うと「ユーザーがきっちり見る意思があるものは」の方が近いかもしれません。
きっちり読んでくれるユーザーだと、わかりやすい仕様書を納めていると後々の問合せが少なくなるので楽です。

引用:

unibonさんの書き込み (2007-09-07 22:57) より:

仕様の記述としては漏れが出てくると思います。

そういう意識があれば漏れないと思いますよ。

このアンケートはどういった仕事をしているかによってブレが生じると思います。そういった環境の違いによって他の人の意見が悪く見えてしまうのもつまらないですから、少し背景的な事も書いてみます。全て「私の場合は、」です。

まず、お付き合いしているユーザーの特性として、やりたいことの要件は提示してくれるものの、”運用にマッチし、システムのある程度の構造をイメージできる”ようなきっちりした要件定義書を提示してくれるユーザーは稀です。従って、私が記述する仕様書を要件の受け渡し確認に用いることも多いです。

受け渡し確認（責任の分岐点）を「ユーザーが記述する要件定義書」とするか「開発側が記述する機能仕様書」とするかでは、私は好んで後者を選んでいます。幸いにもこの時点での再見積りを認めていただいている点ではユーザーに恵まれているかもしれません。実感としては後者を分岐点とした方がユーザー側のその時点での仕様書に対する真剣さは増すように感じます。ここで「仕様書にかいていないことは実装できてなくてよい」を確定させる替わりに、ユーザーには運用までイメージできる安心感を与えることに留意しています。

この仕様書での「要件の漏れ」はユーザー責任。「仕様の漏れ」は開発責任。どちらも漏らすわけにはいきませんし、工数的に楽だと感じたこともありません。

目的は「お互いの明確な責任範囲をきっちり繋ぐことで戻りをなくす」こと。その主役はシステムが明確になっているものが望ましく、私の場合はそれが要件定義書ではなく機能仕様書であることが多い、ということです。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）