システム開発に関する勉強会

目次

1. 提案と見積もり

1-1. 情報提供依頼書 RFI

1-2. 提案依頼書 RFP

1-3. 提案書

1-4. 要求定義書

1-5. 要件定義書

1-6. 役割分担

1-7. 開発範囲、サービス範囲

2. 契約と法務

2-1. 請負契約

2-2. 準委任契約

2-3. SES契約

2-4. 多段階契約

2-5. 著作権

2-6. 瑕疵担保責任

2-7. 下請法

2-8. 責務不履行

2-9. 無償契約

3. 要件定義

3-1. 導入の目的

3-2. 目的達成の方針

3-3. エンドユーザーの要望

3-4. 制約条件

3-5. 前提条件

3-6. 業務要件(業務の把握)

3-7. 機能要件

3-8. 非機能要件

3-9. 用語集の作成

3-10. 推奨環境の定義

3-11. 権限マトリクス

3-12. ワイヤーフレーム

3-13. ER図、データベースエンティティ定義書

3-14. 画面一覧

3-15. ステークホルダー

3-16. 交通整備

※他にもいくつか項目はあるが今回は時間の都合もあり割愛します。

4. 顧客が本当に欲しかったもの

4-1. 顧客が本当に欲しかったもの

4-2. 氷山の一角

4-3. 5W1h

5. まとめ(5分)

5-1. 全体を通して

1. 提案と見積もり

1-1. 情報提供依頼書

情報システムやサービスの開発・導入を検討する顧客が、ベンダに対して製品の最新技術動向に関する情報の提供を依頼する文書。セールストークや展示会での説明等違い、顧客向けの具体的かつ正確な用法を正式な文書として回答する。

RFIでは、以下のようなことについて情報提供依頼がなされます。

• 最新技術の動向/製品・サービスの情報
• 同様の課題を解決した他者の先行事例
• 新システムのイメージ。構成概要、参考価格
• ベンダ選定の着眼点、評価軸 など

ここに挙げているのは一例で実際のところ情報提供依頼書では何を聞いても構いません。「ライバル会社のシステムに関する情報を洗いざらい出してくれ」という無茶な要求も、質問するだけなら自由です。

また、回答もsの質や量を問われることはなく、回答しなくても文句を言われる筋合いのものでもありません。

ただ、ベンダーが責任を持って行う正式なものですから、ウソや誇張はいけません。 そのあたりの注意点について裁判所に実際にあった事例をまとめて記載します。

回答は後々要件となるため、契約時の洗い直しが必要

RFIへの回答は訂正、削除のない限り、契約後も要件として生き続けると考えるべきです。

例えば既存の人事システムに接続する勤怠管理ソフトウェアに関する情報を求められたとき、よく調べもしないで「このソフトのインターフェイスは一般的ですから貴社の既存システムとの接続に特別な考慮をする必要はありません」と回答したとします。

開発開始後に何らかの措置が必要と判断したとしても、この「発言」がそのまま確定した要件とい見なされ、その作業費をユーザーに請求できない危険があります。

ですから、めでたく受注が成って契約する際には、それまでに提出した回答文書を洗い直し、 誇張や虚偽、時間の経過で変化してしまったようなことを修正したり。他の文書で否定しておくことが大切です。

確認の取れない定量的表現をしない

しかし、いくら「情報提供」と言っても、RFIへの回答はベンダーにとって重要なセールスチャンスです。

自社の提案したいソフトウェアやサービスに好都合な情報を提供するのは、むしろ自然なことともいえるでしょう。

まして、自社に有利な定量的データや評価結果があれば、是非とも回答に入れ込んでおきたいところです。

ただし、こうした定量的表現は、真偽が判断しやすいため、そこに虚偽や誇張があると「誇大広告※1」ではないかと疑われることがあります。「当社製品のシェアは80%」、「顧客満足度一位」とい言った表現は、その情報源、論拠、情報の新しさをよく確認し、必要に応じて但し書きや注釈を付記します。

このような表現を客観性を証明できあいのであれば使用しない方が良いでしょう。

そして、「当社製品の速度はA社製品の1.5倍」、「コストはやく２分の１」と言ったユーザーのメリットを数字的に約束していると取られるような表現はされに危険です。

導入後そうした数字を達成できない時、あてにして導入を決定したユーザーに訴えられる可能せもあります。

※1 商品やサービスの内容・価格などが、実際のものより優良または有利であると消費者に誤認させるように表示した広告。

1-2. 提案依頼書

提案依頼書（RFP）とは、ユーザ企業が、情報システムの構築やサービスの提案を依頼するためにベンダに交付する文書。 ユーザの基本情報に加え、現状抱えている課題と、システム化の目的・方針、導入でのスケジュールや各種方針、システムに求められる機能や希望するサービスの内容および作業の範囲、各種の前提条件・制約条件のほか、ベンダ選定の方針やスケジュールなどを記載します。

