Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

coincheckから580億円相当のNEMが盗まれた騒動と会見について僕の考え、僕の被害状況などのまとめ

考え 製品開発

f:id:hirokiky:20180127104722p:plain

id:hirokiky です。 正直、今回のような時事ネタはブログやTwitterではあまり書かないようにしているんですが、 さすがに今回は書いておこうと思います。

なぜか。

理由は僕自身がcoincheck （コインチェック）を2016年ごろから使ってきたことが大きいです。 また、同じようにサービス（オンライン教育サービス PyQ）を作る人として思うところがあったのでブログにまとめました。 雑文なのはお許しください。

coincheckはUIも使いやすく、取扱い仮想通貨も多い+対応が速いという点が好きで使っていました。 成長も早く、たしかにセキュリティ面や法務面での怪しさはありましたが、成長に期待しつつ僕自身でも安全面に対応して使おうと決めていました。

が、そんな中 coincheck からNEMという仮想通貨が580億円相当盗まれたとの情報がありました。 coincheckでは取引の停止、全通貨の出金停止（日本円を含む）となりました。

その後に2018-01-26 11時30分 PMからの記者会見がありました。 このブログは、その記者会見の内容やポイントに触れつつ、仮想通貨や僕の被害状況、サービス提供者としての考えをまとめたものです。

僕はニコ生で、coincheckの記者会見を見ていました 仮想通貨取引所「コインチェック」売買停止トラブル 記者会見 生中継 - 2018/01/26 23:30開始 - ニコニコ生放送。

（YouTubeであるのはこことかでしょうか YouTube）

追記: 1月28日

coincheckからNEMの保有者に現金での補償があるそうです。

http://corporate.coincheck.com/2018/01/28/30.html

NEM持っていた方は本当に良かったですね。。 訴訟などしても時間はお互いに返ってこないですし、coincheckの早急な対応は素晴らしいと思います。

簡単なキーワード解説

あくまで簡単な説明と振り返りなので、大きな嘘でない限りはご容赦ください

  • NEM：仮想通貨の一つです
  • コールドウォレット：仮想通貨を、オンラインではない場所に退避させるもの
    • 取引所であれば、顧客の資産すべてを常にオンラインにおいておく必要はありません
    • 取引量などを見つつ、何割かをコールドウォレットに逃がす必要があります
  • マルチシグ：仮想通貨の「お財布」の「鍵」を複数にして安全性を高めること

仮想通貨における「お財布」にはアドレスと鍵があります。アドレスは口座番号で、「鍵」（秘密鍵）は送金に必要なものです。

仮想通貨は世界中の皆が帳簿を共有して「誰々さんがいくら持ってる」と管理するものなので、財布と言っても、言ってしまえば単なる口座番号（と鍵）でしかありません。「みんながどこ（口座番号、アドレス）にいくら入ってる」と保証してくれているだけになります（僕たちの日本円や株式、債権も物理でなく帳簿上にあるだけのものがほとんどでしょう。誰がどう保証しているかの違いでしかありません）。 紙幣や硬貨っぽくなっている仮想通貨もありますが、単にアドレスと秘密鍵が入った財布です。

コールドウォレットというものは、その秘密鍵をオンラインから切り離された場所に保管する（すぐには送金できないようにする）ことです。 ハードウェアウォレット（専用のデバイス）を使ったり、紙に書いたりするのがこれです（スマホアプリは十分ホットウォレットです）。

僕の中での会見のポイント

  • coincheckのNEMが580億円相当盗まれた。本当にNEMが盗まれた
  • coincheckはNEMを全額ホットウォレットに入れていた。コールドウォレットに移動はしていなかった
  • マルチシグ対応はしていなかった

コールドウォレットについてはサイト上でも「サービスの安全性」の項目で対応していると明記されていますので、 僕としては一番衝撃だった部分はこの点でした。以下、サイトからの引用。

コールドウォレットによるビットコインの管理

当時、Mt.GOX（マウントゴックス）のコールドウォレットの管理は完全なオフライン状態で行われていなかったため、安全性が確保されていませんでした。 coincheckでは、お客様からの預り金の内、流動しない分に関しては安全に保管するために、秘密鍵をインターネットから完全に物理的に隔離された状態で保管しています。

コールドウォレットの冗長化と暗号化

コールドウォレットは冗長化され複数の場所に分散されて保管されているため、万が一、災害等で一部失われたとしても問題ありません。 また、AES-256 の規格を持ってコールドウォレットは暗号化されており、第三者が盗むことはできません。 AESとは、Advanced Encryption Standard の略称で米国商務省標準技術局(NIST)によって制定された、米国政府の新世代標準暗号化方式です。AESの後に付与されている数字は暗号アルゴリズム強度指数を表しており、256が最大のものとなっています。

