帰属意識が薄れない客先常駐の話

客先常駐という働き方はもうやめにできないか、っていう話が盛り上がっています。

実際自分が体験して、また仲間を現場に送りこむ立場になって思うのは、この働き方は働き手にあまりに負荷をかけるのではないかということです。
IT業界で客先常駐という働き方はもうやめにできないか – あいむあらいぶ

どういう問題があるのかについては、記事に書かれているとおりだと思いますので、元記事を読んでいただければと思います。

そういう問題が起きがちであることは認めつつも、それを解決することにほぼ成功していた会社で働いた経験があるので、この記事では、どういう対策が行われていたかを書いてみようと思います。

“帰属意識が薄れない客先常駐の話” の続きを読む

ホウレンソウに頼らないマネジメント

sxchu_299380_hourenso.jpg

Twitterのつぶやきを見ていたら、わりと常識に縛られないタイプの方なのに、「新人研修で覚えてもらうのはホウレンソウとプログラミングくらいかなぁ」的なことを言われていて。そういえばホウレンソウって必須でもなんでもないことは意外と知られていないなぁ、と思ったので書いてみる。

ホウレンソウに頼ったAくんの仕事の進め方

  • 9:00 業務開始。朝Mtgで、その日やることをみんなの前で発表。ぼく早くプログラム書き始めたいんだけどな…
  • 9:30頃 昨日の進捗報告に上司からツッコミが。詳細な説明を書いて返信する。
  • 10:00頃 ようやくプログラムを書き始める。
  • 12:00 お昼休み。
  • 13:00 再びプログラムを書き始める。
  • 14:00 今朝のメールに上司は納得しなかったらしく、呼び出された。状況を説明してようやく納得してもらう
  • 15:00 えーと。何してたんだっけ。あれ。このあと進捗会議か。
  • 15:00 さっき上司に説明したばっかりの状況をもう一回みんなに報告。みんな興味ないから聞いてないんだけどね。
  • 18:00 延々と関係のない人たちの状況を聞かされて、ようやく終了。晩御飯食べに行きますか。
  • 19:00 定時後はプログラミングの時間だ!
  • 22:30 今日の進捗をメールに書いてMLに投げる。メールボックスに届いている他のメンバーからの進捗報告は、興味が無いのでまとめてゴミ箱へ。

だいたいこんな感じかと思います。公平を期すため、3時からのラジオ体操とか、11時から健康診断に行かないといけないイベントは省きました。

sxchu_994712_carot.jpg

ホウレンソウに頼らないBくんの仕事の進め方

  • 9:00 業務開始。昨日思いついたアルゴリズムを猛然と書きはじめる。
  • 9:30頃 マネージャさんが後ろを通った気がしたけど、猛然とプログラムを書いていたら通りすぎていった。用事があればまた来るでしょ。
  • 12:00 お昼休み。
  • 13:00 再びプログラムを書き始める。
  • 14:00 マネージャさんが後ろから覗いた気がしたけど、猛然とプログラムを書いていたら去っていった。用事があればまた来るでしょ。
  • 15:00 一休みしていたら、マネージャさんが走ってきた。手が空くのを待っていたらしい。
    「様子はどう?」と聞かれたので、進捗を説明。納得の行かないところにはツッコミが入るけど、説明したら納得してくれた。1vs1の会話だから、所要時間は15分もあれば十分
  • 15:30 再びプログラムを書き始める。
  • 18:00 仕事終わり。スポーツジムによって帰ろう!

かっこ良く定時で仕事を終えていますが、プログラムを書いている時間はAもBも7.5hです。Bくんが超高速で仕事を終えているわけではありません。

sxchu_977756_salad.jpg

進捗の把握は誰の仕事?

