中小企業にプログラマはいらない
「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。
この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。
以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。
- 新しい機能を実装することばかりする
- たまにバグを修正する
- 仕様書を書かない
- ドキュメンテーションを書く手伝いをしない
- 自動化されたテストを作成しない
- テスト実行を手助けしない
- 開発環境を最新に保たない(自動ビルドシステムを最新に保たない)
- 問題発生時に顧客の手助けをしない
- コードを読みもしない
- ひたすら新しいコードを生成している
小規模な企業では、ただ単にコードだけを書く人を雇用し続ける余裕がないそうです。 少ない人数であらゆる事をやらなければならないそうです。
大企業と小規模企業の違い
小規模
- オールラウンドプレイヤーが必要
- 会社が成功するために色々とやってくれる人が必要
- 一人の担当者が全てをやってしまう
- 何かを黙々と勝手にやっている人がいることがある
- キーワードは柔軟性
大規模
- 専門家がいる
- アーキテクトがデザインをする
- プログラマがコードを書く
- マネージャがプログラマを管理する
- キーワードは境界(守備範囲)
開発者に必要な要素
小規模企業では多くの人がコードを書きますが、その他の作業も同時にこなさないといけません。
- 仕様書書き
- 設定マネージメント
- コードレビュー
- テスト
- 自動化テスト
- ドキュメンテーション
- 顧客対応
「開発者」は「プログラマ」と違って大きな視点で物事を見ることができるそうです。 脅威的なプログラミング能力を持つ人は、「開発者」にはならない事があるかもしれないそうです。 コーディングは「開発者」になるためのスキルの全てではないそうです。 また、コーディングスキルが低いメンバーが、最高の「開発者」としてチームに貢献することもあり得るそうです。
FAQ
面白かったので一部要約してみました。 他にもあるので、是非原文をご覧下さい。
Q : うちのプログラマは、そんなことしたくないと言うのですが
小規模企業に居るのが良いかどうかを、そのプログラマと相談して下さい。
Q : そんなことを出来る人はあまりいなくて、雇用できないと思うんですが。
その通りです。 外部から雇用はできないので、そのように育て上げましょう。
でも、育った後はしっかりと捕まえていましょう。 そうでないと、大きな会社に転職されたり、起業したりしてしまいます。
トラックバックURL : http://www.geekpage.jp/cgi-bin/tb.cgi?id=2007/4/25
コメント
| あめみやいつき |
|---|
| はじめまして…ではありませんが、 たまに拝見させて頂いております。 私はひよっこSEですが、今の仕事が開発者側のワードにすべて当てはまりました。 興味ある内容でしたので、 一言だけコメントを残させて頂きます。 すみません。。 |
| Akira |
| ここで「プログラマ」と呼んでいる人は単にコーダーであり、だめな例は、企業規模によらず要らない人材である。 研究者はここでいう新しいことしかしない「プログラマ」に当てはまるのだろうか。会社の規模を拡大するために必要な新規技術の創出を考えるならば、研究者も小中企業に必要である。 経営者が外注にシステムを作成させた場合、新規システムならば経営者が開発者といえなくもない。 用語の認識の違いで言葉遊びをしているだけに思える。 |
| はろう |
| この記事をよんで喜んだ→プログラマ 怒った→開発者 |
| きむこう |
| というか 中小の場合一人で仕事3つぐらいしないと 利益でないので 「余計なことをしているくらいなら売上を上げろ」 という話なんではないかと。 営業が 「仕事を高く取ってこれない (かなりの確率で赤字ベースで取ってくる)」 という話はいつも問題にされないんですが、なぜ? <逆に「仕事とって来たえらいえらい」とほめられる |
| きしむ |
| >きむこうさん @お金が無いと、会社が回らない。→1ヶ月の会社の運転資金があるのなら、仕事を取らなくてもいいんじゃない? A市場には、競争がある。競争の中で、何で「差別化」するの? 1)機能 2)仕様 3)価格 4)人間関係 5)ブランド力 同じものを買うなら、あなたは何で買いますか? WindowsとLinux、「好き」はブランドイメージ、「買う」は購買行動です。 |
| おれはなに? |
| そもそもこの記事自体、日本では当てはまらない気がします。 ・仕様書書き ・設定マネージメント ・コードレビュー ・テスト ・自動化テスト ・ドキュメンテーション ・顧客対応 日本では、上記作業までがプログラマーの役目なので、こういう仕事まできちんとできる人を(日本では)プログラマーと呼ぶのだと思いますが・・・。本記事の言葉は、 開発者→プログラマ プログラマ→コーダ、パンチャ に置き換えるべきでしょうね。 確かに、日本でコードだけ書く奴なんか要りません。 |
| きむこう |
| >きしむさん コメントありがとうございます。 @自転車操業といわれている所で 少しだけ余裕がある所は 「このままいくと3ケ月後 OR 半年後にショートする」 ということだと思うのですが。 手形もすぐ現金で入ってくるわけではありませんから。 A大手IT系のようにブランド力があれば 確かに国営産業に入札できますよね。 大多数の中小は、 * そこから仕事をもらう <ここにIT土方といわれる構造があります。 * 大企業が取らないようなうまみの少ない仕事を取る (開発期間と内容が金額とバータでは無い物) しか方策がとれないのでは無いかと思います。 (オリジナルのソフトを作っていても 大企業ブランドの販売網通さないと 買ってくれないとか・・) 例)DAYDA.Laboo とか。 あそこはF社ブランドで売ってますよね。 後は「損して得取れ」で最初はお仕事もらって * 続けていくことにより信頼をもらう * =>適正な金額で次の仕事をもらえるように頑張る となってしまうのではないでしょうか。 悲しいことですが。 |
| ふうう |
プログラムが仕様通り動かなければコーダーの責任 その仕様に問題があればプログラマの責任 開発中に仕様が増えていったのならSEの責任 開発中に仕様変更を受けてしまったのなら営業の責任 全部うまくいっても開発代金が入ってこないなら役員の責任 まぁ、開発会社の構造なんて、こんなもんじゃね。 |