coincheck.com

コールドウォレットについては明記されているのに対応されていなかったというのは一番マズイと思います。 たしかに「コールドウォレットによる ビットコインの管理 」とありますが、これはかなり恣意的で、良くないと思います。 これは 「投資家の自己責任」では済まない 内容ではないかと思っています 「いや、コールドウォレット対応はビットコインの管理であってNEMではないよ」と言えるのは僕も理解しています 。がそれってどうなの、と。

マルチシグ対応していないというのは、会見の前からNEM公式などから指摘があったので知っているところではありました。 coincheckの公式や会見よりも、TwitterのNEM公式や仮想通貨のトランザクションを見ている人たち、coincheck内のチャットのほうが情報が速いというのが面白いところでした。

マルチシグ対応していないのはcoincheckの問題であり、NEMという仮想通貨が脆弱というわけではありません 。

僕の会見の感想

  • 本当に盗まれたのか。。嘘だと言ってよバーニィ
  • coincheckがコールドウォレット対応していなかったは良くない
    • 嘘の情報（すべての仮想通貨でコールドウォレット対応してるように見えるのにしてなかった）をサイトに書いていたのはかなり良くない
  • 東洋経済、日経など経済誌と朝日の記者さんは分かった上でちゃんと質問しててすごい
    • 逆に、知ってる人じゃないと仮想通貨への理解はかなり低いと分かった
  • CMを大きくうつと人の目に晒される
    • 認知度は上がるが、問題が起こった場合の心象に大きく影響する
    • 「CMより優先すべきことがあったのでは」という記者の質問がそれを語っていた
  • 会見中「株主と検討が必要」という言葉を繰り返す => 会見の2人が株の過半数を持っている、はコントだなと思った
  • 同じサービスを提供する身として気をつけないといけない

マルチシグ対応していないこともそうですが、コールドウォレットに関してはサイトに掲載している内容なのでマズイ（少なくとも誤解を発生させるものだったかどうかの争点にはなる）と思います （ビットコインというワードを使ったときに仮想通貨全般を指す言葉のように感じられる点、NEMなど一部の仮想通貨ではコールドウォレットに移動していないと書いていなかった点、などは争点になるかなと思います）。

Twitterで見た声に対する個人的な感想

  • 分かる: 「coincheckも被害者である」
  • 分かる: 「一部記者が無知だ。攻撃的すぎる」
    • 分かったうえでちゃんと質問してる人もいた
    • 過激に記者側を叩くのはそれはそれでおかしい
  • 分かる: 「会見でcoincheck代表、取締役、顧問弁護士が「検討」「確認」しか言ってなくて何の話にもなってない」
  • 分かる: 「coincheck頑張って欲しい」
    • 和田社長も、まぁ頑張って欲しい
    • 個人的な感想としてはTwitterはもう少し抑えたほうが良いとは思う
  • 分かる: 「今後の仮想通貨が心配。仮想通貨は悪くない」
  • 分かる: 「サービス提供責任者として自分たちも気をつけよう」
  • うーーん: 「セキュリティはキリもないし仕方ない面はある」
    • とはいえマルチシグ対応、コールドウォレット対応はするべきだったのでは。。
    • とはいえサイト上で全仮想通貨でコールドウォレット対応してるように見せるのは良くないだろう

僕の被害状況

僕はNEMを買っていなかったので、直接的な、分かってる範囲での被害はありません。ご安心ください。 ただ、Rippleだけはcoincheck上に "いくらか" ありました。Rippleは盗られていないとのことですが詳細は不明です（かなり不安です）。 これからどうなるかも不明です。

Rippleについても現在はcoincheckから出金できない状況です。 返ってきたら嬉しいな、くらいの諦めの気持ちになりつつあります。お祭りへの（ちょっとお高い）参加費だと思っています。

僕は2016年ごろからBitcoin、Ripple、DAO、ETHを取引していたのですが、基本的には 取引所に置かない、 ハードウェアウォレットを使う ようにしていて良かったなと思います（ハードウェアウォレットはコールドウォレットの一つです。物理のオンラインでないデバイスに「鍵」をしまっておいて安全にするものです）。 逐次、仮想通貨の転送が必要なので、かなり面倒ですけどね。 この物理のデバイスが無いとこの財布から送金できないのでさらに面倒です。

これが僕のハードウェアウォレット、Trezorです。Bitcoinには使えます。

f:id:hirokiky:20180127104722p:plain

サービスの提供者として感じたこと