じつは、AもBも自分が経験したことのある仕事です。Bは夢物語だったわけじゃなくて、実際にそういうふうに仕事をしていました。ラピュタは本当にあったんだ!(海の向こうに)

  • Aでは、進捗を報告するのがメンバーの責務になっています。Bでは、進捗を把握するのはマネージャさんの仕事です。だってマネージャってマネジメントする人でしょ?
  • 進捗会議で全員の時間を束縛するより、1vs1を繰り返したほうが、進捗把握に係る工数は少なくなります。わかりきっているところはカットできるし、わからないところはその場で聞き返せるので、マネージャさんの理解度も高いです。
  • 進捗を把握するのはマネージャさんの仕事であってメンバーの仕事ではないので、マネージャさんはメンバーの仕事を邪魔しないように、忙しくなさそうな時間を見計らって進捗を聞きに行きます。「忙しいところ悪いけど、進捗を聞かせてもらえるかな?」
    とはいえ、マネージャとメンバーは同じ目標に向かって進むチームなので、メンバーも可能な限りマネージャさんがヒアリングしやすいように協力しますけどね。
  • Bの問題は、マネージャさんが異常に忙しいことです。メンバーが日報を書かなくていいのも、進捗会議に出席しなくてもいいのも、マネージャさんが進捗を聞いて回っているからこそです。
    マネージャさんは大変ですけど、メンバーより多くお給料が出ているんだから、メンバーよりたくさん働くのはとても正しい姿ですよね。

メンバーはお互いの仕事の進捗を知らなくて、マネージャさんだけが全ての進捗を把握することになるので、誰かがコケたときに他の人がカバーすることはできません。
各人の責任範囲が明確で、メンバーの役割がはっきりしている欧米型の仕事の進め方だからこそやれるやり方なのだと思います。
でも、ここで書いたのは、実際にぼくがメンバーとして働いたことのある体験談なので、これで仕事が回っている職場が実在します。というか、日本以外で働いたときはたいていこのやり方でした。

日本式に、メンバーが状況を報告したり、やばい時に自発的に動く能力を持っていることは、別に悪いことではないです。やばい時に自発的にアラーム上げてくれたら、マネージャさんは進捗を聞いてまわる頻度を下げることができるし、メンバーの報告だって下手であるよりは上手なほうが嬉しいに決まってます。
でも、そうじゃないと仕事が回らない状態が常識だと思っているとしたら、世の中そうじゃないやり方もあるんだよ、という話も知っておいていただけると嬉しいです。

関連記事

派遣プログラマ時代の思い出

sxchu_1217630.jpg

2010-08-19 追記
ごめん、今更なんだけど、見積もりは「60%と90%」じゃなくて「40%と90%」だったような気がしてきた。まあ本質的には大きく違わないんだけど。この考え方の背景はこちらをご覧ください。

システムの納期とは確率分布だ-Publickey

(追記終わり)

派遣PGとしてひどい目にあった人がいて盛り上がっている。

  • 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。
  • 「これ参考にしてください」と言って渡されたフローチャートは双六のようで、最後から一つ手前に「仕様変更で振り出しに戻る」と書いてあっても驚かないような代物だった。

Togetter-「派遣PG時代の思い出」

で、紅茶屋さんが、そうはいっても、最新技術を追いかけ回す企業が旧態依然とした企業より生産性が高いとは限らないよ?とのご指摘。

現場を変えようと取り組んでも結果として何も変わらないことはよくあります。また、よしんば何か新しいものが導入されても最初の目論見からはねじれた形で運用されてしまうこともあります。
慣習やしがらみという壁はそれほど厚いものです。オフコンが反対の部屋でいまだ現役でデータをあげてくるのに、自分のまわりだけ新しい体制を導入したのではひっかきまわすだけです。運用教育にまつわるコストは、おそらくWEB系の方々が思われているほど低くはありません。
ITドカタを笑ってすましてちゃだめだろ-紅茶屋くいっぱのあれこれ日記

 それはその通りなんだけど、その筋で考えると結局、一般兵は最新技術なんか追いかけ回さずに軍曹の言うことを素直に聞いてりゃいいんだ、という結論になってしまって、
