読者です 読者をやめる 読者になる 読者になる

今日はこのへんで

エンジニアです。雑記がメインですがたまにプログラミング、スタートアップなどについて書く予定です。

煎酒(いりざけ)買ったら美味かった

最近BuzzFeedで以下の記事がバズっていた。意外と知らない調味料ってあるんですね。

このなかで、煎酒(いりざけ)という調味料が気になったので買ってみた。

煎酒(いりざけ) 小

煎酒(いりざけ) 小

(いまAmazonだと1,200円とかになっちゃってるけど、普通に成城石井で買えば700円ちょっとになるので注意。)

煎酒は梅酢とかつおだしを合わせた調味料なんだけど、基本的には醤油かポン酢の代わりとして使うのが良い。

卵かけご飯がうまい

f:id:Kechol:20170304191603j:plain

醤油の代わりに煎酒を使うとうまい。すこし梅の風味がしていい感じ。

ツナの和え物に使うとうまい

ツナ缶と三つ葉(とかオクラ、水菜など)の和え物は、すごく簡単にできて副菜として優秀なんですよ。たまに納豆やかつおぶし入れたりもする。

だいたい醤油やポン酢で味付けをするんだけど、これを煎酒にしてみても美味かったので、試してみるといいかも。


料理の引き出しが少ないのでこのへんで。とりあえずなんにでもかけて食べてみているけど、大体うまいので買ってよかった。

最近の作業用BGM

音楽を大音量で聴くと疲れを感知する機能がにぶる(*1) ってほんとなんですかね?感覚的には合っている気がするけれど。

自分は作業中によくBGMを聴くのだけど、試行錯誤しているので少し紹介したい。あわよくば「これを聴け」という知見が欲しい。

(ちなみに貧乏性なのでSpotifyやiTunes Musicといったサブスクリプションサービスは使っていません。)

YouTubeのミックスリスト

YouTubeのミックスリストは、似たテイストの曲をずっと流しておけるので良い。個人が作ったリストではなく、YouTubeが自動生成したリストは曲数が多いのでずっと聴いていられる。

ちょっと前に深夜のテレビで、たまたまリーガルリリーというインディーズのガールズバンドが紹介されていて、そこからthe peggiesとかテレキャスターストライプとかのインディーズバンドを無限に聴いていた時期があった。

初音ミクやIAも好きだけど、最近は石風呂さんの曲をずっと聴いていた。

あとはいろんな曲をカバーしているGoose houseのチャンネルはカバー曲数が多くて安定してる。

ミックスリストは、インディーズバンドや初音ミク、Goose houseなど、公式が載せているものであれば、楽しく聴けると思う。

ニコ動の作業用BGM

ニコ動の作業用BGMタグ は1時間くらいの長さのアニソンとかボサノバとかJAZZとかがあって、数年前はよく聴いていた気がする。

コメントで”マスター”とわざとらしいやりとりしてるのはニコ動らしくて微笑ましい。

SoundCloud

SoundCloud もいろいろなMixがアップロードされているので、聴いていた時期があった。曲がMixされて作業用BGMに合う感じになっているのも良かった。

SoundCloud: 音楽&オーディオ

SoundCloud: 音楽&オーディオ

  • SoundCloud Ltd.
  • ミュージック
  • 無料

“chillout"とか"anime music"とかのキーワードで検索すればいろいろでてくる。(けど正直自分も使いこなせてはいない。)

Search Results: #chillout | SoundCloud

TuneIn Radio

tunein は、基本的にはラジオアプリだけど、アニメやJAZZなんかを流し続けているステーションがいくつかある。自分は少し試してやめてしまったけど、お気に入りのステーションが見つかれば良さそう。

TuneIn Radio

TuneIn Radio

  • TuneIn
  • ミュージック
  • 無料

たとえば以下のステーションはずっとアニソンを流してる(古いアニメも多い気がする)。

Amazon Prime Music

Amazon Primeの会員であれば、Amazon Prime Music が聴ける。

Amazon Music

Amazon Music

  • AMZN Mobile LLC
  • ミュージック
  • 無料

プレイリストが「晴れた朝に聞きたい洋楽」とか「テンションが上がる映画音楽」とか雰囲気ベースになっているので、気分を合わせて聴きたいときにはいいかもしれない。洋楽が多いので洋楽が好きなひとには良さそう。

プレイリスト: テンションが上がる映画音楽 | Amazon Prime Music

ホワイトノイズ

より集中したいときや、リラックスしたいときなんかはホワイトノイズを聴くこともある。

サイトとかアプリとか調べればいくらでもでてくるけど、自分は Nozio というアプリを使っている。自分で雨音や波の音をMixできて、用途を分けられるところが気に入っている。

Noizio

Noizio

  • Kyrylo Kovalin
  • ミュージック
  • ¥240

f:id:Kechol:20170305124727j:plain:w320

集中して本を読むときや寝る前はホワイトノイズを聴いているときが多い気がする。

Youtube Live

TuneInとかと変わらない気もするけど、YoutubeにはLiveで24時間音楽を流しているチャンネルがあったりする。

以下のチャンネルは雰囲気がゆったりで邪魔にならないので、最近良く聴いている。


