お〜い！フリーランスのみんな！請求書のハンコって全然意味ないらしいよ！ - ジモコロ
いきなり結論を言いますと、請求書は原本を郵送する必要がありません。そして、ハンコも押す必要がありません。意外と知られていない形骸化したハンコの悪習が途絶えますように… 請求書に関する作業、面倒くさすぎ問題 「請求書」 それは生きていくために必要な「これだけ仕事したからお金ちょうだいな」という証明になる大事な書類です。 です、が。あ、この人、ハンコがない、もらい直さなきゃ…あの人からはもらった、あの人からも届いている、こちらが送る分はハンコを押し忘れたやつがあったから再送してくれという連絡が…。 は〜〜〜〜〜〜〜〜 も〜〜〜〜〜〜〜〜〜〜〜〜〜 めんどくせええええええええ！！！！！ 請求書の作業めんどくせ〜〜〜〜わ！！大事は大事なんだけど何でいちいち「印刷」して「押印」して「郵送」しなきゃいけねえんだよ！！受ける側も送る側も面倒くさすぎるだろ！ 会社だったらまだ幾分かマシだけど、フリーランス
なぜ、ソフトウェアは著作権で保護されているのか？
ITプロフェッショナルにとっての知財関連知識の中でも、「著作権によるソフトウェア（コンピューター・プログラム）の保護に関する理解」はとりわけ重要だ。 外注先が開発したソフトウェアの著作権は誰に帰属するのか、開発委託に際してどのような契約を行なうべきか、契約違反があった時にはどのような対策がとれるのか等々、正しい理解が無いと思わぬ結果を招きかねない（実際、正しい理解が欠けていたことで問題となり、裁判にまで持ち込まれた事例も存在する）。 今日では、ソフトウェアが著作権で保護されることは常識となっている。例えば、違法に複製されたソフトウェアの販売や、ネットへのアップロードを行なった人が警察に逮捕されたといったニュースを耳にすることもあるだろう。 しかし、そもそも、なぜ、ソフトウェアを著作権で守られなければいけないのだろうか？ この根本的な問題を考えてみることは、現在の制度の意義と仕組みを理解する
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
どこの出版社で本を出すのか - www.textfile.org
どこの出版社で本を出すのか、ということはけっこう問題だ。最初のうちは選択の余地はない。それに、担当者と親しくなると、「ほかのところで」とは言いにくくなるだろう。しかし、ビジネスというのは、やはりシビアでなければならない。たとえば、Ａ社で出すよりもＢ社の方が明らかにメリットがある、というケースは多い。簡単な例でいえば、発行部数が全然違うとか、売り方が違うとか、印税率が違うとか、である。作者へのメリットはもちろんだが、読者に対しても、たとえば沢山部数が出る方が手に入りやすく、より大勢の手に届くことになる。 http://blog.mf-davinci.com/mori_log/archives/2008/10/post_2207.php 森博嗣氏による。 そういえば森氏は以前「御社で出版したら（御社にとってではなく）著者の私にどういうメリットがありますか？」という質問をするという話をどこかに書
偽装請負から身を守るための法律知識 － ＠IT自分戦略研究所
チームフォレスト 2008/6/12 前のページ｜1 2｜ ■ITエンジニアが、不利益を回避する方法 実際に偽装請負と判断された場合、1年以下の懲役または100万円以下の罰金を科せられる可能性がある。偽装請負は先に挙げたように、業務請負に見せ掛けた労働者派遣と解釈されるため、罰則は労働者派遣法に則する。罰せられるのは企業側であり、不当に働かされていたITエンジニア個人が罰せられることはない。ITエンジニアが被る不利益は法律的な処罰ではなく、労働の中で当然与えられるはずの権利が保障されない状態に陥ってしまうという点である。 こういった事態を避けるためにも、各契約形態がどのような側面を持ち、民法上でどのように区分されているのかを正しく理解しておくことが必要だ（表2）。
フリー技術者に朗報か否か、首都圏コンピュータがJV方式導入 － ＠IT
2008/03/10 フリーランスのITエンジニアを支援し、開発業務の共同受注を行っている首都圏コンピュータ技術者株式会社（MCEA）は3月10日、同社とフリーのITエンジニア、そしてシステム・インテグレータ（SIer）とがジョイントベンチャーを組んで、開発業務を共同受注する取り組みを新たに始めると発表した。これまで個人事業主であるフリーエンジニアとMCEAとの共同受注だけだったが、新たにSIerとも手を組み、より大規模な開発案件を受注できるようにする。同社はこのジョイントベンチャー方式によってIT業界の悪弊といわれる多層請負構造が構成できなくなるとしている。 MCEAは当初、個人事業主のフリーITエンジニアによる協同組合だったが、協同組合法の改正によって組合員が1000人以上の協同組合は「上場企業以上の透明性が求められるようになった」（MCEA 代表取締役会長 横尾良明氏）ことで、200
ソフトウェアの受託開発に関する税務についてです。…
ソフトウェアの受託開発に関する税務についてです。 6/1 開発着手 ↓ 7/30 決算 ↓ 8/20 開発、検収完了。 ↓ 8/25 請求書を9末までに支払ってもらうように発行。 このような場合、売上計上はいつの時点ですべきでしょうか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
