プログラマーについて私が思ったこと。そしてプログラマーにおけるモダン開発について

タイトルは以下リンクの記事より拝借しました。
SIについて私が思ったこと。そしてSIerにおけるモダン開発について

春なので新人応援記事を書きます。

プログラミングとは

プログラムを書くことです。
昔はプログラマーの職業はプログラマーとキーパンチャーに分かれていました。
プログラマーはコードを設計してどうプログラムを書くか、設計書を紙に書く職業でした。その設計書をキーパンチャーに渡してホストコンピューターに打ち込んでもらうことでプログラムを動作させる準備をしていました。

Windowsが生まれてからはパソコン上で設計しながらプログラムを書くことができるようになったようです。

コンピューターだけじゃないプログラミングできる場所

最近では子供向けプログラミング言語「スクラッチ」や、プログラミングトイなどのアプローチや、マインクラフトなどのゲーム上でのプログラミングも生まれ、かならずしもコンピューター上じゃなくてもプログラミングができる時代になってきました。

あえて、職業用プログラマーというほどでもありませんが、ここではプログラマーについて書きたいと思います。

プログラミングスキル

人気のプログラミング言語トップ10

※2016年調べ

1. Ruby
2. JavaScript
3. Python
4. PHP
5. Java
6. Swift
7. C#
8. C言語/C++
9. Excel VBA
10. Visual Basic .NET

他にも、Golang、Perl、PASCAL、アセンブラ、COBOL、FORTLANなど、その種類は300種（Wikipediaによる）。派生言語を入れると2000種ほどあるという。それに加えてライブラリやパッケージ、IDE（統合開発環境）など合わせると膨大な数の知識が必要となります。ハードウェアに近いほど低級プログラムと呼ぶ、対して自然言語に近いものほど高級プログラムと呼ぶ。コンパイルを必要とする/しない、型宣言を必要とする/しないで区別されることも多い。
昔は一つの言語を用意するのに環境依存したため、プログラミング言語はひとつに統一する風潮だったが、近頃はマイクロサービス化、環境のクラウド化がすすみ、多言語でシステム化することの方が多くなっている。そのため、一人のプログラマが複数の言語を扱う文化も普及してきている。

プログラミングを学習する上ではプログラミング言語以外の知識も必要

下記の言葉はプログラミング言語以外のほんの一例である。プログラミング言語だけの知識でプログラムを組めるわけでは無いので必要な知識は書籍やコミュニティから学ぶ必要があります。

• SQL
• プロトコル
• OSI参照モデル
• UUID
• MACアドレス

SQL

SQLはプログラミング言語だが、データベースのデータを取り出したり、書き換えたりするための言語であり、データベース言語と呼ばれる。データベースの外のコンピューター言語とは区別される。Structured English Query Languageの略（諸説あり）。

プロトコル

プログラムという言葉に似たプロトコルというのがあるが、これは規格であり、通信プロトコルとしてRFCで定義されているものを指す。

OSI参照モデル

インターネットやネットワークを階層構造で理解するためのOSI参照モデルなどがある。

レイヤー	内容
アプリケーション層	サーバプログラムとクライアントアプリケーションの層です。HTTPはこの層からセッション層までの3層にまたがったプロトコルになります。
プレゼンテーション層	データの表示形式を区別し、暗号化や圧縮方式、表示方式を制御します。文字コードや画像、動画などを区別して処理する層です。
セッション層	セッションとは通信の開始から終了までを指し、一連のセッションを維持するのがこの層です。HTTPやFTP、SMTPなどの多くのプロトコルが存在します。
トランスポート層	エラー制御やフロー制御により通信品質を高める層です。TCPやUDPなどのプロトコルが存在します。
ネットワーク層	隣接したネットワーク装置の通信を可能とします。（ARP通信によりMACアドレスなどが取扱されます）L3スイッチなど高度なネットワーク装置が存在します。
データリンク層	フレーム単位のデータの正当性や電気信号などを制御します。スイッチングハブやブリッジなどの装置がこの層です。
物理層	ハードウェア、ケーブルなどの物理領域を指します。コネクタの形状やケーブル内を流れる電流・電圧を制御する層です。

