個人とチームのアウトプットを伸ばすうえで、「伝える」「教える」が効いたと感じた話

法人ディベロップメント課のS・Sです。
マイナビBiz / LIVING の新規開発・保守運用を行なっております。

• 日々、インプットもしているし、実装もしている
• それでも、アウトプットの量や質が思うように伸びない

私自身、以前はそんな停滞感を持つことがありました。

今振り返ると、その原因の一つは、インプットして、やってみるところで止まっていたことだったのかなと思います。

そんな課題に対して、 「伝える」「教える」 を加えるようになってから、個人としてもチームとしても、アウトプットの量と質が少しずつ改善してきた実感があります。

今回は、その実体験をもとに、なぜ「伝える」「教える」がアウトプットの改善に効くのかについて、まとめます。

こ️の記事内容をざっくりと一枚絵にしたので、こちらをご確認頂いた上で、読んでいただくとスムーズに読み進めていただけるかなと思います。

アウトプットの量や質が思うように上がらなかった理由

私の場合、結論はシンプルでした。
インプットはしているし、実際にやってみることもできているけれど、そこで止まっているから。

一見すると、これは、
「インプットだけで終わらず、ちゃんとアウトプットしている状態」
に感じますよね。

実際、私自身もそう思っていましたが、今思うと、この状態のアウトプットは自分の中だけで完結する、いわば、一方通行のアウトプットだったんです。

もちろん、「やってみる」こと自体は、とても大切です。

ただ、それだけだと、

• 自分の理解の曖昧さに気づきにくい
• 情報整理が不十分なままでも進められてしまう
• 学びや知見が自分の中だけに留まりやすい

という状態になりやすく、結果として、アウトプットの量も質も頭打ちになりやすいと感じました。

アウトプットをもう少し分解して捉えてみる

そこで、私は「アウトプット」をもう少し細かく分けて考えるようにしてみました。
たとえば、アウトプットには少なくとも3種類あると思っています。

※ 自分なりの解釈なので、広辞苑はもとより、人によって捉え方は変わるかもしれませんが、今回のテーマに合わせてご理解頂けますと幸いです。

1. やってみる
   実際に手を動かして、成果物を生み出すことです。
   実装する、検証する、設計してみる、などがこれにあたるかなと思います。
2. 伝える
   自分の知識や経験を、他者が理解できる形にして渡すことです。
   口頭、テキスト問わず、チャット、記事、レビューコメント、口頭共有などが含まれます。
3. 教える
   相手が、自分と同じか、それに近いレベルで再現できるようにすることです。
   単に情報を渡すだけでなく、相手が実際に使える状態まで支援することまでがポイントかなと思います。

この3つで見て、過去を振り返ると、以前の私は「1. やってみる」まではできていても、「2. 伝える」「3. 教える」が、あまり足りていませんでした。

しかし、この2つを意識して増やすようになってから、アウトプットの量と質の両方に変化が出てきたのかなと思います。

なぜ「伝える」「教える」アウトプットがいいのか

理由はいくつかあると思いますが、特に大きいと感じているのは、

伝えることで、自分の理解が整理されるから

誰かに伝えようとすると、下記を整理する必要が出てきます。

• 何が前提知識なのか
• どこが重要なのか
• なぜその実装や判断をしたのか
• どう説明すれば伝わるのか

その中で、自分の中では分かったつもりでも、いざ言語化しようとすると、意外と曖昧な部分が見つかります。
つまり、「伝える」は、他者のためであると同時に、自分の理解を整理し直すアクションでもあるのかなと思います。

教えることで、自分の理解不足や思い込みに気づけるから

教える場面では、相手から質問やフィードバックが、返ってきます。
これがかなり大きいです。

自分にとっては当たり前になっていることでも、相手からするとそうではありません。
その時に、下記のような質問を受けることで、自分の理解の浅さや説明不足に気づくことがあります。

• なぜその設計にしたのか
• どこまでがフレームワークの責務で、どこからが自分たちの実装なのか
• なぜ TypeScript の型をそこまで厳密に付けるのか
• Next.js のこの書き方を選ぶ理由は何か

これによって、自分の知識や考え方も、アップデートでき、さらに自身のやってみるアウトプット、伝える、教えるのアウトプットの質も向上できます。

チーム全体のアウトプット向上につながるから

「伝える」「教える」は、自分のためだけでなく、チームのアウトプット向上に繋がります。

たとえば、下記のような変化が起きやすくなります。

• 知識共有が進み、属人化が減る
• レビュー観点が揃いやすくなる
• 実装の背景共有が進む
• オンボーディングがしやすくなる
• 同じ失敗をチーム内で繰り返しにくくなる

個人の学びが、チームに展開されるようになるので、結果として、PJ全体として出せるアウトプットの量と質が上がりやすくなります。

私が、実際に、「伝える」「教える」アウトプットをして感じたこと

「伝える」ことで感じたこと

「伝える」アウトプットをしてみた実感でいうと、今こうして記事を書いて伝えていること自体がまさにそうです。

自分の中ではなんとなく分かっていたことでも、文章にしようとすると、

