Make組ブログ

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

Ansibleのdocker.ubuntuロールでdaemon.jsonを設定する（storage-driverとstorage-optを指定する）

Docker Ansible

AnsibleからDockerを入れる必要があるとき、Docker用のロールを使うと簡単にDocker環境を作れます。

GitHub - angstwad/docker.ubuntu: Docker role for Ansible on Ubuntu 14.04+

この angstwad/docker.ubuntu ロールでは変数を設定するだけでDocker環境のカスタムもできます。 daemon.json の設定をAnsibleの変数から指定して、 storage-driver や log-driver の設定ができます。

daemon.jsonの指定方法

以下のように daemon_json という変数を指定しておけば設定できます。 YAML内に書いておけば、 /etc/docker/daemon.json に変換してくれるので便利です。

  roles:
    - angstwad/docker.ubuntu
  vars:
    # docker.ubuntu role用の変数
    # https://github.com/angstwad/docker.ubuntu/blob/4dfee851a7dc762a48dea4bcee59aea9eb2d4e12/defaults/main.yml#L34
    daemon_json:
      storage-driver: "devicemapper"
      storage-opts:
        - "dm...=..."

Dockerの daemon.json には以下の設定ができます。 dockerd | Docker Documentation

最近作ったものが誇らしいのと、いい加減な仕事をしないのはなぜ大事か感じた話

考え

僕は最近、なぜ良いものを作らないといけないのか、いい加減なものを作ってはいけないかを体験したのでその話をします。

まぁ、今日はたわいない雑文なのでリラックスしてほしいです。例によって色々な立場や考え方、思想には配慮して書いてるけど、至らぬところはあるかもしれない。

 

僕がここ最近ずっと作っているのはPyQ https://pyq.jp/  で、1、2年死ぬ気で作り続けてる。今日はそれに最近リリースした「質問と回答機能」ってものについて話そうと思う。

この機能はオンライン上でプログラミングを学んでるお客様の疑問を解決するすごいもので、ブラウザーでコードを書いて学習しているときに「質問する」というボタンを押すと学習サポートをしてる僕たちやチームのメンバーに質問ができるというもの。

とくにすごいのが、そのときに書いてるコードや実行結果、テストの結果も自動で収集して質問に含めてくれるということ。これがあるおかげで、質問者の人はよけいな手間なく質問ができるし、回答者も疑問にすぐに気づいて答えてあげられる。

 

質問回答機能についてはこっちのPyQブログもみてほしい

http://blog.pyq.jp/entry/news_question_180318

 

よくある話だけど、質問に「なぜか動きません」とだけ書いちゃって、プログラムも実行結果も添付し忘れちゃうという状況はあるよね？この問題は往々にして回答者を困らせるし、場所によっては怒られちゃう（メーリングリストとかでね）。でもこのPyQの質問と回答機能を使えばそんな心配は微塵もないんだよね（PyQが自動でコードと実行結果、エラーを共有してくれるから）。回答者も怒らずに済むし気持ちがよい。

さらに質問を書くときに「質問のコツ」、回答を書くときに「回答のコツ」を読めるから、質問や回答そのもののスキルまであがっちゃうすごいものなんだよね。エンジニア人生で一生大切にできるスキルだと思う。

 

この機能を作ろうと思いついたとき、これはヤバいものになるぞって予感がしてた。これは作らないと死ねないぞって。で、質問だけじゃなくてコードや実行結果も共有する方法とかアイディアを色々検討した。スクリーンショットを使う案を考えたこともあったけど、技術的にも難しかったし今思えばイマイチだった。

ランチを食べてるときにmonjudoh, naknurayさんに相談してて「PyQはすべてオンラインでコードも制御できるなら、すべてプログラム上でやればいいじゃん」って案をもらったのよね。うわーまじかよ、天才かよってメキシコ料理を食べながら思ったのを覚えてる。とにかくこの二人に相談して良かった。

