ホワエグ社～分裂君
以前、実質的に社員全員がホワイトカラーエグゼンプションを適用されている会社で働いていたことがあります。 仮にホワエグ社としましょう。 私は、普通に残業代をもらっていた大企業のサラリーマンだった時代もあるので、 その大企業と比較してみます。 この大企業を、仮にサラリ社としましょう。 ホワエグ社では、企画、グラフィック、プログラマ、SE、営業、人事、経理、総務などの職種に関係なく、 ３００万円〜２０００万円という年収の違いに関係なく、 アルバイトさんを除いて、全員が半年ごとに決められる年俸で報酬が支払われていました。 休日出勤も含め、残業代は皆無です。 ホワエグ社は、ごくありふれたIT系の企業で、自社サービスもやってましたけど、受託の占める割合も大きかったです。 儲かっているときもあれば、赤字続きのときもありました。 社員数は、百数十名というところ。 サラリ社は、日本屈指の大手ソフト開発会社。
優秀な人材に変身するキッカケに出会うか、未熟なまま老いていくか
頭が良く、意欲的に仕事にとり組むんだけど、いまいちアテにできない人というのがときどきいる。 ポテンシャルはあるのに、どこか独りよがりなところがあるために、暴走するリスクがあり、安心して、重要な案件を任せられないタイプの人間である。 そういう人は、「きっかけ」があると、大化けする。本当にすごい人材になる。 しかし、きっかけが無いと、つまらない脇役仕事や日陰仕事ばかりやらせられ、未熟なまま老いて、どんどん腐っていってしまう。 この記事で描かれている坂本君は、いかにもそういうタイプの人だ。 芦屋：坂本，この「貴方の営業ご担当者様が販売活動しやすいように工夫しています」という表現は，抽象的で意味不明じゃないか。意味が分からないから，「先方へのアピール」になってないんじゃないか。説得力もないよ。ここは，具体的な事例を使って修正すべきだな。どう修正すればいいか考えてよ。 坂本：いや，ここはこれでいいん
分裂勘違い君劇場 - 実際には、いじめる側のメリットは小さくコストが大きいのだが、その損得勘定ができないからいじめが起こる
いじめる側のメリットが大きくコストが少ない限り、いじめ発生は不可避だろうの補足。 実際には、いじめる側は、トータルではすごく損なのだけど、世間知らずな上に頭が悪い子供は、その辺の損得勘定ができないのじゃないかと思います。 たとえば、シロクマさんが挙げるいじめのメリット： ・クラス内において自分達がボス集団であることの誇示 ですが、ボス猿にもいろいろ種類がいると思うんですね。 もちろん、「自分に逆らった者を容赦しない」、というところまでは、ほとんどのボス猿がやると思いますけど、「卑怯な弱い者いじめを繰り返す」というのは、別の話であって、それをやるかどうかは、タイプによって違ってくる。 で、卑怯で陰湿な弱いモノいじめを繰り返すようなタイプのボス猿は、実際には、やっててあまり「おいしく」ないと思うわけですよ。 そもそも、「自分よりも明らかに弱い者に、卑怯で陰湿ないやがらせをして優越感を味わう」と
現代という時代は、どのようなプログラミングを求めているのか？ - 分裂勘違い君劇場 by ふろむだ
Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。 そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。 団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。 冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。 とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。 冷蔵庫に限らず、洗濯機、ラジオ、テレビ、
「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育シ
2006-02-16
2006-02-16 生産性を向上させるメタオブジェクト技術 ■この記事で取り上げているトピックハイライト■ なぜ、メタオブジェクトを自分自身で使いこなせるようになると、日常のプログラミング生産性が大きく向上するのか? なぜ、メタオブジェクト技術を使うと、分散オブジェクト、Rails、DI、ORマッピング、Webサー… 2006-02-16 「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている この記事で主張しているように「同じことを2度しない（Only and Only OnceあるいはDRY：Don't Repeat Yourself）」と無条件で考えてしまうと、逆に生産性が大きく低下するケースがたくさんある。この記事のテーマは主に自動化の話だが、それは自動化だけでな… 2006-02-16 Web2.0をはるかに超える空前のイノベーション この本を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