• 自分は何に詰まっていたのか
• どこで変化が起きたのか
• 何が再現可能な学びなのか

を整理しないと、筆が進みません。

また、記事として伝えようとすると、単に思ったことを書くのではなく、

• 読み手にとって分かりやすいか
• 読んだあとに行動につながるか
• 自分の経験が他の人にも応用できそうか

という視点で見直すようになります。
（この記事も、自分なり、どうしたら伝わるか、プラスのアクションを起こしてもらえるかを考えながら書いています）

このプロセスを通して、自分の経験や判断が言語化され、再利用しやすい知見になっていく感覚があります。

それでいて、知見が共有されることで、

• 実装の背景が共有されやすくなる
• レビュー時の観点が揃いやすくなる
• チーム内で同じところでつまずきにくくなる

といった意味でも、組織やチームのアウトプット向上に少しはつながるのではないかと感じています。

「教える」ことで感じたこと

私は、フロントエンド寄りなので、バックエンド寄りの方に対して、フロントエンドの基礎や Next.js、TypeScript について共有したり、レクチャーしたりする機会がありました。

その中で強く感じたのは、教えると、自分の理解の甘さがよく見えるということです。

自分の中では当たり前になっていたことでも、質問を受けると、意外とうまく説明できないことが多々ありました。

たとえば、

• その実装方針を選ぶ理由は何か
• この型定義は何を防ぎたいのか
• コンポーネントを分ける基準は何か
• その書き方が保守しやすいのはなぜか

といった質問に向き合うことで、「分かっているつもりだったこと」を改めて深掘りするきっかけになりました。

また、教える中で情報を整理し直したり、説明を改善したりすることで、自分自身のアウトプットの質も上がっていきました。
（いざ質問を受けると一緒に調べつつ改めて学習が深まることが多かったですね）

さらに、教えた相手が同等、あるいはそれ以上の成果物を出してくれるようになると、チーム全体として出せるアウトプットの量も質も上がっていきます。

これは、個人で頑張るだけでは得づらい変化で、「教える」は、自分の成長とチームの成長を同時に進められる行動だと感じています。

「伝える」「教える」がチームにも有効なアウトプットである理由

社内のエンジニア組織という観点で見ても、「伝える」「教える」はかなり重要だと思っています。
なぜなら、開発現場では、単に誰か一人が詳しいだけでは足りない場面が多いからです。

個人の知識や経験が共有されないままだと、

• 特定の人にしか分からない実装が増える
• レビューが人によってぶれやすくなる
• キャッチアップに時間がかかる
• 同じ調査や失敗が繰り返される

といったようなことが起きやすくなります。

逆に、「伝える」「教える」がうまく回るようになると、下記のようになることで、結果として、開発全体の進み方が良くなります。

• 属人化が減る
• 背景込みで実装を理解しやすくなる
• 新しく入ったメンバーも学びやすくなる
• チーム内で共通言語が増える

まずは、小さく始めてみる

ここまで書いてきた通りですが、「伝える」「教える」は時間も労力もかかります。
なので、最初から大きくやろうとしなくてもよいと思っています。

例えば、以下のようなアクションなどが挙げられます。

• 学んだことを社内チャットに短く共有する
• 詰まったポイントと解決策をメモとして残す
• 口頭で説明した内容を、あとでテキストでも共有する
• 勉強会やペアプロの中で、自分が理解していることを言語化してみる

大切なのは、「やってみる」で終わらせず、他者に届く形にする、までアウトプットすることだと思います。

やり方も、ご自身が負担の少ないやり方で良いかなと思いますので、対面や通話で伝えるのが得意な方は、そうした場を活用すればよいと思いますし、口頭よりテキストの方が得意な方は、チャットや記事、ドキュメントで実践するのも良いと思います。
（ちなみに、私は、テキストが好きなので、テキストを積極的に活用しています。）

まとめ

私自身、アウトプットの量や質については、まだまだ道半ばです。
しかし、以前より改善してきた実感があるのも事実です。

繰り返しになりますが、その中で強く感じているのは、アウトプットは「やってみる」だけで終わらせず、「伝える」「教える」まで含めると効果的であるということです。

• 伝えることで、自分の理解が整理される
• 教えることで、自分の理解不足や思い込みに気づける
• その結果、個人だけでなくチーム全体のアウトプット向上にもつながる

短期的には少し手間に感じるかもしれません。
しかし、長い目で見ると、その積み重ねが個人にもチームにも効いてくると思っています。

アフリカの諺にもありますが、
「早く行きたいなら、ひとりで行け。遠くまで行きたいなら、みんなで行け。」
というものがありますが、まさにそれですね。

アウトプット先（チームや仲間）に向けることを意識することで、個人・チームのアウトプットを上げられて、長期的に、より大きなアウトプットが出せるようになると思います。

もし、インプットも実装もしているのに、なかなか伸び切らない感覚がある方がいれば、ぜひ「伝える」「教える」までをアウトプットに含めてみてはいかがでしょうか。

私もまだまだ途中なので、引き続き一緒に頑張れたらうれしいです。