[ ViVi SPR System | ViVi Home ]

 目次:

■ SPR System とは

 SPR は Software Problem Report(ソフトウェアの問題レポート) の略で、ユーザが開発中のソフトウェアを試用し問題と感じたことを開発者にレポートするものです。ユーザが問題と感じることの原因としては、プログラムのバグ、仕様の不備(または不完全性)、実装が不完全、ユーザの誤解・理解不足の場合などがありますが、これらを区別することは(一般)ユーザには困難で意味の無いことです。したがって「バグレポート」とは呼ばず「ソフトウェアの問題レポート (SPR)」とし、それらを同次元で取り扱います。

 仕様書とは無関係に、ユーザがソフトウェアを使用して問題であると判断したものを開発者にレポートするもが SPR です。「仕様書とは無関係に」という点に注意してください。ソフトウェアがユーザが期待した通りの動作をしない場合、それが仕様書に明記されているかどうかは免罪符にはなりません。ユーザが問題と思えば、それは問題なのです。ユーザは主観的に問題と思ったことをレポートします。

 しかし、すべての問題が対処できるかというと、そんなことはありえません。ソフトウェア開発は人員、コスト、時間といった有限のリソースを使って行うものなので、出来ることには限りがあります。したがって、ある問題を実際に対処するかどうかは開発側の判断となります。これに対して不満があるユーザは開発コストを負担するか、当該ソフトウェアを使用しないか、いつかその問題が解決されるのを我慢して待つ、という選択肢があります。または自分で代替物を開発するというのもひとつの選択肢です。ユーザが開発コストを負担するのでない限り、開発者に対処を無理強いすることは出来ません。このことはしっかり理解しておいてください。

■ SPR

○ 状態、結果

 SPRは、New、Pend、OpenFixedReOpen、Close のいずれかの状態にあります。

 SPRは最終的に、対処、実装、自然治癒、仕様、再現不可、NPTF、重複、ユーザエラー、その他 のいずれかの結果になります。
    (補足:NPTF は No Plan to Fix の略です。問題ではあるけれど工数が膨大・困難なために総合的に判断して対処しないことを表します)

が問題を新たにレポートするとSPRが生成され、New状態になります。

 担当者は新規SPRを確認し、問題が再現するのであればOpen状態にします。再現しない場合はPend状態とし、レポートしたユーザと協議します。協議後に再現するようになればOpen状態に、そうでなければ継続協議またはClose状態になります。既に報告済みの問題、ユーザの誤解・理解不足でレポートに問題があった場合、対処しないことが決まっている場合は、重複、ユーザエラー、NPTF、仕様という結果でClose状態になります。

 Openされた問題が開発者により対処されるとFixed状態になります。開発者の判断で問題を対処しない場合があります。その場合は仕様またはNPTFという結果でClose状態となります。

 Fixed状態のSPRは問題報告者により対処が確認され、問題がなければ結果:対処でClose状態になります。対処が不十分な場合はReOpen状態になります。

        ユーザエラー、再現不可、仕様
      ┌─────────────────────┐
      │        NPTF, 再現不可、仕様   │
      │      ┌─────────────→│
 問題報告 │ 問題承認 │  対処等    対処確認  ↓
 ───→[New]───→[Open]───→[Fixed]───→[Close]
      │      │ 対処不完全↓↑対処等   ↑
      └────→[Pend]←───[Reopen]─────┘
                        NPTF, spec

○ オーナー

 各SPRはオーナーを持ちます。オーナーとはその時点での当該SPR担当者のことです。オーナーはSPRの内容を判断、調査し、必要があれば何らかの対処を行って次のオーナーにSPRを引き渡します。ただしClose状態の場合はオーナーはいません。

○ 優先度(Priority)

 SPR対処の優先度を示します。A 〜 E があり、A が最も高い優先度です。

    A:最優先で対処
    B:必ず対処
    C:原則対処
    D:簡単であれば対処
    E:NPTF候補

 優先度B以上は正式リリースまでに対処・実装しますが、C以下はスケジュールの方が優先されます。ただし、優先度はもろもろの事情で変更される可能性があります。

○ 重要度(Severity)

 SPR の種類・問題の深刻さを表します。

    A:通常操作でのクラッシュ・無限ループ
    B:特殊な条件、環境でのクラッシュ・無限ループ、非常に重要な動作不良
    C:機能が動作しないなどの普通の動作不良
    D:些細な動作不良で、簡単な代替手段があるもの
    E:ミススペルや誤った文章など、機能そのものの動作に影響を与えない、さほど重要ではないもの
    M:メモリリーク
    P:パフォーマンス問題
    R:リファクタリング
    T:機能強化要望(Enhancement)、ToDo
    X:XT(eXtreme Toolkit)に由来する問題

■ ポイント

○ ポイントシステム

 ViVi SPR System はポイントシステムを採用しています。
 ユーザは発見した問題をSPRシステムに登録する、有用なコメントを記述することでポイントを取得することができます。取得したポイントは vote(投票)に使用することが可能です。
 問題報告のポイントは以下の目安とします。

非常に重要な問題報告40ポイント
重要な問題報告30ポイント
通常の問題報告20ポイント
軽微な問題報告10ポイント
重箱の隅をつつくような問題報告5ポイント
機能実装要求0ポイント

 実際の報告がどれにあたるかは管理者の独断と偏見で決定します。また、問題報告が具体的でなくわかりずらい場合は 10ポイント程度減点します。
問題レポートの書き方は こちら を参照してください

 Fixed 状態のSPRを確認し、CLoseした場合は 5ポイントを差し上げます。
 有用なコメントの場合、10〜30ポイントを差し上げます。
 月初には自動的に 10ポイント差し上げます。

○ vote(投票)

 vote を行うことで、好みの機能実装や問題対処を*せかす*ことが出来ます。ただし、vote 数の多いものから順に実装・対処するのではなく、vote 値を参考にして作者が独断と偏見で順番を決めます。作者が次に何を対処するかまよった場合は vote の多いものから優先的に対処します。
vote 結果よりも作者の意思が優先します。

 提案されている機能を実装して欲しくない場合はマイナスのポイントを vote することができます。その場合、持ちポイントは増えるわけではなく、voteしたポイントの絶対値だけ減少します。

 機能拡張要求の場合、少ない vote 数であっても、実装工数が少なく副作用の心配が小さい場合は優先的に実装されます。逆に実装工数が多く、副作用の心配が大きい場合は、vote 数が多くても、優先的には実装されません。

○ vote point 上限

 一人の人が1件のSPRに vote できるポイントは(絶対値の)合計100ポイントまでです。

○ point 有効期限

 vote できるポイントの有効期限は、ポイント取得月から3ヶ月間とします。たとえば、1月中に取得したポイントは3月末まで有効です。vote を行わないと無効になってしまいますので、それまでに vote するようにしてください。