本稿に限っては毎日の書き溜めをストックしていく形式にした。
その時の感情を全部ぶつけるようにしたかった。
楽しかった、が、毎日同程度の品質を維持するのが大変だった。
書いてみた所感を徒然と書き残していく。
対象者
- 本アドベントカレンダー記事を楽しんでいただいた方
- 来年のアドベントカレンダーに挑戦しようと思っている方
- モチベーションを維持したい方
同じ目的だが別視点でのアプローチを別日に書いているので、そちらも確認されたい。
これは技術的、戦略的なノウハウがメインの記事だが、本稿はただひたすら感想を書く回である。
ネタはあるし、毎日記事を書いてるのに完成しない焦り
去年の反省を踏まえ、毎日新しい（当日）記事を優先して書くようにした。
元々は一つずつ記事を完成させていくスタイルで書いていたのだが、途中でネタを忘れて何を書こうか思い出すところから始まり、非常に苦労したためだ。
書く内容を思い出したとしても、当日のインスピレーションや勢いなどもあるので、後になるとこういった「書きたい」というパワーがなくなってしまう。
今回は当日の記事を完成させた後、一番古い日付の記事として先行してアップロードし、過去に書いていた記事を後の日付でアップロードすると言う対応を行うことで対処した。
特に非公開記事を書き溜めてアップロードするのも何か違うな、と去年考えていたことなので、これもやめた。
（今年からは明確に完走賞の対象として認められなくなったため、妥当だと考える）
下書きを許容する
Qiitaのアップデートのおかげで、Web上で未投稿記事の下書きのみを抽出できるようになった。
このおかげで「とりあえず下書きをストックしていく」というアプローチは、投稿が遅くなったとしてもサボり防止機能として運用していく事が可能になった。
LINEやSlackなど連絡の件数が数値で表示されるコミュニケーションを入れた初期の頃を思い出して欲しい。
未読数が数値になるため、慣れないうちはとりあえず全件見ていなかっただろうか？
あの時の「未読の件数が溜まっていくので早く読まなきゃ」となっていた頃の感覚を、下書きの件数が増えていく事で対応しなければならないという気持ちになった。
ある一定のラインを超えると「もういいや」となってしまう事が去年の経験として理解していたので、一週間以上は期間を空けないという運用を意識した。
たとえば、今日が20日で埋めている日が1-10,12-15,19だったとしよう。
これは、以下のルールにより成立しうる状態である。
- 通常通り当日の記事を書く（20日目の予定通り）
- 古い期日順に下書きを埋める（今回のケースだと11→16,17,18日目の記事に着手）
- 筆ノリが悪ければ飛ばして、次の古い期日に取り掛かる。場合によっては順番を入れ替えてしまう（11をスキップして16の記事を書いた場合、16の記事を11の記事として投稿する）12
これで見た目上は一週間以上の期間を空けない状態を維持することに成功した。
この運用ルールを認識した上で、記事のタイトルを見ていくと、「記事A」と「記事B」が入れ替わっているような傾向が見えてくるかもしれない。
ヒントとしては、下書きのため投稿日だけで推測するのは難しい。記事のタイトルや内容を見ながら「この日の続きでは？」と予測してもらうのが読みやすいだろう。
なお、出題者もこう言っておきながら正しい順番はもうとっくに忘れているので、解答は出せない。
来年の目標
当然、完走賞。
アウトプットのおかげでインプットの質を高めているので、アドベントカレンダーに限らず継続してアウトプットを続けていきたい。
今年から執筆活動をするとスコアリングされるサービスにも登録・運用を開始したので、これについて効果があったのかどうかも一年を通して検証していくとともに、サービスの充実を祈願したい。
アドベントカレンダー以外でチョイ出し＆表明
もうフリーランスを続けて来年で5年目になるが、そろそろ集中してやりたいビジネスも形になってきたので、協力者を募っていこうと考えている。
今年の時点で既にいくつかのコミュニティには参画しており、そちらの活動も通じて規模を徐々に拡大していきたいという狙いがある。
まだ具体的な行動プランまでは興せていないが、ある程度叩ける状態になったら合わせて発信していきたい。
記事を読んで欲しいとは思わないけど、読んでくれた人に何か持って帰って欲しい
今年は特に意識したのがこれ。
せっかくお時間をいただいたのだから、せめて何かためになりそうな情報を一つでも多く持ち帰っていただくためにどうしようか、様々な施策や表記を考えて試行錯誤したのは間違いない。
そのため、すべての記事で文体が整っていない事に気づくだろう（時間がなかったので内容だけ埋めて投稿したものもあるが）
一応弁解すると、毎記事ごとにコンセプトや目的はあるのだが、文中や表現だけではうまく伝えられず、とはいえいちいち画像を作っていては本題より画像生成に時間をかけてしまう。
ソースコードのように「こうすればこうなった」というものが出せない（特にソース。研修事業だし多少はね？）ので、なるべく筆者が対応・実施した際の環境やペルソナについては思いつく限り明確にするよう務めているが、講師未経験者エンジニアにとってはまだまだイメージしにくい部分はあるかもしれない。
最近開発案件に入ってない理由と抱負
去年のアドカレも見ればわかるかもしれないが、最近は開発事情についてあまり触れていないのが多いのは、エンジニアから講師へロールチェンジしたようになった結果である。
が、今年はなるべくエンジニア側に寄せたかった事もあり、ささやかながら開発支援業務やシステムの運用現場への参画といった「短期でもできるシステム開発に関係がありそうな案件」を選んでいたつもりでもある。
が、研修事業サイドの目標として「エンジニア研修を新卒やリスキリング、インターン生だけでなく、幅広い層へリーチする」というものがあり、こちらが非常に難しかったため開発サイドがおざなりになってしまった気もする。
来年は幅広い層へリーチするために新しい事業を考えなければならないように感じており、こちらを拡大する可能性があるため、更に開発へ手が回らない状態になってしまうかもしれない。
多くの経営層エンジニアやマネジメント層エンジニアが溢していた「キャリアアップすると現場仕事（プログラミング実装）ができないのが悩み」というのは、独立とか法人化とかではなくビジネス事業として発足させようとする全てのエンジニアの悩みなのかもしれない。
本プロジェクト（あえてプロジェクトと称する）をビジネスを先行して考えたとしても、ビジネスを支えるシステム要件やプロトタイプ実装は自分でやりたいところだ。
幸い、筆者は業務系システムならスペシャリストを自認しており、また研修事業以外の運用現場の知見も得ている最中なのでシステムサイドからの要求定義も可能である。
我ながらどんな内容に仕上がるのか楽しみである。