前の開発では、担当者ごとに設計書の書式がばらばらで、数年後に引き継ごうとしたら誰も読めなかった。今回は「ちゃんとした手順で作ってほしい」と伝えたい。でも何をどう指定すればいいのか分からない。システム開発標準を調べると出てくるのは作り方やテンプレートの記事ばかりで、それは社内でルールを作る人向けの話です。発注側の役割は違います。標準を自分で作るのではなく、開発会社が持っているものを確認して、自社が困る部分だけを契約と要件定義書に書く。この記事では、その確認の仕方と、書くべき最低ラインを整理します。
この記事のポイント
- 開発標準は開発会社が持つ社内ルールで発注側は作らない
- あるかないかより今回の案件に適用されるかを聞く
- 発注側が指定するのは4つに絞らないと守られない
- 順守してほしい項目と参考でよい項目は分けて伝える
目次
システム開発標準とは何を決めたルールか
開発標準というのは、作業の進め方や書類の形式をあらかじめ決めておく社内ルールのことです。中身は会社によって違いますが、だいたい次のようなものが入っています。
- どの工程で何を作るか（成果物の一覧）
- 設計書やテスト仕様書の書式とひな形
- レビューを誰がいつやるか
- テストの種類と合否の決め方
- 変更が出たときの記録の残し方
規模の大きい会社ほど整っていて、少人数の会社ほど個人のやり方に寄る傾向があります。どちらが良いという話ではなく、そういう差があるという前提で発注側は見ます。
開発標準は開発会社が持つ社内ルール
最初に押さえておきたいのは、これを作るのは開発会社だということです。発注側が自分で作る必要はありません。
「システム開発標準」で検索すると、作り方やテンプレート、導入の手順を説明した記事が並びます。あれは社内に開発チームを持っている会社が、自社のルールを整えるために読むものです。外部に発注する立場で読むと、自分が何をすればいいのか出てこないので戸惑います。
発注側の役割は、相手の持っているルールを確認して、自社が困る部分だけを指定することです。ゼロから作るのではなく、相手の標準に乗るところは乗って、足りないところだけ足す。この立ち位置が決まると、やることが一気に減ります。
この考え方は、品質の話とも地続きです。開発標準は品質を安定させるための仕組みですが、仕組みがあれば自動的に良いものが出てくるわけではありません。何をもって合格とするかを決めるのは、やはり発注側です。標準は合格に近づけるための道具であって、合格の位置そのものを決めてはくれない、と考えておくとちょうどよい距離感になります。
標準がないと困るのは稼働してから
厄介なのは、標準があるかないかで発注時点では困らないことです。問題が出るのは、作っているあいだか、稼働してしばらく経ってからになります。
よくあるのは3つです。担当者ごとに設計書の書式が変わって、途中から読むのに時間がかかる。数年後に別の会社へ引き継ごうとしたら、書類が揃っていなくて読めない。テストの合否の決め方が曖昧で、検収の場で何をもって合格とするかが決まらない。
とくに引き継ぎは、あとから金額に跳ね返ります。次の開発会社は、まず現状を読み解くところから始めるので、書類が揃っていない分だけ調査の工数が乗ります。私の感覚では、ここで数百万円の差がつくことは珍しくありません。
もうひとつ見落としがちなのが、社内の引き継ぎです。発注を担当した人が異動したあと、残った書類だけで話が通じるかどうか。開発会社が変わらなくても、自社側の担当者は数年で変わります。そのときに読める形で残っているかは、書式が揃っているかどうかでかなり違ってきます。
どの工程で何を受け取るはずなのかは、納品物と成果物の違いと工程別の一覧に整理してあるので、受け取るものの全体像はそちらで確認できます。
標準があっても今回の案件に適用されるとは限らない
ここが実務では一番効きます。「御社の開発標準はありますか」という聞き方は、実は弱いのです。たいていの会社は「あります」と答えます。
聞くべきなのは、あるかないかではありません。次の2つです。
1つ目は、それが今回の案件に適用されるかどうか。大きな会社ほど標準は整っていますが、案件の規模や期間によって簡略版を使うことがあります。フルセットの標準が存在することと、今回それが使われることは別の話です。
2つ目は、再委託先にも適用されるかどうか。開発会社が一部を別の会社に出す場合、その会社が同じ書式で作るとは限りません。実際、書式がばらつく原因の多くはここにあります。「再委託先にも同じ標準を適用しますか」と一言聞いておくだけで、後の手戻りが減ります。
確かめ方としては、過去の案件で実際に作った設計書を1枚だけ見せてもらうのが早いです。機密に触れる部分は伏せてもらって構いません。目次と見出しの付け方、図の入り方、更新履歴の欄があるかどうか。この3点を見れば、標準が運用されているのか、名前だけあるのかがだいたい分かります。断られた場合は、社内の様式サンプルでも構わないと伝えてみてください。
システム開発標準を発注側が使う範囲
ここからが発注側の実務です。確認が済んだら、自社として何を求めるかを決めます。
発注側が指定するのは4つに絞る
やりがちな失敗は、思いつく限りの要求を並べてしまうことです。全部を指定しようとすると、相手は見積もりを厚くするか、形だけ整えて中身が伴わないかのどちらかになります。
絞るなら次の4つで足ります。どれも、守られないと自社が後で困るものです。
| 指定する項目 | 曖昧な書き方 | 契約や要件定義書に書ける形 |
|---|---|---|
| 成果物の一覧と書式 | 必要な資料を納品する | 工程ごとの納品物名を列挙し、編集可能な形式で渡す |
| レビューのタイミング | 適宜レビューを行う | 各工程の終わりに実施し、発注側の担当者が参加する |
| テストの範囲と証跡 | 十分にテストする | 実施したテストの種類と結果の記録を提出する |
| 変更の記録 | 変更は都度共有する | 変更内容と金額・納期への影響を書面で残す |
逆に、指定しなくてよいものもあります。プログラムの書き方の規約、使うツール、社内のレビュー手順。これらは開発会社の内部の話で、発注側が口を出しても品質は上がりません。
迷ったときの線引きは、「自社が後で読むもの・使うものかどうか」です。設計書は自社が数年後に読みます。テストの記録は検収の場で使います。だから指定する。一方、プログラムの命名規則を自社が読むことはまずありません。そこは相手の裁量に任せたほうが、結果として品質は安定します。
この4項目は要件定義書にも書き込むことになるので、書いたつもりで抜けていないかを一度点検しておくと安心です。要件定義書レビューシート（発注前に抜け漏れを点検する確認リスト）を使うと、成果物やテストの記載が漏れていないかを項目単位で確かめられます。
順守と参考の2段に分けて伝える
もうひとつ、伝え方に工夫の余地があります。求めることを全部「守ってください」にすると、相手は身構えます。
参考になるのが、公的なガイドラインの作り方です。デジタル庁が公開しているデジタル社会推進標準ガイドラインでは、各ドキュメントの位置づけが2種類に明示されています。順守する内容を定めた「標準ガイドライン（Normative）」と、参考とする「実践ガイドブック（Informative）」です。同じガイドライン群の中で、守るものと参考にするものが最初から分けてあります。
これは政府情報システムの整備と管理についての共通ルールなので、民間の発注でそのまま使えるものではありません。ただ、2段に分けるという考え方は自社の発注ルールにもそのまま持ち込めます。なお、このガイドライン群は旧称を「デジタル・ガバメント推進標準ガイドライン群」といい、政府内部だけでなく社会全体のデジタル化を推進するという観点から名称が改められた経緯があります。民間が参考にすること自体は想定の範囲内だと読めます。
実務では、先ほどの4項目を「順守」に置き、それ以外の希望は「参考」として伝えます。相手からすれば、絶対に外せない線がどこかがはっきりするので、見積もりも出しやすくなります。全部が順守だと、どこに力を入れるべきか判断できません。
この分け方は、提案を受けたあとにも効きます。参考として伝えた項目について相手が別のやり方を提案してきたなら、それは標準を持っている会社の証拠です。逆に、順守として伝えた項目に何の言及もなく見積もりだけが返ってきたときは、読まれていない可能性があるので、提案の場で1つずつ確認します。どちらに転んでも、相手の実力が見える材料になります。
工程の呼び方は相手に合わせる
指定する側で気をつけたいのが、工程の名前です。自社で工程名を決めて押し付けると、かみ合わなくなります。
開発会社によって、基本設計と外部設計のように呼び方が違います。略語の使い方も会社ごとに差があります。ここを統一させることに意味はありません。相手の呼び方に合わせて、「どの工程の終わりに何を受け取るか」だけを対応づければ十分です。
工程の区切り方や略語の読み方に不安があるときは、システム開発の工程と流れ・略語の意味を見ておくと、相手の説明が追いやすくなります。
決めたルールを守らせる進め方
契約書と要件定義書に書いたからといって、そのとおりに動くわけではありません。書類は出発点で、守られるかどうかは進め方で決まります。
効くのは2つです。ひとつは、定例の確認項目に入れてしまうこと。進捗の話だけで終わらせず、「今回の成果物は決めた書式になっているか」を毎回の議題に1行入れておきます。
もうひとつは、最初の1工程で実物を見ることです。要件定義や基本設計の成果物が上がってきた時点で、決めた書式どおりかを実際に開いて確認します。1回目が守られていれば、その後も続く可能性が高い。逆に1回目から崩れているなら、その時点で言えば直せます。最後まで待つと、もう作り直せません。
この確認を毎回どう回すかは、ベンダーコントロールの進め方で扱っている動き方がそのまま使えます。
- Q. うちにも開発標準を作るべきですか
- A. 外部に発注するだけなら、作る必要はありません。作るのは開発チームを社内に持つ会社です。発注側が用意すべきなのは、標準そのものではなく「自社が受け取りたいものの一覧」です。成果物の名前と形式、レビューの参加者、テストの証跡、変更の記録。この4つを書いたA4一枚があれば、複数の開発会社に同じ条件で伝えられます。
- Q. 開発会社に標準があるかどうかは、どう聞けばいいですか
- A. 「ありますか」ではなく「今回の案件に適用されますか」と聞きます。大きな会社ほど標準はありますが、案件の規模によって簡略版を使うことがあるためです。あわせて「再委託先にも同じものを適用しますか」を聞いてください。書式がばらつく原因の多くは再委託先との差です。可能なら、過去案件の設計書を1枚だけ見せてもらうと実態が分かります。
- Q. 公的なガイドラインを契約書にそのまま引用してもよいですか
- A. おすすめしません。政府情報システム向けに作られた文書なので、民間の案件では過剰になったり、前提が合わなかったりします。参考にするのは考え方の部分だけにして、契約書には自社の言葉で必要な項目を書いてください。どうしても引用したい場合は、範囲を明示したうえで法務の確認を通すのが安全です。