僕も PyQ というサービスの企画、開発、保守からやっている身なので同じ気持ちとして会見を見ていました。

「問題はあるけど、まぁいいかな」と頭をよぎる瞬間は人間あると思います。例えば「自宅についてももう少し防犯したほうがいいかな？」や「防災グッズ買っといたほうがいいかな？」と思うことはありますよね。

「ちゃんとやらないとダメだろう」という内なる声に聞かないふりをしてしまったり、日常の庶務や、成長や開発を優先したくなることがあります。

でも、そこは踏みとどまってお客様のことを考えないといけないんだなと改めて強く思いました。 また、万丈な体制でないのに過剰な広告、宣伝、成長は自分をダメにしてしまうんだなとも思いました。

一般的なWebサービス提供者であれば個人情報の流出などのリスクは常にあります。 もちろん、仮想通貨ほどの直接的な金銭の被害は起こらないですが、それでもお客様の情報などを預かる身と思い直さなくてはいけないなとは思います。 オープンなサービスであれ、社内システムであれ何であれ関係なくそのリスクはあります。

今一度、サービス提供者が嘘をついてはいけない。誤解を与えるような表現をしてはいけないと肝に命じました。 また、セキュリティ上の課題を後回しに考えてはいけないものだと思い直しました。他のタスクを差し置いても、セキュリティ上の問題があった場合に被害の大きい点から対応する。成長を抑えても対応すべきことはあると思いました。

というわけで皆さん、ご安全に。

S3で302リダイレクトをする（301リダイレクトでなく）

AWS

AWSのS3でリダイレクトの設定ができます。

例えば https://hirokiky.org/ 以下へのアクセスをすべて https://blog.hirokiky.org/ にリダイレクトするなどです。

簡単な設定（301リダイレクト）

S3の親切な設定を使うと簡単に設定できるのですが、 301リダイレクトになります 。

バケットの Properties => Static website hosting => Redirect requests で簡単に設定できます（以下の画像のように）。

f:id:hirokiky:20180123173128p:plain

302リダイレクトする設定

代わりに Use this bucket to host a website という静的サイト配信用の設定から 302 リダイレクトを設定できます。

この RedirectionRules を設定することで 302 リダイレクトができます。 以下の設定は https://blog.hirokiky.org/ に 302 リダイレクトする設定になります。

f:id:hirokiky:20180123173159p:plain

XMLの内容は以下です。

<RoutingRules>
    <RoutingRule>
        <Redirect> 
            <HostName>blog.hirokiky.org</HostName>
            <ReplaceKeyWith></ReplaceKeyWith>
            <Protocol>https</Protocol>
            <HttpRedirectCode>302</HttpRedirectCode>
        </Redirect>
    </RoutingRule>
</RoutingRules>

index document の設定はテキトウに index.html などで良いです。

他にもオプションを指定できるようなので、以下から参照してください。

docs.aws.amazon.com

簡単な設定はこのオプションの設定をラップしているんですかね。 ともあれ色々設定もできて便利です。

製品を使ったときに余地を感じられるかどうか

考え

まえがき

これは僕の雑記なので、あまりマジメに言及することはオススメしません。 どんな人が読んでも、読む人にとって不快感のないよう配慮しておりますが、内容の正確性や面白さ、情報としての価値は保証しておりません。

本文

製品を使ったときに、自分の人生がこう変わるかもしれないと感じれるものを作りたいと思っています。 人は根源的に、自分の生活や人生を変えたいと思っているものだと僕は考えています。 それは劇的に自分の何かを変えたいと万人が思っているというわけではなくて、日々自分の生活を豊かにしたり、 自分にとって「違うもの」に触れたり、避けたりして自分の人生を変えたり、守ったりしたいと思ってるという意味です。

僕は、人が製品に触れたときに、その可能性を感じれるものを作りたいと思っています。 それには「余地」が必要だと思っています。使い手が自分自身で解釈して、自分自身の人生に適応していく余地が必要だと考えています。

そのために、僕は「シンプル」であるべきだと考えています。「シンプル」という定義も曖昧なので難しいですが、多くの製品は僕の感じるシンプルとは違うように思えます。 シンプルである、ミニマルであると言いつつ、使う人にとっての可能性の余地がないものが多くあります。 また、余地は存分に作りつつも、使い手が自分自身の内面にどう適応していけば良いかがボヤけた可能性を感じられないものも多くあります。 僕は、これらはシンプルでないと思います。シンプルなものは、簡素であり、削ぎ落とされており、機能に注力しており、かつ可能性を感じれるものだと思います。