こういう作業用BGMは選んでいる時間がもったいないと思いつつ、ずっと聴いていると飽きてくるので悩ましい。とはいえ、最近は作業中はYoutube、本を読むときはホワイトノイズで安定してきたので、やっと整ってきた感じがする。

まぁ自分の気に入った曲を聴くのがいいよね。

f:id:Kechol:20161122211341j:plain

いまさら docker-compose

ここ数日、Railsアプリの開発環境をDockerに移行できないかなと思って触っていた。Dockerについては昔から横目でウォッチしていたものの、実際にRailsアプリの開発環境をDockerコンテナ上で作る機会がなかったので、いまさら試した。

触ろうと思って調べると、意外と日本語記事が古かったり、不満が多かったので、ここでは軽くTipsなんかをメモしておきたいと思う。

前提の環境としては

  • 既存Railsアプリの開発環境をDockerで作りたい
    • puma, webpack, postgres, redis (ActiveJob) のプロセスを起動する
  • docker -v : Docker version 1.13.1, build 092cba3
    • Docker for Mac 使ってる

今回試した結果のDockerfileとdocker-compose.ymlは以下に書き捨てた。まだ修正の余地はあると思うけど。。

https://gist.github.com/kechol/787429078865eff623e62b0ebbe78280

docker と docker-compose の関係

これは基本的なことをちゃんと理解していなかっただけなんだけど、docker-compose するときはほとんど dockerコマンドのお世話になることはない。docker-composeを使ってコンテナを作成する場合には、Dockerfileの一部(CMDとかEXPOSEとかENVとか)の内容を docker-compose.yml に移すことになり、Dockerfileが単体では動作しないものになるので、docker コマンドに対応した docker-composeコマンドを使う。

Overview of docker-compose CLI - Docker

buildだったら

$  docker-compose build SERVICE_NAME

runだったら

$  docker-compose run SERVICE_NAME COMMAND

になる。

Dockerfileのディレクトリ構成

docker-composeを使うときは複数のDockerfileを作成したり、開発環境と本番環境を分けたりするので、docker-compose.ymlをプロジェクトルートにおいて、あとは適当なディレクトリにまとめるのが良いと思う。

以下のような感じが良いんじゃないかと思う。

PROJECT_ROOT
├── docker-compose.dev.yml
├── docker-compose.prod.yml
├── .env
├── dockerfiles
│   ├── dev
│   │   ├── Dockerfile-rails
│   │   ├── Dockerfile-node
│   │   ├── Dockerfile-xxxxx
│   │   ├── entrypoint.sh
│   ├── prod
│   │   ├── Dockerfile-rails
│   │   ├── Dockerfile-node
│   │   ├── Dockerfile-xxxxx
│   │   ├── entrypoint.sh

最初 docker-compose.yml をdockerfilesサブディレクトリ以下に置こうとしたんだけど、セキュリティの都合で上の階層のディレクトリをVOLUMEとしてアタッチできないっぽかったのでルートに置かざるを得なかった。

Alpine Linuxを使う

特に開発用のDockerイメージのソースとしては、Alpine Linuxベースのものを使ったほうがいい。サイズが小さいから。いまはOfficialのソースもたいていalpineに対応しているしね。(-alpineとprefixがついていたり、タグがalpineになっている。)

$ docker images
ruby                2.3-alpine          c963a2466730        4 days ago          137 MB
node                6.10-alpine         340408be6110        5 days ago          50.3 MB
redis               alpine              0d39481626b2        12 days ago         20.5 MB
postgres            alpine              575c5e74b765        2 weeks ago         38.4 MB
busybox             latest              7968321274dc        6 weeks ago         1.11 MB

実際にイメージを見てみても、alpine ベースのイメージは100MB以下のものが多い。ubuntu とかのイメージだと、100MBくらいは余裕で使うから、ハードディスク容量を圧迫しなくて済む。

ひとつ注意点としては、パッケージ管理が apk というコマンドになっているので書き換える必要があるということだ。利用できるパッケージは Alpine packages で検索できる。

docker-compose.yml version 2 or 3 を使う

サンプルを見たいと思って色々なdocker-compose.ymlを見てみたけど、意外とver. 1の文法のままのものが多い。特に links がそのままなものが多かった気がする。よくわからずコピペしていると古い文法を使ってしまったりするので注意が必要。

なので結局、公式のリファレンスを読んで自分で組んでいくしかない。 Compose file version 2 reference - Docker

ちなみに公式にはもうversion 3のリファレンスが出ているんだけど、まだチュートリアルとかはver. 2のままだったので、今回はおとなしくver. 2を使った。

Shared Volumeを使う

DBのデータやインストールしたライブラリなどは永続化したり、コンテナ間で共有する必要があるが、その際の一般的なパターンがShared Volume、またはData-only Container Patternと呼ばれるもののようだった。

Manage data in containers - Docker

具体的にはデータを保持するためのコンテナを作っておき、そこにVolumeをアタッチするようにする。どうせVolume用のコンテナ内ではなにもしないので、イメージは小さいbusyboxを利用する。今回だと以下のような感じになった。

  datastore:
    image: busybox
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - redis_data:/data
  postgres:
    image: postgres:alpine
    volumes_from:
      - datastore
  redis:
    image: redis:alpine
    volumes_from:
      - datastore

