自然流水と法律

ちょくちょく、木曜日のひるおび!で放映されている八代弁護士のコーナーをチェックしています(キャッチコピーが「大人の女性たちに贈る大型情報番組」となっていて微妙な気分)。先日は、自然流水に関するトラブルが取り上げられていました。あまりメジャーではない領域ではありますが、現実には多くのトラブルが眠っている領域だと思います。

甲は、趣味の家庭菜園を自宅の庭に持っているが、隣家の乙に悩まされている。雨が降ると、一段高い場所に建っている乙の家から雨水が甲の家の敷地に流れ込み、家庭菜園が水浸しになってしまうのである。先日の台風では記録的な降水量となったため、大量の雨水が甲の家庭菜園に流れ込んだことで、すべての植物が流されたり、腐って枯れたりしてしまった。甲は、乙に対して何らかの請求をすることができるか。

このような場合、甲は、乙に対して、損害賠償を請求することはできないのが通常です。

(自然水流に対する妨害の禁止)
第二百十四条 土地の所有者は、隣地から水が自然に流れて来るのを妨げてはならない。

民法214条は、自然流水を妨げてはならないと規定しています。これはつまり、自然に水が流れてくるのであれば、それを受け入れなければならないということです。これは承水義務と言われています。自然に流れてくる水によって何らかの損害が生じたとしても、上流の人に文句を言うことはできないということになります。そのため、損害賠償を請求することができません(民法709条における過失が認められない)。

甲は、趣味の家庭菜園を自宅の庭に持っているが、隣家の乙に悩まされている。雨が降ると、乙の家の屋根から甲の家の敷地に雨水が直接流れ込み、家庭菜園が水浸しになってしまうのである。先日の台風では記録的な降水量となったため、大量の雨水が甲の家庭菜園に流れ込んだことで、すべての植物が流されたり、腐って枯れたりしてしまった。甲は、乙に対して何らかの請求をすることができるか。

このような事案ではどうなるでしょうか。先ほどの事案に基づいて考えると、この事案においても甲は乙に損害賠償を求めることができないように思えます。しかし、乙の家の屋根から直接に甲の家の敷地に雨水が流れ込んでいるという状況は、自然に水が流れてくる場合であるといってよいのでしょうか。民法は、次のような規定を置いています。

(雨水を隣地に注ぐ工作物の設置の禁止)
第二百十八条 土地の所有者は、直接に雨水を隣地に注ぐ構造の屋根その他の工作物を設けてはならない。

民法218条の存在により、この事案においては、甲は乙に対して損害賠償を請求することができます(民法709条の不法行為責任)。

甲は、趣味の家庭菜園を自宅の庭に持っているが、隣家の乙に悩まされている。雨が降ると、一段高い場所に建っている乙の家から雨水が甲の家の敷地に流れ込み、家庭菜園が水浸しになってしまうのである。先日の台風では記録的な降水量となったため、大量の雨水が甲の家庭菜園に流れ込んだことで、すべての植物が流されたり、腐って枯れたりしてしまった。甲は、乙に対して何らかの請求をすることができるか。なお、甲の土地は乙が所有しており、甲は乙から借地しているものとする。

最初の事例と同じように見えますが、甲と乙の土地が自己所有の場合ではなく、甲が乙から土地を賃貸しているような場合です。番組ではちらっと触れられているだけでしたが、個人的には「なるほど」と思ってしまう事案でした。民法は奥が深い。

さて、この場合、甲には承水義務があるので、乙には何も請求できないようにも思えます。確かに、不法行為責任を追及することはできません。しかし、この場合における甲と乙には、土地の賃貸借関係という、最初の事例にはなかった事情が存在します。このとき、甲は乙に対して、契約上の責任を追及するという、別の道が用意されているのです。

(債務不履行による損害賠償)
第四百十五条 債務者がその債務の本旨に従った履行をしないときは、債権者は、これによって生じた損害の賠償を請求することができる。債務者の責めに帰すべき事由によって履行をすることができなくなったときも、同様とする。
(賃貸借)
第六百一条 賃貸借は、当事者の一方がある物の使用及び収益を相手方にさせることを約し、相手方がこれに対してその賃料を支払うことを約することによって、その効力を生ずる。

