320
110

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

お題は不問!Qiita Engineer Festa 2023で記事投稿!

「残念な技術アウトプット」を避けるためにできる工夫は?

Last updated at Posted at 2023-07-02

アウトプットはいいぞ

現代日本のITエンジニア界隈では、自分の学びや経験をブログや登壇で「アウトプット」することを奨励する風潮があります。

これはとても喜ばしいことで、インターネット上の叡智としてどんどんナレッジが蓄えられていき誰かの助けになってくれますし、アウトプットした本人にとっても発信行為によって学習効果が促進されます。

↑ IT勉強会「ssmjp」では "アウトプットしないのは知的な便秘" という有名なスローガンが掲げられています。

軽率なアウトプットを忌避する声も

一方で、その技術分野の権威でもなんでもない一般人による技術アウトプットがインターネット上に増えてしまうことを良く思わない人々の声もたまに挙がります。

確かに、明らかに質の悪いアウトプットが増えると以下のような懸念事項が考えられます。

  • 技術的に誤った内容が含まれていることにより、誤解が広まってしまう
  • 完成度の高い情報源が既にある場合、検索時のノイズと受け取られてしまう

私自身、これまでのキャリアでアウトプットする側・受け取る側の双方の立場で多大な恩恵を受けてきたからこそ、みながポジティブにアウトプットを続けられる優しい世界にしていきたいと強く思っています。

そこで僭越ながら、いわゆる「残念なアウトプット」と揶揄されてしまわないための工夫として、私が普段心がけていることをみなさんにもご紹介してみます。

「残念なアウトプット」を避けるための工夫

極力、一次情報をたどる

「xxについて調べてみた」系のアウトプットの場合、先行する他者のアウトプットを読んで参考にすることも多いと思います。その際、参照していたアウトプットに誤りが含まれていた場合、同様の誤りをそのまま引き継いでしまうリスクがあります。

技術的なトピックに関して調べる際は、先行アウトプットを参照していたとしても極力、公式ドキュメント等の一次情報で裏取りをするようにしています。すべての情報を裏取ることが非現実的な場合は「疑わしいポイント」や「日々のアップデートで変わりやすそうな部分」だけでも優先して調べておくだけでも効果があります。

実機でも検証してみる

技術分野によっては、一次情報ですら正確性が十分でない場合もあります。アウトプットのテーマが実際に手元で試せる技術分野であれば、出来るだけ実際に自分で実機検証するようにしています。

メリットとして正確性が増すだけでなく、実機動作やコマンド出力、画面キャプチャーなどをアウトプットに添えることでさらに価値のある発信内容になります。触ることでアウトプットする人自身の理解も深まるでしょう。

自分が実体験したテーマを優先する

自分が机上で調べただけの技術テーマについてアウトプットをしようとすると、実際にその技術を業務などで実体験した人に比べると理解の解像度が大きく劣っていたり、押さえどころのポイントを外していることに気付きづらいケースが増えてしまいます。

なるべく自分が実際にその技術を利用して実体験した分野を優先してアウトプットのテーマにしてみると、受け手にとっても有益な内容になる可能性が高まります。

最低限の概要説明を入れる

結構よく見られるケースだと思いますが、「かなり具体的な技術や機能について検証した記事だが、その周辺分野に触れている人以外からすると何の話をしているのか全く分からない」というアウトプットがあります。(それ自体の是非を評価するものではありません)

これについてはあくまで私の意見ですが、その分野に詳しく無い人が運良く目にしてくれた際に最低限どんな話をしているのか分かるように「どんな技術分野の(プログラミング言語/フレームワーク/プラットフォーム/Webサービス等)どんな用途の機能についての記事だよ」ということをタイトルや冒頭に一言書くだけでアウトプットの可能性がより広がると考えています。

概要紹介がその記事の目的でない場合はあまりリッチな説明に踏み込む必要はないと思いますが、一言加えるだけで記事タイトルやリード文を見て興味を持ってくれる人の割合が増え、その記事の有用性がさらに増すはずです。

自分なりの付加価値をつける

よほど登場ホヤホヤの技術や超ニッチな分野でなければ、今の時代必ず他の誰かが同じテーマについて先行情報を残していると思います。そんな中でせっかくアウトプットをするなら、あなただけの付加価値をつけられれば先行する他のアウトプットと差別化が図れます。

付加価値のつけ方の例:

  • テキストやコマンドの情報を図にまとめて表現してみる
  • 実機で検証した結果を添えてみる
  • 海外の情報を日本語でまとめてみる

アウトプットに付加価値をつける工夫については、こちらの記事でも紹介していますのでよろしければご覧ください。

作成時期や引用元を明記する

ソフトウェアやITサービスは日々アップデートされ変化します。アウトプットを作成した時点では正しかった情報も、時を経て見られた際に誤った内容になってしまうことがあります。

すべてのアウトプットを逐次メンテするのは至難の業だと思うので、最低限いつの時点の情報かが分かるようにしておきましょう。(幸い、Qiitaを含め多くのアウトプット媒体では投稿日や更新日が自動で表示されるものが多いですね)

また、参照した情報源がある場合はソースを添えておくと、受け手が自ら最新の情報を再確認することもできるため有用です。

逆に、受け手側も貢献できること

誤りや疑問は(ポジティブに)伝えてあげる

あなたが受け手としてアウトプットを読んだり聞いたりした際に「この部分、間違ってるかも?」「この説明だと意味が分かりづらいな」と思った点があった場合、ぜひ発信者へフィードバックしてあげましょう。

ただし、お客様気分でぶしつけに「ここ間違ってますけど?」とクレームをつけてしまうと、せっかく時間をかけて悪気なくアウトプットした発信者は気分を悪くし、今後アウトプットをするモチベーションを落としてしまいかねません。

あくまで敬意を払ってポジティブに「発信してくれてありがとう。ただ、この点は誤っている気がするので再確認してみてください」と伝えてみましょう。アウトプットする人はそういったフィードバックも含めて自らの学習のために発信しているはずなので、ありがたく受け取ってくれるはずです。

役に立ったら「良かったよ」をフィードバックする

世の中にはアウトプットが溢れていますが、何か調べものをしてアウトプットを参照して疑問が解消できた場合、そのまま受け手の中で完結してしまうケースは非常に多いと思います。(私も多々あります)

アウトプットが明らかな誤りを含んでいた場合には指摘コメント等がつきやすいかも知れませんが、アウトプットが役に立った・良かった場合のフィードバックというのはかなり得にくいことが多いです。だからこそ、良質なアウトプットには受け手が積極的に「良かったよ」「ありがとう」とポジティブなフィードバックを返してあげることが重要です。

幸いなことに、SNS機能を持つ発信媒体では「いいね」や「スター」等のワンプッシュで発信者に対してポジティブなフィードバックを送れる機能を備えているプラットフォームも多いです。(Qiitaもそうですね)

頑張ってアウトプットした人は、受け手から良いフィードバックをもらえるとモチベーションが上がるのはもちろん、自分のアウトプットの方向性に一定の需要があったことを認識でき、さらに価値のあるアウトプットが増えることが期待できます。

320
110
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
320
110

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?