こんにちは。kyです。 今日はちょっと昔話というか、お話をしようと思います。ですので気軽に聞いてもらえると嬉しいです。
ここでお伝えしたいことは「テックブログの運営で大変だった話」と「課題を解決するプロダクトを作っていった話」です。僕なりに気づいたこともお伝えします。
昔、テックブログを作ったときの意気込みと大変だったこと
前の会社でPyQというWebサービスを数人で立ち上げたのですが、成長するにつれて、もっとお客様にPyQを知っていただく必要がありました。
マーケターのnanaもチームにジョインし「ブログを通して有益な情報を公開して、それでサービスを知ってもらおう！」と決めました。SEOだけを考えた残念な記事を量産するのでなく、ちゃんと問題の解決や知見になる記事を書こう！ということを大切にしました。
テクノロジーに関したWebサービスだったので、テックブログとも言えるブログを作り始めました。ブログについてきちんと取り組むため、こういったことを大切にしました：
- 独自ドメインでやる
- 技術の内容とWebサービスのニュース両方を書く
- 複数人で運用。相互にレビューしてちゃんと良いものを書く
- エンジニアが技術的な正しさや有益さに、マーケターが読みやすさやSEOに責任を持つ
ブログを作るだけなら良いのですが、このような条件で真剣に運用するとなると、どうでしょうか。とくに最後の1つはとてもチャレンジングだったと思います。コピー&ペーストしたような記事が量産される時代を終わりにしようと、「うちはちゃんと読まれるうえ、読む人の課題解決や成長につながるものを作ろう！」と意気込んでました。
最初は、運営について大変なことがありました。チーム（とくにこの活動を引っ張ってくれたnana）が一生懸命考えて運営体制を作っていきました。
当時の運用フロー
そのためにこのようなフローで記事を書いていました。
- 記事をVSCodeで書き「テキスト校正くんプラグイン（textlint）」でチェックする
- 記事を書く仕事をAsanaでタスク管理する
- 記事のレビューをDropbox Paperで渡してコメントしてもらう（Asanaのタスクにアサイン）
- レビューのやり取りを記事に反映して、はてなブログに記事を作成する
- はてなブログの下書きプレビューで社内に共有する
- 記事を修正して、完成すれば記事を予約投稿する
- 記事が投稿されたらツイート、Facebookでシェアをする
これは結構大変そうです。
ですが条件の中で良い記事をちゃんと作ろうとすると、必要な作業だったと思います。実際に良い記事を書いて、多くの方に読んでいただいていました。今もそのブログ、Python学習チャンネル by PyQは多くの方に読んでいただいていますし、実際に役立つ内容が盛りだくさんです。
ですが、もう少しでも良いから運用を改善したいものです。とくに外部の人のチェックがあるインタビュー記事で、さらに運用が大変になったのを覚えています。困っているチームメンバーを見たときに 「絶対に助けたい」と思いました。
数年前の話ですので、今なら「Notionで運用できる！」など新しい方法があるかもしれません。Slackのスレッドでコメントしたり、Zennをチームで運用するのも良いかもしれません（独自ドメインでやりたいのでZennやQiitaは避けたと思いますが）。皆さんも、もしかしたら苦労されているかもしれません。
何かを作って解決できないかな、と考えた
そんな困っているチームメンバーを何とかしたい、と思いました。
そこで 「テックブログの運営に使えるWebサービスがあれば良いのでは」 と考えました。いえ、テックブログと言わず、複数人でのメディア運営を何とかできるプロダクトが作れるのではないでしょうか。
こんなものがあれば、協力してブログを運営するプロダクトになるのではと考えました：
- インストール不要ですぐ使える：
- 執筆のタスク管理もできる：
- 記事を執筆する状態を同じサービス上で管理する
- レビューのワークフローに自動で則る
- アサインや期限、ステータスを管理し、誰があと何をすれば記事の完成かを分かるようにする
- 記事のレビュー（コメント）もできる
- GitHubライクな行のレビューにし、社内のエンジニアも協力しやすくする（案外誰にとっても見やすい）
- 記事はバージョン管理し、コメントが混ざらないようにする
- コメントが通知、Slack連携されることで連絡を減らす
- ワンクリックで配信できる：
- ブログ上への記事作成をワンクリックでできるようにする
- 画像も自動で配信する
- 高速な校正：
- textlintはJavaScriptの形態素解析エンジンを使うので、MeCabなどの速いものを使う
- 独自に校正ツールを実装し、高速化する
- ディープラーニングによる校正：
- BERTの技術を活かした文法誤り訂正（GEC）をする
- 助詞の間違いやタイポなど、ルールや正規表現でカバーできない間違いを検知する
と、若干モリモリではありますが、これを作り始めました。
当時のブログ運用は「ある価値を実現しようとして、既存の仕組みで何とかしていた」状態でしたので、マッチするプロダクトがあるだけで何とかなります。最初からすべてを実装する必要はなく、運用しながら改善できる点も取り組みやすかった理由です。
もし皆さんも「既存のツールをいくつか使って何とか運用しているが、大変」という場面があれば、何かプロダクトを作るチャンスだと思います。一般化でき、1つの需要としてまとまりがあれば、きっと他の人も困っています。
使ってもらいながら成長する
これは完全にサイドプロジェクトとして作り始めました。まずアルファ版として作り、PyQチームに使ってもらいました。 その当時でも業務はかなり改善されたので、より便利になる「はてなブログ連携」やディープラーニングの技術を追加していきました。
ただ、狭すぎる需要に特化して作れば、それは「便利な社内システム」ができるだけです。そこで開発が進むごとに、クローズドベータやオープンベータとして多くの方に使っていただきました。 開発はその後も続き、半年前に正式リリースしました。もう前の会社での新規事業（PyQ）も軌道に乗っていたので、退社して今の株式会社ゼンプロダクツを起業しました。
テックブログの運営にお使いいただいています。
導入してフィードバックをくれた皆さん、初期のころから使ってくださる皆さん、本当にありがとうございます。プロダクトは人に使ってもらわないと育たないと、よく分かりました。
そして、誰に使ってもらうか、どういった人に使ってもらうかも大切だと思います。なぜなら使う人によってプロダクトの方向性すら左右されるからです。プロダクトマネージャーとしては、誰に使ってもらい、いただいた意見をどう受け取るかという判断が重要です。そのためのブレない指針や心と、その逆の柔軟性も大切です。
今のShodoが最初からあれば、当時の悩みはなかったと思います。ですが悩みもあったからこそ良いプロダクトが生まれましたし、悩みや課題に向き合ったからこそチームがより強くなれたのかなと思います。
おわりに
今回は昔話的な内容でしたので、これが知見だ！と豪語するつもりはありません。ですが、こういった学びがあったよ、というサマリーをお伝えしたいなと思っています。
- 今ある仕組みやツールで何とか解決している課題があれば、プロダクトを作るチャンス！
- 何か具体的な悩みや助けたい人がいれば、まずは作って使ってもらおう
- 広い意見をもらったり、どんな立場から意見をくれたかを考えて「社内システム化」を避けよう
プロセスの説明を端折って結果だけを伝えている気もしますが…、もしこの記事が多くの人に読んでいただけたら、もっと詳しく書こうかなと思います。
今後もShodoを開発して皆さんを助けられたら嬉しいです。もちろん今後、Shodoの方向性が大きく変わる可能性なども十分あります。ですが、最初に思った「この困っている人を助けたいな」という気持ちはずっと大切にしたいです。
プロダクト開発、やっていきましょう！
- 執筆：Kiyohara Hiroki (@hirokiky)
- レビュー：kameko、nana
（Shodoで執筆されました）
