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

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

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

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

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

プログラマーの秘密アプリ – ローカルアプリケーション

プロとしてお金が発生するプログラミングを続けていると
どうしても自由にアプリがつくりたくなります。

しかし業務と関係ないアプリを作っていると怒られるので一目を気にしながらこっそり作る。
その名も「俺のアプリ」・・・はダメですね。すでに俺の株式会社がやってました。

名付けて・・・虎の子アプリ。
んん~ネーミングがダサい。

まぁ、名前は何でもよいのですが、
平たく言えばこっそりつくったローカルPCにしかないローカルアプリです。
日の目を見る事がないひっそりと楽しむツール。

今日はそんなローカルアプリの話でもしようかと思います。
隣の大先輩も密かに愛用している名作があると思います。
聞いてみたら自慢してくるかもしれません。

役に立ちたい気持ちと役に立ちたくない気持ちと

勢いで行先ボードアプリを作りました。
僕としてはアプリを作りたい欲求が満たせたので満足です。
しかし、社内に展開してちょこちょこ要望が増えてきました。
後悔しています。なぜ僕が対応しなければならない?

自分で言ってて何を言ってるかわかりません。
勝手につくって、勝手に現場に投入して、活用されたら文句を言う。
僕は何様なのでしょうか。

まぁ、そこは置いておきましょう。
もう少し使われないままで作り続けたかったのですが使われると責任が発生します。
どうしよう・・・。面倒くさい。

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

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

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

DXの設計書⑪ – タスクを洗い出し覚悟を決めて見積るべし

必要だけどやりたくない作業の一つ見積。
まず、ハズレます。
見積もれるわけねー。というのが本音です。
でも、やらないといけないのですよ。

今回は作業量の見積もりについてです。

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

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

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

DXの設計書⑧ – 業務フローのビフォーDX、アフターDX

業務フローの話です。
僕は現状のBPMNのみを書くことが多いです。
システム導入後のBPMNは必要に応じてですね。

設計書や資料の価値は、どれだけ見返されるかで測定できると思います。

問題や課題に関するビフォー・アフター(現状とあるべき姿)の洗い出しは困難を極めますが、
業務フローのビフォー・アフターは簡単です。

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

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

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

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

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

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

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

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

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

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

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

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

DXの設計書② – DXを定義せよ

肚落ちしていないDXの理解に対し、周囲は容赦なく心を折ってきます。

「厳密には違う」と。

定義がふわっとしているDXの名の下、多くのお金が失われようとしています。
国内で回ってくれる分には良いんですけどね。

COVID-19の折、日本は大きく出遅れました。
ITの巨人、マイクロソフト様がDXで本気出すと言ってます。
国内企業はたくさん飛びつくでしょうね。

「DXはマイクロソフトの戦略そのもの」、日本MSが経営方針を説明

さて、デジタルトランスフォーメーション。
何気にネーミングセンスが良いんですよ。DXの"X"もカッコ良い。
ちょっと古い感じも良い。タカラトミーのメカのせいですね。
昭和おじさん達のDXに群がる様子が目に浮かびます。