「熊野寮で電子化した話」というタイトルでLTした

bit-valley.jp

先日BIT VALLEY 2018というイベントがあり、そのAFTER PARTY(懇親会)で「熊野寮で電子化した話」というタイトルでLTをした。

これがその時のスライド。

熊野寮で電子化した話 from Yusuke Sangenya

内容としては、手作業の塊みたいな地獄のタスクがあり、これをWebアプリ化して担当者の仕事量を削減したという話。

LTをやったのは僕の他にも2人いて、うち1人とはうっかり内容が被ってしまうところだった*1。

• 遺伝的アルゴリズムでシフト組みを自動化した話 - Speaker Deck
• 勢いだけで起業して壁にぶち当たった話(スライド未公開)

LTなので5分という制約があり、また会場の客層もよくわからなかったため、あまり詳細な話はしなかった。この記事でもっと詳しく書こうと思う。

（LT自体は結構うまくいったと感じていて、笑いも2つ3つとれたので満足している）

作ったWebアプリケーションの説明

スライドにだいたい書いた。ここではスライドに書いていないことを補足する。

このアプリの主な機能は以下である：

• シフト提出をする
• シフト提出を一定時間ごとにメールで催促する
• シフトを作成する
• 作成したシフトをメールで通知する
• 各寮生の仕事回数をカウントする

今回も Ruby on Rails をつかった*2。また、サーバーとしてはConoHaを採用した。*3*4。コードはgithubで管理しているが、デプロイ情報が載っているので公開はしない。デプロイはtravis ciとcapistranoを使っている。capistrano初めて使ったわ。自動デプロイ便利だね。

仕事を電子化するということ

熊野寮は50年も前からある組織だ。50年前はスマートフォンなど存在しないので、紙とペンと人力に頼った手続きで仕事が行われていた。その手続きが50年間引き継がれ、未だに人力で仕事が行われている。Japanese Traditional Big Companyも真っ青なアナログさである。スライドで紹介した「シフト組み」という仕事は、まさにこの”アナログな仕事”の一例だ。

アナログな仕事には良い面もある。原始的なので誰でも理解できるし、「人はスマートフォンを持っている」という仮定を置かなくても良い*5。 一方で、こういう仕事のやり方は非効率的で担当者の負担も大きい。人間の労働力に大きく依存するので、人間のやる気がなくなったときに適切に仕事が執り行われなくなる。

そういう問題意識から今回発表したようなWebアプリケーションを作った。結果として、実際に担当者の仕事が減って喜ばれている。しかし、都合の良い事ばかりではない。というのも、このWebアプリケーションをメンテナンスできるのは現時点で僕しかいないのである。障害が起こったら僕が直すしか無いし、修正や機能追加が必要になったら僕がやるしか無い。今までシフト組み担当者が抱えていたタスクを、代わりに僕が抱えるようになっただけと見ることもできる。

とはいえこちらの仕事は人力の仕事とは違って、一度労力を払ってしまえば以降は同じ苦労はしなくて済む。長い目で見れば仕事の量は減っていると信じたい。

仕事回数が可視化された話

また、人間の仕事量が減ったことで、以前ではできなかったことができるようになった。それは、「誰が何回シフトに入ったのか」をシフトを組んだ瞬間にカウントするということである。

大前提として、熊野寮での仕事は無給である*6*7。従って、仕事を平等に負担するということが重要になってくる。

では、仕事を平等に負担させるにはどうすればよいだろうか？まずは、仕事の偏りを明らかにする必要がある。つまり、「Aさんはもう10回もシフトに入っているが、Bさんはまだ1回しかシフトに入っていない」という情報をひねり出す必要がある*8。 アナログ時代は、年度末にシフトの紙をかき集めて、誰が何回仕事をしたのかを手作業で集計していた。 そして、仕事回数が少ない人間には圧力をかけて、もっと仕事をするように要請していた*9。

このやり方には問題がある。年度末にならないと仕事の偏り具合がわからないのである。このため偏りの是正は後手に回ることになる。最悪なケースとしては、仕事を全くせずに2月ぐらいに退寮していくカス面の皮が厚い人間などもいる。

