この記事は、Money Forward Engineering 1 Advent Calendar 2023 21日目の投稿です。 20日目は宮村（みやむー） @miyamura.koyoさんで【Ruby】今年も福岡拠点で ISUCON13 に参加しました！でした。
こんにちは、fujiyamaorangeです。普段は福岡拠点にてマネーフォワードPay for Businessのフロントエンド開発を担当しています。
※本記事内で登場するアウトプットは「技術記事を書くこと」を指します。
いつもならこういったタイトルの記事では最初に結論を持ってきて、それから詳細を説明していくのですが、今回は最後まで読んでいただきたいため、その形式を取らずに進めていきたいと思います。またいつもよりも自分の書きたいこと、考えていることを全面に押し出して書いていきます。
アウトプットへのこだわり
前提として僕は2023年春に新卒としてマネーフォワードに入社してからZennへ6つ、会社のテックブログへ1つ技術記事を投稿しました。学生時代を含めれば合計で19個の技術記事をZennに投稿しました。
そしてありがたいことにいくつかの記事はZennのトレンドに載るなどしてそれなりに多くの人に読んでいただけています。
それらの経験を通して感じたアウトプットをするメリット、そして僕なりのアウトプットの方法・コツを紹介できればと思います。
アウトプットするメリット・理由
結論から言うとアウトプットすることはメリットしかないと感じています。実際に僕は技術記事を公開してから「もう書きたくない」と思ったことは一度もなく、むしろ「また書こう」と何度も思いました。
それは以下のようなメリットがあったからだと思います。
インプットをする習慣がつく
アウトプットをするために自然とインプットする習慣がつきます。アウトプットするということは自分の知っている情報を共有するということであり、それを見たり聞いたりした人はあなたのたどり着いた情報に同じようにアクセスできるということです。
アウトプットすることで「他の人はあまり知らない秘伝のタレ」的な情報を自分から減らすことになります。そうすると自然と自分の知識が浅薄なものに感じてきます。その結果またインプットしようと思うサイクルが生まれるのです。
また外部に公開することで、自分だけが見るためにまとめておくのとは違って緊張感があり、より詳細な情報を調べるようになります。その過程で情報の取捨選択を行い、正しい内容であるか精査するようになるため、結果的に確実な情報にたどり着けるようになります。
自分の知識を貯めておける
これはアウトプットすること自体とは少しずれてしまいますが、副次的なメリットとして「過去の自分の記事が参考になる」というものがあると思っています。 皆さんも自分用にまとめていたメモに助けられた経験があるのではないでしょうか。
それらを技術記事にしておくことで過去の自分が知らなかったこと、つまずいたポイントを把握でき、再度同じ問題に遭遇した時にすぐに解決することができます。
今まで遭遇したすべての問題に対して解決策がすぐに出せる人はそう多くないと思うので、技術記事として残しておくことはこの点において非常に役立つと思っています。
自分や会社のことを知ってもらえる
技術記事を書くことで「この会社にはこういう技術を使う人がいるんだ」と認識してもらうことができます。 さらにそこからSNSなどでつながり、話が広がることもあるかもしれません。僕も実際に、社外の友人から「記事を見たよ」と何度か言ってもらえることがありました。
このように、記事を公開することは個人のプレゼンス向上にもつながるだけでなく、社名を公開することによって会社の発信力に対して貢献することができます。
アウトプットの方法・コツ
ここからは僕が実践しているアウトプットの際の方法とそのコツを紹介していきます。
アウトプット駆動
僕が継続的にアウトプットできている要因のひとつに常にアウトプットのことを考える、アウトプット駆動が挙げられます。
開発の際につまずいたときや悩んだときには「これネタになるかも」と考えながら業務をしています。業務で実装する処理や設計・ライブラリでハマったことは他のエンジニアの方もハマる可能性があるので、技術記事を書く価値は十分にあると思っています。
常にアンテナを立てておくことでできるだけ「ネタがない」という状態にならないようにしています。
短期間で仕上げる
僕は時間が経ってしまうとモチベーションが徐々に下がっていくタイプなので、技術記事は書こうと思ってからなるべく早く完成させるようにしています。
実際にドラフトのまま数ヶ月が経過した記事もありますが、「技術のトレンド過ぎ去ったかなぁ」と思ってしまい、いまだに公開できていません。それくらい書き始めてから公開するまでの時間というのは大切です。
短期間で仕上げるために以下の手順で作成しています。
まず全体のアウトラインを考える
まずは記事の中でどんなことを書きたいか、どの範囲まで書きたいかなどを考慮しセクションの構成を考えます。ソースコードや結論をどこに配置するか、どういったテーマで書くかなど思考の流れがわかりやすいように構成します。
各セクションについて書ける部分から書いていく
アウトラインが完成したら次に各セクションについて書きやすい部分から書いていきます。
これが意外と効果的で、書ける範囲から書き進めていくことで進捗が生まれ、完成させようというモチベーションにつながります。その結果、記事を公開できる確率が上がりました。
最後に読み返してタイトルを決める
よく小説家がタイトルを最初に決めるか最後に決めるかで議論をしますが、僕は技術記事を書くとき、タイトルは一番最後に決めます。
技術記事においてもタイトルは非常に重要で、読んでもらえるかどうかの最初で最後の分岐点となります。 そのため記事をすべて書き終えたあと、内容を読み返しながらその内容を端的に表すキャッチーでわかりやすいタイトルを考えます。
時間をかけて書いたものなのでせっかくならより多くの方に読んでもらいたいですよね。
気をつけてきたこと
過激すぎるタイトルは使わない
記事のタイトルは毎回慎重に決めているのですが、その際に過激すぎるタイトルはつけないようにしています。過激なタイトルは人の目を引くことができる反面、信頼感が薄れ、肝心の中身をきちんと見てもらえない可能性があるからです。
僕が書いてきた中で一番過激なのはおそらく『【保存版】「そのuseEffectの使い方あってる？」と言われる前に』でしょう。個人的にはギリギリ過激でないラインだと思っています。
コメントには真摯に対応する
技術記事を書いているとたまにコメントで指摘をいただくことがあります。 時にはかなり切れ味の良い、いわゆるマサカリ(技術的な指摘)と呼ばれるようなものが来ることがありますが、そんなときも焦ってはいけません。真摯に受け止め、自分でも調査をするべきです。そうすることで自分の知識に厚みが出てきます。
一方で指摘というよりも悪口、誹謗中傷やマウントに近いコメントもあるかもしれません。これらのコメントが投稿されるケースでは前提となる条件が不足していたり、対象となる主語が大きい可能性があります。 そのため、できるだけ前提条件を明確に示したり、不用意な主語を使わないことで避けることが可能です。
それでも投稿される悪口、誹謗中傷などに関しては無視してしまうのも一つの手です。そっとブラウザと目を閉じ、メンタルを乱さないようにしましょう。
不確実な情報はそのことを表明しておく
記事を書く上で、すべて詳細に完全な情報だけを提供するのは難しいと思います。その際は「調べた限り」、「間違いなどありましたらコメントお願いします」などと一言付け加えておくと安心できます。
記事を書こうか迷っているあなたへ
僭越ながらここからは、アウトプットするにあたり不安があり、記事を書こうかどうか迷っている方へ向けて、僕なりのエールを送ろうと思います。
書いても読まれないんじゃないか
いいえ。そんなことはありません。あなたがつまずいたポイントは他の人もつまずくでしょうし、その人にとっての助けとなります。
誰か1人でも読んで、良いと思ってくれればそれでよいと考えています。以前投稿した『【Rust】SWCプラグインを作って得た学び』もSWCに関するかなりニッチな記事ですが少数の人にはきちんと届いています。
マサカリが飛んでくるんじゃないか
指摘してもらえることはありがたいことです。積極的に自分の意見を発信し、多くのフィードバックをもらうことで自分だけでは収集しきれなかった情報を補完することができ、エンジニアとしての力になると思います。僕はそう信じています。
しかし公開する前には必ず自分で何度かレビューすることが必要です。心配な場合は、チームメンバーにレビューしてもらうのがおすすめです。
おわりに
ここまで読んでくださりありがとうございます。これから記事を書こうと思っている方、書くか悩んでいる方などの参考になれば嬉しいです。
