はじめに

Qiita Tech Festa 2026で、22記事を書きました。

Qiita Tech Festa Sprintの記事投稿期間は、2026年6月1日から7月13日まででした。イベントには、記事数に応じた賞や、スポンサー企業が用意した投稿テーマ、コーヒー・エナドリ・お茶などのチームに分かれて参加する企画がありました。

自分はコーヒー派として参加し、最終的に22記事を投稿しました。

最初から、

アウトプットの本質について考えるために、22記事書こう

と思っていたわけではありません。

20記事を書くとQiitanのぬいぐるみがもらえる。

スポンサー企画では、テーマに沿った記事が賞に選ばれる可能性もある。

せっかくのお祭りなので参加してみよう。

スポンサー賞は、当たれば嬉しい宝くじくらいの感覚で出してみよう。

始まりは、そのくらいでした。

でも、22記事を書くために自分の経験を何度も掘り返しているうちに、アウトプットに対する考え方がかなり変わりました。

以前の自分は、アウトプットを「すでに理解している知識を、他人に説明する行為」だと思っていました。

今は少し違います。

アウトプットとは、自分の中にある曖昧な経験や違和感を、他人も再利用できる知見へ変換する行為なのではないか。

この記事では、Qiita Tech Festaで22記事を書いて感じた、アウトプットに対する考え方の変化を整理します。

以前は「詳しい人が書くもの」だと思っていた

技術記事を書くとき、以前は無意識に高いハードルを設定していました。

ある技術について十分に詳しくなければいけない
誰も知らない新しい情報を書く必要がある
完成度の高いプロダクトが必要
間違ったことを書いてはいけない
誰かの役に立つことが確定していなければいけない

つまり、アウトプットは理解や経験の「完成品」だと思っていました。

何かを完全に理解する。

すごいものを作る。

分かりやすく整理する。

そのあとに、ようやく記事を書く。

しかし、この考え方だと、いつまでたっても書けません。

技術を完全に理解できる日は、ほとんど来ないからです。

新しいことを学べば、さらに分からないことが増えます。

作品を完成させても、改善したい場所が見つかります。

「もっと詳しくなってから書こう」と考えていると、経験は頭の中に残ったまま、少しずつ消えていきます。

22記事を書くために、日常の見方を変える必要があった

1本や2本なら、最近作ったものについて書けば終わります。

でも、22記事となると、それだけでは足りません。

そこで、自分がこれまで経験してきたことを徹底的に掘り返しました。

個人開発で、なぜその技術を選んだのか
実装中に、どこで詰まったのか
ハッカソンや展示会で何を感じたのか
技術イベントに参加して、何を知らないと気づいたのか
プロポーザルを出したとき、何を考えたのか
技術が好きな人たちを見て、どんな違和感があったのか
面接や就職活動で、何を改善したいと思ったのか
自分の作品を、なぜその体験にしたかったのか

ここで気づいたのは、記事のネタがなかったわけではないということです。

自分が、それらを「知見」として認識していなかっただけでした。

大きな成果や珍しい技術だけを記事にしようとしていたため、日常の中にある小さな判断や違和感を見落としていました。

22記事を書くために必要だったのは、22個の新しい技術を習得することではありませんでした。

必要だったのは、

自分が普段何を考え、何を選び、何に迷っているのかを観察すること

でした。

書いた記事を振り返ると、アウトプットの対象が変化していた

今回の記事群を振り返ると、自分のアウトプットは大きく4段階に分かれていました。

段階	主に書いていたもの	記事を書くときの問い
1	作ったもの・参加したイベント	何を作ったか、何が起きたか
2	実装方法・技術選定	どう作ったか、なぜ選んだか
3	経験から得た考え	なぜそう感じたか
4	自分の価値観・未整理の問い	自分は本当は何を考えているか

最初は、自分が作ったものや参加したイベントを外へ見せる意味合いが強かったと思います。

たとえば、GitHubの活動履歴を3D惑星として表現した「GitHub Planet」について、最初の記事では、技術的な説明よりも「なぜ草を惑星にしたかったのか」「展示して何が起きたのか」を中心に書きました。

その後の記事では、同じGitHub Planetを題材にしながら、READMEへの埋め込み、WebSocketによる演出、カードとしての見せ方など、より技術的な部分を説明しました。

同じ作品でも、

作ったものを紹介する
↓
実装方法を説明する
↓
なぜその表現を選んだかを考える

というように、違う角度から記事にできました。

これは自分にとって大きな発見でした。

1つの経験から書ける記事は、1つではありません。

事実、実装、選択、失敗、感情、比較、改善。

見る角度を変えると、同じ経験の中に複数の知見があります。