volumes:
  postgres_data:
    driver: local
  redis_data:
    driver: local

なんだけど、実はDocker v.1.9.0から docker volume がサポートされるようになったので、実はわざわざコンテナを別で用意してvolumes_fromで参照する必要ないのかも(あんまりわかってない)。以下のドキュメントをもうちょっとよく読もうと思う。

Volume configuration reference | Compose file version 2 reference - Docker

ネットワークとデータベース接続

docker-compose でコンテナを作成すると、デフォルトで一つのネットワーク上に配置され、コンテナ間の通信がしやすいようになっている。

Networking in Compose - Docker

今回だと、データベースの接続に rails コンテナから postgres コンテナのDBを参照する必要があり、database.yml は以下のようになった。

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  host: postgres
  port: 5432
  username: postgres
  password:

development:
  <<: *default
  database: app_development

test:
  <<: *default
  database: app_test

host: postgres になっているのが一見奇妙だけど、コンテナ内でnslookupしてみるとちゃんとIPが返ってくる。

mac:~$ docker-compose run rails sh

rails:/app # nslookup postgres
Name:      postgres
Address 1: 172.18.0.3 app_postgres_1.app_default

いらないコンテナを削除する

これはDockerfileいじっている時には頻繁にやらないといけないので、エイリアス割り当てた。filter=で死んだイメージやコンテナだけを削除するのがポイント。

alias docker-clean-images='docker rmi $(docker images -a --filter=dangling=true -q)'
alias docker-clean-containers='docker rm $(docker ps --filter=status=exited --filter=status=created -q)'

deeeetさんのブログでもいろいろ紹介されている。 Dockerを便利に使うためのaliasをつくった | SOTA

Dockerコンテナをデバッグする

Dockerコンテナのプロセスが意図せず終了してしまう時、docker-compose logsでログみてもよくわかんないことがある。

そういうときはシンプルに docker-compose run SERVICE_NAME sh を実行して中に入り、コマンドを実行してみたりして動作を確認するのが良い。

Docker自体の挙動を追いたいときには、docker events & を実行したターミナルでdockerのコマンドを叩けば、コンテナが作成される様子などが逐一ログに流れてくるのでおすすめ。

ログがたくさん流れてくると動いていることがわかって安心するのは僕だけだろうか。

Entrykitについて

Dockerfileでは基本的に、CMDやENTRYPOINTで一つのコマンドしか流せないので、entrypoint.shstart.sh なんかを用意してコマンドをまとめて流す、というようなことをする。

それをより簡単にするEntrykit というツールがあるのだけど、今回は使うのをやめた。最初、コンテナを分けるのがむしろめんどくさいような気がして、nodeとrailsのプロセスを一つのコンテナに入れようかと思って検討していたのだけど、結局分けたほうが綺麗に収まるし、Entrykit自体の使いみちともずれるような気がした。

Entrykitを使った記事が英語だとそんなにでてこないので、実際どれくらい使われているかはわからないけど、テンプレート化したConfigファイルを配置したりするのに使えるのは確かに便利そうなので、本番のDocker環境構築なんかではまた検討するかもしれない。

余談:開発環境をDocker化するのはいいことか

んで、ここまでやっておいてなんだけど、ちょっと開発環境をDocker化するのはやめておこうかなぁとも思い始めた。

RailsとWebpackのログが一緒にでてきてしまうし、整形もされないのですごく見にくい。rails cなどのコマンドもdocker-compose run経由で叩かなければならず、遅いしコマンド打つのがなんとなく面倒に感じる。

(まだDockerに慣れておらず不安定だからだとも思うけど、)ローカルの開発環境のつもりなのに、Docker上で動かない原因は結局ローカル(Mac)上で確認しなければいけない状況なんかが生まれてきて、結局Macの開発環境を手放すわけにもいかない。なぜ僕はローカル環境のデバッグをローカルでしているのか、という気分になる。

あと単純に、Dockerで開発環境を作ると、コンテナやイメージで簡単に数GBを消費するのが辛い。複数のプロジェクトに関わったりしていて、それらをすべてDocker化したと思うとノートPCのHD容量がそれだけでパンクしてしまいそうだな、と思う。

Dockerを使っているというと、なんとなくクールだな、とか、本番環境もBlue-Green Deploymentでイケてる感じなんだろうな、とか思うし、今回手を動かして得た知見にも満足しているけど、どうしようかなぁ、というのが今回の結論だった。

ほんとはサービスをECSでデプロイしてお手軽に運用するところまでやりたかったのだけど、ちょっと触ってから置いておくのも手かもしれない。

なにか快適に開発するための良い知見があれば知りたいな。

その他参考にしたサイト(日本語記事とか)

Docker入門

Docker入門

f:id:Kechol:20140703080750j:plain

がんばれ日本の自動車メーカー!自動運転の未来はすぐそこだ!(技術編)

概要編に引き続き、自動運転について見ていこうと思う。今回は技術をより掘り下げる。

特許を多く持つ日本メーカー

