📝

25日完走した感想と、今からQiitaアドベントカレンダー2023に向けてのテーマ・抱負

2023/08/29に公開

お詫び

Qiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。
全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。

完走した感想

Q. アドベントカレンダー2022の当初のモチベーションと今のモチベーションが変わったか？

A. 変わりました。

当初は

反省：準備が大事

今回、記事が難産だった事より体調不良に苦しめられました。
精神的なものなら事前準備するぐらいしか緩和策が思いつかないんですが、カゼから始まったものでした。
まさかここまで悪性が強いとは思いませんでしたが、これ本業だけだと最悪、納品さえ間に合わせられれば何とかアフターフォローで挽回できますが、副業（今回はアドベントカレンダーが該当するものと考えてください）の場合が大変です。
実際の案件だとカゼや身内の不幸は当たり前ですが言い訳になりません。ブラック企業とかそういう話ではなく、事業主だと会社間での取引になるので、損害賠償が発生する可能性があります。

本題から外れますが、大事な話なので触れておきますね。
やむを得ず個人事業主になる場合でも、契約時に再委託の可能性を残しておくか、再委託禁止を盛り込まれる場合はやむを得ない理由での取引遅延については交渉の余地を残すようにしましょう。
今回は広報も宣伝もしていませんし、Qiitaのアドベントカレンダーを書くだけの話なので遅延損害もありませんでした。
その結果として体調を優先する事ができましたが、実際は再委託の交渉あるいは遅延時の取り決めをしているところです。

Qiitaの仕様も研究しておくべきだった

嬉しい誤算なのですが、Qiitaのリンクカード（正式名称をど忘れしてしまったんで、意図が伝わってほしい）が非常にリッチだったのでリンク関連は改行しておけばよかったです。
また、

:::note
この書き方
:::

関連はQiita独自記法だったので避けていましたが、置換自体は難しくなかったので組み込めば他の場所でも活用できたはずです。
執筆するまで完全に忘れていましたが、見やすくなる機能があるなら使っていくべきでした。
なお、アコーディオンの書き方はhtmlタグで頑張っているので、これはこちら側の仕様の問題で諦めました。
あまり有効活用するシーンもなかったので、大きな障害にはなっていないのが救いでしょうか。

ネタバラシ：初動の進め方

「要件は確定してないけど、多分これやらないとダメだから先行して実装しておこう」というプロダクト推進をするチームの経験が多かったため、初日から翌日などの記事をぼちぼち書き進めていったんですが、今回はこれが活きました。
初日までに25日分（当時はその想定だった）の記事のネタを決め、初日から一週間までに25日分の書き始めと書き終わり、やりたい事だけ箇条書きなりやりやすいスタイルで書くだけ書いて、後は上から順番につなげていくだけの作業をする予定でした。
これは私がアフィリエイター時代に培った、独自流のやりやすい記事の書き方のスタイルなので人によってやり方は変わりますが、とりあえず方針が決められたのです。
このやり方で私が一番苦労するのが、このつなぎ合わせの作業で不自然な部分を消していくという工程を繰り返していく事になります。
なぜこの方法を採用しているのか、というと記事にも納期がある事が挙げられます。

しっかりとした記事を書き上げるために書き上げた直後の状態を叩き台原稿
１日時間を置いて繋ぎこみの甘さを是正した推敲原稿
レビュー（セルフの場合、自身で記事を読んだ感想を踏まえて期待する結果と異なる部分の書き直しなど）を経て公開している完成稿

といったステップを踏んで品質を上げていくやり方をしているので「とりあえず納期までに出す」を叩き台原稿でできるのが強みです。
と、同時にデメリットとして進捗状況（記事の書きやすさ）によって露骨に品質に差が出ます。
初見だと比較ができないのですが、ソロのアドベントカレンダーという性質上、記事を読んでいくとどれがどの段階なのか透けやすいです。

問題点