電子化したことで仕事回数が即座にカウントされるようになった。これにより、回数が少ない人間に対して先手を打って圧力をかけることが可能になった。では、回数の偏りは実際に是正されたのか？電子化してからまだ半年しか経っていないのでまだなんとも言えないが、現時点ではそれほど大きな偏りは見られない。これに関してはまた別の機会に考察できたらと思う。

引き継ぎの問題

昨年の CAMPHOR- Advent Calendar にも似たような話を書いた。

dawn.hateblo.jp

このときはシフト組みではなく、カーシェアリングサービスを電子化した話を書いたのだが、印象的なブコメがあった。

熊野寮でコードを書いて感謝された話 - さんちゃのblog

いい話だけど、次のステップとして運用できる人を育てて引き継げるようにしないとずっと一人でメンテする羽目になるので頑張って。

2017/12/02 20:30

b.hatena.ne.jp

このコメントは正しい。現状、これらのサービスのメンテナンスができるのは自分しかおらず、それなりに大きな負担になっている。さらに、私が大学を卒業したあとにメンテナンスをする人間の目処は未だに立っていない*10*11。

しかし、これに関して私が思うのは、「自分がいなくなったあとにそれを維持できないから」という理由で電子化を諦めるのは正しくないということだ*12。自分が作ったアプリケーションが真に有用であって、絶対に使い続けたいと寮生が思ったのであれば、外注したりプログラミングを勉強したりすることでメンテナンスを続けることは可能である。そのような手段が取れない場合は、以前のアナログな仕組みにフォールバックすればいいだけだ。アナログな手段は理解しやすく誰にでも実行可能なので、フォールバックするのは簡単だ。

むしろ、そのような心理的障壁があることで改善が進まないことこそが問題である。

@_6v_ の自動化アプリと連携したい話

他のLTと内容が被りそうになったと冒頭に書いた。 シバニャン(@_6v_)は私とは異なるアプローチでシフト組みを自動化しようとしている。

詳しくはそちらのスライドを参照していただきたいのだが、要約すると、私がシフトを 集める というところに焦点を当てているのに対し、シバニャンはシフトを 組む というところに焦点を当てている。

私の作ったアプリケーションでは、シフトを提出させるというところまでは自動化がされているが、誰をどのシフトに割り当てるのかを決めるのは人間である*13。一方でシバニャンは、シフトを集めるところは外部の予定調整サイトに任せ、その情報を集約してシフトを組むところを自動化している。

この2つのアプローチは、協調することによってより便利になると私は考えている。シバニャンにはシフト組み"AI"のソースコードを共有してもらっている（感謝！）。これを私のアプリケーションにも組み込むことで、更に作業を減らすことができるはずだ*14。やる気が出次第取り組みたい。

まとめ

BIT VALLEY 2018 AFTER PARTY でLTをした。LTの内容は熊野寮にWebアプリを導入した話である。熊野寮で自動化/電子化を行う際には考えるべきことがいろいろあり、心理的な障壁もある。しかし、最悪なのは仕事の改善をしないということであり、寮生は電子化に限らず仕事の改善を積極的に行ってほしい*15。また、私の他にも仕事の自動化を試みる寮生はおり、彼ら彼女らと協力してよりよい熊野寮をやっていきたい。

Related articles

dawn.hateblo.jp

*1:被せたわけではなく、被りそうになったことがわかったのは当日だった

*2:こいついっつもレールズ書いてんな

*3:別にGMOのステマというわけではない。

*4:オタクなのでかわいい女の子の絵があると使いたくなってしまう。

*5:2018年の現在においても、スマートフォンを持たない大学生というのは、ごく少数ながら存在しているのだ!

*6:これは学生の仕事が無給ということであって、寮で働く大人の人達にはちゃんと給料が払われている。念の為。

*7:すべての仕事に給与をつけて、財源として寮費を上げれば良いのではないかという議論も当然存在するが、それは本稿の担当範囲ではない。

*8:ここにはもう一つ、仕事の負担を「回数」でカウントしてよいのかという議論がある。事務室当番１回と食器洗い当番１回は、本当に等価な労働量なのだろうか？

*9:このあたりの具体的な話は居住するフロアによってやり方が異なっている。熊野寮は自治寮だが、その中にも「フロア自治」があるのだ。