それだったら結局、件のtogeterのエントリを見て笑っておくのが一番精神的に健康が保てるような気がする。

どうしたらいいかは自分にも分からないのだけれど、過去に真逆の現場を見たことがあって、これはこれで珍しい話のような気がするから書いてみる。
数百人規模のエンジニアが一つのプロダクトを開発しているのに、見通しのいいコードを書こうとする文化が存在していて、プログラマの見積もりがそれなりに当たるようになる魔法のメソッドが存在した現場の話。ラピュタは本当にあったんだ!
sxchu_431877.jpg

(注:画像は全部イメージです。ここで述べている会社とは関係ありません。)

その製品は、外資系の会社と日本の会社が合併して出来た会社の製品だった。ので、本国にもエンジニアがいっぱいいるし、日本にもエンジニアがいっぱいいて、トータル数千人規模の開発じゃなかったかと思う。全容は把握できなかったけど。
過去10機種以上が同じソースコードの上に開発されていて、そこに機能を追加したり、場合によっては既存のコードをいじったり。数機種の開発が並行して進んでいた。
あっちの不具合がこっちの開発に影響したりしないために、機種ごとにブランチが切られていた。
というか、実はブランチがプログラマの人数×数倍存在していて、プログラマはそれぞれ自分のブランチ上で開発ができる、すんごい規模のソースコード管理システムが動いていた。機種コードネーム+社員IDみたいなブランチの命名規則があった。

この規模になると、自分のコードをマスターにマージしようとしても、そもそもマスターがバグっていて動かないとか言うことは普通にあった。でも、あんまり困らなかった。
あとで書くけど全体としてスケジュールはゆるかったから、マスターが動かない時は、動くようになるまで一週間くらい放っておくこともあった。
せっぱ詰まった人が文句言って、当事者か上級エンジニアが直していたのだと思う。末端のエンジニアからしたら、一週間待てば勝手に直るイメージだった。

sxchu_1072482.jpg
Q:一週間待つってどういう事?なんでそんな緩いの?
A:プログラマが見積もりを出す時は、「90%の確率で実現可能な納期」と「60%の確率で実現可能な納期」というのを見積もる。つまり、前者はよほど致命的な問題が見つからない限り実現可能な納期で、後者はたいていの物事がうまくいった場合の納期。
マスターブランチにマージするのは、60%と90%の間のバッファの時期にリリースする事になるから、今日中にリリースせねばならない的な圧迫感のある状況に追い込まれることは滅多になかった。
チームリーダーも、「○月○日がデッドラインだ!」みたいなことは言わなくて、「今月くらいでできあがる時期のはずだから、タイミングを見てリリースしてね。出来たら報告してね」みたいなノリだった。

あと、全体にスケジュールはゆったりしていた。最初、普通に日本の開発現場のつもりでぎりぎりの見積もりを作ったら、「本当にそれで出来る?本当に実現できる数字を聞かせて。見積もりが大きかったら機能を切って調整できるけど、出てきた見積もりが遅れた時はとても困るんだ」と言われた。
でも、競合する日本製品と出荷ペースはあんまり変わらなかった。
理由は分からないんだけど、プログラマをぎりぎり締め上げてスケジュールを短縮しても、いい加減なソースコードを書いたり、どうしようもないプログラマを入れてしまったりして遅れる分が出てくるから、最終的にできあがるペースは案外変わらないのかも。
実際、ドキュメントとかも大量に作られていたし、レビューもしっかり行われていて品質はとても高かった。

sxchu_1171248.jpg
Q:不具合管理は?
A:バグトラッキングシステムが存在して、プログラマと同じ人数くらいのテストエンジニアがいた。
そのテストエンジニアが担当のモジュールをテストして、出てきた不具合をバグトラッキングシステムに登録していた。
プログラマが自分で見つけた他のモジュールのバグをあげることもあった。

