2010年12月

いよいよ大晦日。
毎年恒例の、今年書いたエントリーを読み返してみて、自分にとって印象深かったものを10本ピックアップしました。
今年は昼休みをアプリ開発に費やしたので、例年以上にエントリーが少ないのがアレですが・・・

2010年03月10日
iPhoneアプリは、夜中に靴をつくってくれるこびとさんだったという趣旨のエントリー
残念ながら、人生観を変えるほどの影響力はもっていないようです。
ただ、1万円未満のお金を使うことに対するハードルは、恐ろしいほどに低くなりました。
自分自身の自制力を全く信じられないので、今年からお小遣い帳をつけることに。

2010年03月11日
さいごのおくりもの
僕の父は、ほんとうにすごい人でした。

2010年04月17日
すみません、裁判例一つください
結構がんばって書いた、久々の創作もの。
立法が後手後手の著作権まわりでは実際に行われても不思議じゃない気もするんですけどね。

2010年05月07日
実際に作ってみて垣間見えた電子書籍後の世界
電子書籍は、いまでこそ書籍の電子化にとどまっていますが、そう遠くない将来、電子書籍は紙の書籍の呪縛から解き放たれて、大空へ羽ばたいていくことと思います。
そのとき僕たちはきっと、なんであんなものを「電子書籍」なんて呼んでたんだろうな、って思うんでしょうね。

2010年06月28日
寺井先生と僕
昔頂いた年賀状を整理していたら、高校生のときまで寺井先生と年賀状の交換をしていたことが発覚。
最後の年賀状には、ついに結婚しちゃったとありました。
いつかちゃんと面と向かって、寺井先生、あのときはありがとうございましたって言いたいです。

2010年07月09日
iPad専用六法「パーフェクト六法HD」のリリース時のキャンペーンをちょっと工夫してみたという話
はじめてアプリのプロモーションを工夫してみたという話です。
iPhoneアプリを作る際には、常に何か新しい要素・試みにチャレンジすることを自分に課しているのですが、このときは売り方をちょっと工夫してみました。

2010年07月23日
契約法務初心者がおかしがちな10の過ち
IT系の記事を法務に適用するシリーズの一つ。
一番言いたいのは、実は1だったりします。

2010年10月29日
「今日、すごく寒くないですか?」のまとめ
こちらもTwitterでネタ投稿したもののまとめ。
想像していたより受けました。特にCMO CTO CFOのくだりが(笑)

2010年12月10日
永和システムマネジメントの例のスキームは、どうやって赤字リスクを回避しようとしているのかについてちょっと考えてみた
久しぶりにちゃんとちゃんと書いたエントリー。
リリース後って、ほんとに1人日しか対応してもらえないのかな。

2010年12月17日
英文契約書はじめの一歩
軽い気持ちで書いたエントリーですが、その後dtkさんの一連のシリーズにより、法務担当者のブログでは、ちょっとした英文契約書関連のエントリーブームが訪れました。
どれもとても勉強になります。

それでは、良いお年を!
このエントリーをはてなブックマークに追加 Share on Tumblr

英文契約書を初めて読むよ!という方をターゲットに、これを知っておけば役に立つんじゃないかという豆知識をまとめてみました。
ツッコミ、補足大歓迎です。

------
shallとmay
契約書においては、ほとんどのケースでshallは義務、mayは権利を示す助動詞として機能します。
shallが出てきたらこの文には義務が、mayが出てきたらこの文には権利が書かれていると割り切ってしまって続きを読むことで、スムーズに権利と義務を整理することができます。

大文字で始まる単語は定義されてる
文頭でも固有名詞でもない(通常の英語のルールでは大文字で始まるはずが無い)のに大文字で始まっている単語は、契約書のどこかでその意味が定義されています。
このような単語は、通常とは異なる意味が付与されていますので、文意を誤解してしまわないよう、定義済み(のはず)の用語を見かけたら、その意味を確認する必要があるのです。
逆に、契約書の最初に登場する定義をまとめた条項は、それだけ読んでも何の意味もないので、通読する際は読み飛ばしちゃってOKです。