ユーザとベンダは「お客様の課題解決に寄与する仕組みを実現して、経営に寄与する」という大目的は同じでも、その実現過程においてはある意味利害が相反する存在です。 少しのお金で難しい作業をたくさんやってもらおうというユーザーと、その真逆のことをしたいベンダの関係は、どちらかが得をすれば、必ずその分もう一方が損をするという利害不一致関係が成り立ちます。 「右手で握手をしながら、左手には剣」というわけです。

上記のことを踏まえながら提案依頼書を受領したとき、後々火種にならないようにどのようなところに注意をしてみる必要があるか考えてみます。

まず、提案依頼書にはどのようなことが書かれているのか簡単にみてきます。

項目の概要だけですが、大体以下のことが書かれています。

提案依頼書の記載事項例

[ 基本情報と提案依頼の目的 ]

• ユーザーの基本情報（業種、業態、組織、提供する製品やサービス 等）
• システムやサービス導入の背景（経営方針およびシステム化方針 等）
• 開発/サービス導入の目的（期待された効果・メリット 等）
• 想定するシステムやサービスの概要（想定される業務フローも含む）
• 使用者に関する情報（部門および業務的な役割、人数 等）
• マスタスケジュールとマイルストーン 等

[ 提案を依頼した事項 ]

• サービス範囲や作業範囲（対象システム/サブシステムや工程 等）
• 役割。責任分担（ユーザとベンダの作業分担）
• 想定するシステム開発手法、プロジェクト管理手法
• 想定する成果物
• 要件概要（機能要件/非機能要件）
• 新システム/サービスに関する社員教育の要望
• その他要件検討事項および未解決事項
• 提案書の目次、体裁、提出期限、提出方法、先行方針 等

ユーザのわがままを真摯に受け止める

この提案依頼書の作成はユーザ企業が行うもので、その要望や希望は比較的ストレートに表現されています。 ベンダ主体で決める要件定義書とは異なり、ユーザーが技術的な制約やベンダの背景を気にせずに作成されたものになります。 プロジェクト開始後ではなかなかできない自由な発想や要望を記載したこの資料はユーザーの本来の目的を最も忠実に表現したものになります。

ベンダにはこうしたユーザーの自由闊達な要望を軽視せずにそこからユーザーが本当に欲しているものを見抜いて、現実的で有効な代替え案を提出することが求められます。

提案依頼書の記述も予見に化けるため、契約時には洗い直しが必要

提案依頼書の記載項目に特に訂正、削除がない場合、要件の一つとして取り扱われる可能性があります。

実際のIT控訴でも、ユーザが提案依頼書で要望したいくつかの機能をベンダが要件として定義せず、完成後に気づいて紛争になった事例があります。 ケースバイケースではあるが、たとえ要件として定義してなくても提案依頼書の記載がそのまま要件とみなされることが実際にはあるということです。

1-3. 提案書

システム構築やサービスの提供をベンダーが提案する資料になります。 課題と背景、解決の方針とその実現方式、提供するハードウェア、ソフトウェアおよびサービスの範囲と内容。また体制・役割分担、スケジュール概要を記載して見積もりとともに提示します。

IT紛争を意識しながら、提案書で足元をすくわれないための注意事項について書いていきます。

やること、やらないこと/責任を持つこと、持たないことを明示する

提案書にはユーザに様々な夢を具現化できると説明するものであると同時に、ベンダが「この期間・費用でこれだけのことを実現します」と約束するものです。ですからその内容は隅から隅まで非常に重要で、IT控訴においても度々重要な証拠として扱われます。悪くすると、その記述が最後まで双方を苦しめることにもなるため、提案書は「仕事をとる」という攻めの姿勢と、「これ以上はやらない、約束しない」という守りの姿勢の両方を意識して書く必要があります。

下記にシステム開発の提案書を例にどのような項目があるのかをみていきます。

提案書への記載事項例

[ 現状理解とシステム導入/開発の目的・方針についての認識 ]

• ユーザの助教、事業環境と解決すべき課題についての認識
• システム化の目的と方針・メリットについての認識
• 既存システムについての認識

[ 新業務とその要件 ]

• 新業務フローとシステム化範囲
• 業務要件概要（業務の内容）

[ 新システムの要件概要 ]

• 開発にあたっての事前事項・制約事項についての認識
• システムの基本要件、基本機能
• 画面や帳票イメージ他UX概要

[ 新システム構成概要およびソフトウェア、ハードウェア ]

• システム概念の説明
• システム構成概要
• 使用するハードウェア、ソフトウェア一覧およびその特徴・優位点
• ネットワーク機器

[ プロジェクト計画概要 ]