技術記事は、手順だけではなかった

今回、実装寄りの記事もいくつか書きました。

TextAlive App APIを使った記事では、単に音楽を再生する方法を説明するのではなく、音楽をBGMではなくWeb演出の状態として扱う設計について書きました。

天気APIを使った記事では、取得した天気情報を画面に表示するだけでなく、現実世界の天気をゲーム内の体験へ変える方法について書きました。

ポートフォリオの記事でも、使用技術だけではなく、「見やすいサイト」ではなく「記憶に残る世界」を作りたかったという設計思想を中心に置きました。

これらの記事に共通していたのは、コードそのものより、

なぜこの表現にしたのか
どんな体験を作りたかったのか
なぜ一般的な形では物足りなかったのか
技術を何へ変換したかったのか

という部分でした。

自分は、技術そのものだけに興味があるというより、

技術を使って、機能を体験や意味へ変換すること

に興味があるのかもしれません。

これは、記事を書く前には、はっきりと言語化できていなかった自分の関心です。

複数の記事を並べて初めて、自分の作品や技術選定に共通する思想が見えてきました。

記事は、考えたことの記録ではなく、考えるための場所になった

以前は、

考えがまとまったから記事を書く

という順番を想像していました。

実際に22記事書いてみると、むしろ逆でした。

記事を書き始める
↓
説明できない部分が見つかる
↓
過去の経験や資料を調べる
↓
自分の考えを修正する
↓
ようやく考えが形になる

書く前には分かっているつもりだったことが、文章にすると説明できない。

自分の中では筋が通っていたはずなのに、他人が読む前提で並べると論理が飛んでいる。

「なぜそう思ったのか」を書こうとすると、具体的な経験が足りない。

そういう穴が何度も見つかりました。

自分の考えを文章にする行為は、頭の中にある完成品を転記する作業ではありませんでした。

むしろ、書くことで初めて、考えが組み立てられていきました。

認知科学でも、学習者が自分で説明を生成する「自己説明」は、単に情報を読み返すだけでなく、事例と原理を結びつけ、理解を深める行為として研究されています。

また、振り返りを書くことは、出来事を記録するだけでなく、自分の学習方法や理解の状態を認識するためにも使われます。

22記事を書いたことで起きていたのも、これに近いものだったのかもしれません。

記事は、理解した証明ではありませんでした。

自分にとっては、理解を作るための開発環境でした。

「自分にしか話せない知見」は、意外とたくさんあった

技術記事の独自性というと、

世界初の技術
誰も知らないバグ
高度なアルゴリズム
大規模サービスの運用経験

のようなものを想像しがちです。

もちろん、それらには大きな価値があります。

しかし、自分にしか書けない知見は、それだけではありませんでした。

自分なりに整理すると、独自性は次の組み合わせから生まれます。

一般的な技術
× 自分が置かれていた状況
× そのときの制約
× 自分が行った判断
× 実際に起きた結果
× 後からの解釈

たとえば、React Three Fiberそのものは、自分だけが知っている技術ではありません。

しかし、

なぜ静的な壁紙ではなく、WebGL空間にしたのか
自分のロゴや世界観をどう空間へ落としたのか
個人開発として何を優先したのか
どこまで作ると「自分らしい」と感じたのか

という組み合わせは、自分の経験です。

TSKaigiのセッション内容も、多くの参加者が同じものを聞いています。

でも、

それまで自分がTypeScriptをどう使っていたか
何を分かっていなかったと気づいたか
どの話が自分の経験と接続したか
参加後に何を調べようと思ったか

は、参加者ごとに違います。

自分にしか書けない知見とは、世界で自分だけが所有している事実ではありません。

同じ技術や出来事を、自分の経験を通してどう解釈したか

に独自性が生まれるのだと思います。

個人的な体験を、他人が使える問いへ変える

ただし、「自分にしか書けない」というだけでは、公開記事として十分ではありません。

自分の感情や出来事を、そのまま並べるだけでは日記になります。

Qiitaは、エンジニアが知識を記録・共有するサービスであり、他の利用者が学べる、再利用可能な情報を集める場所だと説明しています。

そこで意識するようになったのは、

自分の経験を、他の人も自分の状況に当てはめられる問いへ変換する

ことです。

たとえば、

「Go Conferenceのプロポーザルに落ちた」

だけなら、自分の出来事です。

しかし、そこから、

プロポーザルは採択されるためだけに出すものなのか
応募する過程で、何が言語化されるのか
落選しても残るものは何か

という問いに変えると、これから応募する人も自分の状況に置き換えられます。

「技術に対する周囲の熱量についていけない」という感覚も、そのままなら個人的な悩みです。

でも、

