はじめに
2022年3月にQiitaを始めて10ヶ月、今月初旬に1,000Contributions1を達成したので、ここまでの振り返りをしてみようと思います。2
10か月間で書いた記事たち
全12記事書きました。
各記事のViews数および付けていただいた いいね や ストックの数、受賞歴などをまとめてみました(2023/02/27 23:00時点)。
スマホで見たときにグリッドが破滅的に見づらかったので折り畳み形式にしました。
興味のある方はぜひ開いてみていただけると。
投稿記事一覧
投稿日 | タイトル | Views | いいね | ストック | Note |
---|---|---|---|---|---|
2022/03/04 | コーヒーショップの例をベースにAWSの勉強をしていったらクラウドプラクティショナーに合格した話 | 5,511 | 27 | 24 | Best Qiita賞(社内月間賞)受賞 |
2022/05/08 | はじめてChrome拡張機能を作ったので、作り方と公開までの流れをまとめる | 16,613 | 54 | 68 | |
2022/06/12 | Tips:Eclipse上のファイルをWindowsエクスプローラーで開くショートカットキーの割り当て方 | 1,251 | 5 | 1 | |
2022/07/03 | JUnit未経験者がテストコードを書ききるためにまずやったことと、初心者的悩みポイントを逆引き解説 | 18,883 | 66 | 58 | |
2022/07/16 | Remote Test Kitの実務での使い方と所感 | 4,111 | 14 | 2 | Qiita Engineer Festa 2022 Remote TestKit 優秀賞 受賞 |
2022/08/20 | がんばりすぎない時間の作りかた・使いかた | 32,687 | 252 | 178 | |
2022/08/29 | 易しい言葉でめった刺しされる一冊に出会った | 23,727 | 105 | 88 | エンジニア夏休み企画! ピックアップ記事選出 |
2022/10/05 | テキストエディタを使ってWeb画面から雑にコピーした残念リストをシンプルきれいなリストにする | 6,066 | 11 | 10 | |
2022/11/26 | PCのObsidianで作成したノートをGitHub経由でiPhoneへ同期する | 8,141 | 19 | 18 | |
2022/12/13 | いまさら訊けないバッチ実装の心得 6選(超基本編) | 4,236 | 25 | 14 | |
2022/12/20 | 仕事と子育ての間隙を縫ってAWS SAA-C03に合格するまでの2か月ちょっとでやったこと | 7,336 | 26 | 9 | |
2023/01/23 | サクラエディタをもっと使いやすくするために最初にやる6つのこと | 22,969 | 135 | 154 | Best Qiita賞(社内月間賞)受賞 |
1度でも私の記事を閲覧いただいた方、いいねやストックをしてくださった方、本当にありがとうございます!
そして、月に1回くらいの頻度で書けたらいいな~という当初の目標を10か月間達成し続けているので、全力で自分を褒めてあげようと思います。えらいぞ私!
継続できた理由
もともと文字ベースでのアウトプットに抵抗がなかったのに加え、記事を継続的に閲覧いただいたり、その際にいいねやストックをしていただけたりというリアクションを受けられるのは大きいです。
自分でお題を見つけづらいときは、Qiita Engineer Festa、アドベントカレンダー、月間テーマへ参加をすることで、お題のヒントを得たり、投稿機会を作ったりもしました。
そういった中で時折社内外の賞を受賞できたり、ピックアップしていただけたり、想定以上に多くのいいねやストックをいただける記事があったことも、ここまで地道に続けられた理由の1つだと感じています。
Views・いいね・ストックとは?(個人解釈)
Qiitaで記事を書いていると、どうしても気になりますよね。
私はそれぞれ以下のように捉えています。
- Views:タイトルやタグに惹かれてとにかく見に来てくださった総数。興味を持ってもらえた方の数
- いいね:文字通り「いいじゃん」と思ってもらえたもの。一過性のもの
- ストック:読み返したいもの、リファレンスと捉えてもらえたもの。その時々の必要性に応じて付け外しされるもの
これに当てはめると、
Viewsの数はそれだけタイトルを読んで興味を持っていただけたということだし、
いいねがついた記事は一読して「いいじゃん」と思っていただけたということだし、
ストックされた記事はあとから見返す価値があると判断していただいたということです。
うれしいですね!
そうは言っても、時間がなくて後で読むためにストックしてそのまま・・ということもあるとわかっていますし、冒頭だけ読んでブラウザバックされる場合があるのもわかっています。
また、それ以前に書いた記事を全然見てもらえない、いいねやストックが付かないということも当然あります。
私も始めたばかりのころは、いいねやストックの数、気になっていました。
けれど、途中からあまり気にならなくなりました。
ふと記事を見返してViewsが伸びていたり、いいねやストックの通知が来たときだけ都合よく喜んだり、驚いたりしています。
なぜあまり気にならなくなったのか。
自分がどんな目的で記事を書くかを意識しておくことが大事
Views・いいね・ストックと都合よく付き合っていくためには、何が書きたいのか?
誰に向けた記事なのか?
を念頭に置きながら記事を書くのが大事だと感じたからです。
そしてその指標として、Views・いいね・ストックを活用するといいと気づいたからです。
以下は一例です。
-
何が書きたいのか?
- 初心者がゼロから何かを成し遂げるまでのハウツー
- ピンポイントな悩みを解決するためのTips
- 合格体験記
- ポエム
-
誰に向けた記事なのか?
- 検索して見つけてくださった方
- 社内の同僚
- 未来の自分
大前提として、Views・いいね・ストック、すべて嬉しいです。
そのうえで何が書きたいのか?
によって、Views・いいね・ストック、それぞれどのように推移してほしいかを考えます。
上記の例だと、
-
初心者がゼロから何かを成し遂げるまでのハウツー:
ストックしてもらえたらうれしい。後から見返してほしいものだから。ただ、初心者を抜けたタイミングでストックから外すはずなので、増減あるはず(何もしなければ情報が古くなって緩やかに減っていくはず) -
ピンポイントな悩みを解決するためのTips:
いいねがついたらうれしい、ストックも同じように伸びたらより有効な記事だったと判断(困りごとを解決できたときにいいね、忘れたときに見返せるようにストックしてもらえるという想定から) -
合格体験記:
ハウツー同様、ストック数が増減するもの。合格したら不要になるはずだから -
ポエム:
View数があるだけでうれしい。いいねが伸びたら何か感じていただけたとのことで御の字
加えて誰に向けた記事なのか?
によっても想定が変わります。
-
検索して見つけてくださった方:
定期的にいいねやストック数があったら、誰かの役に立てている証拠。万々歳 -
社内の同僚:
同じOrganizationに所属するメンバーからいいねやストックがあったら成功。この目的の場合、併せて社内でLTを実施したり、社内Slackなどで反応を併せて確認することも -
未来の自分:
Views・いいね・ストックの数はそもそも気にしない。未来の自分が想定読者だから
これに当てはめて記事を振り返ってみると、概ね想定通りにリアクションをいただけているので、各記事の目的が達成できているなと感じます。
で、あまり閲覧数などが伸びていない記事があった場合でも気にしない理由というのが、そもそもほぼすべての記事が未来の自分に宛てたものだと認識したからです。
記事の多くは自分が躓いた内容やその時の所感で、未来の自分が過去にやったことを忘れてしまっても困らないようにするための、ちょっとした布石だったりもします。
そうなると、すべてViews・いいね・ストックの数は気にしない。未来の自分が想定読者だから
に当てはまります。
ついでに他の人のお役に立てたなら何より、という心構えになります。
そうなってくると、誰かが見てくださっているだけでうれしいし、いいねやストックされたら狂喜乱舞ものです。
ありがたいことに今まで閲覧数0ということはなかったので、(過去の自分も含めて)誰かが見てくださっているということですし。
Views・いいね・ストック=記事の価値 ではない
ある技術に特化した話はその分読者の母数が少ないので、Viewsとしては伸び悩んで見えますし、いいねやストックも付きづらくなります。
逆に、ポエムや読書感想文などは、間口も広いうえにタイトルもキャッチーにしやすく、いいねなどが比較的付きやすいのは自然かなと思います。
なので、これらの数には一喜一憂しすぎる必要はありません。
・・・半分嘘です。先に書いた通り、普通に喜びはします。うれしいものはうれしいので。
でもたとえそこまで伸びなくても憂うことはないです。1人でも見てくださればうれしいですし、たとえそれが数年先だったとしても、誰かの役に立てるのであればこんなに幸せなことはありません。
こうやって都合よくViews・いいね・ストック振り回されていくと、気負いせずにアウトプットを続けられるんじゃないかなと思います。
目に留まる機会が多いのはOrganizationに恵まれているという一面も
Organizationに所属し、定期的に記事を書いたり、記事を読んでいいねやストックをしてくれるメンバーや、それを応援してくれる組織に恵まれると、多くの方の目に留まる確率は格段に上がると確信しています。
いいねがついているものにはアクセスしてみようかなと思うのが人の心だからです(ですよね?)。
なので私はとても恵まれているな~と常日頃感じています。
定期的なアウトプットの効用
月に1回くらいの頻度で何かアウトプットしてみよう、と思い立ってから10か月、振り返ってみるとよかったことがたくさんあります。
霧散している思考を掘り下げたり、整理したりする機会を増やせる
アウトプットのためには手順や思考の整理が不可欠です。
頭の中だけで考えていると、自分が思っている以上に内容がまとまっていません。
アウトプットを目標に脳内を整理してみると、記事が書けるだけでなく、その話題について誰かと話すときに、持論を自分自身が理解した上で話すことができます。
未来の自分の役に立つ
一定期間アウトプットを続けてきて、記事一覧を見返してみると、その当時自分が何をしていたかがわかり、振り返りがしやすいです。
また、すべて未来の自分に宛てた備忘録の側面があるので、数か月後に「あれどうやったんだっけ・・?」「このトピックに関してまとめたことあったな・・・」というとき、過去の記事を漁ると出てくることが多いです。
ある程度体系立てて書いているおかげで、資料作成時やメンバーとの雑談時にリンクを送れば内容を共有できるのってすごく楽です。
自分以外の記事を読む機会が増える
Qiitaにアクセスする習慣がつくので、他の方が書いている記事を読む機会が圧倒的に増えたなと感じます。
アウトプットの手段はなんでもいい
アウトプット方法の得手・不得手はあるので、別に文字ベースでなくてもいいと思います。
私はしゃべるよりも文字を書く方が好き3なので、記事を書くというアウトプット方式を選んでいるだけです。
なので、人に話すという形式がアウトプットとして向いていると感じるのであれば、プレゼン形式もラジオ形式もいいと思います。
社外向けが緊張するということであれば、Qiitaでなく、社内メンバー向けのドキュメントもいいと思います。4
アウトプットを躊躇う=他者のインプット機会を奪っているかもというマインドで
アウトプットの方法は問わないです。でも、自分の書く内容なんて価値ないかも・・・誰も読まないかも・・と、世に出す前から閉じてしまうのはもったいないなと思います。
私もそんな気持ちを抱えつつ、「まあ未来の自分に宛てたものだし・・・」という気持ちで世に出した記事が、予想に反して多くの方に見ていただけて度肝を抜かれる、ということが何度かありました・・・
何が世の中の役に立つかわからないので、まずは世に出していただけるとうれしいです。
このあたりの話や、アウトプットはいいぞという内容で、すごく好きな記事を以下に挙げておきます。
おわりに
以上、1,000 Contributionsを節目として、Qiita事始めから現在まで投稿を続けてみての振り返りと、所感を書いてみました。
色々書いたけれど、始めてみるとシンプルに楽しいので、これからアウトプットをする方がもっと増えるといいな~
案外「記事を投稿する」ボタンを押すときが1番緊張して、でも押してしまうと達成感が優ってきますよ!
推敲は公開後でも続けていけますし、読んでくださった方からのコメントをもとに、より質の高い記事にしていくこともできますし。
私もViews・いいね・ストックに都合よく振り回されつつ、マイペースにアウトプットを続けていこうと思います。
おまけ
1,000 Contributionsでメンションいただいた際、私事でうれしかったツイートをしたので載せておきます。
-
今までContributionの定義やカウント方法などをちゃんと知らなかったので、改めて検索してみました。検索結果筆頭にQiitaヘルプのContributionとはのページが表示されました。簡潔かつわかりやすく説明がされているのでそちらをご参照ください。 ↩
-
1,000 Contributionsで騒ぐなよ、とお思いの方もいらっしゃるかもしれませんが、Qiitaのいろいろランキング2022によると、1年間で1,000以上のControbution数を上げていらっしゃる方は全ユーザー中の0.2378%だそうです!1つの大きな節目ということで大目に見てください ↩
-
たぶんしゃべるのもそこそこ好きなんですが、LTとかになるとなかなかに緊張しがちです ↩
-
社内向けと社外向けの棲み分けを考えたうえで選択できるのが理想ではと考えています。自社業務特化、製品コード特化の内容なら社内向けとして、そうじゃないなら極論すべて社外向けとして書けないかを模索してみるのがいいのではとも。 ↩