もうすぐエンジニア3年目に突入するということで、いつも以上に真剣な考え事が多くなりました。
個人的には、3年目は初級とも中級ともいえず、そろそろその間にある壁を越えるべきだが頭打ちになりかねない、難しい時期に突入しているのではないかと感じています。
そして、実のところ最近の私には、それ以前の困難もありました。
これから書くことは、今の私にとっての特効薬にすぎません。
決して一般論ではなく、次のフィールドに進んだら適用できなくなるかもしれない、だからこそ今書くべきこと。
コロナ後遺症によるパラダイムシフト
エンジニア2年目の後半であるこの頃は、コロナ後遺症と考えられる不調に悩まされていました。コロナ発症直後に経験し、一度は良くなりましたが、一ヶ月経って再燃したものです。
思考をまとめる力が低下し、生活の中心だったプログラミングですら、1日に15分程度しかこなせない時期もありました。
この症状がブレインフォグと呼ばれるのなら、私はとても軽度なはずです。5 + 8 の暗算に考え込んでしまう時はありましたが、日常生活で多大な支障を感じるほどではなく、エンジニアという高度な思考が求められる職業でなければ、症状に気づかなかったでしょう。
幸いなのは、強い脳疲労を抱える中でも、限られた脳のリソースをどう生かすか、この状態でもできることを増やすための工夫に、頭を巡らせる余力があったことです。（思考がまとまらないがゆえにインプットやアウトプットには支障がありましたが、雑多に思考することは辛うじてできました。）
休む工夫や適度なリハビリを重ねた結果、今は、文字を見ると頭がショートするような感覚もなくなり、こうしてこの文章を書けるくらいにまで回復しています。読書もできるようになりました。
おかげで、この状態に陥ったメリットを一つは生み出すことができます。一心不乱にコードばかり書いていた私が、本当にそれだけでこの先も成長し続けられるのかと、立ち止まって考える機会が生まれました。
これは、膨大な時間を費やすことだけを成長の支えとする根性論を捨て、持続可能な学びについて考える好機なのかもしれません。
休む技術、這い上がる術：無意識に成せていた行動を分解する
当たり前にできていたタスクがまったくできない状態に陥る経験が、むしろエンジニアとしてさらに成長するために、必要な過程だったのではないかと思うことがあります。もちろんそれは、数多くの困惑と回復を経て、最近やっと言えるようになったことですが…
この章では、何を成すにも賢くエネルギーを使わなければならない状況下で模索した、負荷分散の術と、試行錯誤の日々について話します。
ここで語る過程には、「何も考えずにとりあえず休みなさい」というツッコミが入るかもしれません。先の見えない状況で、休む忍耐力を持ち合わせていないのは、私の一つの弱点だと自覚はしています。
しかし、わずかでもこの状況を「どうにかできるかもしれない」と思えた体験は、この先もきっと重要な助けになるはずです。
ハードルを下げる
症状が出始めた当初は、本当に何一つ手につかない状態にありました。つい昨日まで熱心に取り組んでいたプロジェクトに対しても、何も感じず、何も考えられない、そんな日が唐突に訪れたのが、症状の始まりだと認識しています。
そんなとき、同じくプログラミングを生業とする友人が多くの言葉をかけてくれました。共に勉強し、いつか共同でアプリを開発したいという構想を共有していた仲で、私の異変を真っ先に察知した人でした。
そんな友人からのアドバイスの主題は、次のようなものです。
新しく何か始めたい時は、ハードルを下げると良い
なぜそうすべきなのか、脳科学の理論を噛み砕いて語ってくれました。次の記事で語られている内容に近いものです。
そして、習慣化に至る具体的な方法として、小さい努力を継続することが大事なのではないかと結論づけたのが、先ほどの主題でした。
これまでの私の学び方は、客観的に見てハードルが高いものだったと思います。技量に合わない壮大なものを作ることを目標に設定し、自分に足りない知識を炙り出す。これはある意味、挫折を材料として、学ぶ目的を自らに植え付ける戦略でもありました。初見の理論であってもデモを作りながら学ぶような、インプットとアウトプットの同時進行も、それなりに負荷の高いものです。休憩を疎かに毎日何時間も、脳を酷使していたのは紛れもない事実でしょう。
そんな習慣が絶たれた今、元の自分を取り戻すことは「新しく何かを始める」ことに他なりません。取り戻すというよりも、新しいやり方を見つけるべきなのです。
この友人の言葉から、脳が過負荷にならずに済む生き方を模索するようになりました。もちろん、この言葉をもらった当時はまだ、そんなことを考えるエネルギーすらありませんでしたが、この発想は後に大きな手がかりとなります。
負荷に耳を傾ける
どうすればいいのかもわからず、これ以上悪化することが何よりも怖かった当初は、多くの人の力を借りて、少し休養の時間を作りました。その結果、意欲だけは順調に取り戻していきました。
逆に生まれた意欲を封じ込めておくことが難しくなり、時期尚早かもしれませんが、「今の自分に何ができて、何ができないのか」を見極めるための活動を開始しました。万人に推奨はできませんが、やってみなければ自覚できない症状もたくさんあるものです。
当時の状態をいくつか抜粋します。
- 文章を書くよりも、読む方が不得手。文字に焦点がいつまでも当たらないような感覚から抜け出せない
- 技術ドキュメントなどの長文や、SNSなど大量の情報を追いかけていると吐き気を感じる
- 記憶力は問題なく、誕生日など数字の羅列を覚える速さは相変わらずだった
- 意思決定には非常に時間がかかる。次に自分が何をしたいのかすら、ぼやーっとして突き止められず、最短でも一時間くらい悩んでようやく決まる
会話には支障はありませんでしたが、文章の読み書きには大きな負荷を感じました。特に、文章を読んでいると、頭の中にどんどん文字が溜まっていく感覚があり、未処理の文字情報ですぐに頭がいっぱいになって頭痛すら覚えるのです。（例えるなら、すでにお腹は苦しいほどで消化がまったく追いついていないのに、もっと食べなさいと次々食べ物を口に放り込まれる…文字に対する嫌悪すら抱えざるをえない状態でした。）
言葉に関しては、テキストより音声の方が素早く理解し、容易に組み立てられるようでした。（これは本来の自分とは逆の状態でした。元々は音声ベースの講義よりも読書の方が圧倒的に得意だったのです。）そのため、仕事の相談は基本的に通話でお願いするなど、密かに工夫をしていました。
一連の症状には日内変動があり、起床直後は比較的頭が軽く、時間が経つにつれてどんどん重くなっていきます。また、日によっても程度が異なり、集中力のなさ、思考の途切れなどの症状が軽い日も時々あります。
何もしていない時を含めた普段の体感としては、脳に霧がかかっているというより、重たい布団を被っているような感覚でした。霧で包まれているよりもっと重いのです。
そして、何かをし始めると、重い処理でPCが熱くなるように、脳をフル稼働させているのが自分でもわかります。
そうして脳にかかっている負荷をリアルタイムで自覚できていたため、すべての活動は休み休み行っていました。しかし、休憩時間を長くしてみても、起床直後は比較的頭が軽く、時間が経つにつれてどんどん重くなっていく、そのスピードはあまり変わらないようでした。
重くなった頭をリセットするには、休憩ではまったく足りないようです。朝昼夜問わず、ひたすら眠るしかないのでしょうか。
無駄な処理を認識する
眠ることで一時的に思考力が回復する現象は、まるでコンピュータの再起動のようです。人間の脳をコンピュータに擬えることで、ある自問が生まれました。
果たして私は、休憩によって思考をリセットできているのだろうか？と。
PCの動作が遅いと感じたとき、とりあえず再起動することによって改善した経験は、誰しも多くあるのではないでしょうか。
これはプログラマ向けの表現になりますが、再起動は予期せぬ状態を破棄し、プログラムが制御できる範疇の状態に戻すことです。再起動で動作不良が直る原理は、根本的にも「リセット」という言葉で説明できます。
さて、コンピュータの動作が遅くなる原因は多数考えられます。
直感的な例を取り上げると、バックグラウンドで動作しているアプリがある場合や、ブラウザであれば開きすぎたタブなどが、使っていなくても存在するだけでメモリを消費している場合です。
雑にいえば、少なくとも次の2つは確実に動作を遅くする要因になります。
- 背後で知らぬ間に動き続けているものがある
- 動いていなくても、存在するだけで容量を食っているものがある
ここでは、「もの」という、あえて抽象的な表現を使いました。この「もの」という単語を、「思考」に置き換えたとき、休憩中もどんどん頭が重くなっていく現象に説明がつく気がしました。
集中力のなさ、思考の途切れなどの症状が軽い日は、反対に、一度考え始めたことを他の作業に移っても考え続けてしまっていることに気づいたのです。
タイマーで作業を中断する習慣がつき、意識的に作業時間を減らすことには成功していました。しかし、ずっと頭の片隅で思考が続いている状態を止めることはできていないため、いくら休憩を取っても知らぬ間に疲弊していく問題は解決できずにいました。
これは発達障害でみられる、過集中という特性に対してもいえることかもしれません。過集中の対策として、定期的にタイマーを鳴らすことで時間を認識し、作業を切り替えるきっかけを作る方法がよく紹介されます。たしかにきっかけとしては有効です。ただし、それだけでは「考え続けてしまう」という根本的な特性にアプローチできるとは限らないように感じています。
つまり、体は休んでいても、頭が休まっているかは別問題。回復するために休息が必須なら、「休んでいるようで休めていない」状態をどうにかしなければならない。
そのために、すべての作業を投げ出すべきなのでしょうか？できれば今はそうした方が良いのかもしれません。しかし、いずれは根本的な解決策を見つける必要があります。
脳の無駄な稼働を減らすヒントは、既に見えていました。簡単なことではないかもしれませんが、せめて次の二つさえ、うまくできればよいのです。
- 動き続けている思考を一旦置いておく
- 容量を食っている思考を吐き出す
脳の棚卸しをする 1. 段階的なアウトプット
「考えないようにする」ことも、それはそれでエネルギーを浪費するものです。無意識に起きてしまうことを意識的に止めようとするのは、一種の抑圧であり、封じ込めるにはエネルギーが必要になります。
考えが止められない中でも、脳のメモリ不足に陥らないようにするには、考えたことをその都度手放すことが必要そうです。
まず試したのは、考えたことを都度文章に書き出そうとすることでした。しかし、言語化によって余計に疲弊し、逆効果になるという状態が続いていました。
断片的な思考はいくらでも浮かぶ状態でしたが、それらを繋ぎ合わせて、一つのアウトプットとしてまとめる思考作業は、まだ高負荷すぎたようです。
なんらかのアウトプットができる状態を取り戻すには、その「思考を繋げる」ことへの困難にアプローチする必要がありました。
文章という完全体まで至らなくてもよい、気楽に「書き出す」形態として、真っ先に思い浮かんだのは、箇条書きです。しかし、箇条書きでは、思考の流れや関係性を書き起こすことは難しく、思考を整理する目的では、結局文章としてフローを作らないといけない状況に陥ります。
最初から文章を「組み立てる」ことができないのなら、思考の断片ごとに書き出せばいい。そうして見える状態にした上で、後から繋げればよい。…このような、段階的に「流れ」や「関連」を記録できるツールがあれば、一度に負荷をかけることなくアウトプットにたどり着けるのではないか。
まさにそんなツールとして、ふと思いついたのがマインドマップでした。
休憩前のクリーンアップ作業として、マインドマップを活用し始めました。Xmindというソフトウェアを使って、考えていることをマインドマップに書き起こしてから、休憩に入るようにしたのです。
そうして、保留中・実行中の思考タスクを手放すことで、少しずつ脳のON/OFF切り替えができるようになっていきました。
この工夫により、休息の質が上がったことを自覚できたのは、すぐに頭が重くなってしまう症状が緩和されてきたからです。
脳の棚卸しをする 2. 情報の濁流に呑まれないインプット
なぜ、マインドマップが有効だったのでしょうか？その背景は、止められない考えとはどのようなものか、を突き詰めていくと見つかるような気がしました。
私の場合、次のような考えは、なかなか止めることができません。
- 忘れられない
- まだ整理できていない
だとすれば、このような思考を手放すには、逆の性質を持たせれば良いはずです。
- 忘れても良い状況を作る
- 整理しやすい形式にする
この二つを一度に、多大な負荷を伴うことなく実現できる手段が、私にとってはマインドマップだったということなのかもしれません。
そして、このようなマインドマップの恩恵を、読書などのインプット作業の再開にも応用しました。
文章を読んだら、入ってきた情報をその都度マインドマップに書き出します。こうすることにより、処理が追いつかずに頭がいっぱいいっぱいになっていく感覚が軽減され、少しずつ技術書による学習を再開できるようになったのです。
とりあえず写し書きをしておくと、入ってきた情報を脳内に留めておく必要性がなくなります。読みながら「理解」しようとしたり、読みながら「記憶」しようとしたりといった、自動的に有効になるマルチタスクを抑える効果があるのかもしれません。その結果、高い負荷をかけることなく、「読む」タスクもこなせるようになっていきました。
また、マインドマップ（Xmind）では、情報の関連に気づいたら、矢印や要約囲みを使って、すぐに視覚化することが可能です。「これは何と関連するんだっけ…？」などといった、関係性を脳内で検索する負荷も軽減することができます。
タスクを直列化する
マインドマップという強力なツールの力を借りることで、少しずつ、読書などのインプットや、思考のアウトプットを再開できるようになりました。
しかし、依然として業務に支障をきたす状態は続いていました。 作業単体はこなせるようになっても、マルチタスクになると、再び症状が顔を覗かせたのです。
ここでいうマルチタスクは、決して大層なものではありません。どうコミットを分けるか考えながら修正したり、ドキュメントを読みながらコードを書いたり、普段ならマルチタスクとして認識すらしないような、ごく当たり前にこなせるはずのタスクです。
ここで必要となったのが、「話題を分割してから各話題に取り組む」ことです。
「レビュワーにどう報告するか考えながらコードの修正を行う」というタスクを例に考えてみます。このとき、初めから修正作業に取り組もうとすると、報告する粒度を意識しながら作業する必要があります。そんな無意識の並行作業を避け、一つずつ順番にこなしていけばよい直列的な状態を作るため、作業してから報告するのではなく、報告する粒度や報告のあらすじを決めてから作業に入るという工夫をしました。
これは当時の私にとっては、脳に一度にかかる負荷を軽減して、なんとか必要最低限の作業をこなすためにやらざるを得なかったことです。しかし、解決すべき問題を分割し、「何に対して」「どう対応するか」をしっかり決めてから実際の作業に入ることは、エンジニアとしての普段の業務でも習慣にすべきことだと感じました。
このようなスタイルで業務を進めるにあたって、若干の枷となるのは、複合的なタスクであっても、取り組む過程を人に見せることに抵抗を抱きがちな、「完璧主義」な性格です。
解決すべき問題を整理する工程には、まだまだ時間がかかります。作業を完結させてから公開するのではなく、過程も見せていかなければ、進捗がまったく伝わらない状態に陥ってしまうのです。
整理する過程も見せることは、完璧主義の殻を破らない限り、一切の抵抗なしにできることではありません。しかし、作業ペースが落ちており、進捗が生みづらい状態では、なおさらやるべきことです。
行き詰まっているところを客観視できたり、他の人にも開示することで、一人で無限に悩んでいたタスクを円滑に進められる可能性もあります。そう気づけたことは、今後のエンジニア人生において、プラスの出来事だと思っています。
結び：戦い方を変えるということ
できないことが増えたことで、意識しなければならないこと、やらざるを得ないことが増えました。そして、それらは今までの私が抵抗を持ち、避けてきたことばかりでした。
- 「ハードルを下げる」ハードルを下げ、着実に取り組むこと
- 「負荷に耳を傾ける」過度に楽観視せず、自分を正しく理解すること
- 「無駄な処理を認識する」自分で自分に課している負荷を自覚すること
- 「脳の棚卸しをする」根性論に走らず、休むために工夫すること
- 「タスクを直列化する」作業の中で偶然生まれる発想に頼るのではなく、事前に問題を整理すること
後遺症との戦いも、アサインされた仕事も、究極には一人の戦いです。
しかし、戦い方を変えることに関しては、誰かの力を借りることができるときもあります。一人で戦わなければならないことだとしても、戦い方をよりよく知る人は自分以外にいるかもしれません。
- 「戦い方を変える」人に開示すること
これが、ここまでの回復に至る最初のピースでした。もしこれが欠けていたら、私一人の知恵では、ここまで乗り越えてくることは難しかったでしょう。
これからの個人開発、持続可能な学びのために
コードを書くという、暇さえあれば取り組んでいた習慣が絶たれたことは、私はこの先個人開発で何をしたいのか、何をすべきなのか、冷静に考え直す時の訪れでした。
個人開発を再度習慣化するには、少なからず手段を改善し、目的を取り戻しておいた方が良さそうです。
そのコードに意思はあるか？
私はこれまで、四六時中、ひたすらコードばかり書いてきました。常に何かしら、作りたいと望んだものの実現に夢中になり、本を読む時ですら、並行してコードを書くことをやめられませんでした。その作業量は、確かにここまでの成長を支えてきたものかもしれません。
しかし、作業量を優先したことで、犠牲にしてきたものもあります。より良い設計やコードの検討、それらの言語化に時間を割かずに突き進むことは、根拠も意思もないコードを量産しているにすぎません。
だから、闇雲にコードを書くだけでは身につかないスキルがあると、今では感じています。私にとって必要なのは、立ち止まって言語化することと、技術に対する「面白そう」以外の価値観を養うことです。
惰性の本音を問う
個人開発で行き詰まったとき、そもそも何のためにやっているのか、意味が欲しくなることも正直あります。個人開発では、すぐに仕事で使う技術に絞らず、さまざまな分野に触れようとしているので、尚更でした。
楽しさが伴わないと、過程に価値を感じることが難しくなります。また、必要性が伴わなければ、楽しさの代わりに使える予備的なモチベーション、結果への期待すら保てなくなります。
「楽しい」と「必要」が十分に揃わないとき、それでも何のために個人開発をやるのか。そう自問したときに、続けることの価値を次の2つに置いている自分に気がつきました。
- 自分に自信をつけたい
- 仲間が欲しい
自信を持つために - 生み出すための深さを持つ
自信をつけるためには、人に見える形を生み出すしかないのだと、ずっと思っていました。
しかし現状は、どれだけ多くのコードを書いても、確かにできることが増えてきたとしても、自信が比例していないのが事実です。
それは、言語化できるほどの理解まで落とし込まずに、どんどん次の実装へと進んでしまっていることが原因なのかもしれません。
目に見えるスキルばかり追求した結果、目には見えないプロセス（理解する過程など）をおざなりにしてきたのではないかと感じています。そして、空の箱から取り出せるものが何もないように、人には見えない材料（深い理解や洞察）がなければ、人に見える形を生み出すことも難しいのだとすでに思い知っています。
より深い理解を追求し、それを言語化するにあたって、アウトプットの方向性の改善が必要です。この改善については、後に取り上げることとします。
協働するために - 交わるための広さを持つ
「仲間が欲しい」というのは、長年抱いている切なる夢です。今、周りにいる人たちはまだ仲間ではない、と言いたいのではなく、その人たちと「議論できるようになりたい」という意味です。
共通領域の十分な語彙を持ち、責任を持てる見解を持ち、ディスカッションで十分に戦えるようになるには…周りの人と重なるフィールドを持てるように、自分のフィールドを広げていく必要があるのです。
この思いは、個人開発でさまざまな分野に挑戦する、確固たるモチベーションになるはずです。
小さい単位で見える化する
さて、症状が出る直前も、個人開発としていろいろなコードを書いてはいましたが、それを見える形にはできていない状態が続いていました。成果としてアウトプットしていても、言葉としてのアウトプットはしていなかったのです。
私にとって、「何かを作る」と「言語化できる」の間には大きな壁があります。
その壁を乗り越えられたら、理解まで落とし込めた確実な武器が増えていき、人に見える形でアピールすることも容易になり、着実に自信に繋がるはずです。
完璧主義と問題の分割
言語化を阻む壁の一つは、単純な文章化能力以前に、性格に起因するものです。
昔から「過程を見せる」ことがどうも苦手で、何を作ってもいつも完成してから人に見せる傾向がありました。
しかし、「完成」とはどこにあるのでしょうか。自信が完成の先にあるのなら、自信のない私が、自信を持って完成だと言える日は、本当に来るのでしょうか。
物事はよく知るごとに、壮大に鮮明に見えてくるものです。自分自身が成長して、視野が広くなればなるほど、自分には及ばないものがはっきりと見えてきます。つまり、私はきっとどこまで行ってもすべて未完成だと言うでしょう。（実際、ソフトウェアに完成などないはずです。）
ならば、人に見せられる準完成ポイントをこまめに設定した方が得です。ゴールが遠い大きなトピックに取り組むときには、なおさら。
今やるべきか、一ヶ月後にやるべきか
私達の脳は不確実性を嫌う。今すぐ手に入るリンゴは確実だが、１ヶ月後のリンゴは不確実だし、1年後のリンゴはさらに不確実である。そのため、不確実性が高ければ高いほど（時間が後になるほど）、その価値は割り引かれて感じられる。
時間割引の理論とは、「手に入るのが後になればなるほど、価値が割り引かれて感じられる現象」です。
少し拡大解釈が含まれるかもしれませんが、この理論から導けることが2つあります。
- 後回しにしたものほど、自分の中での価値は下がっていく（そもそもの意義を感じられなくなる）
- 遠すぎる目標は諦めが近くなる（モチベーション維持が難しい）
活動について発信することを後回しにし、活動自体を優先し続けると、次第に発信する意義すら感じられなくなります。
さらに、人は後から振り返ろうとしても道を忘れてしまいます。
作ったものについて語るのであれば、ゴールではなく、過程を見せることができた方が、深みのある語りができます。臨場感ある過程を記録できるのは、「今」の自分だけです。
自信は「自覚」から育てる
一時期、個人開発の進捗に関する日報を書いていた時期がありましたが、なかなか良い効果を感じていました。
自らの前進を自覚できる痕跡を残しておくことは、モチベーションを保つ上で重要です。
また、過去の自分がどこでつまづいたのかを記しておくことで、挑みを再開する時に「どこまで挑戦したのか」を把握し直す手戻りがなくなります。単純に、失敗や不完全な挑みを忘れず、未来の自分が伏線回収してくれる可能性が高まるのは面白いものです。
立ち止まることで前に進める
個人開発は、実装スピードにこだわらない方が良いのかもしれません。
意思決定をこまめに言語化するなど、立ち止まる機会を作りたいと考えています。
2年目の結び：自らを手なづけるということ
エンジニア2年目は、何をどう学ぶべきか？と悩み、伸び悩みを感じることも増えてきました。
自由とは、個々の道を縛るレールがないということですが、反面、正解へ導くレールもないということです。
自由さの中で、「誰かに育ててもらおう」ではなく、自ら育とうとするとき、怠けてしまうリスクもあれば、頑張りすぎてしまうリスクもあります。
休む勇気をなかなか持てない私は、後者のリスクについて、一度論理的に立ち向かってみたいと思っていました。
「休むときは休む」というメリハリは、自由な環境に適応する一つのスキルです。自由な環境下でも生産性を発揮するために必須のものです。
症状に悩まされ始めた頃、相変わらず無理をしようとしていた私でしたが、そんなとき、ちょうど耳にした言葉があります。
「無理する」と「頑張る」は違う
この言葉は救いでもあり、試練でもありました。
自分の中から、「無理をする」という選択肢を排除したとき、何が残るのか。当たり前のこともできない状態で、無理のない活動範囲に限ったとき、自分に何ができるのか。
そこで得た気づきを、これからの3年目に向けて残しておきたいと思いました。無力感に立ち向かった記録が、このエッセイです。