例えばWebサービスなどでよく「Simple and minimal User Interface」などの踊り文句をよく見ます。 確かにその製品はよく作られていて、チュートリアルなども充実していたりしますが、たいていの場合「余地」を感じません。 そこで言われる「シンプル」というのは、単に機能的な面で分かりやすいと言うだけで、言ってしまえば簡素なヘルメットであったり、トースターのような印象を受けます。 その製品を通して、新しい可能性や創造の余地、面白み、使うことを通して感じる「何か」が無いような印象を受けます。

そうなってしまう理由は、作り手の中で世界が完結しているからだと思います。その作り手の考える世界に準じること、準じさせることが製品の最大の目的になっているからです。 作り手にのみ主体があり、使い手は単なる使い手でしかないような製品です。 それは僕は、シンプルでないと思いますし、製品として僕の作りたいものではないなと思います。

「機能美」といってもその機能の先に「何か」を想像できるでしょうか。「シンプル」といって使い手の自由を奪うものではないでしょうか。作り手の世界を強要するものになっていないでしょうか。 まして、ユーザーの工夫や創造性を「そぐわないもの」として排除してはいけないと思います。作り手は場や空間、可能性を作るものであって、ユーザーの思想を脅かしてはいけないと思います。 新しい世界を作るのは作り手ではなく、それを使った使い手であるべきです （もちろんツールとして安全であるべきものや、規格に準ずるべきもの、業務的に正しく使わせることが目的のものは作り手の意図に従わせることが正しいと思います）。

僕が作りたい製品は、ミニマルで小さくて使い方がわかりやすいのはもちろん、使う人が自由に模索できる余地があるものを作りたいと思っています。 ただ挑戦的で尖ったものを作りたいという意味でなく、その人の中で製品を解釈できて、今までの（使い手の）常識を見返すキッカケになって、その人の人生にその人の工夫で取り込まれていくような製品です （もちろん美しい体験を保証したいので、導線や、ランディングページの分かりやすさは大切だと思っています）。

例えばモレスキンのノートはとても簡素でシンプルですが、それを使ってどうノートを取るか、人生を形作るかは使う人に委ねられています。 メモ帳のように使っても良いですし、バレットジャーナルのように使っても良いですし、ユビキタスキャプチャーのように使っても良いです。 その余地があるからこそモレスキンのノートはシンプルで簡素でありながら美しいですし、使い手に愛を与えるものだと思います。 それは使い手が自分で発掘した使い方そのものに愛を寄せているのだと思います。 モレスキンがすごいのは、シンプルなノートに「ピカソ」や「ゴッホ」も使っていたという物語を載せることで、その愛と可能性を加速させることにあると思います。 さらにすごいのは、ピカソやゴッホはモレスキン社のノートを使っていたわけではないという点ですね。

僕はPyQにおいては使い手が制限されないように最大限配慮して作りました。 PyQはWebの教育用プラットフォームですが、実務と同じ環境を動かしながら自学自習できることに力を使っています。 作り手としては教育用の制限された環境を提供するのが一番簡単です。利用者に、教育者が指示する方法でしか動けないようにするのが一番簡単です。 ですがそれでは意味が無いと考えています。PyQでは最大限シンプルに、本物の環境を提供しています。 さながら、机に向かう義務教育やテストでの評価を放棄して、文学や芸術、語学の実地を学生に体験させるようなものです。 これはセキュリティやシステムの設計、料金体系などを考えると本当にチャレンジングなことですが、僕も考えるシンプルさを貫けたかなと思っています。 今後、コンテンツも併せてよりユーザーさん自身が学ぶ場、工夫できる場、人生に可能性を感じれる場にしたいと思っています。

僕は、使い手の想像できる余地、新しい人生が想像できるワクワク、創意工夫できる自由がある製品を作りたいと思っています。 そういうものこそ、本当に人に愛され、長く、広く使われる製品なんじゃないかなと考えています。 新しい常識を、使う人自身が生み出して、その人自身の世界を変えていけるような製品を作りたいと思っています。

日本語アンチパターンその1「日本語ぶった切りプログラム」

伝わる日本語表現

ドキュメントやサポート、チャットでの説明で日本語を書く機会は多いと思います。 「プログラムについて日本語で伝える」ノウハウは、単に日本語の美しさだけではない部分もあるので難しい点です。

今日はその1つ、「日本語ぶった切りプログラム」というアンチパターンを見つけたので共有したいと思います。 アンチパターンとして名付けて、伝えやすく・覚えやすくしようという目論見です（今後の僕自身のためにも）。

アンチパターン:日本語ぶった切りプログラム

このアンチパターンは、日本語の文の途中にプログラムが入ってしまうアンチパターンです。 とくに「以下のように、」や「このような、」のあとにプログラムの引用を文中に書いてしまって、日本語が途中で切れてしまうものです。