ここまでは普通。普通と違ったこと。
1.テストエンジニアは派遣会社から連れてこられた素人じゃなくて、テストの理論を把握していて自分でテスト計画を立てたりなんかできる人が普通にいた。
2.登録されたすべての不具合を解決する文化がなかった。
日本だと、出荷前にはバグを0にして出荷するから、最後の数個はプロジェクトマネージャ権限で無理矢理Closeしたりrejectしたりするじゃない?
これに対して、そもそもバグを0にするという考え方が存在しなかった。バグトラッキングシステムには、常に無数のバグが放置されていた。
もちろん、担当レベルでたいていのバグは直していたし、致命的に困りそうな不具合はリーダーが割り振って修正していたけど、トータルで見ると、重要度の高い方からつぶしていって、納期が近づいてきたら、これくらいでいいかな?的な気分で製品が出荷されていく感じだった。
結果的に出荷した製品に不具合は残っていただろうけど、そのおかげで製品が売れなくなったという話は聞いたことがない。いくつかの機種は日本にも出荷したけど、普通に売れていた。

Q:テストエンジニアとか雇って採算あうの?
A:自分は1派遣エンジニアに過ぎなかったから、あの巨大なプロジェクトのコスト構造は分からない。でも何年もそれで回るのだから、コスト超過な状態ではなかったのだと思う。
日本の派遣会社に対するコスト要求はとても厳しかった。外資系で現場は英語がデフォルトだったから、テストエンジニアも普通のエンジニアも、インド人がいっぱい雇われていた。
日本国内で英語をしゃべるエンジニアといったら付加価値つけて高くなりそうなものだけど、インド人と価格競争を迫られるんだから、派遣会社はたまったもんじゃなかったと思う。
でも、現場に出るエンジニアにしてみたら、英語力はぐんぐん伸びるし、無茶をいわれない現場だったから、それはもう天国のようであった。

あと、世界規模で出荷してたから、必然的に予算も大きくなるよね、というのもあったのかも知れない。

sxchu_1251118.jpg
Q:なんでそんなおいしいところやめたの?
A:紅茶屋さんと同じ結論になるのがつまらないのだけれど、結局この職場も、巨大すぎて改善なんておいそれと出来ないという点では一緒なのです。
改善のための提案をすることは可能だし聞いてくれるんだけど、例えば何百万ステップもあるソースコードを何千のブランチに切ってアジアとヨーロッパからアクセスしても動き続けているシステムに対して改善なんて提案できるかという話で。
プロジェクト全体としては少しづつ改善が行われていたんだけど、それは自分のあずかり知らないずうっと上の方でいろんな事に目配りして検討した結果が降りてくるものであって、末端の自分は巨大なシステムの隅っこの歯車みたいな気分でした。歯車としてはとても恵まれた環境だったと思うんだけど。

で、幸せだけどなんだかつまんないよね、と思う一方で、いいめもをはじめとして、プライベートはいろいろ盛り上がっていった結果、やめることになりました。
今思えば、サーフィンが趣味でプログラミングが仕事みたいな人だったら、幸せに過ごせる職場だったんじゃないのかなぁ、と思います。
Q:僕その職場に行きたいから紹介して!
A:飲みに行った時に聞いてください。でも、派遣(請負w)ですから、自分がいた会社に今入ったからといってその現場に入れるかというと微妙だと思う。あと、同僚や上司と技術的なやりとりをできる程度の英語力が必須です。

会社に定時があって朝礼がある理由

去年の夏頃、いいめもを開発する時間を捻出するのに、朝早く起きて(ヨメに起こしてもらってw)、7時頃朝食を食べ終わって、7時から9時まで開発して、9時になったら会社に行く、という生活をしていた。

会社で昼間8時間かけて開発するのと比べて、2時間あれば1/4の成果が出せるかというとそんなことはなくて、集中力を高めて、1タスクこなすかこなせないかのうちに2時間が終わってしまうので、実際には1/8位の成果しか出せない。昼間作業できたらどんなにいいだろう、と考えていて、そういうわけで、会社を辞めた。