• 全体計画と当プロジェクトの位置づけ
• 開発方針
• マスタスケジュール
• システム移行の方針と計画概要
• ユーザとベンダの役割分担概要
• 体制およびメンバのスキル、略歴

[ プロジェクトの進め方 ]

• プロジェクト管理方針（進捗、リスク、課題 ...etc）
• コミュニケーション計画（定例、各種報告）

[ 納入後について ]

• 納入後の保守サービス
• 納入後の保守体制
• 保守の方針と概要

[ その他 ]

• ユーザへの依頼事項
• 特記事項

よく紛争の元となる記載項目

• システム開発の目的と方針、メリットについての認識
• システム基本要件・基本機能
• ユーザーとベンダの役割分担概要
• コミュニケーション計画
• 開発方針

開発方針は崩れるので、崩れたらどうするのかを書いておく

開発プロジェクトを進めていれば、要件定義が予定通り完了せず、バラバラに分けてしまったり、各種イテレーション※1 で実現する機能を後ろに持って行ったりということは日常茶飯事ですが、逆に「そんなことは発生しない」という前提をもとに提案・見積もりを行うことがどれだけ不誠実かは、開発プロジェクトの経験がある方なら容易に理解できるでしょう。

工程の変更は見積もりやスケジュールを大きく変える可能性があるのに、へんこの余地について契約前にユーザーと合意しておかなかれば、ベンダーは何があってもそれを遵守せざるを得なくなるという危険な状態に陥ります。

ユーザの責任で作業の段取りを変えざる得ないような時に備え、提案書には、その特記事項として開発方針の変更についての注意書きをいれておくことが必要です。

提案内容も要件に化けるため、契約前に洗い直しをする

提案内容も同じく記載した内容は要件い化ける可能性があるため、提案内容に誤りや「書きすぎ」があった場合は速やかに訂正すべきです。 契約前の文書だからと甘く考えることは後々自分たちをの苦しみのタネとなりかねません。

1-4. 要求定義書

要求仕様書とは、ユーザがベンダに対して開発を依頼するシステム要件を文章化したものです。

こういったことがしたい、という要求と予算、開発体制、リリース時期などの記載が主で、多くの場合、実現方法が具現化していません。

内容に関して、実現性が低いものでは困りますが、あくまでユーザー側の要求なので、基本的にユーザー側は好きに書いても構いません。

要求仕様書は、システムを使う側からの要望を書き留めたドキュメントであり、ユーザーが、開発の結果、得る機能をまとめたもと言えます。

要求仕様書は、要件定義よりも前の段階でユーザーがまとめるのが普通ですが、一方で、要件定義の段階で、エンドユーザーではなく、SEがまとめることもあります。

また、システムによっては、要求仕様書の作成は行わずに、要件定義の段階で、要求仕様も含めて要件定義書として一つにすることもあります。

1-5. 要件定義

要件定義書は、システム設計者側から見た、ユーザーからの要望に応えるための機能を書き留めたドキュメントです。

要件定義書は、システム開発プロジェクトにおける要件定義フェーズのアウトプットとなるドキュメントであり、機能要件、非機能要件など、後工程の設計に必要な情報を記述します。

よって、「要件定義書の内容」＝「クライアントに確認する成果物」であるとも言えます。

一部割愛しますが、 詳細に関しては「3. 要件定義」にて触れていきます。

1-6. 役割分担

あるシステム開発を行う場合、ユーザの要件を巡ってはベンダが部署間との仲裁に入ったり、上層部に掛け合ったりする必要があったります。 「おいおい、冗談じゃないぜ。なんでウチがお客の中の意見調整をしなきゃならないんだよ」と。こんなセリフを聞くことがあります。 しかし、昨今のIT控訴における裁判所の判断を見ると、こうしたことが必ずしもベンダの「好意」ではなく、むしろ「義務」となっているのではないかと考えさせられることがあります。 判例は端折りますが、ユーザ内部の調整も、そこにシステム開発に必要な情報収集、要件の取捨選択、効率的で安全な作業順など、専門家だからこそできることを含むのであればベンダーの役割だと判断されています。

そのため、 ユーザーに行って欲しい作業がある場合は、これを明示的に役割分担表に表してユーザと合意しておく必要があります。

一般的な例を記載します。

2. 契約と法務

はじめに「業務委託契約」についてですが、 民法では「贈与」「売買」「交換」「消費貸借」「使用貸借」「賃貸借」「雇傭」「請負」「委任」「寄託」「組合」「終身定期金」「和解」の１３種類の契約について特に名前を付けて定めており、それらの契約を典型契約（有名契約）と呼んでいます。

この中に「業務委託」という名前がないことからもわかる通り、法律上、業務委託契約というものは存在しません。業務委託契約とは、請負契約と準委任契約をひっくるめた実務上の呼称なのです。

