25日完走した感想と、今からQiitaアドベントカレンダー2023に向けてのテーマ・抱負Zennのむらや@IT教育をもっと拡大したいマン📝25日完走した感想と、今からQiitaアドベントカレンダー2023に向けてのテーマ・抱負2023/08/29に公開アドベントカレンダーidea!この記事はQiitaから移行しています。https://qiita.com/items/7974edd43c24fae38d9fお詫びQiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。今回、記事が難産だった事より体調不良に苦しめられました。精神的なものなら事前準備するぐらいしか緩和策が思いつかないんですが、カゼから始まったものでした。ここまで悪性が強いとは思いませんでしたが、これ本業だけだと最悪、納品さえ間に合わせられれば何とかアフターフォローで挽回できますが、副業(今回はアドベントカレンダーが該当するものと考えてください)の場合が大変です。実際の案件だとカゼや身内の不幸は当たり前ですが言い訳になりません。ブラック企業とかそういう話ではなく、事業主だと会社間での取引になるので、損害賠償が発生する可能性があります。本題から外れますが、大事な話なので触れておきますね。やむを得ず個人事業主になる場合でも、契約時に再委託の可能性を残しておくか、再委託禁止を盛り込まれる場合はやむを得ない理由での取引遅延については交渉の余地を残すようにしましょう。今回は広報も宣伝もしていませんし、Qiitaのアドベントカレンダーを書くだけの話なので遅延損害もありませんでした。その結果として体調を優先する事ができましたが、実際は再委託の交渉あるいは遅延時の取り決めをしているところです。Qiitaの仕様も研究しておくべきだった嬉しい誤算なのですが、Qiitaのリンクカード(正式名称をど忘れしてしまったんで、意図が伝わってほしい)が非常にリッチだったのでリンク関連は改行しておけばよかったです。:::noteこの書き方:::関連はQiita独自記法だったので避けていましたが、置換自体は難しくなかったので組み込めば他の場所でも活用できたはずです。執筆するまで完全に忘れていましたが、見やすくなる機能があるなら使っていくべきでした。アコーディオンの書き方はhtmlタグで頑張っているので、これはこちら側の仕様の問題で諦めました。有効活用するシーンもなかったので、大きな障害にはなっていないのが救いでしょうか。「要件は確定してないけど、多分これやらないとダメだから先行して実装しておこう」というプロダクト推進をするチームの経験が多かったため、初日から翌日などの記事をぼちぼち書き進めていったんですが、今回はこれが活きました。初日までに25日分(当時はその想定だった)の記事のネタを決め、初日から一週間までに25日分の書き始めと書き終わり、やりたい事だけ箇条書きなりやりやすいスタイルで書くだけ書いて、後は上から順番につなげていくだけの作業をする予定でした。これは私がアフィリエイター時代に培った、独自流のやりやすい記事の書き方のスタイルなので人によってやり方は変わりますが、とりあえず方針が決められたのです。このやり方で私が一番苦労するのが、このつなぎ合わせの作業で不自然な部分を消していくという工程を繰り返していく事になります。この方法を採用しているのか、というと記事にも納期がある事が挙げられます。した記事を書き上げるために書き上げた直後の状態を叩き台原稿1日時間を置いて繋ぎこみの甘さを是正した推敲原稿レビュー(セルフの場合、自身で記事を読んだ感想を踏まえて期待する結果と異なる部分の書き直しなど)を経て公開している完成稿といったステップを踏んで品質を上げていくやり方をしているので「とりあえず納期までに出す」を叩き台原稿でできるのが強みです。同時にデメリットとして進捗状況(記事の書きやすさ)によって露骨に品質に差が出ます。して書こうとして、結局ネタ不足になって書ききれなかった記事たちを「まとめ」として供養しました。余談:AIに記事を書かせて校正する方法は現実的か?正直、毎日投稿を前提にする場合は本稿レベルのボリュームですら書き続けるのはちょっとした苦行です。AIのべりすとのようなサービスあるいはツール(AI)を作って書かせて、まずい部分を修正する方が作業としてはラクだったりしますが、既に出来上がった文章自体がそもそも使い物になるのか?という観点で見てみると単純に作業工程が増えるだけになってしまいます。「人が書いたテキストを修正して投稿する」という作業が考えている以上に重労働である事に理解があると、1から自分で書いたほうがマシなシーンもあったりします。それが、自分が苦手な分野の記事を投稿するケースだったりするとつらいですね。本アドベントカレンダーの縛り実は、今回のアドベントカレンダーはなるべくコードを書かない事を意識しました。実際は業務の都合上、ほとんど書けないものばかりだったので、ポエムの傾向に寄ってしまいました。これは予想通りというか、反省すべき点でもあります。実績ベースの話になるようにしていたのですが、NDAの関係もあり最新のお話が難しいものやデータを開示できないものが多かったために体験談に説得力を持たせるために解説や事例紹介を盛り込みました。根本的な問題であるノーデータであるという点は変えられないため、アドベントカレンダー内でも講師向け、あるいは受講者に向けて書く傾向を増やす=ボリュームアップで対応しています。自分が主張したい事はきちんとデータを示しましょう。データを示さず(示せず)に主張すると、当たり前ですが非常に苦労します。今回は私が書いている話ですが、いざ自分がデータを示せずに主張したい内容があったとすると、相当苦労する事は容易に想像ができるかと思います。いざ記事を書いてみると、想像以上に大変だと言うことにも気付きました。何より、表現の仕方に恐ろしく気を遣うので難産になる傾向があります。今にして思えばそりゃそーだと思うんですが、決して楽ではなかったです。主張したい内容と、解消できない根拠不十分な状況を少しでも解決したい思いで空回りがちです。書いているときには全く気付かなかったんですが、今読み返すと色々と粗い・拙い部分が目立ちます。何度か本音をポロリしていますが、記事を書く時にもリアルタイム性を出したいという思いがあったので、上述した推敲原稿や完成原稿でも表現の部分については可能な限り叩き台の書き方を尊重するようにしています。そのため、アドベントカレンダーの執筆期間中は過去記事の内容を修正を含めた変更をしないようにしています。いいねやコメントは気付いていて、きちんと確認はしていますが全てリアクションはしていません。私が「(この結果は)やっぱりな」と思っているか「マジか予想外でした」と思っているかも見てもらえれば、原稿がどの段階での投稿なのかも見えやすいかもしれません。回答発表はしませんが、カゼを引いたので品質の違いが露骨すぎるかな...とは思っています。最後にここまでお付き合いいただき、誠にありがとうございました。末文になってしまい恐縮ですが、また本稿からご覧頂いた方は、特に講師・受講生向けの書き方の苦悩部分を意識しながら、本アドベントカレンダーを巡回していただくと「多分本当はこういう話がしたかったんだろうな」というのが見えてくると思います。他の日から飛んできた方は、新鮮な気持ちで読める一回目と、本稿の内容を踏まえて読めるので二度美味しい(ハズ)です。実は、こういう記事構成を書くのは結構好きで、寄稿した記事もアドベントカレンダーのようにシリーズ化が決まっていれば今回のように最後を読むと見方が変わるようになる事を心がけています。「小説家になろう」とかではないんですが、当初から最初に構成を考えて1周でエンドコンテンツにならないようにしようと決めていましたが、これがうまく行ったかどうかはあなたが内心だけで決めていただければと思います。VueとGASとPythonでWebアプリ作る人。現場ではPM業務多め。日中は開発、定時後は(勉強会などの登壇含め)講師業、休日はコード多めにアウトプット頑張ってます。経歴がかなり異端(CTO経験があるとか元営業だとか講師やってるとか)なので、キャリコンも取っちゃおうかと検討中...バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。VueとGASとPythonでWebアプリ作る人。現場ではPM業務多め。日中は開発、定時後は(勉強会などの登壇含め)講師業、休日はコード多めにアウトプット頑張ってます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。