2007-07-16

得意なことをやっていきましょ

神様なんて信じない僕らのためにというブログの得意でないことを無理にやらせてもな、とという記事を読んで、一言。
まぁ、こういうのってよくきく話なんですがね。
でも、やっぱり私も一言言っておきたい。

コンテンツ

  1. ソフトウェア開発ビジネスのプロセス最適化
  2. 専門職のゼネラリスト?
  3. ゼネラリストな人
  4. ゼネラリストなチーム


ソフトウェア開発では、常に業務プロセスを適切に分析する能力が要求されています。
業務プロセスを適切に分析できなければ、それをどうやってソフトウェアに実装するというのでしょう?
ソフトウェア開発(とくに業務系アプリケーション分野)とは、ビジネスプロセスを分析して、これの最適化を提案することが第一の仕事です。
次に、最適化したプロセスのうち、コンピュータが肩代わりした方がうまくいくところを、コンピュータにやらせるために、ソフトウェアを開発するわけです。

ソフトウェア開発ビジネスのプロセス最適化

では、ソフトウェア開発という業務自体は、いつ誰が分析するんですか?
これ、まさに医者の不養生というやつですよね。
ソフトウェア開発業務が適切に分析、最適化されていなければ、その全く最適でない業務の仕方で開発されたソフトウェアは、はたして最適なんですか?
効率の悪い業務で開発するということは、不必要に開発費がかさむことも意味しますよね。
不必要に高額な開発費をかけて、最適でないソリューションを提供しているのでは?
もっとはっきり、強い調子で言っちゃいます。
不快感を感じられたら、すいません。
ソフトウェア開発業界は、いつまで詐欺まがいのことを続けるんですか?

もちろん、そうでないところもたくさんありますね。
常に技術力を磨き、その能力で自分自身のプロセスを見つめ、継続的に改善し、その上で顧客の業務プロセスを改善するソリューションを提供しているところも、たくさんあります。
でも、そういう優れた開発組織って、業界全体からみるとどれくらいの割合なんでしょう?
調査したわけじゃありませんのでなんとも言えませんがね。
人間というのはコンピュータと違って、個性をもっています。
得意不得意もありますし、それぞれの目標や価値観を持っています。
業務プロセスというのは、人間が行うものであることを忘れてはなりません。
コンピュータでなく人間が行う以上、最適なプロセスとは、人間の長所を引き出すものでなければなりません。
人材が適切に配置されていないということは、とりもなおさず、その業務は最適化されていないということです。

専門職のゼネラリスト?

時折、「職業人はゼネラリストでなければならない」というような言葉を耳にします。
この言葉がソフトウェア開発者に向かって発せられる場合、私の意見はまったく否定的です。
この言葉の真意は「社会人として最低限必要なことは、ひととおりできるようにならなければならない」というような新社会人に対するメッセージなのかも知れません。
しかし、私の経験から見ると、こういうことを言う人は、往々にして「社会人として最低限」以上のことを求めてしまうように思います。
そして結局のところ、全分野に対してのスペシャリストを求めてしまうのです。
全分野に対するスペシャリストなどという人は存在しません。
存在するとしても、それは天才なのであって、社員全員が天才にはなれるはずもありません。

ゼネラリストな人

同じだけの能力と同じだけのやる気―それも素晴らしいやる気を持った人、AさんとBさんがいたとします。
Aさんは全ての時間をかけて、1つのスキルに打ち込みます。
Bさんは全ての時間をかけて、Aさんが打ち込んでいるものも含めて、5つのスキルに打ち込みます。
Aさんが打ち込んだスキルについて2人で競ったら、どっちが優れているでしょうか?
差は歴然ですね。
Bさんが、5つ全てのスキルのスペシャリストになろうと、どれだけ心血を注いだとしてもムリです。
なぜなら、Aさんも同じだけ心血を注いで1つのスキルに打ち込んでいるからです。
5つのスキルに取り組んだ時点で、Bさんはスペシャリストではないのです。
こんなこと、誰だってわかってますよね。
でも、いざ仕事のこととなると、どうでしょう。
あなたの職場では、どうですか?

ゼネラリストなチーム

今度は、個人ではなくチームのことを考えてみましょう。
5人それぞれが5つのスキル全てに取り組むAチームと、5人が1つずつのスキルに取り組むBチームがあったとします。
どちらのチームにもコミュニケーションギャップがないとすると、どっちのチームが、優れたスキルを持っているのでしょうか?
同じではありませんよ。全く同じではありません。
Bチームの方が何倍も優れています。
Aチームでは、全員が全てのスキルを持っていますが、全員中途半端です。
Bチームでは、1つのスキルを知っている人は1人だけですが、その人は完璧なスキルを持っています。
たとえば、継承は知ってるけどインターフェイスを知らないという人が集まったチームでは、人が何万人いようが、インターフェイスを駆使することはできません。
でも、インターフェイスを知っている人が一人でもいれば、人数とは関係なく、それだけでインターフェイスを駆使することができます。
スキルは、民主主義ではないのです。
専門職は、ゼネラリストをどれだけ大量生産しても勤まらないのです。
待て待て、AチームとBチームの話で、「コミュニケーションギャップがないとすると」っていう条件があったじゃないか。
あれがおかしいんだ。
Bチームは全員違う分野のスペシャリストなんだから、Aチームとは比べ物にならないほどギャップが大きいはずだろ。
その結果、Bチームの方がスキルを有効に発揮できなるはずだ。
…とか、思いました?
そう思ったあなた、するどいですね。
コミュニケーションギャップは、組織の効率に最も大きく影響する要素です。
営業と開発の間に軋轢があったり、開発メンバーとマネージャの間がぎくしゃくしたり、コミュニケーションギャップは非常にわかりやすいカタチで、組織を苦しめます。
でも、それを解決するために、優れたスキルを失うようなやり方が、正しい解決方法だと思いますか?
全員をゼネラリストにして、オーバーラップするスキルを大きくすれば、お互いがお互いを理解することが容易になり、たしかにコミュニケーションギャップが小さくなるでしょう。
でも、そのために専門職の人のスキルが中途半端になったら、本末転倒ではないですか?
スキルを鈍らせることで問題を解決することは、はっきり言えば逃げでしかないと私は思います。
「コミュニケーションギャップ」という問題そのものを見つめて、それを真っ向から解決するべきです。
なんだかまとまりが悪いですが、要するに、私はソフトウェア開発という業務のプロセスをちゃんと分析して、最適化していくことで自己改善すべきだと思うわけです。
得意でないことを無理にやらせてもな、とでおっしゃってるような、人材配置の問題も含めてね。

0 件のコメント:

コメントを投稿

Related Posts Plugin for WordPress, Blogger...