プログラマー 9割のキツい仕事と1割の楽な仕事

プログラマーはキツイか?
という質問に対して僕が答えるとすれば

9割はキツイと答えます。

根拠ですが、僕は中小のITベンダーで約12年ソフトウェア開発の仕事に従事しました。
これは楽だったなぁと思える開発期間を累計すると1年とちょっとです。
きっと楽な仕事を効率よく奪ってる企業はありますね。

今回は9割のキツさと1割の楽さについてご説明します。

DXの設計書㉔ – パッケージという選択肢

世の中に数多存在するパッケージソフトウェア(以下パッケージ)。
業務を包括するパッケージも存在します。
ERP(Enterprise Resources Planning)などはその最たるもので、数も多いし歴史も長い。

それなりのお値段もしますが、
スクラッチでつくるより値段も労力も抑えられるようになってきました。

DXの設計書⑩ – 機能一覧を作成せよ

機能一覧が出来上がると途端にプロジェクトの見通しがよくなります。

これまでに集めた情報を機能一覧に凝縮させましょう。
カッコいい漢字が並んだXXX機能とかいう漢字だらけの曖昧なものではなく、
「~をする機能」ときちんと動作がイメージできる内容を記載して一覧をつくります。

DXの設計書⑦ – 無秩序な業務フローダイアグラム

システム開発で設計書を書く際、UMLやSysMLを使用します。
モデリング言語というやつですね。

業務フローをかけと言われた時にあなたは何を使いますか?
多くの人が独自モデルを使用します。
エクセルやパワーポイントを使用し、ルール無用の矩形や〇の組み合わせで記述します。
一回使用しただけで全く見返されないものや、別の人が何度も同じ内容で作り直すケースがしばしば発生します。
折角時間をかけて書いたものなのにもったいない限りです。

ところで、業務フローかけますか?

DXの設計書⑤ – 自分のゴールをイメージせよ

何を変えるのか、何に変えるのか、どのように変えるのか
The Goal の一文です。

前回の記事では個別の作業単位に分割することについて説明しました。

言うは易し、行うは難しです。
迷いが生じる2つの要素があります。

  • どこまで耕やせばよいのか自信がない
  • 作業の数が多すぎて正しく洗い出せる自信がない

残念ながらプロジェクトを完成させるには、ゴールの設定とすべての手順の踏破が必要です。
明文化するかしないかの違いだけで必ず実施することになります。
ゴールがふわふわしていると自分を見失います。

心を病む前に、自分の中のDXのゴールを決めましょう。
耕す畑のサイズを決めるのです。

「何を変えるのか、何に変えるのか、どのように変えるのか」を明確にし、
そこから逸脱するあるべき論やそもそも論はバッサリ切る覚悟をします。