賃貸人は、目的物を賃借人に使用収益させなければなりません(その対価として賃料をもらっているわけです)。乙の家から雨水が流れ込んでくることによって家庭菜園が正常に営めないというのであれば、それは甲の土地が正常に使用できている状態にあるとはいえません。賃貸借契約の特約で家庭菜園を作ることが排除されているのならばまだしも、一般的な住宅用の土地においては、家庭菜園を作ることが容認されていると言っていいでしょう。そのため、乙は、甲に対して家庭菜園を作ることができるような状態に保たなければならないという、賃貸借契約上の義務を負っていることになります。本件では、甲の腕が悪いために植物が育たないというのではなく、大量の雨水によって流されたり腐ったりしてしまうという状態にあるのですから、乙には契約上の義務違反が認められます。そのため、民法415条に基づく損害賠償を請求することができるということになります。

ルームドナーから考えたこと

NHKのニュースを見ていたら、roomdonor.jpというサイトが紹介されていました。3月11日の東日本大震災で住むところを失った人たちに対して、貸し出すことのできる家や部屋を登録することができるというサイトです。ポイントは、営利目的の賃貸物件をあっせんするサイトではない、というところです。登録できるのは非営利目的の不動産に限られ(利用規約に明記されている)、被災者は無償で家や部屋を借りることができます(光熱費等は自費負担とする場合もある)。

今回の大震災は、市民の生活基盤を根こそぎ破壊してしまう規模のものでした。また、原子力発電所の事故により、広範囲において人が住むことのできない地域が生じてしまいました。そのため、住居を確保しなければならない被災者の方々が数多く現れることになったのです。このようなニーズに対して、営利目的の企業は役立ちません。被災者は資産をも失っていることが多いので、住居に対する対価を支払う余裕がないのです。そのため、このroomdonor.jpは、被災者のニーズを満たすことのできる、有益なプロジェクトであると思います。うまく、費用をかけずに住居を確保したいという被災者のニーズと、手持ちの不動産を使って被災者を支援したいという人々のニーズをマッチングさせているといえるでしょう。

しかし、わたしは、このプロジェクトに引っかかるところがありました。

「被災者には無償で提供します」という姿勢、果たして本当に手放しで褒めることのできることなのでしょうか。一見すると、お金にこだわらず、被災者を支援したいという純粋な心で動いていることから、実に素晴らしい、できる限り広めるべきだ、と感じます。しかし、住むところがなくて困っている人々は、被災者以外にもたくさんいます。ネットカフェを渡り歩いている人々、公園に寝泊まりしている人々、最近の景気低迷による派遣切りなどで、住むところを失っている人々は増え続けているようです。そのような人々と、被災者の違いは一体何なのでしょうか。

これまで人並みの生活をしていたところ、急に地震などによって住むところを失ってしまい、路頭に迷ってしまった。そのような人々に対しては、かわいそうだ、なんとかしてあげたい、と思うのが普通でしょう。だから、住むところを提供したい、支援してあげたい、と思うのも納得できます。一方で、たとえば派遣切りにあって手持ちの資金がなくなってしまい、アパートなどを出なければならなくなってしまった人々に対しては、そのような感情は起こらないのでしょうか。そのような道を選んだのは自己責任であって、震災のような自然現象が原因でいまの状況に追い込まれたのではないから、住むところを持っていても提供する気は起きず、支援してあげる必要もない、自分で努力してくれ、ということになるのでしょうか。それはどこか間違っているように思います。世界経済の状況が変わるのは、誰にも予想できることではありませんから(関東大震災がいずれ起こるというようなレベルでの予想はできるかもしれませんが)、自然災害と似通ったところがあります。また、稼ぎたいと考えても、自分だけがそう思っていても何ができるというわけではありません。人によって事情が異なるので、一般的な結論を出すことはできませんが、住むところを失い、たとえばネットカフェの住所で住民登録をしているような人についても、住む場所を同じように無償で提供するようなネットワークがあってしかるべきではないでしょうか。このような問題は、以前からありました。しかし、先に作られたのは、被災者向けの検索サイトです。