とはいえ、どうUIを組み立てるかとか、既存のコードを内蔵から変えてどう作るかとかは本当に悩んだ（かなりの修正が必要だった）。そのとき、「まぁ、ここまでできたら良いし、こんなもんにしとこうかな」って何度も思ってしまった。実際それでも悪いものにはならなかったし、よくあるエンジニアQAフォーラム程度のものならできてたと思う。でもそうじゃなくて、かなりこだわってコードとか実行結果の共有とか、それの見やすいUIとかがちゃんと出来るようになった。

UIも何度も考え直したし、デザインも情報量が多いのをどう配置するかかなり悩んだ（質問、コード、実行結果やら公開範囲の設定やらで情報が多い）。プレビューをつけたり違和感なく回答できたり、メールや通知がキレイに表示させるようにも凝りに凝った。チーム内でもこまめに見せて反応をもらってたのは良かったと思う（この機能については開発もデザインもコーディングも仕様も僕がすべて自分で作ってるんだけど、案はチーム内のharuoさんとかkameko、nanaとかにもたくさんもらった）でも、人に使われ始めて思ったのが、まったく妥協しなくて良かったということ。もちろん使ってるうちにアレコレ要望は出てくるだけど、それでもかなりよい使い勝手で使えてると思う。

 

ここで、なんで人間はこだわって良いものを作らないといけないか、いい加減なものを作っちゃダメかが深く分かった気がする。もちろん無駄で意味のないこだわりには全く意味がないと思う。使う人と製品の価値に繋がるこだわりのことを僕は言いたい（注: こだわりが大事と言うと、ライブラリーの検討やくだらない技術上の宗教や主義思想の主張のことと考える人もいるので、そうではないと付け加えておく。また、仕事が遅いのを「こだわり」で言い訳するのもいけない。ただしこの主張は僕の人生の総括的な意見であり特定個人や一つの事象を非難するものではない）。

 

こだわってものを作る1つめの意味は、それが人に与える印象が製品を決めるからだと思う。

この機能は不完全なものだなと思えば使う人もその程度にしか使わない。

不完全だと思えばチームメンバーも真摯に向き合わないし、広報もいいかげんになっていく（みんなちゃんと仕事してくれるのは当たり前なんだろうけど、もっと深い心の底でのモチベーションみたいなのがダメになるという意味）。何よりも 作った人間の心と印象に不完全という事実が残る。一度そう思ってしまうと僕自身が誰かに話すときも一歩引いたものになるし、最悪「僕じゃなくて誰かが広報するものでしょ、それが分業ってもんでしょ」みたいな訳の分からない論理を自分の中で構築しまう。それはよくない。質問と回答機能についてはPyQブログに書くときも本当に楽しかったし、お客様やメンバーが使って良さを感じてくれるととても嬉しい。

 

そう、いい加減なものだと自分の中に残ってしまうから、これが2つ目。いい仕事をしたかどうかは自分の心が知ってる。それには嘘は絶対ついちゃダメだと思ってる。自分の気持ちにもそうだし、チームメンバーにも嘘をついちゃいけない。人間、聞こえの良いことを言うために気持ちに蓋をしたり小さな嘘をついたり、言わない嘘を使うことがあると思う。でも、たとえ誰かと衝突しようが、自分の考えは伝えないといけないし、嘘をついちゃいけないと思う。僕は（入社したときから）激しい人間だけど、どうしようもないし、それも才能だと最近思うようにしてる（普段の心根は自分的にはかなり穏やかなんだけど、プログラミングのことになると、いつものようになる）。

 

自分の製品を好きになれるかどうかは自分の仕事にかかってる。枕を高くして、堂々とした気持ちで今晩眠れるかどうかは自分の仕事にかかっている。