*10:もちろんプログラマ無しで完結するように頑張ってはいるが、プログラマなしで完結するようにするのにも工数がかかり...

*11:熊野寮ならプログラミング人材が沢山いそうという旨のブコメもあったがそれは幻想である。熊野寮においてはプログラミングができる学生は貴重な存在だ。

*12:これは電子化に限った話ではなく、新しい制度や組織の創設にも言えることだ。

*13:とはいえブラウザに表示されたチェックボックスをポチポチするだけなので、そこまで重労働というわけではない。

*14:もちろん私のWebアプリのソースコードもシバニャンに共有している

*15:とはいえこういう話は全部無給なので、一歩間違うと五輪ボランティアと同様の問題を抱えることになる。実際、一部の人間の仕事のしすぎ(させられすぎ)が問題として取り上げられることは多い。

MySQLの中身を時系列プロットするワンライナー

MySQLに入ってるデータの傾向をグラフで見たい、しかしgrafanaとかkibanaとかは導入したくないし、グラフを描画するプログラムを書くなんて論外という事があると思います。

そういうときにおすすめなのがこのワンライナー！必要なのはmysqlクライアントとgnuplotだけ！

はい。

$ mysql dbname -u root --password=passwd -e "SELECT timestamp, value FROM tbl WHERE some=condition" | gnuplot -e 'set terminal dumb 150 30; set xdata time; set timefmt "%s"; plot "<cat" using 1:2 with line;'

gist5e6cb1eb0b6d56bf5642471d18e0ad2f

解説

まず、

gnuplot -e 'set terminal dumb 150 30; set xdata time; set timefmt "%s"; plot "<cat" using 1:2 with line;'

について解説します。

set terminal dump

gnuplotで set terminal dumb とすると、プロットの結果をターミナルにアスキーアートで出力することができます。

また、set terminal dump width height のようにwidthとheightを指定すると、プロットの大きさを指定することができます。

set xdata time

gnuplotで set xdata time とすると、X軸を時系列データとして解釈してくれるようになります。

set timefmt "%s";

set timefmt "%s" は、時系列データのフォーマットを規定しています。%s はUNIX時間に対応しています。

もし時系列データが他のフォーマットで渡ってくる場合は、 %Y-%m-%dT%H:%M:%S のように適当に変えてやる必要があります。

plot "<cat" using 1:2 with line

通常gnuplotの plot コマンドの第一引数には、プロットするデータが入ったファイルの名前を指定します。ここに "<cat" を指定することで、標準入力の内容をプロットするデータとして解釈するようになります。

MySQLからデータを渡してやる

あとはMySQLからデータを取ってきてTSVにして、これをgnuplotの標準入力に食わせてやればグラフが描けます。

MySQLからデータを取ってきてTSVにして標準出力に出すワンライナーです:

mysql dbname -u root --password=passwd -e "SELECT timestamp, value FROM tbl WHERE condition=hoge "

1列目に時系列データ、2列目にプロットする値を持ってくるのが重要です。

制約

このワンライナーは2つ以上の列を1つのグラフにプロットできません。例えば、CPU使用率とメモリ使用率を1つのグラフにプロットするというようなことができません。

そういう複雑なグラフが見たくなったらgrafanaなどを使うべきということですね。導入がちょっと面倒ですが...

トップレベルスタイルSinatraの起動プロセス

トップレベルスタイル とは、以下のような書き方のことを指します：

require 'sinatra'

get '/hello' do
  'hogehoge'
end

このスタイルで書かれたSinatraアプリケーションが、どのような手続きで起動しているのかを解説します。

TL;DR

以下のようなトップレベルスタイルのSinatraアプリケーションは、

require 'sinatra'

get '/' do
  'hoge'
end

以下のようなコードと概ね等価ということです：

# 空のモジュラーアプリの定義
require 'sinatra/base'

class Application < Sinatra::Base
end

# DSLの定義
[:get, :post, :put, :delete].each do |method_name|
  define_method method_name do |*args, &blk|
    Application.send(method_name, *args, &blk)
  end
end

# Webサーバー起動処理の登録
at_exit { Application.run! }

