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

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

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

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

以下のことをやるケースは稀です。

  • ベストプラクティスをつくる
  • 誰もやったことが無い新技術を確立する

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


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

問題とは何か?現状とあるべき姿のギャップです。

あるべき姿が明確でなければ問題を認識することすらできません。
また、具体性に欠けるあるべき姿はいくらでも描けます。
「現状の100倍儲っている状態があるべき姿だ!!」

ま、問題はそれでも良いでしょう。

しかし行動に移すためには具体的な課題抽出が必要になります。
理想に近づけるための行動内容全てがいわゆる課題になり
その優先順位から一つないしは複数の課題を潰していきます。
それが請負プログラマーの役割です。

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


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

僕がITベンダー時代にとある工場の社長さんがおっしゃっていました。
僕とそう歳が変わらない人でしたがやはり二代目社長で
生まれながらにして儲かってる工場のトップを約束された人は言う事が違います。

そんなリスクを取らない仕事の何が面白いの?

言う事が違いますね。
この人の環境が恵まれすぎててついていけない。

当時の僕にはそれがどういう意味かはわかりませんでしたし、
僕自身、納期というリスクを背負っていると考えていました。

今思えばそれの何が面白いんでしょうかね。


全然本題にたどり着きませんが本題です。

  • ベストプラクティスをつくる
  • 誰もやったことが新技術を確立する

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

もちろん一発でうまくいくならみんながやってるわけで
通常トライアンドエラーの繰り返しが必要になります。

一回の失敗に評論家が集まり
寄ってたかって叩くような環境では難しいでしょう。

話は変わりますが、新しい星を発見すると発見した人が名前をつけるというのは有名です。
企業に勤めてる人より一般人が発見するケースが多いと聞きました。
ホントかどうか知りませんけれども。

請負プログラマーは要件定義にかこつけて
何か賢そうなことを言ってきますが
そのほとんどが
答えを教えてくれないと動けません
と言ってます。
正直、退屈です。

もう少し自分の好きなものを自由に作ってみてはいかがでしょう。
自分の責任で自分のリスクで。
ひょっとしたら世界中の誰も知らない事実に出会えるかもしれません。
最近それを探すのが楽しいと感じます。

ITをビジネスにしない楽しさですね。

1割以下の打率ですけどね。
笑える。

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

おわり

コメントする

メールアドレスが公開されることはありません。