ずっと、Backlog World 2020 re：Union オンライン - connpass の感想を書いているのだが、開催からすでに1ヶ月近く経とうとしているのに参加記事が完成しない問題がある。
問題の分析と対応方法を考える。
問題の分析
いわゆるチケット・機能が巨大すぎる問題に本質的な類似が見られるように思われる。
- 明らかに分量が多すぎる
- すでに3時間くらい書いているが、まだ半分という段階
- 6000文字くらい
- おそらく超大作になりすぎて完成しないような気がしている
- 自分が知り得ない情報を知って、学び直しが多く発生している
- 発見自体は良いことであるが、発見が多すぎて発散している
- 正しい認識をするために調べ直しや、学び直しが発生している
- 調べることにも時間がかかっている
- できないことに対して、気持ち的な問題が発生している
- この文章どれだけの価値があるんだろうというのを思って書いている
- 基本的にブログは自分の思考整理の面が強いが、それでも人が読んでわからないもの ＝ 自分があとから読んだときにわからないものだと思っているので、ある程度の情報は詰める必要がある
- なかなか完成しないので、まだ時間をかけなければいけないのかという気持ちと、疲れ
対応
小さくリリースを積み重ねて大きなものを実現するのが良さそう。
- 全体の紹介をやらないことにする
- 書く部分を限定的にする
- BackLog Worldは1トラックなので、あまり気にしないでよいが、複数トラック走っている場合は自分が見たものの一覧だけ書く形にする
- 興味のあるセッションから書く
- 全体的に前から作業しているのが効率の悪さにつながっているように思える
- 自分にとって学びが多かった、面白かった、というものから書く
- （これに関しては発表者視点で微妙な気持ちもあるけれども…）
- ぜひこれは見てほしいというものを書く
- 1セッション or 2セッションごとに記事を投稿する
- 小分けに出して。記事①、②みたいな形
- 小さく出して、フィードバックを少しづつもらおう
- 1記事は2000〜3000文字程度にしたいので（長すぎると読み手にとって辛い）、その意味でも記事を分けるのは良いかなと
- 1セッションについて学びが深かったシーンを抽出する
- 全体的に学べた、というのはもちろんあるが、セッション中でも興味のあるパート2，3個に絞って内容を深く理解したい
- 多分、たくさん並べても自分自身も理解が追いついていない（他の機会に改めて聞き直して、そういえばこういうのもあったな、と振り返る程度が良いかなと）と思う
- 読み手的にもセッションのポイントがわかりにくいのではないかと思われる
- 発表のコピーとならないようにする
- 発表の概要を伝えるのは良いが、道筋に沿ってコピーとなっても、劣化コピーにしかならない
- というか、自分の記事をフックに実際の発表を見に行くとか、スライドを見に行くとかしてもらえるような形にするほうがベターなはず
- 発表者的にも嬉しいはず
- 発表の概要から、自分の環境と照らし合わせて、どのような点で面白いと感じたのか、応用できそうなのかをまとめるほうが良さそう
まとめ
これまでカンファレンスレポートみたいなのをガッツリ完成させないといけないかなと思っていましたが、書いていて心がしんどいなと思いました。
自分以外にもカンファレンスレポートは最初から最後まで書かなければいけないんだ、みたいな気持ちになって完成せずつらい気持ちになり、途中で書くのを断念してしまった、という経験がある人はいるような気がします。
この記事は自分で今後はこうしていきたいという方針を示しながらも、そういったイベント全体の記事を書くのが辛くなってしまった人向けになにかの参考になれば幸いです。
あと書いてみて、これチケット粒度の話と全く一緒だなということにも気がついたので（少しずつ改善してすぐリリースで、価値提供を最速にしようというやつ）、日々のソフトウェア開発の仕事をする上での構造がこういったところにも現れているのは興味深いなと思いました。