# アプリケーションの定義
get '/' do
  'hoge'
end

解説

モジュラースタイル

Sinatraでは、上記のようなトップレベルスタイルを用いる以外にも、 モジュラースタイル を用いる方法があります。

モジュラースタイルというのは、以下のような書き方を指します：

require 'sinatra/base'

class MySinatraApplication < Sinatra::Base
  get '/hello' do
    'hogehoge'
  end
end

MySinatraApplication.run!

この用に定義されたWebアプリケーションのことを モジュラーアプリ と呼びます。

空のモジュラーアプリの定義

require 'sinatra' と書くと、 Sinatra::Application という名前の空のモジュラーアプリが定義されます。

DSLの定義

また、require 'sinatra' が実行されることで、 Sinatra::Delegator というモジュールがグローバルに extend され、get とか post などの、SinatraのDSLで使われるメソッドが定義されます。

これらのメソッドは Sinatra::Application.get や Sinatra::Application.post に”リダイレクト”されます。

つまり、以下のコードは、

require 'sinatra'

get '/' do
  'hoge'
end

以下のコードと等価です：

require 'sinatra'

Sinatra::Application.get '/' do
  'hoge'
end

詳しい実装が気になる人は sinatra/base.rb at master · sinatra/sinatra · GitHub を読んで下さい。 メタプログラミングのお手本のような使い方だと思います。

サーバーの起動

Rubyには Kernel.#at_exit というメソッドがあります。 このメソッドにブロックを与えると、インタプリタ終了時にそのブロックが実行されます。

Application::Sinatra の定義の中で at_exit が呼び出されている部分があり、Webサーバーの起動処理が登録されています。

これによって、スクリプトの実行終了時にWebサーバーが起動します。

まとめ

つまり、以下のようなトップレベルスタイルのSinatraアプリケーションは、

require 'sinatra'

get '/' do
  'hoge'
end

以下のようなコードと概ね等価ということです：

# 空のモジュラーアプリの定義
require 'sinatra/base'

class Application < Sinatra::Base
end

# DSLの定義
[:get, :post, :put, :delete].each do |method_name|
  define_method method_name do |*args, &blk|
    Application.send(method_name, *args, &blk)
  end
end

# Webサーバー起動処理の登録
at_exit { Application.run! }

# アプリケーションの定義
get '/' do
  'hoge'
end

SinatraでaタグからPUTリクエストを投げる

やりかた

app.rb を↓のように書き、

require 'sinatra'

class Rack::MethodOverride
  ALLOWED_METHODS=%w[POST GET]
  def method_override(env)
    req = Rack::Request.new(env)
    method = req.params[METHOD_OVERRIDE_PARAM_KEY] || env[HTTP_METHOD_OVERRIDE_HEADER]
    method.to_s.upcase
  end
end

enable :method_override

put '/hoge' do
  # do awesome things
end

htmlの方で↓のように a タグを書きます。

<a href='/hoge?_method=PUT&hoge=fuga'>PUTを投げる</a>

このリンクをクリックすると、hoge=fugaという内容のPUTリクエストが飛びます。

注意 ：クローラがやってくるとPOST/PUT/DELETEリクエストが飛びまくります。クローラがやってくるWebアプリケーションでこれをやるのは絶対にやめたほうが良いでしょう。

解説

enable :method_override によってRack::MethodOverrideミドルウェアを有効にし、その挙動を変えています。

以下でこれを説明します。

Rack::MethodOverride とはなにか

Rack::MethodOverrideとは、 リクエストに含まれる _methodというパラメータを読み取って、HTTPのmethodを書き換えてくれるRack middlewareです。 例えば _method=PUT という値をリクエストに入れると、PUTリクエストとして処理されるわけです。

しかし、Rack::MethodOverrideが「method書き換え」をしてくれるのは、元々のmethodが POSTの場合だけ です。 従って、GETリクエストで_methodパラメータを指定してもmethod書き換えは起こりません。

また、 _method という値はPOSTパラメータに入っている必要があります。 このため、Query Stringに _method=PUT と書いてリクエストを投げてもPUTリクエストにならないというわけです。

Rack::MethodOverride の挙動を変更する

