気負わず、書く。私が意識してやっている、子育て中でもできるアウトプット術

連載の第1回では子どもができる前後での生活の変化や仕事への影響について、第2回では家庭、とくに子どもがいるエンジニアとして技術キャッチアップにどう取り組んでいるかというお話をしました。

どちらの回も男女関係なく、ライフステージの変化と限られた時間の中でキャリアと日々の生活でどうバランスを取っていくのかという話だといえます。前回は主にインプットをどうやっているのかについて、一例として私が普段何をどう意識して取り組んでいるか、隙間時間の有効活用という話をしました。

今回はインプットに対してアウトプットについての話をしたいと思います。

• keyboard_arrow_down 子育て中でもできる、さまざまなアウトプット
• keyboard_arrow_down ブログは未来の自分に残すメモ
• keyboard_arrow_down 多くの人に認知してもらうために効果的なイベント登壇
• keyboard_arrow_down イベントの主催者になるメリットは複数ある
• keyboard_arrow_down 自分のアウトプットはパブリックに公開するものだけじゃない

さて、「アウトプット」といったときに皆さんはどういったものをイメージするでしょうか。人によって具体的なイメージは違うでしょうが、「エンジニアの」と言った場合には以下のようなものをイメージする人が多いのではないでしょうか。

では、エンジニアの皆さんは何のためにこういったアウトプットを行うのでしょうか。個人だけで考えれば、必ずしも自分の知見を外部に発信する必要はないかもしれません。私の場合は「自分のやりたいことに近づきやすくなるため」、「自分の困りごとの解決に多くの人の知見を借りたいため」、そして「自分が得た知見が他の人の助けになれば」といったあたりでしょうか。

前者は自分がやっていることや、興味を持って取り組んでいることを発信しておくことで、その後の自分のキャリア形成を有利にできればという期待からです。自分がやっていることというのは、つまり自分がその時に興味を持って取り組んでいることとも言えます。興味があることを適宜アウトプットしておくことで、それが何かのきっかけで誰かの目に触れ、それがチャンスとなる可能性を信じているからです。私自身も実際にアウトプットがきっかけでチャンスを得た経験が何度もあります。大きなところでは、前々職から前職に移ったきっかけも、前職から現職に移ったきっかけも外部へのアウトプットの積み重ねが直接的なきっかけとなっています。

2つ目については、シンプルに自分が困っていることを発信するだけです。そうすると、それを見たその分野に知見のある人にアドバイスをもらえたり、同じ経験やエラーに遭遇したことのある人から教えてもらえるといったことが少なくありません。自分ができないことを、外に発信するのは勇気がいることかもしれませんが、一歩踏み出すだけでそういった良い点があります。ためらわず、勇気を出してみてはいかがでしょうか。

最後については、2つ目で助けてもらったのとは逆に自分が経験したこと、ハマったポイントやその対応策は他の人にも役に立つかもしれません。ただし、人の役に立つための記事を書こうと意気込んで書くことはプレッシャーにもなりますし、自分なんかの経験が他の人の役に立つなんてことがあるのだろうか？と思う人も多いでしょう。役に立つかはわからないけれどもし誰かの助けにちょっとでもなったらラッキーぐらいの感覚で書くといいと思います。ただし、各種公式ドキュメントのGetting Startedのようなものをやっただけのあまりにも初歩的な「やってみた」記事は個人的にはさすがに望ましくないと思います。そういったものであればそれを進めるにあたって困ったところなどについて記載があるといいと思います。

なお、いずれも仕事に関係する内容であったときは適宜情報をマスクするなり、汎用的な内容に置き換えるなどの配慮が必要となります。

さて、私が実際にやっているアウトプットとしては、先の例ではブログ投稿、発表・登壇が主なものになります。加えて、発表や登壇の場を自分で作つくるといっては偉そうですが、自分自身で勉強会やミートアップを開催しています。

このように、私の場合はアウトプットといっても、インプットで学んだことの知識の定着などはそれほど考えていません。そのため、個人開発をすることは最近ではほとんどないです。これは単に個人で作るプロダクトのアイデアが思いつかないといった悲しい事情もあります。OSSプロジェクトへのコントリビューションも同様に最近ではほとんどすることはないのですが、こちらは仕事の一貫でたまに行うことがあります。