ThomsonReutersのレポートによると、実は自動運転関連の特許(2010年-2015年)を一番多く持っているのはトヨタらしい。さらに上位5位をみても、デンソー、日産、ホンダといった企業が並んでいる。

f:id:Kechol:20170226035022p:plain

http://images.info.science.thomsonreuters.biz/Web/ThomsonReutersScience/%7B86ccb67a-e45a-4c3a-8513-5350b39929de%7D_tr-automotive-report-2016_final.pdf

実際に特許の詳細を見てみないとわからないのだけど、衝突回避システム関連の特許が多いようだ。日本企業の知財管理はしっかりしてる。

自動運転を変えるAI技術

なんだけど、実際の自動運転開発の現場では状況が少し異なる。ここ1,2年の自動運転技術開発は、ディープラーニング等のAI技術が発展したことによって革新したといっても過言ではなく、自動車部品等のハードウェアの領域ではなく、ソフトウェアの世界で進んでいる。

Level 3相当の技術はすでにコモディティ化している?

そして、Level 3相当の自動運転技術はすでにコモディティ化していると言って良いと思う。その理由が NVIDIAのDRIVE PX 2 だ。いわばJavaScript界のjQuery、ゲーム業界のUnityみたいなものだと思っている。

DRIVE PX 2は、ディープラーニング用のAIを積んだ車載用コンピュータで、2016年初頭に発表された。自動運転に必要なセンサーデータの融合を行ったり、ディープラーニングを用いてトレーニングを行い、高精度な道路上の物体検知を可能にする。また、センサー情報から3D地図を作成することもできる。

Volkswagen、Daimler、Volvo、Hondaなど、Tier1の自動車メーカーがすでに採用を発表している。また、Teslaは昨年の事故のあと、自動運転技術をDRIVE PX 2ベースのものに置き換えている。(*1)

こうしたAIプラットフォームを使ってどれだけ周囲の環境の認識精度を高められるかが、これから自動車メーカー各社の戦いとなっていくことでしょう。

公道のデータを集めているのはどこか

自動運転技術の技術にディープラーニングを使っているとなれば、認識精度向上の肝になるのは走行データになる。

カリフォルニア州の年次報告によれば、公道実験での走行距離が圧倒的に長いのはGoogleだ。2桁違うって・・・。その次にはGMとNissanが続く。

f:id:Kechol:20170226035040p:plain

http://www.kantei.go.jp/jp/singi/it2/senmon_bunka/detakatsuyokiban/dorokotsu_dai2/siryou3.pdf

実質、公道実験を行える州は非常に限られているので、もうこれだけで各メーカーがどれだけ先行しているかわかるようだ。やっちゃえ日産。

(余談だけど、シリコンバレーに研究拠点があるトヨタが入っていないのは気になる。そもそもカリフォルニア州DMVの自動運転認可リストにも入っていない模様。(*2) なんでだろ?)

インフラとなる3D地図データ

車両がセンサーで感知できる範囲のみで安全に交通上の問題を解決しようとすることは不可能なので、道路状況、信号の状態等までを含めた3D地図の整備をすることが、一般道での高レベルな自動運転の実現には欠かせない。

3D地図プラットフォームで一強?のHERE

実は、この3D地図のプラットフォームを提供している HERE というドイツの会社がある。2015年にNokiaから売却され、BMW、Audi、Daimlerといった欧州自動車メーカー3社が主要株主となっている。2016年以降もIntelやTencentの資本参加があり、最近パイオニアとも提携が発表されて注目を集めている。(*3)

各提携パートナーから、欧州/中国/日本の地図データがHEREに集まることになると思うし、これから更にHEREのプラットフォームが拡大していくことは間違いないと言える。

アメリカではちょっとわからないけど、Googleがデータを大量に持っているので、Googleが3D地図を含めた自動運転プラットフォームを提供する、ということが今後あり得るかもしれない。

日本では合同で会社を設立へ

日本では、政府が主導となって 戦略的イノベーション創造プログラム(SIP)自動走行システム研究開発 を計画しており、その検討課題のひとつとして地図情報の高度化を目指している。

この地図情報整備のために、日本の会社6社と自動車メーカー9社が協力し、ダイナミックマップ基盤企画株式会社という会社を設立した。(*4)

出資比率は以下の通り。

三菱電機株式会社 18%、株式会社ゼンリン 17%、株式会社パスコ 17%、アイサンテクノロジー株式会社 6%、インクリメント・ピー株式会社 6%、株式会社トヨタマップマスター6%、いすゞ自動車株式会社 3.3%、スズキ株式会社 3.3%、トヨタ自動車株式会社 3.3%、日産自動車株式会社 3.3%、日野自動車株式会社 3.3%、富士重工業株式会社 3.3%、本田技研工業株式会社 3.3%、マツダ株式会社 3.3%、三菱自動車工業株式会社 3.3%

マップのデータをメーカー各社から集めることで、共通の地図基盤を作ることができる。地図データはまさにインフラなので、良い流れのように思う。

日本メーカーは自動運転技術で勝てるのか

自動運転技術の開発にはAIを存分に扱える人材が不可欠だと言える。実際、身の回りでも日産やホンダが機械学習エンジニアを募集している求人広告を見ることがある。