上記を理解した上で請負契約から順にみていきます。

2-1. 請負契約

請負契約とは、民法第632条に規定されている契約の形態です。

請負契約のポイントは、仕事を完成することを約する契約であるということです。

[ 民法第632条（請負） ]

請負は、当事者の一方がある仕事を完成することを約し、

相手方がその仕事の結果に対してその報酬を支払うことを

約することによって、その効力を生ずる。

成果物の納品に基づき支払う契約なります。

成果物の数量や品質についての責任をベンダが追う反面、作業の方法や作業量の多寡（タカ：多い少ない）は契約条件には含まれず、ベンダの裁量に任されます。

そのため、効率的な作業を行った時の恩恵はベンダが受け取ると認識します。

受注側に完成責任がある

受注側には仕事を完成させる責任があります。そのため、受注側から一方的に契約を破棄することはできません。

受注側に瑕疵担保責任がある

世間一般の常識として、仕事の完成には、その成果物が問題なく動作することへの期待が含まれます。

そのため、発注側は成果物に問題（民法では「瑕疵」という）を発見した場合、それを無償で修正（民法では「修補」という）することを請求したり、損害賠償を支払うことを請求することができます。

[民法第634条（請負人の担保責任）]

1. 仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、

   相当の期間を定めて、その瑕疵の修補を請求することができる。

   ただし、瑕疵が重要でない場合において、その修補に過分の費用を

   要するときは、この限りでない。

2. 注文者は、瑕疵の修補に代えて、又はその修補とともに、

   損害賠償の請求をすることができる。この場合においては、

   第533条の規定を準用する。

また瑕疵担保責任は、民法上は無過失責任とされています。

そのため、問題が生じたことについて受注側に明らかな非がなくても、発注側は修正や損害賠償を請求することができます。

発注側に指揮命令権はない

発注側に指揮命令権はありません。

そのため発注側は、「業務の遂行方法」「業務の遂行に関する評価等」「労働時間」「残業、休日出勤」「服務上の規律」「勤務配置等の決定及び変更」に関する指示を行ってはなりません。

報酬は成果物を検収した後に支払う

仕事を完成することを約した契約ですから、契約の達成は仕事が完成したとき、ということになります。 そのため、受注側から成果物の納品を受け、発注側で成果物に問題がないことを確認（「検収」という）した後、一括して報酬を支払うことが一般的です。

要件定義が重要である

「仕事を完成することを約する」ためには、最終的な完成の姿を詳細に決めておくことが重要です。

2-2. 準委任契約

準委任契約とは、民法第656条に規定されている契約の形態です。

準委任契約のポイントは、業務を処理することを約する契約であるということです。

受注側に善管注意義務がある

受注側に仕事を完成させる責任はありません。 しかし、業務を委託されるということは、専門家として業務を委託するに足る知識や経験を持っていることが背景にあり、プロフェッショナルとして一般的に期待されるレベルの注意を払うことへの期待が含まれます。 そのため受注側には、善良なる管理者の注意をもって委任された業務を処理する義務（善良な管理者の注意義務＝善管注意義務） があり、これを怠ると債務不履行責任を問われることになります。

[民法第644条（受任者の注意義務）]

受任者は、委任の本旨に従い、善良な管理者の注意をもって、

委任事務を処理する義務を負う。

発注側に指揮命令権はない

発注側に指揮命令権はありません。

そのため発注側は、「業務の遂行方法」「業務の遂行に関する評価等」「労働時間」「残業、休日出勤」「服務上の規律」「勤務配置等の決定及び変更」に関する指示を行ってはなりません。

報酬は期間ごとに支払う

「仕事の完成」という明確なゴールがないため、報酬は一定期間ごとに支払われるのが一般的です。

例えば、受注側は毎月最終日に業務報告書を提出し、発注側は内容を確認の上、翌月末に報酬を振り込む、といったものです。

業務の種類とプロセスの定義が重要である

「業務を処理することを約する」ためには、業務の種類やプロセス（どういった業務を、どのように処理して欲しいのか）を詳細に決めておくことが重要です。

実態上の条件

発注側と受注側の関係において、実態として、受注側は以下の条件を満たしている必要があります。 この条件を満たさない場合は偽装請負とみなされる場合があります。

1. 業務の処理について、事業主として財政上及び法律上のすべての責任を負うこと
2. 自らの設備や資材を使って作業を行うもので、単に肉体的な労働力を提供するものではないこと
3. 指揮命令を受けないこと

委任契約と準委任契約