昼間作業できるようになってみると、思ったほど効率は上がらないことに気づく。時間が増えるとその分油断してしまうらしく、思ったほど成果は出ない。時間がボトルネックじゃなくなったとたん、やる気がボトルネックになってしまうのだ。

その上、フリーエージェントは自分で仕事をとってきたり、管理したりしないといけないので、一日八時間週五日が開発につぎ込めるなんてことはあり得なくて、実際には一日4時間くらいしか開発につっこめていなかったりする。それも、いいめも以外の開発も含めての話だから、実際にいいめもにつっこんでいる時間は実は去年の方が多い。

そう考えてみると、会社というのはうまくできた仕組みで。

とりあえず会社にいる間は仕事をすることになっているから、最低限のやる気や時間は自動的に確保できるようになっている。朝礼という、やる気を呼び起こす儀式まで用意してくれたり。

さらに、仕事をとってくる人は別にいるから、一日8時間、月曜日から金曜日まで全部やることが用意されている。

なんてうまくできた仕組みだったんだろう、と今なら思う。

あ、別に会社員に戻りたいという話をしているわけではない。好きな時間に起きて好きな時間に寝て好きな時間に風呂に入れる生活を一度経験したら、通勤なんてもうできませんw

でも、会社はなぜ定時が決まっているのか、なぜわざわざ出社しないといけなかったのか、それって、一度会社を辞めてみないと見えてこない話なんじゃないのかな、と思ったので、書いてみる次第。

上場企業にMacBook Airが作れないわけ

大きな会社小さな会社」ということで、何で人はそんなに会社を大きくしたがるのだろう?とずっと考えてきたのですが、そもそもなんでそんなことにこだわるのか?と。

会社が大きくなれば簡単に倒産しないし、たくさんの人が集まることで、より大きな物事を成し遂げることができます。なのにどうして自分はこんなに大きな会社がイヤなんでしょう?その理由が、ちょっと分かったような気がします。

 ネット企業はベンチャーが多いこともあり、上場しても社会への配慮が手薄になりがちだ。特に広報は華やかなイメージで捉えられるが、企業が大きくなればクライシスマネジメントやリスクマネジメントといった泥臭い側面も重要になってくる。

 インターネットや携帯は社会的なインフラとなり、その影響は大きい。しかし社会のルールを決定しているのは、ネットへの理解が少ない層であることも事実だ。ネットの不安を取り除くためのこういった層に向けたアプローチ、政府・政治家へのロビー活動、マスメディアの問題点を押さえながら戦略的な取り組みを行うフェーズに突入している。

携帯フィルタリング「強制反対派」に支持が集まらない理由

人からお金をいただくということは、それ相応のことをする必要があるわけで、たくさんの人からたくさんのお金を集めるということは、当然責任も大きくなってきます。上場して何億というお金を預けてもらっている会社になれば、藤代さんのいわれるような責任が生じるのも、それは仕方のないことなのでしょう。

でも、上場企業にふさわしく、ネットを知らない人にも配慮して、政府・政治家へのロビー活動、マスメディアの問題点を押さえながら戦略的な取り組みを行って、自分たちが作り出すものが起こすかもしれないあらゆるリスクを勘案し….そんなことしながら新しいものって作れるものでしょうか?自分にはそうは思えません。

インターネットでの音楽配信が引き起こすかもしれないレコードショップの倒産とか、プロテクトが破られてファイルがインターネットに流出するかもしれない可能性に対して、「上場企業にふさわしい配慮」していたら、そりゃあiTunesやiPodは作れませんよね。

結局のところ、自分はそういう、新しいことを試すときに足かせがついて回るのがイヤなのだと思うのです。
だから、コンプライアンスとかISOとか、あるいは人事とか勤怠管理とか、そういうことを考えないといけない規模まで会社を大きくしたくない、いかにそうならないようにしながら、新しい物事を成し遂げるのに必要なリソースを集めるか、それが自分の興味の焦点なのだと思います。