ここからは、先にあげたものを実施するにあたり、自分がどういうスタンスや考え方でやっているかを紹介したいと思います。

まずはブログについてです。ブログを書くにあたり、自分よりも立派なアウトプットをしている人は世の中にはごまんといます。そうすると、どうしてもそれらの方々の発表内容などと比べて「自分のブログなんて……」と考えてしまい、つい発信を控えてしまう人もいると思います。

ですが、これに関しては、私は一切、気にしなくていいと考えています。もちろん間違いだらけのものは論外ですが、実際に私のブログも、特定の技術トピックやテーマを深掘りするというよりは「未来の自分に残すメモ」という感覚で書いているため、それほど技術的なレベルが高いものがあるわけではありません。また、技術的な内容だけではなく、世間で話題になっていることに対する意見や、自分の考えを綴ることもあります（いわゆるポエム）。それ以外にも、自分が読んで良かった本や買ってよかったものを紹介していたりと、自分のメディアなので自由にやっています。

書く内容にこだわらず、それでも書くことでチャンスを得られた

ブログのアクセス数についても、もちろん多いと嬉しいですが、それほど気にはしていません。更新回数についても同様です。2年前、3年前は年間で50本程度でしたが、昨年は13本とかなり少なくなりました。自分の場合、ブログに技術について書くときは、仕事との関連性が高い場合が多いです。先述のようにブログ記事は自分用のメモも兼ねているので、必然的に業務でコードを書いたりすることが多い時期だとブログを書くことも増えるのです。もちろん、仕事の内容をそのまま書き記すわけにはいかないので、内容として汎用的なものにしたりするなどしています。それでもやはり業務でコードを書く頻度が下がると、やはりネタが減るということなのでしょう。

なお、実際にブログに書いた内容がきっかけとなって、出版メディアへの寄稿を依頼されたり、企業のとある企画へ参加を打診されたりと、ブログを書いてなければ巡り合うこともなかったであろう機会にも恵まれました。これらはそもそもブログを書いていなければ得られなかった機会なので、書いた意味はあったのだと思います。とはいえ、私の場合はこういったことが数多くあるわけではありません。

執筆活動は隙間時間を活用して行う

問題は、ブログを書く時間をどう捻出するかですが、これには2パターンあります。

まず、お気持ち表明のようなポエム的な内容の場合、インプットと同様に隙間時間にスマホで書き連ねて、最後PCで見直して公開します。このパターンの場合はサンプルコードなどもないので、わりとスマホだけで完結させられる場合も多いです。一方で、技術的な内容の場合は最初の調査段階の資料や実際に検証に使用したサンプルコードなどをメモとしてブログの下書きに適宜に残しています。そして、ある程度、記事内容としてまとまったものになりそうになったら、その乱雑なメモを文章として清書します。この清書も多くはスマホを使って隙間時間にやっていることが多いです。こちらも最後はPCで確認したり調整したりします。

次は勉強会やカンファレンスでの登壇です。こちらはCfP（Call for PapersまたはCall for Proposal）などの公募に自分で応募する場合と、イベント主催者などから依頼される場合があると思います。登壇についても、ブログ同様に立派な発表をしようとはあまり思わないようにしています。特に自分で応募する場合は「こんな内容で大丈夫かな？」と自分で思ったとしても、そのテーマの分野に明るくない人には自分が思っているよりも有用だからです。そういう意味では、難易度よりもテーマのニッチさを多少意識しています。ただし、ニッチすぎると需要が限られてしまうので、バランスが難しいところではあります。

人から依頼される場合、テーマがすでにあるケースが多いので、この限りではありません。なお、私は人から依頼されたものはスケジュールの都合や、依頼内容について自分がまったく話すことができないといったケースを除いて、断らないようにしています。ただし、スケジュールについては前回と書いたように、土日祝日のイベントであれば子どもの面倒をみるため基本的にお断りします。