技術を人生の中心に置かなければ、エンジニアではないのか
他人の熱量と自分の関心を比較する必要はあるのか
自分が長く続けられる距離感は何か

という問いに変えると、似た感覚を持つ人が考える材料になります。

ハッカソンの賞についても、

「賞を取れて嬉しかった」

だけではなく、

賞を取った人が勝者なのか
作品の価値は一度の審査で決まるのか
自分なりの成功条件は何か

まで広げることで、他の参加者も持ち帰れる話になります。

個人的であることと、再利用性があることは、対立しません。

具体的な個人経験から、他人も考えられる問いを抽出できれば、むしろ独自性と汎用性を両立できます。

実装していない構想も、正直に書けば思考の整理になる

22記事の中には、完成したプロダクトの技術解説だけでなく、構想段階の記事もありました。

たとえば、「音楽を交換するように技術記事を交換するサービス」というアイデアを、実装前の段階で記事にしました。

記事を書くことで、

技術記事が多すぎるという課題
検索だけでは出会えない記事の価値
AIによる読む前ガイド
記事を交換する体験
著作権や要約の扱い

など、頭の中にあった断片をプロダクトの形へ整理できました。

Zoom AI Servicesの記事では、面接終了後の90秒の音声メモを、次回の改善タスクへ変換する仕組みを考えました。

これは実装・API検証済みの記事ではなく、入力方法、処理フロー、保存形式、評価方法を整理した設計記事であることを明記しました。

ここでも重要だったのは、「作っていないのに作ったように見せない」ことです。

実装したもの
実際に検証したもの
過去の経験から考察したもの
まだ構想段階のもの

これらを区別して書けば、完成していない考えもアウトプットできます。

アウトプットするために、すべてを完成させる必要はありません。

ただし、どこまでが事実で、どこからが仮説なのかは明確にする必要があります。

賞品目当てで始めてもよかった

今回のイベントを振り返ると、20記事達成の賞品やスポンサー賞がなければ、22記事も書いていなかった可能性があります。

だから、賞品目当てだったことを悪いとは思っていません。

外側にある報酬や締切は、最初の一歩を軽くしてくれました。

「良い記事を書かなければ」と考えるより、

とりあえず祭りに参加してみよう
20記事まで走ってみよう
スポンサー企画にも出してみよう

くらいの方が動きやすかったです。

スポンサー企画には、テーマに沿った記事を投稿し、選ばれれば賞品を受け取れる仕組みがありました。Zoom AI Servicesの企画でも、APIをどのように活用し、開発や自動化へ組み込むかがテーマとして設定されていました。

賞に選ばれるかは分かりません。

記事を出しても、いいねが付かないこともあります。

それでも、普段なら触れなかったテーマについて考える理由にはなりました。

賞品はゴールというより、普段とは違う方向へ寄り道するきっかけでした。

そして、その寄り道の中で、

自分の面接経験
技術記事の読み方
AIとの付き合い方
イベントへの応募経験

など、今まで記事にしようと思わなかった経験を掘り出せました。

外発的な動機で始めたアウトプットが、続けるうちに自分の思考を整理する内発的な行為へ変わっていきました。

それも、イベントの価値だったと思います。

数を書くことで、記事の「最小単位」が変わった

22記事を書く前は、1記事には大きなテーマが必要だと思っていました。

しかし、数を書いていくと、1記事にすべてを詰め込む必要はないと気づきました。

1つの作品があれば、

なぜ作ったのか
どう実装したのか
どんな技術を選んだのか
どこで失敗したのか
展示して何が起きたのか
他の作品と比較して何が分かったのか
次に何を改善するのか

を、それぞれ別の記事にできます。

1つのイベントでも、

セッション内容のまとめ
自分が知らなかったこと
参加前後の変化
交流から得たこと
応募や参加方法
次の行動

という複数の視点があります。

記事の最小単位は「完成した大きな知識」ではありませんでした。

1つの判断
1つの失敗
1つの比較
1つの違和感
1つの問い

でも記事になります。

ただし、小さなテーマだから内容が薄くてよいわけではありません。

小さなテーマを選び、その一点を具体的な経験や検証によって深く掘る。

それが、継続して書くための方法なのだと思います。

量を書けば、すべて良い記事になるわけではない

ここまでアウトプットの良さを書いてきましたが、22記事書けば自動的に技術力が上がるわけではありません。

22記事すべてが、同じ深さや完成度だったわけでもありません。

実装して検証した記事もあれば、経験を整理した記事、構想段階の記事もあります。

今読み返すと、

根拠をもう少し調べるべきだった
技術的な比較が足りなかった
自分の経験を一般化しすぎている
タイトルと内容が少しずれている
コードや実測値を追加したい