・・・MacBookAirですか?こういうタイトルだとたくさんの人に読んでいただけるかな、とw

でも、有線LANコネクタが必要な人とか、再インストールが必要な人に配慮していたら作れるわけがないですよね。

「大きな会社小さな会社」について

独立を考える以前からずっと疑問だったことの一つに、「どうして人は組織を大きくしようと思うんだろう?」というのがあります。



よく「組織が大きくなると風通しが悪くなったよね」「会社が大きくなったら余計な組織ばっかりできて、やたらと書類にはんこが必要になって」というような話を見聞きします。



だったら会社大きくしなければいいんじゃないの?とずっと疑問だったのです。

数十人程度の規模で、社長が全員の名前を覚えている、独自の技術を持ってそれなりの売り上げがあって、その売り上げが社会や社員にしっかり貢献されていれば、それでみんな幸せじゃない?どうしてそこで大量の社員をやとって拡大の道をひた走ってしまうのか?そんなに社長が儲けたいのか?そんな貪欲な人ばっかりじゃあないと思うんだけど。



とはいえ、実際自分も会社で小さなチームを任されてみると、無意識のうちに組織を大きくしようとしていることに気づいたり。人間、無意識のうちに組織を拡大したくなってしまうものなのかもしれません。



どういう場面で人は組織を大きくしたいと思うのか?それはいいことなのか悪いことなのか?そういう話題を「大きな会社小さな会社」に書いてみたいな、と思っています。

どうして社員を雇いたくなるのか?僕の場合

そういうわけで、先日から、いいめもOBIIを通じて知り合った方を中心に、独立することになりました、こんなことやりませんか?(だからお金ください)、と営業をかけさせていただいております。



ありがたいことに何人かの方から一緒に仕事をしようと言っていただいた結果、それなりの量のお仕事を確保することが出来そうです。



で、やってみて思ったのですが。むしろ社員が5人くらいいた方が仕事取りやすいのかも知れない。

つまり、営業に行って、うまいこと仕事の出来る人を探している人がいたとしても、あんまりにも大きな仕事については、ひとりでこなせないのでお断りせざるを得なくなります。

一方、社員が5人いれば、5人月の仕事もとれるし、1人月の仕事もとれる。

1人月ってすっごいちいさな工数なので、むしろその人数で出来る仕事の方が少ないんじゃないのか?



マイネット上原さんは5人を率いて創業した、というのを聞いて「なんて勇気があるんだ!」と思っていましたが、なるほど、やってみると、その方が合理的なのかも知れない、と思いました。



でも当面は、自分ひとりでやってみようと思います。そこでいろいろ学んだ上で、やはり組織が必要だと思えばその時作ればいいことなので。

どうして会社を大きくしたいのか?mixi笠原社長に聞いてみた。

IPA未踏ソフトウェア創造事業 2007年度I期畑PM採択プロジェクト 最終成果報告会に来ています。



ゲストとしてmixiの笠原社長にお話ししていただいたので、先日の、会社を大きくしたい理由、というのを質問させていただきました。



質問「なぜ10人程度でずっとそのままにするのではなくて、苦労してでも会社を大きくする方を選ばれたのですか?」

笠原さん

「うーん。増やさない判断はありだと思うけど、大きくする方を選びました。」

「まず、大きなサービスを作りたい、大きな貢献をしたいと思ったら、大きな組織が必要になります。」

「あと、当時若かったから。20人程度の規模で会社を維持することは将来でもできる、大きな組織に挑戦することは今しかできない、と思いました。」



なるほど。そんなこといつでも出来る、といわれると確かにその通りなのかも知れませんね。

会社が大きくならないと社員もおもしろくない

とある社長さんとお話しさせてもらって、聞いた話。



この人は今社員が五人くらいで、年商一億円くらいの規模の会社を経営されています。



これくらいの規模であれば、社長も十分な収入が得られるし、社員としても、大企業にありがちな非効率的な仕事をやらなくていいから、社長も社員もお互いハッピーだよね、不必要に大きくしないで、これくらいを維持するのが幸せなんじゃないのかな、と思っていたのです。