こだわりをもって、いい加減な仕事をしないのは、他でもない自分の自尊心や美意識、安心感のためにも大切なんだと思う。1つ目はいい加減さは人に伝わるし、伝わればいい加減な気持ちにみんながなるということ、2つ目は自分自身が一番仕事の良し悪しを知っているから、よい眠りにつくためにやり切らないといけないということ。

 

人間は「どこかの誰かの他人のため」と思うと、意外にもいい加減になってしまう。「仕事だから」と思うとなおのこといい加減になってしまう。でもそれが目の前の大事なお客様だったり、この機能を使うチームメンバーだったり、何よりも自分のためと思えるなら、もっと良いものを作れると思う。ものを作るってそういうことなんじゃないかな。

オープンソースに貢献する第一歩は？

考え

オープンソースに貢献するというと難しそうなイメージがあります。 僕も昔、 How to become a hacker を読んで感動してOSSに興味を強く持ったのですが、 オープンソースに還元するというのは難しいことのように思えました。

とくにGitHubもない（今ほど普及していない）時代であればどこで作られているのかもよく分かりませんし、 今となっても数少ない「すごい人」が活躍しているように見えます。

でも、実はそんなに難しくないですよ、という話をします。 また、ある意味では一番難しいパラダイムシフトが大事かもしれないね、という話もします。

この話は僕が日頃考えていることで、最近仕事やコミュニティーであった出来事には全く関係していません。 DjangoCongress JP の運営で何かあったとかではないので、変な邪推はしないでください（リラックスして大丈夫です）。 また、昔話的なこともしますが、僕はオープンソースと関わって10年とかその程度なので、長い人からすれば説明に間違いがあったり「新参が何を語るか」という気持ちになったりするかもしれません。

でも、そんな人も、DjangoCongressに参加してくれる人やスタッフ、発表者などすべての人も、この気持ちが共有できていると嬉しいな、とは思います。

本文はじめに

オープンソースに貢献する第一歩は、「自分はお客様である」と考える習慣を捨てることだと思います。 同時に「製品、サービスの提供者である」と考える習慣も捨てることだと思います。 これが、「第一歩」だと思います。

僕がこの話をする理由は「オープンソース」というものが当たり前になった今、改めてその活動とは何なのかを捉え直したいからです。 普及した故に逆説的に「自分たちのもの」では無くなっているのでは、と感じているからです。

オープンソースとは

オープンソースとは平たく言うと「みんなで便利なプログラムのソースコードをオープンにして共有すれば超良いよね」という考えです。 あまりにもザックリな説明なので、深い理解や歴史に興味がある人はオススメの書籍を最後に書いておくので読んでください。

さて、もちろんですがオープンソース活動の中心にはオープンソースソフトウェアを作ることあります。 それについての情報を発信したり、場を提供することも素晴らしいことです。 How To Become A Hacker では以下の5つがあげられています

  1. Write open-source software
  2. Help test and debug open-source software
  3. Publish useful information
  4. Help keep the infrastructure working
  5. Serve the hacker culture itself

引用元 How To Become A Hacker

1、2は分かりやすいですね。 3はブログやFAQで有用な情報を書くこと、 4はメーリングリストやRFCを運営すること（もはやSlackなどの各種サービスに代替されていますが）、 5はハッカー文化について伝えたり入門する内容を書くということですね（EricRaymondがオープンソースについて活動してきたこと自体を含むので意味の理解は若干難しいと思います）。

当たり前となったオープンソースの良いところ、ちょっと悲しいところ

How To Become A Hacker は素晴らしい文章なので読むことを強くオススメします。 ですが今となっては「当たり前」とも捉えられる内容かもしれません。 オープンソースそのものや、ハッカー文化や心構えを書いたエッセーだからで、今は「オープンソース」に疑問を持つこともないだろうからです。

僕が感じるのは、当たり前になった「オープンソース」に新しい接し方ができているということです

  1. オープンソース活動を通して、キャリアを形成する
  2. オープンソース活動を通して、企業やその製品やサービスを認知してもらう
  3. オープンソース活動を通して、業界の標準をとり製品やサービスに優位に進むようにする