１３種類の典型契約を見ると、「準委任」という名前がありません。「委任」という名前はありますが、「準委任」という名前はどこにもないのです。準委任契約もまた、法律的には存在しない契約なのでしょうか？ いいえ、準委任契約は存在します。ずばり、委任契約＝準委任契約です。エンジニアとしては、準委任契約という名前だけを覚えておけば問題ありません。 「わかった。委任契約のことは忘れよう」と思えた方は、この後の説明を飛ばして次に進んでください。忠告します。この後の説明は実務ではまったく役に立ちませんよ。

民法第643条では、当事者の一方が相手方に、法律行為を委託する契約を規定しています。この契約は委任契約と呼ばれます。事件の弁護を弁護士に委託する契約は、委任契約の典型的な事例です。

[民法第643条（委任）]

委任は、当事者の一方が法律行為をすることを相手方に委託し、

相手方がこれを承諾することによって、その効力を生ずる。

民法第656条では、法律行為でない事務の委託についても、委任契約の規定の準用を認めています。 委任契約の規定を準用した契約、という意味で、この契約は準委任契約と呼ばれます。

[民法第656条（準委任）]

この節の規定は、法律行為でない事務の委託について準用する。

法律的には、委任契約は法律行為を委託する契約、準委任契約は法律行為以外を委託する契約、という違いがあります。

しかし、準委任契約は委任契約の規定を準用しているため、委託する行為以外の違いはありません。

エンジニアが委任契約を扱うことはほとんどない（仮にあっても、そのときは法務部が一緒でしょう）ので、実務上は準委任契約という名前を覚えておけば問題ありません。

2-3. SES契約

エンジニアの能力を契約の対象とした手法です。

つまり、エンジニアを雇用する時間に対して報酬を支払う形態になります。

「作業時間についてのみ報酬が発生し、成果物に対しての責任は一切発生しない」という点が、SES契約の最大のポイントです。

つまり、契約期間に全く成果物が出せないとしても、報酬は支払わねばならないのです。

エンジニアが作り上げた成果物に対して報酬を支払う請負契約とは、大きく異なります。

2-4. 多段階契約

多段階契約方式では通常、プロジェクトの開始時点で、プロジェクト全体の基本的な条件を定める基本契約が締結されます。 基本契約には、各個別契約に共通して適用される条件（瑕疵担保責任、契約の解除、損害賠償、検収の方法、守秘義務など）が規定されますが、工程ごとの委託費用や作業期間については、別途締結される個別契約で定められることになります。

具体的には、要件定義工程が終了した段階で、要件定義工程の結果を踏まえて、基本設計工程の契約書が締結され、そこで、基本設計工程の費用と作業期間が合意され、同様に、基本設計工程が終了した段階で、開発工程の契約書が締結され、開発工程の費用と作業期間が合意されることになります。

多段階契約の方式をとる場合でも、プロジェクト開始時点で、ベンダーから見積書やスケジュール表が示され、プロジェクト全体の予算のほか、各工程の作業期間とプロジェクト全体の終了時期が示されるのが通常です。しかし、プロジェクト開始時点では、各工程の委託費用や終了時期が、契約として合意されないという点が、一括契約方式と大きく異なります。

多段階契約のメリット・デメリット

ユーザーの立場からすると、プロジェクトを始めたところ、費用や作業期間が想定よりも多くかかることが判明した場合に、そのリスクを負担しなければならないということになります。

場合によっては、プロジェクトの範囲（スコープ）の削減が必要になることもあります。

一方で、工程ごとに見積もりを行うことになるため、工程ごとの見積もりの精度は高くなり、プロジェクトの失敗リスクの低減にも繋がります。

また、スコープの見直しを工程ごとに行うということは、無駄な機能の開発をしないで済むということを意味します。

2-5. 著作権

今回の内容から割愛します。

※内容は記載しておくためお時間あるときに参照してください。

著作者の思想・感情を創作的に表現した著作物について、排他的に認められる財産的権利。

ソフトウェアの場合、設計書やpログラムなどについて認められることがあるが「思想・感情を創造的に」表現したと言えるものに限られ、それを証明することが難しい権利でもある。

著作権法では著作物を以下で定めています。

[著作権法 第二条 1 - 著作物]

著作物 思想又は感情を創作的に表現したものであつて、

文芸、学術、美術又は音楽の範囲に属するものをいう。

成果物の権利保護について著作権を頼りすぎない

条文だけを見ると設計書やプログラムは含まれないようにも見えますが、児童を経てコンピュータが社会的インフラとして地位を気づいていくようになり、その保護の対象tして次のような文が加えられました。

十の二 プログラム 電子計算機を機能させて一の結果を得ることが

          できるようにこれに対する命令を組み合わせたもの

          として表現したものをいう。

十の三 データベース 論文、数値、図形その他の情報の集合物であって、

           それらの情報を電子計算機を用いて検索することが

           できるように体系的に構成したものをいう。

プログラム、データベースが著作権の保護対象、つまり著作物であるとみと得られる道筋がついたというわけです。