UUID

Universally Unique IDの略。
ソフトウェア上でオブジェクトを一意に識別するための識別子のこと。
超要約すると世界中で勝手に生成しても衝突しないユニークなIDということ。

参考：UUID がぶつかる可能性を考えなくていい理由

UbuntuやFedoraといった最近のLinuxディストリビューションの場合，このUUIDを，例えばハード・ディスクの個々のパーティションを識別するための情報として利用している。

MACアドレス

Media Access Control addressの略。
ネットワーク上で、各ノードを識別するために設定されているLANカードなどのネットワーク機器のハードウェアに（原則として）一意に割り当てられる物理アドレス。
一般的ではないが、MACアドレスがわかると端末・個人が特定できるため、むやみに公開しないことが暗黙の理解となっている。

Wi-FiのMACアドレスはもはや住所と考えるしかない
無線LANのMACアドレス制限の無意味さがあまり理解されていない

一人ですべてできるわけではない

上述のように多種多様な知識が必要なプログラミングの世界では、ひとりですべてをやりきるのは特定の場合（個人開発、趣味など）をのぞき困難である。自然とその分野のコミュニティにたどり着き、他者との協業、場合によっては競業することを必要とされてくる。そのため、プログラマー、エンジニアの人にはオンオフとわずコミュニティが身についていると思って良い。
また、プログラマーとして活動するためには企業に所属するケースが考えられるが、採用する経営者が必ずしもプログラミングの知識を有しているとは限らない。企業が会社を存続させるためには、営業や販売、広報や総務など、必要なポストを維持して、その上でプログラミング環境が成り立つということも頭にいれておきたい。
ここで言いたいことは、協力者を探そうということであり、ひとりですべきではないという意味ではない。ひとりでやりとげる充実感もプログラミングの醍醐味のひとつではある。

プログラマーの特性

プログラマーは日々コードを書き、システムやサービスの問題点を多角的、ときには部分的に悩みながら解決に向かうことを求められる。そのため他の職業に比べて常に問題意識を持っており、その優先順位ごとに手を動かし頭を動かしている。はたから見てその思考の難解なところから、周囲に理解されないケースもあり、自身の評価も自身で行うしかない。与えられた課題を期日までに解決する品質に重点をおいたり、解決に至ったノウハウをアウトプットする量で能力を推し量ったり、はたまたシステムの改善が実際の業務の売上効果にどの程度反響したかで評価する方法がある。最悪なのは成果物の量だけに特化したり、働いた時間にのみ対価を求めるプログラマーである。そういう人物に自分がなっていると感じたらすぐに改善することをおすすめする。

プログラマーの将来性

プログラマーにはさまざまな未来がある。
プログラマー35歳定年説など昔流行ったが、プログラマーを採用している経営者が今後プログラマーの採用動向をどうしたら良いか迷ったときにとびついた悪説である。筆者は42歳であるが、いまだにプログラマーとして成果を上げている。直接的な金額に反映はしていないが、チームがいかに潤滑に運営できるか、システムの効率を正しくあげられているかなどプログラミングをすることで解決している。もともとプログラマーには定年制度が無い。近頃では60歳からプログラミングを始めたという記事がホットになったりしている。

プログラマーのロードマップ

昔使われていたロードマップを見てみよう。
プログラマー、システムエンジニア、システムアナリスト、これは単に一例にすぎないが、所属するコミュニティや企業によって開かれる道も変わってくる。

