qiita.com 年明け早々こちらの記事がかなりバズっていました。記事の内容自体が「前提を共有せずに理由なしに斬って捨てる」だったのと、タイトルが「初級者のため」と付けながら内容が「中級者になろうとしている、もしくはそれ以上向け」であった為に、読んだ方の期待値との落差がかなり激しいものでした。
その後、私が上記の記事を書いたのですが、その裏側で私が考えていた事を記しておこうと思います。qiitaは技術を行う人同士が研鑽を積むために利用するべきと思うのと、こっちならあまり人目に触れすぎない安心感があるのでエモい内容はここに書いておくことにしました。
私の考えた事
私の見た目に、元記事は一定の良い内容が含まれる反面、通常の開発の想定では逆に落とし穴になること（ex. 全てをアロー演算子で書く）が項目に挙がっていたり、for文についての内容があまり推奨できるものでは無かったりするなど、「概ね良いが、良くないところも混ざっている」内容だと感じました。
普段こういう記事についてはそっ閉じして無かった事になるのですが、はてなブックマークを見ていると気になるものがあったんですね。ある種の諦めの混ざったような「JavaScript自体が難しい」という発言や「多数違反しているけれど、やったらまずいのか」という困惑です。ある程度修行した人なら「どんな前提ならどこまでを信じて良くて、どこまでが良くないか」がわかるのだと思います。
プログラミングは難しいかもしれないけれど、人が勝手に決めたルールに従おうとして苦労する必要はないし（意義のあるルールならもちろん従うべきですし、チームのルールは大事にすべきです）、一喜一憂する必要などないと思います。混乱したり諦めてしまうようなことが私はあまり好きではありません。そう促す外部の存在も好きではありません（この辺りの話とリンクしそうですね）。
そして嫌だ嫌だと言う前に何か行動するのが良いと思うので、言葉を発する前に何かをしようと決めました。
マサカリ？
こういう時に力のある人が「それは違うよ！」するのを マサカリを投げる （参考 ）と言ったりしますが、もともと何かを否定し合う関係って好きじゃないので、否定記事を書く気はありませんでした（私が権威も力も別にないということも、もちろんあります）。物事を好ましい状態に持っていく手段は、なにも否定したり戦ったりすることだけじゃないと考えたいからです。 そうでなければ何でも喧嘩したり権威に訴えたりしないと実現しない世の中になって、とっても面倒だと私は思うのです。
あと、年始から技術ライターさんのツイートに対して何か殺伐としていたりして、こんな心境だったんですね。
なんか年明けから殺伐としているなぁ。仲良くしようよ〜。
— 佐藤正志 (@ms2sato) January 3, 2017
なので補足記事を書きました
はてブを見るとかなり多くのコメントに「理由がない」を挙げています。ここに乗っかると色々とやれることがありそうに見えてきました。この時の私が考えたことは以下です。
- すでに私が背景を納得できているものに関しては噛み砕いた理由を示す。禁止ではなく判断の指針を示す。
- 可能ならより深い勉強のための参照リンクやキーワードを入れる（リンク先への感謝を忘れずに）。
- 私が別の考えをしているものや前提が曖昧なものには疑問を投げかけるか放置。無理に筆者に寄り添うことはしない。
あとは博識な方々が有効な情報をくださるだろうと考えていました。結果色々とご意見頂いて、ブラッシュアップしながら進めることができたと思います。元記事の作者さんは存じあげなかったので、どのような反応をされるかわかりませんでしたが、大変好意的に受け入れてくれたので助かりました。ありがとうございます。
ちなみに元記事の作者さんが「解決編」を用意している可能性があったのですが、コメントからそういう想定では無いと伺えたので、この行動に一定の自信を持って進めることができました。
答えを教える？
こういった文書について「考えさせずに答えを教える行為だ」と思う方がいるかもしれません。ただ、私は「何について考えるべきか」を重んじたいです。今回の内容の多くは「JavaScriptの処理系が昔から抱えている意外な落とし穴」や「最新に追いつくための手法」なので、一回どこかで目にして「あぁ、そういうことあるんだね」くらいで十分だと思っています。落とし穴が気になるならlintなりで抑制できることもあるでしょう。lint使うにもAtomのプラグイン入れるだけでも可能なので手軽さ優先ならこれでも良いはずです。
本当に考えることが必要なのは、概念の獲得だと思います。どう設計するとバグが少なくできるかとか、処理を分割する際にはどう気をつけると共通化しやすい処理になるかとか、抽象度が高い処理とはどのようなものかとか、バグの潰しやすいデバッグの方法はどういうことかとか。そういったことを考えるために、時間と脳のリソースを確保しておくべきです。
あくまで「何をよく考えるべきか」という切り口ですので、全く理解せずに記事を鵜呑みにせよと言っているわけではないとご理解ください。
記事・タイトルの書き方
よく記事のタイトルはバズらせるようにワードを仕込んだり表現を工夫するように提示されています。ただ、読者の期待値と食い違い過ぎるタイトルに価値があるのかは疑問です。今回のエントリも「中級者になりたい人向け」などとなっていたら、ここまで脊髄反射的にブックマークされることもなかったはずです。返信コメントも別の形になったことでしょう。 もしくは最初に前提とする読者像を書くべきだったかもしれませんね。
初級者という言葉
私が考えるのはこんな感じかな？上の方はどこまでも上があるでしょうが、概ねこんな感じかと思っています。
初心者: まだ内容が良くわかっていない。提示されている内容を鵜呑みにしてしまったり、本の内容を写してみたり、とにかく試行錯誤しながら何かやっている段階。初級者: より良い方法はわからなくても、とりあえず自分の望む動くものが（仕様を自分で調整したりしながら）ある程度作れる。「何をしたら良いか」が判り始めている。中級者: 基本的なことは身について、より良い方法を求めている。他人から依頼されたり、仕様を外から決められたものもある程度作れる。哲学を獲得しつつある。上級者: ある程度自分なりの哲学を持ってメリット・デメリットを判断しながら進めることができ、外部からの怪情報に惑わされることはあまり無くなる。周囲の他の人が気づいていない考え方に気づいたりする。
その観点で行くと、元記事は「より良い方法を求めている」に近いことをやっていると思うので、中級者に思えるのです。
おしまいに
自分で率先して記事を書いていくよりも、誰かが投げかけたものにレスポンスする方がうまくできそうな気がするので、こういうこともたまにはやってみようと思います。できれば喧嘩せずにやっていきたいものです。
