はじめての裁判手続き 〜 スクールの講師料支払いを求めて

会社も3年目に突入しました。

2年も会社というのを経営していると、売掛金の回収漏れというのがでてきます。

普通は売掛・買掛みたいなものは適切に処理されるもので、支払い漏れがあったとしても連絡すれば うまいこと払ってもらえるものなんですが、たまにそううまくいかないケースもあるみたいです。

先方の不渡りや回収漏れ、債権整理や裁判手続きなどはできれば避けたいところですが、 会社をやっているとなかなかそうもいかないみたいですね…

今回初めて売掛金の回収漏れというのを経験し、 裁判手続きとか諸々、面倒な事をすすめて来たので、その記録をまとめ、 今後同じような自体に遭遇した人の助けになれば、と思います。

今回の問題

事の発端は、2016年初めに IT系のスクール の講師依頼を受けたことから始まります。

1 ヶ月いくら、と言うかたちの口約束で始まり、最初のうちはきれいに入金もあり、 そこから安心した分もあってかすっかり入金確認を怠る様ようになってしまいました(ここがそもそもも問題)。

STAND COFFEEという喫茶店の一角で IT系のスクールを開催したいという依頼を受けて 3ヶ月タームのIT系スクールの講師として登壇してきました。

代表はFacebookの方でも上がっている、こちらの方ですね。 株式会社 ラブスタンダードチャンネルという屋号でプロデューサ的なことをされている 稲谷 将太 という方です。

スクールは期間満了で終了したのですが、未払いの債権は残ったままだったため、 「書類を書いてくれ」と頼み、無事書類を書いてもらったため安心していたのですが…

書類があるからと言って安心出来るわけではない

債権を確認する書類があったからと言って、それがお金になるわけではありません。

書面で約束した期日までに振込が無かったため、再度本人へ連絡。しかし向こうは待ってくれの一点張りです。

こうなったらもうどうしようもないので、次のステップに進むしかありません。

とは言え、ここで書類が存在しているのは大きな意味があります。

次のステップとなると裁判手続きとなるのが一般的なのですが、 売掛回収の裁判手続きでは「債権存在の確認」→「支払命令」→「強制執行」という手続きが一般的ですが、この「債権存在の確認」というのが面倒なのです。

債権存在の確認とは、誰が誰にどういう理由でいくら支払う、ということを確認するもので、 書類をかわさない口頭でのやり取りで仕事を進めている際には、裁判手続きが、このフェーズからのスタートになります。

xxx万円払うっていいましたよね?に対して「言ってない」と返されたらそこで終了です。

書面を書いてもらう際には、後々の裁判のことも見越して

  • 誰が : 債務者の確認
  • 誰に : 債権者の確認
  • どうして : 摘要欄の確認
  • いくら : 金額の確認
  • いつまでに : 期日の確認

を誰が見てもわかるような形で明記しておくようにしましょう。

支払督促を立てる

ここから面倒な裁判手続きの始まりです。

少額の支払い請求には、支払督促の利用が便利とのことだったので今回はそれを利用することにしました。

必要な書面は3枚で 裁判所の公式Webサイトからダウンロードすることが可能です。

裁判所|支払督促申立書

また相手方が法人の場合、相手方の登記簿が必要になりますので、法務局で取得してきましょう。

書類には色々と書く欄がありますが、自力での記述は不可能だと思いますので、適宜裁判所に電話しながら記述すると楽だし確実です。

支払督促申立書

申立手続費用に関して記述します。記述スべき金額は裁判所の人が丁寧に教えてくれます。

また書類には返信用封筒と官製はがきを同封する必要があるみたいなので、そのへんも併せて確認すると良いでしょう。

当事者目録

債権者と債務者の確認を行います。

債権者・債務者ともに相手の登記簿に書かれている住所で記載します(法人の場合)

請求の趣旨及び原因

ここで債権の内容を記述します。今回の場合は書面による確認があったためことはスムーズに進みましたが、 その辺がないと色々ややこしいみたいです。 自分で書くにしても下半分くらいは開けておいたほうがいいです。 裁判所には裁判用の日本語フォーマットがあるみたいなので、適宜向こうの事務員さんが朱入れしてくれます。 いくら工夫して素人が書いても1発OKとはならないみたいです。

