カテゴリ: 雑記 【おしごと関係】

2回目の月一プレゼン。
早くも月一というペースに不安を感じてきました。

今回もKeyNoteを利用していますが、前回よりもアニメーション・遷移の癖が掴めてきたので、煩さは減少しているのではないかと思います。

肝心の中身についてですが、ターゲットはスタートアップの経営者で、投資を受けることを検討している場面を念頭に置いています。
果たしてこの状況に当てはまる人が現在何人いるのかまったくわかりませんが、もしうっかり誰かの役に立つようなことがあれば嬉しいです。
あと、見返したら「エージェントコスト」の説明がちょう雑ですね。
ま、大目に見てください。

ではでは。


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

今年の新企画、月一プレゼンです。
出だしからギリギリのアップになってしまって自分でもどうかと思うんですけど、とにかく今月は目標達成。先が思いやられます。

今回はMacを新調したことと、諸般の事情でKeyNoteを使う用事ができたこともあって、慣れないKeyNoteで資料を作成しています。

では、どうぞー。



---

本筋とは関係ないけど、誰でも簡単にカッコいいプレゼン資料を作れるというふれこみだったKeyNoteは、本当にすごかった。

資料作成(下書きも含めて)に数時間。
エフェクトを付けるのなんて、1時間もかからずに完了したからねぇ。

見栄えにあまり留意しなくていいというのはこんなにも快適なことだったのかと感心しました。

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

この前、昼休みに思い付きで「コンプライアンス違反が起こるパターン」をまとめてみたんだけど、それだけじゃ何にも産み出せていないので、さらにもう一日分の昼休みをかけて「パッと思いつくコンプラ違反の事例との関連付け」もやってみたら、シートがすんごく汚く・見づらくなったこととの引き換えに一つわかったことがありました。




それは、ほとんどのコンプラ違反事例が「ばれない」ことを前提にしてるということ。
いや、考えてみれば当たり前のことなんだけど、こう「ばれないと思ってた」に矢印が怒涛のように突き刺さる様を見ていると、実感がわいてくるわけです。
「ばれない」っていう期待というか思い込みは怖いな、と。

コンプライアンス研修ではよく、「人に見られているとしても同じ行動を取るのか?」という判断基準を与えることがあるけど、結局のところ「ばれない」って思ってる人にそんなこと言っても全然意味ないんだよね。
だって、「同じ行動はとらないけど、ばれないからまぁ大丈夫」ってなっちゃうわけだから。

といことは、「ばれないと思わせちゃうかどうか」がコンプライアンス違反が止まるか否かを画するわけなので、コンプライアンス研修ではまず、知識とか意識とかの前に、「何かやったらばれるかんな!」ってことを強調することから始めなきゃならないのかもしれません。
もちろん、この脅しが空振らないようにするための当然の前提として、「何かやったらばれる」体制・システムの構築も必要になります。
今までは、どちらかと言うと「やらせねぇよ」という観点で体制・システムを考えていましたが、もしかすると、正解は「やったら見逃さねぇよ」の方なのかもしれません。

ここら辺を見なかったことにして「そもそもコンプライアンスとは、法令遵守にとどまる概念ではなく・・・」とか、「下請法と言う法律によって、資本金3億円以下の事業者に・・・」とか、「今や会社が潰れるような事態にも・・・」とか言ってみたってあんまり効果ないんだろうな、なんて思ったりしました。

んでは、また!

おっきい図はこちらから
このエントリーをはてなブックマークに追加 Share on Tumblr

コンプライアンス研修を今まで何度か受け、また自分で企画してきて確信に至ったんだけど、例外的なケースを除いて、コンプライアンス研修では何が良くて、何が悪いのかを教えてちゃダメなんだと思う。
ほとんどのコンプラ違反の場面では、「それが悪いこととは知らなかった」わけではないので実際の効果として期待薄だし、何よりコンプラ意識が低い段階ではコンプラ離れを加速させてしまう。

じゃぁ、何を伝えれば良いのかというと、それは、「(きれいごとではない)コンプライアンスに取り組む必要性」と、「コンプライアンスは、実現するのがすごく困難であるという事実」なんじゃないかと今は考えている。

その上で、個別の知識については、コンプラ研修の外に知識習得用の予備校的なスタイルで習得してもらう。

つまり、コンプラ意識の醸成と知識の習得を完全に切り離してしまった方が良いんじゃないか、と。

近々コンプライアンス周りの整備を担当することになりそうなんだけど、今まで各個撃破のような対応しかしてこなかった反省を踏まえて、今回はちゃんと戦略を立てながら進めてみたい。
このエントリーをはてなブックマークに追加 Share on Tumblr

磯崎さんのコラム投資契約を結ぶ際の3つの重要ポイントを読んで、大切なことだけど普段契約書を読んだことのない人には大変だよなぁ、と思ったので、少しでもこんな方々の役に立つことができればと思い、簡単なガイドを書いてみました。