厳しい日本のIT事情

深刻な問題として、日本はAI人材が米中にくらべて非常に少ない現状がある。

Yahoo! CSOの安宅さんが経産省に提案し、少し前に話題になったAI×データ時代における⽇本の再⽣と⼈材育成 の資料から少し抜粋すると、日本はICTエンジニアがアメリカの3分の1しかおらず、しかもこの大半がSIerにおけるCoderだというから、現状は非常に厳しい。

f:id:Kechol:20170226035053p:plain

AI×データ時代における⽇本の再⽣と⼈材育成

日本の自動車メーカーは、海外から優秀な人材を引っ張ってくる必要があるだろうし、国内だと理工系の数少ないAI人材(東大の松尾研の研究生とか)を青田刈りして連れてくるしかないと思う。

IT企業のエンジニアにはなにができるのか

こと自動運転技術に関しては、今はおそらく、人材がいないせいで、機械学習の経験が少ないエンジニアにも採用の間口を広げているだろうから、ちょっと勉強するだけで市場価値が非常に高まるいい機会だと思う。なので勉強するといい。

機械学習であればCourseraの有名なコースがあるし、いまはDeep Learningも日本語で読めるいい本がある。

自動運転技術についても、MITのコースUdacityのプロジェクト が見つかるので、独学できる範囲でも学べることは多い。オープンソースで自動運転技術を開発しているスタートアップのComma.aiのリポジトリにも面白そうなもの(commaai/research)があるのでチェックしてみると良いかもしれない。


ということで、雑に自動運転についてまとめてみた。機械学習の勉強をしたいと思いつつできてないのが残念なので僕も勉強します。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

がんばれ日本の自動車メーカー!自動運転の未来はすぐそこだ!(概要編)

CES2017が終わってからだいぶ経ってしまったけど、自動運転について自分でも以前軽く調べたので、簡単にアップデートしつつブログにも放流しておこうと思う。つい先日もWaymo (Google)がUberを訴えたり、Teslaが保険もオファーするようになったりと、自動運転の話題には事欠きませんね。

自動運転のレベルは6段階

まずは基本から。自動運転のレベルはLevel 0も含めると6段階ある。以前のNHTSAの水準は4段階だったのだけど、2016年9月からはSAE Internationalの水準に合わせるようになっている。(*1)

f:id:Kechol:20170226034529p:plain

automated_driving.pdf

一言で各レベルを解説すると、

  • Level 0: 自動化なし。常に運転者が運転。
  • Level 1: 運転者の補助。運転者が運転するが、加速、ブレーキ、ステアリングのいずれかをシステムが補助
  • Level 2: 部分的な自動化。加速、ブレーキ、ステアリングを組み合わせてシステムが単純な運転を補助
  • Level 3: 条件付き自動化。システムが運転の主体となるが、自動運転の条件に合わない場合は運転者に運転を移譲
  • Level 4: 高度な自動化。システムが運転の主体となり、一定の条件下ですべての運転をこなし、条件が変わってもシステムが運転を担う
  • Level 5: 完全な自動化。すべての場面でシステムが完全に運転を制御する。(運転手は必要なくなる)

現在はLevel 2程度の自動化(というより運転補助システム)が市場に出ており、高速道路の一車線をハンドルやアクセルなしで走るようなものが多い。

自動運転の利点・欠点

さて、それで、実際自動運転が普及するとどんなことになるんだろうか。調べた感じではVictoria Transport Policy Instituteのレポートによくまとまっている。

f:id:Kechol:20170226034537p:plain

avip.pdf

運転者のストレスを低減し、安全性を高め、燃費効率を上げて排出量を抑える、という効果などが言及されている一方で、車のメンテナンスコストの増加や無人運転車によるテロの可能性、車の利用の増加による様々なコスト(駐車、事故、大気汚染)の増加などが指摘されている。

利点のなかで特に面白いのは、カーシェアリングが増加するという指摘かな、と個人的には思う。実際、多くの自動車メーカーは、カーシェアリングサービスとの事業提携を進めており、自動化された後の未来も見据えている。

自動運転はいつごろ普及しそうなのか

自動車メーカーによって多少異なるものの、2020年ないし2021年にLevel 3かLevel 4の市場投入が目標というのがおおよその見解だと思う。

日本政府のロードマップ

日本では、日本の自動車メーカーを支援するため、政府も自動運転の制度整備に積極的だ。2016年に発表された官民ITS構想・ロードマップによれば、2020年ごろにLevel 3の市場化、2021年以降にLevel 4の市場化という構想であることがわかる。

f:id:Kechol:20170226034548p:plain

余談なんだけど、日本政府の最近の動きを見ていると、一般的な自動運転技術よりも、過疎地の移動手段としての、より公共性の高い自動運転システムの実現に力をいれている気がする。メーカーとの動きの違いも出ていて面白い。

官民ITS構想・ロードマップ2016

自動運転についての普及予測

McKinseyが出している自動運転についての普及予測のレポートによると、自動運転が上手く市場に浸透したとして、2030年にはLevel3の自動運転技術が50%、Level4は15%ほど普及するという見通しだという。いま(ほぼ)0%であることを考えると、相当早く普及する見通しだと言える。