設計書については特に書かれていませんが、通常の機械や建築の設計書、図面と行ったものと同じ扱いであるとの判断からここではあえて書かれていなと考えれば、やはり、保護の対象であると考えられます。

契約書で個々の権利を明確にする

ただ、実際にはプログラムやデータベース、設計書などが著作物であることを主張するのは困難な作業と言わざる得ないのが現状です。

これらはその性質上、「思想や感情を創造的に表現したもの」である必要がそもそもないものだからで、実際の判決（長いため割愛します）でも「プログラムの処理や機能が類似していることは、コンピュータの性質上も致し方ないことであり、著作権法による保護が及ぶことはない」という内容になっております。

要約した部分だけで言えば「プログラマが頭をひねって考え、工夫した成果物について、それを保護するものではない」と受け取れてしまいます。

実際のところ、現行の著作権法ではプログラマや設計者の血と汗の結晶を守ることはできないのです。

では、どのような策を考えるべきでしょうか。 プログラムその他の成果物の権利の保護が著作権法の及ぶところではないとするなら、契約書の条文で、その権利を保護することが考えられます。まずは下記の経済産業省「情報システム・モデル取引・契約書」に記載されている納入物の著作権に関する条文をご覧ください。

（納入物の著作権）

第○条 納入物に関する著作権（著作権法第２７条および２８条の権利を含む。）は甲又は第三者が従前から保有していた著作物の著作権を除き、乙に帰属するものとする。

2. 甲は、納入物のうちプログラムの複製物を著作権法第４７条の２に従って自己利用に必要な範囲で、複製、翻案することができるものとする。

この条文は、著作権を開発者側に帰属させるもので、発注者側には、「自己利用」だけを認めています。発注者が開発者の成果物を勝手に利用して商売しないように、との意図で、それなりに開発者の権利を守っているよに見えます。 しかし、これはあくまでもプログラムや設計書が、著作権法に定める著作物に当たることを前提としており、これらが思想、感情を創作的に表現しているものであると判断されれば適用されない条文になります。

であれば、いっそのこと「著作権」という表現そのものを改め、「成果物の権利」という条文を作成し、成果物の複製、翻案、再利用等の権利について発注者と開発者が各々どのような権利を持つか決め込んで行った方が現実的です。

発注者の再利用による外板、内部利用、開発者の類似プログラム製造、販売をどこまで認めていくか、禁止するか、交渉には苦労があるかもしれませんが、契約慣れした海外の商売相手も増えてきた昨今こうした権利の確保は経営自体にも関わる重大事であり、手を抜くこてゃ許されない時代ということができると思います。

2-6. 瑕疵担保責任

今回の内容から割愛します。

2-7. 下請法

今回の内容から割愛します。

2-8. 責務不履行

今回の内容から割愛します。

2-9. 無償契約

今回の内容から割愛します。

3. 要件定義

3-1. 導入の目的

システムの企画時にユーザーが定義するもので、多くはユーザの抱える課題かの解決が謳われます。「営業力強化」「コスト削減」「生産性の向上」「顧客満足度の向上」などです。 ここで謳われる内容は、経営陣に了承してもらうための材料になります。

ただ、開発を行う人間は時にこのことを忘れがちで、どれが必須でどれが見送ってもいい内容なのかを取り違えることはよくあります。 特にプロジェクトの進捗が遅延していたり不意の要件追加変更要望があり、代わりに落とす要件あるいは機能を選択する時には、既存の要件、機能のうち死守すべきものは何かということについて、ユーザー、ベンダー（開発者）、ユーザーの経営層、様々な利害関係者の中で思いがバラバラで、結果導入したシステムがユーザーに寄与しないものであったということが起こることがあります。

実際にプロジェクトの現場で「お客様」を目の前にした時、プロジェクトがうまくいかず、なんとか失点を回復したいと考えるとき、あるいは新規の要件を申し出たユーザーが影響力の大きい人間である時、さらには担当の営業担当者が横で勝手に「対応させていただきます。」と大見得切ってしまった時...ベンダの技術者は、心ならずともこうした対応をせざるを得ない場面が少なくありません。

実際の現場ではゴリ押しに負けることが多く、こうしたことが元で起こるトラブルもあります。 そしていかにゴリ押しされた結果であっても受け入れた要件は要件であり、そのために付け加えた機能は機能です。 後から言い訳はできません。

あえて正論を言うのであればシステム導入の目的に合致しない要件は採用すべきではありませんし、機能を作り込むべきではありません。

何か新しい機能を途中で思いついても、場当たり的に思いついた機能のために必要な機能を制限したり、データベースの構造を変えたりするのは本末転倒です。また、余計に定義した要件を満たせないからとプロジェクトが頓挫するようなことがあっては目も当てられません。

導入の目的と要件・機能の関係を文書化する。