以下がアンチパターンの例です

time_it 関数では以下のように、

def time_it():
    …
    …

関数の冒頭で処理を実行しています。

「以下のように、」の後にプログラムが貼られることで日本語が途中で切れてしまっています。 書き手の意図としては「この関数では以下のように〜『ここでプログラムを指差す』」というイメージはわかりますが、 読み手としてみるとプログラムのどこに集中して読めば良いのかが分かりにくくなります。

問題

以下のような問題が考えられます。

  • プログラムを読ませられる意図が事前に分からないので、どの点に注目して読めば良いのか分かりにくい
  • プログラムを読んでいる間にも、プログラム前に説明された日本語を記憶しておく必要があり疲れる

改善方法

プログラムを貼って説明したいこと・伝えたいことを、まず1文で表現してからコードを貼りましょう。

time_it 関数では以下のように、関数の冒頭で 〜 という処理を実行しています。

def time_it():
    …
    …

time_it 関数の冒頭で 〜 することによって、〜の意味があるためです。

* 〜するので、〜しやすい
* 〜するので、〜がわかりやすい

細かい説明や意図の説明は、プログラムを貼った後にすると良いと思います。 逆にプログラムの前に説明しすぎると、それはそれで前の文を覚えきれなくなってしまうので避けましょう。

アンチパターン名 日本語ぶった切りプログラム でした。

楽するための、日常動作のバッチ処理化

考え

どうも、こんにちは id:hirokiky です。

今日は日常生活する中で僕がやってみていることを話します。

完全に僕理論なので、「最近そんなことやってるんだ」くらいに楽に聞いてください。

習慣になると色々と楽

id:haruo860 さんと話していたときに、「習慣になってしまえば強い」という話題になりました。 何か動作をするときや決めるときに、習慣になっていれば迷いがなくて「楽」になる。 大切なことに集中できるので強いという話でした（だったと思いますが、あってますかね、はるおさん）。

そのとおりだなぁと僕も思っていて、例えば朝起きて出社することは大変です。 これは誰しもたぶんかなり辛いことだと思います。

「今日は遅刻しちゃおうかなぁ」「何着ようかなぁ」「顔は洗わなくていいかなぁ」と毎朝だらだらしてしまう。 でもそこが習慣になっていれば余計な考えなく済ませられます。 余計なエネルギーを使わずに超強大な定期タスク（朝出社するとか）をこなせるということです。

自分の中でココ最近試していた

僕なりにココ最近気をつけて実践していたことの話をします。 これは何かの本に書いてたことではなくて、単にここ数週間自分の中で試していることです。

「何かに影響されたんじゃないの？」ということは無いので安心してほしいのと、 実践するときも人には気づかれないように試せるので、「アレに影響されたんでしょ」と言われる心配もありません。

頭の中だけでやります

やりかたは簡単で、日常やる動作を頭の中で「まとめておく」ことです。 対象になるのは以下

  • 毎日やる動作
  • だらだらしてしまう動作

オススメは「朝起きた瞬間〜着替え終わるまで」です。

やることは3つだけです:

  • 頭の中で動作順の流れを決める
  • 全く同じように自動でやる
  • その動作中は他のことをしない

紙に順序を書き出したりはしません。 ポイントなのが 何をやるかでなく、どうやるか いかに 無思考で、自動で、意思決定なしに できるかが重要。

例えばここ数週間で確立した僕の「朝起きた瞬間からの動作」

  • 朝起きる
  • 顔を洗う
  • 歯を磨く
  • トイレに行く
  • 着替える

文字に列挙すると何ともないですが、決めておかないと日常どうしても「もうちょっと寝ようかなぁ」とか思ったりSNSをチラチラ見たりしてしまいます。 この「着替える」まではそういったことをせずに、機械的にやります。

僕の中では 日常動作のバッチ処理化 と呼んでいます。

各処理を意思決定なしにできることが大事

単一の処理、例えば「着替える」をとっても、自動でできるようにしておく必要があります（MUST）。

クローゼットの順番を整えておいて、何でもすぐ着れることだったり、服は着合わせしやすい服ばかり用意しておくとかです。 （例えば僕は着ない服をクローゼットから除外しました）。

バッチの設計は最小で

バッチ処理は短く終わるほうが良いですよね。

それと同じように日常動作のバッチ処理も短くしておきます。 例えば朝であればそれ以外の動作、ゴミ出ししたり、水槽の様子を見たりもありますが、 それはこのバッチが終わった後にやります。