（新しい、というのはオープンソース活動が普及した後、みんながGitHubを使うようになった後くらいの意味です）。

オープンソースが当たり前になったのは僕はすごいと思いますし、それを中心にした個人や企業の戦略なども良いものだと受け取っています。 かなり好意的に受け取っていますが、逆に、ある意味で遠いものになってしまったようにも感じます。

とくに2、3については「企業主体のオープンソース」となってしまい、「自分たちが参加するものではなくなってしまった」ように感じています。 1についても、「利用者」を超えて「貢献者」になった「すごい人」のみが、輝くように感じてしまいます。 （あくまで負の側面を抽出して見ていると捉えてくださいね）。

オープンソース（への貢献）と僕たちとの間に壁があるように感じてしまいます。 この壁とはなんでしょうか？それは、「お客様」と「提供者」の壁です。 オープンソースは全員が参加者であり提供しあうもののはずですが、このような「壁」を感じるのが昨今です。

お客様という癖

なぜお客様になろうとしてしまうのでしょうか？ ソースコードはそこに公開されています。情報は自由に発信できます。

その原因は、人間には「お客様」になろうとする癖があるからだと思います。

人は生きていれば、人生のほとんどの時間を「お客様」として過ごしています。 たとえば、買い物をするときは「お客様」と扱われます。 電車に乗っているときは「乗客」と言われますね。 外食をするとき、仕事用の有料ソフトを使っているとき、はてなブログプロを購読して使っているとき、これら全ての瞬間で「お客様」となれます。 そして、仕事をしているときは「製品、サービスの提供者」としてお客様に価値を届けていることと思います。

つまり、人は生きている時間のほとんどを「お客様」もしくは「提供者」として生きていることになります。 「お客様」と「提供者」として常に生きています。 だから人は自然と「お客様と提供者」という立場をとる癖があると思っています。 （良い悪いという話ではなくて、その癖が染み付いているということ）。

「お客様」として受け取るのが当たり前という気持ちを持ってしまうことがあります。 逆に、何かを人にするときは「サービスの提供者」として最大限に頑張ってしまう癖もあります。

その「お客様と提供者」習慣があるからこそ、オープンソースにおいても「利用者」と「開発者（貢献者）」に分けて感じてしまうのではないでしょうか。

僕は、オープンソースやフリーソフトウェアの世界ではその感覚を捨てて良いと思います。 捨てなきゃいけない、という意味ではなくて、その感覚から自由になって楽になって良いんだよ、ということです。

貢献する第一歩は「お客様」習慣をやめること

「オープンソースへの貢献って難しいんでしょ？」

いえ、そうではありません。 僕はこの「お客様、提供者という感覚を捨てる」とこが第一歩だと思います。 オープンソースはみんなのものです。「お客様」として製品やサービスを受けることに専念する必要はありませんし、「提供者」として頑張って人のためになりすぎる必要もありません。

まだまだプログラミングも学びたてという人は、もちろんスキルを伸ばすことはまず大事だと思います。 ですが、勉強会に行くときも、純粋に自分がそこの一員として振る舞えば良いと思います。 私とあなた、という関係ではなく、みんなが一緒にいるんだという感覚をもつこと、これが第一歩だと思います。

そうすれば視点が変わると思います。

たとえば以下のような視点を持てると良いと思います

  • ツールに不満があったときは、それを改善する提案をしてみる
    • 難しければ、どう提案すればいいか人に聞いてみる。
  • ドキュメントに分かりにくい点があれば直す提案や変更をする
  • だれか困っている人がいれば解決の相談にのってあげる
  • 勉強会やイベントに行ったときにゴミが落ちていれば拾ってあげる。机を一緒に拭いてあげる

