「自分の記事を自分で読んでムカつかないように」　うさみけんた氏が意識している、誤情報を届けないための工夫

うさみ氏の自己紹介

うさみけんた氏（以下、うさみ）：今日は「技術発信の信頼性を高める10（イチゼロ）のポイント」ということで話したいと思います。

私は「うさみ」といいます。ふだんはピクシブという会社で、ピクシブ百科事典とか、PHPで書かれているWebサービスの開発をしています。個人ではEmacsでPHP開発する環境を作っていたりとか。2022年はあまりできていませんが、イベントやカンファレンスのスタッフ、実行委員として参加することがあります。

今回のお題ですが、「技術発信の信頼性を高める10のポイント」ということで。個人的なブログとかWeb日記とか、10年くらい技術記事を書いてきて、どういうところを工夫してきたか、どういうところを気をつければ良い文章が書けるかなみたいなところを話そうと思います。

まずはじめにお断りですが、「10」という数はこの案を出した時に適当に作った数なので、任意の進数での10ということにしておいてください。今スライドはできていますが、実際に何個のトピックが書いてあるかは自分でも数えていません。ということで、よろしくお願いします。

うさみ氏のこれまでの取り組み

個人的にはどういうことをやってきたかというと、コンピューター自体は2003年頃からいろいろやってきて、Webとかもいろいろできて。プログラムやソフトウェアみたいなものにけっこう関心があって使ってきました。プログラミングを勉強したり、記事とかを読んでそれっぽいことを学んだり、簡単にちょっと動かしてみるぐらいは2003年頃からできました。

2010年より後、2012年ぐらいになるまでは、ちゃんとプログラミングでソフトウェア、アプリケーションを作るようなところ、体系的に「プログラミングができる」と言い切れるような感じにはなっていなかったです。

自分の中で10年ぐらい駆け出しをやっていて、そこでようやく仕事に就けた感じです。その間に自己研鑽という言い方をするとアレですが、プログラミングを学んだりする過程で知ったこととか、勉強になったこととかをWeb上のブログとかに書いてきました。

ということで、就職したのは2012年頃。Qiitaができたのが2011年頃です。それまではPHPにあまりのめり込んではいませんでしたが、2014年頃からPHPの詳しい記事とかを書き始めたりしました。

2016年に『WEB+DB PRESS』という、技術評論社さんが出している雑誌とかで、PHPの連載があったので、そちらに（記事を）書いたりするようなことを始めていました。あと、この頃からPHPカンファレンスみたいな、リアルのイベントでもPHPの発信をしてきています。

ということで、初めて技術記事っぽいものを書いてから雑誌に寄稿するまで8年ぐらい。けっこう長い期間をかけてやってきました。自分としては、発信するよりは、いろいろな技術をインプットしてやっていくようなことが、時間的にはかなり長かったですね。

ということで、2000年代中盤くらいから、わからないなりにプログラミングのいろいろな知見とか、複雑なコンセプトみたいなものの勉強はしてきました。その頃は使えもしなかったんですが、その後、複数のプログラミング言語とかを学んでいく上で、それが有機的につながっていって、今できる技術に直接つながっていくようなことがありました。

自分が思っていることとしては、なにかを発信する前に、乱読というか、使えるにしろ使えないにしろ、知識としてため込んで、そこから発信することはけっこう大事なポイントの1つであるかなと思っています。

初期の発信で実践してきたこと

初期にどういうことをやってきたかというと、環境構築とかカスタマイズみたいな、あまり技術的ではないこと。自分がやってきたログみたいなこととか、リアルで教えてもらったこと（をやってきました）。

昔アルバイトをしていた会社で、関数型言語をちょっと教えてもらったりするようなことがあったのですが、それを自分なりにいろいろ調べたり、教えてもらったノートとかをブログに書いてまとめたりみたいなこともしていました。

あと、ググっても中途半端にしかわからないようなこととか、ふわっとした言い回しで「なんでこれがこうなっているのかよくわかんない」みたいなことって、たまにあるじゃないですか。そういうところを、自分で「どうしてこうなるのか」というのをハッキリさせたくてまとめたりもしていました。

