プログラミングスキルはコーディングスキルだけではない

プログラムには何が書いてあるのかを改めて俯瞰してみると、シンプルさと難しさを併せ持っていることに気づく。

業務アプリケーションの中身

シンプルさ

理論的には中学校の教育レベルで理解できることばかり

難しさ

業務を客観的かつ大局的に捉えないと、ロジックの手順化ができない

例えば、Excelで開発された業務アプリケーションの中身は下記のような「演算」と「操作」が記述されている。

• 四則演算
• 論理演算
• フォルダ操作
• ファイル操作
• エクセル操作

システム化されていないExcelで仕事をしているビジネスパーソンは上記の「演算」と「操作」を手作業で行ってる。手作業で行っているこれらを手順化したものが設計書となるが、プログラミング初級者には一番の難所となる。難しい理由は、ケースバイケースで違うのだが、一例を挙げる。

２種類の集計手順がある集計業務

ほとんどのケースでは売上×掛率で粗利額を算出できるが、一部の商品についてはその月の売上数量100点までの掛率と101点以上の掛率が異なる。

このような方法Aと方法Bの２つの集計手順を、１つのフロー図(設計書の一部)でまとめるというのもプログラミングスキルの大事な部分なのだが、こういった設計書作成スキルについては、技術書には載っていない。プログラミングスキルはコードを書く以外にも、身につけないといけないスキルが複数ある。設計書作成スキルの他にも、システムテストスキル、インフラ構築スキルなどだ。
技術書では身につけられないこのようなスキルを身につけるには、最適な教材がないので、実践で場数を踏むしかないのが現状だ。