なにも、roomdonor.jpの存在がおかしいと言っているわけではありません。存在価値が高いサイトだと思いますし、その活動は続けていくべきだと思います。しかし、どうして、被災者のことになると俄然やる気が出てくるのか、いろいろなサービスや支援が出てくるのか、そこが引っかかるのです。

他人に何かを伝えるには、プレゼンテーションをしなければなりません。その手法がうまいものであればあるほど、伝えたい内容は正確に伝わっていきます。一方で、その手法がうまくないと、伝えたい内容は伝わっていきません。それがどれだけ深刻なものであっても、受け手はそのように受け取りません。東日本大震災は、すべての国民に対して「これは非常事態です! なんとかしてください!」というメッセージが伝わりやすいものだったのでしょう。roomdonor.jpを作った方は、大量の帰宅困難者を目の当たりにして、なんとかしなければならないと思ったそうです。これまで見たこともない、非日常的な光景は、最高によく伝わるプレゼンテーションであったということなのでしょうね。一方で、派遣切り等の問題で住居を失った人々については、自己責任という印象で片付けられてしまい、その深刻さがうまく伝わらなかったのかもしれません。

とくに、何をしなければならないと主張したいわけではありません。ただ、このような国が、日本なのだろうなあ、と思っただけのことです。

Ruby on Rails挫折

こんなところ読んでいる人がいるのか分かりませんが、ことの顛末は書かなければならないと思いますので、書いておきます。

2か月ほど前に「Ruby on Railsでアプリを作る!」と意気込んでいたのですが、その意気込みは、日数が経過して完全に消滅してしまいました。なぜかというと、Ruby on Railsで開発することの「まずさ」が予想以上に大きかった、時間が経過するにつれて考え方が変わった、という理由によります。

最初、次のような理由からRuby on Railsを使おうと考えていました。

  • 書かなければならないコード量が少ない。
  • Rubyで書ける!
  • データベースの種類を気にせず、データベースの恩恵を受けられる。
  • HTML部品が使えるので、プレゼンテーションが比較的容易。

しかし、作っていく中で、次のように考えが変わってきました。

  • 単体で動作するアプリケーションとする場合、ウェブサーバを立てなければならない。それがRuby on Railsに付属するものであったとしても、手軽さは減少する。
  • デバッグがやりにくい。起動して、走らせてみて、動作チェックするというプロセスに(スタンドアロンのプログラムと比較して)時間がかかる。

なんとなく、Ruby on Railsは最初に設計をしっかりと行ったうえで、ある程度の見通しを立ててから作るスタイルなのだと感じました。だとすると、行き当たりばったりで作っているようなホビープログラマには向かない環境だということになります。

もちろん、使い始めて間もないので、今回苦労したあたりを楽にするツールもたくさんあるのだろうと思います。しかし、それを教えてくれる環境もないですし、自ら探すのも面倒に感じます。

そんなわけで、Ruby on Railsでなにかを作るという計画は、いったんお蔵入りとし、続く記事は書かれないということになります。いつか、Ruby on Railsに適したアプリケーションを作ろうとしたとき、また触れるかもしれません。

Pure JavaなHTMLレンダリング

CobraというPure JavaなHTMLレンダラーがあるそうです。オープンソースで開発が進められており、HTML4、Javascript、CSSがサポートされているとのこと。性能のほど(レンダリングの質)はまったく確認していないのですが、JavaでHTMLを扱うソフトウェアを開発するときなど、役に立つ場面もあるのではないでしょうか。

ちょっと気になるので、いつか使ってみようと思います。

Ruby on Rails – 開発中のテーブル調整

「最初にガチガチに設計してから開発する」というスタイルをとらない場合(個人開発・趣味開発の場合はほとんどがあてはまると思います)、開発が進行するに伴って、モデル(データベーステーブルの設計)を変更していきたいと思うはずです。

このようなとき、先の記事にも書きましたが、db/migrateにあるファイルを変更するだけでは、データベースに反映が行われない場合があります。正しくは、マイグレーション機能を使ってインクリメンタルに変更していかなければなりません。しかし、個人で開発する場合、これは面倒です。テーブル数が少ない、カラム数が少ない、といった小規模開発の場合は、とくに当てはまります。

