2018-05-20

DjangoCongress JP 2018ってイベントを開催した話

f:id:hirokiky:20180520174908p:plain

2018年5月19日に、DjangoCongress JP 2018というイベントを開催しました。

djangocongress.jp

これはWebフレームワーク Django のカンファレンスです。参加者は全部で100人ほど、発表者12人、スタッフ（合計で）15人ほどのイベントでした。めちゃくちゃ楽しいイベントでした。もうね、最高。

Togetterも作ってくれたよー togetter.com

僕は代表として、キックスタートからこのイベントを皆で作っていました。今まで日本でDjangoだけを扱った大きなカンファレンスはなかったので、これが初めてのイベントになったなと思っています。

スタッフは〜15人ほどで開催しました。準備には2017年の11月に初めたキックスタートから初めています。

django.connpass.com

もともとsalexkiddが2017年のPyConJPのパーティーで、「そういやDjangoでカンファレンスやんねーの」と言うので、「お、じゃぁやるか」となったのがこのDjangoCongress JPです。

（これを書いている今はDay 2のSprint Dayで、DjangoへのPRが1つまとまったので休憩がてらブログ記事を書いています）。

ここではイベント開催するときに感じたことや、「こうやったのは良かったなぁ」という話をします。あまり時系列順に語るまとめをする気もないので、感じたことを書きたいと思います。

最小のイベントを作る、みんなで盛り上がる

このDjangoCongress JPは宇宙で初めて誕生するイベントです。去年までのノウハウやスタッフ間の繋がりもそれほどない状態からスタートでした。なので、まずは「最小でイベントを作ること」、「5年続く1年目になること」をコアの考えた方としてイベントを作っていきました。

まずスタッフ間の「コミュニティー」も無いに近い状態ですし、Djangoでイベントをやって需要があるのかすら分からない状態でした。その状態で「アレをやろう」「イマドキのカンファレンスはこれは絶対ある」みたいなのを闇雲に追い求めると破綻するのは当たり前だと思います。

まず、キックオフの集まりから「こういうものを作ろう」というビジョン、温度感をスタッフの間で最初に共有できていたのは良かったと思います。とくに「やらなくていいよね」を共有できたので、すごく小さい（やる作業が少ない）けど良いカンファレンスができたと思います。僕たちは「他で聞けない、深くて面白い発表を聞きたい」、「場所さえアレばみんなで楽しめる」ということに注力していました。

例えばランチ提供も、パーティー（懇親会）提供もしません。チュートリアルやハンズオン、企業スポンサーにブース出典、ポスタートーク、動画配信、同時通訳もありません。その代わり、ランチは「ランチマップ」を用意して各人に自由に行ってもらったり工夫を凝らしていました（ランチマップ作ってくれた小俣さんありがとう）。

ただ、「他のイベント（とくにPyConJP）で採用されないようなDjangoの濃い、Django内でのバラエティーに富んだ発表をしよう」という一点は貫けて良かったです。 PyConJPはイベントとして規模が大きくなっていますし、データ系や機械学習系などPythonの幅もかなり広がっています。ディープな話（例えばDjangoのデータベースドライバーの実装の話や、GeoDjangoを使った地理空間アプリの話）を発表をする機会はどうしても減ってしまうと思います。

（開催するまでは不安でしたが）上記のものなかったけどなくても良いんだなぁと思いました。同時通訳がなくても英語の発表も聞いてる人多かったですし、動画配信もなかったけど、その分スライドのアップロードやSNSでの投稿が多かったのでそれはそれでよかったと思います（スライドは https://djangocongress.jp/ にすべてまとまっていますよ！）。あと、みんなブログとか書いて情報を広めてくださいね。それか、同じ発表内容で再演とかしてくださいね。