ゴミ出しとかは曜日や時間という外部要因が関係して、かつ判断や分岐が必要になるのでバッチ処理からは除外したほうが良いです。 SNSやメールを見るのも、バッチ処理後にやったほうが良いです。

  • 日時、曜日
  • 判断が必要な動作、判断を迫られかねない動作
  • 他人、ペット
  • SNS、メール、Slack

こういった要因はバッチ処理の複雑化につながります。 とりあえず朝目が覚める〜朝出社するまでの最小構成（かつ気が重い場所）を、バッチを走らせるだけで完了するようにしておきます。 また外部要因にすぐ応えられるようにも、バッチは最小構成の設計にしましょう。

やろう！としないで良い

普段、自分がすでにやっている流れで、バッチとして意識するようにするだけで良いです。

色々試す中で、「化粧水をはたく」など「必須ではないがやっておきたい動作」を増やすと途端にやる気がなくなりました （いつもの朝起きられないモードに突入する）。除外をオススメします。

バッチは最小構成で、普段やっていることをまとめるだけで良いです。 その代わり、確実に自動でできるようにします。

バッチ化はどうでも良い意思決定の自動化

僕はもうずっと5年10年くらい朝食にカロリーメイトを食べてるんですが、これは「朝食が決まってないときはカロリーメイトとコーラ」と決めているからです。

とにかくどうでも良いことは事前に決まっていると色々楽だなぁと最近気づいて、ここ1ヶ月くらい自分で実験して日常動作のバッチ化をやってみています。

気持ち的な面が大きいですが、朝起きてからの流れが気楽になります。 ぜひ、ちょっと意識するだけで済むのでバッチ処理化をしてみてください。

まだ僕の勝手な理論でしかないので、実践してみた報告やコメントがアレば直接伝えるか、ブログに書いてみてください。

おまけで、意思決定についての考え

実家を離れたとき、何でも自分で決められることが本当に嬉しかったことを覚えています。 でもそれは逆に、自分で何でも決めないといけないということですよね。 僕の場合はそれは苦ではなかったんですが、ココ最近は色々と大事な意思決定が増えてきて、細かい日常の迷いみたいなのを無くしたいと思っていました。

例えば製品づくりやイベント開催などは意思決定が大事です。 やることとやらないこと、それを決めて線を引くこと、集中することが良い製品を作るのに大切です。 PyQ を作っていると、とくにそれを感じます（まぁ小さいチームだからというのもありますが）。

最近大事なことを考える時間と必要性が指数的に増えてきて、正直いうとココ数年は大変です。 なので日常の細かい迷いくらいは無くして、その瞬間くらいは脳みそを休ませてあげたいんですね。

何かを作るときは「人との調整」でなく「意思決定」することが大事だと思います。 とても大事なので、大変だからといってその機会を捨てる気はないです。 それ以外の余計な迷いはドンドン捨てていきたい、そんな今日この頃の、セキララトークでした。

他のオススメ記事

blog.hirokiky.org

Ubuntu17.10にしたら日本語が打てなくなった問題を何とか解決した話

Ubuntu 環境設定

f:id:hirokiky:20171021190512j:plain

雑メモです。

Ubuntu16.04からUbuntu17.10にアップグレードしたら日本語が打てなくなっちゃいました （まぁよくある話です）。

平たくいうと fcitx とIMの環境変数周りの設定がうまくいってなかったということで、色々場当たり的に直してたら動いて良かったという話です。

あんまりアテにならない情報です 間違ってたら教えてください。

まず「入力メソッド」 im-config で fcitx を設定するも状況改善せず。

im-config

GUIから設定して再起動するも変わりませんでした （単に im-config が設定している先のファイルを読んでないとか、 im-config が古いとかもありえます）。

とりあえず fcitx-diagnose で状態を確認。

fcitx-diagnose

以下の環境変数周りでエラーがでているようでした。

  • GTK_IM_MODULE
  • QT_IM_MODULE
  • XMODIFIERS

（間、 ibus をアンインストールしたりも試していました）

XMODIFIERSやQT_IM_MODULE環境変数の設定先

Ubuntu 17.10では /etc/environment に環境変数を設定しました。

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

Ubuntu17.10からWaylandで動いているそうで、 ~/.xprofile を読めないそう。 なので /etc/environment で設定しました（これって何かマズイとかありますかね。。？）。

とりあえず .xprofile とか .xinitrc とか .xinputrc とかに設定してみていましたがダメでした。

ArchWikiを参考に設定しました。

非デスクトップ環境