なお、支払督促の請求は 債務者の住所の管轄の 簡易裁判所あてに送付します。

この辺も初めてだったのでよくわからずに苦労しました。

支払督促の逃れ方

支払督促をだしても安心、というわけではありません。

支払督促の請求を行っても裁判所は支払い督促を確実に届けてくれるわけではないのです。

そもそも受け取らなければ勝ち

裁判所からの手紙、となると普通はびっくりして中を確認するものですが、 受け取らなければそれはそれでOKみたいです。

今回のケースでも不達とのことで帰って来てしまいました。 そもそも手紙が届かないケースでは裁判手続きが届かない、ということみたいです。

届かないケースとしては表札がない、担当者がいないなどのケースがあるみたいで、 プロの回収業者などは配達期間中家の前で張り込んで勝手に表札を掲げる、みたいなこともするみたいです。

そもそも住所が存在しなければいい

さらにその上を行く手口で、 登記の住所を不完全にしておく という手口もあるようです。

今回の件でも裁判所の担当の方に、「債務者の方の登記住所が不完全でおそらく届かないだろう」と言われており、 手続き時点から届くかどうか微妙な所はありました。

裁判手続きに備えて 不完全な住所(丁目や番地が欠落している、など)を登記 登録しておけば、裁判関係の書類も届きにくい、というわけですね。

ちなみに正確に配達可能な住所を知っていたとしても、裁判所は原則「登記上の住所」にしか送付出来ないみたいです。

餅は餅屋

とまぁこんな感じで、色々裁判手続きに関して調べたり手を動かしたりしたものの、

どうにも回収できそうな雰囲気はなかったので、最終的には弁護士先生 や 債権回収業者にお願いすることにしました。

年末期バタバタする時期の手続きで色々後手後手になってしまったのですが、

年が終わる前に債権処理を手放せて本当に良かったです。

未回収債権の処理は、回収だけではなく、会計上の問題も生じてくるので本当に厄介です。

未回収債権は 1年立たないと貸し倒れ処理が出来ない

貸し倒れ損失処理は、1年間立たないと出来ないとのことです。

例えば 100万円分の未回収債権があった場合、 その100万円を当期売上に計上した場合、

回収不能債権の貸倒れ損失は翌期移行に繰り越されます。

今期の税務では、回収不能売上に対して税金を払わなきゃいけない上に、

翌期移行はマイナスからのスタート、となってしまうので会計上もいいことがないです。

(いっそ、帳簿から消すという手もありますが、書類がある分やっかいですし、万一回収出来たケースで処理にこまる、というのもあります)

感想

裁判手続きなどは今回が初めてだったのですが、本当に面倒でした。

色々勉強になった部分もあり、まぁ個人的にはいい経験だったかなぁとは思うものの、できればもう二度とやりたくないなぁというのが正直な感想です。

会計的にも法務的にもめちゃくちゃ面倒なので、回収漏れは今後できれば避けたいと思ったので、 通帳のチェックは今後しっかりやっていかなきゃ行けないなぁ…と心に誓いました(まずはその前に売掛金の管理を…)

あと、今回いろんな請求逃れの方法とかも学ぶことができ、書面って意外と無力だなぁ…と痛感しました。 書類を書いてあったとしても、結局弁護士等に依頼しなきゃいけないってことがわかり、 今回はそれなりの額だったためにこうしていろんな手続きを試すことになったのですが、 少額だとほんとに書類なんて書いてても意味ないんだろうなぁ…とか思っています。

まぁそもそもこういう手続きにならないようにするためにも、取引相手はしっかり選びましょうということで、2016年の反省としたいと思います。

WebデザインとUX について考えるに参加してきました。

chatboxデザイナーのyasuiです。 先日、「[HTML/JS/CSS] WebデザインとUX について考える」という勉強会に 参加してきました。

セッションの内容も数もとても充実した勉強会で、ためになるお話ばかりでした。 そんな中での自分の発表は緊張しすぎて@plum_shigaさんの講義にあった「マジ忘れる」を体感してたり…。

こんな発表してきました。

docs.google.com もう少しいくつか技法紹介できたりしたら良かったのかもしれないですけど、 なんかもう、いっぱいおっぱいでした。

感想

