エンジニアがチーム内で自分の小さなコミュニティを持つことの重要性

まとめ

• エンジニアがチーム内で自分の小さなコミュニティを持つことは、会社の時間を使って自分の能力を向上させることや、上司からの評価を高めることに繋がる
• コミュニティの活動内容や目的・方針を、組織のメリットと合致させることが重要
• コミュニティの内容として勉強会がお勧め

はじめに

この記事は、会社員として働くソフトウェアエンジニアを想定して書いている。

特に、

• 自分の技術力を高めたいという向上心があり、
• 会社の時間を使って学習し、
• かつ、それを成果として上司に高く評価されたい

と考えている人向けに書いている。

本ポストでは、上記を達成するために、チーム内で自分のコミュニティ（特に勉強会）を持つことを提案する。

自分のコミュニティを持つ目的

まず、チーム内で自分のコミュニティを持つことの “表向きの” 目的は以下だ。

• コミュニティの活動を通して、チームや組織の課題を解決する

その結果、副次的に得られる効果として以下が期待できる。これが、自分のコミュニティを持つことの “本当の隠れた” 目的である。

• 会社の時間を使って自分の能力を向上させる
• 会社からの評価を高める
• チーム内で自分の存在感を高める
• チームのメンバーとの関係を良好にする
• チームのメンバーのスキルを底上げする

自分のコミュニティ＝お勧めは勉強会

結論から言うと、チーム内で小さな「勉強会」を主催し、継続して運営することをお勧めする。ポイントは以下だ。

• コミュニティの活動内容や目的・方針を、組織のメリットと合致させる
• 小さく始める
• 社外ではなく、社内のチームの中で活動する
• 議事録を残しチームの財産とする
• チーム内のつよつよエンジニアを巻き込む

これらを意識することで、チームや組織の課題を解決でき、その結果として会社の時間を使って勉強することを許され、さらに上司から高い評価を得ることが可能となる。

１つずつ見ていこう。

コミュニティの活動内容や目的・方針を、組織のメリットと合致させる

これが一番重要なポイントだ。

コミュニティ運営の本質は「活動を通して何らかの課題を解決する」ことである。

コミュニティの活動内容や目的・方針を、組織のメリットと合致させることで、上司からの評価を高めることができる。逆に、これが出来ていないと、上司からの評価は得られない。場合によっては、工数を無駄にしているとして活動を禁止されることもある。

組織のメリットとは何か。

それは、上司の上司（部長クラス）の発言、もしくは経営陣の発言を注意深く聞くことで見えてくる。

例えば、会社の業績が悪く、コストカットを行う必要があるとする。そこで、部ミーティングなどで上司の上司が「来期はコストカットのために、協力会社への発注を減らす必要がある」と発言したとする。ここで、協力会社へ発注を減らすということは、今後、製品開発の内製化の割合が増えることを意味する。つまり、今まで外部のエキスパートを頼っていた製品開発を自分たちで行う分、社内のエンジニアのスキルを底上げする必要があるということだ。

ここに貢献のチャンスがある。

上司からすると「自分のチームのエンジニアの育成」という課題があり、それに対し部下から「チーム内の勉強会（コミュニティ活動）を通したスキル向上」というソリューションを提供できる余地があることを意味する。

つまり、勉強会の目的を「チーム内のエンジニアのスキルを向上すること」とし、活動内容も「チームで開発している製品の技術的な課題を解決するための勉強会」とすることで、勉強会に時間を割くことを上司や組織にとってメリットがあることにしつつ、かつ我々も「会社の時間を使って自分の能力を向上させる」というメリットを得ることが出来るようになる。

上司視点では、本来は自分がやるべき「チーム内の技術力向上」という課題を、部下（つまりあなた）がボトムアップで率先して引き受けてくれることになる。これは、上司にとって非常にありがたいことである。なぜなら、部下の育成に割くはずだった自分の工数を大きく削減できるからだ。

このように、コミュニティ活動を通して上司や組織へメリットを与えることにより、上司から感謝され、さらに成果として自分の評価を高めることができる。

ここで、チームや組織の課題を見据えて、先回りしてそれを解決するために動くことは、昇進するために必要な能力の１つであることは言うまでもないだろう（昇進をする気が無くとも評価を高めるには重要である）。

小さく始める

「小さく始める」ことは何事にも重要だ。勉強会（コミュニティ運営）でも例外ではない。まずは、チーム内で自分と気が合い、かつ、ある程度の熱意のある数人で始めることが望ましい。

小さく始めることで以下のメリットがある：

