ワイの働き方

最近形ができてきたからメモるわ。

この内容は、大学の学習でも、バイトでも、研究でも全てに当てはまって、活用しておる。

基本的に、課題にしろバイトにしろ研究にしろ、何か解きたい・書きたい・作りたい・取り組みたいものがあるんだが、いきなりそこで解きはじめるとか、書きはじめるとか、作りはじめるとかするのは経験的に筋が良くなかった。

ので、一旦、その手前で全体像を細かく切り分けてイメージを作っておくっていう作業をしてる。

具体的には、A4の紙を何枚も用意して、そこにこれからやることの言語化とイラスト化を目一杯しとる。例えばバイトで、追加機能を実装したい、こういう機能を実装したいていうのがわかっているときに、いきなりパソコン開いてキーボード叩き始めるんじゃなくて、A4の紙の上でほとんど言語的に明確に書けるところは書いておいてしまう。エディタ開きながらウンウン唸るっていうのをやめて、基本思考は紙の上であらかたやってしまう。

これは、別に全部をあらかじめ紙の上で考慮しておくというわけではなくて、交互に挟む感じ。紙であらかたやることを明確に言語化しておいて、ある程度先のことが決まったら実際に作っていく。またやることがボヤけてきたり、新たに課題が見つかったら紙に戻って抽象的な課題を具体化していく。

メタ認知的なスケジューリングみたいな感じかもしれない。自分の中にマネージャーをもう一人置く感じ。

今はコード書くのを例に取ったけど、例えばパワポスライド作るのでも、論文書くのでも、計算回すのでも、課題終わらせるのでも全部同じ。ある程度概要をあらかじめ作っておいて、いざ取り組む段になったらその取組むときの詳細に集中できるようにする。あらかじめ、Big Pictureみたいなのは紙の上で押さえておいて、実際に作るときは細かいところに意識をさく。

こういうことやり始めてから、バグがクソ減ったし、より綺麗なコード描けるようになったし、より綺麗なスライド作れるようになったし、より綺麗な文章書けるようになった気がする。文章に関しては、そこまでのことするのは論文だけだけど。

ポイントはやっぱり、集中する場所の切り分けという感じ。作りながら大局的なものの見方をするっていうのはやっぱり難しいんだけど、でも大局的な見方ができてないばっかりに、悪戯に時間を消費した挙句細部に拘ってゴミみたいな作業している時が割と多くある。コレが無駄だなと思ったのと、ずっとディスプレイ見てると目が痛いなと思ったのが行動を変えたキッカケ。

イメージとしては、全体の概要を捉えにいくミーティングを紙の上で一人で開催してる感じ。その後に、細かい仕様書を作って自分に渡して作業してもらう。またそれがある程度できたら、全体を見るミーティングに戻って軌道を修正する、みたいな。

やっぱりコードを書く例が説明しやすいんだけど、これはもう紙の上で関数名とか処理の流れを決めちゃうぐらい具体的にやってる。関数名はまじで紙の上でもう書いてる。そこまで具体的に行うことをイメージすることで、めちゃめちゃ実装にかかる時間が短縮されて、社員にも驚かれる速度で実装しとる。

パワポの例で言うと、各スライドに書く内容とか全部具体的にあらかじめ紙の上で作っとる。論文で言うと、ほぼ各節の内容を紙の上で構成しとる。そしてそれを書いた紙の上で何度もそのレイヤーで議論を戦わせて、その時点でかなりマシなものを紙の上に構成しとる。パワポにしろ論文にしろ、先生から早いね（意訳）のようなこと言ってもらえたし、有効な技だと思う。

紙の上で前もって時間を投資することで、実際に作業する段階でゴミを生み出す時間と、それがゴミだと気づく時間、ゴミの前で悩む時間、ゴミを消して再度修正する時間っていうのが一気になくなる or 短縮されて、かなり時間的に猶予ができ始めた。最初はこの上の悪いサイクルをまさにやってて、土日全部クソコードのために費やすとかやっちゃってたけどね。そこから学びました。

多分、こういう似たようなことをやってる人は少なからずいると思うが、普遍的に役立つ技だなとか思ったのでメモっとく。