ハッシュタグ#frontkansaiは後日に確認しましたが、 色々ご意見いただけてて嬉しかったです。

「見てる人は手抜きに敏感だよ」ということを言ったんですが、 制作時間を短縮しつつ手抜きに見えないようにすることは今の私にはできてないことだなーと反省したり。

発表のきっかけ

スライド内には入れることができなかったところです。 今回発表しようと思ったきっかけは、 ただただ、与えられた情報を組み立てるだけとか、目に見える形にするだけの作業じゃなくって、 プレゼント(=伝えたいこと)のラッピング(=デザイン)する気持ちとか 受け取る人の事考えたりとかは大事にしていきたいなぁと思ったからでした。 別にイラストやデザインに限った話でもないのですが…。 まぁ、表現するということで共通する技法もあったのでそこを導入にしてお話出来たら良いなって。

参考にした本

お話したことは以下の本を参考にさせていただきました。 イラストにも興味ある方がいらっしゃったらオススメします。

www.amazon.co.jp


他の方のセッションの感想

あくまで個人の感想なのでご参考までに…。

おっぱいから見るUI/UXとPELSONA /コンチさん

docs.google.com

発表前で激しい動悸を感じながら聞いてたのでほぼ「おっぱい」しか覚えてない気もする………ということもなく、 UI/UXって言葉は知っているけど、どう考えたら良いのか、よくわからなかったので、 「利用前」、「利用中」、「利用してない時」の気持ちを考える必要があるんだなぁとか、 どんな手順でどんな要素を意識しながら考えたら良いのかなど知ることができました!


初期導入と記憶の利用 /plum_shigaさん

記憶は「マジで忘れる」。という感じで人の記憶はどのくらい維持できるのか、 どうやったら残るのか、などなど大学の講義のようなセッションでした。

どういった方法や問題の組み合わせで記憶させるとより記憶に忘れやすかったか、 逆に記憶に残りやすかったかのお話をされてました。

簡単すぎると忘れるけど、毎回ヒントを出されると鬱陶しくてストレスになる。 ストレスになってしまうと脳は忘れようとしてしまう。

他には、問題が例えば2文あって、その文が関連する項目で(そこには書かれていないけれど)未来を予測できるような問題とかだと 思い出しやすかったとか。 言葉を覚えようとして声に出して復唱するのってよくやるけど、 それだけだとわりと簡単な処理なので忘れやすいとか。 そのくらいが印象的であとは忘れました…。

脳の記憶の働きに基づいて覚えてもらう工夫するのって 難しいけど聞いてて面白いなぁーと思いました。


UI記述言語としてのHTML /masuP9さん

masup.net

要素を意識してHTMLを書くことの大切さについてのお話でした。 buttonタグ…divにしちゃうことのほうが多いかもと反省しました。 タグについてくる親切要素が逆に煩わしく思うことが多くて、ついついdivで記述してたんですが、 でもそれって肝心のUI優先できてないんじゃないかと色々振り返るきっかけになりました。


UXを損ねる静的コンテンツ配信アンチパターン /岡田勇樹さん

www.slideshare.net

HTMLの時と同じく正しく書くことがUXを損なわないことに重要だよということで、 いくつかわかりやすい事例とともに紹介されてました。 これも毎回できてるかと言われると、ついつい製作時間をいいわけにして 色々後回しにして結局出来てない的なことが多い気がしました…反省。


正解のないデザインについて、それでも正解について考えてみる /カイトさん

speakerdeck.com

デザインに正解はないけれど、本当にそうなのか?デザインの正解のある部分と、正解のない部分はどこなのか、それぞれの考え方とアプローチの仕方など 具体例を色々織り交ぜながらわかりやすく説明されていました。

これは本当にデザインに足を踏み入れた瞬間に誰もが迷い込む道なので、たくさんの人の意見を聞いてみたいと思ってました。 カイトさんのセッションを聞くことで迷ってたところを少しすっきり出来たのと、 共感できる部分に関しては少し安心できて、お話聞けてよかったなーと思いました。

すごく悩んだ時期の自分に教えてあげたいようなお話でした。これからデザインはじめる人に聞いてほしいと思いました。

あと紹介されていた「PIXEL PERFECT PRECISION HANDBOOK 3」読んでみようと思います Pixel Perfect Precision Handbook 3