「無い効果」というのは面白いなと感じていて、例えば「動画配信がある」と思うと、たとえ参加してても「昼寝してて良いかな」と思ってしまう瞬間はあると思います。「ブログに書かなくても動画あるしなぁ」とか、「メディア記事あるしなぁ」とか、「togetherとか公式の色々もあるし良いかなぁ」って言い訳ができちゃうわけですね。でも今回はみんな会場でのその瞬間に集中してたと思います。

Twitterで #djangocongress が日本のトレンドになったりもしてて、スタッフも参加者の人もみんなで盛り上げられて良かったなぁと思います。オープニングで「みんなブログ書いてね！！スライドアップロードしてね！！ってSNSに書いてね！！」って共有したのも良かったのかな。提供者が提供しすぎると、参加者がより参加者になっちゃうのかもしれない。それだと寂しいし、みんなで盛り上げていこうねーってほうが僕は好きかな。

やらない、という力

「やらない」を決めると色んな懸念や作業、連携や指示、担当割りもなくなるので一気に楽になると体感できました。たぶん、今回のイベントでそれが一番大事だったと思う。おかげでイベント当日にも余裕があって、スタッフも含めてとてもイベントを楽しめたと思う（僕は色んな発表も聞けたし、話もできたし、すごい楽しかったよ）。今後もし何かやることを増やすにしても、お金で解決するほうを選ぶかなぁ。

代表としてやったこと

イベントの代表として色々やったけど、僕は流れとか勢いとか場を作るのが大事なんだなぁと思いました。あんまり自分が「長」みたいになるのが好きじゃなくて、「座長」という呼び方もあえて使いませんでした（なんかね、僕の気持ち的にですが）。立場として、窓口として、顔として「代表ですよ」以上の意味はない（し、必要ない）と思ってます。

今回は初めてのイベントだったし、Djangoのでかいイベントをやって需要があるかも分かりませんでした。でも確実にある気はしていました。なので、まずは「やるよ」って言うことが一番僕の大事な仕事だったんじゃないかなぁと思います。「やりたいね」じゃなくて「やるよ」と言うこと。あとはスタッフみんなで頑張りました。スタッフの僕たち、頑張ったね～。

具体的なやったことはビジョンを共有したり、定期的に作業イベントを開催したり、作業するためのツールとかスラックとかを整備したり、進捗を見たり、担当や役割をお願いしたり、色々実務的なタスクをこなしたりしていました。当日は全体の動きを見たり、オープニングスピーチとクロージングスピーチをしたり、LTの司会者をしたりしていました。でも主には人の発表を聞いたり話したりしていたんで、参加者としてもかなり楽しみました。

コアのスタッフが運営に慣れてる人が多かったのでとても助かりました。お互いに空気感がとても伝わりやすいからですね。「～しようよ」「～いらないよね」って言ったときに「え、なんでなんですか」って根本からの説明が少なくて済むから。あと、みんな色んなイベントを開催したり参加してる人たちだから「あれは必須だよね」とか「まぁ、あれはなくてもぶっちゃけいいよね」って気持ちが深いとこで伝わっていたと思う。

でも今までそんなに繋がりも深くない同士だったけど、かなり深まったなぁと思う。Djangoの日本コミュニティーってあるの？みたいな感じはあったけど、今ならあるって言えるよね。少なくともスタッフ同士があれだけ一緒にいいもの作って時間を共有できたってだけでも良かったです。それが僕が今回、一番作れて良かったことかなぁ。

身近なイベント

感想を聞いてみると「みんなの顔が見えた」「warm and like family event」みたいな感想を何人かに聞いた。それはとても嬉しくて、規模を大きくしすぎないこと、行動規範を大切にすること、みんなで楽しむことは大事にしたかったので実現できて良かった。

僕は「参加者」と「提供者（スタッフ）」に分かれたくないと思ってた。どんなイベントでもそう思う。だってスタッフってボランティアですよ。何十時間っていう労力を無償で提供しています。一番楽しめないといけないと思う。