と思う記事もあります。

アウトプットが得意であることと、技術理解が深いことは同じではありません。

特に生成AIを使えば、文章の形を整えたり、構成案を作ったり、コード例を生成したりするハードルはかなり下がります。

その結果、「それっぽい記事」を作ることと、「自分が理解した記事」を書くことの差は、以前より見えにくくなりました。

だからこそ、自分に問い続ける必要があります。

このコードを自分で説明できるか
なぜこの設計を選んだのか
他の選択肢と何が違うのか
本当に動作確認したのか
事実と推測を分けているか
AIが出した説明を、自分で検証したか

記事数は分かりやすい成果です。

でも、22という数字そのものが、技術理解の証明になるわけではありません。

量を書くことの価値は、記事数を増やすことだけではなく、

自分の理解の浅さや、思考の癖を発見する回数を増やすこと

にあるのだと思います。

公開することで、自分の思考が外部記憶になる

頭の中だけで考えたことは、時間が経つと変化します。

当時なぜその技術を選んだのか。

イベントで何に驚いたのか。

作品のどこにこだわっていたのか。

失敗したとき、何を改善しようと思ったのか。

数か月後には、結果だけが残り、途中の判断は忘れてしまいます。

記事にすると、その時点の自分の考えが残ります。

そして後から読み返すことで、

当時は何を理解していなかったか
どんなことに興味を持っていたか
同じテーマに対する考えがどう変わったか
以前の自分と、今の自分の違い

を比較できます。

記事は、読者のためだけに存在するものではありません。

未来の自分にとっても、当時の思考を復元するための外部記憶になります。

Gitのコミット履歴がコードの変更を残すように、記事は自分の認識や価値観の変更を残します。

22記事を書いたことで、自分が何をしてきたかだけでなく、

そのとき何を考えていたか

が少しずつ保存されました。

アウトプットは、自分を大きく見せるためだけのものではない

アウトプットには、チャンスを増やす側面もあります。

作品や記事を外へ出さなければ、存在を知ってもらうことはできません。

実際、自分もイベント参加記、個人開発、ポートフォリオ、ハッカソンなどのアウトプットを続ける中で、作品や活動を知ってもらえる機会が増えたと感じています。

ただ、今回22記事書いてみて、アウトプットの価値は「評価されること」だけではないと思うようになりました。

いいねが付かなかった記事にも、書いた意味はあります。

賞に選ばれなかった記事にも、考えを整理した価値は残ります。

他人から見て大きな成果でなくても、自分の理解が一段深くなったなら、それもアウトプットの成果です。

アウトプットは、自分を実際より強く見せるための包装ではありません。

自分が何を理解していて、何を理解していないかを外へ出す行為でもあります。

ときには、未熟さや迷いも見えます。

でも、その状態を残すからこそ、次の変化を確認できます。

22記事書いて、一番変わったこと

22記事書いて、知識が22個増えたかと聞かれると、単純には答えられません。

しかし、確実に変わったことがあります。

それは、日常の経験を見る目です。

以前なら通り過ぎていた出来事に対して、

なぜ自分はこの技術を選んだのだろう
ここで詰まった原因は何だったのだろう
この違和感を持つ人は他にもいるのではないか
この経験から、他の人が使える問いを作れないか
数か月後の自分に、何を残しておきたいか

と考えるようになりました。

つまり、記事を書く能力だけが変わったのではありません。

自分の経験の中から、知見の種を発見する能力が変わった

のだと思います。

おわりに

Qiita Tech Festaに参加した当初の目的は、かなり単純でした。

20記事を書いて賞品が欲しい。

スポンサー賞にも、宝くじ感覚で出してみたい。

コーヒー派として、お祭りに参加してみたい。

そんな動機から始まりました。

でも、22記事を書くために、自分の作品、失敗、イベント、就職活動、技術への距離感、価値観を何度も掘り返しました。

その結果、アウトプットに対する考え方が変わりました。

以前は、

アウトプットは、持っている知識を他人へ渡すもの

だと思っていました。

今は、

アウトプットは、自分の中にある曖昧な経験を、書きながら知見へ変えていくもの

だと思っています。

自分にしか書けない知見は、特別な技術や大きな実績の中にだけあるわけではありません。

日常の小さな選択、失敗、違和感、比較、迷いの中にもあります。

それらを具体的な経験として書き、他の人も考えられる問いへ変換する。

それが、自分にとってのアウトプットになりました。

22記事を書いたことで得た最大の成果は、22という記事数ではありません。

「これは記事になるかもしれない」と、自分の経験を見る目が変わったこと。

それが、今回のQiita Tech Festaで得た一番大きなものだったと思います。