その1:契約書を読む前に、この契約で実現したいことを再確認する
契約書を読みなれていない人は、契約書案が手元に届いても、いきなり読み始めるのはうまいやり方ではありません。
なぜなら、契約書を読みなれていないと、契約書の記載から条件を読み取るのはとても大変だからです。

では最初に何をすればよいかというと、それは、この契約で、自分は何を実現したかったんだっけ?ということを再確認することです。
自分は何を実現したかったのか、とは、つまり投資を受ける契約でいえば「現金を●月●日までに自分の口座に振り込んでほしい」ということであり、物品を買う契約であれば「ある商品を●月●日までに自分の手元に納入してほしい」ということです。この段階では細かいこたぁどうでもいいので、「これがなかったら契約するなんてありえん」というコアが何かを明確にしましょう。

そして、この再確認が終わったら、自分が実現したかったことが、契約書にちゃんと書かれているかを確認するしてください。
この確認作業は、「契約書に何が書いてあるかを頭から読み解いていく」ことよりもずーーーーーっと簡単なので、さくさくっと終わらせることができるのではないかと思います。

その2:自分の義務に、無茶なことが書いてないかを確認する
さて、無事実現したいことが契約書にちゃんと書いてあることが確認できたら、次は「自分の義務」としてどのようなものが規定されているかの確認です。
義務には「●●しなければならない。」というものと、「●●してはならない。」という2種類があることに注意して、蛍光ペンで自分の義務が書いてある部分にラインを引いてしまいましょう。
和文の契約では「●●するものとする。」という。日本語的にどうなの?という書き方で記述されることもあります。
 また、英文契約では、義務には助動詞「shall(禁止義務の時はmay notも)」が義務の目印になります。
そして、ライン引きが終わったら、自分の会社がこの義務をちゃんと守ることができるのかを想像してください。
想像してみて「こりゃ無理だわ」と思った義務については、削除する必要があります。
カッコつけずに「無理ですごめんなさい」と先方に伝えましょう。
なお、文句を言うと、相手方の担当者が「これは紙上の問題で、実際は無視でいいっすよ」と優しい言葉をかけてくれることもありますが、不思議なことに、いざもめ事になると、優しかった担当者の姿が見えなくなってしまったり、担当者の姿は見えても優しさをどこかへ置き忘れてしまっていることがとても多いのでぜひご注意ください。

その3:意味が判らない条項は、思い切って削除する
その1、その2が終わったら、ようやく頭から契約書を読んでもいい頃合いです。
が、結局のところ、読んでも意味のわからない記載はゴロゴロ出てきてしまうと思います。
ここで気をつけてほしいのが、「読んで意味がよくわからない記載については、なぜか自分に有利なように推測してしまう」という、悲しき人間の性です。
ですが、残念なことに、相手方が作った契約書に書いてある意味のわからない記載が自分に有利な意味を持つことはほとんどありません。
そのため、専門家に頼れないケースでは、意味が判らない条項は削除してしまった方が安全ということになります。
ガシガシ削除すると間違いなく先方からは文句を言われますが、後で振り返ってみると意味が判らない条件をのむよりよっぽどマシなことも多いので、がんばる価値はあると思います。


といったところで昼休みが終わりました。
午後もがんばりましょー。
このエントリーをはてなブックマークに追加 Share on Tumblr

最初に断ってしまいますが、いつも通り、タイトルと内容はあまり関連していません。

---

今年は、みずほFGと東京電力という、前期に大問題を引き起こした会社の株主総会に立て続けに出席した。

どちらの総会も当然のように荒れ、ヤジと怒号が飛び交う中、株主はここぞとばかりに質問の場で大演説をぶちかまし、動議が出され、そして粛々と決議事項が可決されていった。

中でも東電の総会は、Twitterで詳細な実況をする方が複数登場し、その日のニュースでも大きく取り上げられえたこともあって、その異様な雰囲気は多くの人に知れ渡ったことと思う。
その夜、東電に対するネガティブな感情が文字になってTL上を駆け巡っているのを眺めながら、一体どうすればよかったのか、自分だったらどうしたのか、ということについて考えざるを得なかった。

---

株主総会で会社が想定していない決議がなされてしまうと実務上多大な支障が生じることが明らかである以上、協力株主から委任状や当日の協力を取り付けようとするのは当然の行動であり、非難されるいわれはない。
総会を始める前から勝負が決まっている状態になっていることについても、それはひとえに会社に賛同する議決権が多かったと言うだけのことであって、ほめられこそすれ、貶められる筋合いのものではないのは明らかだ。
また、株式会社の性質上、株主総会の場で渦巻いていた「明らかに反対/賛成の挙手の方が多いのに、なぜ可決/否決されるのだ!」という問いが完全に的をはずしたものであることにも疑問の余地はない。
さらに言えば、株主総会は数カ月の綿密な準備を経てピンポイントで実施される失敗の許されない一大イベントであって、もしかすると取消のネタになるかもしれないような不規則な(他社と横並びでない)対応などは徒にするべきではないということも理解しているつもりだ。

今回の東電の総会だって上記の観点から見ればなんらおかしなことはないのに、それでも違和感をぬぐい去ることはできない。


