Make組ブログ

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

Webpack (v4) で複数の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.cssCSSファイルとしてビルドされます。

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

まとめ

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

他のおすすめ記事

blog.hirokiky.org

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

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

免責

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

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

会話のレイヤー

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

f:id:hirokiky:20180421140652j:plain

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

あいさつ

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

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

情報

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

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

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

語り

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

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

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

この考えの意味

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

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

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

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

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

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

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

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

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

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

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

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

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よく分からんけど動いたから良いかという気持ち。

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

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

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

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

この angstwad/docker.ubuntu ロールでは変数を設定するだけでDocker環境のカスタムもできます。 daemon.json の設定をAnsibleの変数から指定して、 storage-driverlog-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、仕事や自分の作品についてはその怒りや悲しみ、はずかしい気持ちや申し訳ない気持ちがかなり長く続くので、胃袋を悪くしてしまった(してしまっている)んだろうなと思います。

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

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

 

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

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

 

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