継続的なアウトプットのためのマインドセット

論旨

今日までにアウトプットの媒体や、アウトプットの内容（書き方）について触れてきたが、アウトプットのためのマインドセットにも言及していこうと思う。
「継続的」なアウトプットが目的になるので、アウトプットを習慣化するところまでをゴールにしたい。
せっかくのアドベントカレンダー記事なので、想定するゴールは「完走賞を得る」としたい。

つまり、25記事を毎日書き続けるためには？というテーマが副題となる。

想定読者

• 書く事は問題ない（昨日、一昨日の記事の内容は既に問題ない段階である）方
• ネタが続かない方
• モチベーションの維持に悩んでいる方
• アウトプットをする目的が明確な方

いわゆる「やれば出来る」人が対象となる。
なお、「やった結果、うまくいかない方」も対象となるので安心されたい。

アウトプットをする目的について

筆者の個人的見解に基づくため、必ずしも一致する必要はない。

筆者の考え方によるが、メモとか備忘録という形式になったのは結果論であって、メモをするためにアウトプットをしているわけではない。
大体の場合において、アウトプットはインプットの質を高めるために行うものという認識だ。

とはいえ、書き始めなどは過去の経験則に基づく内容などはインプット量も少ない事もある。
インプットがなければアウトプットの価値はないのか、というとそうではないが、アウトプットの過程でインプットが足りない部分、特に弱点としている単元などを割り出す事ができる。
そのため「とりあえず書いてみる」には結果的にインプット量が０だったとしても意味がある行動だと筆者は考えている。

このように、本項においてはアウトプットをするという行動について、自分自身を納得させられるぐらいの意味を持たせられるかどうかが鍵となる。

目標設計の考え方

アウトプットの目的を考えてはみたものの、継続することは言うほど簡単ではない。
特にモチベーションは簡単に崩れやすいため、いわゆるリマインドが「定期的に」必要になる。
ポイントとなるのは、一度立てた目標は絶対ではなく、ケースバイケースで変わるという前提が必要 ということだ。
目標はあくまで目標で、しかも常に古くなってしまうためいずれ必ず陳腐化する。陳腐化する目標が問題なのではなく、時代の変化がそれだけ早いので目標が陳腐化したら、それ自体が成長の証なのだと考えよう。

アウトプットの話題から若干外れるが、たとえば10年計画・5年計画・1年計画のように大きなものから小さいところへ目標設計（ゴールベースプランニング）を行い、１年計画をまた半分に分けて月別計画を立て、計画に沿って毎日の作業を棚卸ししていくと、必然的に10年計画を満たせる行動ができる、という話を聞いたことはないだろうか？
フランクリン・プランナー（フランクリンシステム手帳）の考え方だが、非常に理に適っており、難しいことを考えなくても良いのがお勧めできるポイントだ。¹

アウトプットの目的については、ゴールベースプランニングレベルの難しくないとはいえ、大掛かりな計画を練る必要はない。散発的な計画で構わない。
ただし、継続性の高い方法をトライアンドエラーで模索し続ける必要がある。
どういう目標であれ「続ける事に意味がある」という前提は維持したい。

アウトプットの時の心構え

1. 人に見せる前提を意識するが、コメントを求めない
2. 後で振り返ると稚拙だな、と感じるであろう事を恐れず、稚拙さを受け入れる
3. 内容は拙くても誠実たれ、少なくとも自分には嘘をつかないようにしよう
4. 書き方（表記）を考えるより、何を書きたいかを考える

誤解を恐れずに言えば「手書きノートを公開する」だけなので、周りの影響や見せ方よりも自らの姿勢として「俺はやった」と自分に言える段階を目指そう。
学校の方針や時代によるかもしれないが、筆者は学習ノートを担任に提出してレビューを受けた小学校の頃を思い出す。

人に見せる前提を意識する

手書きメモをすると、後で思い出せるようにするレベルの内容しか書かないだろう。
が、人に見せるようにすると途端に内容の真偽であったり他の人でも同じように解釈できるよう表現を意識したりするようになる。
記事を書こうと思った方だとほとんどの方がメモの時ほど気軽さを感じないだろう（というのは想像に難くない）

案外このアプローチが未来の自分を助ける事になりやすい。
というのも、自分用だと特にWhyが抜け落ちるため「これ何のためにやってるんだっけ？」が発生しやすい。
あとで振り返った時にWhyを読めばとりあえず流れを思い出せるようになっていれば、第三者が読んだ時にも説得力を増しやすい。
それでも分からない時は分からなかったりするので、過信は禁物だ。

稚拙さを受け入れる

昔も今も、同人界隈の絵師がよく言う「絵が上手くなったら本にする」という発言がある。
同じように「プログラミングスクールで勉強してからエンジニアになる」という人がいる。

