はじめに
こんにちは。楽楽勤怠のバックエンドを担当しているkoyaです。
約二年前、あるきっかけからQiitaに記事投稿を始めました。
最初は毎週書こうと決めていたわけではありませんが、 気づけば毎週投稿するようになり、いつの間にか100週が経っていました。
振り返ってみると、続けてきた中でいろんな気づきがあり、自分自身も少しずつ成長できたように感じます。
この記事では、その間のことを少し振り返りながら、
書くことを続ける中で感じたことをまとめてみようと思います。
入社当初の焦り
2023年7月、私はバックエンドエンジニアとしてラクスに中途入社しました。 入社して最初に感じたのは、周りのエンジニアが持つ知識や考え方の幅の広さです。
前職で担当していた領域にはある程度対応できましたが、 新しい環境では扱う技術の幅が一気に広がり、アーキテクチャの考え方や開発プロセスなど、これまで経験してこなかった領域に触れる機会が増えました。 最初のうちは、新しい概念や技術が次々に出てきて、ミーティングの内容を理解するのにも時間がかかるような状態でした。
当時メンターをしてくれていたのは、新卒2年目の社員の方でした。 分からないことを質問すると、どんな問いにもすぐに明確な答えが返ってきて、その知識量や理解の深さに驚くと同時に、 「このままではまずい」という焦りの気持ちが次第に強くなっていきました。
とりあえずで始めた記事投稿
焦った私は、とにかく何か行動しないとと思いました。
勉強はしていたと思います。技術書も読んでいたし、実際に手で動かすということもしていたつもりです。 ですが、“身についている実感”があまりなく、読んだ内容を翌日には半分忘れていて、いざ会話になると説明できない—— そんなことの繰り返しでした。
また、社内には、技術が好きで、実力のある方々がたくさんいます。 「このまま同じ勉強方法を続けても、たぶん今の差を埋めることはできない」 そんな感覚がありました。
そうした感情の中で始めたのが、Qiitaへの記事投稿です。
正直なところ、深い理由があったわけではありません。
「アウトプットは大事」とどこかで聞いたことがあって、 何か形に残ることをしていれば、少しは安心できるかもしれないと思ったというのが本音です。
今思うと、記事投稿は結果的に自分に合っていたのだと思います。
大きな苦もなく続けられたのは、書き終えたときの達成感や、反応をもらえたときのちょっとした喜び、そして少しずつ実力がついていく実感といったポジティブな要素が、アウトプットの負担を上回っていたからです。
楽しさが負担を超えていたからこそ、自然と継続することができました。
毎週投稿の決意、そのためのルール
書き始めて数週間が経った頃、投稿を週1で続けていることに気が付きました。
Qiitaには「バッジ」という機能があり、毎週連続で投稿すると、その週数に応じたバッジがもらえます。
当時は50週が上限だったので、「まずは50週連続を目指そう」と目標を立てました。
毎週投稿を続けるにあたって、自分の中でいくつかルールを決めました。
どんなに短くても書く
書き続けているうちは順調でも、一度手を止めてしまうと、そのまま書かなくなるかもしれないという不安がありました。
目的はあくまで「実力をつけること」ですが、書かなくなることが一番の遠回りだと思い、とにかく手を止めないことを最優先にしました。 そこで、「どんなに短くてもいいから、毎週必ず書く」というルールを設けました。 内容の深さよりも、“書き続けること”自体に価値を置きました。会社のOrganizationには入らない
QiitaにはラクスのOrganizationもありますが、私はそこに所属していません。 「どんなに短くてもいいから書く」というルールと、会社名が並ぶことへの責任の重さが相反しているように感じたためです。 「こんな内容で出して大丈夫だろうか」 「もし間違っていたら会社に迷惑をかけてしまうかも」 そんなことを考えると、気軽に投稿できなくなってしまいそうでした。 そこで、プレッシャーを感じずに自由に書けるよう、個人として投稿することを選びました。
こうして決めたルールのもとで記事投稿を続けてきました。
途中でQiitaのバッジ上限が100週に引き上げられたこともあり、50週を達成したあともそのまま継続。
気づけば、今も習慣として続いています。
記事投稿をする中で得た気づき
投稿を続けたことでとで、以下のような気付きを得ました。
1. アウトプットできるかどうかが理解度の物差しとなる
Qiitaを書き始めた当初は、とにかく一つの記事を書くのにすごく時間がかかりました。 「簡単な内容だからすぐ書けるだろう」と思っていても、実際に手を動かしてみるとまったく違います。
まずは知りたい内容を調査して、手元で検証して、それを整理してまとめる。
この一連の流れだけでも思っていた以上に大変で、特に理解が浅いとそもそも記事としてまとめられないということに気づきました。
逆に、何度も調べ直して試行錯誤しながら、ようやく一本の記事として書き上げられたときは、 そのテーマについて人に説明できるレベルまで理解できていることが実感できました。
この経験から、「アウトプットできるかどうかが、自分の理解度を測るバローメーターになる」ということを強く意識するようになりました。 書けないということは、まだ理解しきれていないというサイン。 書けるようになったら、それは確実に自分の力になっている証拠。 記事を書くという行為は、自分にとっての「理解の物差し」そのものになっていきました。
2. 書けない週はインプットが少ない
焦りから始めた記事投稿でしたが、最初の気持ちをずっと保ち続けるのは簡単ではありません。
モチベーションが上がらない時期もあり、そういうときは記事のネタがなかなか思いつきませんでした。
しかしある時、「書けないのはモチベーションが低いからではなく、インプットが少ないからだ」と気づきました。
定期的に記事を書くことをルールにしておくと、書きづらさそのものがインプットの少なさを示してくれます。
逆に、すらすら書けるときは、それだけ知識が新しく、理解が整理されている証拠です。
いつの間にか、「記事を書くことはインプットの量を測る物差し」としても機能し始め、 記事が書きづらいという感情から、インプットの不足を早めに察知できるようになり、結果として「気づけば最近全然勉強してないな」という状態を防ぐことができました。
3. アウトプットを前提に学ぶことの大切さ
毎週の記事投稿を続けているうちに、少しずつ記事を書くスピードが上がってきました。
最初の頃とは違い、一本の記事を書き上げるまでの時間が目に見えて短くなっていったのです。
その理由は、「アウトプットを前提に学ぶという習慣が自然と身についていた」からでした。
調査や学習の段階から、
「これをどう言語化しよう？」
「文章にするとき、どんな順番で説明すれば伝わりやすいだろう？」
といったことを意識するようになりました。
その結果、学びながら理解を整理するクセがつき、“分かっていない状態で書き始めて詰まる”ということが格段に減りました。
書き始める段階では、すでに頭の中で構成ができているため、筆をとったらそのまま最後まで書き切れることも多くなりました。
「書くために学ぶ」から「学びながら書く」へ。
このスタイルに自然と変わっていったことで、アウトプットの効率も質も大きく上がったと感じます。
さらに、この習慣は業務にも良い影響を与えました。
会話の中で内容を整理しながら聞き、理解したことをその場で言語化して確認することで、認識の齟齬が減り、コミュニケーションの精度が高まったと感じています。
これもまた、「アウトプットを前提に学ぶ」姿勢の成果だと思います。
記事投稿を継続したいま、思うこと
あらためて自分の書いた記事の一覧を見ると、「たくさん書いたな」としみじみ感じます。
転職したばかりで自信を失いかけていた自分にとって、努力の軌跡が記事という形で残っていることは、大きな支えとなっています。
記事を書く過程では、思い通りにいかないことも多く、何度も試行錯誤を重ねました。
AIに質問したり、公式ドキュメントを読み込んだり、OSSのコードを追ったり——
記事投稿を始める前にはほとんどやってこなかったことを、今では自然と行うようになりました。
そうした試行錯誤の中で身についた「トラブルシュートの力」は、今では業務でも確実に活きていると感じます。
焦りから始めた記事投稿は、いつの間にか日常になりました。
「ローマは一日にして成らず」
もちろん、まだ道半ばですが、小さな積み重ねが確かに今の自分を作ってくれていると感じます。
おわりに
これまでたくさんの記事を書いてきましたが、こうした“ポエム系”の記事を書くのは今回が初めてでした。
なかなか筆が進まず、「記事投稿を続けてきて自分は何を得たのか」を、実はこれまできちんと整理できていなかったことにも気づきました。
書き終えたいま、日々の積み重ねが自分に与えた影響の大きさを、あらためて実感しています。
もちろん、万人に合うやり方ではないかもしれませんが、もし当時の自分と同じように悩んでいるエンジニアの方がいたら、この経験が少しでも参考になれば嬉しいです。
最後に、自分のQiitaアカウントを紹介します。
気になった記事などありましたら、ぜひご覧ください。
ここまで読んでいただき、本当にありがとうございました！
