テキストは3つの部分に分かれています。 最初に、そのような開発を形式化するための5つの重要なステップについてお話します。 この形式化は、これらの開発に対する会社の権利を保護するだけでなく、元従業員によるソフトウェア権利の「傍受」に関連する法的リスク、および資産としてのソフトウェアの誤った会計処理の経済的リスクも軽減します。 2番目の部分から、会社のために作成されたソフトウェア製品に対するどのような権利がプログラマーに直接利用できるかが明らかになります。 そして、第3部では、ドキュメントを正しく作成することが非常に重要である理由と、開発会社が直面するリスクについて説明します。
過去3年間の経験は、内部開発に対する企業の態度がどのように変化したかを示しています。 「ひざの上で」作成された単純なソフトウェアでさえ、独自の価値を持つ特定のエンティティとして認識されます。 一部の企業では、輸入代替ポリシーの影響を受けて内部開発の価値も高まりました。彼らにとって、ソフトウェアプログラマーのチームが独自に作成したものは、外国製品の代替品であり、多くの場合、すでに機能が非常に近くなっています。 なるべく、組織は内部開発の形式化を模索しています。これは、当社部門への関連するアピールの数で見られます。
内部開発を形式化する5つのステップ
正式化とは、まず、創造された知的活動の結果の適切な文書化を意味します。 適用法に従い、コンピュータープログラムの著作権は、その作成のまさに事実による作成の瞬間から生じることを明確に理解しなければなりません。 雇用契約に基づいて組織で働く従業員が会社のソフトウェア製品を開発する場合、そのソフトウェア製品はその職務に関連するため、会社に属している必要があり、そのために賃金やその他の種類の報酬（ボーナスとその他の補償的支払い）。 ただし、著作権法では、著作権（無形）といわゆる2つのことが区別されることを理解することが非常に重要です。 独占権（実体法、著作権の対象を処分する権利）。 そして、著作権が作成によって生じ、製品を作成した個人に属している場合、「実質的な」法律はドキュメンタリーの微調整の対象となります。 内部開発を保護するメカニズムは、5つのステップに含まれています。
最初のステップ。 雇用契約の一部として、従業員の職務を正式化し、従業員の義務には公務、コンピュータープログラム、データベースなどの開発が含まれることを強調します。 また、当事者によってすでに署名されている雇用契約を確認してください。これは、公式の作品の開発に関する条項が示されていない可能性があるモデル文書である場合があります。 この場合、開発者と追加の契約を締結します。この契約では、スペシャリストの機能的タスクに焦点を当てるとともに、会社の新たな独占権の所有権を雇用主に登録する必要があります。 また、契約では、作成されたコンピュータープログラムの使用料を支払う手順を指定する必要があります。 著作権の報酬は、賃金、ボーナス、またはその他の種類の重要なインセンティブに含めることができます。
ステップ2 コンピュータープログラムの開発のために、常にジョブの割り当てを作成します。 厳密に言えば、すべての開発はそれから始めるべきです。 ジョブの割り当ては自由形式で準備されます。 これには、開発を開始する予定の特定のプロジェクトの目標と、アプリケーションが解決される機能またはタスクの簡単な説明が含まれています。 開発されたソリューションの特定のモジュールに対してジョブの割り当てが準備され、各モジュールの完全で明確な技術タスクが含まれている場合、それは絶対に理想的です。 そのようなドキュメントが欠落している場合、進行中のプロジェクトのためにそれを開発するか、以前に開発された製品の開発のために新しいものを作成することをお勧めします。 お客様の生活を簡素化し、既製のテンプレートを提供しますが、自由な形式で書くことができます。
開発の前の段階で仕事の割り当てを作成しなかったとしても怖くありません。 製品が完成する可能性が最も高く、製品の開発時にはタスクの実践を開始するのが理にかなっています。 この場合、コンテキストから明確になるようにタスクを定式化します。以前に解決されたのは、作業中の既存のソリューションです。 仕事の割り当てが何らかの方法で策定されている場合、自分で、またはコンサルタントの助けを借りて、それらを監査することが有用です。 これは、すべてがドキュメントと整然と並んでいるかどうかを理解するのに役立ちます。 あなたは、文書を持たないあなた自身のソフトウェアが海賊版として検査当局によって認識されることを理解する必要があります。 そして、これらはどの会社にとっても役に立たない不必要なリスクです。
ステップ3 開発者（1人の場合）またはチームリーダー（開発部門がある場合）に、職務の遂行に関するメモを用意してもらいます。 これには、開発されたモジュールの機能に関する情報、または製品全体の機能に関する情報が含まれています。 また、ソフトウェア製品が動作する準備ができているという説も流通しているはずです。 実際、覚書は公式の任務の遂行の事実を記録しており、受け入れ行為に類似しています。
ステップ4 覚書に基づいて、特別に任命された委員会が、テストまたは産業用ソフトウェア製品を受け入れる可能性を分析し、合格後、受け入れ証明書に基づいて、このソフトウェアの商業運用への移行を組織するための命令が発行されます。
ステップ5 組織が製品を運用するように命じた後、ソフトウェアを貸借対照表に載せ、初期費用、耐用年数などを決定するための命令を準備する必要があります。これを行う方法 ソフトウェア機能の議論の枠組みの中で、ソフトウェアのコストに関連する推奨事項と評価を提供する専門家評議会を作成する必要があります。 専門家の推奨事項は、プロトコルの形でより適切に策定され、その後、会計に転送される必要があります。 初期費用は開発会社が独自に決定し、ほとんどの場合直接費用が直接含まれます。 ソフトウェアのコストを誇張しないでください。 登録後、会社は税金を支払う必要がありますが、これは初期費用に依存します。 会計および財務報告における組織の無形資産に関する情報の生成に関する詳細な規則は、PBU 14/2007（2007年12月27日付ロシア連邦財務省の注文番号153に付属する会計規則「無形資産の会計」）によって確立されています。
したがって、内部開発を完全に形式化するには、次のドキュメントで保護する必要があります。
1.ジョブの割り当て
2.課題について報告する
3.社内で運用するためのソフトウェア製品の受け入れ証明書
4.貸借対照表のソフトウェア声明の注文
インテリジェントかつ正しく実施された形式化プロセスは、内部開発をソフトウェア資産に変えます。 法律上および会計上の用語では、これは会社の資本化を高める無形資産をもたらします。 その無形の地位にもかかわらず、ソフトウェア資産は通常の資産と多くの共通点を持っていますが、何よりもその価値があります。 たとえば、ソフトウェア製品の非独占的権利を他の企業/ユーザーに譲渡したり、組織で使用したり、以前は自動化されていなかったタスクのコストを最適化したり、実装にかかる人件費を削減したりすることで、企業は稼ぐことができます。 この開発が高価な製品である場合、企業の資本化が大幅に増加します。
Habréでは、Rospatentでアプリケーションを登録することの重要性について繰り返し質問が提起されました。 私の意見では、Rospatentの証明書はソフトウェア製品そのものではなく、ユーザーに対する価値を決定する特性の組み合わせを記述しているため、これは非常に望ましいことです。 アプリケーションを保護するためにお金と時間を投資することで、開発を繰り返しからある程度保護できます。 重要：Rospatentは、登録時にアプリケーションの正式な検査を実施しますが、ソフトウェア製品の詳細な検査は実施しません。 したがって、ソフトウェア製品の知的保護のためのアプリケーションの適切な準備は、実際には別の話です。 同時に、現在のロシアの法律に従って、コンピュータープログラムの国家登録は必須ではありません。 つまり、Rospatentでコンピュータープログラムを登録しないと、その権利を保護できないとは言えません。繰り返しますが、著作権は製品の作成から生じたものであり、どこからでも登録されたものではありませんだった。
通常の開発者は何を期待できますか？
これはプログラマーにとって非常によくある質問です：「作成者として、私が書いたアプリケーションを形式化することでどのようなメリットが得られますか？」 ほとんどの場合、作成者はすでに行われた作業に対して報酬を受け取っており、作成したソフトウェアの所有権はもはやないため、金銭的なメリットはありません。 非所有権により、自分のエゴを楽しませ、ポートフォリオにプロジェクトを追加できます。 たとえば、開発者はソフトウェアの名前を提供する権利があり、アプリケーションのコンテキストで名前を示すことができます。 ただし、著者の名前を示す権利、または名前を示さない権利は、前述の雇用契約にも準拠していることに注意してください。 また、複数の人を含む人格権が適用されることに注意してください。つまり、製品には複数の著者がいる場合があります。
開発段階またはその後3年以内に、雇用主がソフトウェア製品が商業的秘密であると発表した場合、ソフトウェアに関する情報を開示することは禁止されていることに注意してください。
紙の仕事が重要なのはなぜですか？
同僚と私は、顧客企業の所有者やトップマネージャーが、開発チームが作成したソフトウェアや目的を知らない状況に直面することがよくあります。 このようなソフトウェアに関する情報は、ソフトウェア資産管理手順の最初の段階で、特別なツールが顧客企業のサーバーとPCをスキャンするときに取得されます。 そのような「アーティファクト」を発見したので、私たちは責任ある従業員と一緒に必要な文書を提出し、少なくとも内部開発に直面していることを理解しています。
会社が、ライセンスを確認するドキュメントがない、理解できない「左」ソフトウェアを検出するチェックを受け取った状況を想像してください。 この場合の「これはプログラマが開発したものである」という正当性は機能しません。サポート文書が必要です。 それらがなければ、企業は状況が明らかになるまでハードウェアとソフトウェアの押収に直面するかもしれません。 同社は遅かれ早かれ、このソフトウェアが独自の開発であることを証明する可能性がありますが、それに費やされる力と時間は、企業が被るビジネス継続性に対するリスクと比較できません。 結論ではなく、そのようなホラーストーリー。
ご質問がありましたら、コメントを書いて、お答えします。