あとは断片的ならまだしも、明らかに間違っていたりとか、現場に即していないようなものを、端的に言うとムカついたので、自分でやるしかないと。そういうところから発信していきました。

自分の記事を自分で読んでムカつかないような文章を出していく

みなさんもそうだと思うんですが、なにか解決したい問題（があったり）、困っているのにぜんぜん関係ないようなこととかが出てきたら、ムカつきますよね。

だいたいの人はムカつくと思うので、「これから発信する」という段階では、自分の記事を自分で読んでムカつかないような文章を出していくのは、けっこう重要なポイントかなと思います。ということで、自分を客観視して見ていくというところです。

この「ムカつく」という感情はけっこう理不尽で。読者の立場は、人がまとめた情報を一方的に摂取して、それで自分の解決したい問題に合わなかったからと、書いた人が悪くなかったとしても「自分の感情としてはそうじゃないんだ」みたいに思ってしまうことがあります。（その現象に）憤りは感じつつも、自分でそれをどう解決するかを考えたりしていました。

誤情報とは何か

技術的な情報とかを見ていくと、「この記述は嘘だ」みたいなことを、僕自身ちょっと言ってしまいがちなところもあるのですが、それはさまざまな事情で現場に即さないということもあるし、単純に技術の誤認みたいなこともあったりします。

間違った情報は、自分でもっと適切なものを発信していくことでしか置き換えられない、止めることはできないのかなということで、（自分で）発信していくことをしていました。

誤情報にはどういうものがあるかということと、（それに対して）読者としてなにができるか。（例えば）単純な間違い、なにか書き間違いみたいなものとか、スペルが間違っていたり、リンク先が間違っていたりは、自分が発信する立場じゃなくても、読者の立場として例えばQiitaの編集リクエストとかを送って修正してあげるとか。小さいことですが、技術発信の最初の1歩みたいなところにできるかなと思います。

あとは、その記事を書いた人が明らかに間違ったことを書いているみたいなところは、コメント欄とかSNSとかでやんわり指摘するといいかもしれないです。

あとはドッグイヤーというか。コンピューターの分野は特に短い時間で進歩していったりするため、すぐにその内容が廃れたり、事情が変わっていったりすることがあります。昔は正しかったけれど、今は誤情報になってしまうようなこともあったりします。こういうものは、自分で新しい記事を書くことが、1個の解決策かもしれないですね。

誤情報を届けないための工夫

ということで、自分で新しく技術を発信する上で、どうやってそうならないようにするかという単純な工夫としては、これはちょっと根性論っぽいんですが、自分で気をつけるとか、あとは誰か信頼できる人にチェックしてもらう。

ちょっと宣伝ですが、友人が「Shodo」というサービスで、AI校正のツールを開発しているので、こういうサービスを利用するのもいいかもしれないですね。

明らかに技術的な対象の事実誤認みたいなところに関しては、その分野の専門家になるということでは完全に解決できなくて。偉い教授の人とかでも間違った内容を書いてしまうことはあり得なくはありません。

すべてのものを見通して書くことはできないので、「この記事の内容は普遍的に正しい内容だ」ということではなくて、「今自分が動かしているこの環境に対してはこう動く」というところを、記事の条件を絞って記述することで、間違っていないことを主張することはできるかなと思います。

あとは、情報源に関しても、Googleとかで適当に検索した記事よりも、Web上に「この記事を見ておくと間違いない」みたいなサイトがいくつかあるので、こういうのを見ておくといいでしょう。

HTMLとかCSSとかJavaScriptみたいなものに関しては（MDN Web Docs）。これはMozillaが運営しているサイトですが、かなり網羅的で正しい内容で、なおかつコミュニティで日本語に訳したような内容が見られるので。基本的には適当にキーワードで検索したものよりは、まず「MDN」とつけて検索することで、比較的信頼性の高い中立的な記述、あとは互換性とかも配慮されたような質の高い情報にアクセスできます。

あとは、PHPとかプログラミング言語の固有のマニュアルに関しては、コミュニティで訳されているドキュメントがあったりするので、こういうのにもアクセスしてみるといいでしょう。

あと、読めればの話ですが、ソースコードに当たってみることで「ここでこういう記述をされているので、確実にこう動きますよ」みたいなことを説明できるかもしれません。