システム開発の現場では、いろんな言葉があり、それぞれに大きな意味を持つことがよくあります。
例えば「要求」と「要件」は一見似た様な言葉ですが、システム開発の現場では明確に違うものとして認識されています。
今回はそんなシステム用語についてまとめてみたいと思います。
また、システム開発を依頼する側が見聞きするであろう言葉に限定しています。
エンジニア同士で暗黙知としてある言葉はエンジニアという生き物同士の意思疎通でしか使えなかったり、闇が深いので割愛させていただきます。
「宣言」と「定義」の違いであったり、「技術的には可能です」は「現実的には無理です」の意味で使われているなど、。
はじめに
最初にシステム開発のやり方や、プロジェクトの進め方などは人員のスキルやリソースなどによって開発会社ごとに最適化されています。
合わせて用語の意味についても変化していることがあり、それ自体は間違っていませんし、むしろそうあるべきです。
ここで紹介する意味についても極力一般的にはそう解釈されている程度で書いていますが、実は先駆のみでそう認識しているだけの可能性もありますので、ご承知ください。（免罪符
また、コミュニケーションしながらプロジェクトを進める以上、言葉の認識の違いによるトラブルは避けては通れません。
弊社でもシステム開発の全体像から詳細工程まで齟齬がない様、都度ご説明しながら進めていますので、不明な点がありましたら持ち帰らず、その場でお気軽にご確認ください！
プロジェクトの走り出しに使う「なんとなく同じ」っぽい用語
要求 vs 要件
先ほど例にあげた「要求」と「要件」です。
「要求」はシステムを導入したいお客様やそれを使うユーザがやりたいことを指します。
開発の現場では要求整理と呼んだり、そういったものがない場合はヒアリングを通して整理します。
一番イメージしやすいかと思いますが、「こういうシステムがほしいなぁ」ということを書き溜めたものになります。
「要件」はシステムが実装すべき機能や性能を指します。
これだけだと違いが分かりにくいかもしれませんが、お客様やユーザからいただいた「要求」の状態ではシステム化で解決する課題と、そうでない課題が存在します。
「従業員の意識を向上させる」など抽象的であったり、システム化が難しい内容や、「年に1度の軽い業務」など、そもそもシステム化は行えるけど開発・維持するコストより、人が行う方がコストとパフォーマンスに優れている場合があります。
このシステムで行う箇所と、人（運用）で行う箇所を整理して、システムがどうあるべきか決めるのを「要件定義」と呼びます。
以上のことから「要求はお客様目線でほしいもの」、「要件はシステムとして実装する対象」を指しているため、「なんとなく同じ」っぽいけど違うものということがわかるかと思います。
制約条件 vs 前提条件
プロジェクト憲章やプロジェクト計画書の作成によく出てくる言葉になりますが、正直自分も時々意識せずに使ってしまうことがあります。
そのぐらいニアな意味ですが、意味を知らないと優先度のズレが発生し、予算配分などに影響を与えます。
「制約」とは予算、納期などの必ず守らなければいけない縛りを指します。
この中には使用する技術スタック、例として「既存のシステムと揃えるためGPS座標を使った距離計算はデータベースの関数を使用する」「別プロジェクトで開発中のシステムとユーザ認証を共通化する」なんていうのも明記されたりします。
「前提」は仮定とした状態で進める条件になります。
プロジェクト開始時のため、実際にはまだシステムは存在していないですが、OSの種類やバージョン、上記の例で言うところのデータベースはMySQLを使用するなどが記述されています。
他にも「関係する外部システムが稼働していること」など、外的要因がある場合は責任がないことを明記するのに使用します。
「制約」は文字通り守らなければいけない度合いが強く、「前提」は比較すると変更があるかもしれない内容が含まれています。
一概には言えませんが、「制約」はお客様から提示されている条件で、「前提」はこれから作るシステムに必要な条件として開発側が提示するケースが多いです。
見積もりで考えると、お客様から頂いた費用の「制約」の中で、こういう「前提」であれば費用内で作れます、といったイメージです。
設計・開発時に使う「なんとなく同じ」っぽい用語
仕様 vs 設計
「仕様です」といったパンチラインについてはどこかで目にしたことがあるかと思います。
これも混同しやすい言葉で、ドキュメント作成時もどこまで記述すべきかわからなくなることが多いです。
「仕様」とは何を作るかを決めることを指します。
仕様書にはシステムの振る舞いについてであったり、画面の項目やボタンを押したときの挙動などが記述されています。
「設計」とはどう作るかを決めることを指します。
設計書にはより具体的になクラス群に機能を追加することや、どういったテーブル構造を持っているかなどが記述されています。
とても境界線が曖昧になりがちですが、これを読むターゲットを意識すると分かりやすいと思います。
「仕様」はお客様の承認をもって作成されるため、お客様がわかる範囲で記述されるべきです。
「設計」はこの後の実装を行う開発者に対する指示書に近いものです。
開発規模によっては外部設計・内部設計、基本設計・詳細設計のように上記の切り分けに対応しないこともありますが、どちらも結局はお客様向けか、開発者向けかで判断できます。
これらを混同するとお客様を置いてけぼりにしてしまったり、開発者側から具体的な実装手順がわからないなどのトラブルが発生します。
また別の角度でありがちなのが「どうつくるか（設計）」の議論を先にしてしまい、「何のためにつくるのか（仕様）」を見失い、お客様に求められてもいない技術的な説明や提案を行ったり、「仕様」が決まれば自然と「設計」が決まるものだったなど、スケジュールが押したり無駄な労力が発生することです。
経験値がないとなかなか判断できないので、開発会社側がしっかり今議論すべき内容はなんなのかハンドリングして、技術的な議論が深入りするなら持ち帰って整理してから提示するのが大事です。
修正 vs 改修
開発か運用か悩みましたが、開発の方に記述したいと思います。
システムを実際に作っていく中で、プログラムコードを書き換える作業としては同じですが、意図が違うため、状況によっては言葉の重さが変わります。
「修正」とはバグや間違いを直すことを指します。
思っていた通りの動作にならなかったり、計算結果が想定と合わないなどの問題を解決する作業です。
「改修」は機能追加や性能向上のために手を加えることを指します。
問合せ機能の追加であったり、処理速度向上のためにデータの整理などをおこなったりする作業です。
極端な例ですが、明日リリースという状態で「修正中」であればまだ間に合う感がありますが、「改修中」だと間に合わない可能性があります。
というのも追加された機能は検証を行い、その中で不具合があれば「修正」を行う時間も必要になるからです。
また「修正」は瑕疵担保責任の範囲で行われることが多く、「改修」はより良くするための費用を頂きながら行う作業でもあります。
なので「こういう動作をしているのは仕様？」といったやり取りの中で、これから行う作業は「修正」なのか「改修」なのかは直接費用に関する話になるため、お互いに言葉の使い分けを慎重に行うべきです。
テスト・運用時に使う「なんとなく同じ」っぽい用語
検証 vs 妥当性確認
今回紹介している言葉の中でも一番といっていいほど開発会社ごとに呼び方が変わるかと思います。
単純に意味として分けずにテストと呼んでいたり、システム納品時の検収（けんしゅう）を妥当性確認とするといった考えがあると思います。
弊社でも検証を社内テスト、妥当性確認についてはお客様確認と呼んでいます。
体制や費用感、伝えやすさなどから変化しているため、どれでも間違いではないです。
ただ説明する上で分かりにくいので「検証（Verification）」と「妥当性確認（Validation）」で分けて解説します。
「検証（Verification）」は設計通りに動くかを行います。
先に説明しましたが、設計書は開発者に対して作成されるドキュメントで、その設計書通りに正しく作られているかを確認する作業になります。
単体テストや結合テストといったエンジニアが（開発会社からみて）内部的に行うテストを含んでいます。
「妥当性確認（Validation）」は要件に適った動作をするかを行います。
要件定義において、お客様からの要求のうちシステム化する範囲を決め、作るシステムについて定義を行います。
その定義されたシステム通りに動いているかを確認する作業で、お客様も一緒に行っていただく（開発会社からみて）外部的に行うテストになります。
お客様のイメージ通りのシステムになっているかの確認です。
なぜ分かれているかというと、システム開発にはたくさんの工程と人が関係しており、それぞれ伝言ゲームのようにシステムを定義して設計し、開発しています。
その中でどうしても認識のズレであったり、ミスが発生してしまうことがあり、「検証（Verification）」については工程ごとに行い、すぐに問題を見つけられる様にしています。
「妥当性確認（Validation）」だけにすると、リリース直前に認識のズレが見つかって修正する時間や後戻りするコストが膨大になってしまうため、「検証（Verification）」を行っています。
保守 vs 運用
「保守」は壊れたものを直す、アップデートを行うことを指します。
操作ミスによってシステムが壊れた場合はバックアップから戻したり、WordPressであればCMSのアップデートが該当します。
「運用」はシステムが日々止まらないように動かし続けることを指します。
サーバーやドメインなどの契約管理や、日頃のサーバーの負荷を監視したり、メンテナンスを定期的に行ってシステムの動作を安定させることも含まれます。
これも混同しがちですが、「保守」は計画外の要因で発生する作業、「運用」は計画されている作業で捉えるとイメージしやすいかもしれません。
先駆ではどちらもシステムとして欠かせないものという認識のもと、「保守」・「運用」はセットで商品提供しています。
開発会社によっては分けて提供していたり、そもそも制作のみで「保守」・「運用」を提供していない会社もあったります。
レンタルサーバーであれば「運用」にお金を払っており、「保守」をサポートとして別途費用を出すか、「保守」を担当してくれる会社と契約を行ったりします。
すでにシステムに対するサポートを受けている場合は、いざという時にどこまで対応してくれるのか把握しておくことが今できるトラブル対策かと思います。
さいごに
以上、ここまで読んでいただき、ありがとうございました。
システム開発の現場では常識かもしれない言葉でも、他の業界では全く違う意味で使われているケースが結構あります。
その場合は無理にシステム開発の用語として使用せずに、お客様の業界用語を避けながら別の呼び方でプロジェクトを進行するほうがコストが低いです。
用語の管理も積極的に行うことで、システム開発を理解してもらうのと同時に、その業界の解像度をあげるためにも開発会社とお客様両方で用語の管理を更新していくことがプロジェクトの成功につながります。
一見言葉が通じたとしても油断せずに、認識があっているかどうかも確認していくことが大事かと思います。
弊社でシステム開発を発注いただいているお客様や、すでにサポートを受けている方も不明な用語がありましたら、お気軽にお問い合わせ頂けたらと思います。
