システム系とＷｅｂ系それぞれの仕事の進め方や考え方といったことは、私が書くよりもそれぞれの分野の方からお互いに話を聞いていただくほうがよいと思います。
ここでは、どのような点に注意すべきか、どのような問題が起こり得るか、ということをいくつか考えてみたいと思います。
2016年12月26日月曜日
2016年12月19日月曜日
システム系とＷｅｂ系の連携の注意点（前編）
様々なビジネス展開を考える際に、他業種（異業種、異分野）の企業等と連携することが出てきます。
‘連携’という言葉は使わなくても、例えば「何かおもしろいこと一緒にやりましょう！」という感じで始まるようなものも含みます。
例えば、モノ作り企業がデザイナー（デザイン事務所）と連携して商品開発するようなケースです。
産学連携と呼ばれる、企業と大学（の研究者）もそうです。
あるいは、システム系の会社とＷｅｂ系の会社が連携するケースもあります。
2016年12月12日月曜日
その「契約」は、成立していますか？ ～ 契約成立・不成立の‘境目’
システム開発契約等のＩＴ契約においては、全体としては請負契約にしておくほうが、業務の内容（範囲）を明確にすることになり、その点においては受注者（ベンダー、開発）側にメリットがあります。
但し、請負契約の場合には、「仕事の完成」の内容を明確にしておく必要があります。
これが不明確だと、後々に争いになった場合に、請負契約とは認められなくなります。
2016年12月5日月曜日
「瑕疵」と「仕事の完成」の認識（後編）
（前編からのつづき）
システム開発等における「瑕疵」の問題に関連し、システム開発等における「仕事の完成」の認識が問題になります。
請負契約では、「仕事の完成」に関する合意が契約成立の一つの要件になります。
2016年11月28日月曜日
「瑕疵」と「仕事の完成」の認識（前編）
システム開発等において、「瑕疵（かし）」が問題になることがあります。
「瑕疵」とは、簡単にいえば「製品等が本来有すべき性能等を有してないこと」とされています。
単純に「キズ」と表現されることがあります。
2016年11月21日月曜日
「契約の成立」と、契約成立の「立証」
契約は、口頭（口約束）でも成立します。
契約書が無くても、契約は成立します。
（法律で、書面作成が義務付けられている契約もあります。）
一方で、契約書がないと、契約があったことを立証することは非常に困難になります。
まず、この「契約の成立」と、「契約があったこと（成立したこと）の立証」とは別の次元の話であることを理解する必要があります。
とりあえず、この場合の「立証」とは、第三者に対することと考えてください。
2016年11月16日水曜日
ＩＴ契約は、「契約内容」が決まっていない契約である（続）
前回、「ＩＴ契約は、「契約内容」が決まっていない「契約」である」であると書きました。
システム開発やＷｅｂ制作における契約では、最初の段階、つまり‘制作を依頼’し、それを‘承諾’する段階では、その‘契約’において開発するシステムの内容や制作するＷｅｂの内容が定まっていない、ということがほとんどです。
2016年10月31日月曜日
ＩＴ契約は、「契約内容」が決まっていない「契約」である
ＩＴ関連業務における契約、特にシステム開発やＷｅｂ制作に関する契約について、他の契約との大きな違いとして、
「契約締結」時に、「契約内容」が確定していない
という点が挙げられます。
2016年9月23日金曜日
30年間繰り返されてきた失敗、30年間繰り返されるであろう失敗
ＩＴ契約に関するトラブルは、同じようことを原因に繰り返されてきていると思っています。
「なぜ30年間同じ失敗が繰り返されるのか」というレポートで、高田寛教授（富山大学経済学部経営法学科）は「開発失敗に至るプロセスに30年間変化なし」として、
「受注金額が決まっているにもかかわらず、交渉過程において次から次へと要求が増えていきます。そのうちに、予定の納期が迫ってきて、契約が締結されていないまま作業を始めてしまいます。」とそのプロセスを説明しています。
（BUSINESS
LAW JOURNAL No.64 2013.7 p54～p55）
2016年9月12日月曜日
ＩＴ関連業務の契約の特徴 ～ 契約すべきことが分かっていないということ （後編）
開発するシステムの内容というのは、確定した仕様である、ということについてはおそらく異論はないと思います。
（ここで、仕様が‘いつ’確定するのか、という議論は別のことであると理解しておく必要があります。）
本来、そこが明確にならないと、開発にどれだけの費用が掛かるのかの見積もりもできないはずです。
しかし、何らかの見積もりを出さないと契約してくれない、という状況もあることは事実でしょう。
2016年9月4日日曜日
ＩＴ関連業務の契約の特徴 ～ 契約すべきことが分かっていないということ（前編）
ＩＴ関連業務、特にシステム開発やＷｅｂ制作等に関する契約について、他の契約ではあまり問題にならなかったことが問題になることがあります。
その一つが、
契約の内容が決まらない段階で契約が締結される
という点です。
ほとんどの契約の場合、契約の内容が分かって契約を締結します。
2016年8月30日火曜日
2016年8月29日月曜日
プロジェクトマネジメント義務・序論（後編）
開発が進んできたときに、以前決めたことを、「ちょっとココ変えて」というふうに言われた場合、開発の進捗状況や、あるいはデザイン的にもいろいろが差しさわりが出てくることはよくあることですが、一般的に、発注者はそれがそんなオオゴトとは思っていません。
「ちょっと変えるだけやんか」くらいのイメージで、その‘ちょっと’がどれくらいの作業量や時間がかかるか、ということも、委託者側は通常は知りません。
2016年8月22日月曜日
プロジェクトマネジメント義務・序論（前編）
契約（といいますか、もう少し単純な‘感覚’としては、「受けた仕事」「依頼された仕事」くらいでしょうか。）の「履行」について、それが一方当事者にとってなかなか思い通りにならない場合、どうしてもその理由を相手方にしたい、というのは、一般的によくある発想です。
（その方が楽ですし．．．）
2016年8月1日月曜日
請負契約と準委任契約の基本（前編）
民法には、売買契約や賃貸借契約など、１３の契約類型が規定されています。
この１３の契約類型を、典型契約、又は（法律において名前が付けられているということから）有名契約といいます。
この典型契約（有名契約）の中で、
ＩＴ関連業務の契約では、「請負契約」と「委任契約（準委任契約）」という契約類型が重要になります。
2016年7月25日月曜日
「契約の履行」まで考えて「契約の締結」をしていますか！？
契約に関するトラブルの原因はいろいろあると思いますが、その中で、「契約を仕事（ビジネス）の流れと関連して理解していない」ということがあると思います。
もう少し違う言い方をすると、
契約の成立（契約書を作ること）だけに注目していて
契約の履行について考えられていない
ということです。
「契約を締結」すること ＝ 仕事をもらうこと（？）
だけが、重要なのではありません。
2016年7月18日月曜日
「債務を明確にしたくない」が、リスクと契約トラブルの原因に？（後編） ～ ＩＴにおける債務とは
前回、契約をする際に重要なこととして、
何が義務（債務）か？
義務（債務）の範囲はどこまでか？
ということを明確にすることが重要であると書きました。
ＩＴ契約においては、それを明確にしていないので、
いつまでも業務が終わらない
となっている可能性が考えられます。
契約における義務（債務）を、単なる「負担」ととらえるのではなく、自分がなすべきことの範囲と考えることが重要なのです。
2016年7月15日金曜日
【告知】9月27日 沖縄でＩＴ契約に関するセミナーを開催します！
ＩＴ関連業務における様々なトラブルは、契約のやり方にあるといっても過言ではありません。
（もちろん、開発スキルによる開発の失敗や、ユーザーの要望に応えられない、というトラブルのケースもありますが、それは契約以前の問題です。）
また、契約締結については、開発を始める前、あるいは交渉（相談）が始まる段階からその内容を意識しておく必要があります。
2016年7月13日水曜日
「債務を明確にしたくない」が、リスクと契約トラブルの原因に？（前編） ～ 義務を明確にすることとは
日本の契約における一つの特徴として、義務（債務）を明確にしていない、ということがあります。
（特に、個人事業主や中小企業における契約においてよく見られます。）
これには、契約当事者において、自分の義務はできるだけ曖昧にしておき、いざという場合（？）には責任を逃れたい、という意識があるようです。
2016年6月13日月曜日
ＩＴに関する契約で繰り返されるトラブル （後編）
ＩＴ関連の業務に関する契約について、同じようなトラブルが繰り返されているのはなぜでしょうか。
別の観点から見ると、トラブルへの対処法として提示されている内容への反発（？）のようなものがあると思います。
2016年6月6日月曜日
ＩＴに関する契約で繰り返されるトラブル（前編）
ＩＴ関連の業務に関する契約については、もう何年も同じようなトラブルが繰り返されていると言われています。
雑誌等でもそういったトラブルに関することが度々取り上げられ、トラブルを未然に防ぐ方法、トラブルへの対処法といった内容の特集が組まれてきました。
いくつか有名な裁判例もあり、そういった情報からトラブルの一端を知ることにもなります。
それでも同じようなトラブルがなくならないのはなぜでしょうか。
2016年5月30日月曜日
議事録は契約書の代わりになるか？（後編）
「議事録は契約書の代わりになるか？」ということについては、
・ 議事録の内容が、合意内容を明確にしているか
・ 権限を有する者が合意しているか
・ 基本契約書との関係
という３つの点がポイントになると考えられます。
前２つについては「前編」に書きました。
「基本契約書との関係」についてですが、ＩＴ契約の特徴として、ほとんどの場合が最初の段階（基本契約書を作成する段階）で作成する内容（成果物
＝ 契約事項）が決まっていません。
2016年5月23日月曜日
議事録は契約書の代わりになるか？（前編）
「契約書を作成してください」という話をしていると、
交渉（‘契約に向けた’話し合い）や、契約成立後のプロジェクト・ミーティング等での「合意」について、
議事録が契約書の代わりになるか
という相談を受けます。
特に、最初の基本契約で決まっていなかったことが、ミーティング等で決定した場合に、いちいち「個別契約書」を作成するのがめんどくさい、ということがあるように思います。
これについては、次の３つの点が重要になると思われます。
2016年5月10日火曜日
契約の成立前の開発を着手してトラブルに．．．～ 契約の成立とは？（後編）
前編では、
ＩＴ関連業務に関する「意思の合致」が不明確になりがちである
ということを書きました。
それに加え、別の事情もあるように思います。
「契約が成立する前に開発に着手したケース」では、開発側（受託者側）が、何のきっかけもなく開発に着手するケースがほとんどないと思います。
契約の成立前の開発を着手してトラブルに．．．～ 契約の成立とは？（前編）
ＩＴ関連業務における契約トラブルについて、
契約が成立する前に開発に着手したケース
があります。
開発に着手した後に、
契約が成立していたか否か
という点で争いが生じ、委託料の請求や支払い拒否といった問題に発展することが多いのです。
このような場合にも、契約書を作成していない場合がほとんどなのですが、そもそも、契約はいつ成立するのでしょうか？
2016年5月2日月曜日
ＩＴ契約のトラブルの始まりはココ！ ～ 営業担当と、開発実務と、法務の関係（前編）
ビジネスの契約をする際には、
業務の流れ
を反映させる必要があると考えています。
自分の仕事の進め方とかけ離れた契約をしても、実際の場面では何の役にも立たず、単に契約（契約書）に振り回されるだけ、ということになります。
業務の流れ、とは、ＩＴ関連業務の場合、
開発業務の進め方
という部分が重要になるのですが、もう一つ、別の場面で意識してほしい‘業務の流れ’があります。
ＩＴ契約のトラブルの始まりはココ！ ～ 営業担当と、開発実務と、法務の関係（後編）
発注（しようとしていている）の相手方が出している要望の内容
をしっかり聞いて、開発担当に伝えることは重要です。
しかし、さらに重要なのは、
営業担当がどのような話をしてその要望が出てきたか、
そして、
その要望に対して営業担当は何を話したか
ということです。
2016年4月22日金曜日
ＩＴ関連業務の契約について
システム開発（ソフトウェア開発）やＷｅｂ制作などのＩＴ関連業務の契約においては、発注者側（委託者側）と受注者側（受託者側、ベンダなど）の間で様々なトラブルが起こっています。
その多くが、
・ 「契約」をしっかり交わしていない
ということに原因があります。
また、
・ 「契約」とはどういうものか
ということが、発注者側・受託者側の双方がよく分かっていないこともあります。
ここでいう「契約」とは、「契約書」と同じ意味ではなく、契約の内容（合意内容）のことです
このブログでは、
・ 契約とは何か
・ 契約とはどういうものか
といった基本的なことから、
・ 契約をする際に注意したいこと
・ 契約をする際に盛り込んでおきたい事項
など、発注者側・受注者側の双方にとって役立つ内容を、できる限り分かりやすく書いていきます。
メールアドレスは、ホームページをご覧ください。
登録:
投稿 (Atom)