動かす前の準備が8割だった話”プログラミング初心者の気づき”

実践と気づきの記録

私は思いつきで行動することが多く、それはプログラミングの勉強へも影響しているのですが、こうしたい!こう動かしたい!と思ったらいつもすぐにコードを書き始めてしまいます。

ですが直近で少し複雑なExcelVBAのコードを組んだことで下準備の大切さを改めて学んだので、今回はその気持ちを忘れないためにも、学んだ内容ときっかけを記録しておこうと思います。

 

下準備がすごく大切だと気づいた

プログラミングを始めたつい最近までの自分

私のプログラミングは基礎の基礎を以前の職場の先輩に教えてもらったきり完全独学なことと、今は周り私以上に詳しい人がいないこと、結果的にそこまで複雑なマクロ組むことはないため、特に仕様とかを考えずにコードを書き出してしまっていました。

そして出来上がってからそれに合わせて簡単な操作マニュアルを作成するという流れだったのですが…、直近で初めて少し複雑なマクロを組んだことでこのままではいけないことに気づかされました。

  

“うまくいかない理由”に気づいたきっかけ

このままではいけないと気づいたきっかけですが、完成したマクロを使用した際に実は目に見えている条件よりももっと結果が分岐する条件が判明したことで後から大き目な仕様変更を行わなくてはいけない目にあったことです。

後から仕様変更を行おうと思っても、仕様書も何もなくただ完成されたコードが目の前にあるだけなので、コードをパッと見ただけではどこに追加の条件を差し込めばいいのか全く分からなくとても頭を抱えました。。。

仕様書があればコードを視覚的に捉えることが出来るためここまで悩む必要なかったのにと後悔したのと同時に学ぶことができました。

 

仕様書ほどはいかなくともフローチャートを作成すること実行

とはいえ、ちょっとした業務効率化のために毎回仕様書を作りこむのはむしろ時間がもったいないので、仕様書替わりにフローチャートを作成することを心がけるようにしました。

フローチャートとはこういう図のことですね。

これを作成することでどのタイミングで分岐を入れるのが適切なのかが分かりやすく、またもし後から条件を追加するにしても、その処理をどのタイミングに入れるべきなのかが一目で分かります。

それにフローチャートがあればその処理タイミングごとにコードを当てはめてそれを組み立てていけばいいだけなのです。

いきなりコードを書き始めていた少し前のころよりも悩む時間が短くなり、視覚化することって大切なんだと気づきました。

 

下準備を意識し始めてからの変化

仕様書やフローチャートはいわばプログラミングをし始める下準備にあたる作業かと思いますが、今回のことで「段取り八分に仕事二分」とはこういったことを指すんだなと自分の経験として理解することができました。

そこからは業務を一気に済ませようとするのは止めました。

 

この経験は他の業務にも活かすことが出来ました

プログラミングを通して下準備が大事と気づいてからは、振られた仕事に対して急に取り掛かり始めるのはやめて、下準備含め業務を整頓してから実際に手を付けるようになりました。

するとます、全体像が見えるようになったことでタスクが積みあがっても前より混乱しなくなりました。

それから自分が手一杯でも他の人にお願いしやすくなりました。

こういったことを考慮すると全体的に効率的に業務内容を把握できるようになったかなと思います。

 

プログラミングは“技術”以上に“考え方”が重要

またプログラミングの話に戻ってしまいますが、プログラミングの技術面(実際のコード等)は調べれば何かしらヒットします。

ただ、それを調べる方法や調べた情報を自分の業務にどう反映するかは自分で考えなくてはいけません。

そのどう反映するかを考えやすくするために仕様書や視覚化しやすいフローチャート作成が大切だなと今更学んだ今日この頃でした。

今頭抱えているマクロ、早く解決するといいな…。

コメント

タイトルとURLをコピーしました