f:id:Kechol:20170226034559p:plain

automotive_revolution_perspective_towards_2030.pdf

普及の足かせは条約と法律

いま自動運転技術の開発・普及の足かせとなっているのは、国連条約や道路交通法といった法制度になる。

車両の自動制御や自動操舵を禁ずる国際基準

例えば、日本は1949年にジュネーブ国際道路交通条約に批准しており、運転者は常に車両の速度を制御しなければならない、などの制約がある。(*2) 他にも、国連では自動操舵の国際基準(R79)が定められており、現在10km/h以上の速度での自動操舵が禁止されている。(*3)

こうした国際条約は、国際的なフォーラムや作業部会で議論され、早期の改正を目指して動いている。

アメリカ連邦政府の定める自動車基準

アメリカでは、上記の国際条約の問題は発生しないが、代わりに連邦政府の定める自動車基準(FMVSS)に準拠する必要がある。

また、アメリカでは、州法に基いて、認可された事業者のみが自動運転の実証実験を行うことができる。この認可を与えている州も限られており、シリコンバレーのあるカリフォルニア州、デトロイトのあるミシガン州などが特に人気が高い。このせいもあって自動車メーカーの研究所はシリコンバレーに集まる傾向にある。

f:id:Kechol:20170226034610p:plain

Autonomous car - Wikipedia

自動運転の開発は、機械学習のために公道での実データを集める必要がある性質上、これらの規制が緩和され、様々な状況下でのデータが集まるようにならなければ、開発・発展は難しいと言える。


と、ここまでで続きは次回。今回は業界の人には耳タコな話ばかりだったけど、後編はもう少し技術にフォーカスしたいと思う。

2020年、人工知能は車を運転するのか 〜自動運転の現在・過去・未来〜

2020年、人工知能は車を運転するのか 〜自動運転の現在・過去・未来〜

Web検索がやりづらい世界になってしまった

Google Spreadsheetの便利機能に IMPORTXML ってあるじゃないですか。あれを使ってGoogleの検索結果を取得して、1件目のリンクを取得したかったんですよ。ざっと5000件くらい。

ちょちょいってできるかと思ったけど、意外とできなかった。

なんでもプログラムからの検索結果の取得は Google Custom Search を使わないといけないそうで。なのでGoogle AppScript を書いたんですよ。

function imFeelingLucky(query) {
  var apiUrl = "https://www.googleapis.com/customsearch/v1?"
  var queryParams = "&client=google-csbe&cr=countryJP&gl=jp&hl=ja&oe=utf8&num=1&output=xml_no_dtd&safe=off";
  var apiKey = "YOURGOOGLECUSTOMSEARCHAPIKEY";
  var cx = "YOURGOOGLECUSTOMSEARCHAPICX";
  var requestUrl = apiUrl+queryParams+"&key="+apiKey+"&cx="+cx+"&q="+query;
  var response = UrlFetchApp.fetch(requestUrl);
  var json = response.getContentText();
  var data = JSON.parse(json);
  return data.items[0].link;
}

あ、Custom Searchはもともとサイト内検索のための機能の設定だったりするので、検索するサイトの設定をウェブ全体に変更しないとだめでした。

f:id:Kechol:20170220195622p:plain

これでいけるかな、と思ったらまたたくさんエラーでて。API制限ですよ。Custom Search API は100 リクエスト/日 で制限食らっちゃうんですね。

100リクエストって何もできないじゃん!みたいな。Googleさん計算機リソース余りまくってるでしょ!って。調べたらBingも無料枠は1000リクエスト/月しかできなくて。いろいろドキュメント見てみると Google Web Search API が Deprecated になったのは 2010年11月、終了は2014年9月だそうで。これまでよく気が付かなかったな。


GoogleがAPIの制限をこれだけきつくするのは、やっぱり検索エンジンの返す情報が正確になって、より価値を生み出すようになってきたからでしょうか。

今はAIがブームだけれど、Google検索結果に限らず、一見シンプルな結果を返すインターフェースも、裏側では膨大なデータの計算によってなされるというようなことが多くなっていくでしょう。結果からは想像しづらい計算コストが生まれ、その計算結果が、まるで人の手が込んだような価値を生み出すようになるんですから、ITサービスの料金が将来的にどんどん上がっていくのは自然な流れなのかもしれません。

という愚痴でした。

「身近な人が亡くなった後の手続のすべて」を読んで、葬祭業界について少し調べた

確定申告や行政手続がネットでできることも多くなってきた。住宅選びや結婚式場の予約も、ネットが入り口になることが当たり前になってきた。

そんななかで、同じく大きなライフイベントの一つである葬儀法要や相続手続きについてはネット化、もしくは簡略化されていっているのだろうかと疑問に思い、本を読んで少し調べてみた。

身近な人が亡くなった後の手続のすべて

身近な人が亡くなった後の手続のすべて

  • 作者: 児島明日美,福田真弓,酒井明日子,児島充
  • 出版社/メーカー: 自由国民社
  • 発売日: 2014/11/29
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

葬祭業界では低価格化が進んでいる

葬祭業の市場規模

葬祭業の市場規模は 経産省の特定サービス産業実態調査報告書 で確認することができる。