このように些細な瞬間でも「お客様でも提供者でもない一員である」と思えばやれることはたくさんあると思います。 おせっかいで良いと思います。ぞんざいに扱われるときもありますが、逆に言えば相手も丁寧に扱う責任もないので仕方ないと思います。 そういう、お互い自然であって良いという感覚が広まれば良いなと思います。 PyConJP にいくと、みんなが丁寧にゴミを捨てていて良いなと思います。

ポイントは「いい子」になろうと言っていないことです。自分らしく一員として振る舞えば良いということです。 そのうえで出来ることがあるなら協力しよう、ということです。 「このソフトまじ使いにくいな」とか言うのは自由だと思います。僕もしょっちゅう言っています。 ただその上で何かアクションを起こしたりできると良いと思います。

今からできることは

まず今から以下の観点をもってみましょう。

  • このツールやライブラリーはここが良くなれば良いのにな（僕にも協力できるかもしれない）
  • このドキュメントの和訳はここが直すと良さそうだ（誰に伝えると良いだろう）
  • この本は面白いな（読みどころとか読み方、ポイントを多くの人に伝えられないだろうか）

週末に勉強会に行く人は、心の中で実践してみましょう。

  • イベントで学んだことをまとめてブログに書こう（他の人にも教えてあげよう）
  • イベントをこうすれば皆がより楽しめる、学べるかな（手伝ってあげよう、いま協力しよう）

そういう「ちょっとした気持ち」から変わっていけば良いと思います。 自分はオープンソースコミュニティーの一員だと思って、何かできそうなときは、ゴミ拾いでも良いので協力してみましょう。

それが、僕はそれが一番大切な貢献だと思います。

オススメの本、エッセー

以下の本はこの話に深く通じる内容です。 僕自身がかなり好きな本やエッセーなので、ぜひ読んでみてください （ご丁寧にAmazonの広告としているので、この話を読んでよかったと思う人、僕にコーヒーを買ってあげたい人は以下から買ってください）。

伽藍とバザール

伽藍とバザール

伽藍とバザール

フリーソフトウェアと自由な社会

フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集

フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集

それが僕には楽しかったから

それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス)

それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス)

どうでもよいストレスとどうでもよくないストレス

考え

この記事はあくまで id:hirokiky が自分の考えを書くものであって誰かの権利や自由を損害するものではありません。

表現には十分配慮しておりますが、至らぬとこがあればコメントでご報告ください。

 本文

最近、会社でメンタルケア研修を受けています。これは大変ありがたい会社の補助で、ストレスへの対処法や接し方、避け方を学んでうつなどの病気にならないようにしようというものです。

 

そこで、物事を受け取るときに「リフレーミング」することで楽になれるよ、というものがありました。

例えば「このサービスは使えないくそだ」という強い怒りや悲しみを覚えたときに一瞬、以下のように考えてみようという方法です

  • このサービスは別に悪いわけではないよな
  • なるほど、このサービスのことをよく見ているんだな
  • これが便利に使える人もいるのかもしれないな

このように捉え方を一瞬変えてみてみることで、状況を見てみようというものです。

もちろん物事自体は改善しませんし、これで100パーセント感情が収まるわけではありません。ただ、99パーセントや80パーセント、60パーセントに落ち着けることで自分が疲れなくて済みますし、状況にも冷静に対応しやすくなるでしょう、というものでした。

他にも「満員電車」や「レビューコメントでLGTMしかしない状況」、「暗に自分を攻撃してくる人」に接するときに使える（とかまぁそんなかんじの）ものです。

 

これについてはたしかに便利なメソッドでした。枠にはまった見方以外をしてみようということですね。

僕はよく「これはダメだ」とかをよくミーティング中や会話、Twitterなどで言うんですが、そのときにはこういう違いがある気がします

  1. これは良くない。直そう、無くそう（自分の仕事や自分の領域にあること）。自分の仕事、サービスや製品、著書に関すること
  2. これは良くない（利害関係もないしどうでも良いこと）飲食店とかどこぞの誰かの広告

