はじめに
ピクトリンク事業部開発１課の里形です。
本記事は、テックブログリレー7日目の記事です。
前日6日目の記事は西村さんの「Zustandを使ったNext.jsの状態管理」という記事でした。
状態管理ライブラリの中でも有力な候補の一つであるZustandに関してわかりやすくまとめられており、非常に読みやすかったです。
Next.jsの実装から離れて久しいですが、すごくわかりやすいチュートリアル記事だったため、とても勉強になりました！
私は、今回を含め2回のテックブログリレーを主催いたしました。
本記事では、技術発信文化醸成に向けた取り組み（テックブログリレー）と、その中で感じた課題点に関してご説明いたします。
組織の技術発信文化を作りたい方へ少しでも知見をお伝えできますと幸いです。
テックブログリレーを開催した経緯
開催した経緯としては、2024年度上期に開発部内で下記の流れの出来事があったことが理由として挙げられます。
- ピクトリンク開発部で技術発信文化を促進する動きが生まれた（2024年度の評価制度に組み込まれた）
- 2024年上期に各々がブログ記事を書いたが、計画的な遂行にならず、期末に執筆が集中した
- その結果、レビュワーの不足や記事公開日の延期など複数の問題が発生した（フリューテックブログでは、記事の品質や誤字脱字、守秘義務事項などをチェックするレビュー制度が存在しています。）
実際に、自身のカンファレンス参加レポート記事などもレビューを受けられず、鮮度が高いタイミングに公開できないという事態が発生しました。
上記のような問題を回避するために、計画的な技術発信できる制度が必要だと感じたため、2024年度下期にこの企画を実施することにしました。
企画の構想としては下記の内容で考えておりました。
- 期中に技術発信（記事執筆）ができる企画を実行する
- 6ヶ月(下半期)のうち2回は開催する
- 12月はQiitaでアドベントカレンダーを実施しているので、それに影響しない実施形態を目指す
- 期末となる3月は、それぞれのメンバーが評価に必要な執筆数等を調整するはずなので、その時期は避ける
- 最低でも5日、可能であれば7日間連続で公開するような形にする
- 開発部に所属する多くのメンバーが発信する機会を作るため
次の章では、各回の実施形式とその反省点をご説明します。
テックブログリレー第一回
第一回の方式
第一回は以下のような形式で進めていきました。
- 実施期間は11/11 〜 11/17
- 執筆期間は10/28 〜 11/14
- 7名7日間の連続公開
- レビュー担当記事を1人あたり3つずつ割り当て、実施日初日にメンバーに周知
第一回の振り返り
第一回開催を通しての振り返りをKeep/Problem/Tryに分けて記載します。
Keep
[計画的な技術発信に貢献できた]
少なくとも、私を除いて6名のメンバーが下期前半に1回は記事の公開を行うことができました。
評価的には期中に2〜3回の執筆が必要になるため、その半分ほどの進捗をサポートできたことは、計画的な技術発信への大きな貢献ができたと感じております。
[レビュワーの確保を確実にできた]
元々、ブログ記事のレビューは互助的な取り組みでしたが、基本的には各メンバーの自主性に依存した仕組みになっています。
そのため、期末などの忙しない期間では、機能不全に陥ってしまうこともあるという点が上期に発見した課題の一つでした。
その上期に発生していたレビュワーが不足する問題を、参加メンバーでレビュースケジュールも固めることで、仕組み的に解決できたと考えております。
[全てのメンバーが公開日通りに記事公開ができた]
準備期間内に全てのメンバーの記事が、執筆のみならずレビューまで完了したことは非常に素晴らしいことだと感じました。
技術発信自体は評価にはつながるものの、定常業務には含まれていない業務であったため、それぞれのメンバーが時間を捻出して取り組んでくれたことに大きな感謝を感じております。
また、第一回の取り組みを通じて、多くのメンバーでレビューし合う環境を提供することで、計画的な技術発信を実現できる可能性が大きいことを実感しました。
Problem
[準備期間が2週間強では短かった]
準備期間に行うことは執筆のみならず、他メンバーの記事をレビューしたり、レビュー内容を反映したり、果てはネタ出しから行わなければならないこともあります。
それら一連の行程を業務の合間にするには、2週間という期間では短かったようでした。
特に、記事のネタ出しに関しては半数以上のメンバーが悩んでいた印象がありますし、参加を断られた際の理由も「ネタがない」が多かったような気がします。
[レビュー提出への期限を設定していなかった（記事提出期限しか決めていなかった）]
記事の提出期限に関しては、それぞれの公開日から2日前程度に設定してお伝えはしておりましたが、レビュー期間などを考慮に入れていなかったため、レビュー提出期限日に関しては設定をせずに企画をスタートしました。
その結果、記事提出期限ギリギリに提出されることが多数あり、レビューと修正の完了までにほとんど時間が残されていない状況が発生しました。
このレビュー提出期限を設定していなかった点が第一回の取り組みの中で最も大きな課題点だったと感じています。
[直前のレビューでは執筆時間と重なり、レビューが大変だった]
また、上記二つの問題点が重なった結果、公開日が後半の記事は執筆とレビューが重なってしまう形になり、かなり負荷が高い状態になってしまいました。
可能な限り、自身のレビュー提出時期と他メンバーの記事をレビューするタイミングは被らないようにしたほうが良さそうです。
[レビュー観点を知らなかったので手戻りが発生した]
一部メンバーはテックブログのレビュー観点を知らなかったため、機密事項などの指摘点での手戻りが発生していました。
この手戻りに関しては、事前にレビュー観点に目を通してもらうだけで避けられる問題だったと思います。
そのため、初めてテックブログを執筆するメンバーには、README感覚でレビューガイドラインを見てもらうようにするほうが良さそうだと感じています。
Try
Keep/Problemを踏まえて、第二回では以下の点を意識して実施しました。
[長期休暇を挟むことで、ネタの準備をしやすくする]
記事を執筆する上で最も最初につまづく点であるネタだしをしやすくするためには、長めの落ち着いた時間が必要なのではないかと考えました。
ちょうど、第二回を開催する前にお正月の長期休暇が1週間程度あるため、第二回開催のアナウンスは長期休暇の前に行いました。
私自身、技術的挑戦をしてみたくなるきっかけは業務外の時間に見つけることが多いため、ゆっくりお休みしている最中に見つけた面白い技術や小さな問題などをストックしやすくなるのではないかという狙いがあります。
[レビュー依頼期限の追加と依頼スケジュールの改善]
執筆とレビューの期間が重なることでかなり大きな負荷がかかることが判明したため、以下二つの対応策を追加することで解決しようと考えました。
- 記事提出期限の3日前にレビュー依頼期限を設定し、その日までにレビュー提出するようにする
- レビュー期間は可能な限り重複しないように、1ヶ月程度の執筆期間スケジュールを作成する
テックブログリレー第二回
第二回の方式
第二回は以下のような形式で進めていきました。
- 実施期間は2/17 〜 2/23
- 執筆期間は1/24 〜 2/20
- 5名7日間の連続公開
- レビュー担当記事を1人あたり3〜5つずつ割り当て、実施日初日にメンバーに周知
第二回の振り返り
第二回開催を通しての振り返りをKeep/Problem/Tryに分けて記載します。
Keep
[ゆとりのある執筆とレビューが行えた]
今回は前回の2倍近い期間を使って準備を行なったため、全体的にゆとりを持って執筆やレビューが行えました。
また、いくつかトラブルが発生したものの、バッファをとったスケジュールだったため、大きな問題にもならず無事に当日を迎えられました。
そのため、定常業務に対する障害も発生していないようだったため、今回のスケジュールは以降の企画にて目安にできるのではないかと考えております。
[レビューと修正が余裕を持って行えた]
今回はレビュー提出期限を設けたため、以下の2つのメリットが得られたと感じています。
- レビュー内容の修正を時間的に焦らずに行うことができた
- レビュワーがレビューしなければいけない期限が明確になり、計画的にレビューすることができた
これらのメリットより、記事の品質を高く保ちつつ、余裕を持った記事の公開ができたのではないかと考えております。
Problem
[一般的に長期休暇でネタ出しはしない]
これはよくよく考えれば当たり前のことなのですが、長期期間中に業務のことを考えるのはあまり現実的ではないと気づくべきでした。
せっかくの長期休暇前に、年明け以降の仕事を増やすということはあまり考えられないため、休暇前に募集を開始してもメンバーが集まることはありませんでした。
実際、参加希望のメンバーが集まり出したのは1月中旬以降だったため、第一回で考えたTryは効果がなかったと言えます。
ネタ出しに関しては別の方向からアプローチをかける必要があると感じました。
[2月末は時期が非常に悪かった]
記事の前半でも述べましたが、今回の公開期間を2月末に設定した理由としては以下の2つがあります。
- 期末である3月末から1ヶ月程度期間が開けるため
- ブログリレー以外に発信する必要がある人が期末までに時間的ゆとりを得られるようにするため
- 例年12月に開催されるQiitaのアドベントカレンダーから十分な時間的間隔を開けるため
- ネタ出しに困らないようにするため
しかし、2月末から3月にかけての期間は一部のメンバーに社内行事が発生したり、施策の仕上げのために工数的なゆとりが失われたりなどの時間的な課題点が発生していました。
その結果、そもそも執筆活動に時間が割けないことでメンバーが集まりづらかったり、執筆予定のメンバーが辞退せざるを得ない状況が生まれてしまったりしました。
これらの問題を避けるためには、アドベントカレンダーが終わった直後から1月末ごろに実施期間を設定するのが、ギリギリ取れる選択肢のように感じました。
Try
[下期後半での実施期間は1月にする]
Problemでも述べましたが、弊社ではスケジュールに都合上アドベントカレンダーが終わった直後から1月末ごろに実施期間を設けるのが適していそうだと感じました。
長期休暇を挟んでしまう形にはなりますが、執筆と公開スケジュールを作成をアドベントカレンダーの直後には着手をしておかないと、1月末での公開はかなりスケジュールがタイトになってしまいそうなためです。
アドベントカレンダーの直後ということでネタ出しの難易度が上がりそうですが、もともとネタ出しは課題点として上がっている部分なので、同時に解消を目指すのが良さそうに思います。
技術発信文化を作るにはどうしたらいいのか
2回のブログリレー開催を経て、技術文化発信に関して得た知見と感想を説明していきます。
イベントがあることで、技術発信による業務的負荷を分散できる
2回のブログリレーを経て、記事執筆を恒常的に行う上でイベントがあることは大きなサポートになるのではないかと感じました。
レビュワーの確保と執筆期間を設定したことで、一定の期間に負荷が集まらないように分散することができたと思います。
それにより実業務への影響を減らしつつ計画的に多くの記事が公開できたのではないかと思います。
技術発信はモチベーション的に難易度が高い
発信を行う以上、有用な知見がある、あるいは新規性のある情報であることが求められていると思います。
もちろん私たちが業務を遂行する上で学ぶことは多くありますが、その多くが既出の情報源から得た知識であり、記事や発表として形になっているものです。
そのため、求められる条件を満たした発信を行うには、相当なモチベーションか経験値がないと難しく感じると思います。
そういった面では、経験値獲得を促すために評価制度に組み込まれている環境は一つの強みであると感じます。
しかし、発信の難易度に対して評価制度のみではモチベーションの面であまり効果を発揮できていないのが現状かもしれません。
私自身も実際のところ、イベントとして開催されているアドベントカレンダーやハッカソンくらいでしかできていません。
技術発信を恒常的に行えるようになる前に、まずは始めるモチベーションを形成するところへのアプローチが必要かもしれないと感じました。
技術発信はネタづくり的に難易度が高い
上記でも触れましたが、有用性あるいは新規性を含んだネタを作るのは難易度が高いと感じています。
複数の書籍にまたがり学んだ知見をまとめるなどでも、十分に有用な情報であると考えていますが、実際に公開するという話になると苦手意識を持つ方が多いのではないでしょうか。
その理由としては、普段から業務上で多くの記事や書籍などを読み、既知の情報を多く追っていることも原因の一つではないかと思います。
この苦手意識に対処するために、技術発信における基準的な例を大きく紹介することなどは、一つのアプローチとして考えられそうです。
技術発信の選択肢が少ない
弊社における代表的な技術発信の選択肢としては以下のものが挙げられます。
- 記事の執筆
- カンファレンス登壇(参加人数に限りがある＆時期が限られている＆難易度激高)
- ハッカソン参加（参加人数に限りがある＆時期が限られている＆ハードルが高い）
- 勉強会のLT登壇(あんまり勉強会に参加する文化ではなさそうなため、難易度高め)
- 社内LT（難易度は低いが、かなりの発表本数を求められる）
ネタ出しの難易度や参加ハードルが高いものが多く、記事執筆を選択する方が多いのではないかと思います。（弊社ではハッカソンに参加するメンバーも結構いる） あまり良い手は浮かんでおりませんが、選択肢を増やすのも技術発信へのハードルを下げる方法になりそうな気がしています。
技術発信文化を作り上げるためにはどういうアプローチが考えられるか
ブログリレーのように定期的に執筆ができるイベントを開催する
個人的にはやはり、自由時期に発信を行うことはかなり難しいのではないかと感じています。
運営業務が必要にはなりますが、ブログリレーのように計画的に発信するための場があることは、文化醸成を行う上で取れる選択肢の一つになると考えています。
実際に、今回参加してくださったメンバーは計画的に発信を行うことができたのではないかと思います。
まだ下期の期末が来ていないため、どの程度テックブログのレビューが混雑するかわからないですが、注意深く観察しようと考えています。
発信のネタづくりのために対話的に考える機会を設ける
技術発信のネタづくりは、今のところ個人で考えるか、個人的に相談を持ちかけるかのどちらかを選択しているメンバーが多いのではないでしょうか。
期初や期中などのタイミングで、技術発信の目標立てをするための場があっても良さそうに感じました。
ラバーダッキングのような形でもいいので、技術的な目標の整理や学びの整理を行う時間が公にあると、技術発信に繋がりそうな予感がしています。
おわりに
実際にイベントの運営を行い文化醸成に挑戦したことで、組織文化を作ることの難しさを痛感しました。
それと同時に、技術発信をする上でより多くのメンバーが感じているハードルを下げるヒントを得られたように感じています。
この記事が、技術発信文化を新たに作ろうとしている方の助けになれますと嬉しい限りです。
本記事をもちまして第二回テックブログリレーの連続投稿が完了いたしました。
記事を投稿してくださったメンバー、読んでくださった皆様に心より感謝を申し上げます。