条文のタイトルで内容を推測する
多くの契約書では、内容を一言で言い表すタイトルがつけられており、タイトルから内容を推測してから読み始めると、内容を理解しやすくなります。
なお、以下のタイトルは日常ではあまり用いない表現だったり、内容とタイトルが正反対だったりするので、内容と一緒に覚えてしまった方が手っ取り早いと思います。
  • Force Majeure
    不可抗力、つまり、当事者ではどうにもならないことに起因する義務違反に関する免責が定められています。たまにとんでもないことが不可抗力として列挙されていることがあります。
  • Representation and Warranty
    相手方に対して「ここに書いてあることはほんとだよ」と保証する旨が定められています。たまに神様でもない限り保証できっこないことや、驚くほど白々しい嘘がちゃっかり書かれていることがあります。
  • Assignment
    契約上の地位や権利、義務の譲渡・移転を”禁止”する旨が定められています。
  • Severability
    契約条件の一部が無効になった場合でも、他の条件は生き残る旨が定められています。丁寧な契約書だと、例外として、契約書もろとも無効になる条項を別途指定していることもあります。
  • Waiver
    権利を行使しない場合であっても、その権利を放棄したわけではない(後で行使することができる)旨が定められています。
  • Entire Agreement
    この契約が、契約締結以前になした合意よりも優先する旨が定められています。契約書に規定した内容が、交渉時の議事録等でひっくり返されるのを防ぐ条項です。
  • Whereas/Recitals
    WhereasやRecitals はタイトルではありませんが、この後ろに「契約書がなぜ締結されるに至ったか(締結の背景)が書かれている」という目印になります。とはいえ、WhereasやRecitalsには、大抵、毒にも薬にもならないようなことしか書いてありません。

全部大文字の条項
契約書の中には、全てが大文字で記載されている条項が登場することがあります。
これは、「よく読め!」という意味だそうで、大抵は原案作成者に有利な条件、多くの場合は「保証などの責任を制限する内容」が定められています。

原則例外パターン
多くの条項は、原則と例外・条件の組み合わせで構成されています。
以下の用語が登場したときは、ここから先は例外・条件だ、と認識しながら読むことで、立体的に把握することができるようになります。
  • Notwithstanding 〜,
    〜に関わらず、という意味で、Notwithstanding the foregaing,(上記の規定に関わらず)や、Notwithstanding Section 2.1(2.1条の規定に関わらず)といった形で登場します。
  • , unless 〜
    〜の場合を除き/〜しない限り、という意味で、unless otherwise agreed(別途合意しない限り)といった形で登場します。
  • , provided that 〜/, provided, however, that 〜
    (但し)〜ならば/〜という条件で、という意味で、provided that the other party uses best efforts to 〜(相手方が〜するために最善の努力を払うことを条件に)といった形で登場します。

契約書特有の表現
契約書特有の表現は上げればきりがありませんが、これだけは覚えておくと絶対に役に立つというものが一つあります。
それは、here+前置詞というもの。
契約書では、hereunderやらhereinやら、やたらとこのhere+前置詞が登場しますが、これは全て前置詞+this agreementと読み替えてください。
例えば、set forth hereinと書いてある部分は、set forth in this agreement(本契約に定められた)と読み替え、grant a right hereunderと書いてある場合は、grant a right under this agreement(本契約に基づいて権利を許諾する)と読み替えればいいのです。

ではでは〜
このエントリーをはてなブックマークに追加 Share on Tumblr

ござ先輩のエントリーを読んで、久しぶりに法務ブログっぽいエントリーを書こうと思い立ちました。
題材は、永和システムマネジメントの例のスキームです。

このスキームを目にした方が最も印象的に感じるのは「初期費用を無料にして、運用費だけで回収する」「しかも、途中解約に制限・ペナルティはない」という回収モデルの部分だと思います。
永和システムマネジメントは、どのようにしてプロジェクトが赤字に終わってしまうリスクを回避しているのでしょうか。