たとえば、以下の広告はかなり良くないと感じます。とくに文字の視認性の低さが地をはうレベルだと思います。

 

https://twitter.com/nhk_n_sp/status/974279084007030784

 

ですがこれは2番の「利害関係がないとき」なので、たとえ広告を見てスマホを地面に叩きつけたくなっても5秒後には忘れています、僕は。次の瞬間に「あぁワッパーまじうまいな」とか思えます。

 

たぶん僕は、かなり極端な考え方をしているし、すぐダメだとか言うし、「まぁみんなお互い大変だから仕方ないよね」みたいなのも受け入れられない人間です。かなり白黒をハッキリつけます。

でも日常生活を営んでいて問題がないのは、そんなことがあっても2においては全く気にしてないからと思います。そこから「なんでこの広告はこんな色味にしてしまったんだ？誰がどんな教育をうけてこんなものを？きっと何々～なんだろうな、Twitterに書いてやろうか？」みたいなことを一切考えないんですね（こういう、怒りや悲しみからの妄想が激しい人は人生が大変なんだろうなと思う）。

 

ただ先述の1、仕事や自分の作品についてはその怒りや悲しみ、はずかしい気持ちや申し訳ない気持ちがかなり長く続くので、胃袋を悪くしてしまった（してしまっている）んだろうなと思います。

でもたぶん、それは僕の作るものの完成度や作る意義にプラスにも働いていると感じています。人間、ダメだと思っていても率直に言える人は少ないです。ダメだと思っていても自分でケツを持って直せる人は少ないです。製品やお客さんのために是が非でも良くしたいという人はほとんど世の中にいません。

でも、僕はそれを白黒ハッキリつけて良くしたいと思っていますし、性格故に推していけるんだろうなと感じています。

 

かなりのストレスを受けていますし、率直で協力的で生産的なメンバーにも助けられています。

でも、僕は今の自分のままで良いと思っています。もう少し、リフレーミングとかの使い方は知っていても良いかもしれませんが、自分の主張は率直に常に言いたいと思います。

 

一番ストレスを受けない方法は、未来も過去も他人の考えも、社会の常識も自分の正しさにも自分の在り方にも一切こだわらず、ただ感じるまま、あるままに生きることなんじゃないでしょうか。

スクリプトやバッチ処理、システム間連携をするときの観点

考え 製品開発

僕がシステムを作るときに観点としていることのメモです。 自分で作ったり、お客様とやり取りする際に、このあたりに気をつけて見ているという話です。

このネタは 執筆のために書いていたプロットのボツネタなので内容は精査できていません 。 与太話として、メモしている程度です。

スクリプトやバッチ処理、システム関連系をするときの観点

スクリプトやバッチ処理を作る場合は、まずデータの流れが大切です。 連携するシステムのどの位置にいて、どれだけのシステムが後ろにあるかを把握しましょう。

もし発注元のお客様や、社内の情報としてシステムの図がある場合は聞き出してもらっておきましょう。 これから作るシステムが、全体のどの位置で動くのかはとても重要です。

  • 関連するシステムはなるべく描き出しましょう
  • 関連システムのその先も簡単にでも書いておきましょう
    • データの不備やシステムダウンがあった場合などに、どこまで影響するかを把握できます

書き方は、紙にペンで書いたり、UMLのドローツールを使うのがオススメです。 具体的な書き方をイメージできないのであれば、ロバストネス図を書くと良いです。

