今回はシステムやサービスの納品物ついてのお話です！
サービスの導入が完了した時や、システムの納品時は、ドキュメントの提出を求められます。
このとき、どんなドキュメントを提出すればよいのでしょう？
今回はこの辺のお話をしたいと思います！
システム納品時に求められるもの
大体よく求められるのは、以下のドキュメント。この一式を納品書として提出するのがよくあるパターン。
- 操作マニュアル
- 業務マニュアル
- 障害対応マニュアル
- システム仕様書
マニュアルについて
では、それぞれどんな時に使うドキュメントか解説します。
操作マニュアル
例えば、起動・ログイン・操作全般・ログアウト・終了、注意すべきポイント・などなど、ユーザー側の目線で書かれた、システムの全機能についてのドキュメント。
業務マニュアル
オペレーターはどうやって業務を行うのか？を中心としたドキュメント。
業務フローに沿って書く事が基本で、操作マニュアルに含める場合もあります。
この業務をやるときは「この手順」みたいに、上から順に見て行けば業務に沿った手順が解るように作るのが基本です。
障害対応マニュアル
システムに問題が発生したとき、どのように対応すればよいか？について記載されたマニュアルです。
いまどきは「サポートにお問い合わせください」や「障害時はこちらから連絡をします」みたいなフローだけをお伝えする事が多いですが、冗長化されているシステムの場合は、その切り替え手順を記載します。
システム仕様書
システムの仕組み・ルール・構造・構成についてなど。仕様について書かれたドキュメント。
受託開発の場合、開発や導入が完了しましたという証拠に、プロジェクトで決定した内容のドキュメントの提出を求められる場合があります。
これを総称して成果物と呼びます。
この成果物で代表的なのが、設計書や仕様書なんです。
マニュアルは納品物によって違う
受託開発の場合は、毎回オリジナルのシステムを作るので、当然マニュアルも0から作る事になります。なので初期費用にマニュアルの作成費用も含まれている事もあって金額がどうしても高めになるのです。
ただ、クラウドサービスのように、全てのユーザーに同じ仕様で提供するようなサービスやプロダクトは、あらかじめ作った汎用的なガイドだけをそのままお渡しします。
全てのユーザーに同じ仕様で導入するなら、ベンダーの作業を削減する事ができるんで、初期費用も安くなるのです。
最初に合意を取るのが重要
提出物は、最初のうちに合意が取れていないと、揉めてトラブルに発展しやすいんです。
「ドキュメントは基本提出をしない」というポリシーのベンダーもいますし、「提出するのが普通ですよね」と考えるユーザーもいます。
さらに言うと、業務中心のマニュアルにしてくれというユーザーも入れば、仕様だけではなく、すべての仕様の項目になぜこの仕様にしたか、根拠の記載を書け！というユーザーもいます。
ドキュメントには「粒度」という定義があります。
粒度とは「内容をどこまで細かく書くか？」の決めで、粒度はユーザーによって大きく異なります。
このようにユーザーから求められるドキュメントの粒度やベンダーのポリシーは様々です。
この「粒度」の合意が先に取れていない場合、どうなるかと言いますと。
最後の最後に、手直しを何度も何度も要求されてしまい、プロジェクトがどんどん長引いてしまうんです。
大事なのは、できるだけ最初の段階で「決め」と「合意」をきちんとやっておくこと。
何も言われなけば、際限なくいつまでも修正依頼をされるかもしれません。
それどころか、お金をもらわなきゃいけない作業なのに、無償でドキュメントを作らされ続けるリスクもあるんです。
合意が成立していない赤字案件を繰り返すと、会社は赤字になりますんで、ちゃんと対策を考えなければいけません。
例えば「３か月間は修正を受けつけるがそれ以降は受け付けない」みたいに締め切りを設けたり、汎用的な手順書の提供はするが、修正は受け付けない・・など宣言をしておく事です。
サンプルを初めに提供したり、見積りの前提条件に納品物のポリシーを記載したりなど、どこのベンダーも色々と工夫をしています。
チェックされるポイント
ユーザーによって多少違いますが、例えば情報システム部門はこんな部分をチェックします。
| 機能要件 | 要件定義した機能が実現できているか？ |
| 性能要件 | 想定している利用状況がすべてクリアできるか？ |
| 保守性 | シンプルで解りやすい設計になっているか？ |
| ドキュメント | 要件定義をした項目が、仕様書やマニュアル各種にすべて記載されているか |
これを現場が認め、上長が承認すれば「検収印」をもらえて納品完了となり、お金がもらえるのです！
最後に
歴史のある日本企業や、金融系からはかなり粒度の細かいドキュメントを求められます。
例えば「仕様」だけではなく「なぜこの仕様なのか？」みたいな根拠の要求も出てくるのです。
一般のベンダーは多くの案件を最小限のコストで回さなければいけないので、こういった対応を嫌います。
しかし、コンサルティングファームと呼ばれる企業は、逆に面倒なドキュメントの対応が得意です。
コンサルティングファームは、ドキュメントに手戻りが発生すればするほど、お金が儲かる仕組みになっていたり、手戻りを想定して、あらかじめドキュメントの料金を高めに設定しています。
こういう背景があるので「コンサルティングファームは高い」みたいなイメージを持つ担当者が多いのです。
細かい粒度が必要なドキュメントの仕事を、コンサルティングファームに依頼すると高いので、今度は安い料金でやってくれそうな一般のベンダーに頼もうとします。
この流れを警戒せず、粒度を未確認のまま、相手の言いなりで進めてしまうと、際限なくドキュメントを作り続ける、採算の取れない案件になってしまいます。
赤字案件を量産しないよう、こういった背景も理解しておきましょう！