私の例でいうと、
COBOLプログラマー→VBプログラマー→VBシステムエンジニア→システムエンジニア（ASP開発、IISサーバ構築）→システムエンジニア（CRMパッケージ導入）→SIer（パッケージ導入、サーバ調達、要件定義、運用設計）→インフラエンジニア（Linuxサーバ構築、運用、ミドルウェア導入、運用設計）→プロジェクトマネージャー（要員調達、スケジュール立案、要件定義、設計、開発アウトソース、リリース判定、運用保守）→クラウドインフラエンジニア（システム分析、AWSサーバ提案、AWSサーバ構築、運用保守）→システム部ニアショア（システム予算提案、システム計画、設計、移行、運用、旧システム廃棄予算、廃棄実施、システム資産化計上）→ベンチャー企業システム顧問
というように、後半は未来予測なども盛り込みましたが、稀なケースなのかなと思う。
当初、プログラマーを職業としてやりはじめたころは、COBOLやVBでどんな将来があるのか描けず、自身のスキルプランを考えようとすると途方に暮れていました。そこにASPやIISの方につながりそのままVisualStudio系の道を進むかと思いきや、.NET挫折にあったのを覚えています。ところがIIS構築からWebサーバ系へ展開し、マルチOSを学び始めることで何か手ごたえめいたものを感じたのを覚えています。今ではサーバ構築、運用などのインフラ系勉強会やセミナーなどに参加したりして交流を増やしたり、業務上でも各ベンダーと課題解決や議論のぶつけあいなどができるインフラエンジニアへと成長できました。

どうなりたいか

どうなりたいかを設計するのもプログラマーは考えて行動することが求められる。
そして、とりあえずやってみる。
後から、やってみたことはどういうことかをきちんとチェックする。
最後に良し悪しを区別して、良いところは伸ばし、悪いところはつぶすという自己成長性を維持することがプログラマーを維持することにつながる。

挫折をしたらアウトプットしよう

どんな小さなことでもつまいずたら大きな挫折のきっかけになったりします。
また、設計時にあやふやにした箇所は必ずテスト時に大きなバグとなって降りかかります。
原因がわかるバグというのは時としてプログラマーのエサとなります。問題意識が高いので、解消につながる原因特定が早ければ、すぐさま解決という成功体験となります。
ただどうしても誰も悪くない無慈悲なバグというのも世の中には存在します。落としどころを整理して問題を閉じてもまた無慈悲なケースが起こると思うと手がすくんでしまうのは無理が無いです。そいったときはその事例と理不尽と感じた気持ちをアウトプットしておきましょう。その記事にたどり着いた人が同じ思いをせずに救われるんだとしたら自分も救われる気持ちになりませんか？

勉強と仕事はきっちり分ける

勉強は自分のスキルアップ、仕事は売上アップ
勉強は仕事中にしても良いかについては論争が巻き起こりますが、わたしは上述のように考えています。

プログラミングの勉強には歴史と単体テスト

どうしてそういう規約なのか、過去の歴史を振り返ることで紐解ける問題が多々あります。それに対して、どう実装するとどういう結果が得られるのか、日々単体テストで検証する必要があります。歴史的にこうだからといって、必ず同じ結果が得られるとは限らないケースがあります。

究極の勉強法「写経」

写経でプログラミングが上達するか

気になる言語があったらHelloworldだけでもやってみることです。
じつはHelloworldまでたどり着くためには環境を作らなくてはならないからです。
環境をつくってHelloworldができたら、ひたすらよさそうなコードを探して写経です。
写経したものが動くと「こいつ、動くぞ」と感情が高ぶります。高ぶったらカスタマイズです。何度かカスタマイズしているとおれのかんがえたさいきょうのかすたまいずが見えてきます。みえてきたら全世界のおれと比較してみましょう。おれたちがかんがえたさいきょうのかすたまいずが生まれるはずです。

絶対に読むべき本

体系的に学ぶ 安全なWebアプリケーションの作り方
別名：徳丸本

説明不要のバイブル

今必要な知識

• 環境
  • Cloud9
  • 自サーバ
    • Vagrant
    • Docker
  • クラウド（AWS、GCP、Azure、さくらインターネット、ConoHa、Heteml、Heroku）
• CI（継続的インテグレーション）
  • RubyやJavaScript、PHP
  • GitHubから自動デプロイ
• セキュリティ
  • 最低限
    • SNSと個人情報
    • メールセキュリティ
    • 通信の保護
    • システムから得られる情報と発信してよい情報の区別

今後必要な知識

• AI、人工知能、機械学習、深層学習（ディープラーニング）
• AR、VR、MR

まとめ

プログラマーとしての具体的な勉強法に正解はありません。クールでスマートな勉強法を見つけたら臆せずアウトプットして、プログラマー界隈に貢献をしてください。