※2012年12月1日より新ブログに移行しました。
＞＞＞現行ブログ free to write WHATEVER I like
⇒2019年にさらにWordpressに移行しました。
＞＞＞現行HP シャイン経営研究所（中小企業診断士・谷藤友彦）
⇒2021年からInstagramを開始。ほぼ同じ内容を新ブログに掲載しています。
＞＞＞Instagram @tomohikoyato
新ブログ 谷藤友彦ー本と飯と中小企業診断士
December 12, 2005
【ミニ書評】金子則彦監修『拝見！プロジェクトマネージャの仕事場』
拍手してくれたら嬉しいな⇒
 | 拝見!プロジェクトマネージャの仕事場―ITプロジェクトの成否の鍵を握る人々 金子 則彦 技術評論社 2003-12 Amazonで詳しく見るby G-Tools |
金子則彦監修。プロジェクトマネジメントの入門書的な位置づけ。プロジェクトマネジメントが直面する様々なケースを紹介し、どのように意思決定し、行動すべきかを平易な文章で解説している。PMI（Project Management Institute）が規定したプロジェクトマネジメントのための知識体系であるPMBOK（Project Management Body of Knowledge）についても言及されている。ところで、ケースに登場する人物が明らかにドラえもんの登場人物を意識しているのはなぜ…?
July 02, 2005
知識労働者の生産性の測定方法（アイデアベース）
拍手してくれたら嬉しいな⇒
私が以前勤めていたシステムエンジニアリング会社では、従業員の評価方法がマネージャーによってまちまちであるために、従業員の間で評価に対する不満、不信を漏らす人が少なくなかった。
残業時間が長い人のほうがよい評価をされたり（←本当に意味不明なのだが）、ひどい場合は、マネージャーのフィーリングで「この人はよく頑張った」と思う人に高い評価を与えたりすることもあった（←真面目に評価をしている他のマネージャーが可哀想だ）。
最大の問題は、従業員の生産性を評価する基準がないことにあると思っている。システム開発は知識労働の要素が強いので、この問題は一般的な表現をすれば、知識労働の生産性の評価方法の問題ともいえる。
知識労働の生産性を測定するこれといった指標は実は存在しない。知識労働の多様性を考えればやむをえないことではある。しかし、少なくとも社内に限定すれば、ある程度の指標を作成することが可能だと考えている。
出発点は生産性の一般的な定義である。
生産性＝産出量÷投入量
この式は普遍であるから、後は「産出量」と「投入量」にどのような値を代入するかを決定すればよい。（以下は私が勤めていた会社を想定している。）
（1）産出量
マクロ的な分析をする場合には、ここには付加価値額、あるいは利益額を代入するのだが、社内での評価をするならば、ここには「成果物」を代入する。もちろん、クライアントにとって真に価値のあった成果物を用いなければならない。
成果物とは、作成した基本設計書、詳細設計書、プログラム、テスト仕様書、テスト報告書、ユーザーマニュアルなどがある。これに、難易度、寄与度、重要度、精度などの乗数を掛け合わせて調整値を算出する。
・難易度…同じプログラムでも容易に開発できるものとそうでないものがある。また、詳細設計書よりも、ユーザーマニュアルの方が容易に作成できるかもしれない。こうした、各成果物の難易度の格差を調整する。
・寄与度…すべての成果物が一人で作成されることはまずない。基本設計書の作成に途中まで関わっていたとか、実際にプログラムは書いていないが、開発者の横で随時プログラミングに関する助言を行っていたということもある。その成果物を作成するのにどれほどの割合で関わっていたのかを表す。
・重要度…誰も読まないドキュメントを作成しても、評価には値しない。それぞれの成果物が顧客にとって価値を生んだか否かを評価する。また、顧客の目に触れることのない成果物の場合、その成果物を利用して作られた他の成果物が、顧客にとって価値を生んだかどうかで判断する。
・精度…バグだらけのプログラム、読みづらいユーザーマニュアルは精度が低い。それぞれの成果物の品質を評価する。
（2）投入量
人件費や経費を算出することができれば一番よいが、細かくなりすぎて面倒くさくなるので、別の指標が望ましい。一番解りやすいのは総労働時間である。
これに、本人が持っている知識のレベルを加味するともっと正確になる。
例えば高いプログラミング能力を持っている人が簡単なプログラムを短時間で仕上げた場合、投入量を総労働時間のみで算出すると、生産性が高くなってしまう。しかし、彼の高い能力も投入量に加えて生産性を算出すれば、生産性が低くなり、より妥当な数字になる。
非常に大まかな算出方法なのだが、もっと突き詰めていけば多くの従業員が納得する式が出来上がると思う。
他のシステムエンジニアリング会社の評価は一体どうなっているのだろう?
《参考HP》
知識労働の生産性についてマクロ的な視点から述べているページ。
IT資本論 8つのパラドクス−生産性パラドクス(1) 生産性とはなにか
IT資本論 8つのパラドクス−生産性パラドクス(2) その解消に向けて
残業時間が長い人のほうがよい評価をされたり（←本当に意味不明なのだが）、ひどい場合は、マネージャーのフィーリングで「この人はよく頑張った」と思う人に高い評価を与えたりすることもあった（←真面目に評価をしている他のマネージャーが可哀想だ）。
最大の問題は、従業員の生産性を評価する基準がないことにあると思っている。システム開発は知識労働の要素が強いので、この問題は一般的な表現をすれば、知識労働の生産性の評価方法の問題ともいえる。
知識労働の生産性を測定するこれといった指標は実は存在しない。知識労働の多様性を考えればやむをえないことではある。しかし、少なくとも社内に限定すれば、ある程度の指標を作成することが可能だと考えている。
出発点は生産性の一般的な定義である。
生産性＝産出量÷投入量
この式は普遍であるから、後は「産出量」と「投入量」にどのような値を代入するかを決定すればよい。（以下は私が勤めていた会社を想定している。）
（1）産出量
マクロ的な分析をする場合には、ここには付加価値額、あるいは利益額を代入するのだが、社内での評価をするならば、ここには「成果物」を代入する。もちろん、クライアントにとって真に価値のあった成果物を用いなければならない。
成果物とは、作成した基本設計書、詳細設計書、プログラム、テスト仕様書、テスト報告書、ユーザーマニュアルなどがある。これに、難易度、寄与度、重要度、精度などの乗数を掛け合わせて調整値を算出する。
・難易度…同じプログラムでも容易に開発できるものとそうでないものがある。また、詳細設計書よりも、ユーザーマニュアルの方が容易に作成できるかもしれない。こうした、各成果物の難易度の格差を調整する。
・寄与度…すべての成果物が一人で作成されることはまずない。基本設計書の作成に途中まで関わっていたとか、実際にプログラムは書いていないが、開発者の横で随時プログラミングに関する助言を行っていたということもある。その成果物を作成するのにどれほどの割合で関わっていたのかを表す。
・重要度…誰も読まないドキュメントを作成しても、評価には値しない。それぞれの成果物が顧客にとって価値を生んだか否かを評価する。また、顧客の目に触れることのない成果物の場合、その成果物を利用して作られた他の成果物が、顧客にとって価値を生んだかどうかで判断する。
・精度…バグだらけのプログラム、読みづらいユーザーマニュアルは精度が低い。それぞれの成果物の品質を評価する。
（2）投入量
人件費や経費を算出することができれば一番よいが、細かくなりすぎて面倒くさくなるので、別の指標が望ましい。一番解りやすいのは総労働時間である。
これに、本人が持っている知識のレベルを加味するともっと正確になる。
例えば高いプログラミング能力を持っている人が簡単なプログラムを短時間で仕上げた場合、投入量を総労働時間のみで算出すると、生産性が高くなってしまう。しかし、彼の高い能力も投入量に加えて生産性を算出すれば、生産性が低くなり、より妥当な数字になる。
非常に大まかな算出方法なのだが、もっと突き詰めていけば多くの従業員が納得する式が出来上がると思う。
他のシステムエンジニアリング会社の評価は一体どうなっているのだろう?
《参考HP》
知識労働の生産性についてマクロ的な視点から述べているページ。
IT資本論 8つのパラドクス−生産性パラドクス(1) 生産性とはなにか
IT資本論 8つのパラドクス−生産性パラドクス(2) その解消に向けて
 | IT資本論―なぜIT投資の効果はみえないのか? (Mycom PC Web) 近 勝彦 毎日コミュニケーションズ 2004-12 Amazonで詳しく見るby G-Tools |
