シングルマザーが抱える漠然とした不安
http://nikkeibp.weblogs.jp/mental/2005/06/singlemother.html
メモ．
この問題はシングルマザーだけでの問題ではない．
http://www.doblog.com/weblog/myblog/17090
- 作者: 城繁幸
- 出版社/メーカー: 光文社
- 発売日: 2004/07/23
- メディア: 単行本
- 購入: 9人 クリック: 261回
- この商品を含むブログ (206件) を見る
けれども3年もすると、どうやら評価されるのは残業時間の長い人らしいと、分かってきた。
成果を評価できない人間が「管理職」をやっていると，結局は成果ではなく別の指標で評価される．「残業時間」とか「頑張っている（ように見える）」だとか．それは即不公平感に繋がる．少なくともソフトウエア開発の世界において，残業時間を直接の評価尺度にすることには無理がある．
全員の労働時間が同じであるならば、背中に一つしか麻袋を背負わない労働者は、他の労働者の半分しか仕事をしないことになる。少し難しく言えば、この「怠け者」の労働生産性は他の労働者の半分だということになる。したがって、作業量に応じて報酬を支払うというルールになっていれば、この「怠け者」の労働者の報酬は他の人の半分でよいことになる。
しかし、不思議なことにソフトウェア産業では、この「怠け者」に一人前の報酬を支払っていることが多い。場合によっては「怠け者」の言い分を真に受けて、「怠け者」の方が報酬が多くなることもある。なぜなら、他の人より長時間働くことになり残業手当が多くなるからである。この業界を知らない人にとっては信じられないことかもしれないが、これは事実である。
仕事のできない人間の方が給料が多いとなれば、仕事のできる人間がやる気を失ってもしまうだろう。これでは、仕事のできる優秀な人材が集まるはずがない。
http://hotwired.goo.ne.jp/original/maegawa/050118/index.html
努力して技術を高めて十分の一の時間でかたづけて残り時間を持て余している人と，何も努力せずに最低の技術力で不具合を大量生産して他の人まで残業に巻き込んでいる人がいたとして，どちらを評価すべきだろうか？
こう言われれば，それがどちらであるかは言うまでもない．しかし実際には技術力が低いから失敗しているのか，仕事量が多すぎるから時間がかかっているのかは必ずしも分かるとは限らない．特に技術が分からない素人が「管理職」をやっている場合などはまさにそうだ．その結果，低い技術力で失敗している人の方が，高い技術力をもって成功している人より高い評価を得る逆転現象も発生する．これで「成果主義」とは笑わせてくれる．
藤本の開発するソフトのほとんどは、ほかの部署が作ったソフトを借用して開発している。だれもが全体の一部分のみしか担当しない。自分の担当したところに関連する、他人が開発した部分の出来の良しあしが自分に降りかかってくる。
ある人の失敗が，他の人の生産性低下に繋がるのは良くあることだ．自分が作ったバグや設計ミスが他人の足をひっぱらないかと，いつもヒヤヒヤしている．それに比べたら，他人の作ったミスが自分の足を引っ張る方が気が楽だ．
だがそれがあまりに初歩的且つ致命的なミスで，しかも毎回となると話が変わる．それでもその技術力の差，品質の差が成果として評価されるのならいいが，このような品質を測るのは極めて難しい．ソースコードも満足に読み書きできない人が「管理職」をしていたとして，はたしてそのような品質を測り，それを評価に反映できるだろうか？まず無理だろう．たとえ昔は一流技術者だったとしても，現場を離れて数年もすれば一流ではいられなくなる．ましてや元が素人だとしたら論外だ．*1
ただ、こうして鉄が錆びるようにソフトの質を下げていって、開発者として恥ずかしくないのかと藤本は思うのだ。もちろん藤本は、「エラー」の後の処方箋は「当然のこと」として組み込んでいる。なるほどそれを省けば、一手間、楽にはなる。でも使う人の立場を考えれば、そんな手抜きができるわけはないと思う。
成果主義が始まってからだ、と藤本は感じている。さっと作ってポンと納入する。そうやって自分が開発に加わった企画の数を増やす方が、評価の基準となる「数字」に現れる。実際にそうして高い評価を得ている人間を、藤本は何人も知っている。
残業の少なさが評価に響く制度の下で働いているのだ。「エラー」表示のフォローを細かく作っていますと訴えたとしても、それは「数字」には反映されない業績だ。開発したソフトが顧客に喜ばれたと聞いても、自分の担当したあまりにも小さな一部分がどのくらいそれに貢献したのか、見当もつかない。
「品質」や「技術力」が評価基準に含まれず「売り上げ」だとか「作ったコードの行数」だとかを評価基準にすれば，当然こういう結果になる．一社員の立場としては自分の給料を上げるため，時として自分の家族の生活を守るためにはそうせざるを得ない．
これを個人の問題と切り捨てるわけには行かない．このような方法をとることで給与が上がる『成果主義』を採用しているということは，経営陣が「品質の低下を奨励している」ことを意味する．経営陣自らが品質を低下させて短期的な売り上げを上げようとする戦略を採用しているならば，一社員としてそれに逆らうのには無理がある．
一方でこういう品質の低下は，長期的には生産性の低下や不具合の増大，顧客満足度の低下などの形で帰ってくる．短期的には会社に利益をもたらすように見えても，長期的には果たしてどうだろうか．「安かろう悪かろう」を容認していて日本車や日本の電化製品が世界で認められるようになっただろうか．私に言わせればこういう成果を一切評価しない『成果主義』は，技術をウリにするソフトウエア企業にとっては自殺行為だ．*2一つのブランドを育てるためには何年ものたゆまぬ努力が必要になる．一つのブランドが崩壊して地に落ちるには，たった一度の失敗で十分だ．経営者は雪印乳業の食中毒事件や三菱自動車のリコール隠しから，何も学んでいないのだろうか．
でも働くからには、何か目標や希望がほしい。不安ばかりを抱えてあと20年働き続けるのは、精神的にきつい。
こういう不安は，できるできないに関わらず存在する．そしてこうなるとできる人から順に辞めていく．技術に対する拘り，良いものを作るためのたゆまぬ努力，それらを全て否定して品質を低下させ続ける会社で，将来に夢を持てという方が無理というものだ．それどころか，そのような会社が今後十年生き残れるかどうかさえも疑わしい．
だから，私は前の会社を辞めた．
「開発プロセスの功罪」
http://blog.uzushio.org/?date=20050611#p03
「開発プロセスにより低レベル開発者でも高い生産性と品質が得られる」という幻想は、現場では結構盲目的に信じられていることなんじゃないかな
いや，信じているのは経営陣と，経営陣などからそう言われ続けた初心者開発者だと思う．
「高い技術を持った開発者を前提とした場合に、さらに開発プロセスというものがあることにより、高い生産性と品質が得られる」という話なんじゃないか。
これには賛同しかねます．いわゆる「開発プロセス」というものを策定したからと言って，生産性や品質が向上するという根拠もなければ，経験的に言っても向上するとは考え難い．少なくとも開発者の足を引っ張る「開発プロセス」の方が多いのは事実です．
有効な対策としては，むしろ優秀な技術者のベストプラクティスを広めることだろうが，これについては評価制度との関係もあって，実現は遙かに困難でしょう．なによりも「何がベストであるか？」を判断するのが，素人にはできない．
しかし、今の業界では「開発プロセスでなんとかしよーぜ」という話よりも先に、「技術力のある技術者をちゃんと育てようぜ」の方が優先度が高いんとちゃうか？
これは正にその通り．しかし残念なことに技術者を育てるには非常に時間と手間が −つまりはコストが− かかる．それだけのコストを負担するよりは，遙かに簡単で安上がりな方法 −「開発プロセス標準化」という名の幻想− に騙されたと思って飛びついてしまう方が多いようだ．*1
そうでない場合もあるけれど，これは即戦力に期待する中途採用の増大という形で，水面下で進められてます．中途採用を増やす企業としては，できるなら自社に求められる経験豊富で優秀な人材を他社に先んじて確保したいから，あまりおおっぴらに宣伝するのは避けたいわけだ．
*1:そして本当に騙されていれば世話ない．
開発プロセスの功罪
『上流行程?神話の信奉者』とか、『UMLモデリングで大系づけられた標準開発手法』を唱える人たちに、実際のプロジェクトを任せてみて、『生産性がXX％上がり，コストがXX％下がる』かどうかを実験してみるのはどうでしょう？
既に一度それに近いことを経験し，痛い目を見てます．結果は悲惨なものでした．*1
これなら、『開発プロセスは役に立たない』ことが証明されるんじゃないでしょうか。
例えば次のような言い訳をしたらどうでしょう？
「私は良いモデリングをしたのだけれど，下流行程で問題が発生しました．実装を担当する開発者の技術力が低く，オブジェクト指向技術に不慣れだったことが原因です．」
「（前回失敗したのは）きちんとしたUMLモデリングができていないからです．つまりUMLモデリングが悪いわけではなく，その時の担当者がたまたま悪かっただけです．私はベテランですから大丈夫．今回は大船に乗ったつもりでいてください．」
こう言われたら，それを信用する経営者もいるでしょうね．実際には複数の要因が絡み合うこともあって，設計ミスとプロジェクトの失敗の因果関係を理解するのは簡単ではありません．それができるのはコードレベルの詳細さで実装や設計を把握できる人くらいに限られるんです．