でも、社長としては会社を大きくしたいのだそうで。



当然理由の一つとして、売り上げをさらに上げるためには社員を増やすのが手っ取り早い、というのもあります。
でも、それだけじゃない。



「社員が増えるとどんどん会社が非効率になっていきませんか?」

「それはある。でも、社員の気持ちにもなってみて。例えば5年とか会社にいるのに、ずっと社長の命令聞くばっかりでおなじ仕事だと、おもしろくないでしょ?いずれは人を使う立場になりたいとか思うじゃない?」



あー。そのためには、必然的に会社は大きくなる必要がある、と。たしかにそうなっていないと、ずっと同じことやっていた社員さんは飽きて転職してしまうかも知れないですね。



米国とかリクルートさんみたいにポンポンやめていくことを前提とする考え方もあるとは思いますが、基本的に社員がやめて蓄積が外部に流出するのは可能なら避けたいことのはずで。社員をつなぎ止めるためには会社を大きくし続けないといけない。うーん。なるほど。



会社が大きくなりたがるのは経営者が貪欲だからだと勝手に思っていたのですが、実は社員自身が無意識に、会社が大きくなることを望んでいくところもあるのですねぇ。

会社は自ら助けない者も助けちゃう?その2

会社は自ら助けない者も助けちゃう?のつづき。


経営する人としては、そんなにがんばってスーパーエンジニアを育てなくても、まあとりあえずそれなりにやる気はありますよ、という程度の人でもたくさん連れてきて、一律の教育制度を用意して、とにかく数で勝負しちゃった方が、実際儲かってしまうんだろうな、と。



そういうわけで、会社としては、技術が好きで好きで仕方ない人をぐんぐん伸ばすより、そうでもないけどとりあえず会社を辞めないで仕事をちゃんとする人をいっぱい養成したほうが有利になってしまう、というお話の続きです。



そういう経済原理がある中で、shi3zさんのような考え方をする方はとても立派だと思うのですが、壁に突き当たるのがとても心配です。つまり、これから会社が成長してさらにたくさん人を雇うようになったとき、技術が好きで好きで仕方のない人だけを集め続けることができるのか?



結局、やる気は多少劣るけど、まあ仕事は無難にこなせるからいいか、みたいな人を妥協して取らざるを得なくなるんじゃないのかな、と。同時に、増え続ける人数に対して今のような目配りは次第に困難になってきて、しょうがない、研修はメニューを用意するから、やる気のある人は勝手に行ってください、ということになってしまうんじゃないかな、と。



今、研修メニューは用意した、行きたいものは各自上長許可の上人事部に申請のこと(でも仕事が忙しくてそれどころじゃないですから!)みたいなシステムになっている会社だって、最初からそうだったわけじゃないと思うのです。

たぶん最初は、社長自ら、バイトの採用にも立ち会って、手塩にかけて育てていたんだと思うのです。そのバイト君が社員になり、リーダーになり、今部長をやっていたり。でも、そのがんばりのおかげで社員が100人になり、1000人にもなると、社長が名前を覚えることすら困難になり….そして…普通の会社になっていったんじゃないのかな、と。



僭越ながら、そうならないことをと心から願っております。



追記:



しまった。そんなことはとっくにご存知だった。



デュアルディスプレイとポルシェ – shi3zの日記

ただ、こんな贅沢を言えるのも、UEIが発展の途上にある会社で、オーナーを含む経営者全員が会社の発展を強く指向していて、社員数が十分少なく、しかも幸いにして一度も赤字を出したことがないからです*2。



大企業になれば、膨大な社員を統率するために細かな服務規程が生まれますし、一部の社員を優遇すると労働組合に怒られる可能性もあります。



すいません。やっぱり僭越でした。今後もぜひ、志あるエンジニアに居心地のいい会社を作っていただければと思います。