• 小さなコミュニティの運営は比較的に容易であるため、初心者でも運営しやすい
• 熱意の高い参加者のみを選べるため、活動を継続しやすい
• 参加者が発言しやすく、議論が活発化しやすい
• 参加者の意見を反映しやすい
• 活動のスタイルを確立するためのトライエンドエラーがしやすい
• 本質である「活動を通して解決すべき課題」に関係する人のみを集めることができる

はじめは片手の指で数えられる程度の人数で充分だ。活動が軌道に乗って来たら、必要があれば徐々に参加者を増やすことを検討すればよい。

ただし、重要なのは人数より参加者の質であることを忘れてはいけない。手段（参加者を募集する）が目的（組織の課題を解決する）と入れ替わらないように注意が必要だ。

繰り返すが、コミュニティ運営の本質は、その活動を通して何らかの課題を解決することだ。そのために必要十分な人を集めることが重要であり、人数を増やすことが目的ではない。

社外ではなく、社内のチームの中で活動する

「自分のコミュニティ」と言うと、インフルエンサーのようなものを想像しがちだ。つまり、何らかのテーマに基づいて人を広く多く集め、自分のオンラインサロンへ誘導し、サブスクリプションで集金するようなものだ。

ここでは、そのような活動は想定していない。あくまで、社内のチームの中で活動することを前提としている。部や課単位なのか、プロジェクト単位なのか、それは各々の状況で判断すればよいが、本ポストでは「チーム内」という非常に狭い範囲でのコミュニティを推奨している。

これも、「小さく始める」ことに通ずる。

解決すべき課題を見つけるためには、まず自分に最も身近で、かつ自分ごとである「自分の所属するチーム」に関する課題を見つけることが最も容易である。

そして、「社内のチームの中で活動する」ということは、「社内のチームに存在する課題を解決する」ためにコミュニティ運営を行うということを意味する。

まずは対象を思いっきり小さく絞って課題を探す。その課題を解決するために小さなコミュニティを運営する。これが最も小さく初めて、かつ効率的にコミュニティ運営のノウハウを学ぶことができる方法である。

また、ゆくゆくは社外でコミュニティを立ち上げたい場合も、まずは社内でコミュニティ運営を行ってみることをお勧めする。というのも、社内は基本的に味方しかおらず、閉鎖的な環境であるため、比較的安全に活動を行えるからだ。かつ、上述のように小さく始めることもできる。そのような環境でコミュニティ運営のノウハウを学んだあとで、外に目を向けるのも遅くはない。というのも、会社の外で活動をする場合でも、コミュニティ運営の本質は同じであるからだ。つまり、コミュニティ参加者にどんな価値を提供するか、どんな課題を解決するか、が重要である点は共通である。

議事録を残しチームの財産とする

コミュニティの活動を通して得られた知見やノウハウは、必ず議事録として残すことをお勧めする。なぜなら、議事録はチームの財産となるからだ。

文章として残しておくことで、勉強会に参加できなかったメンバーも、後からその内容を確認することができる。さらに、議事録はチームのナレッジとして蓄積されていくため、次回以降の勉強会やプロジェクトに活用することができる。

勉強会を長く続ければ続けるほど、文章化されたナレッジが蓄積されていく。開発のノウハウ・知識がいつでも参照可能な文章という形で積み上がっていくことで、開発の効率化が図られ、チーム全体の生産性が向上していくことが期待できる。

また、議事録という目に見える成果物は、上司へ成果をアピールする際に重要な役割を果たす。必ず議事録を残すようにしよう。

チーム内のつよつよエンジニアを巻き込む

チーム内に経験豊富なエンジニアがいる場合、その人を勉強会メンバーに加えることを強くお勧めする。

経験の浅い若手エンジニアだけで集まっても、深い議論に発展することは難しく表層的な理解で終わる可能性がある。シニアエンジニアやリードエンジニア、もしくは中堅のエンジニアが議論に加わることで、より深い議論ができるようになる。

チーム全体として、以下のような効果が期待できる。

• ベテランから若手へのナレッジの伝承
• ベテランの知識・経験に基づく深い議論
• プロジェクトのコーディング規則など、ルールが制定された理由の深い理解
• ベテラン・若手問わず、開発に対するチーム全体の認識の統一
• 年齢差のあるメンバー同士のコミュニケーションの活性化

ここで、ベテランの人は忙しいため勉強会に誘うのを躊躇してしまったり、レベルの高くない勉強会に誘われても迷惑なのでは、と考えるかもしれない。

全く気にする必要はない。

むしろ、逆である。ベテラン側にも多くのメリットがある。