以下の観点に注意しましょう

  • 入出力先はどこなのか
    • どこからデータが来るのか
      • 連携先から送られてくるのか（Pushされる）
      • 連携先に取りに行く必要があるのか（Pullする）
    • どこにデータが行くのか
      • 連携先に送るのか（Pushする）
      • どこかに置いておけば取りにきてくれるのか（Pullしてもらう）
    • どうやって通信するのか
  • データ、とは何か
    • ファイルやデータの形式
    • ファイルのサイズ、分割単位
      • 日単位の分割、ID単位、一括
  • 処理は何をするのか
    • どんな処理をするのか
      • XMLから必要な情報を抜き出してCSVに変換する
      • CSV内のID値から、他のメタ情報を問い合わせして追加する
      • HTTPでWebサイトに問い合わせして商品名、商品概要説明を取得してCSVにする
    • 頻度
      • 1日1回なのか
      • 週や月に1回なのか
      • 5分に1回なのか
    • 実行時間
      • 1時間で終わればよいのか
      • 1分以内に終われば良いのか

観点の使い方

  • 連携するシステムや処理の制限を把握すると、どのように処理すれば良いのかが見えてきます。
    • 他システムにデータがPushされる場合、リクエストを受け取るだけ受け取って変換処理は非同期で別途やるなどです。
  • どんなデータがどんな形式でやりとりされているかが見えてきますので名前付けや用語の整理がしやすくなります。
    • そのデータは「本」なのでしょうか「旅館」なのでしょうか「旅館の予約」なのでしょうか
    • あまり単純に「CSVファイル」と読んでいると、CSVファイルの種類が増えたときに混乱が生じます
  • 処理に1時間使える場合と、5分で終わらないといけない場合では利用する技術も変わってきます
    • 例えばAWS Lambdaは便利ですが、5分以内に処理を終わらせる必要があるので長時間の処理には向いていません。
  • 連携先とはどういうファイル、プロトコルで通信するのでしょうか
    • 連携先からHTTPでJSONをPOSTしてくれる場合はHTTPサーバーを作れば済みます
    • 定期的にSFTPでファイルを取得しにいく必要がある場合、サーバーを起動しておいて定期処理を実行する必要があります。
    • HULFTなどであれば固定長のCSVを扱う必要があります
    • USBファイルでないと転送できないのであれば、人がどう運んでくれるのかまで考える必要があります

終わりに

ちゃんと色々調査したり、まとめて書けば良い知見になりそうな気はしています。

Altair8800とFord T型、今はまだ成熟していない、という話

考え 製品開発

（この話は僕の個人的なエッセーなので、話の深さや確かさは追い求めないでください。 90、00年ごろに書かれた、よくあるプログラマーエッセーみたいなものだと思ってください）

本文

僕の心には、どうしても「諦める理由」を探してしまうクセがあります。 何か新しいものを作ろうとするときに、「もうこの産業は成熟している」とか、「すでにレッドオーシャンだ」とかが僕の頭の中でささやかれます。

たぶん、誰の頭の中にも居るんじゃないでしょうか。

ただ、僕はその主張は間違っていると考えています。間違ってると言いたいです。 たしかに、僕が仕事の主軸を置いているWebの世界もドットコムバブルやITバブル（90年、2000年ごろ）から10年、20年と経ちます。 最近のWebサービスは、巨大な企業のサービスを解体して個々を提供しようとする「アンバンドル」や、UberやAirBnBのような「既存事業のWeb化」のようなものが多く、たしかにSFのような目新しさは少し陰りを見せているように思います。

でも僕はいつも「まだまだ成熟はしていないな」と思うようにしています （自分を鼓舞するためにも）。

どういうことでしょうか。

例えば考えてみてください。 世界初のパーソナルコンピューター、Altair8800ができたのは1970年代です （例え話ですので、この際何をもって世界初のパーソナルコンピューターと呼ぶかは議論しないでおきましょう）。

Altair 8800 - Wikipedia

Altair8800から現代までで、40年の時間が経過しています。 現在（2018年）を「コンピューター時代の40歳」としてみましょう。

これを他の産業で考えていきましょう。

例えば車。Ford T が発売されたのが1908年です （ここでも、世界初の大衆車をFort Tと考えていますが細かいことはおいておきましょう）。

