1. はじめに
スキルアップには発信活動が良いと言われていますが、3年前の私(38歳)は、技術記事を書いた事も社外発表した事もありませんでした。
そんな私が発信活動を始めたことで人生が劇的に変わりました。
その前の十年以上より、発信活動を始めてからの3年間の方が圧倒的に成長できました。
発信活動をきっかけに、Developers Summit 2020 KANSAI でベストスピーカー賞1位、Software Designで連載執筆、Microsoft Build 2022で発表などの機会をいただきました。
その中で様々なエンジニアと楽しく交流したり、多くの人から感謝されたりなど、人生が楽しくなりました。
本稿では、楽しく成長するために、誰でも始められる具体的な方法を紹介します。
長いので要点を知りたい人は太字のみお読みください。
本稿の内容は Microsoft Build 2022 というカンファレンスで発表した内容です。
動画で視聴したいと思っていただけた場合は以下のページから視聴できます。
Microsoft Build のセッションページ
2. 成長することの必要性
2.1 数年前の私
今でこそ明かしますが、ぶっちゃけプライベートで勉強するのは嫌でした。
けっこう残業していたので、仕事で疲れてプライベートでさらに勉強するには、かなり気力が必要な状態でした。
それでもプライベートで勉強していた時期もあります。でもそれは、仕事で必要にせまられて、プライベートでしぶしぶ勉強していました。
ちなみに社外での勉強会やイベントになぜ参加しなかったかというと、そもそも社外イベントの存在を知らなかったからです。
でも、仕事は真面目に頑張っていました。
私はプレイングマネージャーとして、ある自社製品開発の管理と技術の両方を頑張っていました。
そこそこ残業していましたが、開発しているプロダクトが好きで、ユーザーの要望をもとに企画する所から、アーキ設計やテスト戦略など、自分が決められる裁量が広く、仕事にやりがいを持っていました。
2.2 娘(1歳)を見て涙
ただ、ある時、何のために働くのかを考える出来事がありました。
人生の中で仕事が最も大変でめちゃめちゃ忙しい時期がありました。
その頃は、娘が1歳で、家庭においても育児でなかなか大変な時期でした。
この時期は、1年以上、友人と会う機会もすべて断っていて、それほど心の余裕を無くしていました。
正直、娘とあまり遊べていませんでした。
そんなある日、娘が雑に折られた折り紙で一人で遊んでいるのを見かけました。
図のように、裏側の白い部分が見えているような雑に折られた折り紙でした。
よく見ると、それは数ヶ月前に、私が心の余裕がない中で、雑に折ったペンギンの折り紙でした。
そんなものを娘がずっと大事にして、一人でそれで遊んでいるのを見て、自分は何をしているんだと思って泣きました。
その時、私は自分にとって大切な事は何なのか、働く理由を考え直しました。
自分がマネージャーのプロジェクトを成功させる事や、社会的な地位や、収入の維持よりも、大切な事がありました。
家族との時間を大切にして、家族と幸せになる事の方が何万倍も大切だと思いました。
だから、上司に相談してプロジェクトの計画を変更してもらい、自分の業務量も減らしてもらい、家族との時間が確保できるようにしてもらいました(ホワイトな会社で良かったです)。
その頃から、成長する事の必要性を感じ始めました。
家族との幸せを維持する上で、自分はとても危うい状態である事を痛感しました。
今のままの自分では、今のチームでしか役に立たない人材であり、会社に依存し過ぎていました。
当時の職場環境はホワイトだったから良かったものの、常にそうである保証はありません。
そもそも、この変革の時代において、定年まで1つの会社で働ける保証はどこにもありません。
家族との幸せを安定して維持するためには、成長して自分の市場価値を高める事が必要だと思いました。
2.3 成長することの必要性まとめ
まずは自分の中で「成長する事の必要性」を明確にすると、成長するためのステップが始めやすいと思います。
3. 成長するためのファーストステップ
3.1 まず技術記事を書こうとしたがネタがない
家族との時間が確保できるようになって少し余裕が出来た頃、プライベートで個人開発アプリ(スマホアプリ)を作ってみました。
「プライベートで勉強する事」は嫌でしたが、「作りたいと思ったものを作る事」は楽しかったのです。
その個人開発アプリが作れたのは、世の中のエンジニアの人たちが書いてくれた技術記事のおかげでした。
だから、技術記事を書く事に興味を持ちました。
そして、スキルアップするためにはアウトプットが良いと言われているため、技術記事を書けば成長して市場価値も高められそう！と思いました。
でも、私は最初、なかなか技術記事が書けませんでした。
書きたいと思うことと同じ内容の記事がすでに世の中にあるので、書くネタがないのです。
(ちなみに、その後、技術記事の投稿経験のない社内の若手20人に聞いたところ、皆そんな感じでした)
3.2 どんな技術記事でも価値があるという考え方
そんな私が、技術記事を書くネタがなくて困って、いろいろ調べて分かった事は「自分なりの視点で書いた記事なら、どんな記事も価値がある」という事です。
分かりやすいように具体例となる記事を紹介します(私の後輩T君の記事です)。
上図の記事内容は、「C#の初心者の視点」から見て「C#の型スイッチ」という機能が「地味だけど意外と便利」である事を説明した記事です。
同じ内容を扱った記事は、世の中にすでに存在しますが、記事内に書かれている「この機能は地味だけど意外と便利でオススメ」という初心者ならではの視点が、同じ初心者にとって価値があるかもしれません。
そもそも人により前提知識が異なるため、同じ記事でも
「分かりにくい」「得る知見は無かった」「刺さらない」と思う人と
「分かりやすい」「良い知見を得た」「刺さった」と思う人がいます。
だから、同じ技術を扱った記事でも、それが色んな視点(初心者の視点、熟練者の視点、組み込み開発経験者の視点など)で複数あった方が、より多くの人に刺さる可能性が高まります。
つまり、自分なりの視点で得られた知見を書いた記事なら、どんな記事も世の中に貢献していると言えます。
この考え方に至ったおかげで、私は他の人と重複するネタで投稿する事を気にしなくなりました。
とにかく自分を成長させるという目的で、自分なりの視点で自分の考えを書いた記事を投稿しました。
そうして投稿し続けることで、少しずつ役に立つ記事が書けるように成長できて、結果的に他人に貢献することにも繋がりました。
3.3 100人以上に匿名アンケート
世の中には、自分にとって価値の低い記事が増えることで、自分にとって価値の高い記事の検索性が下がることにネガティブなことを言う人もいます。
そこで以下のようなアンケートを実施してみました。
私のエンジニア仲間106人中100人(94%)が 1 の「適切な情報を探すのは探す方の責任」を選択しました。
この世の中は優しさに満ちていました。
だから初心者でも、まずは自分なりの視点で自分の学んだ事を発信すればOKです。
最初は記事の質が低いとしても、経験を積んで成長すれば、きっと多くの人に貢献する記事が書けるようになります。
3.4 技術記事を書く無限ループ
技術記事を書いてみて痛感したことは、今まで自分は技術記事を読んで、分かった気になっていたということでした。
人に説明しようと思って記事を書いてみると、実は全然理解できていなかったということに気付きました。
記事を書きながら理解し直すことで、やっとそれが「使える知識」になりました。
だから技術記事を書くことで「その技術を理解して自分が成長できる」という事が分かり、それが記事を書く主目的になりました。
そして、記事を投稿すると時々LGTMを押してもらえたり、コメントで間違いを教えてもらえたり、フィードバックがもらえて嬉しく感じました。
だから、「記事を書く」→「成長できる」→「フィードバック嬉しい」という無限ループが回っていきました。
3.5 技術記事を書く事で起きた心の変化
技術記事を書く前は、私はなんとなく情報をインプットしていました。
しかし、自分で記事を書くようになると、その心境が大きく変わりました。
無意識のうちに「人に説明するために自分なりの解釈」をしようと試みながら情報をインプットするようになりました。
アウトプットする前提でインプットするので、それまでよりも情報を理解する効率が上がりました。
また、それまでは、記事を読む時にその筆者に対して興味を持ちませんでしたが、自分が記事を書く経験を積むと、たくさん読まれる記事を書く人に興味を持つようになり、他にどんな記事を書いているかが気になって興味を持って記事を読むようになりました。
つまり、記事を書く事で、記事を読むことが楽しくなり、そのおかげでより多くの情報を楽しく理解できるようになりました。
3.6 成長するためのファーストステップまとめ
記事を書くことで楽しく成長が促進されるため、まずは自分なりの視点で自分が学んだ知見を記事に書くことから始めることをオススメします。
4. コミュニティに参加する
4.1 楽しく成長するためには刺激し合う仲間が必要
もっと刺激し合う仲間を作りたいと思っても、会社が発信活動に消極的だったりすると、なかなか既存の仲間の意識を変えるのが難しかったります。
だからこそ、自分と同じものを目指すコミュニティに入る事をオススメします。
例えば、「Web技術の発信活動を頑張るぞ」と思っている人なら、そういう人たちが集まるコミュニティに入ることで、一緒に頑張ったり、刺激し合ったり、自分の背中を押してくれたりします。
恥ずかしながら、過去の私は「井の中の蛙」で成長が停滞していました。
(特に、チームの中で一番技術力があったりすると「お山の大将」という感じで成長が停滞しやすいと思います)
人は一緒にいる人の影響を受けやすいため、自分が尊敬する人たちが集まるコミュニティに所属すると、その人達の影響を受けて成長しやすいです。
尊敬する人たちと一緒にいた方が、エンジニアライフは圧倒的に楽しくなり成長も加速します。
私はコミュニティで尊敬する人たちと交流する事で、半年間で価値観がガラっと変わりました。
- 仕事の時間以外で社外の勉強会に参加するのは嫌
→ コミュニティの人を真似て参加してみたら、興味あるテーマでの勉強会は楽しい - OSSやサービスを作って公開するのは限られた天才のみ
→ コミュニティの人を真似てやってみたら、意外と作って公開するのは簡単で楽しい - 情報は自分で調べるしかない
→ 困っているとコミュニティの皆が助けてくれるし、色んな知見を気軽にシェアしてくれる - 凄いエンジニアの人達とは一生かかわる事がない
→ コミュニティ内で凄いエンジニアが気軽に会話やフィードバックしてくれる
4.2 私を育成してくれたコミュニティ
私を育成してくれたのは、主に以下の3つのコミュニティです(順番は入った順)。
これらのコミュニティに入っていなければ、こんなに楽しく成長できませんでした。
運営者ギルド
Webサービスの運営者が知見を共有するためのコミュニティです。
皆が新しいチャレンジを楽しみながらどんどん行い、そこで得た知見が皆に共有されます。
Engineering Manager Meetup
エンジニアリングマネージャーの知見を共有するためのコミュニティです。
マネジメントについて困っていることを相談すると皆から助言してもらえます。
エンジニアと人生コミュニティ
発信に対する知見や刺激が多く、発信することの背中を押してくれるコミュニティです。
メンバーの発信や発信による成功を見ることで、発信のモチベーションが上がります。
4.3 コミュニティの探し方
オススメはconnpassというサイトで興味のある勉強会やイベントに参加してみる事です。
私の場合、最初に入ったコミュニティは、たまたま読んだ記事の筆者が入っているコミュニティという事で興味を持って、運営者ギルドに入りました。
コミュニティによっては、Slackのワークスペースへの参加を促すものがあります。
Slackがある方が、イベントがない時でも繋がりができるのでオススメです。
ただこの時、「このコミュニティに参加し続けるか分からない」という気持ちだと、なかなかSlackに参加する勇気が出ないと思います。
でも大丈夫です！
どの管理者も「試しに一度参加してみて」と思っているので、合わなかったら抜けても大丈夫ですので、もし興味を持つコミュニティがあれば、試しにぜひ参加してみてください。
4.4 コミュニティに参加する まとめ
コミュニティを探して、勇気を出してコミュニティに参加することをオススメします。
5. 社外発表にチャレンジする
5.1 LTにチャレンジ
初めての社外発表は、5分程度のLT(ライトニングトーク)がオススメです。
最初は私も「自分なんかが人様に何か教えるなんて無理ー」って思っていました。
でもコミュニティで「LT発表をやってきた」という話を楽しそうにしているのを見て、興味を持ちました。
そんな時、コミュニティの皆が迷っている私の背中を押してくれたので、勇気を出してLTに申し込んでみました。
発表直前に「こんな発表資料でいいのか」とモジモジしていたら、コミュニティの人が「良かったら発表資料みますよー」って言ってくれました。
そこで「素敵な内容ですね」と言ってもらえて、私は自信を持って初めての発表をやる事ができました。
5.2 発表で得られる事
1回目の発表に挑むのが1番敷居が高いので、勇気を出して1回目をやって本当に良かったと思います。
発表する事で、色んな得られる事がありました。
- 話す技術・テーマについて、記事で書くよりも、さらに深く理解できる
- 社外イベントに参加するエンジニアは優しい人ばかりで、意地悪な事を言われず、ポジティブフィードバックがたくさん得られる
- リアルタイムで顔の見える人からフィードバックをもらう事で新たな刺激がある
- 社内に閉じこもっていた自分は、自分と他の人の発表を比較して、自分がどれだけ「井の中の蛙」か思い知った(良い意味で)
- 運営や参加者に仲良くなりやすい(私は発表したコミュニティで運営になりました)
そして、やって分かったのは、社外イベントは参加するだけより発表した方が100倍楽しいということでした。
(私は1回目の発表後、1年間で7回くらい発表しました)
5.3 初めての社外発表の探し方
オススメはconnpassというサイトで「LT」というキーワードでイベントを探して申し込む事です。
「発表初心者だけど大丈夫かな」と思うかもしれませんが、LT大会を開催している管理者は「初めて発表する人が上手にできないかも」という事は織り込み済みなので大丈夫です。
そして、初めての発表は迷惑ではなく業界への貢献です。
1回目のハードルさえ超えれば、2回目以降の発表は容易にチャレンジできます。
(私はそういう人を何十人も知っています)
そのように発表者が増加する事はコミュニティの活性化に繋がり、コミュニティの活性化は業界への貢献に繋がります。
だから、初めて発表する事は、業界への貢献だと思って、LT大会に申し込む事をオススメします。
5.4 オススメのLT大会
いきなり大きなコミュニティで発表するのはハードルが高く、なかなか発表機会が得られない方々もいます。
そんな人のために、参加人数が少なく、LT初心者が集まるオンラインのLT大会を毎月開催するコミュニティを2020年7月に立ち上げました。
発表経験0回の人が30人以上、ここで発表を経験しています。
初心者向け発表資料テンプレートと発表準備方法も公開しています(こちらの記事参照)。
コミュニティの詳細は以下のURL参照ください。どなたでも ご参加 大歓迎です。
https://serverlesslt.connpass.com/
5.5 次はカンファレンスにチャレンジ
LTをする事で、自分の発表が人の役に立つという実感が得られると、参加者がより多く集まるイベントで発表したくなると思います。
そうなったら、「カンファレンス」と呼ばれる1000人くらいの規模で参加者が集まるようなイベントの公募セッションに応募しましょう。
私の場合、最初に応募した時は落選しました。
その当時は、初めての社外発表をしてからまだ半年だったので、そんな私がカンファレンスの公募セッションに当選するなんて、ほぼ無理で確率的には0%に近いと思っていました。
ただ、当選する確率も1%くらいあると思ったからチャレンジしました。
(公募セッションというのは、実力だけじゃなく、運も関わってくるはずと考えました。たまたま有力な候補の人たちの応募が少ない時があるかもしれません。もしくは、他に応募した人たちの発表テーマが同じ傾向で偏って、自分が応募するテーマがユニークなものになるかもしれません)
だから、落選の経験を糧にして成長した上で、繰り返し応募し続ければ、いつか当選できるはずと考えました。
1度の失敗で終わってしまえば、それは「失敗」という結果でしかありません。
でも、成功するまで失敗を続ければ、それは「失敗」でなく「成功のためのプロセス」です。
私はその考え方で挑んだ結果、Developers Summit 2020 KANSAI で運良く当選できました。
せっかく運良く当選できた場合は、そのチャンスに全力を尽くすのが良いと思います。
私の場合は、こんなチャンスは2度とないと思って、人生で最高の発表をしようと考えて2ヶ月間ほぼ全てのプライベートの時間を費やして自分が納得するまで資料の改善や発表練習を行った結果、ベストスピーカー賞1位を受賞できました。
準備期間中に、なぜすべての時間を費やすほど頑張れたかというと、コミュニティのおかげです。
発表内容の一部について、他のエンジニアの人達から意見を聞きたいと思ってコミュニティで質問したら、たくさんの意見をくれましたし、準備を頑張っている事に対して、皆が応援してくれたりポジティブフィードバックをしてくれたりしました。
だから、準備期間中は大変でしたが、とても楽しい時間に感じました。
それと、家族との時間については、期間限定という事で、家族会議で家族に相談して、この期間は発表準備に集中させてもらえるように協力してもらいました。
参考までに、エンジニアと人生コミュニティでもらったフィードバックを紹介します。
図は、ベストスピーカー賞をもらった時の例ですが、このようにコミュニティの皆は、一緒に喜んでくれます。他にも励ましてくれたり、応援してくれたり、助言してくれたりします。
カンファレンスを視聴した人からの感想の一例を紹介します。このような感想をたくさんいただきました。
- 仮説と検証を計画的かつ具体的にされていることに感銘を受けました
- 風土や文化づくりや、未来を考えての様々な行動には心打たれました
- 今日一番為になりました！！！
- 多様な取組を短期間で成果を挙げておられる点に刺激を受けました
- 弊社でもぜひ取り入れてみたいことがたくさんありました
- 動機付けの働きかけ、組織の風土を変える地道な努力が素晴らしいです
- メチャメチャ参考になりこれを見られただけでも参加価値ありました
- 新人教育で悩んでいることがあり、深く共感できる内容でした
このように感想をたくさんもらいやすいのがカンファレンスです。
凄く役に立ったという感想をもらったら、めちゃめちゃ幸せな気持ちになり、さらに頑張ろうと思えます。
だから、たとえ可能性が低くても、カンファレンスの公募セッションに応募する価値があると思います。
5.8 社外発表にチャレンジまとめ
LTを開催しているイベントを探して、勇気を出してLT枠で申し込むことをオススメします。
LTに慣れたら、カンファレンスの公募セッションに申し込むことをオススメします。
6. 仕事のチームを発信活動するチームにする
6.1 当初(3年前)の私のチーム
全員(私も含めて)、技術記事の投稿も社外イベント参加も一度もありませんでした。
ぶっちゃけた話をすると、主体性も低くて「開発知識は、業務で教えてもらったことしか知らない」「中堅の私以外は、自分のタスクの事しか考えない」という状態でした。
どうせなら仕事のチームメンバーも一緒に発信活動を頑張った方が楽しいです。
だから、発信活動をする事が自分にとって凄く良かったという話を伝えた上で、チームメンバーの主体性を高めて、主体的に発信活動するチームになる施策を紹介します。
大きく分けて以下の3つを並行して行います。それぞれの詳細を以降で説明します。
- 新しいものを試行する風土を作る
- アウトプットする習慣を付ける
- アウトプットで楽しい体験を得る
この章に関しては、他と違って少し難易度が高く、チームが変わるまでに何ヶ月もかかりますが、これができると仕事も楽しくなるためオススメです。
6.2 新しいものを試行する風土を作る
まず最初にやったことは、新しい技術・ツール・プラクティスを思いつくものから、どんどんやってみようという方針を決めたことでした。
なぜかというと、その方が「面白そう」だし「楽しそう」だったからです。
チームみんなで議論して、そういう方針でやってみることにしました。
具体的には、上図のように、新しい技術・ツール・プラクティスを積極的に施行して、得た知見を社内や社外にアウトプット(技術記事で情報発信)し、いいねをもらってモチベーションアップするという活動です。
「試行→アウトプット→いいね」の無限ループで成長できて楽しそうということで、この活動を「ハピネスチームビルディング」という名前のスローガンにしました。
ただ、新しい技術・ツール・プラクティスを提案するためのネタを継続的に探し続ける事は難しいです。
掛け声だけでは、活動は継続しません。
そこで「提案タイム」を毎月1時間確保します。
全員で同じ時間に、新しい技術・ツール・プラクティスを探し、提案タイムの最後に各自が提案します。
ここで重要なのが、思い付きでも、効果見込みが低くても、提案自体を善として、とにかく試行して実績にすることです。
そして、試行して得られた知見を社内外に発信(技術記事などに投稿)します。
ちなみに、試行した結果、効果があったものは継続しますが、効果がないものはやめます。
とにかく試してみることが重要という価値観なので、効果がなくてやめることになっても気にせずに、どんどん試行しました。
試行を促進するために、新しいものを試行した件数を下図のようにグラフで見える化しました。
グラフで件数の増加が見える状態で、「今月もいろいろ試行できたね」という感じに喜び合うことで、達成感を感じやすくなります。
6.3 アウトプットする習慣を付ける
毎朝15分のアウトプット勉強会
学んだことをアウトプットする習慣を作るファーストステップとしてオススメなのが、毎朝15分のアウトプット勉強会です(これは私が提案した手法ですが、実際に複数の会社で実施されました)。
事前に全員が書籍を30ページ程度 読んできた上で、勉強会の中でその重要ポイントを各自が自分の言葉で説明します。
これにより、学んだ事を説明(アウトプット)する事で効率的に成長する事を実感できます。
実際、実施したメンバーは「得た知識を他人に説明することで、その知識がより定着することも身をもって体験できた」と言っています。
詳しいやり方は以下の記事を参照ください。
主体的に学習できる環境を作る
学習は「やらされる」状態では捗りません。
興味がある技術に対して主体的に学習する方が効率的です。
そこで、自由な学習を毎日30分～60分、業務時間内で確保することを勧めました。
ポイントは、プロジェクトの進捗が遅れていても、この時間を確保していいことを明確にしたことです(プロジェクトはだいたい遅れることが多いので、そうじゃないと結局時間を確保できない)。
ただし、インプットするだけでは身につかないので、学んだことを随時アウトプットする場を作りました。
具体的には、Slackに学びをアウトプットするチャンネルを作成し、技術記事などで学んだことを随時Slackに投稿してもらうようにしました(下図参照)。
各自の学習内容をチームで共有できる上に、お互いに刺激し合う効果もあるのでお勧めです。
ちなみに、脳科学者の茂木健一郎氏は、書籍「脳を最高に活かせる人の朝時間」にてGoogleの20%ルールにふれた後、「たとえ仕事の時間を削ってでも、心にゆとりの時間を与えることで、仕事のクオリティは格段にアップします」と言っています。なので、この施策は脳科学的にも、わりと有効なんじゃないかと思います。
技術記事投稿をサポート
アウトプットして成長する方が、長期的には生産性が高まると判断して、技術記事を書くなどの学習工数を踏まえて業務の計画を立てるように調整しました。
そして、投稿できるようになるまで、チームメンバーをサポートしました。
記事のネタを一緒に考えて、下書きの記事を見せてもらって助言して、記事の質は求めずに、投稿したらポジティブフィードバックという感じで、サポートしました。
(自分も記事投稿の初心者でしたが、頑張ってサポートしました)
その結果、自分も含めて全員が、毎月 技術記事を投稿できるようになりました。
6.4 アウトプットで楽しい体験を得る
チーム内でLT大会を開催
発表資料は準備不要で「最近投稿した技術記事」などを元に学んだ事を5分程度で発表する形式で、チーム内でLT大会を開催しました。
これは以下の効果があります。
- 知見がチームで共有できる
- 自分の知見が他メンバーの役に立つという他者貢献の実感
- チームメンバー同士で刺激し合う効果
- LTはポジティブフィードバックしやすいので、称賛し合う風土を作る
個人で企画したアプリ開発を勧める
いつ使うか分からないような技術を調べるのに比べて、自分が作りたいものを作るために必要な知識を調べることは楽しいと思います。
「作りたいものを作る」という個人開発を、もし趣味にできれば、プライベートでも趣味として楽しみながら成長できると考えました。
また、企画から考えることでアプリ開発者としての視座が高まると思います。
従って、以下の手順でメンバーに個人開発を勧めました。
- 書籍「個人開発をはじめよう！」のいくつかのエピソードの要約を説明する。
- 「Web1Week」という1週間でWebサービスを作るイベントの作品を紹介し、誰でも簡単に作れることを伝える
- 何が作りたいか聞き出して、MVP(Minimum Viable Product)を一緒に考える
- 作りたいアプリの技術選定と公開手順を教える(簡単にできそうと感じてもらう)
- 週に1時間「個人開発タイム」を作って、少しずつでも進める
- つまった所はペアプロで解消
- MVPが出来上がったら皆に見てもらう場を設けて褒める
上記の手順で全員に個人開発アプリを作成してもらい、新しい技術を学びながら、自分で企画して作る楽しさを経験してもらいました。
6.5 現在(3年後)のチーム
私のチームには毎年新人が入ってくるため、現在7人のチームとなりましたが、その新人も含めて、以下のような主体性を発揮するチームになりました。
- 全員が技術記事を毎月投稿、全員が社外イベントで発表
- 毎月新しい技術・ツール・プラクティスを皆が提案
- 各自が自分のタスクの事だけでなく、チームのための提案を積極的に行う
開発の生産性も向上しました。ここでは紹介しきれないほど、他にも様々な施策を実施しているため、詳細は以下の記事を参照ください。
7. 自分の自己実現を考える
7.1 自己実現について
「自己実現」と「他者貢献」ができると幸せを感じるという理論があり、私はその考え方が好きです。
この章では、自分自身の心が本当に望んでいる自己実現が何か考える話を書きます。
詳しくは『「コーチング脳」の作り方』宮越 大樹 著、ぱる出版を参照ください。
以降は、その書籍を読んで私がやった方法を紹介します。
7.2 過去の出来事の棚卸しから見つける
自分の自己実現は分からない事が多いため、まず過去の出来事の棚卸しで、自分の重要な価値観を見つけます。
過去の出来事の棚卸しというのは、子供時代から振り返って人生の中で、とても嬉しかった事や充実感を得た体験を思い出す事です。
ここでポイントになるのは、「創作活動で、人に楽しんでもらって嬉しかった」という抽象的な表現でなく、その時の状況、相手がどんな表情だったか、自分はどの瞬間に一番嬉しくて、どう思ったのか、その瞬間をできるだけ具体的にイメージできるように言葉にすることです。
そのエピソードをもとに、自分にとって重要な価値観を見つけます。
私にとって、人生で最も嬉しかったエピソードを紹介します。
私は子供の頃から漫画やゲームなどの創作活動が好きで、学生の頃、作ったゲームを公開していました。
そのゲームの感想メールの1つを読んだ時が一番嬉しく感じました。感想の送り主は、重い疾患を抱えた人で、この数年はずっと悲しい気持ちのまま暮らしてきたという人でした。
その人が、私が作ったゲームをプレイしたことで、笑っている時は幸せな気持ちになれることを知り、「これからは私も笑顔を心掛けて生きたい」というメッセージを送ってきたのです。それを読んだ時、自分でも誰かを幸せな気持ちにできると知ってすごく嬉しくなりました。
そして、自分の創作活動が意義ある事なんだと思えて、今後は創作活動を誇りを持ってやっていこうと思いました。
思い出すエピソードは1つでなく、複数を思い出して言葉にします。
そして、私がその他に思い出すエピソードも、自分の創作物で誰かを幸せな気持ちにした時に嬉しかったエピソードでした。
その結果、自分にとって重要な価値観は「自分の成果が人を幸せな気持ちにすること」であり、この価値観を満たす事が自分にとっての自己実現であると分かりました。
7.3 仕事の中での自己実現を考える
自己実現が分かったら、次はその自己実現を仕事の中でもできないかと考えます。
「自分の成果が人を幸せな気持ちにすること」という自己実現を仕事の中でやる方法として考えたのが「自分が考えた施策でメンバーを幸せな気持ちにすること」でした。
では、どうすればチームメンバーを幸せな気持ちにできるのか、仕事で「楽しい・嬉しい」と感じるのは、どんな時かを考えました。
色々ありますが、「主体的な行動で成果が出る」というのは、多くの人が嬉しく感じるのではないかと考えました。
例えば、自分が提案して導入したツールやライブラリに対して、他の人から「便利になった」と言われると嬉しいと思います。
そこで私は「主体的な行動で成果が出る」という体験を繰り返す事に取り組みました。
具体的には、メンバーの主体性を発揮してもらうために3年間 様々な施策を試しており、今でも試行錯誤しています。
様々な施策を試して得られた知見は、ITエンジニア向け月刊誌「Software Design」2022年4月号から連載記事「ハピネスチームビルディング」で紹介しています。
Webの記事でも同じ内容を2ヶ月遅れで順次公開しています。
もし興味があれば、以下の記事を参照ください。
私は「自分が考えた施策でメンバーを幸せにすること」が自己実現であり、それが自分の幸せに繋がるという考えに辿り着いたからこそ、心からメンバーの成長を願うようになり、チームビルディングの活動や発信を楽しめています。
プライベートで勉強するのは嫌でしたが、自己実現のために、調べたり勉強するのは楽しく感じています。
そして、今のチームで育成したメンバー(全員新人から育成)が入社して10年後に
「最初の育成担当者があなたで本当に良かった！おかげで今、こんなに幸せです」
って言ってもらう事が私の夢の1つです。
7.4 自分の自己実現を考える まとめ
以下のステップで自己実現を考えれば、それを達成するために楽しく頑張れます。
- 過去の出来事の棚卸しをする
- 複数のエピソードから自分にとって重要な価値観と自己実現を見つける
- 自己実現を仕事の中でやる方法を考える
- それをどうやって達成するのか考えて取り組む
8. まとめ
8.1 楽しく成長するためのステップ
本稿で紹介した楽しく成長するためのステップは以下です。
- 自分なりの視点で、自分が学んだ知見を記事に書く
- 勇気を出してコミュニティに参加する
- LTを開催しているイベントを探して、LT枠で申し込む
- LTに慣れたらカンファレンスの公募セッションに申し込む
- 仕事のチームを主体的に発信活動するチームにする
- 自己実現をよく考えて、自己実現のために頑張る
これを行った結果、私は多くの人と楽しく交流したり感謝されたりで、人生が劇的に楽しくなりました。
8.2 過去と現在の比較
3年前の自分は以下でした。
- 社外での発表経験なし
- 社外での勉強会の参加経験なし
- 技術記事の投稿経験なし
現在は以下の状態です。
- Developers Summit 2020 KANSAI ベストスピーカー賞1位
Microsoft Build 2022 セッションのスピーカー - 複数のコミュニティや勉強会に参加し、自分でコミュニティを運営
- 技術記事(Qiita/Zenn/Note)でのいいねの合計1万件
ITエンジニア向け月刊誌「Software Design」連載執筆中
8.3 さあ発信活動を始めましょう
本稿を読んで、記事投稿や社外発表やコミュニティ参加を始めようと思ってくれた人がいたら、めちゃめちゃ嬉しいです。
QiitaのコメントかTwiiterのツイートかDMで、その旨を教えてくれると、私が泣いて喜びます。
(そういう気持ちは形に残した方が強い決心になって、発信活動が継続しやすいのでWin-Winです)
Twitterはこちらです(kojimadev)