まず結論からいえば、現場経験に勝るものはないので今すぐに目標に向かった方がいい。
絵が下手なら本を描いてはいけない理由はないし、エンジニアになってからプログラミングを学べば良い。
本人だけのためを考えると、勉強してからやるよりは、その立場になってから勉強した方が実入りも効果も高い。
もちろん、容易なことではない事は理解も認識もしている。が、ここで言いたいのは「挑戦して失敗する事と、挑戦すらしない事は全然違う」という事だ。

同じように、アウトプットを公開することも「綺麗な文章が書けたら、内容が高度になったら公開する」のではなく「今のレベルで良いから一旦公開してみて、その中でブラッシュアップして行った方が圧倒的に効果が高い」という事に気づいて欲しい。
そのためには「自分が過去（現在）に書いたものはレベルが低くて当然」という事実を受け入れられるかどうかがポイントになってくるだろう。

内容に誠実たれ

まず初めに誤解のないようにしておくが、「嘘を書いてはいけない」とまでは言わない。
たとえば、初学者向けに講演をする際に理解度を優先するため「厳密に言えば正しくないが、伝わりやすいものの言い方」をすることがある。
分かりやすいのは、オブジェクト指向の概念の説明だろうか。既に理解している方にとってはうんうん、と首を縦に振ることができるが、これからプログラミングを学ぼうとする方にとって、手続き型処理からオブジェクト指向型プログラミングはパラダイムシフトが起こるため、従来の常識を一旦捨てるという工程が必要になる。
また、オブジェクト指向を理解した後にやってくる関数型プログラミングについても、またパラダイムシフトが発生するため、常識を疑う力が養われていくことだろう。

問題は、これをどうやって理解させるか？というと、筆者の場合はイメージ先行で細かい部分は実践のケーススタディで比較していくアプローチをする。
見た目の違いがわかったら、次は役割や目的の違いを意識する。たとえば、手続き型で書いているプログラムコードをオブジェクト指向に書き直すのはなぜだろうか？
手続き型で困って、オブジェクト指向で解決されるケースはなんだろうか？
同じく、関数型のケースを考えていく。

こうなると、例えば筆者としては嘘を書いたつもりでも分かりにくくするつもりでも、ましてや混乱させるつもりはなかったとして、読者はそのように感じないケースも考えられる。
これは嘘をついていないけど、読者の問題を解決できなかったという意味では嘘になってしまう。こういったケースも含めて「内容に誠実たれ」という意識を持って欲しい。

何を書きたいかを考える

この単元を最後に持ってきたのは理由がある。
書きたい事だけを書けばよい、ということではない事をここまで見てきた。

• 人に見せる努力をする
• 文章は稚拙かもしれないが、向上心を持つ
• 内容は誠実である

これらを満たした上で「書きたい事を書くべき」という話をしたかったからだ。

ここまでにアウトプットの目的や媒体を考えた。
これを踏まえて書きたい事とは何か？という事を考えなければならない。
たとえば、LINEBotを作りたいと考えた時にコードなど動くものから入る方もいれば、体系的な知識から入る方もいる。
アウトプット駆動開発（仮にOutput-Drive Development=ODDと呼ぶ）は、ゲームを遊ぶ時に取扱説明書やガイドブックを読まない層にとって非常にとっつきやすいアプローチではないだろうか？
もっとも、昨今はガイドブックすら存在せず、全部作中チュートリアルで完了してしまうケースも多くなってはいるのだが。

やりたい開発をアウトプットするためにインプットをする。
慣れないうちはこのフローでも良いと、講師としての筆者は考えている。
大事なのは、開発をする事を目的にするのではなく、やりたい事を実現するための手法としてソフトウェア開発があり、開発を行うために必要な知識や技術の棚卸しから始めるべきという、筋道を立てた計画策定である。

現場の開発

システム設計や開発経験がある方はわかると思うが、エンジニアの仕事とはプログラムを書くことではない。
システムを作ることである。
それも、ただシステムを作れば良いのではなく、クライアントの見えざる要望を実現し満足を得るシステムだ。
そのためには、クライアントのニーズを把握、または掘り下げて特定するヒアリングスキル＝コミュニケーションが必要である。
おそらく、他業種（接客業や営業）と比べても細やかな気配りを求められる傾向が強いと、接客業の現場リーダー経験もある筆者は感じている。
エンジニアは同期的コミュニケーションを求められるわけではないので、コミュニケーションスキルと考えられていない節があるが、非同期でもコミュニケーションスキルは必要である事は認識されたい。

せっかくなので、同期的コミュニケーション、非同期コミュニケーションの違いを調べて記事にしてみるのも良いアプローチではないかと思う。

読者に期待すること

来年はぜひQiitaアドベントカレンダー2024の完走賞を狙ってみて欲しい。
そのための練習として、アウトプットを「し続ける」癖をつけておくことを推奨する。

1. 【フランクリンシステム手帳ページ】 売り込みのような表現になってしまったので、念の為アフィリエイトリンクではないことを示す。→https://www.franklinplanner.jp ↩