イベントのオープニングで「みんなが参加者、みんながスタッフ」と話しました。「SNSにたくさん書いてほしい。スライドをアップしてほしい。隣にいる人と話したり助け合ったりしてほしい」と伝えました。みんなイベント中によく話してたしリラックスしてるようで良かったなと思います。とくにCybozu Barはリラックスできて良かったなぁ。

行動規範についてもたっぷり時間を使って話したのが良かったのか、ビデオ録画どストリーミングがないからその瞬間を大事にしたのか、そういうのもよかったのかもしれないです。ただ、その場にあった空気感みたいなのが、何か良いなと思っていました。

今後のイベント

たぶんDjangoCongressは参加者300人を越えるイベントにはならないと思う。今回で120人くらい。150人+2,30人くらいでいい感じかなと思っています。今回は「参加枠増やしてください」「参加できなくて残念です」という声もいただきました。申し訳ない気持ちになったし僕も謝っていた気がしますが、でも、だからって500人とか1000人のイベントにはしないと思います。501人目は常にいるとも思いますしね。まぁ他人を変えようとするよりも、やりたいことがあるならイベントを別に作るのも素敵だと思います。協力はどんどんしますよ！！たとえば地方でもDjangoCongressをやってほしいなら、ぜひ、「やろうぜ」って言ってみてほしいです。

内容も、今年と同じように色々と提供しないけど、発表が面白くて、みんなで色々好きに話せるようにしたいです。究極、場所と、人と、話のきっかけがあればそれでいいと思います。会場提供のサイボウズさん、ありがとうございました。発表者、スタッフ、参加者のみなさんもありがとう。楽しかった？僕は楽しかったです。また、こういうのやりたいなー。

Django Congress JP 2018! #djangocongress pic.twitter.com/YleEJUZuAa
— mamix1116 (@mamix1116) 2018年5月19日

2018-05-03

Webpack (v4) で複数のJavaScriptファイル、CSSファイルを分けてビルドする

JavaScript css

webpackは便利ですが設定などは慣れが必要です。僕は面倒なので、毎度自分の過去のプロジェクトからコピーして使っています。その内容から抜粋してブログの記事にしています。

想定としてはSinglePageApplicationとしてはアプリを作らずに、フレームワークからJSを配布するWebアプリの構成です。すべてのページをJSで作るならよいですが、一部のみアプリケーションとしたい場合はこの記事で説明されている設定を参考にしてください。

僕の考えですが、管理用のページや設定画面など一般的なWeb+DBの画面であれば、SPAとして作るのは手間が無駄に多いと考えています。モデル定義+フォームの自動生成や、一般的なWeb+DBの画面構成はDjangoなどのWebフレームワークをそのまま使うほうが扱いやすいと思っています。そのうえで、CSSはビルドしたい、Web画面で共通に使うJSをビルドしたい、アプリケーションとして動作するページのJSもVue.jsやvue-loaderなどで作りたい場合はよくあると思います。

SPAで作りたい人は vue-cli を使って、そのまま従うのが良いのではないでしょうか。

免責

この記事での情報や内容の正しさは保証しません。最大限注意していますが、間違っていたり重大なバグがある可能性はあります。それによって発生したどんな損害にも責任は持ちませんし、保証しません。自己責任で参考にしてください。

バージョン

$ webpack --version
4.6.0

記事内で特別に書きませんが、 style-loader などのインストールも必要です。適宜、インストールしてください。

リポジトリー構成の想定

以下のように、 client 以下にJS、CSSのビルド用のディレクトリー、 web 以下にWebフレームワークで作るWebアプリのディレクトリーを分けています。 client ディレクトリーからビルドして、 web から使えるようにします。

repo/
  - client/
    - webpack.config.js
    - src/
        - editor.js
        - webcommon.js
  - web/
    - myproject/static/dev/js/  # Webアプリから配信

複数JSファイルをビルドする

アプリケーションとしてのJavaScriptと、Web画面で使うJavaScriptを分けてビルドしています。 editor.js をアプリケーションとしてのJS、 webcommon.js を（ナビゲーションバーの操作などの）一般的な画面のJSと考えてください。

