ソフトウェアエンジニアに求められるアウトプットは社内向けと社外向けに分類できる。
本記事ではそれぞれどのようなアウトプットがあるか整理してみる。
ソースコードをアウトプットだと認識できていないことも多いが、間違いなくソフトウェアエンジニアが最も時間を費やしているアウトプットだ。
アプリケーションやシステムを動かすために書いているわけだが、未来の自分やメンテナに情報を伝える手段でもあるということを忘れずにいたい。 適切にコメントは書けているだろうか、命名や型によって意図を表現できているだろうか、テストは整備できているだろうか。
docstringなどからドキュメントを自動生成する方法もあるが、プロジェクトによってはどうしても分けて作成しなければいけないこともある。
ドキュメントは利用者の目線に立って書く必要がある。 ソースコードと乖離は起きていないだろうか、誰が見てもすぐ使えるドキュメントになっているだろうか。
NotionやConfluenceが代表的だろうか。
環境構築であったり新たな言語を学習したときだったり、他の人（あるいは未来の自分）にとって有益であろうことを覚え書きしておくのだ。 インターネット上の情報よりも信用でき、情報が古かったり誤りがあったりしても直接作成者に質問できるため、迅速な問題解決につながりやすい。
達人プログラマーでも推奨されているアウトプット。
日誌にはミーティングで出た意見、作業内容や学んだこと、デバッグの変数値ややりかけの作業の覚え書きなど、あらゆる仕事に関係のあることを記録する。
作業内容を書くことで頭の中が整理され（いわゆるラバーダック・デバッグ）、後から振り返ることができるなどの利点がある。
日誌とは異なり他者に見られることを前提とした報告書。
チームメンバーとのコミュニケーションとして活用されることもあれば、ちょっとした質問を書いておくとコメントがついたりもする。 チームメンバー全ての分報を確認することは時間的に不可能なので、分報は日誌のような意味合いが強い。 日報くらいが報告としては限界だろう。
業務連絡以外に気軽に話せるチャンネルもあるだろう。 雑談はチームのコミュニケーションを円滑にするため、業務とは関係がない技術スタックは幅を広げるのに有用である。
ソフトウェアエンジニアに人気なのはTwitterだろう。
誰かに情報を伝えるというよりはただの趣味として利用されている印象。
誰しもQiitaやStack Overflow、どこも誰が書いたかも分からない個人ブログに助けられた経験はあるだろう。
学んだことをアウトプットすることで定着させる、アウトプットを習慣化するといった自分のメリットだけでなく、インターネット上に情報を増やすといった点で他者のメリットにもなる。 デメリットは自分の業務外の時間を割いて行うためリフレッシュやインプットに割ける時間が減ることだ。
パッと思いつくのはこれくらいだろうか。
ソフトウェアエンジニアにとってアウトプットは重要で、アウトプットが滞ると次第にインプットも遅れがちになり学習サイクルがゆっくりになっていく。 なんとなく手に取った達人プログラマーを読み、自分の学習サイクルが止まってしまっていることに気づいた。
インプットとアウトプット、どちらも太く保っていきたい。