前回までで、システム開発の契約完了まで説明しました。今回は、その後、つまり開発時のポイントについて述べます。そのために必要なのが開発版ＳＬＡ（サービス基準契約）です。
契約といっても、この契約は前回述べた開発前の約束事項ではなく、開発中の約束を決めるものです。実際には、前回の契約と連続して行う場合が多いですが、これを中小企業で締結しているケースは非常に少ないと思います。以前紹介したリンク集にサンプルがありますので、詳しくはそれをご覧いただくとして、今日は契約のポイントをお話します。
先ほどＳＬＡをサービス基準契約と直訳しましたが、通常はサービス品質保証契約と表現します。実はこの品質保証というのがポイントなのです。システム開発に関しては、残念ながら公的に品質を保証する仕組みがありません。全くないというわけではないのですが（ISO 9126（JIS X 0129）シリーズで定めた「ソフトウェア製品の品質」と、ISO14598（JIS X 0133）シリーズで定めた「ソフトウェア製品の評価」、そして次世代国際基準としてISO/IEC 25000 SQuaREシリーズがあります。）、しかし、これらを利用して管理している例は特に中小ベンダーでは聞きません。
建設業ならば、品質管理基準がありますし、ＩＳＯ９０００シリーズもあります。これらは中小企業でも一般的ですが、システム開発の世界では品質管理の概念がまだまだ浸透していません。そこで上記のようにＳＬＡを結ぶのです。
ＳＬＡは、通常、開発後の運用時に結ぶことが多いのですが、開発時でも使えます。開発版ＳＬＡといっても難しく考えることはありません。主に決めるべき項目は、
・基本工程
見本品・設計ができあがる時期、テスト期間などを決めます。
・体制と役割分担
開発側と発注側の窓口、責任者、担当を決めます。役割分担は誰が何を決めるのか明確に。
・コミュニケーションルール
打合日、打合方法、参加者、議事録、承認方法などを決めます。
・セキュリティ
開発中に使うデータの取扱いや、（システムがビジネスアイデアによるものならば）漏洩防止の対策を決めます。
・システム開発の品質
システム開発の品質は、機能品質、操作品質、サービス品質、セキュリティー品質の４つです。
機能品質は「システムが実現する機能の範囲は満たされているか」、
操作品質は「操作上の性能要件は満たされているか」、
サービス品質は「いつまでに、誰がどのような役割で、どこまで作るか。計画は満たされているか」、
セキュリティー品質は「セキュリティー確保の範囲は満たされているか」です。
さらに、レビュー（みんなで内容をチェックする）回数、バグ対応時間、テスト項目消化数などの指標を決め、それをチェックできる仕組みを決めます。
上記のほとんどは、ベンダー側が提案するものばかりです。つまり、ベンダー側の実力が一番よく分かる資料でもあるのです。
ユーザーとしては、中身を理解した上で自分たちの出来ること出来ないことを明確にする必要があります。特に抑えるべきは、仕様変更時の責任分担で、もっとも揉める箇所と言えます。しっかり決めましょう。
サービス品質に関しては、システム内容と開発手法によって様々な表現・指標がありますので、これというものが出せず申し訳ありませんが、大事なことは、 開発中はおまかせというのでなく、「依頼者として途中段階もしっかり見ますよ」という意思表示です。家を建てるときでも、途中で進捗状況を見に行きます ね。システム開発においても、途中状況を見られるよう、指標や打合回数、工程などをきちんと決めておきましょう。そうすれば、最後に「こんなはずではなかった」となってしまうことはありません。
いずれは、システム開発にも一定の基準が適用されるようになるでしょう。それまでは試行錯誤もありますが、くじけず開発版ＳＬＡを作りましょう。