制作側とユーザーの温度差、そしてペルソナのズレ-プロゲーマーと高校生から学んだ例- /コソバマイさん

ゲーマにとっての使いやすいUIがホバー表示っていうのが意外な印象でした…! そんな感じで、自分たちの考えるユーザ=ペルソナが実際のターゲットユーザと、どのくらいずれているのかというのを 現場で実感した経験を元に色々お話してくださりました。

できるかぎり対象に近い人に直接話を聞かないことには、どんなにユーザのことを思っても推測である以上 実際とのズレでてしまうのだなぁと思いました。

ユーザにとってのあたりまえっていうのは本当にユーザの普段見てるものやライフスタイルによって多種多様で、 作るもの(今回の場合はwebサイト)の範囲だけでなく、大きな範囲で考えてみることが必要だと 感じました。

学習能力、それは普段見ているものから調教されているのだと改めて考えさせられました。 自分の「あたりまえ」を押し付けてはいけないし、でも、それは意図せずやってしまうことなので、 「これは本当に自分だけの当たり前になっていないか?」と自身に問いかけるタイミングをつくるなど、 できるかぎり注意することだでも意識しようと思いました。


人類の進化とデザイン /角田綾佳さん

t.co

人間本体のスペックって、太古からそこまで変わってないのに、 テクノロジーはどんどん進化してしまっている現代において、 ずっと変わらず人間の本能的に求める感覚をデザインで埋めることが が心地よいUXのヒントになるのではないかなというお話でした。

どんなにテクノロジーが進化してもやっぱり人間は人間で。 変わらない感覚はやっぱりあって、それらの感覚は進化の中できちんと理由づけされてきたものだから 人に大きな影響をもつところなんだなって思いました。

感覚って言うとすごくあやふやな感じがするけど、 それらの感覚は進化の過程のどこからきたのかっていうのを考えると もう少し本質がつかめるのかなと感じました。


WebアプリケーションとWebサイトのデザインの違いからみるCSS設計 /@potato4dさん

speakerdeck.com

色々なCSS設計がうたわれてるけど、本当にそれっていつでも万能なのかしら?的なお話。

ちょっとあんまりついていけてなかったので、すこしあやふやですが… webアプリケーションにおいてはパーツをどんどん組み合わせる形になるから有効的。だけど webサイトにおいては時と場合によるよねって感じだったと思う。

現場慣れしてる人の言葉って感じで重みがありました。 実際にチームの人と、かけれるコストと相談で折り合いをつけていくことベストなんだなと 改めて思いました。 考えないのはあまり良くないけど、とりあえず評判のものをいれたり、ルールに 縛れることで本来解決したかったことを見失わないようにしなきゃいけないなと 思いました。


FileAPIでJavascriptを使ったファイル操作

FileAPIを利用するとJavascriptを利用してファイルの中身を取得する事が出来ます。

各種ブラウザの実装状況は caniuse から確認可能です。

http://caniuse.com/#feat=fileapi

File API を利用する

FileAPIに対応したブラウザでは、input[type=file]のHTML要素からFileオブジェクトを取得する事が出来ます。

DOMのオブジェクトにfilesというキーが生えており、ココに配列形式でFileオブジェクトが格納されている形になります。 (input[type=file]ではmultipleプロパティを指定して複数ファイルの選択が可能)

jQuery で利用する場合

jQuery ではinput要素を選択する事で、DOMを取得できます。

$("input[type='file']")[0].files

イベントで利用する際には、eventオブジェクトのtarget属性からデータを取得します。

$("#fileForm").on("change",function(e){
  console.log(e.target.files[0])
  console.log(this,e);
})

Fileオブジェクトを利用するとファイルに関する様々な情報が取得可能です。

  • lastModified: 最終更新日時
  • name: ファイル名
  • size: ファイルサイズ
  • type: mime

Fileの中身そのものを読み取るには、非同期のFileReaderを利用する必要があります。

File Reader でファイルを取得する

ファイルの読み込みは非同期に行われ、readerオブジェクトに登録したイベントから読み込み完了後のイベントを取得します。

var reader = new FileReader();
reader.onload = function(event) {
    console.log(event.target.result)
}
reader.readAsDataURL(file);

