Возможно ли увеличение сметной стоимости системной разработки после факта?

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

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

В каких случаях можно говорить о дополнительной разработке или исправлении функций?

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

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

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

• Если после утверждения спецификаций вам приказано добавить дополнительные функции
• Если вам приказано исправить программу после ее реализации

В таких случаях, ваше утверждение может иметь определенную законную силу.

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

Положительный пример: случай, когда спецификации базового дизайна были изменены после факта

В следующем примере были внесены изменения в спецификации после факта.

Разработка программного обеспечения происходит через этапы разработки, включая ① определение требований, ② внешний дизайн, ③ внутренний дизайн, ④ создание исходного кода программы (дизайн программы, кодирование), ⑤ различные тесты (тестирование модулей, комбинированное тестирование, системное тестирование) (пропуск)… Исходные спецификации (пропуск) реализуются через работу, начиная с внутреннего дизайна, и это является областью работы, связанной с отношением между правом на вознаграждение на основе настоящего контракта на разработку и оплатой.
Предложение об изменении спецификации, с юридической точки зрения, рассматривается как предложение о новом контракте на разработку, превышающем рамки работы, основанной на первоначальном контракте, и если подрядчик не представляет сумму дополнительной оплаты за работу и завершает работу, связанную с дополнительным поручением, без согласия на сумму дополнительной оплаты, то считается, что был заключен новый контракт на выполнение работ без определения суммы оплаты, и обязательство по оплате соответствующих дополнительных расходов на разработку возникает, что считается разумным.

Решение Осакского окружного суда от 29 августа 2002 года (Heisei 14)

Ключевые слова, такие как «отношение оплаты» и «новый контракт», помогут углубить понимание этого решения.

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

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

Решение Осакского окружного суда от 29 августа 2002 года (Heisei 14)

В тексте решения использовалось интересное слово «детализация спецификации».

• Случай, когда то, что должно было быть уже определено, было пересмотрено позже
• Случай, когда то, что можно было бы определить по ходу дела, было специально не определено и продолжено

Следовательно, можно сказать, что это показывает мысль о том, что правовое обращение также должно отличаться.

Другие положительные примеры

Среди других случаев, признанных как дополнительная разработка или исправление функций, есть:

• Случай, когда количество программ, поставленных по сравнению с первоначальным планом, увеличилось примерно вдвое (Решение Токийского окружного суда от 22 апреля 2009 года (Heisei 17))
• Случай, когда срок выполнения работы увеличился примерно в три раза (Решение Токийского окружного суда от 22 января 2010 года (Heisei 22))

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

«Соглашение о дополнительной разработке или увеличении оплаты» и «заключение первоначального контракта» – разные вопросы

Важная точка в отношении этих вопросов:

1. «Был ли официально заключен контракт (первоначальный контракт) о разработке системы между двумя компаниями вообще?»
2. «Был ли заключен дополнительный контракт (также) о дополнительной разработке в отношении системы разработки, которая была официально заключена однажды?»

Критерии суда отличаются в этих ситуациях. Говоря простыми словами, суд:

• имеет строгую тенденцию в отношении 1 (он редко признает заключение контракта в ситуациях без контракта)
• имеет относительно мягкую тенденцию в отношении 2 (даже если нет контракта о дополнительной разработке, он гибко признает увеличение оплаты)

Подробнее о 1 я объясняю в другой статье.

https://monolith.law/corporate/system-development-contract[ja]

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

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

Спор в данном случае заключается в следующих вопросах: (1) каково содержание работы, которую истец принял на себя в рамках данного контракта, (2) было ли достигнуто соглашение о расширении масштаба и увеличении оплаты в отношении этой работы между истцом и ответчиком, (пропуск)… (пропуск).

Во-первых, данный контракт является контрактом на выполнение работ, в котором было согласовано, что сумма оплаты является окончательной оплатой за работу, принятую на себя истцом, и количество шагов, цена за единицу и т.д. являются лишь внутренними документами истца для расчета суммы оплаты за выполнение работ, и увеличение количества шагов и т.д. не имеют никакого отношения к оплате за выполнение работ. (пропуск)

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

Решение Токийского окружного суда от 12 июня 1995 года (Heisei 7)

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

В конечном итоге, считается, что для работ, которые не включены в это, признается право на дополнительное требование оплаты, учитывая, на какую работу была установлена сумма оплаты.

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Как определяется размер вознаграждения за дополнительную разработку и исправление функций

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

В таких случаях следует обратиться к статье 512 Японского коммерческого кодекса (подчеркнутое – мое).

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

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

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

Случай 1: Признание дополнительного вознаграждения, пропорционального увеличению трудозатрат

Справедливо считать, что трудозатраты на разработку на основе изменения спецификаций в этом случае составляют общую сумму указанных трудозатрат, равную 257,5 человеко-дней, и если пересчитать это по стоимости разработки в 32 500 иен за человека в день (в контракте на разработку в этом случае стоимость составляет 650 000 иен за человека в месяц, и если считать, что число рабочих дней в месяце составляет 20 дней, стоимость разработки за человека в день составляет 32 500 иен), то справедливо считать, что дополнительные затраты на разработку на основе требования об изменении спецификаций составляют 8 368 750 иен.

Решение Осакского окружного суда от 29 августа 2002 года (Heisei 14)

Ключевое слово здесь – “за человека в день”. Это показывает, что для расчета дополнительного вознаграждения используются трудозатраты.

Случай 2: Признание дополнительного вознаграждения, пропорционального количеству программ

При рассмотрении суммы соответствующего вознаграждения, включая дополнительную часть в этом случае, учитывая, что большая часть себестоимости разработки компьютерной системы состоит из зарплаты технического персонала, и что эта зарплата в общем соответствует объему программ, которые нужно создать, следует признать, что справедливо умножить количество программ, прошедших третью проверку, 414, на стоимость одной программы, полученную путем деления первоначальной контрактной суммы в 23 250 000 иен на количество программ, завершенных до второй проверки, 206, что составляет 46 725 728 иен (23,250,000 ÷ 206 × 414 = 46,725,728).

Решение Токийского окружного суда от 22 апреля 2005 года (Heisei 17)

Здесь много цифр, но если вы спокойно прочитаете, вы увидите, что не делается сложных расчетов. Основываясь на первоначальном контракте, они просто подтверждают “сколько стоила программа за единицу”, а затем делают простое умножение “цена за единицу × количество”.

Случай 3: Признание дополнительного вознаграждения, пропорционального продолжительности периода

Таким образом, учитывая, что в контракте А3 было установлено, что вознаграждение за работу в качестве заместителя в течение трех месяцев с января по март 2005 года составляет 60 000 000 иен, и что работа, проведенная после апреля того же года, включает в себя работу, выполненную бесплатно, с другой стороны, предполагается, что объем работы увеличивается после апреля того же года, когда система регистрации курсов и т.д. начинает работать с началом нового учебного года, как и в предыдущем году. Исходя из этого, справедливо считать, что вознаграждение за работу в течение шести месяцев с апреля по сентябрь 2005 года составляет 120 000 000 иен, основываясь на 60 000 000 иен, установленных в качестве вознаграждения за работу в течение трех месяцев.

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

Вышеуказанное решение указывает на то, что дополнительное вознаграждение рассчитывается на основе простого пропорционального расчета для продленного периода.

Заключение

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

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