フォード・モデルT - Wikipedia

そう考えると、現在を「車時代の110歳」と考えられます。

現在はコンピューターの時代で40歳でしたね。 では「車の時代で40歳」はいつだったんでしょうか。 ジャガーSS100が40年代のようですが、見てみるといかにも昔っぽい車です。

www.jaguar.co.jp

身近なところですとHONDAが創業したのは1940年代です。

本田技研工業 - Wikipedia

僕達のいる「コンピューター時代の40歳」は言ってしまえば、まだHONDAが創業して間もないころというレベルです。 こう考えると、今からコンピューターの世界で何か新しいことを始めるのも悪い気はしませんね （もちろん、Webの世界は産業がすぐにグローバルになってしまうので当時のHONDAと比べるのはおかしい、というのも分かります）。

この考え方は実に優秀です。 例えば、現在を「Mozaicブラウザー誕生からまだ20年」と考えればまだまだ今は車時代の1920年ですし、 電球（電気の大衆化）を考えるとエジソンランプが1880年代なので「電気時代の何歳」という考えもできます （参考 電球の歴史）。

僕が僕に言い聞かせたいのは、現在ばかり見てはいけないということです。

ミクロな視点でものを見ると、たしかに色んなものが流行っては廃れているので時代はかなり速く進んでいる（進んでしまった）ように見えます。 ですが、こうやって産業そのものの成り立ちや古い時代に目を向けると、まだまだ現代は若すぎます。 Fort T型からTesla Model3の間には100年以上の時間が空いています。

僕が僕に言い聞かせたいのは、まだまだ何かを生み出すチャンスはあるということです。

未来から見れば今はまだまだ黎明期です。未来は訪れるものではなく今の人間が作るものです。 僕の、あなたの作るものがHONDAになれるのかは分かりません。 TVR や Nokia7600 、Zune のようになるかもしれませんが、それでも生み出した価値はあると思います。 みんながSkypeを使っていた時代に登場したSlackもあります。

2018年現在

  • プログラミングの環境構築は大変すぎます
  • サーバー構築も大変すぎます
    • Dockerは素晴らしいですが、以前複雑です
  • 人類はまだExcelから卒業できていません
    • 僕もGoogleSpreadSheetを表計算以外の目的で使うことが多々あります
    • VisiCalcが発売された1979年から進化していません
  • RDBは素晴らしいですが今だにfilesortやindexやbinlogやよく分からないEXPLAINの結果に悩まされています
  • ビデオ会議用マイク接続、GoogleHangout起動、スクリーン共有という無駄な5分を毎日使っています
  • 未だにテキストを人に共有して一喜一憂しています
  • 通勤電車は昔からずっと超満員で人の精神を傷つけています
    • リモートワークだけが解決策でしょうか？
    • 他に良い通勤手段や、仕事場は無いものでしょうか
  • 人類は今でもタイムカードや出勤簿をつけています
  • 人類は今でもHTTP1.0/1.1やIPv4を使って通信しています

今だけを見ると全てはすでに成熟してしまったように見えます。今にはもう可能性が残されていないように思えます。 でもそれは自分が諦めてしまっているだけです。自分の創造性に蓋をしているだけです。 自分の可能性の芽を摘むのをやめましょう。ゴミの山の上に座って「まぁここも悪くないもんだ」と言うのはやめましょう。 今はまだ成熟していない、不満だらけの毎日です。何か、新しいものを作りましょう。

この話が好きだった人へ

初期の電気産業とゴールドラッシュ、次のイノベーションの比較をジェフ・ベゾスが語っているので、ぜひこちらも見てください。

www.ted.com

歴史を知りたい人へ

コンピューターの産業史を知りたい人にはこのインテルの本をとても強くオススメします。

インテル　世界で最も重要な会社の産業史 (文春e-book)

インテル　世界で最も重要な会社の産業史 (文春e-book)

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

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

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