#7 ソースコードを読むのが怖くなくなった日

 

  一年間の振り返り

 

3月末、社会人としては年度末にあたり、一年間の成果を振り返る季節になった。

 

今年の私はかなり後悔がある。

「今の会社で社内SEになろう」と自分でも納得してスタートを切ったのに、結局のところほとんど成果を上げられず、完全に有言不実行になってしまったこと。

周囲の人も適度なタスクを振ってくれたにもかかわらず、本職に時間を取られて結局先延ばしにしてしまったことも多く、罪悪感と後悔が残る。

 

成果が上がらなかった原因は明白で、

  • リソース投下量（実際に手を動かした時間）が少なすぎる
  • そもそも目標設定が抽象的すぎた

のだが、もう一つの心当たりとして、

 

わからないものに向き合うのが怖くなった結果、本職の忙しさを言い訳にエンジニアリングから目を逸らすようになってしまったのではないかと振り返っている。

その「わからないもの」とは、他人（またはAI）が書いた長いソースコードのことだ。

 

GitHubって何？レベルの未経験状態からスタートして、最初の半年はごく単純なコーディングタスクが多かった。

簡単なコードに触れているうちは心も軽く、AIも駆使して割とトントン拍子に仕事をしていたように思う。

 

ところが、少しずつ機能の複雑さが増したり、フロントエンド-バックエンドの連携や外部システムとの連携、使用ライブラリなどが多いソースコードに触れるようになると、自分でも意識しないうちに恐怖心のようなものがじわじわと蓄積し始めた。

真っ暗な画面に浮かび上がる意味不明の長い文字列。

 

しばらくして、ソースコードを読むにもコツが要るということを知り、なんとかタスクをこなすために「全部は理解しようとしない、一部だけ読む」という実践はできるようになったが、

それはそれで、いつまでも全体像を把握できないという気味の悪さに苛まれ、結局、苦手意識を募らせることになってしまった。

 

  どうすればよかったのか

 

では、この一年を振り返り、どうすればよかったのかを考えてみる。

 

単純にもっと時間をかけて勉強するとか、専門性がないとできない方法ではなく、未経験者でもすぐにできて、もっと早くやっておけばよかったと思えることを考える。

①「後回しにしている自分」に早めに気づくべきだった

まず第一に、「やるべきだとわかっているけど、最近つい後回しにしてしまっているな…」と感じた時点で、しっかりその事実に向き合うべきだった。
 
自分の後ろめたさに向き合うのは難しい。
しかし去年の私は、「本職が忙しい」ということを言い訳にそれらを覆い隠してしまったのが良くなかった。
 
後ろめたい状況からは目を背けたくなるが、放置すればするほどさらに後ろめたくなるので、そうなる前に「自分が悪いのではなく、こうなってしまうメカニズムがあるはず」と考えて向き合うべきだった。
（こういったアプローチを、心理療法分野の言葉では「問題の外在化」という）
 
自分がどんな時に、なぜ後回しにしてしまうのかもう少し早く深掘っていれば、今年の結果はもう少し違っていたのかもしれない。

②「わからなくて怖い」ものを、「わかる」形に変える技術

もう一つ気づいたのは、私の場合、ソースコードを見た瞬間の「わからなさ」が恐怖心を呼び、無意識のうちに遠ざける→後回し、のループになってしまっていたということだ。

 

でも、タスクをこなすにはソースコードを開かなければ何も始まらない。

ヒントが見えたのは、もはやヤケクソでAIに「ソースコードから仕様書を作って」と丸投げした時だった。


AIすごい。

私の代わりに難解なソースコードを読み、構造を整理し、日本語でまとめてくれた。
圧倒的に手をつけやすくなったと感じた。

 

この体験から私は、「わからなくて怖い」ものに取りかかるには、一刻も早く「わかる状態」に変換してしまうことが大事なのだと学んだ。

コツは、自分の慣れ親しんだ言語に翻訳し、全体像がわかるように構造化すること、

そしてそれをなるべく自分の手を煩わせずにやること。（原本が目に触れた時点で発生する拒否感こそが一番厄介だから）

 

実践として効果を感じた方法には次のようなものがある。すべて、可能な限り自分自身でガチンコでコードを読むのではなく、AIにやらせることを前提としている。

 

  1. AIにソースコードを読ませ、仕様書や設計書、インフラ構成図などのドキュメントを起こしてもらう
    とにかくまずは、自然言語で全体の構造が把握できるようにする。
    まずはAIに作らせた仕様書を読んで当たりをつけてから、仕様書の各内容がそれぞれソースコード上のどこにあたるのかを探す（照らし合わせながら読む）。読むべき部分と読まなくていい部分の取捨選択もここでする。
    本で言えば目次のようなもの。私はこの方法で、抵抗感少なくソースコードと向き合えるようになった。
    ただし、AIの作ったドキュメントの内容が正しいとは限らないので、内容の正確性は必ず自分自身で読みながら補完する。
     
  2. 分岐が複雑、ネストが深いなどそもそもソースコードが読みにくい場合は、思い切ってAIにリファクタリングさせる
    初心者はコードが読めない自分自身を責めがちだが、意外と「コード側にも落ち度がある」ケースがあるのだと知った。
    AIにただ「リファクタリングして」とだけ投げると時間がかかる場合があるので、たとえば「処理の分岐と順番がわかりにくいので、処理の中身は変えずにリファクタリングして」など、少し具体的に指示を出すと良い。これによってコードの構造が整理され、劇的に読みやすくなることがある。
     
  3. コメントアウトを活用する
    ソースコードにコメントアウト部分がない、または読んでもあまり意味のないコメントしか残っていない場合は、自分で補完していくのも手だと思う。
    設計・実装の意図や、どこからどこまでが何の処理なのか、これもやはりコード全体の構造をわかりやすくするようなコメントを残すと読みやすくなる。AIに「コメントアウトを追記して」と投げるのも手。
     
  4. ソースコードが書かれているプログラミング言語の基本概念、基本文法だけ把握する
    直感的な「読めなさ」を解消することだけが目的なので、本などで一から勉強する必要はない。
    AIに「この言語の基本文法を簡単にまとめて」と指示して軽く目を通す。ソースコードを見たときに「ここでは何かしらの関数を定義しているんだな」「ここで何かしらの変数に値を代入しているんだな」等の展開がなんとなく見えるようになれば十分。細かい部分はAIに解説してもらえばよいので。

 

もちろん、日々のタスクをこなすにはまた別の技術が必要なこともある。

しかし、これらを実践したことでまずコーディングへの苦手意識が克服でき、楽しみさえ感じられるようになったのは大きな一歩だった。
 
行き詰まった場合は問題を外在化し、原因を取り除くことの大事さを感じた一年間だった。
 
※ちなみに、この「翻訳と構造化」はソースコードに限らずボリュームの大きいタスクやドキュメントの整理をする時にも活用できる。
AIに読ませづらい形式のドキュメントであれば、その作成者に全体像を直接喋ってもらい、録音をAIに文字起こし・サマライズしてもらう、などいくらでもやりようはある。というか私たちはその方法を考えるべきなのだ。私も引き続き模索中…
 

  最後に

 

振り返ってみれば、この一年間で大切な学びを得られたようにも思うが、やはりもう少し早く気付けていれば…という後悔も否めない。

 

今年度は既に始まっている。

今年こそは悔いが残らないよう、楽しみつつ引き続き頑張って社内SEを目指していこうと思います。