module.exports = {
  mode: 'development',
  output: {
    path: __dirname + '/../',
    filename: '[name]'
  },
  entry: {
    'web/myproject/static/dev/js/editor.js': './src/editor.js',
    'web/myproject/static/dev/js/webcommon.js': './src/webcommon.js',
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: {
          loader: 'babel-loader'
        },
        exclude: /(node_modules|dist)/
      }
    ]
  },
  plugins: []
}

これで、 ./src/editor.js をエントリーポイントにするJSファイルが ../web/myproject/static/dev/js/editor.js にビルドされます。 entry の中身を増やせばビルドするJSファイルも増やせます。

フレームワーク側でのJSファイルの扱い

JSファイルはフレームワーク側で管理できるディレクトリーに書き出しています。このとき、開発用のJSは static/dev 以下に保存しています。 Webアプリケーションが開発環境時にはこのディレクトリー内の静的ファイルを使うように設定して、本番環境時は別のファイルを使うようにしています（CloudFrontから配信された、UglifyされたJSやCSS）。 static/dev はGit管理しないようにすることでGitリポジトリーの肥大化も防げます。

Webpack 4でCSSをビルドする

JSファイルだけでなくCSSファイルを別途ビルドしたいことがあります。ただし今回は、「JSファイル内のCSSを別に配信する」目的ではありません。 JSファイル内のCSSはそのまま組み込むようにしておいて、別途、CSSのみをビルドする方法を説明します。

webpackではCSSファイルはビルドできません。 extract-text-webpack-plugin を使ってうまくできるようにします。

ただし、2018年5月3日時点では extract-text-webpack-plugin はWebpack4に対応していないので、インストール時は以下のようにしてBeta版を使います。

$ npm install --save-dev extract-text-webpack-plugin@next

webpack.config.js にCSSの設定を追加する

単に extract-text-webpack-plugin の設定を追加すると、既存のJSのビルドにも影響してしまいます。上記したJSの設定とは別に、CSSをビルドする設定を書きます。

module.exports = [
  { ... },  // 上記したJSのビルドの設定
  {
    mode: 'development',
    output: {
      path: __dirname + '/../',
      filename: '[name]'
    },
    entry: {
      'web/myproject/static/dev/style/main.css': './src/main.scss'
    },
    module: {
      rules: [
        {
          test: /\.scss$/,
          use: ExtractTextPlugin.extract({
            fallback: "style-loader",
            use: [{
              loader: "css-loader"
            }, {
              loader: "sass-loader"
            }]
          })
        }
      ]
    },
    plugins: [
      new ExtractTextPlugin({
        filename: (getPath) => {return getPath('[name]')}
      })
    ]
  }
]

これで、 ./src/main.scss をエントリーポイントにするSCSSファイルが、 ../web/myproject/static/dev/style/main.css にCSSファイルとしてビルドされます。

もちろんJSファイルの設定も渡しているので、 webpack コマンドのみでビルドできます。両者の設定で重複している部分は共通の設定にしておくと良いでしょう。

まとめ

最近作っているものは PyQ も含めてこの構成で作っています。 SPAではやりたくないなぁ、という人にはオススメしたいです。

他のおすすめ記事

blog.hirokiky.org

2018-04-21

会話の深さと人数、コミュニケーションが苦手とは何か

会話の深さと、その会話ができる人数規模、一度に集まったときにどの深さまで話せるかと考えてみました。たとえばコミュニティの集まりや飲み会、ビジネス上の会話や友人との会話、または配偶者の会話をする中で考えていたことです。

免責

この内容は誰かを批判するためや優劣を競うためのものではないとお伝えしておきます。僕自身の考えた分類を紹介したいという気持ちと、悩みなんて持たなくていいんじゃないかという気持ちの共有です。