readerオブジェクトのイベントは、onloadの他にも様々なものがあります。

  • onabort : 読み込み処理が中断された際にイベントが発火
  • onerror : 読込中にエラーが生じたときにイベントが発火
  • onload : 読込が成功したときにイベントが発火
  • onloadstart : 読込が開始されたときにイベントが発火
  • onloadend : 成功・失敗に問わず読込が終了したときにイベントが発火
  • onprogress : ファイルの読込中にイベントが発火

各イベントでは、targetプロパティからreaderオブジェクトを参照することができ、各種プロパティを参照することでファイルの読み込み状態を参照可能です。

  • error : ファイルの読込中に発生したエラー
  • readyState : 状態変数を格納するプロパティ(0: 読み込み前、1: 読込中、2:処理終了)
  • result : 読み込み完了後に有効となるファイルのコンテンツを格納するプロパティ

ファイルの読み込みはreadAsDataURL()メソドにfileオブジェクトを渡して行います。

データはresultプロパティにdataURL形式で格納されます。

生のテキストデータを取得するためのreadAsText,生のバイナリデータを取得するためのreadAsArrayBufferなどのメソドも利用可能です。

ファイルの読み込みを中断するにはabortメソドが利用可能です。

参考

Laravelで学ぶRestAPI設計

chatboxオフィスにて RestAPIの制作入門セミナーを実施します

chatbox 本町オフィス(地図)にて、Laravel を利用したRestAPIの設計入門セミナーを実施します。

leccafe.connpass.com

近年開発需要の高いRestAPIの設計ノウハウや、開発手法について学んでみませんか?

Laravel で作る RestAPI設計

Laravel はPHP界隈で話題のフレームワークで、最近では多くの場面で利用されることが多くなりました。

laravel.com

SPAなどを中心とするフロントまわりのアプリケーション開発でも、このLaravelを活用してRestAPI開発を進める事が出来ます。

通常のページベースでのPHP開発とことなり、Javascriptとの連携が中心となるRestAPI開発では、

設計の観点や、開発手法等に幾つか違いあるため、なれないうちには苦労する事も多いかもしれません。

特に初めてRestAPI開発にチャレンジする際には悩みがちな、

レスポンスフォーマットの仕様決定についてや、開発のフローなどを、

RestAPIの開発経験豊富なスタッフが、実際の開発経験を元に説明していきます。

設計の観点や、開発効率化の手法、テストのフローなど、

これからRestAPIを用いた開発を始めようとする人には必見の内容となっています。

Laravelで学ぶRestAPI設計 は2016/05/28 15:00〜

chatbox 本町オフィス(地図)にて実施します。

ご参加希望の方は下記Connpassページ 募集サイトよりお申し込み下さい!

leccafe.connpass.com

Vue.js で SPA制作学んでみませんか?

chatboxオフィスにて SPA アプリケーションの制作入門セミナーを実施します

chatbox 本町オフィス(地図)にて、SPA(Single Page Application)の制作入門セミナーを実施します。

leccafe.connpass.com

近頃話題のフレームワーク Vue.js を利用した入門向けセミナーとなりますので、ご興味の方は是非ご参加下さい。

Vue.js って?

Vue.js はJavaScript でリッチなアプリケーションを作成するための、JSフレームワークと呼ばれるライブラリの1つです。

jp.vuejs.org

最近は version2 の発表などで何かと話題になっています。

version 1 と 2 では高い互換性が維持されるようで、この機会に是非version1からVue.jsの使い方などを学んでみませんか?

JSフレームワークといえば、AngularJSが何かと話題だったりしますが、

Vue.js はAngularJSに比べて比較的学習コストが低いと言われており、初心者の方にも安心の制作ツールとなっています。

PHP界隈で話題のLaravelというPHPフレームワークでも、JSフレームワークにVue.jsを採用する動きがあるなど、

多方面で何かと話題を集めている、今まさにHotなJSフレームワークです。

日本語ドキュメントも充実しており、英語が読めない人でも気軽に学習していけるので、是非この機会にVue.jsお試し下さい。

Vue.js で作るSPA制作入門は2016/05/20 20:00〜

chatbox 本町オフィス(地図)にて実施します。

ご参加希望の方は下記Connpassページ 募集サイトよりお申し込み下さい!

leccafe.connpass.com