もし、プロジェクト実施中に新しい要件が舞い込んできたら、それがシステうやサービスの導入目的にかなうものであるかどうかを考えるために、下記のようなワークシートを準備しておくといいかもしれません。

要件と機能と導入目的の関係を明らかにしたこの図を共有し新たな要件や機能の追加を申し出る人がいた時、その人ともに導入の目的と関連するかどうかを確認すれば要求者も自分の申し出が妥当なものであるかを確認することができます。

この図はあくまで一例にすぎません。 要は導入の目的と要件あるいは機能の関連がわかるワークシートを作成し要件の取捨選択の際に要求者も含めたメンバーで確認すれば要望を叶えられなかった要求者にも納得感が生まれまする、と言うことです。

まとめる際は以下のようなワークシートで項目を設けて書き込みを行います。

3-2. 目的達成の方針

システム導入の目的を達成するためにシステムをどのように活用するのかを明確にしたもの。

方針と機能を混同せずに、機能に振り回されない

目標達成の方針として気をつけてなければいけないことは、システムやサービスの機能に固執して目標達成を考えてはいけないと言うことです。 本来の目標からすれば機能開発に固執する理由はなかったはずなのに、いつの間にか機能開発が方針となり金科玉条になってしまったことでトラブルの原因となってしまったパターンがあります。

3-3. エンドユーザーの要望

※今回は割愛します。

3-4. 制約条件

制約条件はプロジェクト自体の努力では回避できず、どうしても考慮に入れなければならない内容です。 例えば「ユーザーのオペレーションスキルが低く、タブレットとスマートフォンしか使えない」、「接続先のシステムとの通信プロトコルはhttpsのみである」と言う内容が挙げられます。

自身の経験から制約のでそうな切り口を設定して調査する

以下のような切り口を準備し、各々でブレークダウンしながらヒアリング項目を決めていくのが良いかと思います。 下記の内容はシステム開発の制約条件が出てきそうな分野の多くをカバーしていると思います。

3-5. 前提条件

開発前、導入前に決めておく条件になります。 前提条件を定める場合は、その通りになるのかどうかを定期的に監視し、その状況によってはフレキシブルに対応することが大切です。 以下の事柄は決めておいたほうが良いかと思われます。

• 前提条件の内容
• 前提条件確定の期限
• 前提条件の状況確認者
• 前提条件の状況確認時期と方法
• 前提条件が変わった時の検討メンバと方法

3-6. 業務要件(業務の把握)

ユーザの業務自体が実現する機能を要件として整理したもの。 そもそも情報システムとは業務上の要件を満たすために構築するのですから、この後に定義するシステム要件に対して必要かつ十分なものである必要があります。 以下の図は業務フローを書きながら業務処理を明確にしたものです。

上記のような図を作ったら各部門へのヒアリングを行い、入力、出力、処理やタイミングや実施者などの情報をまとめていきます。 情報量は多いので、フォーマットや業務の切り方も実際には十人十色でしょう。

3-7. 機能要件

システムが持つべき機能を定義したもので、何を入力したら、どのように演算をして、何を出力するのかを明確にします。

様々な書き方があるが、ここでは抜け漏れ理解齟齬を原因としたトラブルを防ぐためにはどのようなことに注意すべきかを記載します。

5w1hチェックを行う

要件定義の抜け漏れを防ぐための銀の弾丸はなかなか見つかりませんが機能要件定義においては最低限、下以下の事柄に注意しておく必要があります。

(1)要件は必要かつ十分であるか

• 記載されている要件は、開発導入の目的方針に寄与するものか
• 開発や導入の目的・方針を達成するのに記載されている要件で十分か
• 記載されている派生要件は、親となる要件に寄与するものか
• 親となる要件を満たすのに記載されている派生要件で十分か
• 処理に分岐がある場合、全ての分岐を網羅しているか
• 要件と別要件との間で矛盾はないか

(2)要件は十分に細分化されているか

• 要件は設計者が迷いなく設計できる程度に細分化されているか
• 優先度最下位の要件に異なる操作者の操作・処理が混ざってないか
• 優先度最下位の要件に異なるタイミングの操作・処理が混ざってないか
• 優先度最下位の要件に異なるタイミングの出力が混ざってないか
• 他のドキュメントと整合しているか

(3)業務や例外を考慮しているか

• 例外的な業務や処理を漏れなく記載しているか
• 異常系処理を守りなく記載しているか
• 異常系の復旧とその後の処理は妥当か
• 要件に基づく業務は時間、スキル、業務規定等に照らして問題ないか

(4)要件が正しく整理されているか

• 一箇所にまとめられているか
• 要件定義書へのアクセス権限は正しく設定されているか
• 要件の管理者は明確か
• 要件変更時に影響を受ける他の要件や設計とその箇所の把握は容易か

