■CALENDAR■
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
<<前月 2024年11月 次月>>
■Twitter■
■AD■
↓家電が何でも安い!↓
家電エクスプレス(ケーズ電気系)
■NEW ENTRIES■
■RECENT COMMENTS■
■RECENT TRACKBACK■
■CATEGORIES■
■ARCHIVES■
■LINK■
■PROFILE■
■LOGIN■
現在のモード: ゲストモード
USER ID:
PASSWORD:
■POWERED BY■
BLOGN(ぶろぐん)
BLOGNPLUS(ぶろぐん+)
■OTHER■
■COUNTER■
  •  now  visiter(s)

先日、mixiを見ていて、「ヒッチハイク」に関するコミュニティーが目に付いた。

近頃、ガソリン代が急騰して、世界中の人が運賃の値上などで家計を圧迫されていることと思う。
実はこういった動きはエコに興味がある私自身は好ましいと思っているんだけど、それが行き過ぎちゃうともはや自動車を趣味として維持すること自体が難しくなってくるんだよね。
まぁ、あんまり“モノ”には執着心がないほうなので、そんなときに夢中になる違う趣味も沢山在るので、なかなかお金は貯まらない訳なんだけどさ。


しかし、世間は“お盆”。高速道路は軒並み数十km~100km超の大渋滞ですよ。
もちろん家族連れが多いんだろうけど、半数くらいは座席は空いていると思うんです。

で、思ったわけですよ。『ヒッチハイク(相乗り)が出来れば、おもいっきり「エコ」じゃん!』って。




そこで、必要なものはやっぱりWEBアプリケーションですよ。名づけてi-NORI(あいのり)システム。
「ヒッチハイクしたい人」と、「乗せてもいい人」のための、いわゆるP2Pシステムですね。


ヨーロッパでは40年前からフランス発の「アロー・ストップ」というシステムが普及しているらしいです。
さすが合理主義の国。
合法ヒッチハイクで、エコロジー - フランスのエコライフ - 環境goo


しかし、克服しなければならない課題も数多く存在しています。


例えば、やっぱり気になるのは「<em>初めて会う人がどんな人か</em>」ですよね。
コレは事前登録の属性を細かく設定することが必要になると思います。
ヒッチハイカー側としては、性別・年齢はもちろん、体型や趣味など、同じ空間で長い時間を一緒に過ごす際に気になる情報を出来るだけ多く出した方が、高感度UP!ってモノですよ。
ここはほとんど自己紹介になるでしょうから、SNSの要素を取り入れることになりますね。
もちろん、キャリア側も乗っている車種や喫煙の有無・寝てもいいか・音楽の趣味等々、コレも情報量が豊富な方が喜ばれるでしょうね。


あと、アメリカでは<em>ヒッチハイクを装った強盗</em>が相次ぎ、全米で法律で禁止されてしまったらしいです。
上で揚げたSNS要素も、実際にそれらの情報が正直なものなのかという点も怪しいところです。
そこで、Web2.0的要素を借りて克服するわけですよ。
そのソリューションは『評価制度』です。
オークションや宿泊施設予約などで取引が終了した後にお互いを採点しあう制度ですね、それをヒッチハイカーとキャリアの両方に適用します。


と、解決策は存在して、実際に運用することも可能ではありますが、その運用に脆弱な点があります。
仲間同士で共謀して評価をUPさせることには対応しにくいのです。
しかし、仲間同士の利用を禁ずるのはこのオープンなシステムの趣旨に反するところでもあります。


それらの脆弱性を考慮すると、システムが不正無く利用されることを担保するための仕組みがまだまだ必要ですね。


<em>金銭の授受を発生させるか否か</em>も課題の一つです。
先に書いたmixiのコミュニティーでは、交通費は相乗りした区間のガス代・高速代をワリカンすることで、双方の費用負担を低減しているところがポイントであると感じました。しかし、元々ヒッチハイクというのは無料のものではなかったでしょうか。
そこは考え方だと思いますが、要するにカーシェアリングに近い発想で、『区間限定カーシェアリング』と定義し、ヒッチハイカー側にも費用負担を強いることにより、キャリア側に対する啓発にも有効でしょう。
ただねー。この部分、実際に乗るときに支払うのか、それともWebシステム経由で支払うのか、その辺りは非常に重要なだけに、どう決めればいいのか考えあぐねています。


他には、実際にヒッチハイクする側がどのようにその情報を登録するか。
「○月○日○時頃、△△市周辺⇒××県方面」という情報を、どのように検索しやすく格納するか、ということも重要なファクターです。そのためにGoogleMapのAPIを利用して、緯度・経度情報として保存するのもいいかもしれませんし、あるいは路線情報を利用して、沿線から検索したりするという方法もあります。この辺りは複合型にするのがいいかもしれませんが、緯度経度と違って、駅の情報は常に変更が生じるので、それがASP形でモジュール提供されていると便利なのですが…


そして、キャリア側も、今度は点ではなく線のデータになるので、例えば通過する高速道路の情報と予定通過時間を、線で検索できると便利です。しかし、どんなアルゴリズムを用いればいいのか、、、Perlでスパゲッティプログラムしか書けない私には全く見当もつきません┐(´・ω・`)┌


と、言うわけで、Webアプリケーションベンダの方、このアイデアを買っていただけませんか?w

| 妄想 | 06:53 AM | comments (0) | trackback (x) |










PAGE TOP ↑