では、目的であるところの「 a タグがクリックされたときに POST/PUT/DELETE のリクエストを投げる」を実現するためには、 Rack::MethodOverrideの挙動をどのように変更すれば良いでしょうか。

これは簡単で、

1. GETリクエストについても「method書き換え」をするようにする
2. _method パラメータをQuery Stringからも読み取るようにする

の2点について変更すれば良いわけです。

前者に関しては、Rack::MethodOverride::ALLOWED_METHODS の値を %w[POST] から %w[POST GET] に変更してやれば良いです。

また、後者に関しては、Rack::MethodOverride#method_override をオーバーライドして、↓のように¹ req.params² から _method パラメータを取得するようにすれば良いです。

# before
method = req.POST[METHOD_OVERRIDE_PARAM_KEY] || env[HTTP_METHOD_OVERRIDE_HEADER]

# afrer
method = req.params[METHOD_OVERRIDE_PARAM_KEY] || env[HTTP_METHOD_OVERRIDE_HEADER]

参考

• Rack::MethodOverrideを少しいじった話 - 【旧】PerlerのRuby日記->はてなブログに移行しました
• Class: Rack::MethodOverride — Documentation for rack (2.0.5)

はじめてのRuby Sinatra入門: 軽量RubyフレームワークSinatraとPaizaCloudを使って10分でWebサービスを作る

メタプログラミングRuby 第2版

---