また、歴史の中で誰かがこれと似た、または同じものを語っていたとしても、とくにどうでも良いと思っています。僕の考え方は今まで読んだ本の影響がありますので、その影響が入っているか、単に知らないだけです。小学生がピタゴラスの定理を発見することもありますし、そういうものだと思ってください。

会話のレイヤー

考えを文字で伝えるのが大変だったので絵にしてみました。この絵は下にいくほど「より少ない人と」、「より心に近い深い」会話ができるという構図です。図の右には具体的にはどういった内容があるのかの例を書いています。

f:id:hirokiky:20180421140652j:plain

上にいくほど「口」で話す部分で、下にいくほど「気持ち」で話す部分なのかなとも思います。

あいさつ

単純なあいさつから、社交辞令的な会話、天気の話などがここに含まれます。この会話ができる相手はおおよそ無限にいます。一度に数十人が円卓を囲んでもこのレイヤーの会話はやりやすいです。

なぜなら相手の好みや興味の分野（情報）と心情や思想、感性（語り）の部分に踏み込む必要がないからです。この逆三角形は、下に行くほどできる相手が減ると考えてください。ですので人数が増えれば最小公倍数的にこのレイヤーの会話が増えます。

情報

このレイヤーは趣味や興味の分野、仕事や技術の会話です。好きな食べ物や趣味のレジャースポットの情報交換、業界や技術の動向の会話です。たとえば僕はプログラミングやソフトウェアが好きです。Webサービスやロック音楽、バイクなども好きです。こういう「プロフィール欄」に載ってそうなことがこのレイヤーです。また、共通の知り合いの近況の話題などもこのレイヤーに入ると考えています。要するに、共通のコンテキストのうえのみで成り立つ会話ということですね。

技術者のコミュニティや趣味などの集まりが大切なのは、同じコンテキストを持つ人が集まるのでこの情報交換がしやすいことにあると思います。あいさつから入って、相手と話題があうところを探す必要がないからですね。いきなり「Vue 2だけどvue-loader使ってる？emacsだとjs2モードがmmm対応していなくて〜」や「ラバーソウル以降からそれ以前にない深みがでてサージェントペパーのスタジオ以降〜」などの会話です。この「情報」のレイヤーは、コンテキストがあえば会話もよくあいます。

ただコンテキストが共有されているからといって「情報」の話ができるとは限りません。「技術コミュニティの飲み会はつまらないので行かない」という人は、この「情報」レイヤーの会話を強く期待しているけど、その実「あいさつ」レイヤーの会話（技術系や業界の「あるある」ネタ）に終始していて残念だった記憶があるんじゃないでしょうか。

語り

このレイヤーは自分の心情や考え方、生き方や感性、過去の生い立ちなどを語りあえる関係というレイヤーです。ここで大切なのは 思想や宗教的に別であっても語り合える相手 というニュアンスがあることです。相手の考えを上下や評価、優劣、同じか違うかの関係でなく、認めあって語れる相手かどうかという意味です。政治思想が同じでも「情報」の会話や、まして「あいさつ」の会話しかできていないことは十分によくあります。

何の思想を持っているかでなく、自分の深い考え方や生い立ちを語れるかということです。逆説的に、他愛ない会話ができるというのもこの相手だと思います。それはどのような話をしても相手と受け取りあえるという信頼があるからだと思います。

このレイヤーの会話が出来る人は、0〜多くて20人ほどだと思います。僕は5,6人くらいでしょうか。同時にこの会話ができるのは多くて3人だと思います。人間心理的に「深い考えをさらけ出せる」と思える場はかなり少ないでしょう。

この考えの意味

これは僕なりに人との関わり合い、会話とは何かと考えてまとめたものです。僕自身が「会話しているけど、何か物足りない」と思うときに、なぜそう感じるのかをまとめるために書きました。僕の場合は「あぁ、もう少しこの人と深い話がしたいんだ」と気づくことや逆に、「情報交換がただただしたいと思ってたけど、これはこれで楽しいからいいか」と思うようにもなった気がします。

