私は前職(飲食、製造、専門職など)から個人事業を経て現在の仕事を経営するに至りました。

当たり前ではありますがたくさんの失敗をしながら覚えて、いろいろ教わって今もその成長過程の真っ只中にいるわけです。

偏りがありますが趣味が多く、1つ1つにのめり込みます。いろんな仕事に携わって将来自分の役に立つと信じて必死になって仕事を覚えて自分のものにしようと勉強もしてきました。

そんな経験からおそらく今一番役に立っている職種が「プログラマー」です。

もちろん他の経験も合わせて相乗効果(ドラクエで言う上級職的なもの)があっての話ですが本日は「プログラマー」がなぜ役に立つのか記事にしたいと思います。
あくまで私の主観が入っていますので参考までに。

プログラマーと言ったら皆様はどの様なイメージでしょう

最近のアニメではプログラマーの社畜が過労なんかで死んで異世界転生する様なストーリーもちょくちょく見かけます。

よくわかんないけど難しそう辛そうとか、徹夜続きの大変な仕事、と言うのが一般的なのかなーって思います。

私はもう客観的に見れないのでわかりませんが。

でもそれって半分正解で半分不正解です。

そもそもプログラマーって何する仕事なの?

プログラマーはシステムエンジニア(以降SE)が設計したシステムを形にするのがお仕事です。

プログラマー自体、実は意外と簡単な仕事なんです。

職場環境がしっかりしてて納期がまともならと言う条件付きですが。
後の説明で分かると思いますがダメなSEや管理者の下に着いたプログラマーとクライアントのパワーバランスが強過ぎる場合には悲惨な末路が待っています。つまり組織としての個の歯車が重要で噛み合わない場合にはもれなく、社畜のようなものになってしまいます。

建築士が設計した家を大工さんが建てる。

みたいなものですが、大工さんみたいな職人さんの技を身につけるのは数年では無理だと思いますがプログラマーは数ヶ月から数年で可能だと思います。

その弊害みたいなものですが、プログラマーは入れ替わりが激しく、設計者に提案、または文句つけれるプログラマーがいない場合があり、その場合に欠陥の多いシステムになりがちです。

プログラマーの何がのちのち役に立つのでしょう

簡潔にまとめると思考そのものが役に立ちます。

プログラマー的思考や概念と言うのは職業病みたいなもので体に染み込みます。

主にフローチャートやプログラミングや設計です。

プログラミングは最近子供のプログラミング教室なんかも流行ってるみたいで聞きた慣れた単語ですがフローチャートとは聞いた事あるようで具体的にはわからない方も多いかと思います。

フローチャートとはプログラミングで言うとアルゴリズムを視覚的にしたものです。

分かりにくいですよね。
説明しづらいんです。
イエスノーの分岐表みたいなものです。

1日の行動サイクルをフローチャートにする事も可能です。
長いので今回は簡単な電話対応のフローチャートを作ってみます。

                          スタート
                              
                          着信有り
               番号通知  or  非通知
                                      
                   出る            出ない
                                      
                   話す               
                                      
                              切る
                               
                            エンド

すごーくシンプルですがフローチャートはこんなものです。

正確には図形や線を使うルールがあるのですがこんな感じの行動の過程を分かるように表にしたのがフローチャートです。

プログラミングはフローチャートをコンピュータが分かるように文章にして命令してあげる事です。大雑把な説明書でプラモデルを組み立てる様なものです。

プログラミングとフローチャートは切っても切れない関係です。

そして設計です。
先程、「SEが設計したシステムを形にするのがプログラマーの仕事」と言いましたがプログラマーも設計します。
会社によってまちまちでしょうが、SEが全体的な設計を、プログラマーが細かいところを(私が勤めていたところではそんな感じ)作るものなんだと思います。
プログラムを作れないSEもいるくらいですからおそらくこんなところが大半ではないかと思います。

システムを作る上で設計は一番大事です。
実際、プログラムを作る時間よりも設計の方が長かったりします。
基礎設計がしっかりしていなければ、全ての工程にロスが発生します。
難しいものほどシンプルな設計を目指します。
そして、クライアント、ユーザー、開発者の3方向から見る事、見れないけれど見れるように努力する事が大事です。

これらが何の役に立つのでしょう

あらかじめ予定を立てる癖がつくため、未来予想からリスクを排除する癖がつきます。

そして、問題が発生したとしても原因と対策を考えて、一時的な応急措置(暫定措置)と根本的な改善措置(恒久措置)を考えるようになります。
少し分かりにくいかと思うので具体例を。

◆問題
車が走らなくなった。

◆原因
部品の劣化により故障した。

◆対策
・暫定措置
劣化部品の交換する。
交換した部品の関係する部品の全ての動作を確認する。

・恒久措置
定期的に点検をする。

答えを見れば当たり前のようですが、なかなかこう言った思考には至らない、もしくは至ったとしても行動に移せない人が多いんではないでしょうか。

行動を起こす前に一度立ち止まって後ろを振り返り全体を見直すくらいでいいんじゃないかと思います。
多分ここが今回の記事で一番大事なとこかもしれません。

まとめ

どんな仕事をしたいかわからない方は「プログラマー」を数年だけ経験してみると今後の生き方や考え方が変わるんじゃないかと思います。手に職、と言う実感も湧き自信が持てるようにもなれます。

どんな仕事も本質を押さえた上で目的を明確にし、達成するために今何をすべきかを順序立てる事が大事ですが物を作る仕事は、それらの基礎を学べる機会になります。

興味がある方は趣味でプログラムを勉強してみるのもオススメします。

仕事は歳を取ると凝り固まった考えやプライドが邪魔をして成長を妨げます。
物事を教わる時は自分が一番わからないんだ、と言う気持ちで素直に聞くのが大事なんだ、と教えてくれた恩人を思い出します。

英語の方が役に立つかもしれませんが、英語よりお手軽です。