1. 実際のコードはエラー処理が入っており、もう少し複雑である(https://github.com/rack/rack/blob/bfd4c155a9ba2fb1fcee8daab433fbdef582cce2/lib/rack/method_override.rb#L27)↩

2. req.params はQuery Stringのパラメータとrequest bodyのパラメータが合成されたもの↩

職人じゃないけどAAがしたい！

作ったもの：

https://image2aa.herokuapp.com/

AA(アスキーアート)とは

AA(アスキーアート)というのは、上の画像のように文字で書かれた絵のことです。一般には「AA職人」が職人芸で作ります。

元々は画像が貼れない2chで絵を表現するための手段だったと思われますが、近年はフォントの違いによって絵が崩れるのを防ぐためにAAの画像を貼るまとめブログなどもあるようです。

アスキーアートを自動で生成したい！

AA作成には特殊な技術が必要なので、一般人はAAを作れません。

僕だって好きなキャラクターのAAを作りたいのに...

AAを画像から生成できればいいのに...

それRustでできるよ

画像からAAを自動生成するWebアプリ

デモ

画像からAAを自動生成するWebアプリ

このWebアプリはRust言語で作成されています💪

• GitHub - genya0407/image2aa-web
• GitHub - genya0407/image2aa

どうやって実現しているのか

以下の3段階の処理を行ないます。

1. 線画を抽出する
2. 画像を分割する
3. 部分画像ごとに文字を割り当てる

1. 線画を抽出する

まずは線画を抽出します。

線画を抽出するには、以下の2段階の処理を行います。

1. ソーベルフィルタをかける
2. 2値化する

ソーベルフィルタ

↓こういう畳込みフィルタを掛けます。

http://ipr20.cs.ehime-u.ac.jp/column/gazo_syori/chapter5.html より引用

これをすると「周囲との差が大きいピクセル」は値が大きくなり、「周囲との差が小さいピクセル」は値が小さくなります。

2値化

画像において「線」は「周囲との差が大きいピクセル」の集合です。 なので、ソーベルフィルタの結果に対して「ある値より大きいピクセルは白色、ある値より小さいピクセルは黒色」というように2値化すると、線画が生成されます。

2. 画像を分割する

図のように、線画を適当な大きさのブロックに分割します。

3. 文字を割り当てる

各ブロックに似た文字を割り当てることで、アスキーアートを得ることができます。 上図の例では「縦棒の画像」を「｜」に割り当てています。

ここで問題になるのは各ブロックに似た文字とはなんぞや？ということです。

「似ている」とはどういうことか

画像と文字が「似ている」とはどういうことでしょうか？

いろいろな方法で「似ている度合い」を計算することはできるでしょうが、ここでは「直線の傾き」に着目します。 つまり、「画像の直線の傾き」と「文字の直線の傾き」を比較して、それらが近い時に「画像と文字が似ている」とします。

上の画像の例だと、「縦棒の直線の傾き」と「｜の傾き」が近いため、「｜」を割り当てるということです。

直線の傾きをどう求めるのか？

では、直線の傾きはどのように求めればよいのでしょうか？

これについてもいろいろな手法があるでしょうが、ここではハフ変換というのを使います。 ハフ変換を使うと、画像内に含まれる直線の傾きと、その直線の原点からの距離を求めることができます。

あとは、画像の直線の傾きと文字の直線の傾きを比較して、近いものを割り当てればアスキーアートが得られます。

完成 🙌

このように、

1. 線画を抽出する
2. 画像を分割する
3. 部分画像ごとに文字を割り当てる

の3段階の処理を行なうことで、画像からアスキーアートを生成することができます。

Programming Rust: Fast, Safe Systems Development

詳解 OpenCV 3 ―コンピュータビジョンライブラリを使った画像処理・認識

「熊野寮生だけど質問ある？」

CAMPHOR- Advent Calendar 2017 の 7日目 の記事です。

CAMPHOR-運営メンバーの @genya0407 です。

熊野寮ネタばかりで恐縮ですが、「熊野寮生だけど質問ある？」というWebサービスを作った話をします。

「熊野寮生だけど質問ある？」とは？

「熊野寮生だけど質問ある？」は、熊野寮生に匿名で質問ができるWebサービスです。 質問を投げると熊野寮生から回答がつきます。

熊野寮祭の企画の一つとして作りました。

なんでこの企画をやろうと思ったの？

Twitterでエゴサかける度に、みんな熊野寮のこと誤解してるんだなぁと感じます。 特にガサ入れ直後とかはひどくて、目を覆いたくなるようなツイートもたくさんあります。

これは、テレビで流れるのはガサの報道か「変人の巣窟」という観点のバラエティ番組ばかりで、そういう情報しか目に触れることがないことが大きな要因だと思います。 さらに、インターネット上にある情報も「廃墟」とか「やばい場所」とか、あるいは「過激派の巣窟」という一面的な切り口でしか熊野寮を語っていません。 こうした状況では、世間の人々が熊野寮に対して偏見を持つのも仕方ないと思います。

じゃあ、熊野寮公式で情報発信をすればいいじゃないかという話になりますが、これは結構難しいです。 というのも、熊野寮自治会として情報を発信するためには寮全体で合意を取る必要があるからです。 これはハードルがなかなか高いですし、単純に時間がかかります。

そこで、「実際のところ○○ってどうなん？」みたいなことを「熊野寮自治会」ではなく「熊野寮生個人」に聞くことができたら、毎度寮全体で合意を取る必要もなく、熊野寮に関する誤解も解けていくのではないかという気持ちがあり、このサービスを作成しました。

実際公開してみてどうなん？

想定していた使い方とはちょっと違う使われ方をしていると感じます。

どういうことかというと、質問してくる人が、熊野寮に全く関わりのない人というよりは、例えば京大生だったり、京都周辺に住んでいる人が多いということです。 つまり、ある程度熊野寮についての知識がある人が質問してきているという感触があります。

これは、そもそも熊野寮に関わりのない人に対してこのサービスが知られていないということが、大きな原因としてあると考えられます。 現状「熊野寮生だけど質問ある？」への流入経路は、熊野寮生のツイートと、熊野寮祭の企画一覧ページの２箇所しかありません。 これでは熊野寮生の友人や、熊野寮そのものに興味がある人にしかリーチすることができず、当初の目的とは対象がズレてしまっています。

サービスを作るときには、ただ単にソフトウェアを開発するだけではなく、ターゲットにリーチするための努力も必要だという知見が得られました。

今後はどうするの？

当初は寮祭終了とともにクローズするつもりで始めたのですが、もっと続けたほうがいいという声もあり、ひとまず継続しようと思っています。サービス自体はまだ完成していないと思っているので、ぼちぼち改善していきます。

検索とかお気に入りとかカテゴリ分けとか回答者ごとの並び替えとかやっていきたいし、デザインも改善していきたい。

12/12 追記：回答者内で議論した結果、一旦質問の募集を打ち切ることになりました。既存の質問や回答は引き続き公開します。入試の時期や春先、ガサが入ったときなどに再度質問を受ける期間を設けようと思います。

熊野寮でコードを書いて感謝された話

CAMPHOR- Advent Calendar 2017 の 2日目 の記事です。

CAMPHOR-運営メンバーの @genya0407 です。

熊野寮でコードを書いて感謝された話をします。

熊野寮

僕は京都大学の自治寮である熊野寮に住んでいます。

ガサが来たり過激派が住んでたりしますが、基本的には自由で楽しいところです。

カーシェアリング

熊野寮にはカーシェアリングというサービスがあります*1。 これは、自動車を共有して安く利用しようというサービスです。会員登録をし、年会費を払い、乗った分だけ追加で料金を払います。

廉価に車を使えるので僕も利用しているのですが、割と昔からあるサービスということもあって理不尽な手作業を強いられることが多く辟易していました。

理不尽な手作業

理不尽な手作業とは何かというと、それは乗車の手続きのことです。

車に乗る時の手続きをまとめると、

• 乗ろうとしている車が予約されていないか確認するために、メーリングリストを検索する
• 今から車に乗る旨のメッセージをメーリングリストに流す
• 乗車時の走行距離メーターの値をノートに書く
• 降車時の走行距離メーターの値をノートに書く

のようになります。クッソ面倒ですね。最悪のユーザー体験です。

なんでこんなにめんどい手続きが必要なのか

なんでこういう煩雑な手続きが必要なのかというと、利用料金を計算するためです。「使った分だけお金を払う」を実現するためには、「どれだけ車に乗ったのか」ということを記録しなければなりません。

例えば、タイムズがやっているカーシェアリングサービスの場合は、車の鍵を開けてから締めるまでの時間が計測されており、それを元に料金を自動で算出します。 そのため、ユーザーは特別な作業をする必要はありません。車に乗って降りるだけで料金が自動で計算されます。

一方熊野寮の場合は、そんなオシャレなシステムを搭載するお金も技術も無いので、上記のような煩雑な手続きが発生していました。

Webアプリの導入

こうした煩雑な手続きをなくすために、Webアプリを作り、導入＆移行しました。 ユーザーは、メーターの値と帰宅時刻を入力するだけで車に乗れます*2。 その上、予約中に乗ろうとすると警告されるので、予約をいちいち確認する必要もありません。

また、以前のやり方だと、使用料金を算出するために半年に一度ノートに書いてある走行距離を秘伝のExcelシートに手入力してマクロを走らせる必要がありました。この手入力という作業が本当にひどくて、一度やらされたときは6時間ぐらいかかって本当に発狂するかと思いました。

Webアプリに移行したことでこの手入力という地獄のタスクが無くなり、僕がバッチを回せば使用料金が算出されるようになりました。最高のユーザー体験です。

非ITコミュニティでプログラムを書くこと

このWebアプリはみんな大好きRuby on Railsで作成されています。 フロントエンドも普通にHTMLを吐き出しているだけで、今時のイケてるJSフレームワークなどは使っていません*3。

こういう雑なWebアプリが作れるだけでも、熊野寮ではものすごく重宝されて褒められます。 このアプリを作ったときも、「めっちゃ便利！」という反応をいただきました。 レベルの高いエンジニアの中で切磋琢磨するのも楽しいですが、こういうIT力の低い組織でいろいろやるのも楽しいです。

みなさんも自分の所属する非IT系コミュニティなどで、自分のIT力を活かしていろいろやってみたら楽しいかもしれませんよ。おすすめです。

結論

• ユーザーの体験は大幅に改善され、みんな快適にカーシェアリングできるようになりました。めでたい。
• 承認欲求が満たされたいプログラマの人はぜひ熊野寮に入寮しましょう。

Related articles

dawn.hateblo.jp

パーフェクト Ruby on Rails

レッド(1) (KCデラックス イブニング)

*1:自治会公式でやっているわけではなく個人がサービスを提供している

*2:理想的にはタイムズのシステムみたいに鍵開けたときと閉めたときのメーターの値を記録するようにしたいけど、現状鍵からユーザーを特定できる作りにはなってないので難しい。

*3:materialize.cssというcssフレームワークは使った