Jekyll2023-07-19T01:01:40+00:00https://blog.sankichi.net/feed.xmlblog.sankichi.netTakahiro Miyoshi's BlogTakahiro Miyoshi市区町村の境界を GeoJSON で返す Web API もどきをつくった2022-03-23T00:00:00+00:002022-03-23T00:00:00+00:00https://blog.sankichi.net/dev/shikuchoson-boundaries<p>市区町村のハザードマップを手軽につくれるソフトウェア <a href="https://github.com/sankichi92/shikuchoson-hazardmap-template">shikuchoson-hazardmap-template</a> をつくっている(詳細は「<a href="/dev/tokyo_oss_party_2021/">Tokyo OSS Party!! 2021 に参加した</a>」)。
shikuchoson-hazardmap-template には、設定ファイルの都道府県名と市区町村名から市区町村の境界を取得し、全画面表示の地図の中心に表示する機能がある。
初期実装ではこの市区町村の境界を <a href="https://www.openstreetmap.org/">OpenStreetMap</a> の <a href="https://osmlab.github.io/learnoverpass/">Overpass API</a> から取得していたのだが、国土地理院の地図上に表示される行政区域界とはズレてしまう問題があった。</p>
<p>たとえば、<a href="https://www.openstreetmap.org/relation/2682891">https://www.openstreetmap.org/relation/2682891</a> は OpenStreetMap の茨城県つくば市の行政区域界である。
OpenStreetMap 上にこれを表示するのはなんの違和感もないが、これを<a href="https://maps.gsi.go.jp/development/ichiran.html">地理院タイル</a>の淡色地図上に表示すると、地図のもつ行政区域界とところどころ重ならない部分が出てくる。</p>
<p>解決策として、ベースマップを地理院タイルではなく OpenStreetMap にするという方法もあるが、</p>
<ul>
<li>災害情報を目立たせるためシンプルな淡色地図を使いたい</li>
<li>自治体で利用・公開することを想定しているため、行政から提供されている地図を使いたい</li>
</ul>
<p>という理由から、行政区域界の取得元を国のオープンデータから取得することにした。</p>
<p>市区町村の行政区域界は、<a href="https://nlftp.mlit.go.jp/">国土交通省国土数値情報ダウンロードサイト</a>で提供されている。
ただし、都道府県または全国単位で1ファイルまとめられた Shapefile または GeoJSON(を圧縮した ZIP ファイル)しか配布されていない。
そのため、任意の市区町村の行政区域界をフロントエンドで動的に取得するのは現実的ではない。</p>
<p>そこで、全国の行政区域界がまとまった GeoJSON を市区町村単位に分割する Ruby スクリプトを書いて、それを GitHub Pages で配布するようにした。
詳細は GitHub リポジトリ <a href="https://github.com/sankichi92/shikuchoson-boundaries">sankichi92/shikuchoson-boundaries</a> にある。</p>
<p>単に静的なファイルを置いているだけだが、API-like に使えるので、たとえば <a href="https://leafletjs.com/">Leaflet</a> を使って次のようなコードで市区町村の行政区域界を表示できる(<a href="/misc/shikuchoson-boundaries.html">実行例はこちら</a>)。</p>
<div class="language-javascript highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">const</span> <span class="nx">map</span> <span class="o">=</span> <span class="nx">L</span><span class="p">.</span><span class="nx">map</span><span class="p">(</span><span class="dl">"</span><span class="s2">map</span><span class="dl">"</span><span class="p">);</span>
<span class="c1">// 地理院タイルの淡色地図をベースマップにする</span>
<span class="nx">L</span><span class="p">.</span><span class="nx">tileLayer</span><span class="p">(</span><span class="dl">"</span><span class="s2">https://cyberjapandata.gsi.go.jp/xyz/pale/{z}/{x}/{y}.png</span><span class="dl">"</span><span class="p">,</span> <span class="p">{</span>
<span class="na">attribution</span><span class="p">:</span>
<span class="dl">"</span><span class="s2"><a href='https://maps.gsi.go.jp/development/ichiran.html' target='_blank'>地理院タイル</a></span><span class="dl">"</span><span class="p">,</span>
<span class="p">}).</span><span class="nx">addTo</span><span class="p">(</span><span class="nx">map</span><span class="p">);</span>
<span class="p">(</span><span class="k">async</span> <span class="p">()</span> <span class="o">=></span> <span class="p">{</span>
<span class="kd">const</span> <span class="nx">code</span> <span class="o">=</span> <span class="dl">"</span><span class="s2">08220</span><span class="dl">"</span><span class="p">;</span> <span class="c1">// つくば市の行政区域コード</span>
<span class="kd">const</span> <span class="nx">response</span> <span class="o">=</span> <span class="k">await</span> <span class="nx">fetch</span><span class="p">(</span>
<span class="s2">`https://shikuchoson-boundaries.sankichi.app/</span><span class="p">${</span><span class="nx">code</span><span class="p">}</span><span class="s2">.geojson`</span>
<span class="p">);</span>
<span class="kd">const</span> <span class="nx">geojson</span> <span class="o">=</span> <span class="k">await</span> <span class="nx">response</span><span class="p">.</span><span class="nx">json</span><span class="p">();</span>
<span class="c1">// 地図の表示領域を行政区域界に合わせる</span>
<span class="nx">map</span><span class="p">.</span><span class="nx">fitBounds</span><span class="p">([</span>
<span class="p">[</span><span class="nx">geojson</span><span class="p">.</span><span class="nx">bbox</span><span class="p">[</span><span class="mi">1</span><span class="p">],</span> <span class="nx">geojson</span><span class="p">.</span><span class="nx">bbox</span><span class="p">[</span><span class="mi">0</span><span class="p">]],</span>
<span class="p">[</span><span class="nx">geojson</span><span class="p">.</span><span class="nx">bbox</span><span class="p">[</span><span class="mi">3</span><span class="p">],</span> <span class="nx">geojson</span><span class="p">.</span><span class="nx">bbox</span><span class="p">[</span><span class="mi">2</span><span class="p">]],</span>
<span class="p">]);</span>
<span class="c1">// 行政区域界を地図に追加する</span>
<span class="nx">L</span><span class="p">.</span><span class="nx">geoJSON</span><span class="p">(</span><span class="nx">geojson</span><span class="p">).</span><span class="nx">addTo</span><span class="p">(</span><span class="nx">map</span><span class="p">);</span>
<span class="p">})();</span>
</code></pre></div></div>
<p>静的なものなので、もちろん複数の行政区域界を同時に取得したり、市区町村名や緯度経度で検索したりといったことはできない。
が、shikuchoson-hazardmap-template で使うにはこれで十分である。</p>
<p>また、GeoJSON の分割にあたって次のような加工をおこなっている。</p>
<ul>
<li>飛び地の Polygon を MultiPolygon にマージ</li>
<li>Feature のプロパティのキーを「N03_001」から「都道府県名」のように意味のあるものに変更</li>
<li>bbox フィールドの追加</li>
</ul>
<p>行政区域界のデータソースを置き換えた結果については、<a href="https://github.com/sankichi92/shikuchoson-hazardmap-template/issues/20#issuecomment-1073950680">sankichi92/shikuchoson-hazardmap-template#20</a> に Before / After のスクリーンショットがある。</p>
<hr />
<p>今回は用途に十分かつ無料ということで静的ファイルを置くだけという方法を取ったが、さまざまなユースケースに応用できる柔軟な API が国から提供されるのが理想だと思う。</p>
<p>たとえば、こうした地物データを提供する標準化された API 仕様の一つに <a href="https://ogcapi.ogc.org/features/overview.html">OGC API - Features</a> がある。
また、その OSS 実装として <a href="https://pygeoapi.io/">pygeoapi</a> というものもある。</p>
<p>もちろん ZIP ファイルを置いておくだけよりずっと手間もお金もかかるが、需要の高いデータについてはやる価値があると思う。
地理院タイルや<a href="https://disaportal.gsi.go.jp/hazardmap/copyright/opendata.html">ハザードマップポータルサイト</a> なんかはとても扱いやすい。</p>
<hr />
<p>最後に余談だが、緯度経度の数値の扱いでハマった。
Ruby で行政区域界データの緯度経度を含む JSON をパースすると次のようになる。</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'json'</span>
<span class="no">JSON</span><span class="p">.</span><span class="nf">parse</span><span class="p">(</span><span class="s1">'[140.059931051377021,36.236172864686012]'</span><span class="p">)</span>
<span class="c1">#=> [140.05993105137702, 36.23617286468601]</span>
</code></pre></div></div>
<p>Float 型として読み込まれて値が丸められてしまっている。</p>
<p>パース時に BigDecimal として扱う方法を探すと、<a href="https://rubyapi.org/3.1/o/json#module-JSON-label-Parsing+Options">Ruby のドキュメント</a> にはないが、<a href="https://github.com/flori/json/pull/223">https://github.com/flori/json/pull/223</a> より、<code>decimal_class</code> というオプションがあるようだった。</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'bigdecimal'</span>
<span class="nb">require</span> <span class="s1">'json'</span>
<span class="nb">hash</span> <span class="o">=</span> <span class="no">JSON</span><span class="p">.</span><span class="nf">parse</span><span class="p">(</span><span class="s1">'[140.059931051377021,36.236172864686012]'</span><span class="p">,</span> <span class="ss">decimal_class: </span><span class="no">BigDecimal</span><span class="p">)</span>
<span class="c1">#=> [0.140059931051377021e3, 0.36236172864686012e2]</span>
</code></pre></div></div>
<p>しかし、これだと JSON にシリアライズするとき、数値ではなく文字列になってしまう。</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">hash</span><span class="p">.</span><span class="nf">to_json</span>
<span class="c1">#=> "[\"0.140059931051377021e3\",\"0.36236172864686012e2\"]"</span>
</code></pre></div></div>
<p>最終的に「<a href="https://developers.freee.co.jp/entry/freee-api-bigdecimal">freee の API では BigDecimal をどう扱うべきなのか?</a>」を参考に ActiveSupport と <a href="https://github.com/ohler55/oj">Oj</a> を使って次のように書いた。</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'active_support/core_ext/big_decimal/conversions'</span>
<span class="nb">require</span> <span class="s1">'oj'</span>
<span class="nb">hash</span> <span class="o">=</span> <span class="no">Oj</span><span class="p">.</span><span class="nf">load</span><span class="p">(</span><span class="s1">'[140.059931051377021,36.236172864686012]'</span><span class="p">)</span>
<span class="c1">#=> [0.140059931051377021e3, 0.36236172864686012e2]</span>
<span class="no">Oj</span><span class="p">.</span><span class="nf">dump</span><span class="p">(</span><span class="nb">hash</span><span class="p">)</span>
<span class="c1">#=> "[140.059931051377021,36.236172864686012]"</span>
</code></pre></div></div>Takahiro Miyoshi市区町村のハザードマップを手軽につくれるソフトウェア shikuchoson-hazardmap-template をつくっている(詳細は「Tokyo OSS Party!! 2021 に参加した」)。 shikuchoson-hazardmap-template には、設定ファイルの都道府県名と市区町村名から市区町村の境界を取得し、全画面表示の地図の中心に表示する機能がある。 初期実装ではこの市区町村の境界を OpenStreetMap の Overpass API から取得していたのだが、国土地理院の地図上に表示される行政区域界とはズレてしまう問題があった。地球観測衛星データ提供システムに携わって3ヶ月経った2021-12-31T00:00:00+00:002021-12-31T00:00:00+00:00https://blog.sankichi.net/essay/about_eo_data_providing<p>10月1日から「地球観測衛星データ提供システム」の開発・運用に携わっている。
それまで「地球観測衛星データ提供システム」についてなにも知らなかったが、3ヶ月経ってどういうものか少しずつわかるようになってきた。
この領域について日本語の情報がインターネットにあまりないので、簡単に紹介してみようと思う。
これをきっかけに地球観測衛星データやそのエコシステムに興味をもってもらえるとうれしい。</p>
<h2 id="section">地球観測衛星データとは</h2>
<p>人工衛星にも、測位衛星や通信衛星、科学衛星などいろいろな種類がある。
なかでも地球観測衛星は、さまざまなセンサをつかって地球を観測する衛星である。
地球観測衛星のセンサで取得したデータが地球観測衛星データであり、わかりやすいものとして光学センサで撮影した衛星写真がある。
ほかにも、温室効果ガスや海面水温、植生分布などなど、さまざまなものが地球観測衛星により観測されている。
また、人工衛星による地球観測は「リモートセンシング」という技術の一種であり、地球観測衛星をあつかう学術分野としてはこちらが一般的らしい。</p>
<p>地球観測衛星データは大雑把にいえば画像のようなものだが、RGB値に限らずさまざまな物理量をもつ。
さらに、衛星やセンサの種類、いつどこで撮影したものかを表す位置情報や時間、どのような前処理が施されたかなど、さまざまなメタデータが紐づけられる。</p>
<p>これら地球観測衛星データの解析には、一般に GIS(Geographic Information System・地理情報システム)が用いられる。
有名なものに <a href="https://www.esrij.com/products/arcgis/">ArcGIS</a> やオープンソースの <a href="https://qgis.org/">QGIS</a> がある。また、Web アプリケーションとして実装されたものは Web GIS と呼ばれる。
もちろん Python のようなプログラミング言語をつかって解析することもできる。</p>
<p>地球観測衛星データやリモートセンシングについてより詳しくは以下のページを参照してほしい。</p>
<ul>
<li><a href="https://earth.jaxa.jp/ja/eo-knowledge/">地球観測衛星の基礎知識 – JAXA 第一宇宙技術部門 Earth-graphy</a></li>
<li><a href="https://www.restec.or.jp/knowledge/index.html">リモートセンシング基礎知識・学習 | 一般財団法人リモート・センシング技術センター</a></li>
<li><a href="https://sorabatake.jp/satellite/introduction/?popular_sort=1">衛星データ入門 | 宙畑</a></li>
</ul>
<h2 id="section-1">地球観測衛星データ提供システムとは</h2>
<p>地球観測衛星のセンサで取得した値が地上で解析につかえるデータになるまで、さまざまな経路を通りさまざまな処理が行われる。
しかし、ここでいう「地球観測衛星データ提供システム」は、そうした処理を行うシステムではなく、処理後の解析可能なデータ(プロダクトと呼ばれる)をオンラインで提供する出口にあたるシステムである。</p>
<h3 id="section-2">システムへの書き込み</h3>
<p>地球観測衛星データ提供システムへのデータの書き込みは、基本的に前処理システムからしか行われない。
前処理システムによって処理され解析可能になったプロダクトが、データ提供システムに追加される。</p>
<p>衛星やセンサの種類にもよるが、衛星が稼働している限りそのデータは増え続け、ペタバイト級のデータになる。
はじめて聞いたとき規模感がわからなかったが、地球を回りながら超高解像度の写真をずっと撮り続けていると考えると、たしかにあっという間に相当なデータ量になりそうだと納得できた。</p>
<h3 id="ui-">検索 UI とファイル提供</h3>
<p>トラディショナルな地球観測衛星データ提供システムでは、ユーザは Web UI(や FTP)でプロダクトを検索したりダウンロードしたりできる。</p>
<p>先ほどにも書いたように地球観測衛星データは地理空間データであり時系列データでもある。
その検索クエリは複雑なものになりがちで、それに合わせて検索 UI も難しいものになる。</p>
<h3 id="api">地理空間データ API</h3>
<p>Web UI から検索してダウンロードできるファイルもまだまだ手軽に扱えるものではない。
いうなれば写真の RAW ファイルのようなものであり、解析用途にはこれでもよいが、Web で可視化するような場合には目的の領域をトリミングしたり、広域を表示できるようリサイズしたり、扱いやすいファイルフォーマットに変換したり、その他データ特有のスタイリングをしたりする必要がある。
こうした処理を済ませたうえでアプリケーションから直接扱えるように提供するのが地理空間データ API である。</p>
<p>地理空間データ API(に限らず地理空間データ全般)の標準仕様は <a href="https://www.ogc.org">OGC (Open Geospatial Consortium)</a> が策定している。
もともと SOAP 的な XML ベースのインタフェースが採用されていたが、近年は <a href="https://ogcapi.ogc.org">OGC API</a> として REST 風に策定し直されているらしい。
また、こうした API 等での提供に最適化された <a href="https://www.cogeo.org">COG (Cloud Optimized GeoTIFF)</a> というファイルフォーマットも一般的になってきているようだ。</p>
<p>オープンソースの API 実装として、たとえば <a href="https://earthdata.nasa.gov/covid19/">NASA の COVID-19 Dashboard</a> のサーバサイド実装 <a href="https://github.com/NASA-IMPACT/covid-api">NASA-IMPACT/covid-api</a> がある。
ざっくり見たところ、AWS のサーバレスアーキテクチャを採用していて、COG の特徴を活かしたいまどきな構成になっている。</p>
<h3 id="section-3">カタログ連携</h3>
<p>地球観測衛星データ提供システムは、おそらく地球観測衛星のデータ提供を行う組織の数だけあるだろう。
こうしたシステムを横断的に検索できるよう、メタデータのカタログ連携が行われる。</p>
<p>地球観測衛星に関する国際的な調整を行う組織として、<a href="https://ceos.org">CEOS (Committee on Earth Observation Satellites)</a> がある。
<a href="https://idn.ceos.org">CEOS IDN (International Directory Network)</a> にはさまざまな組織の地球観測衛星データのメタデータが登録されていて、横断的な検索ができる。</p>
<p>また、比較的新しいカタログの標準仕様としては <a href="https://stacspec.org">STAC (SpatioTemporal Asset Catalogs)</a> がある。</p>
<h3 id="section-4">プラットフォーム</h3>
<p>従来は地球観測衛星データをダウンロードしてローカルなど別の環境で解析するというのが一般的なフローだった。
しかし、データをダウンロードすることなくクラウド上でそのまま解析まで行えるプラットフォームも増えてきている。</p>
<p>代表的なプラットフォームとして <a href="https://earthengine.google.com">Google Earth Engine</a> がある。
また、日本発の <a href="https://www.tellusxdp.com">Tellus</a> は経産省主導でさくらインターネットが開発している。
オープンソースの取り組みとしては <a href="https://www.opendatacube.org">Open Data Cube</a> というものもある。</p>
<h2 id="section-5">おわりに</h2>
<p>地球観測衛星データは現状まだ身近なデータとはいえないが、これまでに挙げたように技術の発展とともに手軽に扱えるようになってきている。
もし少しでも興味をもってもらえたらなら、ぜひ一度触れてみてほしい(地球観測衛星データの利活用に関してはぼく自身もまだまだわかっていないことが多いのだけれど)。</p>Takahiro Miyoshi10月1日から「地球観測衛星データ提供システム」の開発・運用に携わっている。 それまで「地球観測衛星データ提供システム」についてなにも知らなかったが、3ヶ月経ってどういうものか少しずつわかるようになってきた。 この領域について日本語の情報がインターネットにあまりないので、簡単に紹介してみようと思う。 これをきっかけに地球観測衛星データやそのエコシステムに興味をもってもらえるとうれしい。Tokyo OSS Party!! 2021 に参加した2021-12-09T00:00:00+00:002021-12-09T00:00:00+00:00https://blog.sankichi.net/dev/tokyo_oss_party_2021<p>11月20日から12月4日の2週間にかけてオンラインで開催された <a href="https://tokyo-oss-party.com/">Tokyo OSS Party!!</a> 2021 という東京都主催のハッカソンに参加した。
1人チーム「Ruby が好き」として <a href="https://github.com/sankichi92/shikuchoson-hazardmap-template">shikuchoson-hazardmap-template</a> をつくり、結果として最優秀賞をいただいた。</p>
<ul>
<li>イベント詳細: <a href="https://tokyo-oss.connpass.com/event/229199/">https://tokyo-oss.connpass.com/event/229199/</a></li>
<li>成果発表: <a href="https://www.youtube.com/watch?v=FivWsvLAAyE">https://www.youtube.com/watch?v=FivWsvLAAyE</a></li>
</ul>
<h2 id="section">参加の動機</h2>
<p>参加の動機は大きく以下の2つ。</p>
<ul>
<li>行政(東京都)の OSS 活用の現状やノウハウが知りたかった</li>
<li>コードを書く目的がほしかった</li>
</ul>
<p>まず、前者について。
この10月、Web サービスの会社からある独立行政法人に転職した。
Web 業界とはそれなりにギャップがあることは覚悟していたが、Web システムの開発・運用やクラウド移行がメインの業務と聞いていて、前職の経験を活かせるだろうと思っていた。
しかし、行政機関の情報システムと Web 業界とのギャップは想像以上で、転職して2ヶ月経ったいまも本番環境で動くコードを1行も書いていない。
東京都は<a href="https://github.com/tokyo-metropolitan-gov/covid19">新型コロナウイルス感染症対策サイト</a>(前職の同僚が関わっていた)等でいわゆる Web 的な開発や OSS の活用をはじめていることは知っていたので、そのノウハウを得て仕事に還元したいと考えた。</p>
<p>後者については、すでに書いたとおりコードを書く機会が減ったので、ただただ単純に何かしらコードを書きたかった。
ハッカソンでなくともコードは書けるが、参加すれば「課題」と「締切」が自動的に与えられるという点が大きい。</p>
<p>ちなみに、ハッカソンを知ったきっかけは、<a href="https://twitter.com/GitHubJapan">@GitHubJapan</a> がリツイートしていた次のツイートだった。</p>
<!-- raw HTML omitted -->
<h2 id="section-1">成果物について</h2>
<p>プロダクトの背景や目的については以下のリンクに書いたので、そちらを参照してほしい。</p>
<ul>
<li>リポジトリ: <a href="https://github.com/sankichi92/shikuchoson-hazardmap-template">https://github.com/sankichi92/shikuchoson-hazardmap-template</a></li>
<li>事前審査資料: <a href="https://hackmd.io/@hackcamp89/Hk7-Y7HuK">https://hackmd.io/@hackcamp89/Hk7-Y7HuK</a></li>
<li>発表資料: <a href="https://speakerdeck.com/sankichi92/shikuchoson-hazardmap-template">https://speakerdeck.com/sankichi92/shikuchoson-hazardmap-template</a></li>
</ul>
<p>「Ruby が好き」というチーム名だが、プロジェクトは <a href="https://create-react-app.dev/">Create React App</a> と <a href="https://www.typescriptlang.org/">TypeScript</a> で作成している。
はじめは <a href="https://nextjs.org/">Next.js</a> でつくろうとしたが、<a href="https://stackoverflow.com/questions/57704196/leaflet-with-next-js">React Leaflet をつかうのがちょっと面倒だった</a>のと、シンプルな SPA で完結できそうだったのではやい段階で切りかえた。</p>
<p>地図ライブラリとしては、<a href="https://leafletjs.com/">Leaflet</a>(および <a href="https://react-leaflet.js.org/">React Leaflet</a>)を利用した。
ほぼ初めてだったが、レイヤーの概念に慣れさえすれば、いろいろな情報を簡単に地図上へ重ねることができる。</p>
<p>難しかったのは地理空間データの取り扱いで、これに関しては <a href="https://gis-oer.github.io/gitbook/book/">GIS オープン教材</a>を参考にした。</p>
<h2 id="section-2">ハッカソンの様子</h2>
<p>先頭集団で入賞を競い合うというよりは、みんなで完走を目指すようなハッカソンだったと思う。</p>
<p>期間中のコミュニケーションは <a href="https://join.slack.com/t/tokyoossparty/shared_invite/zt-xj39veiu-cr_1brEP_VeNWMQCXs~fPw">Tokyo OSS Party!! の Slack ワークスペース</a>で行われていた。
初日に各チームのチャンネルがつくられたが、すべてパブリックチャンネルで、他のチームの開発の様子も見られるようになっている。</p>
<p>Slack だけでなく、優秀賞(Hazard Map 賞)のチーム「Arumon」は、開催期間中から得られた知見や途中経過を Qiita や note に投稿していた。
この記事で <a href="https://www.openstreetmap.org/">OpenStreetMap</a> の <a href="https://osmlab.github.io/learnoverpass/en/docs/">Overpass API</a> の存在を知り、自分のプロダクトでも利用させてもらった。</p>
<ul>
<li><a href="https://qiita.com/t-kurasawa/items/03e5bc9c9a07d8ff99b7">https://qiita.com/t-kurasawa/items/03e5bc9c9a07d8ff99b7</a></li>
<li><a href="https://note.com/arumon_team/n/n228986f88be1">https://note.com/arumon_team/n/n228986f88be1</a></li>
</ul>
<p>また、行政が主催するだけあって入賞のインセンティブも独特だった。</p>
<blockquote>
<p>選出チームに選ばれると、その後の自治体とのワークショップに参加することができ、その場でその後の具体的な実装について検討がされます。</p>
</blockquote>
<p>動機の1つめにも書いたように、行政のつくったソフトウェアを OSS 化するにあたってのノウハウに興味があったので、これに関してはけっこう期待していた。</p>
<p>しかし、実際のワークショップは、「行政による地域課題解決のための OSS 活用」というハッカソン全体のテーマで自治体職員とシンプルに意見を交わすというものだった。
開発したプロダクトの具体的な実装や今後の利用に関する言及はほぼなく、それらをつかって実際に「地域課題を解決する」というより単に「OSS をテーマに東京都がハッカソンを開催する」ことが目的だったのかと感じられて少しさびしかった。
一方で、東京都の OSS 活用も本当にはじまったばかりで、ハッカソンで生まれたようなプロダクトを実際に活用するにはまだまだハードルがたくさんあるということもよくわかった。</p>
<h2 id="section-3">おわりに</h2>
<p>前職に「リリース後9割」という言葉があった。
リリースがゴールではなく、リリースしてからがスタートというような意味である。</p>
<p>今回つくったプロダクトもかろうじて表に出せたという感じで、まだまだ改善の余地がある。
アイデア自体はそれほどわるくない気がしているので、のんびりと改善していけたらと思う。</p>Takahiro Miyoshi11月20日から12月4日の2週間にかけてオンラインで開催された Tokyo OSS Party!! 2021 という東京都主催のハッカソンに参加した。 1人チーム「Ruby が好き」として shikuchoson-hazardmap-template をつくり、結果として最優秀賞をいただいた。個人開発 Web アプリに GraphQL API を生やして Auth0 で保護した2020-04-26T00:00:00+00:002020-04-26T00:00:00+00:00https://blog.sankichi.net/dev/implement_graphql_api_protected_by_auth0<p><a href="/dev/oauth_2_in_action/">『OAuth徹底入門』を読んだ</a>流れで、学生のころ個人開発した <a href="https://livelog.ku-unplugged.net/">LiveLog</a> に GraphQL API を生やして、<a href="https://auth0.com/">Auth0</a> を使って OAuth 2 で保護してみた。
ドキュメントは <a href="https://github.com/sankichi92/LiveLog/wiki">https://github.com/sankichi92/LiveLog/wiki</a> にあり、 <a href="https://livelog.ku-unplugged.net/graphiql">https://livelog.ku-unplugged.net/graphiql</a> から試すことができる。</p>
<h2 id="auth0--api-">Auth0 を使った API の保護</h2>
<p><a href="https://auth0.com/">Auth0</a> は認証認可等の Identity に関する機能を提供するマネージドサービスである。
<a href="https://qiita.com/sankichi92/items/a853cc814705884d92b3">LiveLog の認証周りは Auth0 を利用して実装している</a>ので、これを API の保護にも使うようにした。</p>
<p>実装に関しては、Auth0 のドキュメントやコミュニティの QA が豊富なので、だいたいこれを読むだけでできた。
起点になるドキュメントは <a href="https://auth0.com/docs/microsites/protect-api/protect-api">https://auth0.com/docs/microsites/protect-api/protect-api</a> である。
リソースサーバーの実装は、アクセストークンが JWT になっているのでこれをいい感じに検証すればよい。</p>
<p>少し工夫したのはクライアントアプリケーションの登録である。
利用者は LiveLog のユーザー(=サークル構成員)だけに限定したかった。
そこで、Third-Party アプリケーションは許可せず、LiveLog から <a href="https://auth0.com/docs/api/management/v2/#!/Clients/post_clients">Auth0 Management API</a> を介して First-Party アプリケーションを登録できるようにした。</p>
<h2 id="graphql">GraphQL</h2>
<p>今回 LiveLog に API を生やすことは決めたものの、それがどう使われるかは不明だった。
とりあえず生やしておけば誰かがいい感じに使ってくれるだろう、とだけ考えていたのである。
そこで、どんなユースケースにもおそらくもっとも柔軟に対応できるであろう <a href="https://graphql.org/">GraphQL</a> を採用することにした。</p>
<p>GraphQL は職場の一部アプリケーションにも導入されており、どんなものかはなんとなく知っていた。
ただ、ぼく自身はまだ使ったことがなかった。
GraphQL を採用した背景には、一度自分で実装してみたかったというのもある。</p>
<p>LiveLog は Ruby on Rails アプリなので、<a href="https://graphql-ruby.org/">graphql-ruby gem</a> を使って実装した。
また、設計にあたっては<a href="https://www.oreilly.co.jp/books/9784873118932/">『初めてのGraphQL』</a>を購入してつまみ読みした。</p>
<p>初めて触った感想としては、<a href="https://github.com/graphql/graphiql/tree/master/packages/graphiql">GraphiQL</a> や <a href="https://github.com/prisma-labs/graphql-playground">GraphQL Playground</a> のような API の実験環境が整っているのがとても便利だった。
また、型を定義するだけでドキュメントを自動生成できるのも非常に楽である。
そして何より、クエリを書いてねらい通りのデータを取ってこれると気持ちがよい。</p>
<p>実装に苦労したのは(GraphQL に限らないが)ページング周りである。
まず、Relay Connection の概念を理解するのに苦労した。
次に、N+1 クエリを避けるのに既存の ActiveRecord の仕組みが使えないので <a href="https://github.com/exAspArk/batch-loader">batch-loader gem</a> を使ったのだが、これも慣れが必要だった。</p>
<p>GraphQL API に関してはまだまだ導入したてで、基本的な query しか実装しておらず利用者もいない。
機能追加したり利用者が現れるようになれば、運用上の難しい点も見えてくるだろうと思う。</p>Takahiro Miyoshi『OAuth徹底入門』を読んだ流れで、学生のころ個人開発した LiveLog に GraphQL API を生やして、Auth0 を使って OAuth 2 で保護してみた。 ドキュメントは https://github.com/sankichi92/LiveLog/wiki にあり、 https://livelog.ku-unplugged.net/graphiql から試すことができる。『OAuth徹底入門』を読んだ2020-04-01T00:00:00+00:002020-04-01T00:00:00+00:00https://blog.sankichi.net/dev/oauth_2_in_action<p>『OAuth徹底入門 セキュアな認可システムを適用するための原則と実践』を読んだ。
<a href="https://www.shoeisha.co.jp/book/detail/9784798159294">https://www.shoeisha.co.jp/book/detail/9784798159294</a></p>
<p>昨年からユーザー・決済基盤部というところに異動して主に決済を担当しているが、ユーザーの方もわかるようにならないとな、という漠然とした思いがあった。
さらに、1月には <a href="https://www.openid.or.jp/summit/2020/">OpenID Summit Tokyo 2020</a> に参加して、認証・認可周りの技術についてモチベーションが高まっていた。
そんな折、2月に翔泳社 Kindle でセールで本書が安くなっていたので購入。</p>
<p>内容は、</p>
<ul>
<li>クライアント</li>
<li>リソースサーバー</li>
<li>認可サーバー</li>
</ul>
<p>の3つを実装しながら OAuth 2 のプロトコルを説明していくというもの。
後半では、OpenID Connect など OAuth 2 の拡張についても触れられている。</p>
<p>演習のコードは <a href="https://github.com/oauthinaction/oauth-in-action-code">https://github.com/oauthinaction/oauth-in-action-code</a> で公開されているが、 Node.js v4.4.1 (+ Express) で書かれており、現在の stable である v12 では動かない。
せっかくなので、一番書きなれた Ruby (+ Sinatra) を使ってスクラッチでやることにした。書いたコードは <a href="https://github.com/sankichi92/oauth-in-action-ruby">https://github.com/sankichi92/oauth-in-action-ruby</a> に公開している。</p>
<p>OAuth 2 に関しては、ライブラリを使ってクライアントを実装したり、仕事で API サーバーに機能追加したりしたことはあった。
ただ、必要に迫られて言われるがままに書いたという感じで、ライブラリや認可サーバーが内部で何をしているのかや、なぜ OAuth 2 を使うのかはよくわからないままだった。</p>
<p>本書で一からクライアント・リソースサーバー・認可サーバーを実装することで、それぞれが何をしているのか・何をする必要があるのかがよく理解できたと思う。
<a href="https://railstutorial.jp/">Ruby on Rails チュートリアル</a> は、その大半をログイン周りの実装に割いているが、それを初めてやったときの感覚に近いものがあった。</p>Takahiro Miyoshi『OAuth徹底入門 セキュアな認可システムを適用するための原則と実践』を読んだ。 https://www.shoeisha.co.jp/book/detail/9784798159294AWS 認定ソリューションアーキテクト – アソシエイト を取得した2020-03-08T00:00:00+00:002020-03-08T00:00:00+00:00https://blog.sankichi.net/misc/aws_certified_solutions_architect_associate<p>1週間前の3月1日に<a href="https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/">AWS 認定ソリューションアーキテクト – アソシエイト</a>を取得した。<br />
<a href="https://www.certmetrics.com/amazon/public/transcript.aspx?transcript=VRXGKJW12BRE1LGS">https://www.certmetrics.com/amazon/public/transcript.aspx?transcript=VRXGKJW12BRE1LGS</a></p>
<p>認定を取ることを決めてから合格までのタイムラインは次のとおり。</p>
<ul>
<li>2/1: 突如思い立って 3/1 に試験を予約する</li>
<li>2/2: Kindle Unlimited の1ヶ月無料体験に加入し、<a href="https://www.amazon.co.jp/dp/B07VFFX6V1/">この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集</a>を読み始める</li>
<li>2/2〜2/23: だらだらと読み進める</li>
<li>2/24: 読み終わったので付属の模擬試験をやってみたところ、65%くらいの正答率で不安になる</li>
<li>2/25〜2/28: 模擬試験で間違えた部分を中心に読み直す</li>
<li>2/29: 再び模擬試験をやると90%を超え、公式のサンプル問題も全問正解だったので安心する</li>
<li>3/1: 受験</li>
</ul>
<p>スコアは 852/1000 だった。</p>
<p>試験会場は、同僚のあいだで評判の良かった<a href="https://cbt-s.com/kabukiza-tc/">銀座CBTS歌舞伎座テストセンター</a>にした。
他の会場との比較はできないが、特に問題なく試験に集中できる会場だった。</p>Takahiro Miyoshi1週間前の3月1日にAWS 認定ソリューションアーキテクト – アソシエイトを取得した。 https://www.certmetrics.com/amazon/public/transcript.aspx?transcript=VRXGKJW12BRE1LGSテッド・チャン『息吹』2020-02-23T00:00:00+00:002020-02-23T00:00:00+00:00https://blog.sankichi.net/sf/%E3%83%86%E3%83%83%E3%83%89%E3%83%BB%E3%83%81%E3%83%A3%E3%83%B3%E3%80%8E%E6%81%AF%E5%90%B9%E3%80%8F<p><a href="https://www.amazon.co.jp/dp/4152098996/">テッド・チャン『息吹』</a>は、大森望訳、2019年刊行の9編を収めた短編集。
以下は、印象に残った作品のメモ。</p>
<h2 id="section">商人と錬金術師の門</h2>
<p>読んだときは、過去改変が行われない決定論タイプのよくあるタイムトラベルものか、と思った。
ただ、最後の作品ノートを読むと「アインシュタインの相対性理論と矛盾しないタイムマシン」とのことで、なるほど、と思った。</p>
<h2 id="section-1">息吹</h2>
<p>SF短編の最高峰のひとつだと思う。
「あなたの人生の物語」といい、どこからこんな発想が生まれるんだ。</p>
<h2 id="section-2">予期される未来</h2>
<p>「予言機」というワンアイデアの短い一編。予言機は、「ボタンを押す一秒<em>前に</em>ライトが光る」小さな装置。</p>
<blockquote>
<p>自由意志を持っているという経験はあまりに強固なので、議論ひとつで覆されることはない。それを覆すために必要なのは実体験であり、予言機がそれを提供する。</p>
</blockquote>
<h2 id="section-3">ソフトウェア・オブジェクトのライフサイクル</h2>
<p>AI の権利の話とか、人間と AI のあいだの愛の話といってしまうとよくある話に聞こえてしまうが、これは一味違う。
作品ノートの次の一節がわかりやすい。</p>
<blockquote>
<p>AIに法的な権利を与えるべきだと登場人物が主張する小説はいくつもあるが、そういう小説は、大きな哲学的疑問に焦点をあてる一方、世俗的な現実をなおざりにしている。</p>
</blockquote>
<p>この作品はその「世俗的な現実」に焦点を当てている。</p>
<blockquote>
<p>経験は最上の教師であるばかりか、唯一の教師でもある。もしアナがジャックスを育てることでなにか学んだとすれば、それは、近道などないということだ。この世界で二十年生きてきたことから生まれる常識を植えつけようとすれば、その仕事には二十年かかる。それより短い時間で、それと同等の発見的教授法をまとめることはできない。経験をアルゴリズム的に圧縮することはできない。</p>
</blockquote>
<h2 id="section-4">偽りのない事実、偽りのない気持ち</h2>
<p>個人の経験がすべて記録され、容易に検索可能になった場合に起こる変化について。
攻殻機動隊の外部記憶装置みたいな「リメン」というソフトウェアが出てくる。
並行して走るティブ族の話がこの作品のテーマを際立たせている。</p>
<blockquote>
<p>あるテクノロジーが人間の認識を変革した最新の例とその次の例とのあいだになんらかの類似点が見出だせるかもしれない</p>
</blockquote>
<h2 id="section-5">オムファロス</h2>
<p>「<a href="https://ja.wikipedia.org/wiki/%E8%8B%A5%E3%81%84%E5%9C%B0%E7%90%83%E8%AA%AC">若い地球説</a>」が考古学的に正しいと確認されていたら、という if の話。</p>
<blockquote>
<p>いくつかの面は、容易に想像できる。成長輪を持たない木々、縫い目のない頭蓋骨。しかし、夜空について考えはじめると、この問いに答えるのはかなり困難になる。</p>
</blockquote>
<h2 id="section-6">不安は自由のめまい</h2>
<p>量子力学の多世界解釈とそれに伴う自由意志の問題をテーマにした作品。
多世界解釈を取り扱ったSFはうさんくさいものが多いが、この作品の「プリズム」という機械はかなりそれっぽい説明がなされている。
特に、単一の量子事象がどのくらい歴史の流れに影響しうるかについて、ピーター・シリトンガの実験がとてもわかりやすかった。</p>
<blockquote>
<p>ヒトラーが権力を手にするのを阻止したいと思っている仮想的な時間旅行者がいたとして、最小限の介入は、ゆりかごの中にいる赤ん坊アドルフを窒息死させることではない。必要なのは、アドルフが受胎する一カ月前に時間遡行し、酸素分子一個を動かすことだけ。</p>
</blockquote>Takahiro Miyoshiテッド・チャン『息吹』は、大森望訳、2019年刊行の9編を収めた短編集。 以下は、印象に残った作品のメモ。ブログテーマを変更した2020-02-13T00:00:00+00:002020-02-13T00:00:00+00:00https://blog.sankichi.net/dev/%E3%83%96%E3%83%AD%E3%82%B0%E3%83%86%E3%83%BC%E3%83%9E%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%97%E3%81%9F<p>ブログテーマを <a href="https://mmistakes.github.io/minimal-mistakes/">Minimal Mistakes</a> からオリジナルテーマに変更した。</p>
<p>きっかけは、最近まとまった文章を書いてないなと思い、久しぶりにブログを開いたことである。
なんともう2年も更新していなかった。</p>
<p>何か書こうかと思ったのだが、どうにもブログの見た目がごちゃごちゃしているのが気になってしまう。
ブログの見た目というのは、記事を書くモチベーションにとって非常に重要である。
そこで、記事を書く前にテーマを刷新することにした。</p>
<h2 id="section">オリジナルテーマについて</h2>
<p>以前のテーマである Minimal Mistakes は最も GitHub スターの多い Jekyll テーマだった。
しかし、2013年に作られたのもあって、それほど新しい感じはしない。
また、機能がとても多く、自分の用途にはオーバースペックに感じていた。</p>
<p>もっとシンプルなテーマはないかと探したが、都合のよいものは見つからなかった。
<a href="https://getpoole.com/">poole</a> がもっとも理想に近かったものの、こちらは逆に拡張性がなさすぎた。</p>
<p>そこで、テーマを自作することにした。
方針は、とにかくメンテしやすいよう徹底的にシンプルにつくることである。</p>
<p>まず第一に、GitHub Pages でビルド・デプロイできるようにした。
こうすることで、ビルド・デプロイに関する一切のスクリプトを書く必要なく、git push するだけで記事を公開できる。
ただ、GitHub Pages は、Jekyll のビルドのみでフロントエンドのビルドは行ってくれない。
そこで、JS は用いず、CSS は CDN で配信されているものを使うことにした。
外部へ依存することになってしまうが、手軽さを重視するうえではそれほど悪くないと思っている。</p>
<p>CSS は <a href="https://getbootstrap.com/">Bootstrap</a> と <a href="https://sindresorhus.com/github-markdown-css/">github-markdown-css</a> を用いている。
github-markdown-css は記事部分のみに用い、追加で<a href="https://github.com/sankichi92/blog.sankichi.net/blob/fa7e637d3443b0ffffd6564bbf456726ba0794dc/_layouts/default.html#L11-L15">5行ほど自前の CSS を書いている</a>。
本当は Bootstrap の <a href="https://getbootstrap.com/docs/4.4/content/typography/#responsive-font-sizes"><code>$enable-responsive-font-sizes</code></a> の設定をいじりたかったが、CDN ではこれを <code>true</code> にしたものの配信は行われていなかったので断念した。
Bootstrap 5 に期待したい。</p>
<h2 id="jekyll-">Jekyll テーマとしての利用方法</h2>
<p>このブログのテーマは gem にはしていないが、<a href="https://github.com/benbalter/jekyll-remote-theme"><code>jekyll-remote-theme</code></a> を使うことで、一応 Jekyll テーマとして再利用できるようにしている。</p>
<p>はじめに適当な Jekyll プロジェクトをつくり、GitHub Pages の設定をしたリポジトリを origin に設定する。</p>
<div class="language-shell highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span>jekyll new your-blog
<span class="nv">$ </span><span class="nb">cd </span>your-blog
<span class="nv">$ </span>git init
<span class="nv">$ </span>git remote add origin https://github.com/you/your-blog.git
</code></pre></div></div>
<p><code>Gemfile</code> を以下のように書き換えて <code>bundle install</code> する。</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="n">source</span> <span class="s2">"https://rubygems.org"</span>
<span class="n">group</span> <span class="ss">:jekyll_plugins</span> <span class="k">do</span>
<span class="n">gem</span> <span class="s2">"github-pages"</span>
<span class="n">gem</span> <span class="s2">"jekyll-octicons"</span>
<span class="k">end</span>
</code></pre></div></div>
<p><code>_config.yml</code> を以下のように書き換える。</p>
<div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="na">author</span><span class="pi">:</span>
<span class="na">name</span><span class="pi">:</span> <span class="s">Your Name</span>
<span class="na">url</span><span class="pi">:</span> <span class="s">https://example.com/</span>
<span class="na">lang</span><span class="pi">:</span> <span class="s">ja-JP</span>
<span class="na">google_analytics</span><span class="pi">:</span> <span class="s">UA-12345678-9</span>
<span class="na">date_format</span><span class="pi">:</span> <span class="s2">"</span><span class="s">%Y年%-m月%-d日"</span>
<span class="na">remote_theme</span><span class="pi">:</span> <span class="s">sankichi92/blog.sankichi.net@fa7e637</span>
<span class="na">plugins</span><span class="pi">:</span>
<span class="pi">-</span> <span class="s">jekyll-feed</span>
<span class="pi">-</span> <span class="s">jekyll-remote-theme</span>
<span class="pi">-</span> <span class="s">jekyll-seo-tag</span>
</code></pre></div></div>
<p>最後に、コミットしてプッシュすれば、このブログのテーマが適用された GitHub Pages がビルド・デプロイされる。</p>
<p>ところで、いまこれを書いていて気づいたが、コードブロックのシンタックスハイライトには対応していない。</p>
<h2 id="section-1">ライセンスについて</h2>
<p>リニューアルを期に、すべての記事を <a href="https://creativecommons.org/licenses/by/4.0/">CC-BY-4.0</a> で提供することにした。
Takahiro Miyoshi あるいは sankichi92 の名前と、記事へリンクを明記してもらえれば、自由に利用してもらってかまわない。</p>Takahiro Miyoshiブログテーマを Minimal Mistakes からオリジナルテーマに変更した。なぜ大人になっても成長を求められるのか2020-02-11T00:00:00+00:002020-02-11T00:00:00+00:00https://blog.sankichi.net/essay/%E3%81%AA%E3%81%9C%E5%A4%A7%E4%BA%BA%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%A6%E3%82%82%E6%88%90%E9%95%B7%E3%82%92%E6%B1%82%E3%82%81%E3%82%89%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%8B<p>先日、上司(の上司)から突然「みよしさんは成長したいですか?」とたずねられた。
上司の手前、「とくに成長したいとか思ってないっす」という答えは印象が悪いし、実際、成長したくないというわけではない。
とはいえ、「成長したいです!」と全面的に肯定するような感じでもない。
そんなことを考えた挙げ句「成長したい……んじゃない……ですかね……?」と曖昧な返事をした。
「じゃあ、なんで成長したいんですか?」と、上司が続ける。
いま「成長したい」と答えたのは、上司に対して小さな見栄を張ったからで、ひいては会社での評価のためである。
しかし、「会社の評価項目にあるからです」という答えは、「主体性」という評価項目に反するので言うべきではない。
それ以前に、会社の評価のために成長したいというのはちょっと違う。
ぼくは「うーん、難しいですね……」といってお茶を濁した。
その後の話からすると、上司自身も「成長」という言葉になにか違和感を持っていたらしい。
ぼくもなぜうまく答えられなかったのか、この上司の質問について少し考えてみたい。</p>
<p>まず、なぜ「成長したいですか?」という質問に即答できなかったのだろう。
小さい頃は簡単だった。
身体的な面で目に見えて成長していたし、成長したい=大きくなりたい、大人になりたいだったからだ。
また、学生の頃もまだ簡単だった。
社会人として一人前になりたい、自立したいと思っていたからだ。
では、どうして社会人になったいまは「成長したい」と即答できないのか。</p>
<p>それは、すでに身体的な成長は止まっているし、自立もできているからだ。
かといって、もうまったく成長することがないかというとそうではない。
自分が人として完成しているなんていえるはずもなく、まだまだ未熟なことだらけだ。
ただ、「大人になりたい」「社会人になりたい」というのに比べると、単純に「成長したい」というのはあまりに漠然としている。
だから、答えにくかったのだと思う。</p>
<p>次に、「なぜ成長したいか」のほうに問いを移そう。
「成長」の先にあるのが人としての完成、つまり自己実現だと考えれば、それは人間の自然な欲求のひとつである。
そう考えると、ぼくが「会社の評価項目にあるから」という答えに違和感を覚えたのは、それが自己実現よりも低い次元の欲求からくるもので、成長の先にあるものではなかったからだとわかる。</p>
<p>ここで、新たな疑問が生まれる。
なぜ、上司が部下の成長を気にかけるのだろう。
つまり、なぜ、会社は社員の成長を求めるのだろうか。</p>
<p>会社が社員の能力向上を求めるのは当然である。
会社の目的のひとつは利潤を追求することであり、社員の能力が向上し、生産性が上がれば、より大きな利潤を得ることができる。</p>
<p>では、なぜ「成長」という言葉を使うのだろう。
そこには「仕事における技術・能力の向上」だけでなく、自己実現のような主観的で全人的なものを含むニュアンスがある。</p>
<p>それは、自己実現に向かって成長する人材のほうが、そうでない人材よりも会社にとって都合がよいからである。
給料がほしいとか、承認されたいといったモチベーションで働く人にとっては、可能な限り少ないコストで会社からより高い評価を得ることが合理的である。
それに対し、仕事と自己実現とが一致している人にとっては、よりよい仕事をすること、それ自体が合理的な行動になる。
また、給料や地位が目的の人は、より高い給料や地位を得られる機会があればすぐに離職してしまうだろう。</p>
<p>はじめの会話の中では、<a href="https://medium.com/@tumada/do-not-find-your-passion-a7b2f290b5a">「「情熱を探そう」というアドバイスはもうやめよう」という記事</a>が話題になっていた。
この記事では、「情熱を見つける」のではなく、「情熱を育む」べきだといっている。
これはつまり、いきなり自己実現を目的にしようとするのではなく、別のモチベーションからでも徐々に自己実現へとシフトする(=成長する)ことを目指そうということだ。
結局のところ、成長したいと思えるというのも、ひとつの社会人スキルなのである。</p>Takahiro Miyoshi先日、上司(の上司)から突然「みよしさんは成長したいですか?」とたずねられた。 上司の手前、「とくに成長したいとか思ってないっす」という答えは印象が悪いし、実際、成長したくないというわけではない。 とはいえ、「成長したいです!」と全面的に肯定するような感じでもない。 そんなことを考えた挙げ句「成長したい……んじゃない……ですかね……?」と曖昧な返事をした。 「じゃあ、なんで成長したいんですか?」と、上司が続ける。 いま「成長したい」と答えたのは、上司に対して小さな見栄を張ったからで、ひいては会社での評価のためである。 しかし、「会社の評価項目にあるからです」という答えは、「主体性」という評価項目に反するので言うべきではない。 それ以前に、会社の評価のために成長したいというのはちょっと違う。 ぼくは「うーん、難しいですね……」といってお茶を濁した。 その後の話からすると、上司自身も「成長」という言葉になにか違和感を持っていたらしい。 ぼくもなぜうまく答えられなかったのか、この上司の質問について少し考えてみたい。口ロロ「恋はリズムに乗って」をアコースティックアレンジした2018-01-09T00:00:00+00:002018-01-09T00:00:00+00:00https://blog.sankichi.net/music/%E6%81%8B%E3%81%AF%E3%83%AA%E3%82%BA%E3%83%A0%E3%81%AB%E4%B9%97%E3%81%A3%E3%81%A6<p>三連休を使って <a href="https://ja.wikipedia.org/wiki/%E2%96%A1%E2%96%A1%E2%96%A1">口ロロ</a> の「恋はリズムに乗って」をアコースティックアレンジしてみた。</p>
<!-- raw HTML omitted -->
<h2 id="section">きっかけ</h2>
<p>作業用 BGM として Google Play Music の "I'm feeling lucky" でシャッフルした時に流れてきて曲を知った。
それまでの曲は全然耳に入ってこなかったのに,この曲のイントロが聞こえた途端,耳に意識が集中して作業が止まってしまったのを覚えている。
いつかコピーしたいと思っていて,先日ベースをしている会社のバンドでライブをやることになった時に提案したのだが,そのライブで演奏する曲には採用されなかった。
ただ,提案した時点でこの曲を演奏する気になっていたので,宅録することにした。</p>
<h2 id="section-1">アレンジ</h2>
<p>構成がシンプルなだけに,単純にコピーしてもダメだなとは思っていた。
試しにコード進行を耳コピしてみると <a href="https://ja.wikipedia.org/wiki/%E5%B0%8F%E5%B1%B1%E7%94%B0%E5%9C%AD%E5%90%BE">Cornelius</a> の「太陽ば僕の敵 - THE SUN IS MY ENEMY」とほとんど同じだったので,この曲のアコギのストロークパターンを真似ることにした。
また,久々に Logic Pro X を開くとカホンを叩く <a href="https://support.apple.com/kb/PH13070?locale=ja_JP&viewlocale=ja_JP">Drummer</a> が追加されていたので,これを使ってアコースティックアレンジすることに決めた。
そして,ギターのフレーズが弾きやすいようにキーを3つ下げた。</p>
<h2 id="section-2">レコーディング</h2>
<p>スチール弦のアコギとボーカルはスタジオノア恵比寿店で録音した。
リードギターには自前の S.Yairi YD-75 を使ったが,バッキングにはスタジオでレンタルした Martin D-16GT を使った。
また,ギターの録音には <a href="https://www.amazon.co.jp/dp/B001JERO46?tag=sankichi92-22">Audio-Technica AT2035</a> を使ったが,ボーカルの録音はスタジオの <a href="https://www.amazon.co.jp/dp/B003HGLPC6?tag=sankichi92-22">Neumann TLM102</a> を使った。
ソロを弾いているガットギターは Godin ACS Slim SA をライン録音したもので,オーディオインターフェースとの間に <a href="https://www.amazon.co.jp/dp/B002C5BV36?tag=sankichi92-22">ART Tube MP Studio V3</a> を挟んでいる。
オーディオインターフェースは <a href="https://www.amazon.co.jp/dp/B009USR2Y0?tag=sankichi92-22">Focusrite Scarlett 2i4</a> を用いた。
これはそろそろ買い替えたい。</p>
<h2 id="section-3">ミキシング</h2>
<p>正直なところ,ほとんど定位と音圧の調整しかしていない。
Logic のチャンネルストリップのプリセットから「Natural」と名前がつくものを選んで,ほんの少し EQ とリバーブをいじった程度。
ガットギターはがっつりハイを上げてうっすらとコーラスをかけている。
パーカッションとギターの音はそれなりに気に入っているが,ボーカルはスッキリしないなあと思っている。
EQ やコンプについてはいまだによくわかっていないので,誰か教えてほしい。</p>
<h2 id="section-4">マスタリング</h2>
<p><a href="https://www.landr.com/ja">LANDR</a> を使った。
WAV 16 bit 44.1 kHz を999円で購入した。
ミキシング以上にマスタリングって何をすればいいのか分からないので,それを千円で外注できると思えば安いものだと思う。
まあ,ソフトウェアが単純に波形を変換してるだけと考えると1回999円という値段はボロい商売だという気もする。</p>
<h2 id="section-5">感想</h2>
<p>コードのコピーがうまくいっている気がしない。
ちゃんと耳コピしたというよりは,ベースラインとキーから類推したという方が正確かもしれない。
たまに歌いにくいところがあったので,その辺りは音を間違えているかテンションが足りていないかしていると思う。</p>
<p>コピーしていて気づいたのだけれど,メロディラインが1オクターブ範囲のペンタトニックスケールだけで完結していてちょっと感動した。
それを受けて最後のソロは基本的にペンタだけで弾いている。
ただ,ガットギターのフレーズをアコギとボーカルの録音後に考え始めたのは失敗だった。</p>
<p>ボーカルは何度聞いても下手くそだなあと思う。
作り始めた当初は初音ミクを使おうかと思っていたが,初音ミクの音域だと映えないキーなのと,予約したスタジオの時間が余ったのとで歌うことにした。</p>
<p>最後に,原曲の方が私がアレンジしたものなんかより何倍もカッコいいのでそちらを聴いてほしい。</p>
<!-- raw HTML omitted -->Takahiro Miyoshi三連休を使って 口ロロ の「恋はリズムに乗って」をアコースティックアレンジしてみた。