ITをビジネスにしない楽しさ

ソフトウェア開発において
要件定義がうまくいけばほぼ失敗することは無いでしょう。
受益者が考えるベストプラクティスを聞きだし、
それを機能一覧に落とし込めれば終わりです。

後は想定した機能一覧をどれだけ精度よく具現化するかだけのお話です。
そこには技術の差があり腕の見せどころです。
しかし、それはどれだけこだわるかだけの話です。

請負業務が中心のプログラマーは
「誰かのベストプラクティス」を「誰かが確立した技術の再利用」
で実現します。

以下のケースは稀です。

少しそのあたりについてお話したいと思います。

以前ITベンダーに勤めていたころ、
当時の社長に「社員に求めるものは何か？」ということを聞きました。
答えはシンプルで「問題解決能力」でした。

問題とは何か？
簡単に言えば現状とあるべき姿のギャップです。
あるべき姿が明確でなければ問題を認識することすらできません。

次に行動に移すためには具体的な課題抽出が必要になります。
あるべき姿に近づける行動全てが課題でありその課題を順に潰していきます。
それが請負プログラマーの役割です。

実は請負プログラマーに話が行く頃には
問題提議も課題抽出も何なら解決手段の確立も終わっています。
つまり解かれた課題を実装しているだけです。

プログラマーには作る楽しさがあります。
お客さんの困りごとを聞きそれを自分の技術力で解消。
「役に立った」「儲かった」と言ってもらえればそれはそれは嬉しいでしょう。

僕の顧客であったとある社長さんがおっしゃっていました。
僕とそう歳が変わらない人でしたがやはり二代目社長です。
生まれながらにしてトップを約束された人は言う事が違います。

リスクを取らない仕事の何が面白いの？

ぶっちゃけついていけません。
当時の僕にはどういう意味かはわかりませんでしたし、
そもそも納期というリスクを背負っていると考えていました。

しかし最近はそれに共感できるようになってきました。
僕は恵まれているのでしょうね。

今思えば納期を背負うだけの仕事の何が面白いんでしょうか。

本題です。

この二つはゴール設定はできますが要件（つまり機能一覧）が決められません。

もちろん一発でうまくいくならみんながやっています。
通常はトライアンドエラーの繰り返し。
一回の失敗に評論家が集まり寄ってたかって叩くような環境では難しいでしょう。

ですが、コロナの世の中少し余裕がある方も多いかと思います。
ちょっとだけ自分の好きなものを自由に作ってみてはいかがでしょう。
自分の時間とお金を使って自分だけのために全力で。

ひょっとしたら世界中の誰も知らない事実に出会えるかもしれません。
最近それを探すのが楽しいと感じます。
ITをビジネスにしない楽しさです。
ほとんどハズレですけどね。

ITをビジネスにしない楽しさ

おわり

コメント