1.対価の発生時期を早める
永和システムマネジメントの例のスキーム(永和スキーム)は、ウォーターフォール(最初から完成品を作る)モデルでも、対価の回収方法を変えれば実現自体は可能です。
つまり、実のところ、永和システムマネジメントがアピールしているアジャイル(ちっちゃく作った後完成品目指して追加開発していく)は、永和スキームの必要的要素ではないのです。
ただ、アジャイルはウォーターフォールに比べると最初のリリースまでの時間が圧倒的に早いため、結果として、リリース後に発生することになっている対価の発生時期を早めることが可能になります。
永和システムマネジメントは、アジャイルの特性の「ちっちゃく作って…」を、こんな面からも活用しているんですね。

2.リリース前のコストを圧縮する
アジャイルで開発する以上、最初のリリースまでに必要な工数はウォーターフォールよりもずっと低くなります。
また、純粋な開発工数以外にも、成果物の仕様が限定されているため、仕様変更に振り回される危険も低くなります。(仕様追加に至っては、「リリース後にやりましょう」と切り捨てることが可能)
さらに、著作権を譲渡しないこと、着手時点でリスクを取っているのは主に永和システムマネジメント側であることから、通常の受託開発よりもユーザーの無茶な要求に振り回されにくいという面もあるかもしれず、そうであればコスト圧縮に大きく寄与すると考えられます。
対価発生前のコストが圧縮できれば、当然立ち上げ時の赤字幅も小さくなりますよね。

3.リリース後もコストをかけない
永和スキームの紹介ページを見ると、トライアル開始されるプランSSにおいて、月次で委託できる工数は1チケット。
”1チケットで1日程度の保守・サポート対応が可能です。”とのことですので、これが1人日という意味なのであれば、アジャイルの継続開発というより、どちらかと言うと保守・サポートに近い印象を受けます。
最初のリリースから次のバージョンのリリースに1人月必要だとすると、ユーザーがチケットを買い増さない限り、1年近くかけて開発することになります。(本当の意味での保守が発生する可能性を考慮すると、1年を超過する可能性も多いにあります)
このように、リリース後にかかる工数を限定することで、黒字化までの期間を短縮できるってわけです。

なお、永和スキームの紹介ページを見ると、プランSSの料金は15万円なので、1人日15万円という前提で単純に人月単価に換算すると300万円(4年目以降は半額になるそうなので、150万円)ということになりますね…
ただ、買い増しチケットの単価は15万円よりも安いかもしれません。

4.成果物を転用する
永和スキームでは、著作権は永和システムマネジメントに留保されますので、特段の事情が無い限りコードの転用は永和システムマネジメント側で自由に行えます。
ワークフローの様な汎用性の高い案件を受注できた場合には、これを転用することで次の案件のコストをぐぐっと圧縮できる可能性があります。
ものによっては、パッケージ化してライセンスで収益を上げることだって可能になるかもしれません。

5.成長を見せることで期待感を持たせる
システム変更時には、ユーザーとしても教育や運用の変更などの対応をせざるを得ないため、たとえ開発費/構築費が0であってもそう簡単に新しいシステムの利用をやめる訳には行きません。
これに加え、アジャイル開発の下では、リリースされたシステムに要望していた機能が追加され、(運が良ければ)使い勝手も向上していくのを目の当たりにしたユーザーが「来月・来年はもっと良くなっているかもしれない」と期待することにより、さらにその効果が高まるんじゃないかと思います。想像ですけど。
当然ながら、リリース後は単月では黒字になるように値決めしているはずなので、継続期間が長期化はそのまま黒字幅になるわけですね。



このように見て行くと、目先のキャッシュだけ工面できれば、通常の受託開発と比較しても、それほど危ない橋を渡っていないように思えてきませんか?
ぜひ技術力に自信のある他社さんも、丸パクリではなく、「ご紹介キャンペーン(顧客を紹介してくれたら1年間収益分配する、とか)」「余ったチケットをコンサルティングetcに流用できる仕組み」「ボーナスチケット(汎用性のあるシステムについてはチケットを上積みしてあげる)」のような工夫を追加して新しい契約スキームを盛り上げて頂ければと思います。

ではでは〜

↑このページのトップヘ