
プログラミング
イベント
マガジン
技術ブログ
前回は、アウトプットがなぜ「強力な学習手段」なのかについてお話ししました。アウトプットをゴールではなく「インクリメント」として捉え、リズムを決めて始めることが大切だ、というところまで整理しました。 今回は「では、具体的に何をどう書けばいいのか」という話に踏み込みます。 記事一覧:【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由:「完成品」を手放して最初の一歩を踏み出す [全文公開中] 【第2回】社内の仕事が記事になる瞬間:実践知を言語化する型と習慣 「何を書いたらいいか分からない」問題 アウトプットの意義は理解できた。リズムを作ろう。そう思ったものの、いざ書こうとすると手が止まる。多くの人がぶち当たるのが「何を書いたらよいかわからない」という壁です。 エンジニアブログのようなコンテンツでは、以下の3点を基本構成として意識するのがおすすめです。 目的 :解決したいイシューや背景 実際に取り組んだこと :起きたことなどの生の体験、一次情報 そこから得られた学び :分かったことや教訓 この「目的・取り組み・学び」の3点セットを型として持っておくと、書くべきことが自然と見えてきます。 この構造は、研究論文の報告形式であるIMRaDや、軍発祥の振り返り手法「After Action Review」にも通じるものがあります。学術の世界でも実務の世界でも、「伝わり、再利用される知識の形」として効果が認められてきた構造です。 一次情報の価値 ここで強調しておきたいのが、一次情報としての具体的な体験の価値です。 個別具体のケーススタディや取り組みなど、実際に手を動かした生の体験そのものに大きな価値があります。しかし、これを抽象化・一般化すると、どこかで見たことのある情報になっていきます。著名人や書籍がすでに語っている内容と大差がなくなり、「自分が書く意味」が薄れてしまいます。 今の時代、一般的な知識や情報はAIに聞けば手に入ります。書籍の要約も、技術的な概念の解説も、AIが十分にカバーできるようになりました。しかし、個別具体のケーススタディはあなただからこそ書ける情報です。具体的であるからこそ、読者が自分の状況と照らし合わせて参考にできるリアリティがそこにはあります。 だからこそ、まずは自分が実際に経験したことをそのまま書く、ということを意識してください。 ただし、実際に行ったことを時系列に並べるだけでは不十分です。何のためにそれをやったのか、どのような結果になり、どんな学びが得られたのかという情報がなければ、読者にとって価値のある記事にはなりません。先ほどの型(目的・取り組み・学び)を意識しましょう。 仕事と発信を「1サイクル」にする この「型」を、日々の業務やプロジェクトなどの区切りの良い単位で実践してみてください。仕事が一段落したら、その概要や取り組み、学びを振り返る形でブログ記事にまとめる。この一連の流れを「仕事の1サイクル」として捉えることから始めてみましょう。 仕事と発信をセットで捉えるようにすると、アウトプット駆動で仕事に取り組む意識が芽生えてきます。常に読み手・聞き手を意識し、自分の活動の意義や狙いを言語化しようとすることは、発信の質を高めるだけでなく、日々の何気ない業務の中に新たな気づきをもたらします。「これ、どう説明するんだろう」と考える習慣が、仕事そのものを深める。これが、発信と実践を循環させることの本質的な価値だと思います。 私自身の経験を二つ紹介します。 一つ目は、スクラムマスターとして参加していたチームでの話です。レトロスペクティブ(振り返り)で議論している中で、チームとして重要な気づきが得られることがありました。「この学びは社外にも共有できるのではないか」というアイデアが自然と生まれ、次のスプリントのアクションアイテムとして「気づきをブログにまとめて発信する」というアクションにつながったこともあります。 二つ目は、マネージャーとしてスクラムマスターのメンバーと日々の1on1をしていたときのことです。最近の取り組みや悩み、そこからの学びを聞く中で、「これは他の人にとっても参考になりそうだ」と思ったものについては、「アウトプットしてみませんか?」と提案するようにしていました。 また、あるチームではスプリントの最終日を「アウトプットデー」と定め、スプリントレビューでのデモ準備と並行して、そのスプリントでの学びをブログ記事としてまとめるという活動を行っていました。 このように、日々の業務の一部としてアウトプットを組み込んでいくのがおすすめです。アウトプットによる自己変容は、筋トレに近いところがあります。1回やれば恒久的に変わるものではなく、適切な強度の取り組みを定期的に繰り返すことで、少しずつ鍛えられていくものです。だからこそ、仕組みを整え、一度きりではなく継続的な営みとして回していくことが大切です。 フィードバックを活用する 書き上げたら、一人で抱え込まず、積極的に他者からフィードバックをもらいにいきましょう。 他者によるレビュー は、最も直接的な方法です。上司や同僚に実際に読んでもらい、違和感のある表現や、解釈がぶれるような点を指摘してもらいます。他者がどのように解釈するのかという情報は貴重ですし、フィードバックを受けてブラッシュアップすることで、記事の質が高まり、自身の学びもより豊かなものになります。 生成AIの活用 もぜひ検討してみてください。私自身、執筆活動全体でAIをフル活用していますが、おすすめの使い方は大きく3つあります。 まず 執筆前の壁打ち です。書きたいネタは断片的に頭の中にあるものなので、「こんな記事を書きたいのだけど、対象読者と持ち帰れる学び、骨格となる論点の整理を手伝ってほしい」とAIに相談し、アウトラインを整えていきます。 次に 執筆中のペアライティング です。AIエディタを使い、ペアプログラミングのような感覚で一緒に書き進めます。コツは、AIをただの作業者ではなく、有能な同僚のように扱うことです。例えば、「このセクションは冗長だから削除して」とただ指示するのではなく、「このセクションは冗長に感じるのだけど、どう思う?」と聞く。するとAIは文章全体を踏まえて「このセクションには構成上こういう役割があるので、簡略化した上で位置を調整するのがよいのでは」と提案してくれたりします。 そして 書き上げた後のレビュー です。まず論点としての大きな穴や全体の整合性をチェックしてもらい、全体の構造を整えてから日本語のブラッシュアップに入る、という順序がおすすめです。 ただし、執筆そのものをAIに任せるのはおすすめしません。前回触れた通り、構成を考え、言葉を選ぶプロセスそのものが学びの核です。あくまで自分で書き、AIは壁打ちとレビューのパートナーとして活用するのがよいバランスだと思います。 「マサカリ」への備え方 フィードバックを経て公開する際、「ツッコミが怖い」という懸念もあるかと思います。私自身も昔は、不用意な記述によっていわゆる「マサカリ」が飛んできて苦い思いをしたことが何度もあります。 ツッコミが入りにくい発信の仕方を身につけることが大切です。これについては「 防御力の高い技術ブログを書こう 」という記事が非常に参考になりますので、ぜひご一読ください。 私が個人的に意識しているのはシンプルで、 読み手の感情的な反射を引き起こさないよう配慮する ということです。具体的には以下の2点です。 事実と解釈を明確に区別する 特定の人・組織・ツールを名指しで批判するような表現を避ける メリット・デメリットの比較が必要な場合は事実として淡々と行い、感情的な反応を引き起こしやすい表現を控える。読み手が最後まで冷静に読めるよう整えることが、アウトプットをする上での誠実さではないでしょうか。 まとめ 書き方の型を持ち、フィードバックを取り入れながら続けていく。それだけで、アウトプットは確実に仕事の質を底上げしていきます。 ここまで2回にわたって、アウトプットの意義と実践的な書き方についてお伝えしてきました。次回は少し視点を変えます。テキストのアウトプットに慣れてきたら、次は「外の世界」に出てみましょう。コミュニティやカンファレンスでの登壇・発表も、アウトプットの一形態です。そこで得られるフィードバックの質と量は、ブログとはまた異なります。外に出ることで検査と適応のサイクルがどう広がるのか、次回お話しします。 【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由:「完成品」を手放して最初の一歩を踏み出す [全文公開中] 【第2回】社内の仕事が記事になる瞬間:実践知を言語化する型と習慣 The post 【第2回】社内の仕事が記事になる瞬間:実践知を言語化する型と習慣 first appeared on Sqripts .
はじめに 本記事は、先日開催された「RECRUIT TECH CONFERENCE 2026」より「和田卓人氏と語る、"開発現場"の
ABEMAの広告配信システムのバックエンド開発を担当している黒崎 ( @kuro_m88 )です。 ...


