この図や説明自体が何かに役に立つというわけではありません。また、攻撃の材料にならないことを願っています。ただ会話やコミュニケーションに不満や不安があるなら、自分が今どの会話をしたいのかを考え直すのに役立つと嬉しいです。

コミュニケーションが苦手とは何なのか

僕はコミュニケーションが苦手だと思います。具体的には人の上下が分からなかったり、「触れないでおこう」のような気持ちがあまり分からないのでキツすぎたり怒ってるように思われることです。ただ、あまり気にしていないです。

コミュニケーションが苦手、という場合は以下の2つの種類に分けられると思いました。

「あいさつ」レイヤーの会話ができない
相手と今どのレイヤーの話までできるか、進めればいいかわからない

オチから言うと、1,2両方なくてもいいんじゃないかなと思います。

「コミュニケーションが苦手」という論点は、多くの場合は上記の1番「あいさつ」のレイヤーの会話が苦手なだけだと思います。この部分が属に言う「コミュ力」だと思います。たとえば会話の弾ませ方や相手との距離の測り方、面白い話の豊富さや話の展開力、リズムの良さや掘り下げ力、引き出し力やツッコミ力的な部分です。正直、 コミュ力があるかどうかは全く気にしないとなくて良い と思います。

2つめの「相手とどのレイヤーまで話して良いか分からない」、これは話の相手がたくさんいる中で、相手とどれくらいの親密度でどの会話までできるかを測りかねることです。多くの場合は距離感がつかめずに浅めの会話で終了する場合です。逆に、急に深い話をしすぎて距離をとられてしまうという場合もあります。ですが、 相手との距離感も別段測れなくて良いと思います 。十分見知った相手と会話できればそれで十分だからです。

上記2つ目まではなくても良いと思います。まぁ、かといって「あいさつ」レイヤーの会話は全く不要だとか、その会話ばかりする人は愚かだとか思う必要はないと思います。ただ、 不要とは言わないが思い悩む必要はまったくない と考えています。人間社会の中で求められるケースはあると思いますが、それは狭い視野での正義でしかないので無視しましょう。

ただし、永遠に誰とも「深いレイヤーの話をしない」のは少し寂しいように思います。属に言うコミュ力も不要ですし、深い会話ができる人を増やせる必要もとくにはないですが、いつまでも「あいさつ」や「情報」で会話を終了させようとするクセを持っていたり、優劣や競争、勝ち負けをベースに会話してしまい親身になれないのは少し残念に思います。信用できそうな人と、上下なく少しづつ語ってみるのが良いと思います。僕も、そういう会話を大切にしたいなと思っていますが、なかなか難しいですね。

2018-04-03

Ubuntu17.10 (Wayland環境）でLogitech Marble Mouseでスクロールする

Linux

f:id:hirokiky:20180403203020j:plain

右の小さいボタンをスクロールにする場合はターミナルで以下を実行。

gsettings set org.gnome.desktop.peripherals.trackball scroll-wheel-emulation-button 9

17.10: Mouse Wheel Emulation Fails after upgrade

X周りの設定はうまく効かなかった。

Logitech_Marblemouse_USB - Community Help Wiki

あと、 xinput --list にもLogitechMarbleMouseはでない。 WaylandとXよく分からんけど動いたから良いかという気持ち。

ニッチで新し目のプラットフォームでニッチなマウスを動かそうとするのはめんどくさいな。

2018-04-03

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

2018-03-27

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

考え

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

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

僕がここ最近ずっと作っているのは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つ目は自分自身が一番仕事の良し悪しを知っているから、よい眠りにつくためにやり切らないといけないということ。

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

2018-03-23

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

考え

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

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

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

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

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

本文はじめに

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

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

オープンソースとは

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

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

Write open-source software
Help test and debug open-source software
Publish useful information
Help keep the infrastructure working
Serve the hacker culture itself

引用元 How To Become A Hacker

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

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

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

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

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

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

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

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

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

お客様という癖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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