はじめに
こんにちは。
システムチームのTです。
自分は12月と1月の間、社内で使っているブレインマップというツールに大事なことをメモしていました。
今回はそれを振り返って、ただのメモ書きではなく、
自分の身になるようにまとめたいと思います。
ここでは、２つのことについてまとめます。
処理を変えない、足す
ひとつめの内容としては、処理を変えず、足していってコードを書くということです。
自分は、既存の処理を変えてプログラムを書く傾向がありました。
「○○というファイルのプログラムでは、××となっているから、それに合わせて、△△という処理にしないといけないな、ここに関係ある部分も変えないとな」と考えてプログラムを書いていました。
そのため、書いたプログラムが特定の状況で成立しないということが何度もありました。
すでにあるプログラムに合わせてプログラムを修正したことで、
○○というファイルのプログラムでは成立するけど、
他のファイルのプログラムでは成立しないということが発生するようになったのです。
従って、成立しないことがわかるたびに自分で書いた処理を修正して、テストをして、また修正して
と悪いループに陥ることも増えていきました。
また、このやり方だと、修正の度に既存のコードの内容を把握する時間が発生し、大きなタイムロスを生んでいました。
これはもともとある処理を修正するという意識が強いため起きてたことです。
ところで、先月、上司がプログラムを書くところを見せていただきました。
上司は自分とは逆のプログラムの書き方をしていました。
既存の処理を変えずに、処理を足して、自分が新しく作った処理に合わせるというアプローチをしていたのです。
ですので、修正の回数が少なく、道理の通ったコードになっていました。
また、既存の処理への影響も、処理を変えずに足したことで少なくなっています。
注意深く見るのは、自分が付け足した処理と、それにかかわる箇所で良くなっています。
このことに気づかせていただいたことで、自分の中で普通になっていたプログラムの書き方が変わっていきました。
変えれば不具合の元になるので、つけ足す。
どう付け足せばよいかを考えて、コードを読む。
この2点を考慮して、プログラムを書くようにしています。
これによって、特定のパターンで成立しないから処理を修正する、というアクションをする機会がかなり減ったと実感しています。
列挙して整理する思考法
ふたつめの内容は、思考法についてです。
以前ランチMTGで代表よりご教示いただいた方法で、
実装の時に考えをまとめるなかで自分が使っている（まだまだうまく実践できていないのですが）やり方です。
考えるのは以下の手順で行います。
① 思ったことをばっと書き出す
② 書き出した内容を比較・整理する。
③ 直感的にこれだと思ったものを掘り下げる。
④ 掘り下げて違うとわかったら、別のものを掘り下げる。
⑤ ③と④を繰り返して結論を出す。
自分は業務中の考えはなるべくこの手順を踏んで考えるようにしています。
例えばわからないところがあれば、
「わからない」と初めに書いて、そこから「なぜ？」と理由を複数書き出して、処理しています。
もやっとしているものを言語化しているので、ある程度書き出したら、考えが客観視できるので、
そこからさらに考えを深めることができます。
問題はたいてい、複数の事象が絡み合って構成されているので、それを解きほぐすためにも、
このように書き出して、整理することが大事だと、このやり方で考えることを始めてから、
かなり実感しています。
おわりに
なんか最近、調子が悪いなと思っているのでしたら、
自分のそれまでのやり方が通用しなくなってきているタイミングですので、
自分よりもできる人のやり方を真似することがいいのではないかと思います。
マインドやノウハウなどの、抽象的な部分を真似して、
それを仕事の中でどう実践するかは自分で考えていけば、突破口が開けるはずです。