June 30, 2005
「遅刻」が会社にもたらす金銭的損害
拍手してくれたら嬉しいな⇒
私が以前に所属していた基幹システム開発ではとにかく遅刻が多かった。就業開始は9時という規定になっていたが、9時にメンバーが全員揃うことは皆無だった。
私は遅刻が嫌いである。チームの士気が下がるし、遅刻をする人⇒時間にルーズである⇒仕事の期限を守らないというのが常だからである。迷惑極まりない…
何よりも問題なのは、遅刻によってコストが発生するということである。この事実にどれほどの人が気付いているだろうか。
遅刻をする人がいると、その人がいないために仕事ができないメンバーが出てくる。彼らの待ち時間は完全にコストである。
仮に、あるプロジェクトで毎朝必ず誰かが30分遅刻するとして、そのために仕事が30分間できなくなる人がプロジェクトに5人いるとする。クライアントはメンバー1人当たり毎月100万円（※1）を支払っているとすると、
1日当たりの金額＝100万円÷20日（1月の標準出勤日数）＝5万円
30分当たりの金額＝5万円÷8時間（1日の標準労働時間）÷2＝3,125円
5人分で 3,125×5＝15,625円
つまり、クライアントは1日当たり15,625円無駄に支払っていることになる。
これが年間単位（システム開発のプロジェクトの多くは数年がかりのプロジェクトになる）になると、
プロジェクト内で1年間に無駄になった金額＝15,625×250日（休日を除いたおおよその年間出勤日数）＝3,906,250円
400万円弱もの金額をクライアントは無駄に支払ったことになる。決してこの額は小さくはないと思う。
この5人は朝仕事ができなかった分を残業で賄おうとするので、さらに追加費用が発生するのは目に見えている。
遅刻は無視できないコストである。
※1 大掛かりなシステムを開発するプロジェクトでは、クライアントが支払う額はこのくらいだと思う。ちなみに、私がいたプロジェクトでは、これよりもはるかに高い額をクライアントは支払っていた。
私は遅刻が嫌いである。チームの士気が下がるし、遅刻をする人⇒時間にルーズである⇒仕事の期限を守らないというのが常だからである。迷惑極まりない…
何よりも問題なのは、遅刻によってコストが発生するということである。この事実にどれほどの人が気付いているだろうか。
遅刻をする人がいると、その人がいないために仕事ができないメンバーが出てくる。彼らの待ち時間は完全にコストである。
仮に、あるプロジェクトで毎朝必ず誰かが30分遅刻するとして、そのために仕事が30分間できなくなる人がプロジェクトに5人いるとする。クライアントはメンバー1人当たり毎月100万円（※1）を支払っているとすると、
1日当たりの金額＝100万円÷20日（1月の標準出勤日数）＝5万円
30分当たりの金額＝5万円÷8時間（1日の標準労働時間）÷2＝3,125円
5人分で 3,125×5＝15,625円
つまり、クライアントは1日当たり15,625円無駄に支払っていることになる。
これが年間単位（システム開発のプロジェクトの多くは数年がかりのプロジェクトになる）になると、
プロジェクト内で1年間に無駄になった金額＝15,625×250日（休日を除いたおおよその年間出勤日数）＝3,906,250円
400万円弱もの金額をクライアントは無駄に支払ったことになる。決してこの額は小さくはないと思う。
この5人は朝仕事ができなかった分を残業で賄おうとするので、さらに追加費用が発生するのは目に見えている。
遅刻は無視できないコストである。
※1 大掛かりなシステムを開発するプロジェクトでは、クライアントが支払う額はこのくらいだと思う。ちなみに、私がいたプロジェクトでは、これよりもはるかに高い額をクライアントは支払っていた。
