2024年2月5日
Javaスペシャリスト
九州芸術工科大学 芸術工学部 音響設計学科を8年で退学後、フリーランスでの活動を経て、現在はLINEヤフー株式会社に勤務。著書に、『プロになるJava 』(共著、技術評論社)、『みんなのJava OpenJDKから始まる大変革期! 』(共著、技術評論社)、『創るJava』(マイナビ)など。
X(@kis)
ブログ きしだのHatena
こんにちは、きしだです。
この連載ではエンジニアとしてキャリアを作っていくための勉強法についてを書いていきたいと思います。
初回の本記事では、「アウトプット」について考えてみます。
レバテックLABでも、アウトプットについて書かれた記事がいくつかありますが、ここでは自分のためのアウトプットという視点から考えてみます。
もちろんアウトプットするのであれば、見る人の役に立つほうがいいと思います。けれども、初めてアウトプットする時期にはまだ読者も少なく、「人の役に立つぞ!」と気合をいれて記事を公開しても誰も見てなくてヤル気をなくすということになりかねません。
そこで、まずは自分のためだと思ってアウトプットしてみて、そうやってアウトプットしたものが結果として他の人にも役にたったというスタンスをおすすめします。
現在はLINEヤフー株式会社に所属していますが、今回の記事は「アウトプット」を扱うので、文章などのアウトプットや登壇をどういうきっかけでやってきたかという面からの自己紹介をしてみます。
ネットに「ホームページ」という形で文章をアップしはじめたのは、1997年7月くらいのようです。そのころはC++Builderという開発環境を使っていたので、C++BuilderでXMLを扱う方法などを書いていました。また、ちょっとしたアニメーションを行うJavaアプレットもいくつか公開しています。Java 1.1が出たばかりの頃ですね。
ホームページには更新履歴を書いていたのですが、そこに日々の出来事を交えるようになり、まだブログという言葉は生まれていなかったのですが、ブログのような形のWeb日記に発展していきました。ちなみにブログという言葉が生まれたのは1999年のようです。
2002年、知り合いがやっていたJava講師のアルバイトを引き継ぐ形で、Javaを教えることになりました。いい感じのテキストがなかったので、自分で書いてホームページに載せて、それを使って教えるということをやっていました。そのころは教えられるほどJavaのことを知っているわけではなかったので、勉強しながらまとめるという感じになっていました。教えるというプレッシャーはかなり強く、そこでかなりJavaについての知識を固めることができました。
また、そうやってまとめたテキストなどを目にした出版社の方から連絡を受けて、2003年にWEB+DB PRESSで記事の執筆、2005年にはJavaを教える際に使ったテキストをベースにした「創るJava」という書籍を出版しています。
そして、2005年にSun Microsystemsの方から声をかけていただいて、Javaの大規模イベントであるJavaOne東京で登壇させてもらいました。筆者は福岡に住んでいますが、これをきっかけに東京のイベントに参加するようになりました。
当時はフリーランスでしたが、そこから東京の仕事をもらうことも増えました。東京のエンジニアとの交流が増えたことで、勉強のモチベーションがあがって今に繋がっているとも感じます。東京のエンジニアがはてなダイアリーでブログを書いていたこともあって、筆者もはてなダイアリーでブログを書き始め、はてなブログにそのまま移行して現在でも続けて書いています。現在の会社に入ったのも、東京の勉強会に参加した縁によるものが大きいです。
こうやって見返してみると、アウトプットがキャリア形成に強く影響していることがわかります。ただ、これはネットの人口の増加や技術発展とともに活動を広げていったという側面があり、ネット人口が飽和して技術も成熟した現在、そのまま同じことができるわけではありません。
とはいえ、アウトプットすることが持っている効果はあまり変わっていないと感じています。
ひとくちにアウトプットといっても、どういうものがあるのかまとめてみます。
一番手軽なアウトプット手段がX(Twitter)などマイクロブログ系SNSです。Xの空気があわないという人はBlueskyなどでもいいでしょう。
SNSではアウトプットをあまり気負うことなく行うことができます。何を勉強しようとしてるか、試そうとしてるか、といったことを投稿するのがいいと思います。
ただ、SNSでは何をどのようにアウトプットするかの他に、タイムラインをどう構築するか、どういう人をフォローするかというのも大切になります。興味ある投稿をみつけたら、その投稿に対して「いいね」などの反応をしている人をフォローしていくといいでしょう。
ここで注意すべきなのは、開発に関することだけを書いていると、書くほうだけではなく見ているほうも疲れてしまいます。そのため、ごはんや他の趣味など生活に関することも混ぜて投稿していくと続きやすくなります。また、生活を混ぜて投稿していくことには他の効果もあって、実際の生活にも開発が混じっていくようになることです。つまり、SNSへの投稿は、アウトプットの習慣化のためという側面があるということです。
SNS上での議論もかなり参考になりました。建設的な結論を出すための議論もうまくなったように思います。よく「SNSは議論に向かない」といわれることがありますが、前提を共有していない人と議論が始まることがあるということではないかと思っています。この場合は、その議論を対面や他の媒体で行ったとしても、おそらく議論は難しいのではないでしょうか。エンジニアは議論がうまい人が多く、前提も共有しやすいので、建設的な議論が比較的行いやすいように感じています。
SNS上での議論で筆者が気をつけていることは「相手も、相手の観点から正しいと思うことを言っている」ということです。会議などでの同じ目的に向かって意見を出し合う議論と違って、SNSでの議論では異なる意見のすり合わせになりがちです。そこでは、なんらかの異なる視点や知識が前提になっているので、お互いのどこに差異があるかを見つけるようにやりとりすると、建設的な議論になりやすいです。一方で、議論の内容ではなく議論相手の話題が出る場合は建設的な議論になりにくいので気をつけましょう。例えば「あなたはわかっていない」のような発言は控えたほうがいいですし、相手がそのような発言をしてきたなら軌道修正は難しいので議論を切り上げてもいいと思います。
アウトプットとして主要になるのは、ブログでしょう。
SNSで投稿を続けていると、一つのテーマに関してある程度まとまった内容になることがあります。こういったものはブログなどにまとめておくといいでしょう。
SNSでの投稿は他の日常的な投稿と混ざってしまうので、まとめておくことで扱いやすくなります。また、Googleなどでの検索に引っかかりやすくなるため、同じ内容で困っている人への助けにもなりやすいです。こうした積み重ねの効果が表れやすいのがブログだと思います。
「大筋はすでにSNSに投稿しているので、あとはまとめるだけだな」と思っても、ブログとして書くには詳細が足りなかったり、正確な記述であるか確認するために、実際は結構な時間がかかります。しかし、これがより深く調べるきっかけにもなり、他の人が見たり自分で後で見返すときにも読みやすい文章になります。
そのためにも、他の人が試しても同じようになるよう、つまりあとから自分で試せるように書いておくことが大切です。
とはいえ、あまり時間をかけすぎるとアウトプット欲がさめてしまって、下書きのままお蔵入りというということにもなるので注意が必要です。
イベントなどでの登壇はいいアウトプットになります。また、登壇者としての認知が高まり、自分がその技術に興味があることを強く認識してもらえます。
反応を直接感じることができるので、アウトプットすることで得られるものはブログよりも大きいと思います。登壇後に、よかったことやちょっと違っていたことの指摘もSNSやブログなどよりも得やすくなります。ただ、オンラインイベントの場合には参加者からの反応はほとんど得られないと考えたほうがいいです。
登壇資料には理解しやすい構成が求められるので、ブログよりもわかりやすさに気を使う必要があります。時間も限られるため、話題の取捨選択も重要になります。その結果、話を組み立てる能力が高まるはずです。
大きなイベントになると多数の人の前で話すのでプレッシャーがありますが、小さなイベントで少人数が自分に集中しているというのもまた別のプレッシャーがあると思います。
大きなイベントでの登壇枠は限られており、また頻繁に開かれるわけでもないため登壇へのハードルは高いです。けれども、小さなイベントでは登壇者が足りないことも多く、時間枠の制約もゆるいため、登壇したいと手をあげれば登壇できる可能性が高いです。
登壇のいいところは絶対的な締切があるところです。登壇の登録をしてしまったらやるしかないというのは、筆者のようなだらだらやりがちな人間にはとてもいいプレッシャーです。
自分が主催する勉強会もアウトプットといえるかどうかは微妙ですが、ここではアウトプットに含めておきます。
登壇できるネタがあっても、近所でよさげな勉強会がないというときには、自分で勉強会を開くしかないということになります。
勉強会を主催するには、ある程度は登壇で話せるネタは必要だし、会場を借りる伝手も必要です。また、自分の他に登壇してくれる人を探す必要もあります。
参加者も自分自身で集める必要があります。イベントサイトをつくってX(Twitter)に告知するだけではなかなか人は集まらないので、他の勉強会に参加して直接告知をし、集客することが大切です。集客だけでなく、同じ会場を借りれるかどうか主催者に聞いてみたり、運用のノウハウを聞いてみるのも参考になると思います。
アウトプットとして、最近では動画投稿という選択肢もあると思います。
ただ、ここで話題にしているような、勉強のモチベーションとしてのアウトプットとしてはあまり向いていないように感じています。
というのも、動画投稿の準備の段階でブログ相当の資料はできているはずなので、そのままブログとして公開すればいいということになるからです。その後の撮影や編集などは純粋にアウトプットのための作業となりますが、この作業量がかなり大きく、負担になります。
そのバランスを考えると、動画投稿として継続可能なのはニュースを軽く紹介するような内容になっていきますが、それでは自分自身の勉強としては物足りなくなります。
もちろん、動画投稿自体は楽しいし、人の役に立つものでもあります。また、活動としてアウトプットの比重を高めたいという場合には、動画は重要なコンテンツになっています。動画投稿をやる場合は「動画投稿をやりたい」ということをモチベーションにするほうがいいでしょう。
動画ではなくPodcastでの音声配信であれば、コンテンツ作成の負担は低くなります。音声配信はだれか他の人と一緒にやりやすいので、話を聞きたい人を誘って音声配信すれば自分の勉強になります。もちろん、そういった話は他の人も聞きたいはずですね。ただし、話を盛り上げるには事前準備が必要です。これまでの経歴、今やってること、これからやりたいことなどを話すと思いますが、事前調査で大まかに把握して細かいことを確認していくという感じになるのがいいと思います。
OSSや個人プロダクトは、ここで話題にするような勉強のモチベーションとしては適していません。
むしろ、勉強の目的としてOSSに参加したり、個人プロダクトを開発したりを設定することになると思います。
というのも、OSSへの参加や個人プロダクトの開発は得意とする分野の影響が大きくなります。また、ソフトウェア開発以外の趣味や生活の環境によっても作りたいものが変わります。ある程度まとまった時間を継続的に確保する必要もあります。そのため、一概に「OSSに参加するといいよ」「個人プロダクトを作るといいよ」という話はできません。
開発作業や趣味、日常の生活の中で困ったことや、もっと改善できることをソフトウェアで解決できそうなときに、OSSや個人プロダクトとして開発できるよう勉強をしていく、という考え方のほうが適切に思います。
ブログを書くためにライブラリを試しているとバグをみつけることがあります。そういったときにバグ報告するとか、すぐに直せそうなバグであれば修正してプルリクエストを送るとか、小さなことから始めてみるのがいいでしょう。もし業務プロダクトの開発中にOSSのバグを見つけた場合は、複雑なバグであることが多いです。業務プロダクトで使っているということは、ある程度成熟した機能であることが多いからです。その場合は、業務としてどう対処するか考えることになるはずです。
アウトプットの最後は書籍です。書籍といっても、普通の書店で売られるような本は書きたいからといって書けるものではありません、しかし、最近ではAmazon Kindleダイレクト・パブリッシングや技術書典など、個人で書籍を販売する手段も増えています。技術書典は年2回程度開催されている技術同人誌の頒布イベントですが、電子版であればオンラインでいつでも買えるようになっています。他にも技術同人誌を頒布できるイベントは開かれているので、興味があれば探してみるといいでしょう。
一冊の本にまとめるというのはかなり大変な作業ですが、ちゃんとまとめて世に出すということは大切なアウトプットです。ブログなどでネタがたまったり、自分の興味のある技術をもっと世の中の人に使ってもらいたいということがあれば、チャレンジしてみるのもいいと思います。
では、次にアウトプットすることでどのような効果があるかまとめてみます。
まずは、アウトプットしようとするときに細かく調べるということがあります。SNSでの発信の場合にはそれほど細かく調べませんが、それでも一旦検索して確認するということを行うことが多くなります。
ブログであれば、より細かい記述をすることになります。情報へのリンクがどこが適切か探す過程で、公式ドキュメントなど適切な情報源になじんでいくこともできます。逆にいえば、ブログに貼るリンクはできるだけ公式に近い情報にしましょう。
登壇するときの資料作成や練習で説明を考えていると、自分がその技術について本当にいいと思っているかどうかという確認になったりもします。
どのアウトプットでも、実は説明できるほどわかってなかった、ということの再確認もできます。
そして、全体的に理解が深まっていきます。
この時点でかなり知識が整理され、精度が高まってるはずなので、外に向けて公開しなくても構わないかもしれません。筆者も、時間をかけて書いたものの公開していないブログエントリがたくさんあります。ただ、人に見せることを前提に書くというプレッシャーは大事なので、公開することを考慮しながらまとめていくほうがいいと思います。
アウトプットすることで気になるのは、周りからの反応です。ここには、いいものも悪いものもあります。
役に立ったとか面白かったという反応はうれしいもので、次のアウトプットへのモチベーションにもなります。
ただ、自分にとって役に立つのは誤りの指摘です。そういった指摘があって納得のいくものであれば、可能な部分については反映しましょう。補足を入れるだけでもいいと思います。
継続してアウトプットを行っていると、同じ興味をもつ人から認識されやすくなります。そうすると、新しい情報を教えてもらえることもあります。イベントに参加するときの自己紹介もやりやすくなりますね。
そして、これは特殊な場合かもしれませんが、継続してアウトプットを行っていると、まわりが変わっていくということもあります。例えば、気に入ったプロダクトがあるけど日本語の情報がまったくないというときに、そのプロダクトを紹介するブログを書き続けていると、そこからプロダクトを知って使い始めるという人が出てくるかもしれません。
そこまでいかないにしても、アウトプットというのは、世界をほんのわずかですが変える力があります。
気になっていたことについて調べてアウトプットしてしまうと、その事柄に関して考えることがなくなり、次に進めるようになります。
また、時間がたって同じことで悩んだときに、自分のブログなどを見返すことで解決につながるため、同じことで悩む必要がなくなります。
ただ、「解決方法がみつからなかった」というブログを書いたときに、後日Web検索から自分のブログにたどりついたときに、ちょっと悔しい気持ちになることがあります。
では、具体的にどんなことをアウトプットすればよいのでしょうか。 筆者が書いている内容について掘り下げてみます。
開発作業に携わっていると、一番アウトプットしやすいのはその開発作業中に得た知見ということになります。
ただ、業務中で得た知見というのは、外に出していいかを考える必要があります。契約や就業規則を必ず確認してください。
いずれにせよ、外に出せるのは業務内容とは直接関係のない、プログラミング言語やフレームワーク、汎用アルゴリズムについてになります。これはアウトプットを見る側にとっても役立てやすいということにもなります。
トランザクションやキャッシュ処理、ログなど、高負荷であることや本番運用ならではのことであれば、業務でのサーバー構成も関わってきます。開発プロセスであればチーム形式から説明が必要です。こういったことは、会社の技術力や業務の雰囲気を示す機会にもなるので、会社のブログに書くのが適切でしょう。
もしライブラリやフレームワークのバグを見つけたのであれば、ブログなどに書くだけではなく開発元に報告しましょう。可能であればそのバグを修正してプルリクエストを投げれば、フレームワークへの貢献にもなります。
一方で、業務に関係ないことであれば、基本的になんでも個人の裁量で書けるはずです。
ただ、ここでも外に出していいかを考えねばならない場合もあります。たとえば、ゲームエンジンにUnityを使って開発している有名ゲーム会社に勤めていることが知られていて、別のゲームエンジンであるUnreal Engineの勉強していることをアウトプットしてしまうと「あの会社はUnreal Engineに乗り換えてるぞ!」と騒ぎになりかねません。ゲームや組み込みなど機密性が高いプロダクトに関わる場合は細心の注意が必要です。ゲームや組み込みに関わる人のアウトプットが少ないのは、こういった事情によるところも大きいと思います。
IT系に転職を考えて勉強中であれば、必然的に業務とは関係ないことを書くことになりますね。
こうした場合、書けるテーマは大きく分けて、今後の業務に関係がありそうなことか、今後の業務に関係なさそうだけど面白いと思っていることか、この2つになります。
面白いと思っていることを書くわけなので、面白いアウトプットになるのは圧倒的に後者です。ただ、業務に関係ない場合、読んでくれる他の人にとってもあまり業務に関係なくなるため、ページビューが伸びにくくなります。でも気にせずやりましょう。面白いので。
いろいろと書いてきましたが、この記事に興味を持ったということは、アウトプットに興味がある人が多いと思います。
一度何かを書いてみて、外に出してみないとわからないことが多くあります。
ぜひ、なにか書いて公開してみてください。続ければ何かが変わっていくはずです。
結局、アウトプットで大切なことは「継続すること」なので、自分にとって一番継続しやすい形を模索しながらやってみるといいと思います。
関連記事
人気記事