このイベント登壇ですが、それが専門の仕事でもなければそれほどの数はできないと思います。前職の頃は仕事の一環でもあったためかなり多かったのですが、現在は年に数回程度と大幅に減りました。

ただし、やはりイベント登壇は効果的です。前職時代は多い時で年間30回から50回と、それなりの数を登壇していた結果、多くの人に認知をしてもらうことに繋がり、それがきっかけで色んな機会を得られました。先述したように、過去の転職もイベント登壇がきっかけになっていると言っても過言ではないです。また、イベントでの登壇は、発表した資料をSpeaker Deckなどのスライド共有サイトなどで公開することが多いと思います。自身の登壇前後に登壇内容の資料を公開することで、それが後々にも多くの人の目に触れることになります。単に登壇して終わりではなく、アウトプットとして残すことで長く認知度を上げるのに一役買ってくれるでしょう。

登壇資料づくりは、やはり時間がかかるものです。内容にもよりますが、個人的にはブログ以上に時間がかかることのほうが多いです。特に完全な新作だと、とても時間がかかってしまうため、実はブログなどで過去に書いたネタを利用しているケースも多くあります。ブログなどで過去に書いた内容を軸に、その後のアップデートをしたりして、内容を膨らませるという方法を取っています。

同じネタで話すことに抵抗を感じる人もいるかもしれませんが、実際にはそのイベントで発表を聴いてくれるほとんどの人は、自分のブログを細かく見ていないケースが多いと思われますので、これも特に気にしないようにしています。

また、他の人が開催する勉強会やカンファレンスで発表することもいいのですが、私の場合は、それに加えて自分の興味のあるテーマで自分自身が勉強会を開催してしまうことも少なくないです。こういったイベントを自分で開催することの最大のメリットは、自分自身が開催するので自身の登壇枠を確保することが可能ですし、そのテーマで話を聞きたいと思う人に依頼して、登壇してもらうことで自分にインプットすることも可能だからです。

勉強会やミートアップの開催というと「大変そう」というイメージを持たれる方も多いかもしれません。企業のカンファレンスイベントならともかく、小規模なものであれば意外となんとかなります。

不安な方は人数を30人くらいの小規模から開催してみるといいのではないでしょうか。とはいえ、初めてだと会場の手配だとかどうすればいいかわからないことも多いと思います。まずは経験者と一緒にやってみるといいと思います。困ったらXのDMなどで私に相談してくれれば簡単なアドバイスをすることも可能です。

自身でイベント開催をすることのもう1つのメリットは、開催日や開催時間を自由にコントロールできるという点もあります。私の場合は土日祝日はそういった時間にあてないと決めているのは前回にお話した通りです。そのため、土日祝日は避けて開催しています。開催時間については、オフラインだと会場の使用可能な時間帯に強く影響されるので難しいですが、オンラインであれば家庭の状況を鑑みて時間設定することが可能です。

実際、コロナ禍にオンラインイベントをよく開催していた時は、当時の家庭の状況から21時開催にしていることが多かったです。集客の問題はありますが、いくつかの時間帯で試したりアンケートを取ったりしてみた結果、時間帯が理由で集客が大きく落ち込むといったことは、私がやっている規模感、レベル感のものだとほとんどありませんでした。

今回は、エンジニアとしてのアウトプット、私が日常的に意識してやっていることについてお話させていただきました。何らかの外部発信をすることを中心に話をしましたが、そもそも「アウトプット」は必ずしもブログやイベント登壇だけには限りません。

もっと広い意味で「アウトプット」といった場合、これらの外部発信などパブリックに公開するようなものだけではなく、自分自身が思いついたことをノートに書き出していくことや日報なども自分のアウトプットと言えると思います。Xなどのソーシャル上でのライトな投稿も、ひとつのアウトプットだと言えるでしょう。書き出すことで脳内が整理されることも多いです。

自らの考えなどを話したり、書いたりすることもがアウトプットと言えるので、固く考えて身構えず、まずはなんでもいいので自分が考えていることを書いたり、人に話しをしてみることから始めてはいかがでしょうか。