• 若手エンジニアが成長し、チームの生産性が向上する
• 開発への認識が統一され、コーディングの品質が向上し、コードレビューの負荷が減る
• 若手へ教えることを通して、自分の知識を整理でき自分自身の成長につながる
• 教えるポジションに立つことで、チーム内での存在感を高めることができる

よって、勉強会に参加することは、教える側、教えてもらう側、どちらにもメリットが多く素晴らしい活動であることが分かるだろう。

勉強会は持たざる者の武器

勉強会（コミュニティ）を運営するにあたり、主催者が一番賢い必要は無い。

むしろ、若手エンジニアや、転職したての途中参加のメンバーのように、知識や経験が不足している人こそ勉強会を運営するメリットが大きい。

なぜなら、勉強会であれば、教えてもらうというポジションを自然に取れ、他のメンバーから知識や経験を吸収することができるからだ。教えてもらうポジションであれば、積極的に質問を行える。これにより参加者とのコミュニケーションも行える。教えてもらったことに感謝を伝えれば、自然と良好な関係が築けてゆく（人は人に教えることが好きで、かつ感謝されることが好きだからだ）。

巨人の肩に乗ろう。

つまり、勉強会は、持たざる者に許された大きな武器である。

もちろん、あなたが既に知識や経験の豊富なエンジニアであれば、それを共有する教師というポジションでも勉強会を行うこともできる。また、転職してチームへ参加したての場合でも、新しいチーム内での自分のポジションを確立するために、前職での経験を積極的に共有することが推奨される。もしくは、参加者全員で手を動かしてコーディングをするワークショップという形でも良いかもしれない。

コミュニティの最適な形は、あなたの持つ知識・経験や、チーム・組織の状況によって変わってくる。

いずれにせよ、「活動を通して何らかの課題を解決する」という本質は変わらないことを忘れてはいけない。

勉強する対象の例

勉強のテーマは、その状況に合わせた適切なものを選ぶ必要がある。以下は、私が実際に行い、かつ効果が大きいと感じたテーマの例だ。

• 会社が定義している、製品リリースのために守るべき品質定義書
• プロジェクトのコーディング規約
• プルリクエストの指摘事項の振り返り
• 名著の輪読会（例：リーダブルコード）

実際に行った結果

私は実際に、上記のような勉強会をチーム内で主催・運営している。

頻度としては、試行錯誤の末、今は週に 1度 30分のペースでオンライン開催 (毎週、同じ曜日と同じ時間の固定枠) している。参加者は私を含めて7名ほど。参加自体は自由で、業務の負荷と相談しながら各自好きなときに参加している。

その結果、以下のような効果があった。

• 会社の時間を使って自分の能力（ポータブルスキル）を向上させ続けている
• 上司から感謝され、ぜひ続けて欲しいと言われた
• 上司からの評価が高まり、給料UPにつながった（特に、自分だけでなく、チームメンバ全体のスキル向上を図っていることを高く評価された）
• チーム内での自分の存在感が高まった（コーディングに関して質問されることが増えた、コーディングが強い人というポジションを得た）
• チームのメンバーとの関係が良好になり、仕事がしやすくなった
• チームのメンバーからスキルが上がっている実感があると言われた
• チーム全体のスキルが向上し生産性が上がった

また、上司から受けたフィードバックまとめると、エンジニアも以下の能力が重要であることが分かった。

• チームや組織の課題を見据え、先回りしてそれを解決するために動くこと
• チームや組織の課題を解決するために、周囲を巻き込むこと

また、「リーダーと、参加者とでは、評価が変わる」ということも明言された。つまり、参加するだけでは評価されないのである。どれだけ小さなコミュニティでも、「リーダーとして立案し周りを巻き込んで成果を出すこと」こそが評価されるのである。

おわりに

ともすれば、エンジニアは技術的なことをできれば満足で、組織や人にあまり興味を持たない傾向がある（私もその傾向がある）。しかし、このように、会社の時間で自分の技術的な能力を伸ばすことを真の目的にすれば、その目的を達成するための手段としてコミュニティ運営を行い、それを通してチームや組織の課題を解決することができる。これにより、“表向きには” 組織や人に興味を持つことができ、チームや組織に貢献する自発的な動きができるようになる。

また、勉強会の運営は、実質ノーリスクである。なぜなら「試しに１回やってみませんか」ができ、もし「違うな」と思えばすぐに会を中止出来るからだ。もし失敗しても、勉強会という良いことへのチャレンジなので評価が下がることもない。また、テーマごとに区切りが付けやすく、活動自体の一時停止や再開もしやすい。

このように、エンジニアがチーム内で自分の小さなコミュニティを持つことは、非常に多くのメリットがある。ぜひ、あなたも試してみて欲しい。