До какой степени законно реализовывать функции, которые не указаны в техническом задании на разработку системы?

Проекты по разработке IT-систем, используемых в компаниях, в принципе, создаются в соответствии с заранее определенными спецификациями. Однако, с другой стороны, если учесть, что вендору как специалисту в области разработки систем полностью доверяют разработку, ожидания со стороны пользователя могут быть не так низкими, как если бы он просто механически реализовывал то, что написано в спецификации. В этой статье мы обсудим, в какой степени должна быть взята на себя обязанность реализации программы, которая, хоть и не указана в спецификации, но необходима с точки зрения целей разработки.

Юридические проблемы, связанные с реализацией неспецифицированных элементов

От поставщика требуется усмотрение

Одной из особенностей контрактов и различных юридических вопросов, связанных с проектами по разработке систем, является то, что поставщику, который принимает работу, требуется большое усмотрение.

Связанная статья: Обязанности управления проектами в разработке систем[ja]

Однако, “усмотрение”, о котором идет речь здесь, не всегда применимо ко всем этапам разработки систем. После определения каждого этапа и детализации задач, многие из них могут стать близкими к простым операциям. Однако, в общем, чем более высокоуровневыми становятся задачи, тем сложнее их выполнение без большого усмотрения. Это также объясняет, почему контракты на высокоуровневые задачи часто лучше всего подходят для делегирования.

Связанная статья: Различия и различия между контрактами на подряд и делегирование в разработке систем[ja]

Усмотрение также должно проявляться в строгом процессе разработки

Однако, даже если у поставщика, разрабатывающего систему, есть большое усмотрение, бездумное принятие требований клиента может привести к серьезным последствиям в последующих этапах. Один IT-система состоит из множества мелких компонентов, и даже незначительные изменения внешнего вида могут потребовать значительных изменений в рабочем процессе со стороны разработчиков. В связи с изменением спецификаций разработки систем, есть статьи, объясняющие, как управлять изменениями с юридической точки зрения. Следующая статья объясняет, как управлять изменениями, и обсуждает, насколько сильно изменения спецификаций могут повлиять на работу с точки зрения инженера.

Связанная статья: Как управлять изменениями в разработке систем с юридической точки зрения[ja]

Что должен делать специалист, не ограничиваясь спецификациями?

Для успешного продвижения проекта по разработке систем важно заранее определить требования к разработке и планомерно продвигаться в соответствии с ними. С другой стороны, есть ситуации, когда просто следование заданным требованиям и выполнение только того, что вам говорят, не позволяет вам полностью выполнять свою роль как специалиста по разработке систем. В этом дилемме встает вопрос: “Что следует реализовать, даже если это не указано в спецификациях?”

Юридические обязательства определяются в соответствии с “сутью” технического задания или договора

Содержание того, что должно быть реализовано, определяется не только на основании записей в договоре или техническом задании. Даже если в них нет прямых указаний, важно учитывать “суть” этих документов, то есть “с каким смыслом или намерением было принято это решение”. Давайте рассмотрим несколько судебных прецедентов ниже.

Судебный прецедент, в котором обязанность реализации была отрицана из-за отсутствия упоминания

В приведенном ниже судебном прецеденте, система, разработанная поставщиком, дошла до стадии тестовой эксплуатации, но из-за недостатка необходимых функций возник спор о расторжении контракта. Пользователь утверждал, что отсутствует функция “автоматического обновления данных”, которая, по его мнению, является ключевым продажным аргументом данной системы, однако суд не признал эту обязанность реализации.

Как было установлено выше, в контракте, а также в основном и детальном проекте, нет упоминания о том, что функция ③ является объектом разработки данной системы.

Истец утверждает, что функция ③ была ключевым продажным аргументом системы, предлагаемой ответчиком истцу, и подчеркивает необходимость этой функции, но если бы это было так, это должно было быть ясно указано в контракте, и трудно представить, что разработка этой функции была согласована, несмотря на ее отсутствие.

Решение Токийского окружного суда от 18 февраля 2009 года (Heisei 21)

Действительно, если выделить только вывод из этого решения, можно сказать, что “если это не указано в проекте, то не нужно создавать то, чего нет”. Однако, более точно говоря, решение было принято не на основе формальных фактов, таких как наличие или отсутствие упоминания в проекте, а с учетом “смысла” упоминаний в проекте и контракте. То есть, “если учесть причины, по которым это не было указано в проекте или контракте, то разумно предположить, что не было согласия на соответствующее упоминание”.

Судебные прецеденты, подтверждающие обязательность реализации, даже если она не указана