平成27年の数字だと、冠婚葬祭業務の内訳以下のようになっており、実は結婚式場業務の2倍くらいの規模がある。

  • 結婚式場業務: 年間売上高 4757億円
  • 葬儀業務: 年間売上高 1兆1301億円

また、葬儀業務のなかでも式典進行・設営・葬具業務の売り上げが5600億円と、一番構成比が高い。

なんだけど、実はこの葬祭業の年間売上高は減少の一途を辿っており、過去三年間で半分くらいになっている。

  • 平成25年: 2兆1584億円
  • 平成26年: 1兆5432億円 (前年比▲28.5%)
  • 平成27年: 1兆1301億円 (前年比▲26.7%)

なぜ葬祭業の市場規模は縮小しているのか

売上高は基本的に単価 x 購入回数で計算できる。つまり、葬祭業務の料金と、葬祭を行う回数が問題になる。

国立社会保障・人口問題研究所の人口統計資料 によると、死亡数は年々増加の一途を辿っており、死亡数が減っているわけではない。なので、おそらく葬祭を行う回数はそれほど減っていない。

f:id:Kechol:20170219171946g:plain

ということは、売上高の減少は葬儀業務の低価格化が原因なのだろうか。結論から言うとそのとおりで、家族葬・直葬の一般化が全体的な葬儀業務の低価格化の原因となっていると思われる。

最近では通夜や告別式をしない直葬サービスが多くでてきており、イオンなどの異業種も参入してきている。直葬サービスでは通夜・告別式を行わないため、サービス料金は一般的な葬儀と比べて安く収まる。

余談だけど、ちょっと前に”DIY葬”をやった増田がバズったりもした。実は葬儀業務には資格等は必要ないため、自分でやっても法的には問題ない。はてブのコメントも含めてとても興味深いと思う。

お坊さんをお呼びした家族葬(D.I.Y.葬)が総額42,360円で完璧に出来たお話

葬儀の簡略化で影響を受ける寺院たち

こうした直葬サービスの一般化で影響を受けるのは、葬儀屋だけではない。特に葬儀の際のお布施が収入源の一つとなる寺院の危機感も強いみたいだ。

平成25年の文化庁発行の宗務時報 に載せられた北海道大学大学院教授の論説でも、最近の社会構造の変化と宗教の役割について論じられている。

寺院仏教では葬儀・法要をますます手放さなければならない状況が出てくる。葬祭業や墓苑業は寺院の領域に食い込んだとしても協働関係は維持していた。問題は,直葬といって正式な葬儀・法要を営まない(営めない)人が増えてきたことと,墓の維持管理が根本的に無理な世代が登場してきたことである。(略)年老いて後,子供が近場にいるというのは贅沢な望みである。葬送を自由に行うとか自分らしいエンディングとかいったライフスタイルの問題から寺離れが進んでいるのではない。檀家になれないのである。檀家による護持会費はもとより,法務による布施は当てにならぬものになろう。

世代交代に伴って宗教観もより変わってくるだろうし、こうした家族葬・直葬への流れはより一般化していくんじゃないだろうか。

葬儀前後の難儀な手続き

さて、葬儀前後の手続きの話。本を読む限り、葬儀前後の手続きはとにかく書類仕事が多くて大変。以下に関係書類を本のなかから抜粋してみた。

葬儀直前・直後

  • 死亡診断書
  • 死体検案書
  • 死亡届
  • 火災許可申請書

葬儀後(生活サービス等)

  • 公共料金の支払い停止
  • 各種民営サービスの支払停止
  • 葬祭費・埋葬料の支給申請
  • 高額療養費の請求申請(入院等で高額な医療費を支払っていた場合)

戸籍関連

  • 復氏届(配偶者の死後姓を戻す場合)
  • 婚姻関係終了届(配偶者の死後婚姻関係を解消する場合)
  • 改葬許可申請(改葬する場合)

年金関連

  • 年金の需給停止
  • 遺族年金の受給手続
  • 寡婦年金の受給手続
  • 死亡一時金の需給手続
  • 児童扶養手当の受給手続

相続手続

  • 相続人の調査(戸籍謄本取得)
  • 相続の放棄/限定承認
  • 遺言書の検認
  • 遺産分割協議
  • 預貯金の相続手続
  • 株式・不動産等の相続手続
  • 保険金の受取手続
  • 遺留分減殺請求

相続後の税金関連

  • 青色申告承認申請
  • 所得税の準確定申告
  • 相続税の申告

葬儀・生活・戸籍・年金・相続・税金とカテゴリ分けできそうだけど、特に相続(とその後の税金関連)が特殊で大変な業務といえそう。

だけど、相続手続きについては、手続きに入ってしまえば司法書士や税理士に相談しながら遺族が話し合って決めることであって、簡略化がされる余地というのは考えつかなかった。

一方で、本の中では、遺言やエンディングノートを残すこと、生前贈与の手続きをすることが死後の手続きの簡略化や税金対策のためにおすすめされており、こうした手続きは一人で可能なので、(いわゆる終活の一環として)オンライン化、簡単化するサービスみたいなものは今後出てきても不思議ではないように思う。実際に本を読んでみても、遺言の書き方のルールや税金控除の手続きが複雑なように感じた。