当初単発記事として書こうとして、結局ネタ不足になって書ききれなかった記事たちを「まとめ」として供養しました。

余談：AIに記事を書かせて校正する方法は現実的か？

正直、毎日投稿を前提にする場合は本稿レベルのボリュームですら書き続けるのはちょっとした苦行です。

AIのべりすとのようなサービスあるいはツール（AI）を作って書かせて、まずい部分を修正する方が作業としてはラクだったりしますが、既に出来上がった文章自体がそもそも使い物になるのか？という観点で見てみると単純に作業工程が増えるだけになってしまいます。
いわば「人が書いたテキストを修正して投稿する」という作業が考えている以上に重労働である事に理解があると、１から自分で書いたほうがマシなシーンもあったりします。
それが、自分が苦手な分野の記事を投稿するケースだったりするとつらいですね。

本アドベントカレンダーの縛り

実は、今回のアドベントカレンダーはなるべくコードを書かない事を意識しました。
実際は業務の都合上、ほとんど書けないものばかりだったので、ポエムの傾向に寄ってしまいました。
これは予想通りというか、反省すべき点でもあります。
なるべく実績ベースの話になるようにしていたのですが、NDAの関係もあり最新のお話が難しいものやデータを開示できないものが多かったために体験談に説得力を持たせるために解説や事例紹介を盛り込みました。
しかしながら、根本的な問題であるノーデータであるという点は変えられないため、アドベントカレンダー内でも講師向け、あるいは受講者に向けて書く傾向を増やす＝ボリュームアップで対応しています。

自分が主張したい事はきちんとデータを示しましょう。
データを示さず（示せず）に主張すると、当たり前ですが非常に苦労します。
今回は私が書いている話ですが、いざ自分がデータを示せずに主張したい内容があったとすると、相当苦労する事は容易に想像ができるかと思います。
いざ記事を書いてみると、想像以上に大変だと言うことにも気付きました。
何より、表現の仕方に恐ろしく気を遣うので難産になる傾向があります。今にして思えばそりゃそーだと思うんですが、決して楽ではなかったです。
一番主張したい内容と、解消できない根拠不十分な状況を少しでも解決したい思いで空回りがちです。
書いているときには全く気付かなかったんですが、今読み返すと色々と粗い・拙い部分が目立ちます。
何度か本音をポロリしていますが、記事を書く時にもリアルタイム性を出したいという思いがあったので、上述した推敲原稿や完成原稿でも表現の部分については可能な限り叩き台の書き方を尊重するようにしています。

そのため、アドベントカレンダーの執筆期間中は過去記事の内容を修正を含めた変更をしないようにしています。
いいねやコメントは気付いていて、きちんと確認はしていますが全てリアクションはしていません。
私が「（この結果は）やっぱりな」と思っているか「マジか予想外でした」と思っているかも見てもらえれば、原稿がどの段階での投稿なのかも見えやすいかもしれません。

回答発表はしませんが、カゼを引いたので品質の違いが露骨すぎるかな…とは思っています。

最後に

ここまでお付き合いいただき、誠にありがとうございました。
末文になってしまい恐縮ですが、
また本稿からご覧頂いた方は、特に講師・受講生向けの書き方の苦悩部分を意識しながら、本アドベントカレンダーを巡回していただくと「多分本当はこういう話がしたかったんだろうな」というのが見えてくると思います。
既に他の日から飛んできた方は、新鮮な気持ちで読める一回目と、本稿の内容を踏まえて読めるので二度美味しい（ハズ）です。

実は、こういう記事構成を書くのは結構好きで、寄稿した記事もアドベントカレンダーのようにシリーズ化が決まっていれば今回のように最後を読むと見方が変わるようになる事を心がけています。
「小説家になろう」とかではないんですが、当初から最初に構成を考えて１周でエンドコンテンツにならないようにしようと決めていましたが、これがうまく行ったかどうかはあなたが内心だけで決めていただければと思います。

GitHubで編集を提案