そんなわけで、たぶん正しいやり方ではありませんが、db/migrateのファイルを直接編集する場合の力技的な方法をメモしておきます。

1
2
3
$ rm db/migrate/*.sqlite3 db/schema.rb
$ rake db:create
$ rake db:migrate

要は、データベースファイルとスキーマファイルを削除して、データベース関連ファイルを再構築するだけです。すでに完成したバージョンの上で動かしたい場合は、その時点のデータベースファイルとスキーマファイルを保存しておいて、巻き戻したいときはそれらのファイルで上書きコピーしてしまえばいいということになります。このとき、編集するdb/migrateのファイルを間違えないように注意(そんなことはしないと思いますが…)。

Ruby on Rails – データベースのマイグレーション

Ruby on Railsで開発中、「このテーブルのカラム名を変更したい」「このテーブルの構造を変更したい」といった事態が生じると思います。

こんなとき、最初はdb/migrateの下にできたファイルを編集すればいいのだと思っていました。しかし、いくら変更しても、追加したカラムが反映されない。どうもおかしい。なぜだろう、といろいろ見てみると、db/schema.rbというファイルでデータベースの構造を管理していることが分かりました。こちらも編集すると、追加したカラムなどが反映されます。

しかし、このような方法は推奨されない、というかやってはならないものみたいです。rails generate modelした直後に変更するなどならまだしも、以前に作られたものを変更するなどすると、もはや元に戻せなくなり、困ったことになりかねません。ちょっとした変更でも、ちゃんとジェネレータを介して操作した方がいいようですね。

Ruby on Rails – コントローラのメソッド

Ruby on Railsは、さまざまな「慣習」を用いて、コーディングしなければならない分量を減らす作戦を用いています。

コントローラのメソッド名も、そのなかの一つ。こういう「暗黙のルール」をまとめておいてくれる場所って、ないものですかねえ。まあ、ドキュメントの全部を把握していない段階では、すべてが「暗黙のルール」に見えるわけですけれども。いや、ドキュメントに書かれていれば「明示のルール」なのかな?

それはさておき。

RailsGuidesのRails Routing from the Outside Inによれば、HTTPリクエストの命令とパスによって、コントローラのうち呼び出されるメソッドが決定されるとのことです。ドキュメントの位置からも分かるとおり、これは「ルーティング」に分類されるルールです。リクエストに応じて適切なコントローラのメソッドを呼び出すのですから、確かにルーティングですね。

ただし、これは自動的に設定されるわけではなく、routes.rbで明示的に指定する必要があります。

1
resources :controller1, :controller2, ...

なお、resourceではなく、resources(複数形)なので注意してください。単数形の方は、パスの中にIDを含まない(パラメータでIDを指定する)ものになります。複数形の方は、パスの中にIDを指定するものになります。

resourcesで使用されるメソッド名は、次の7つです。

メソッド名 対応するHTTPリクエスト
index GET / パス=/example
new GET / パス=/example/new
create POST / パス=/example
show GET / パス=/example/[ID]
edit GET / パス=/example/[ID]/edit
update PUT / パス=/example/[ID]
destroy DELETE / パス=/example/[ID]

コントローラでこれらのメソッドすべてを実装する必要はありませんが、特定のHTTPリクエストが送られてきたとき、対応するメソッドが定義されていないとエラー(ページ)が返されます。

Ruby on Rails – 先人の軌跡

探せばあるもので、Ruby on Railsの基本的な部分については、「Ruby on Rails 3.0 日記」で解説がなされていました。Railsを以前から使っている方が書いた記事のようで、ちゃんと「分かっている」方が書いた内容となっています。また、スクリーンショットも多用されているので、分かりやすいないようになっています。

すでにいろいろと書きましたが、ぜんぶ忘れてください(笑)。上記記事を参照すれば、Ruby on Railsの基本的なところは分かると思います。

ここでは、作業記録的なものを書いていこうと思います。

Ruby on Rails – 設計

Ruby on Railsが動作するようになったところで、アプリケーションの完成形をイメージしていきます。抽象的な事項(アプリケーションが提供する機能)は先に掲げたとおりですので、その機能を提供するための具体的な方法や手順について考えていきます。これにより、アプリケーションがどのようなウェブページを提供しなければならないのか、そして何を作らなければならないのか、明らかになっていきます。

Anacondaは、情報源を外部に頼ります。そのため、「どのような情報が存在するのか」をシステムに知らせてあげなければなりません。情報はIDによって識別するものとします。Evernoteは各ノートにGUIDを割り当てているので、このGUIDをIDとして使えばいいでしょう。Spiderで考えれば、ネットワークのGUIDと、情報オブジェクトの番号を組み合わせた文字列がIDになります。Anacondaは、まず最初に、このID収集を行う必要があります。IDを収集する際、同時に、どの情報源から取得したのかも記録しておく必要がありますね。

使用する情報のIDが集め終わったら、反復学習を始めることができます。以前にチェックした日時と、そのときのユーザー評価から、表示すべき状態にある情報を選び出し、表示します。そして、ユーザーは表示された情報についてチェックし、もう表示する必要はない、ある程度分かったので次のチェックは先でよい、分かっていなかったので次のチェックは近くに行う、などの評価を与えます。メモを残せるようにしてもよいですが、現時点では見送ることにしましょう。ある情報についてチェックが終わったら、次の情報を表示します。表示すべき状態にある情報が無ければ、その日の分は終了したということになります。

なかなか理解が進まない情報や、全体に対する進捗情報などを確認する、分析的な処理もあると便利ですね。しかし、これも現時点では見送ることにしましょう。いつか追加する予定がある、という程度に捉えておきます。

以上から、Anacondaが提供すべきウェブページは、次のようになります。

  • ID収集・学習などの機能へ分岐するトップページ。
  • ID収集のため、収集元を選択するページ。
  • 表示すべき状態にある情報を表示し、それに対する評価を与えるためのページ。

とりあえずは、トップページから作っていくことにしましょう。

とは言ったものの、何を編集すればよいのか分かりません。Ruby on Railsのガイドを見ながら進めていくことにします。

まずはアプリケーションを作成します。

1
$ rails new Anaconda

詳しい仕組みはまだ分からないのですが、サイト上のルートディレクトリはプロジェクト上のpublic/に相当し、ここにindex.htmlというファイルが存在すれば、これを読み込むようです。静的なウェブページを使うことはないはずなので、削除してしまいます。すると、ルーティングに失敗するというエラーが出るようになります。ルートディレクトリについて表示すべきファイルがないため、エラーが出ているようです。そこで、表示すべきページを作成することにします。これは、Ruby on Railsが提供する機能を使って自動的に行うことができます。

1
$ rails generate controller index home

次に、ルーティングを行うファイルに、ルートディレクトリとして表示すべきものの位置を教えてあげる必要があります。config/routes.rbを開き、次の行を書き加えます。

1
  root :to => "home#index"

ルートとして、"home#index"を指定するという意味です。これは、コントローラhomeindexメソッドを表しており、homeというページのindexというラベルを表すものではありません。ここまで書き加えれば、サーバを起動して、http://localhost:3000にアクセスすることで、homeコントローラのindexメソッドが呼び出されていることを確認できます(表示されているのはビューhomeindex.html.erb)。

ところで、config/routes.rbには、次の行も追加されています(railsコマンドで自動的に追加される)。

1
  get "home/index"

これは、パスhome/indexに対するHTTPのGETリクエストを許可するという意味です。呼び出されるのは、homeコントローラのindexメソッドになります。この行を取り除く前はhttp://localhost:3000/home/indexに対するアクセスが成功し、取り除いた後はhttp://localhost:3000/home/indexに対するアクセスがエラーを返すようになります。home/indexは使わないので、取り除いておきます。

サーバの起動は、次のようにして行います。

1
$ rails server

いきなり「コントローラ」や「ビュー」という言葉が出てきました。これは、MVCモデルのControllerとViewのことです。Ruby on RailsはMVCモデルを採用しています。これによって、論理のコードと表示のコードを分離することができ、開発を局所に集中して行うことができるようになります。なお、Rubyはとても緩い言語ですので、表示に関する処理のみをすべきであるビューに、データ操作に関する処理を入れてしまうことができます(たぶん)。これをやるとMVCモデルを採用している意味が完全に失われてしまうので、自分がいまどの部分について作業しているのか、しっかりと自覚しておく必要があります。まだModelが出てきていませんけれども、じきに登場します。

Ruby on Rails – 下準備

Ruby on Railsはスクリプト言語Rubyで動作するので、まずはRubyをインストールするところから始めます。なお、環境はWindowsです。

Rubyの公式サイトからダウンロードしてもよいのですが、RubyInstallerというパッケージを使うのも楽です。これは、Windows用にRubyをビルドした環境をパッケージにしたものです。実行形式のインストーラーもあるので、楽ではあります。単にアーカイブしただけのパッケージもあるので、変なインストーラーは使いたくないという方は、そちらも使えます。使うRubyのバージョンは、もちろん最新版(執筆時点で1.9.2)。いまさら1.8系を使うのも、時代遅れというものです。幸いなことに、Ruby on Railsも3.0以降はRuby 1.9をベースにしているようです。

次に、Ruby on Railsをインストールします。

Rubyを使える状態にして(環境変数PATHにRubyの実行ファイルが格納されたディレクトリを追加する)、Rubyのパッケージマネージャgemを使えるようにしておきます(いまは標準添付されている?)。ここまでできたら、gem install railsするだけです。

1
$ gem install rails

自分の環境では、マニュアルをコンパイルしているところでエラーが発生しました。しかし、全体としては問題なく動作しているので、無視しています。何も指定しなければ、安定した最新版がインストールされることになるでしょう(執筆時点で3.0.9)。

次に、SQLite3をインストールします。これは必須ではないのですが、開発段階からMySQLなどフルセットのデータベースを使うのは設定が面倒ですから、それらの面倒を省くことのできるSQLiteを導入しておいた方が楽だと思います。

まず、gemで必要なRubyライブラリをインストールします。

1
$ gem install sqlite3

次に、SQLiteのホームページからsqlite3.dllをダウンロードします。ダウンロードしたら、適当なディレクトリにDLLを展開し、環境変数PATHを通します。ここまで終わったら、正常に動作するか、チェックしておきましょう。

1
$ ruby -e 'require "sqlite3"'

さて、ここで、rake 0.9以降を使っている場合(?)、rakeがうまく動作しないという問題があります。理由はよく分からないのですが、こちらで紹介されている解決方法を実行すると、確かにエラーが出なくなりました。どうやら、rakeのバージョンによって挙動が違っているようで、それが悪さをしているようです。この対処により正しく動作しているような感じですが、まだちょっと分かりません(のちに検証して追記するなどします)。

まだ方法は紹介していませんが、作成したプロジェクトにあるGemfileに次の行を書き加えます。

1
gem 'rake', '0.8.7'

そして、次のコマンドを実行します。

1
2
$ bundle unlock
$ bundle update

こちらの情報によれば、Gemfile修正後、次のコマンドを実行するのでもいいようです。

1
$ bundle update rake

ちなみに、bundleとはBundlerというプロジェクトが提供するプログラムで、アプリケーション相互の依存関係を管理するために作られたものだそうです。

Ruby on Railsは素晴らしいフレームワークですが(そうなのだそうだ)、さまざまな技術を利用しているので、「果たしてこの機能は何が提供しているんだろうか?」と疑問に思ってしまうことがしばしばです。なにやら、Active Supportという、Rubyの標準ライブラリに(ウェブアプリ開発に)便利な機能を多数追加するという芸当をやっているそうで、これも「果たしてこの機能はRubyが標準で提供しているものなのだろうか?」と思ってしまうことが多いそうです。おいおい分かってくると思いますが、「どこまでがRailsなのか」をしっかり把握しておくようにしたいと思います。まあ、そのうち、そんなことを考えなくてもいい時代が到来するのかもしれませんが。