以下の行をデスクトップのスタートアップスクリプトファイル (GDM, LightDM, SDDM を使っている場合は .xprofile もしくは > .profile、startx や Slim を使っている場合は .xinitrc、Wayland を使っている場合は /etc/environment) に追加してくださ> い。この設定で、fcitx は gtk/qt のインプットメソッドモジュールを使うようになり xim プログラムをサポートします (必要なインプットメソッドモジュールがすでにインストールされているか確認してください)

まじっすかーということで、 /etc/environment に設定しました。

GNOME/Wayland 上での Fcitx の利用

Wayland は ~/.xprofile に保管された環境変数を読み込むことができないため、Wayland 上では Fcitx は正常に動作しません。Fcitx を利用するにはディスプレイマネージャから Xorg セッションを起動してください。

https://wiki.archlinux.jp/index.php/Fcitx

かなり場当たり的にですが、とりあえず解決して今も日本語を打てているという状態です。

僕のツイート

あとで見返して笑えそうなので残しておきます。

まとめ

ArchWiki日本語情報ほんとうにありがとうございます！ IMまわりとかは、英語での情報があんまり見つけられなかったので助かりました。

逆に今、消費的な趣味を大切にしてみる

考え

「趣味」という言葉に対してのハードルが日に日に強くなっていると感じませんか。

「このレベルでは趣味じゃないから」、「終わったら内容をまとめておかないと」、「まだここがコンプできてないな」など、 単に「趣味」と言ったときに付随する感情やレベル感、義務が大きくなっていると近ごろ自分の中に感じます。

もちろん頑張れることや何かを生み出すこと、達成することは素晴らしいことです。 ですけど最近は人生の99％がそういった頑張りの必要な時間になっている気がしているので、逆に、完全に消費的な趣味を考えてみました。

対象の人、対象でない人

最終的な目標や、生産的なこと、やりたいことはすでに持っている人と共有する考え方です。 「やってること多すぎてるかな。。。」「趣味へのハードルが高いなぁ」と思う・思ったことがある人です。

僕がまとめる内容はより生産的で健やかな人生を送るために書いています。 単に「何もしない優しい世界になろうよ」というつもりはありません。より生産的かつ心地良く生活や仕事をしたいという考えがまずあります。

静かな趣味

「消費的」というと語弊があるので、これからは「静かな趣味」と呼びます。 より生産的になれるように、あえて静かな趣味を考えてみます。

静かな趣味は完全に 静か でなくてはいけません。 趣味中にも頭の中で「ここまでやりたい」、「こうでなくては〜いけない」という考えは捨てるようにします。

静かな趣味では、以下のことを しません

  • No Goal: 目的を持たない
  • No Sharing: 共有しない（まとめない、アウトプットしない）
  • No Review: 批評しない（分析しない、コメントしない
  • No Agreement: 合意しない（一人でできる。社会に反しない）
  • No Planing: 計画をしない
  • No Choosing: 決断をしない（必要無い、少ない）

以下のことを します

  • 自分が気楽に楽しむ

自分が癒やされる、気楽になる、焦燥感がなくなるためにやります。

例えば私なりに、自分の好きなことで静かな趣味を考えてみました:

  • 音楽をただ聴く
    • とくにお気に入りのLinkinParkやGreenDay、BobDylanをただただ聴く
    • not「僕はロックが好きだから一通りのアーティストは聴いておこう」
    • not「ついでに英語の勉強にもなるかな、意味を調べよう」
  • 料理をする
    • 新しい料理でなく流れでできる煮物や炒め物をただ作って食べる
    • not「最高のチャーシューを作ってみたい」
    • not「米はミネラルウォーターで美味しさが変わる、どれが良いだろう」
  • 風呂に入る
    • 入浴剤を適当に入れてただ入る
    • 風呂あがりにホットアイマスクでもする
    • not「あそこの銭湯にも行ってみたかった。行ってみよう」
    • not「日本の名湯には一通り入っていないとね」
  • バイクでいつもの道を走る
    • 知ってる道をただ無意味に走る
    • not「友人とツーリングの計画をたてよう」
    • not「ヒザが擦れるようになりたい」
  • 知ってるゲームをする
    • 脳みそを動かさず、どこまでクリアしたいかも考えない
    • not「この新作をプレイして感想を書こう。ぜひプレイしておきたい」
    • not「スコアは3000以上いかないと、やったとは言えないだろう」
  • ペットをただ眺める
    • not「一通り飼育設備は揃えておきたい」

こうやってみると、自分が 趣味 としていることでも自分の中でのハードルが勝手に上がったりしていることに気づきます。 ささやかな瞬間にも頭の中の「頑張り」や「自己顕示」がでてくるので、それの無いようにします。