С другой стороны, есть судебные прецеденты, которые подтверждают обязательность реализации, даже если она не указана в договоре или техническом задании. Приведенный ниже прецедент относится к разработке системы для управления историей приема лекарств, где не удалось перенести данные из существующей системы в новую, что привело к тому, что пользователь не смог использовать новую систему и расторг договор. Однако, поставщик утверждал, что перенос данных выходит за рамки его обязанностей, что привело к спору.

Разработка новой системы часто включает в себя устранение существующей системы и перенос данных. Мы подробно обсуждаем важность этих задач и связанные с ними юридические вопросы в статье по ссылке ниже.

Связанная статья: Юридические вопросы, связанные с переходом от старой системы при разработке системы[ja]

В существующей системе уже сохранены данные более 50 тысяч пациентов, и истец использовал эти данные для повышения эффективности работы. Если данные пациентов не могут быть перенесены из существующей системы в новую, это очевидно приведет к проблемам в работе аптеки, и представитель истца, безусловно, должен был осознавать это. И, как уже упоминалось выше, представитель истца, понимая, что ему придется вручную вводить данные более 50 тысяч пациентов, вряд ли решится на внедрение новой системы. Кроме того, как указано в пункте (1) И, ответчик, не смог перенести данные о приеме лекарств из существующей системы в новую, и вместо этого печатал эти данные на бумаге и вводил их в PDF-файлы. Несмотря на то, что в договоре не предусмотрен перенос данных, вряд ли можно предположить, что ответчик предложил такую трудоемкую услугу.

Решение Токийского окружного суда от 18 ноября 2010 года (Heisei 22)

Здесь также важным является цель договора и “суть” условий договора. Если обе стороны заключили договор, понимая, что перенос данных выходит за рамки обязанностей, то это указывает на то, что обе стороны заключили договор с неестественными намерениями. То есть, пользователь согласился на выполнение огромного объема ручной работы, а поставщик, зная, что это приведет к проблемам в работе пользователя, все равно приступил к проекту, что крайне нелогично.

Что мы можем понять из обоих решений

В контексте переноса данных, даже если в контракте или техническом задании не указано, обязательство по реализации было подтверждено. Одной из причин этого, по-видимому, было то, что речь шла о “данных”, которые не отображаются на экране. Предыдущее “отсутствие обязательных функций” напрямую отображается на экране системы. Поэтому, даже если вы новичок в разработке систем, обнаружение пропусков в техническом задании не является особенно сложной задачей. С другой стороны, проблема переноса данных имеет особенность, что для новичков в разработке систем сложно осознать важность этого процесса, сложность работы и количество труда. Поэтому, можно предположить, что были обстоятельства, которые делали легче обрабатывать этот вопрос как вопрос, который сторона поставщика должна была гладко координировать с профессионализмом.

С этой точки зрения, пропуски в техническом задании или контракте могут быть связаны с “обязанностью сотрудничества” пользователя. То есть, вопрос в том, действительно ли пользователь выполнил свою “обязанность сотрудничества” в заключении контракта и создании технического задания. Общее объяснение юридических обязанностей, которые должен выполнить пользователь в проекте разработки системы, подробно рассматривается в следующей статье.

Связанная статья: Обязанность сотрудничества со стороны пользователя, который является заказчиком разработки системы[ja]

Если вы также проверите статью выше, вы, вероятно, согласитесь, что обсуждение пропуска в рассмотрении переноса данных сильно отличается от областей, где требуется большое сотрудничество со стороны пользователя, таких как выявление экрана и обязательных функций.

Как следует относиться к вознаграждению за разработку, которая не указана в техническом задании?

В связи с темой этой статьи, возникает вопрос: разрешено ли законом требовать дополнительное вознаграждение за создание чего-то, что не указано в техническом задании? Вопросы о возможности увеличения вознаграждения и методах расчета стоимости в таких случаях подробно обсуждаются в следующей статье.

Связанная статья: Возможно ли увеличение оценочной стоимости разработки системы после факта?[ja]

В вышеупомянутой статье объясняется, что важно определить, была ли работа, превышающая объем работы, соответствующий вознаграждению. То есть, если говорить о связи с этой статьей, если поставщик согласился на разработку, которая не включена в первоначальные спецификации (в контексте этой статьи, отрицательный пример), то он может требовать дополнительное вознаграждение.

Заключение

В разработке систем, роль поставщика определяется, с одной стороны, содержанием контракта и технического задания. Однако, учитывая, что специалистам доверяют выполнение работы на основе высокого уровня доверия, становится понятно, что их реальная роль не определяется исключительно формальностями. Тем не менее, для понимания этой сути, следует понимать, что закон играет важную роль.