【非機能要件定義書】ループスの雛形紹介その２
お世話になっております。
ループス岡村直人です。
「【RFP】
これがループスの”提案依頼書 雛形”です」に続いて、
ループスで使っているドキュメントの雛形を紹介させて頂こうと思います。
今回ご紹介させていただくのは、「非機能要件定義書」です。
こちらからダウンロードできます。
「【標準】非機能要件定義書20100115.pdf」をダウンロード
◆本エントリについて
以下のような方に楽しんで頂けるように書いています。
- システム開発を発注する立場の方
- システム開発の見積もりを行う立場の方（営業、SE）
- 上記いずれかの面倒くさがりな方
非機能要件定義書については専門的な書籍や記事が色々ありますが、
まずは他人が使っている本物を見るのが早いと思います。
骨の髄までめんどくさがりな私とあなたのために、ざっくり簡単に書きました。
◆「非機能要件定義書」の役割と位置付け
システム開発の見積もりは、大きく以下の3要素から成ると思っています。
- 商流
- システムが提供する機能
- システムの作り方
見積もりを依頼しても、帰ってくる金額がバラバラで比較にならないという場合、
上記3要素についてベンダが独自の解釈を行っている可能性があります。
特に費用として見えづらいのが「3.システムの作り方」あたりで、
このエントリで紹介する「非機能要件定義書」の提案範囲です。
◆3要素について
簡単に説明させてください。
①商流
発注者が「商流」にかけるコストとは、つまりノウハウです。
管理能力だったり、アレンジ力だったり、企画力だったりします。
発注後の付き合いにおいて、商流は簡単に変更できないため、非常に重要な選定項目です。
②システムが提供する機能
発注者が「システムに提供する機能」にかけるコストとは、納品されるアプリケーションそのものです。
一番目立つので、一番深く議論され、提案は厳しく吟味されます。
③システムの作り方
発注者が「システムの作り方」にかけるコストとは、
ある意味「納品物の機能以外全て」に近いです。
多様で、漠然としており、定義するのも難しいのですが、範囲も広く非常に重要です。
個別契約書に詳細が記載されることも多いと思います。
例えば、同じ仕組みを作るのにも、あるベンダは設計に設計を重ね、多くのドキュメントを生産し、
テストは高価な専用ツールを、専門的な技術で操って担保し、
進捗状況は定量的に測定可能な方法で報告するとします。
あるベンダは開発者個々人が実装の過程で設計を行い、
テストをせず、進捗報告は主観に基づくとします。
上記のような、開発の方法で当然コストは変わってくるのですが、
私の経験上、発注者がそういった専門的な観点で質問することも、
ベンダが自発的にそれらを明示することも多くないように思います。
他にも、品質や性能、納品後のベンダの役割、
合意形成のポリシー、対応可能な業務のスコープなど、定義すべき項目は多岐に渡ります。
◆だからどうした
前述した3要素はどれも非常に大切ですが、
システム開発における機能以外の側面は非常に軽視、
あるいは無視されていることが多いと感じます。
未だに、納品物を納めた後になってから
「設計書はないのか」「テストはしたのか」「あるべき」「なくてしかるべき」などと
言った言わないの水掛け論にはまっているプロジェクトを見聞きします。
◆こんなものをわざわざブログにあげる理由
前述のようなトラブルは、ベンダに大きな責任があるとは思いますが
発注者の観点がコストにばかり向いていると、目につきづらい部分で省力化が行われ
後々になって問題になるケースもあるのではないかと思います。
本エントリで紹介させていただいたループスの非機能要件定義書は、
そういった目につきづらい部分の一つの観点です。
当社では、発注時にこういった観点が明示されることで、
はじめて取捨選択の判断が可能となり、公平な業者選定が可能となるはずだと考えています。
紹介させていただいた資料が皆様のプロジェクトの参考になれば幸いです。
また機会があれば内容について詳しく触れていきたいと思います。
それでは、よろしくお願いいたします。
◆最後に
今回掲載させていただいた非機能要件定義書は、特にセキュリティ関連についてかなり貧弱な内容になっております。これは、セキュリティに関しては発注者サイドで基準を設けている場合が普通であり、社内で標準的な基準を用意する意味がそれほどないためです。（非常に営業的な話で恐縮ですが、）発注者サイドでセキュリティ品質に明確な基準がない場合は、その意識が希薄であり、提案しても高コスト業者として弾かれてしまうため、あえて厳密に記載するメリットがない場合が多いです。