最近はプログラムをほとんど触っていないので、自分の研修で身に付けたjavaの技術力が衰えている気がします。
まぁでも、もともと衰えるほどの技術力はついてないから気にしなくていいかもしれませんが。
大学では今AccessとExcelのＶＢＡをやってますが、この会社で学んだことと比べればえらく簡単だと思います。
さて、今就業規則について調べ中ですが、これがなかなか難しくて面白いです。
もともと経営組織論や事業分析には興味があったのでかなりその勉強になります。
就業規則を調べていて、今一番問題なのは社員の公正な評価方法です。
この会社のように知識集約型の産業は職能給にウェイトを置く場合が多いのですが、
そうした場合、昇給における評価方法に主観が入らないようにかなり気を付けて行わなければなりません。
しかも職能給にウェイトを置いてうまくいっている事例はほとんどないそうです。
何かいい案があれば提案をお願いします。
あと、決めて欲しい事項はtracに載せました。資料はopenofficeのパワーポイントで作成したので合わせて見て下さい。
6件のコメント
koreyasu · 2007-07-05 18:18
評価基準は難しいですが、結局は利益ベースにするしかないと思っています。
アメーバー経営などに見られる、『単位時間当たりの付加価値』を評価する方法ですね。
または、チームで行動している場合には、メンバー間で評価を行う方法もあります。これにおけるルールは
・お互いがお互いを１、２，４，５で評価する。
・自分は必ず３
つまり相手を明確に自分の上と見るか、下と見るか判断せねば
なりません。
あるいは、リーダーレベルとメンバーレベルで分けると言うのもあります。
元々求められているものが違うので
・リーダーは利益ベース
・メンバーは生産性ベース
と言うような扱いで考える。というのもあります。
これが良いという最善は今のとこありませんので、トライ＆エラーでいくしかないですね。。
squld · 2007-07-05 19:12
人事評価の方法だけでも十分商売になります。
どこの会社も欲しがっているんですね。
「人事評価」でググると様々なサービスやシステムが見つかるでしょう。
50%はシステムで評価するとしても、残りは今まで通りの評価方法を使うといった事が多いみたいです。
報酬(下手すると人生も)に影響する事柄なのでみんな敏感になりますね。
たとえば、はてなではボーナス査定にメンバー間評価を導入しているようです。
http://d.hatena.ne.jp/rawlow/20070701/p2
hayashi · 2007-07-09 17:33
メンバー間で評価を行う＜
メンバー間で結託されて、お互い５と評価するようになる危険性があります
リーダーレベルとメンバーレベルで分ける＜
生産性の算定方法が問題となります。
完全出来高制であるならば、メンバー間の助け合いはなくなりますし、
時間制では当然要領や技術力が反映されなくなります。
また、この評価方法はリーダーの選出方法やメンバーの構成方法も問題になってきます。
リーダーは契約企業から信頼があるか、プロジェクトの全体を把握しているか。
メンバーに偏りがないか、効率的にプロジェクトを進められるメンバーか。
koreyasu · 2007-07-13 10:26
■メンバー間で評価を行う
> メンバー間で結託されて、お互い５と評価するようになる危険性があります。
どの方法であれ危険はあります。上司に完全に判断を委ねる
場合もお気に入りの部下、のようにひいきは発生します。
逆に、完全に評価基準をオープンにすることもできますが
状況にそぐわないケースも出てきます。
対処案と言うわけではありませんが、誰が誰をどう判断したかを
上司が確認するとあからさまな操作はできないでしょう。
また、なぜそう判断したかを書かせると偽りは書きにくく
なるでしょう。
■リーダーレベルとメンバーレベルで分ける
・生産性
見積もりを行う時に、それぞれの大体の難易度・規模等を
割り出します。ここから大体の予定工数が出てきます。
予定工数/実質工数が基本となる数値と考えて良いです。
ここから、不具合の件数や規模などが加味されます。
・メンバー間の助け合い
これに関してはペアプログラミングの強制で対応できる
かもしれません。最近回りでやってるので見てると思いますが
二人で一つのディスプレイを利用し、作業するという手法
です。これにより、就業時間の半分は必ず誰かの為に作業を
行わなければなりません。また、要領や技術力の伝播も
行われます。
ドラッガーの書籍を読まれた事があるのであれば、
technologyという言葉の発祥をご存知かもしれません。
technologyという言葉が出来る前、techniqueの時代は
ギルド制で師弟関係を持って各ギルドの秘術を伝播して
いました。これと同じようなイメージを持ってもらえば
良いと思います。
正直、今のソフトウェア技術は、テイラーが体系化する前の
ような状態ですね(笑
もちろん、体系化されている分野もありますけど、例えば
EclipseやVisualStudioの使い方なんて秘術みたいな
もんです。
・リーダーの選出方法
基本立候補制です。やりたい人がやれば良い。
その代わり、評価基準は利益ベースに変わるので結果だけ
出さなければならない。やりたい人が複数いれば、経営サイドが
判断します。
また、短期的な利益に走らないように、またリーダー変更時に
正確に情報伝播がなされるように、前任者が後任者を
フォローアップしある程度利益に影響する仕組みを作る必要は
ありそうですね。
・メンバーの構成
基本はリーダーが選出します。リーダーは利益＝自分の評価
ですから、利益を上げれるメンバーを選ぶはずです。
もちろん、メンバーは利益なんて正確には認識していませんから
リーダーの裁量で上手く誘導する必要があります。
と言う感じです。ツッコミを入れてくれればまた返しておきますので、お気軽にどうぞ。
hayashi · 2007-07-13 13:14
＞なぜそう判断したかを書かせる
賛成です。ただ、上司がどの程度全体を見渡せているかは問題になります。
とりあえず現状の規模であればうまく回るかもしれません。
自己評価、メンバー評価、上司評価と三重評価すれば、多少は解消するかもしれません。
＞不具合の件数や規模などを加味
どの程度加味するか難しいところです。
その不具合の原因が、単純なミスなのか、それとも技術不足だったのか、
あるいは手抜きによるものなのか、不具合も様々なので
不具合の程度を感覚で決めないようにする必要があると思います。
＞ペアプログラミング
ここはよくわかっていない点なので質問になってしまうのですが、
どの人とペアを組むかで要領や技術力の伝播ができなくなるのでは？
例えば、同じ技術力を持った者同士でのペアプログラミングは技術力伝播はありうるのでしょうか？
＞メンバーはリーダーが選出
リーダーが選出ならば、やはりメンバーの能力偏りが生じてしまうと思います。
これは複数のプロジェクトを重複して受け持つ人やどのプロジェクトにも属さない人が現れるということなのでしょうか？
ＹＥＳであればプロジェクトに属さない人をどう管理するかや、複数に属する人をどう効率的に回すかが問題です。
＞リーダーの選出方法は立候補制
会社にとって最もいいリーダーを選出できない可能性があります。
信頼性、責任感、技術力の面から見て明らかに劣っている者が立候補した場合、
前任者の信用を汚してしまったり、
最悪会社の名前を汚してしまったりすることも考えられます。
それだけ重要なリーダーを立候補で決めてしまっていいのだろうか。
koreyasu · 2007-07-17 19:00
指摘のあった部分だけ、自分の考えを書いて見ます。
> 不具合の程度を感覚で決めないようにする必要があると思います。
これは大企業が色々やっていて、上手く言ってない点ですね。
どの工程で混入した不具合なのか？規模・影響は？原因は？
繰り返さない為の対処法は？などといった項目を書かせて統計を
取っています。ただ、ある程度は杓子定規にやってしまうのは仕方
ないですね。
生産性を図ると言う意味では、不具合の件数等には着目せず、
不具合に対する対処時間だけを見るのも良いかもしれませんね。
件数だと、いくつかの不具合を一まとめにできたり、一つずつの
不具合対処にえらく時間がかかったり(一まとめにしたら、当然規模も
大きくなる)しますから。
また、お客様に影響のあるかどうかなどの視点も欲しいですが、
まだまだ考えることは多そうです。
＞ペアプログラミング
組む相手は固定では無いので、誰と組むかと言う問題は無いです。
また、同レベルでも問題ないです。各々が得意分野や専門性を持っていますし
業務知識という意味では、みんな異なる知識を持っています。
このような知識を伝播させていくには良い方法です。
＞プロジェクトに重複して所属する人、どこにも所属しない人
そういう人も当然います。
重複して存在する人は、その人の裁量次第で動いてもらうしかないです。
全く所属しない人は、勉強という事になると思います。
誰からも選ばれないと言うのは、それだけ他の人に較べて、技術面で
劣っているから、これは仕方が無いですね。
効率よくという話になると、各プロジェクトレベルではリーダーに
任せるべきです。プロジェクト間となると、メンバー自身がどう時間を
割り振りするかという話です。
＞会社にとって良いリーダー
キャリアパスによると思います。リーダーを将来的にやりたい人と、
一技術者でいたい人はもちろん違います。リーダーの素質があるからと
言って、リーダーをさせるのは酷でしょう。好きこそ物の習いなれ、じゃ
ないですが、うちの方針がそんな感じです。もちろん、こちらから打診も
しますけど、強制はないです。
ただ、サポートしてもまだ難しいだろうと言う人には、さすがにリーダーを
任せることは無いです。hayashiさんの言うとおり信用問題になりますからね。
とは言え、明らかに前任者に較べて劣っている人たちでも、任せることは
あります。そうしなければ、いつまで経っても自分たちがリーダーを
やらなければならないですから。会社を大きくしていく為にも、必要だと
思います。もちろん、徐々に任せるようにはしていきますけどね。
現在コメントは受け付けていません。