どうすればよかったのか、しばらく悶々と考えて出た結論は、「出席した株主に、この総会は茶番・無意味だ、と思わせないよう努力する」ことだった。
文字にすると青臭くて自分でも苦笑いしてしまうけど、でも、特に今期の東電のような総会では必要なことだったと思う。

---

例えば、株主質問の場で超早口でわけのわからないことを捲し立てた挙句、「全員原子炉に入って死ね!」と絶叫した株主がいたけれど、それに対して東電側が、「わけのわからない捲し立て」の部分からかろうじて聞き取れたキーワードを質問事項とし、そのことについて答えたという場面があった。
この心底くだらないやり取りを聞いて、「東電は『質問に答えた体』が必要なんだ」と多くの人が感じただろう。
また、「決議の時挙手を求めていながら数えているふしがない」という別の株主質問に対し「ちゃんと数えています」と答えた場面もそうだ。
こんなことを言われて、茶番だと思わない人がいたら、むしろ驚愕してしまう。

「茶番と思わせないため」に、何も独立したアクションを総会に取り入れろなんてことを言いたい訳じゃない。
ただ、一つ一つの対応に、「目の前の株主と真摯に向き合う」という意思を込めるだけでよかったと思う。
(頭の中に渦巻いている思いをうまく文章にできなくて、夢見がちな抽象論のような書きぶりになってしまうのがもどかしくてたまらない)

もちろん、株主総会だからといって株主に媚びを売る必要があるわけではないし、普段であれば、株主の側だってそこまでの期待はしていない。

でも、今の東電は「普段」ではない。
周りを敵に囲まれる中、東電にとって株主は数少ない味方の一人だ。
それにもかかわらず、1万人近い株主を前に自分たちの声をダイレクトに届けられる機会をみすみす棒に振った(というより、逆に不満を募らせることになった)という損失は、これから逆風の中前進を続けなければならない東京電力にとって、思いの外大きなものになるのではないかと思えてならない。
このエントリーをはてなブックマークに追加 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に流用できる仕組み」「ボーナスチケット(汎用性のあるシステムについてはチケットを上積みしてあげる)」のような工夫を追加して新しい契約スキームを盛り上げて頂ければと思います。

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

五回目くらいらしいBLJの読者交流会に行ってきました。

いい意味で緩く、肩肘張らずに様々な会社の法務の方からお話をお伺いできる数少ない機会の一つだと思いますので、まだ参加されたこことのない方は、次回はぜひお申し込みされることをオススメします。

さて、今回のキーワードです。
  • 自然原料を発酵させて作っているので安全です
  • 名刺が五種類
  • 表紙は坊主頭でバカ売れ
  • 前橋のイントネーション
  • 何のゲーム買ったんだっけ…

    そんじゃ、またね〜
  • このエントリーをはてなブックマークに追加 Share on Tumblr

    マイコミジャーナルでWebデベロッパ初心者がおかしがちな10の誤ちというエントリーに影響を受け、契約法務バージョンを作ってみました。

    1. 案件を止める
      案件を止めるのは依頼者や決裁者の役割で、依頼者や決裁者に正確な情報を伝えるのがあなたの役割です。

    2. 交渉の場に出ない
      10通のメールより、10分直接話した方が交渉が進展するケースも少なくありません。

    3. 根拠資料にあたらない
      条文、書籍、官公庁のウェブページなどの資料にちゃんとあたらないと、思わぬ大けがをすることがありますよ。

    4. 実務上の影響を念頭に置いていない
      理屈の上では不利な条件であっても、実務上はぜーんぜん問題ないというケースはよくあります。
      「実務上、どんな問題が生じるの?」と聞かれて答えられないような文句はつけないようにしたいものです。

    5. 回答が変わる
      同じ前提条件のもとで同じ内容の依頼を受けた場合、同じ回答ができなくてはなりません。
      これは、メンバーが増えれば増えるほど難しく、かつ重要になってきます。

    6. 税務、財務の都合を考えていない
      狭義の法務としては問題なくても、税務・財務的に問題があれば、会社としては見過ごすことはできないわけで。

    7. 自社の業務に関する知識に欠けている
      自社がどんな仕事をして何で儲けていているのかが理解できないと、契約内容も充分に理解できません。

    8. 一般名詞で定義する
      以下「ソフトウェア」という。

    9. 実現可能性を考慮していない契約条件を設定する
      エキセントリックな通知条項を見たことありませんか?

    10. メンテナンス性が低い契約条件を設定する
      構造がしっかりしている(内容によって条項が分けられている)契約書であれば、修正が必要になった場合も素早くかつ確実に対応することができます。


    例によって昼休みにちゃちゃっと作ったやつなので、ツッコミ大歓迎です。
    あと、「おまえはどうなんだ!」と詰め寄るのは勘弁してください。
    ま、いうのはかんたん、やるのはたいへん、ということですね。
    このエントリーをはてなブックマークに追加 Share on Tumblr

    ↑このページのトップヘ