もうあるのかな、面倒で調べてないけど。。


というわけで葬祭業と相続手続きについて少し調べた話でした。

おくりびと [DVD]

おくりびと [DVD]

タニタの体組成計を買ったのでPDCAを回していこうと思う

タニタの体組成計を買ったのでPDCAを回していこうと思う

今年の目標の一つがダイエット(-5kg)なのに、体重計持ってなかったなと思ったので、少し前にタニタの体組成計を買った。1万円くらいするかと思ったけど3000円くらいで済んでよかった。

タニタ 体組成計 BC-705N-WH(ホワイト) 乗るピタ機能で簡単測定

タニタ 体組成計 BC-705N-WH(ホワイト) 乗るピタ機能で簡単測定

体組成計の機能

体組成計は以下の項目がわかる。体重以外は予測値なので、例えば体脂肪率とかだと1%くらいは誤差でずれるけど気にしてない。

  • 体重
  • 体脂肪率
  • BMI
  • 筋肉量
  • 内臓脂肪レベル
  • 基礎代謝量
  • 体内年齢

もっと高い体組成計で有名なものだと、Withings とか Fitbit Aria とかあるみたい。高い体組成計は骨量や体水分量が測れたり、WiFi/Bluetoothでアプリにデータを同期してくれたりするらしい。IoTはすごい。

体内年齢わかるの地味に楽しい。18歳だうぇい。

f:id:Kechol:20170216191617j:plain:w300

体重を測って記録

買ってからは寝る前に測って、Fitbitのアプリで記録している。時々忘れる。

f:id:Kechol:20170216203313p:plain:w320

目標まではあと0.8kgなので、進捗はまあまあです。

測り始めてからは以下のようなことに気づいた。特に意識が変わって行動が変わってきたことが大きいと思う。

  • 体重を毎日測るという行為をすることでダイエットの意識が上がる
    • これまでなんとなく、痩せたい/体重維持したいと思ってたけど実際に数字で見始めるとすごく意識するようになる
  • 飲んだ日の翌日の体重は増える
    • 飲み会行くと太るなって意識が芽生える
      • これは排泄されるまでのトータルで考えないとほんとは意味ないけどね
  • 排泄すると如実に体重が減る
    • まじでもっとうんち出て欲しいって気分になる
  • 運動しても即効性のある変化はない
    • 今んとこ週2で毎回4kmくらい走ってる
    • しかし運動はじわじわ効いてくる気がしている

KPI管理とPDCA

ここからは蛇足なんだけど、ZUU社長鬼速PDCAを読んでいる人を見かけたのでPDCAについて考えてみようと思う。ちなみに僕はこの本はまだ読んでいないので間違っているかもしれない。

鬼速PDCA解剖図〜PLAN→DO→CHECK→ADJUSTをどう行き来するか?〜 | ZUU社長 冨田和成の鬼速ブログ

実際、ダイエットを目的として体重を測っている人は多いと思うけど、体重を測っているだけだと痩せなくて、行動を変えていく必要がある。

体重というのは、「○kg痩せる」というゴール指標、KGI(Key Goal Indicator)になる。ただ、体重は直接変えることができないので、これを設定しても痩せることはできない。

なので、体重を因数分解する。一般に体重は、摂取カロリーが消費カロリーを上回ると増えていくので、単純化すると

体重の増減 = 摂取カロリー - 消費カロリー

となる。摂取カロリーは毎日の食事、消費カロリーは基礎代謝量と運動量で決まる。この摂取カロリーと消費カロリーは、KPI(Key Performance Indicator、ゴール達成のための大切な指標)として管理することで、体重の増減を予測できるようになる。ポイントは、体重は直接動かすことができないけれども、摂取カロリー/消費カロリーは行動を変えれば動かせる(飲みの機会を減らす、ジムに行く)ということになる。

さらに、このKPIを達成するための行動目標(鬼速PDCAでいうKDI)を設定する。摂取カロリーをKPIとするのであれば、飲み会を週1に制限する、一日の食事は2回にする、などとして、その行動をしていればKPIも達成されるような状態に持っていく。

このように、KGIをKPI、行動目標まで落とし込むことで、考えずにやることやっていれば勝手に体重が減っていくシステムができる。ここまでが設計の話。

実際にPlan - Do - Check - Action/Adjust で回していくのは、この設計(Plan)ありきの話で、実際に行動してみた結果(Do)、KPIにどれくらいのインパクトがあったのかを確認して(Check)、行動目標を修正していく(Action/Adjust)。週2の運動だと消費カロリーがあまり上がらないから週3にしよう、とか、食事を一日2回にしたら仕事の能率が遅くなってしまったのでやっぱり3回に戻そう、とか。

現実世界だと、よしじゃあ体重30kg落とそう、みたいな無理なKGIを設定する人がいたり、KPIは摂取カロリーだから、今日から食事は一切抜き!みたいな考えなしがいたりするので、まず最初のうちは行動の結果がそもそもKPI, KGIにインパクトがあるのか、KGIに無理はないのかを確認することから始める必要があると思われる。


PDCAを回して痩せたい話でした。