TwitterにMoney Forward Developersを開設しました

TL;DR

開発者向けの情報をお届けするマネーフォワードの公式Twitterアカウントを先日開設いたしました！アカウントは Money Forward Developers となっています。 Twitter IDは moneyforwardDev になります、ぜひフォローください！

なぜいま開発者向け Twitterアカウントを開設したのか？

まず前提としてマネーフォワードのSNSアカウント戦略は「過度な分散は推奨しないが、必要があれば分割する」になります。そして通常エンジニアやデザイナーなどの開発職に携わる人間がマネーフォワードの公式Twitterへ投稿をしたい場合は、アカウント権限を持っているかたに「このようなメッセージを何時頃に投稿してほしい」と依頼してもらうという方法を取っています。通常はこの運用フローで困ることはないのですが、技術広報としてオンラインテックイベントを何度か開催したことで大きく2つの課題がわかってきました。

テックイベント中の運営ツイートがおこないにくい。

まず第1の課題はテックイベント開催時に運営ツイートを行いたいケースがあります。例えばイベントがオープンしたこと、登壇者情報や登壇資料の共有、または配信トラブルに関する対応状況の告知などが運営ツイートに該当します。これらの問題に対していままでは主催である自分のアカウントか社内エンジニアで協力してくれそうなかた、あるいは登壇者のかたたちの自助努力によって運営されてきました。

ですが、企業が運営するテックイベントとして考えたときに個人に依存してしまう運営スタイルを構築すると、あとに続くひとにもそのスタイルを押し付けることになってしまいます。この運営スタイルが定着してしまう前に何かしらの、個人の頑張りではなく仕組みで解決する対策を行うほうがよいと考えました。

またテックイベントはだいたい18時〜19時から開始することが多く、運営ツイートのためだけにTwitterのアカウントを持つ権限のかたに待機してもらうのは運営コストが大きすぎると判断しました。事前に予約投稿が出来る類のものであればそれでもいいのですが、イベント開催中は突発で対応を求められるイレギュラーなことが多々起こります。そういったときに窓口として個人アカウントよりも公式のアカウントがあるほうが参加者もわかりやすく、問い合わせがしやすいと考えました。

公式アカウントの技術的投稿に対する検索容易性が低い

次に第2の課題としてエンジニアやデザイナーが過去の投稿に対して検索をおこなうときの検索容易性が低い問題があります。現在のマネーフォワード公式アカウントでは会社のプレスリリースやエンジニアブログ、公式note、マネーフォワード社員が登壇するイベントのPRなど数多くの情報を発信しています。

仮に昨晩参加したイベントのアンケートURLを忘れてしまったので探したいエンジニアのかたがいたとして、この投稿の中から簡単に探せるか？と考えたとき、答えはNOでした。イベントではハッシュタグなどを使うので探すこと自体は可能ですが、検索容易性は高くありません。

また多くのエンジニアにとって会社のプレスリリース情報や開発職以外の情報が大量に流れてくるTwitterアカウントはノイズになることが予想されます。経営状態が知りたい、全社的な取り組みが知りたいエンジニアもいるかもしれませんが、多くのエンジニア、デザイナーにとっては自分たちの課題を解決してくれそうな技術的投稿により価値を見出すと考えます。

そう考えたとき、エンジニアやデザイナーにとっては知りたい情報だけが集約されている状態が望ましく、現在は好ましいアカウントの状態になっていないと考えました。

分割するにあたって考えたこと

マネーフォワードでは現在公式アカウントを含むいくつかのアカウントを運営しています。そこで、まず社内の過去事例でTwitterアカウントを分割する際にどのような意思決定と合意形成をおこなったのか確認しました。

調べてみたところ、以下のようなことがわかりました。

Twitterマーケティングの基本はテーマが絞られており、ターゲットユーザ層にとってノイズは少ないほうがよい。
ターゲットユーザ層と投稿のテーマが違いすぎるとアカウントに対する期待値がミスマッチになる。
ブランディング戦略を考えたとき、過去現在よりも未来に視座をおく。
- 過去が現在の意思決定のバイアスとなっては駄目。これからどうしたいかにフォーカスする。
フォロワー数は大事だがあくまで手段の1つ。それを重視するより目的とマッチする方向性を考える。

ケースバイケースな面はありますが、開発者向けアカウントの分割は過去の施策と同様マーケティング要素よりもブランディング要素を重視したほうがよいと考えました。また、フォロワーを無理に増やすという方向性は考えず、技術ブランディング同様じっくりとアカウントを育てていく方向性でいこうと意思決定しました。

今回はエンジニアやデザイナーという社外の開発職に向けたコミュニケーション手段とそのコミュニケーション手段の改善、そして検索容易性を高めることが目的となります。またこれらの考えをまとめた社内ドキュメントを作成し、次のようなことを記載し、合意形成のプロセスを残すようにしました。

アカウントを作成した背景
分割することによる想定されるメリット・デメリット
対象となるスコープとnot スコープの明確化
アカウントの想定される使用用途

これは将来的にこのアカウントを破棄したいと考えたときにどういった課題を解決するために生まれたのか？を残さないと「何が目的で作成されたかわからないので破棄できない」ということが起こると考えたからです。

プログラムでもそうですが、一度書いたコードを捨てるのは書いたコードの何倍もの労力を要します。意思決定や合意形成のプロセスのログが残っていることで、誰かの意思決定をする後押しできる情報を残したいと考えました。

今後どうしていきたいと考えているか？

何度も書いているので耳にタコが出来そうですが、主な目的は2つになります。

社外のエンジニアとの潤滑なコミュニケーションのハブとなること。
- 対外的には開発者向けアカウントが出来たことでより社外のエンジニアやデザイナーとのコミュニケーションが円滑になっていくこと。
- 開催しているテックイベントなどで困りごとが発生した際に迅速で的確なサポートが行えること。
- マネーフォワードに興味があるエンジニアやデザイナーのかたにとってエントリーポイントとなるアカウントであること。
エンジニアやデザイナーにとって検索容易性が高いアカウントであること。
- ほしいデータに対して容易にアクセスできることで、自分たちが抱える課題に対する知見を得られること。
- 情報が集約されることによってより知りたい情報を知ることに専念できること。
- 技術的に学びがあり、成長を促してくれるようなアカウントに育つこと。

これらの効果を期待して、運用して活きたいと考えています。その他にもよりUserFocusなアカウントとしてエンジニア・デザイナーにとって有用な運用が行えるアカウントとして活用できることを期待しています。