すでにある趣味でも「意識の高い」要素を抜いていくことで、気楽な趣味にできそうです。 僕はプログラミングが大好きですが、どうしても「目的」がついてくるので静かな趣味からは外しました。また、前提として前準備や注意点が多いツーリングなどもそもそも「静かな趣味」には向いてないようです。

「頑張り」を抜いて静かな趣味に変えるには、この辺りを意識してみるといいかもしれません:

  • 「コンプリート」をやめる
  • 「こういうものを作って便利にしたい」、「勝ちたい」、「今日はここまでいきたい」という目標をやめる
  • 「ちゃんと参加しないといけない」、「毎日続けよう」という義務感をやめる
  • 「こんなことやっています」、「新しいこの曲はここが最高なのでオススメです」などSNSへのシェアをやめる
  • 始めるまでの準備や調整がいることは一切やめる

この視点で考えるだけで気楽な趣味に変えられるんじゃないでしょうか。 せっかく見つけた自分の好きなことです。その好きなことに潰されないようにしたいものです。

まだ僕なりにも考えてみている段階ですので、間違っている点や他にも良い視点が今後でてくるかもしれません。 何かあれば、ぜひ教えてください。

心の疲れをとる技術という本にある「静のストレス解消法」

僕のお気に入りの本に「自衛隊メンタル教官が教える 心の疲れをとる技術」という本があります。 この本は、実際に自衛隊のコンバットストレス教官をしていた下園さんという方が、事故や災害、ショックな状況に対面する自衛官の心理的ケアに関わる中で培った方法論を紹介する本です。

「心の疲れをとる技術」でも「静」のストレス解消法を持つことが大切だと書かれています。

ポイントは、「動」と「静」のストレス解消法を持つことだ。特に「静」のストレス解消法を準備することを強調している。　エネルギーが低下している第２段階以降は、活発に活動する「動」のストレス解消法は、確かに快感も大きいかもしれないが、その活動のための疲労が大きく、結果的にムリが深まっていく。　例えば、疲れている人が、休日に趣味のサッカーをしたとしよう。その時は楽しいかもしれないが、次の日はもっと疲れている。　ドライブや海外旅行なども、かなりのエネルギーを使う。

「第2段階」というのはこの本で語られている心の疲れの3段階の2段階目ということです。

夜更かし系のストレス解消法も、第２段階以降はマイナスが大きくなる。アルコールが加われば、さらによくない（アルコールについては、後述）。　第２段階以降は、静のストレス解消法を選択するべきなのだ。　ヨガ、軽い散歩などは、疲労回復に効果があることが証明されている。　話をするという作業は、悩みの整理になるだけでなく、静のストレス解消法でもある。 （中略） 他にも、森林浴、庭いじり、俳句や短歌、囲碁や将棋などの頭脳ゲーム、読書、音楽（聞く、奏でる）、映画鑑賞、プラモデル作り、料理、日曜大工などの単純作業、何か作り出す作業などは、心に栄養を与える。　ただし、オンラインゲームやマージャンなどのギャンブルは、なかなか抜けにくいし、夜更かしになりがちだ。お金を使いすぎたりすると、後で自責感が大きくなるというマイナスも大きい。注意が必要だ。　このような、静のストレス解消法は、動のストレス解消法に比べて、瞬間的な快感が少ない。しかし、続けているうちにじわじわとその良さがわかってくる。　だからこそ、第２段階までの比較的元気な時に、「育てて」おかなければならないのだ。

あまり詳細に「静」のストレス解消法については書かれていませんが、イメージは静かな趣味かなと思います。 こちらの本も良い本ですので、「ケガした時の保険」的に読んでおくと良いと思います。

引用元: 「自衛隊メンタル教官が教える 心の疲れをとる技術 下園壮太」1章より

自衛隊メンタル教官が教える 心の疲れをとる技術

自衛隊メンタル教官が教える 心の疲れをとる技術

自分の趣味は何だっけ？どんな姿勢でやっていたっけ？

最近こそ「趣味」と言えるまでのハードルが高くなっている気がします。 SNSの普及で専門的なコミュニティに関わりやすくなったからでしょうか。より高い「趣味性」や「SNS映え」が大切になってきている気がします。 また「好き勝手なセリフや批評を控えて、正しい意見をやり取りすべきだよね」という良い流れも感じます。ですが逆説的に、好き勝手やれる・言える隙間が少なくなっているようにも思います。

今ある静かな趣味は何でしょうか。 単に好き勝手できて、誰にも言わない趣味。 少し気を抜いてできるものを考えてみるのはどうでしょう。

自分の好きにできる趣味なんだから、本当に何にもならなくても良いと思います。 そのリラックスできる時間で心身が回復して、頑張りたいときに頑張れるようにしておきたいです。