(5)体裁・文言

• 機能要件は第三者が見ても同じ理解ができるか
• 使用している文言やコード、記号が統一されているか
• 専門用語やコードについては説明文をつけるか用語集を作成しているか

全てのチェックが困難な場合は以下のように5w1hをチェックして問題ないことを確認する方法もあります。

• この機能はいつ利用されるのか
• 誰がこの機能を利用し結果を受けるのか
• この機能を利用する場所や画面はどこか
• 論理演算や条件分岐、終了条件はどのようか
• この機能から得られる結果は何か
• なぜこの機能は必要か

3-8. 非機能要件

性能、使いやすさ、故障の少なさ、保守性の高さ、セキュリティなど、システムが具備すべき特性を要件として定義したもの。

• 機能性
• 信頼性
• 使用性
• 効率性
• 保守性
• 移植性
• 障害抑制性
• 効果性
• 運用性
• 技術要件

3-9. 用語集の作成

業務で利用している専門用語や、システムで利用している用語などをまとめた一覧になります。 初めてプロジェクトへアサインしたメンバは当然ながら用語を把握していない場合があるため、必要に応じて定義する必要があります。

3-10. 推奨環境の定義

利用する環境の定義を行います。 提供するサービス、システムがどのような環境下でスムーズに動くのかを明示的にします。

例えば下記のようにOS、ウェブサービスならブラウザの名称とバージョンを記載します。

• OSはwindows7/10
• chrome最新
• Android 5/6/7

3-11. 権限マトリクス

ある機能に対して誰が、何をできるのかをまとめた内容になります。 システム開発を行う際は制約の一つにもなるためあらかじめ定義しておいたほうが良いでしょう。 個人的に閲覧、作成、更新、削除をベースに考えます。 あとは機能ベースで例外があるので特記事項等でカバーします。

3-12. ワイヤーフレーム

画面を設計する中でいきなり、デザインツールを利用して作り込んでいくのではなく、方向性を確認する意味でもワイヤーフレームを作成し、プロジェクトメンバー内での画面イメージを共有しておくと開発はスムーズに進むでしょう。 白紙に鉛筆で今実際に行なっている要件定義をベースに自身がどのような実装をイメージしているのかを書き込んでいきます。 チーム内で実現性も含めた実装イメージを共有することが目的です。

3-13. ER図、データベースエンティティ定義書

ER図はデータベースの関係を示した図になります。 以下のような内容で表されます。

エンティティ定義書は以下のようなフォーマットでテーブルの基本情報やカラム情報などデータベースの細かい情報が記載されています。

3-14. 画面一覧

ワイヤフレームの内容を元に実際にデザインされた画面を一覧でまとめたものです。フォーマットは自由です。 最近は様々なツールが出ていますが、エクセルでまとめた内容が以下の添付画像のような内容になります。

3-15. ステークホルダー

どのような人間がプロジェクトに関わっているかを一覧でまとめたものです。 誰が何をするのかこれは役割分担の部分でも触れましたが、そもそも、どの部署の誰で、その方は普段何をしているのか、そしてこのプロジェクトでは何をするのかを定義します。

3-16. 交通整備

プロジェクト内外どのような流れでプロジェクトを進めるのかを整備します。

4. 顧客が本当に欲しかったもの

ここでは最後にヒアリング、要件定義の際に意識すべきこと、参考になる画像をもとに記載していきます。

4-1. 顧客が本当に欲しかったもの

要件定義、プロジェクト内でのコミュニケーション不足、様々な要因でシステム開発とはうまくいかないものですが、それをうまく絵で表した内容があります。

4-2. 氷山の一角

顧客の要望は実は表面的にしか話していない場合が多いです。 仮にそうでなかったとしても、実は潜在的に隠された要望があるのではないか、目的があるのではないかと考えてヒアリングすることで顧客が本当に欲しかったものが引き出せる場合がほとんどです。

実際に利用している機能だけをみて「このようにしたらいいのに」という話は実は機能をみた上での表面的な内容で、解決したい問題はもっと奥底に眠っている場合はがあります。

システム、機能ベースで要望を聞くのではなく、なぜこの顧客はこのようなことを言っているのかを一度立ち止まって考えてください。 その上で、5w1hを意識したヒアリングを行うことで「顧客が本当に欲しかったもの」が見えてくるかと思います。

顧客の要望、要求は氷山の一角と思い、奥底に眠っている本当に欲しかったものが何かを見抜きましょう。

4-3. 5W1h

5W1HとはWho（だれが）When（いつ）、Where（どこで）、What（なにを）、Why（なぜ）、How（どのように）を指し示す言葉です。

相手から要望を受けた際、単純に受け流すのではなく、上記の項目に当てはめる感じでヒアリングを行うことで精度が高まります。