元教育関係者の視点でエンジニアのアウトプット文化について考察してみた

## はじめに

こんにちは、NTTテクノクロスでAWSの開発エンジニアをやらせていただいています。だはです。
元教員として、初心者目線から色々な記事を書かせていただいています。
今回は[NTTテクノクロスアドベントカレンダーシリーズ1](https://qiita.com/advent-calendar/2024/ntt-tx)の25日目となります。
今回は第五弾として、アウトプットの記録を書いていこうと思います。

## 目次

[1.概要](#1概要)
[2.本題](#2本題)
[　2-0.予備知識](#2-0予備知識)
[　2-1.誰にも見えないアウトプット](#2-1誰にも見えないアウトプット)
[　2-2.非同期なアウトプット](#2-2非同期なアウトプット)
[　2-3.同期したアウトプット](#2-3同期したアウトプット)
[3.アンチパターン](#3アンチパターン)
[4.まとめ](#4まとめ)
[5.あとがき](#5あとがき)
[6.出典](#6出典)

## 1.概要

ここでお伝えしたいのは、大きく分けて2点です。

#### どんなことをしてきたのか

2023年の4月からエンジニアをやらせていただいて、約1年半あっという間に経ちました。
お仕事をしていく中で、社内研修やブログに限らず[「Qiitaアドベントカレンダー」](https://qiita.com/advent-calendar/2024)や[「JAWS-UG」](https://jawsug.connpass.com/)なる存在を知り、なんとなく「学んだこと、取り組んだことを外部に発信していくことで、IT業界の集合知を作り上げている」ような感覚を察してきました。
その中で「エンジニアはアウトプットしないと **『知的な便秘』** になるよ」という言葉を聞く機会があり、早速いろいろな手段でアウトプットしてみました。そうすると、

* やりやすいけど得るものが少ないアウトプット
* 準備大変だけど学ぶことが多いアウトプット

が、スペクトラム的に存在するんじゃないかな、ということを感じていました。

#### どんな話をしたいのか

元教育業界の観点でエンジニアのお仕事に取り組んだり、自身の成長を振り返ったりする中で、上記の内容を思い浮かんでは忘れ、モヤモヤする日が続いていました。
そこで今回は（もう忘れないように）体系化して記事にすることで、今後キャリアを考えていく上での道筋を確認したいと思っています。
人によっては「アウトプットって何したらいいの？」という人がいるかもしれないので、その一助となれば幸いです。
知識を吸収すること、それを整理整頓または取捨選択して書いたり話したりすること、それぞれに良さも難しさも両方あって、人によってより良い選択をして欲しい今日この頃です。

[(目次へ)](#目次)

## 2.本題

早速本題に入りたいと思います。一旦自分の知識背景を共有したうえで、分類および体系化に取り組み、考察してみようと思います。

### 2-0.予備知識

#### 2-0-1.人間の記憶メカニズム

昔学校の先生をやっていた時に、こんな質問がありました。

![school_soudan_man_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2773852/c2a0be59-d72a-ae9f-cc2e-fcaf31dd23ff.png)
（生徒）「どうやったらテストの点が取れますか」

これに対して、「教科書をよく読んでいれば点が取れるよ」と答える先生は無責任だと思っています。当てはまる対象が少ないからです。
私はよく「繰り返し問題集を解いたり、友達同士で問題を出し合うといいよ」と答えていました。問題集に飽きた子にはプリントを用意したり、[kahootというクイズアプリ](https://kahoot.com/schools/)で問題を用意したりすることで、テストで極端に点数の低い子は少なかったんじゃないかと振り返っています（当てはまらないパターンもありました）。

上記の考え方の根拠として、まずは「エビングハウスの忘却曲線」が有名かと思います。
下記画像は[宮城県松島町教育委員会の記事](http://matsushima.ed.jp/jody7mwi1-498/)からの引用です。
![2015010511134645c.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2773852/dbdc63d5-8c2c-eeb0-bf4d-18475c2d87cb.jpeg)

:::note info
端的に書くと
* 情報を取得した瞬間が100%の情報量だとして、時間が経つと段々忘れていく
* ある程度時間が経ったときに再び情報を取得することで、忘れにくくなっていく

と、いう現象を表したグラフです。
:::

この「忘れにくい」という状態にすることを「知識の定着」とも言えますね。
人間の記憶に関しては今も昔もずっと研究されていますが、有名なのは[京都大学梅本教授の論文](https://www.jstage.jst.go.jp/article/apr/4/2/4_2_614/_pdf/-char/ja)かと思います。

:::note info
これも端的に書いちゃいますが、心理学や精神医学、脳科学の世界では人間の記憶は持続時間によって
* 超短期記憶
* 短期記憶
* 長期記憶

の3段階（もしくは中期記憶を含めて4段階）に分かれる、という話だけ今回は取り上げさせてください。
:::

それぞれ一言でまとめると、**「人間は同じ情報を改めて記憶することで、記憶が定着する」「記憶の定着にはフェーズがある」** という話です。ここまでは昔からある話です。
じゃあ **「何故教科書を読むよりも問題集が良いのか」** という話ですが、これは最近の理論になります。

サイエンスという雑誌でカーピック博士が行った実験をもとに、[面白い論文](http://learninglab.psych.purdue.edu/downloads/2008_Karpicke_Roediger_Science.pdf)が掲載されました。ただ上記論文は見れない人がいると思うので、[わかりやすくまとめてくださっている記事](https://www.tkg-jp.com/pickup/detail.html?id=475)が参考になるかと思います。

:::note info
結果としては
* インプットの質や量は学習結果に影響しない
* アウトプットの質や量は学習結果に影響する

という実験でした。
:::

私はこの結果を **「インプットしたことを繰り返しアウトプットしていくことで、記憶の定着フェーズが次の段階に移行する」** と読解しています。

最初の話に戻ると、生徒がテストの点を取るには学習事項を定着させる必要があって、

① 教科書を読んだり、授業で聞いたりしただけの内容は超短期記憶
② 改めて問題集を解いたり、ノートにまとめることで短期記憶へ移行
③ ②を繰り返すことで長期記憶へも移行は可能
④ より持続時間の長い記憶とすることで、テストで取り出しやすくなる

と、いうのが「（テストの点とりたいなら）問題集を解くといいよ」の背景なわけです。

#### 2-0-2.エンジニア文化への応用

上記の話ってエンジニアの世界にも当てはまる（医学とか法学とかも当てはまるだろうけど、それはさておき）んじゃないかな、と私は思っています。
今はGoogle検索やエンジニア同士のコミュニケーション、もしくは先人の記した書籍に頼ることで、困ったこと詰まった内容を解決しやすくなったと言われています（全部ではない）。最近はAIに頼る人も多いかもしれないですね。インプットには困らない時代なわけです。
でも「前もこれ調べたな…？」なんてことを繰り返したら、業務の効率ってなかなか上がらないんじゃないかと考えています。
また小学校の算数を応用して中学校の数学が成り立つように、初歩的な内容を繰り返し調べていても複雑なレイヤーの課題をすぐに解決するのは、難しいのではないでしょうか。
そこで提唱したいのが、 **「アウトプットした方がエンジニアとして成長する可能性高い」** という結論です。
じゃあ「より効率的に成長するために、アウトプットって具体的に何をするべきか？」というお話については、次の節で定義していこうと思います。

### 2-1.誰にも見えない（見せない）アウトプット

恐らくすべてのエンジニアが無意識でやっているローカルな作業は、ほとんど見せないアウトプットにカウントして良いんじゃないかと思います。これを繰り返すことで、普通に人としてエンジニアとして成長する要素もあるように感じます。

##### <<具体例>>

![study_night_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2773852/473a1ba0-0cfd-8715-4271-0409e3fd27a7.png)
ex.)問題集を解く

* コードを書いてテストする
* テキストエディタにメモする
* 設計図やフロー図などを書いて情報を整理してみる
* プライベートなGitリポジトリ等に成果物を保管しておく

##### <<メリット>>

* いつ実行しても、実行しなくても良い
⇒心理的ハードルが低い
* クオリティを気にしなくて良いので参入障壁が低く、必要な時間が短く済む
⇒物理的にもハードルが低い

##### <<デメリット>>

* ファクトチェック、正誤判断、の視点が限られる（自己採点しようのないものもある）
⇒正しく学べているか不安定なまま成長に繋がる
* 社会的評価には繋がりにくいものが多い
⇒お金（報酬）が得られない結果、モチベーションの維持に支障が出る

### 2-2.非同期だけど他人に見えるアウトプット

上記を更に発展させて、誰かと共同作業したりお仕事として成果物を納品したりするのも、アウトプットの1つじゃないかと考えます。ここまでは、お金をもらっている多くのエンジニアにとって経験があるのではないでしょうか。

##### <<具体例>>

![school_test_seifuku_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2773852/5048d099-e756-8679-82d6-778c04b7b347.png)
ex.)定期テストに挑む

* ブログ記事を書く
* 資格試験に挑戦する
* アプリを作って公開する
* 動画を収録して公開する
* 手順書や設計図、スクリプトなど、成果物を納品する
* パブリックなGitリポジトリ等に成果物を保管しておく

##### <<メリット>>

* ファクトチェックや正誤判断をしてもらえる可能性がある
⇒自分の成長する方向が誤っていた時、軌道修正できる
* 社会的評価に繋がる
⇒お金（報酬）が得られ、モチベーションになる
　⇒いわゆる「外発的動機づけ」なので、教育学的にどうかは議論の余地がある

##### <<デメリット>>

* 他人に見せる以上、最低限手を抜けなくなる
⇒見せる相手によって難易度や手間、求められるクオリティが変わる
　⇒参入障壁になる
　⇒心理的ハードルにも繋がる
* 時間的制約（締め切り）を課せられていることがある
　⇒物理的ハードルに繋がる

### 2-3.同期した状態で他人に見せるアウトプット

このパターンがなかなか希少で、経験のある人は少ないんじゃないかと思います。昨今の教育業界でもこの学習方法は注目されていて、「課題解決能力を育む」だとか「主体的な学び」だとか言われているやつです。流行りです。

##### <<具体例>>

![happyou_school_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2773852/35ed872d-b1fa-e1b1-5cda-c616345ce4fd.png)
ex.)論文やレポートを書いて発表する

* 講演会で登壇する
* ペアプログラミング
* 成果物を見せながら説明する
* あるテーマに基づいて議論する
* 展示会などで関わった商品を説明する

##### <<メリット>>

* ファクトチェックや正誤判断をしてもらえる
⇒自分の成長する方向が誤っていた時、軌道修正できる
* 社会的評価に限らず、人間関係の形成やソフトスキルの訓練にも繋がる
⇒目の前でリアクションをもらうことで、自分の成長を実感できる
　⇒「内発的動機づけ」にあたり、自主的に更に研鑽しようという意思に結び付く

##### <<デメリット>>

* 他人からどんなリアクションが来るかわからないので、手を抜けなくなる
⇒原稿の用意、情報の整理整頓、資料の作成や削減、真偽の確認、など
　⇒参入障壁になる
　⇒心理的ハードルにも繋がる
* 自分以外にも時間的制約を課せられていることがある
　⇒より高い物理的ハードルに繋がる

### 2-4.考察

ざっくり言ってしまえば、「難易度別に色々なアウトプットの手段があるから、TPOに応じて適切なものを選んでいきましょう」ってことで良いんじゃないかなあ、と思っています。
しかしアルファベットの書き取り練習を繰り返しやっても英語が喋れるようにはならないように、テキストエディタでコードを書いてテストを繰り返しても面白いゲームアプリは作れるようにはならないし、快適に動作するWebブラウザアプリも作れない、と考えます。
難易度の軽いものから挑戦して行って、いつかは人目に晒されることで、質の高い学びに繋がるのではないでしょうか。

[(目次へ)](#目次)

## 3.具体例の具体例

ここで一つ、社内で起きた興味深い出来事をご紹介したいと思います。

（Aさん）「今年AIをテーマに記事書きました、不安なので先輩社員の方々チェックお願いします。」
（先輩Bさん）「△△の話は真偽怪しいので、見直した方が良いと思います、参考文献はこちらです」
（先輩Dさん）「△△の話はウソ言っていないですね、参考文献はこちらです」
（先輩Cさん）「○○の話は主題と逸れるから、別の記事にしても良いと思います」
（先輩Eさん）「アウトプットの内容を精選するのも1つの手段だと思います」

さて、この話で質の高い学びを得たのはAさんだけでしょうか。
誰がどんな学びを得たかはさておき、私は「評価する側も評価される側も、学びはあったんじゃないか」という感想を持ちました。
また見ていた私も「なるほど...」くらいの学びにはなりましたが、約2週間経って記事を書いている今は忘れかけております。しっかり忘却曲線をなぞっていました。チャットで残っていて良かった。
上記には分類していませんが、アウトプットを評価することも、アウトプットの1つだと考えます。評価する側される側は当事者として、きっとしっかり覚えていることかと思います。
要はどんな位置関係（行動の主体なのか評価する側なのか）どんな結果であろうとも、 **積極的に行動した方がお得だよね** 、という事例でした。

## 4.まとめ

* アウトプットは学びに繋がる

元教育関係者として言いたいのは、ドキュメントを見たりコードを眺めたり、アプリの挙動を確認するだけで得られるものは限られるんじゃないかな、ということです。
エンジニアとしてコードを書いたり何かしらの商品を納品するのは当然のこととして、ブログ記事を書いたり、発表して誰かから評価をもらうこともまた、コードを書くのと同じくらい得るものがあると考えます。
また、おそらくこれまで、IT界隈では「手を動かした方が勉強になるよ」論はあったかと思うのですが、経験に基づくフワッとしたお話が多いかと感じていました。そこの補助として、ちゃんと学術的に証拠があることを示せていたら良いな、と思います。

* アウトプットの手段は豊富にある

「じゃあ上記の証拠を示されたところで、具体的に何をすれば良いの」「お仕事無いから（お金絡んでないから）アウトプットできないよ」という意見もあるかなーと思ったので、そこも含めて「体系化」という手段で1つの記事にしてみたつもりです。
正直私のIT業務経験はとても短いので、他にどんなアウトプット手段があるかは把握しきれていないものだと自負しております。
これから更に勉強させていただけたら幸いです。

## 5.あとがき

今回はこれまで実践してきたアウトプットを体系化していくことで、いわゆる「知的な便秘」に対するアンサーを書いてみました。
今後取り組みたい人への後押しになれたら幸いです。

以上NTTテクノクロスアドベントカレンダーの25日目、だはがお送りしました。
弊社に興味を持っていただけた方は、[こちら](https://www.ntt-tx.co.jp/)をご覧ください。
本日でアドベントカレンダーは終了となります。
お付き合いいただきありがとうございました！Merry Christmas！

## 6.出典

* エビングハウス忘却曲線
http://matsushima.ed.jp/jody7mwi1-498/

* 記憶の分類とその再検討
（梅本 堯夫　京都大学教育学部『失語症研究』1984 年 4 巻 2 号 p. 614-619）
https://www.jstage.jst.go.jp/article/apr/4/2/4_2_614/_pdf/-char/ja

* The Critical Importance of Retrieval for Learning
（Jeffrey D. Karpicke and Henry L. Roediger III. The critical importance of retrieval for learning. Science, 319:966-968, 2008.）
http://learninglab.psych.purdue.edu/downloads/2008_Karpicke_Roediger_Science.pdf

* 【てら先生コラム】第4回：「漢字や単語の暗記がニガテです」というご相談
https://www.tkg-jp.com/pickup/detail.html?id=475

* Kahoot! for schools
https://kahoot.com/schools/

* いらすとや
https://www.irasutoya.com/