にゃん太郎さんこんばんわ。
今回も読み応えがあるいいコラムでした。
仰るとおりだと思います。
会社も社員もコスト意識が無さ過ぎます。
他業種の方はもっとコストを意識しています。
よくよく考えてみれば、コスト意識が無いのによくこの業界もっているな・・・
と不思議に感じます。
次回のコラムも楽しみにしています。
どんなコラムが来るかな♪

ビガーです。

コスト意識を持つことは大事だと思います。生産性を上げるということも大事。
ただ、どうやったら生産性って上がるのかを具体的に提示いただけるとコラムの読者(私)としては、参考になるのでありがたいと感じました。

私の考える生産性とは、適切な役割の分割にあると考えています。
スキルのあるヒトは、基盤系(フレームワークの拡張など)、新人君に近い人達には穴埋め系、ちょっとできるヒトにはテスト系など。
社員という前提であれば、そういう環境作りは大して難しくないと考えています。(実際社員時代にやっていたので)
コストを意識すれば、生産性が上がるというのは現実的に「ない」と思います。(根性論に近い？)
背中を見せてあげれば、結構能動的なヒトに変わっていくような気がするんですけどね。(もう5年も前の自分のところだけかな。。)

インドリさん、ありがとうございます。

　本当は使えないエンジニアを切り捨てて、その分人を入れて使えるエンジニアだ
け残す事が出来れば一番いいのですが、生島氏のコラムでもあったように解雇は容
易ではありません。時々、派遣先の偉い人に相談される事もあるのですがそれぐら
い人の採用と配置は難しいのだと思います。

　であるなら、コストを下げ、生産性を上げるしかないんですけど…。

> 次回のコラムも楽しみにしています。
> どんなコラムが来るかな♪

　なんかハードルが上がってる気がしますが、原稿自体は出来ているので公開され
た時はまた読んでやって下さいませ。

ビガーさん、ありがとうございます。

> どうやったら生産性って上がるのかを具体的に提示いただけると
> コラムの読者(私)としては、参考になるのでありがたいと感じました。

　基本的に意識付けだけを書いていたのでそう言われるとそうかな、とも思いま
す。生産性に関してはまた別の機会で書こうと考えています。

　エンジニアの作業分担が難しいと感じるのはスキルと性格でポジションが決めら
れない時だと思っています。クセの強いエンジニアでスキルが高い場合はそのまま
適当な権限範囲を与えてやれば生産性が上がりますが、逆にスキルが低いと文句ば
かり言って進みません。ある程度経験が長い人はそこに自負があるのでこっちが
「出来る」って言ってもラクしようと考えているのか「出来るわけないだろう！」
とか逆ギレする時があります。最近はわりと性格が尖った人が（私の周辺には）多
いので、管理してても苦労します。

　そういう意味では単純にスキルアップ＝生産性アップではないです。でも、スキ
ルアップしてくれないと生産性は上がらないと思っています。

　コスト意識はこれから必要だと認識しています。限られた利益の中で自分たちの
給料を維持したり上げるにはいかにコスト意識しながら生産性を上げるかですか
ら。今は仕事で原価管理もしているのですが、つくづく無駄が多いと実感します。

> 背中を見せてあげれば、結構能動的なヒトに変わっていくような気がするんですけどね

　私はもうそういう時代ではないと思っています。でも、次の次のコラムのネタ
（教育について）にもつながるので、また読んだら意見を聞かせて下さい。

にゃん太郎さん、おはようございます。

かぶってたんですね（苦笑）

私はフリータという言葉ができたころから5年もフリータでしたが、1円でももらったらプロと思ってたけどね。
なんというか、サラリーマンって自分をプロだとは思ってないらしい。

デスマになって終電で帰れるかどうかのときに、部長が「納品前なのに風邪で休む奴がいる、厳しくても体調管理をしっかりするように」と当たり前の話をしていたら、若造どもが「なんて酷い！」とか言い出す。

そいつらに「君ら受験のとき風邪ひいいたらあかんて言われへんかったか？」って聞くと、「入院するほど体調悪かったけど通りました」とか自慢しだす。

受験 ＞＞越えられない壁＞＞ プロジェクト

感覚的に理解できないのよね。

生島さん、ありがとうございます。

　世の中の情勢とあいまって、考える事が似通って来るのでしょうかね。100%同意
見でなくても同じような時期に同じようなテーマだと、ちょっと「やられた！」と
思ってしまいます。

　やってる途中は文句言うくせに、終わったら自慢しますよね。いつも苦々しく思
うのはプロジェクトが火を噴く原因を作った連中が終わってから「あれは大変だっ
たよなぁ」とか言ってる事です。責任取れとは（立場上）言いませんが、自覚しろ
よとは言いたいです。

　私も今はサラリーマンなので「ぬるま湯」って部分では非常に理解できます。極
端な話、仕事が進まなくても出勤していれば毎月給与は貰えます。自営と違い、労
働時間が報酬なのでなかなか「プロ」という自覚は芽生えないでしょう。だから総
フリー化した方が･･･と考えるんですが。

こんにちは。

コストを意識するエンジニアは少数だと思います。

デスマッチを除けば、ある程度効率落として残業代をもらった方が良いとい考える人が多いと思います。

そこをしっかりとコントロールできるマネージャーが居ると良いんですけどね。

こんにちは。お初にお目にかかります。

＞ヴァンさん
そんな危険な職場からは早く離れるべきです。>デスマッチ
って冗談は置いといて。

一時期、製造業に就職していたんですが、その職場では改善提案運動ってのがありました。
自分の担当する作業の改善をして報告書をだせば、１件５００円報酬が出るというものです。
（もちろん社内検査機関が審査して効果が大きいと判断されたら報酬金額が上がったり、
年間で多くの数を報告すれば表彰されたりしました。）

改善するためには、今自分が従事している作業へのより詳しい知識が必要になったり、
現状で満足せずに常に何か改善出来るところがないか探したりと、意識改革の一歩になりました

鼻先にニンジンをぶら下げるのも一つの手段になります。

こちらには、初めての投稿となります。
@ITコラムで問題になっている人月問題ですが、なんか違和感を覚えます。
It開発者に限らず、どの業界にもその道のプロ/職人はいます。[金　<　 自分の腕]という価値観かな。
そこに、「時間拘束型の労働形態」が導入されてから、意識変化が生じたようです。

開発業界限定でなく、労働界全般の問題だと考えてます。
今の「就職」は、職に就くのではなく、「入社」という名で会社に入ることを意味しています。
車掌に憧れてJRに入ったが、売店勤務になるとか。
車が好きで就職したのにハウジング部になったとか。
食品が好きで食品会社に入ったのに、システム開発部門に配属された
というケースもあります。その時点で、自分の持つ職人性と職場の不一致が生じます。

開発業界でも、根っから好きな職人肌の技術者は、自己研摩するので放置しても問題は少ない。
しかし、普通の職種と同一視して開発者になった人は、「成果」より「拘束時間」で考えます。
はじめから、プロ意識を持とうとしない/持つ気のない　サラリーマン技術者に　プロに徹せよというのは、構造上無理がありそう。
2/6/2 と言いますか、集団の 2割はプロ、 6割は、レールを走る労働者、2割は足を引っ張る人。という構図は、人間社会である以上、仕方がないと思う。
　長時間労働　は儲かるというのは、　スキルの人の単価を下げれば、解消する。
能力差に見合った単価設定できないのは、労働基準の問題です。今のままでは、怠慢サラリーマンに対して過保護過ぎる。
企業内失業者もかなりな数になり、コスト高になる大きな要因です。人件費をどこかで回収しないといけないので。
同一労働・同一賃金が正論に映る環境では、プロ不遇の時代だと考える。
どの業界でも、プロの技術度の評価眼力は、経営者層に必須だが、少ない。
　工場型生産の時代だと、それでも成長してたが、これからは,,,,,
　政権交代で淡い期待。

ヴァンさん、ありがとうございます。

> デスマッチを除けば、

　意外といい言葉かも。本当に生きるか死ぬかの戦いって感じで･･･すいません、取
りあえずツッコミは必要かと思いまして（笑）

　うーん、マネージャなのでコントロールしようと努力してますが、コスト意識を
させつつ生産性を上げるのは至難の業です。原価管理していくと･･･あぁ、涙が（苦笑）
サラリーマンだと特にそう言う部分ではペナルティ（給料が下がるなど）がな
いので「ま、いいか」となってしまうんでしょうね。

エンジニアとしてコストや利益を意識する必要性がある、と私も思います。
もう少し言うと、エンジニアだからではなく社会人として、と思えます。
自分たちの食いぶちは自分たちで稼げ、ですよね。

そして意識するようになって生産性の向上など、もっと色々な事を考え出すようになる。後はそのようにして生産性が上がった事に対して、何らかの評価が出ればいいのですが・・・。会社にもよるのでしょうが、中々に難しいと思います。

人月単価の問題点は多くの方が語られているので、私がさして口を出すところでもないのですが、現状としては「それ以外に納得させやすい方法論がない」という感じですよね。商品の価値に対価をつけることよりも、明確に判別できる時間を用いた方法の方が話をしやすいですし、何よりイメージしやすい。

作り手側としては人月単価以外でやりたくとも、ユーザー（発注）側としては難しいですよねぇ。

セロさん、はじめまして。ありがとうございます。

> 鼻先にニンジンをぶら下げるのも一つの手段になります。

　大手ではよくやってますよね（今は知りませんが、確かに大手メーカーに派遣で
行くとそう言う事をよく聞きました）中小のソフトウェア会社では、にんじんより
残業代の方が良さそうなので効果が出るかちょっと疑問です。

　生産性の向上って一種のモチベーションなので、職場全体（プロジェクトチーム
全体）でそういう雰囲気があれば自ずと出来るものだと思います。にんじんはきっ
かけかな。逆にそういう雰囲気がなければ高価なにんじんでもなかなか動き出しま
せん。今はコストがかかっても生産性が低くても給料は下がらないのでどうしたも
のかと。下げられれば良いのですが、普通は出来ないので難しいです。

AZさん、はじめまして。ありがとうございます。

　前にも書きましたが、労働基準法を始め法律的にはかなり労働者に対しては手厚
いと思います。特に経営者になり、社員を抱えるとそれを実感します。自分の計画
通りに社員が動かなくてなかなか売上げが上がらなくてもなかなかクビに出来ませ
んし。

　「解雇しやすく」というと社長が解雇を乱用する、と思うかも知れませんが実際
はそこまではないと思います。優秀な人材は当然解雇したくないですし、あまりや
り過ぎると反発を買って社員総退社になると会社自体が立ち行かなくなります。実
際、解雇したくなる社員は一部なのですが、それすら頑張っている社員と同じよう
に扱わなければならないと思うと結構やりきれません。コンビニのアルバイトもエ
ンジニアも同じような考え方で雇用するので、それは無理があると思います。

> 政権交代で淡い期待

　とにかくマニフェスト実行よりもいろいろな既得権益を破壊して欲しいです。

こんにちは。

環境の雰囲気や制度はとても重要だと感じます。

人月だとなんだかわからないコードを時間かけて作った方が給料が高く、さらに生活残業のためにダラダラと残ったりして、あっというまに仕上げてしまう方が嫌気さして態度不良になってよけい減給されてしまうというグチャグチャの状態が出来上がってしまいます。

コスト意識を持たせるには、自分の存在のためにいくら会社が使ってて、製造物の取引価格等を正確に伝達しておかないとわからりにくいですね。

特に末端のプログラマレベルではそのような事をあまり教えないし、本人も興味ないからあまり覚えようとしない･･･。

Ahfさん、ありがとうございます。

　おっしゃる通り、社会人としてコスト意識や自分の関わる仕事の生産性の向上を
考えるのは当然ですよね。お金は振ってきたり湧いてきたりする事はなく、限られ
た売上げからいかにコストを減らすかが重要だと思います。これはどんな業界でも
そうでしょう。

　とはいえ、エンジニアが時間で報酬をもらうのはちょっと違うんでしょうね、ほ
んとは。経済界がホワイトカラーエグゼンプションの導入（労働時間規制の免除）
なんかを模索するのも我々エンジニアの生産性があまり良くないからだと推測でき
ます。

　まぁ、コスト削減と生産性の向上は永遠のテーマなのでしょうか。民主党政権に
なったのでますます労働者側の方が強くなるのかもしれません。

ひろさん、ありがとうございます。

> 特に末端のプログラマレベルではそのような事をあまり教えないし、
> 本人も興味ないからあまり覚えようとしない・・・。

　確かにそうですよね。私は会社の財務状況を社員に開示する事は必要だと思いま
す。まぁ、あけすけにしてしまうと問題はありますが、せめてどれぐらい売上げが
あって、どのぐらい経費がかかって、どの程度社員の人件費や社会保険が掛かるか
ぐらいは良いと思います。給与明細にに書いておけば少しは意識するかも知れません。

　人月単価が100%悪とはいいませんが、やはりエンジニアのレベルや生産性を考慮
した評価システムはひつようなのかも知れません。

> ただ、人月単価が当たり前のこの業界では会社もエンジニアもコストに関しては無頓着になりがちです。エンジニアに至ってはコストよりもいかに時間を延ばして報酬を多く取るか、と間違った感覚でいますし、エンジニア派遣の会社ならなるべく多く残業してくれと考えがちです。
　ここ、本気でそう思われて、書かれているのでしょうか？
　派遣されている側も馬鹿ではありません。無為に時間を延ばしていると感じれば、契約更新しないでしょう。あるいは、チャージ アップに応じない、もしくは下げる交渉をするでしょう。特に、請負、受託開発していると、入ってくるお金は決まっています。それを超えるような残業はさせません。無い袖は振れないのですから。
　もちろん、エンジニア本人が、自分のコストを知ることが大事だと思います。以前の会社では、逆ザヤだったこともあり、強く意識させられていました。ところが、今の会社では、自分のコストを知りません。その結果、自分がかなり緩んでいると感じています。

> 例えば、総支給額で30万円だった場合...
　最低賃金が上がれば、こうした支出も増えるんですよねぇ。ホント、働いたことのない議員さんは、好きなこといいますねぇ。。。あ、民主党の支持基盤は労働組合か。やっぱり、自分のコストを知っていないから、自分の首を絞める結果に繋がることを要求できるのだろうか？

>人月単価が100%悪とはいいませんが、やはりエンジニアのレベルや生産性を考慮
>した評価システムはひつようなのかも知れません。

あれ？人月単価って、エンジニアの生産性を考慮しているんじゃないですか？
生産性の低い人達は単価安いですよね？
レベルってのはちと、わかりにくいんですが・・・生産性とは区別して評価するものですか？

正直、現実的なところで、生産性が低いほうが得をするような場面がわからないんですよ。
一時的に金を取れる可能性はありますが、次がないのではないかと・・・
いや、独占的な契約でやってるなら話は別ですが、それなら問題になることもないですよね？

人月単価問題って、こーなんか都市伝説のような感じがするんですよｗ
でもって、次にくるのが作ったものの価値で価格設定するような話なんだよなぁ(^^;
少なくとも、ソフトウェア産業でそのようなことをするのは難しい・・・というか無理？
人によって価値観が違いすぎるし、原価も違いすぎる(^^;
悪気のない優秀なフリーウェアの存在が話をさらにややこしくするｗ

結局、他の業種と同じように、作業時間に対する報酬に落ち着くような気がします。

人月単価の問題点については前世紀から言われているに、まだこんな事を言う人が居るとは・・・
人月単価が生産性と正比例していない事は前世紀で既に証明されています。
人月単価が生産性と正比例しているのであれば、そもそも問題だと認識すらされないでしょう。
また、そんな素敵な計算式ならば見習う業界も出ているでしょう。

人数　＊　単価　＝　価格

この単純な計算式に品質とか生産性を加味する善良な経営者なんて殆ど居ません。
「うち会社は慈善事業はしない」といわれるのが落ちです。
利益を算出する計算式にないものを加味するほど善良な人はそう多くないのです。

Jittaさん、ありがとうございます。

　本気かと聞かれれば本気です。ただ、私の感じる傾向からの話ですが。当然、絶
対と言うかすべてではないのは多分わかっていらっしゃるとは思いますけど。生産
性が良いエンジニアはまわりからずれると逆に「仕事が少ないのか」「仕事が簡単
なのか」と思われがちな側面があります。本当の請け負いならおっしゃる通り入っ
てくるお金は決まっているのでちょっと事情は異なります。無い袖が振れない時は
「サービス残業」が待っているだけです。前にも書きましたが、エンジニア自身が
コストを負担する事になります。

　今の会社の上の方にいる人は昔のがむしゃらに頑張った時期を経験している人が
多いのか、現場では今でもその名残を引きずっています。また、会社が大きくなれ
ばなるほど例えば派遣の受け入れなら現場と人事（総務）が別なのでコストと生産
性のギャップがあっても現場優先になります。

　どのみち、今までの考え方では少しずつ破綻していくと思います。

Ｓｏｄａさん、ありがとうございます。

　契約って普通仕事に掛かる前に結ぶのでそこに生産性は考慮していないと思いま
す。せいぜい履歴書（職務経歴書）から経験とスキルを考慮する程度でしょう。そ
こにはせいぜい予定していた仕事がこなせる程度かどうかぐらいの考慮しかありま
せん。

　一般的な契約の方法がおそらく月160時間プラスマイナス20時間、それ以下はマ
イナス、それ以上はプラスというのが多いと思います。だったら単純に同じ仕事を
こなすのに160時間で出来る人と200時間掛かる人ではどうなるかわかりますよね？
日本ではホワイトカラーエグゼンプションは導入されていないので基本的に残業代
を払わないのは労働基準法違反になります。そこに残業した方が「頑張った」よう
に見える昔からの慣習によって結局生産性が低い方が得をする、結果になります。
次があるかないかは生産性の高い/低いに関わらず、元請けの会社の景気次第です。
人を探す手間を考えればよほど使えない人以外の契約解除は少ないと思います。

　フリーウェアやオープンソースなんかは基本的に職業エンジニアの首を絞めてい
ると思います（ここでは良い/悪いではなく、単に状況だけ）ソフトウェアの価値に
関しては前に書いていますが、確かに難しいと思います。無理だとは思いません
が、基準が統一できない点においてはおっしゃる通り無理でしょう。金額的にも技
術的にも素人でもちょっと本を買って勉強すればコードが書けて簡単なシステムな
ら組める時代です。職業エンジニアが生き残るのにはスキルアップは勿論ですが、
品質と生産性を上げなければ差別化は出来ません。これだけ厳しい経済状況でこ
そ、少し企業も意識を変えられるチャンスかな、という気はします。

>インドリさん
>人数　＊　単価　＝　価格

えーと、月（時間）をかけ忘れてるのは置いておいて・・・
そのー単価こそが、生産性じゃないんですか？
生産性が高ければ高いほど、単価は高く、低ければ低いほど単価は安くなるのが人月単価でしょ？

>この単純な計算式に品質とか生産性を加味する善良な経営者なんて殆ど居ません。

品質はともかく生産性は考えないと原価割れしちゃうじゃないですか？

>「うち会社は慈善事業はしない」といわれるのが落ちです。
>利益を算出する計算式にないものを加味するほど善良な人はそう多くないのです。

慈善事業をしないということは、利益を得ているわけですよね？
自社の生産力を無視して利益を得ることは不可能だと思うのですよ。
また、最終的な価格を決定するのに、利益を計算しないことも無いと思います。
しかし、直前の文章で生産性を考慮していないと書かれている。
矛盾しているように思えるのですが・・・どう読み取れば良いのでしょうか？(^^;

最後の文が一番わからないのですが・・・主語というか、どの言葉がどこにかかっているのか(^^;
どこで文を区切っていいのかも・・・ちょっと(^^;

>にゃん太郎さん
>契約って普通仕事に掛かる前に結ぶのでそこに生産性は考慮していないと思います。

えーーー、考慮するでしょ？
考慮しなければ見積もりは出せないですよね？
でもって、人月単価って受注する側が自社の生産性を考慮して２次的に算出するものでしょ？

人月単価を問題視する方々の一部では、人月単価は発注する側で固定しているような説明をされるんですが・・・
仕事請けるときに、自社の生産性を考慮し、どれぐらいの日数で完成できるかって考えますよね？
つまり、これが原価の大部分になると思うのですが・・・

うーーん、なにかがズレてるんですかね(^^;
インドリさんの式も、違和感を感じるんですよ。
私が考える人月単価って

受注希望金額÷人数÷時間＝人月単価

おおざっぱには、こんなイメージです。
自社の生産力から考えた原価に利益やリスク分をのせた金額が受注希望金額だと考えます。
これが一番最初。
この受注希望金額をお客にわかりやすくするために生み出された、仮想的な内訳が「人月単価」だと考えています。
だから、インドリさんの式のように掛け算で受注希望金額を算出するようなものでは無いと思ってます。

私は、上記理由で「人月単価」には生産性が考慮されてると考えています。
間違っている部分があれば、指摘していただけるとズレが修正されると思いますが、どうでしょう？

>日本ではホワイトカラーエグゼンプションは導入されていないので基本的に残業代
>を払わないのは労働基準法違反になります。

にゃん太郎さんのコメントを読むと、労働者に支払う給料が時給ベースで支払われることへの不満であると読めます。
残業って給料ですよね？
その話と、見積もりで使われるような「人月単価」は別の話じゃないですか？
少なくとも、この不景気に意味もなくダラダラと残業やるような駄目社員は、ソフトウェア産業とは無関係な話だと思います。
時給ベースならどこにでもある話ですよね？

>次があるかないかは生産性の高い/低いに関わらず、元請けの会社の景気次第です。

いいえ、別の会社が安く早く同じ仕事ができるならば、そちらに頼むと思いますよ。
例外があるとしたら、その会社でしかできない仕事の時だけじゃないですか？
不景気だからこそ、より安いところを必死で探すんじゃないですか？

>職業エンジニアが生き残るのにはスキルアップは勿論ですが、
>品質と生産性を上げなければ差別化は出来ません。

個人的には、専門性のほうが重要だと思います。
品質やら生産性の平均値はどんどん上がりますよ。
それらは、できて当たり前であり、選択基準にすらならなくなるのではないですか？
それよりも、その会社でしかできない、その人でしかできないという技術のほうが生き残れると思います。

人月単価が生産性を加味しているというのであれば、
具体的にどの様にして単価に反映しているのか説明して下さい。
これが正しく行われていない事は常識でしょうに・・・
分かっていないという事は、プロジェクトマネージメント系の学習をしていませんね。
プロジェクトマネージメント系の学習をした事がある人や、実地した人ならば人月単価に能力を正確に反映出来ないorしていない事なんて常識です。
それにＳｏｄａさんは恐らく契約に参加したこと無いと思います。
契約に関わったものならばにゃん太郎さんの説明で十分に分かるはずです。
契約前に能力を測定して単価を算出しているなんて事ありえません。
どうやって、技術者の能力を数値化するのでしょうか？
もしあるのであれば、人月単価とセットで有名になっているはずです。
私はそんな夢の計算法を聞いたことがありません。
あればここまでこの業界は駄目になっていません。

>インドリさん
>具体的にどの様にして単価に反映しているのか説明して下さい。

開発担当者に何日ぐらいで作れるか直接聞きますが・・・
それを元に受注希望金額を算出し、逆算で単価を出すような感じですかね。

逆にお聞きしますが、インドリさんは、単価をどのように算出しているのですか？

>分かっていないという事は、プロジェクトマネージメント系の学習をしていませんね。

実体験しかないですね、わざわざ学習なんてものはしてませんし、する必要性がなかったですね。
私が、プロジェクトマネージメントの学習（実際にどんなことかすらわかりませんが）をしているかどうかはこの際関係ないですよね？
私は、私の考えを先に提示してあります。
具体的にどこが間違っているのか指摘してもらったほうが、よくわかるのですが・・・
基本的な概念として、私が提示した「人月単価」は間違っているのでしょうか？

>それにＳｏｄａさんは恐らく契約に参加したこと無いと思います。

この場合、契約というのは、見積もりを出すということですよね？
見積もりならば何度も出してますが・・・

>契約前に能力を測定して単価を算出しているなんて事ありえません。

うーん、この契約というと、人を雇うということでしょうか？
そのー根本的なことなんですがーどういう状況のお話でしょうか？
人を雇うときには「人月単価」はでてこないと思うのですが・・・でるのですか？
この場合は、労働報酬になると思うのですが・・・それも「人月単価」と呼ばれているのですか？

私は、「「人月単価」では生産性の低い者ほど利益が得られる」ということが真だとは思えないのですよ。
これが真ならば、全てのソフトウェア会社は大金持ちでしょ？
もしくは、物凄い技術者しかいないことになるじゃないですか？
こんなことは現実には無いと思っています。

だけど、インドリさんや、にゃん太郎さんは真だと言っているじゃないですか？
この矛盾を解きたいだけですよ。

ＰＳ．
先のコメントの解説を先にしていただけると、ありがたいのですが・・・

また、人月単価論ですか、
技術者のスキル面の話と、会社経営上の収支の話が混在するから、矛盾点に見えるだけと思えて来ました。
確かに、技術者仲間で、「なんで俺の単価が彼奴と同じなんだ」といった不満はあります。生産性も明白に違う事もあります。
知識習得にはコストが、掛かります。短時間で作成する人は、先行投資されているので、単価が高くなるのは当然です。
さて、能力差が人月単価に反映できたら、解決するのでしょうか。
　プロジェクト・メンバーは各々スキルレベルは違います。で、見積書に
a1氏 @xxx万円 * n月
a2氏 @xxx万円 * n月
a3氏 @xxx万円 * n月
::::

という見積もりが出せると思いますか? 出せないでしょう。
SE @xxxx万円 * n月
PG @xxxx万円 * n月
計 xxxxx万円............... となるのは、仕方のない事でしょう。

そこで、考慮しなくてならないのは、危険率です。顧客の質によって、納品後の調整作業に差がでます。
サーべイの時に問題点を洗い出せる顧客の時は、調整作業は少ないです。
でも、納品後、「不具合だから直せ」といってくる顧客も多いです。「打ち合わせのときは、見えなかった。使い始め見えてきた。」
これは、SEの分析力の責任もりますが、顧客の業務説明を怠慢した面もあります。
　そういった、後出しクレームの多いと予想される顧客の危険率を高く設定して、標準見積額* 危険率で見積もります。
長年商売をしていると、危険率も一定してきて、この顧客は、「サーベイ時の予想工数* 1.5でとんとんだな」というのが見えてきます。
こういった事は、、技術品質では計測できないと考えてます。
　ですので、人月単価に拘って、延々と論議しても、見積もり他の要素で決まると思います。
低スキル者は低単価にすれば、いいだけの話です。
ましてや、長時間労働が収益に寄与することなんて、あるはずもないです。デスマは受注者が赤を被るだけです。

ご返答、ありがとうございます。

> 当然、絶対と言うかすべてではないのは多分わかっていらっしゃるとは思いますけど。
　はい、分かっています。が、コラムという性質上、書かねばならないかと思います。自分が知っている（nealy equal 経験した）範囲について批評を行うのか、自分が調べた範囲について批評を行うのか。これは、区別しなければならないこと、個人が内輪で雑談をしているわけではないので、書かなければならないことかと思います。

> どのみち、今までの考え方では少しずつ破綻していくと思います。
　同意。ただ、その為には、誰もが納得できる or 簡単に比較できる、代わりとなる単位を出さなければなりません。
　今、人月が料金の単位として通用するのは、生活インフラを始め、様々なものが月単位で料金を徴収されるからではないでしょうか。水道（2ヶ月ごとだけど）、ガス、電気、駐車場、家賃、塾、習い事、税金（数期に分けてだけど）、など。1ヶ月にかかる費用がおおよそ決まっており、その費用をまかなえるだけの収入が無ければ生活できません。
　働く人がいなくなれば（生活できなくて、以下略なので）企業は成り立ちませんから、最低限の生活ができる賃金を保障しなければなりません。それが、最低賃金法ですね。ここで時間単位の最低賃金が決まっているので、月単位の賃金は、とても計算しやすく、比較しやすい事になります。
　人月計算は、「人数×単価」などという単純なものではなく、実質的な単価は個人によって異なります。しかし、場合によっては均されます。この、「場合によっては均される」というのが問題なのであって、人月単価が問題なのではないと思います。
　つまり、実質的な単価が個人によって異なっているというのは、企業であれば査定など個人の能力が測られて、反映されているということです。もちろん、最初は皆同じですが、同じといっても学歴による差はあります。派遣であっても、個別にチャージ料が異なります。決してどこもかしこも同一の料金なわけではありません（同一だったら、そもそもｎ次請けなんてならない）。ただ、会社として対外的に提示するときに、実際には誰が担当するか分からないし、内部的な単価の違いを社外には説明できないから、単一の料金を示す。もし、他の単位が導入されたとしても、やはり均された単価が使われるでしょう。そうすると、今「人月単価は問題だ」といっているのと同じ事が発生するのではないでしょうか。
　このことから、本質的な問題は人月単価ではなく、「個々人の単価を用いず、平均単価を用いること」ではないかと思います。

　そうそう。『ソフトウェア見積り』（ http://www.amazon.co.jp/dp/489100522X ）という本の最初に次のような話が出てきます。ある会場で、「入場者の数を見積もってください」といわれます。一人目は、会場を見渡して、「おおよそ何人」と答えます。二人目は、「ほとんどの机は3人ずつ座っているので、３×机の数で何人」と答えます。三人目は、しばらく席を外し、「受付のカウンターを集計してきました。何人です」と答えます。さて、より正確な「見積もり」をしたのは、何人目でしょう？
　正確な見積もりは、観測することで得られます。観測データがない場合、過去の事例から似たものを引いてくることになります。フリーのエンジニアを雇うときは、本人がどんなに「私は高価値だ」といっても、観測データがないのでその人に対する正しい見積もりは出来ません。過去の似た事例から引いてくるだけです。つまり、「均された単価」が使われているわけです。もっとも、狭い範囲であっても「優秀である」と評判のエンジニアであれば、異なるかもしれません。
　私は、サラリーマンとしての立場から、このように考えます。特に、「実際には誰がやるか分からないので均された単価が使われる」というのは、フリーな方には出てこない発想かもしれません。

> だったら単純に同じ仕事をこなすのに160時間で出来る人と200時間掛かる人ではどうなるかわかりますよね？
　これは、生島さんが、人売りと評していることですよね？Ｓｏｄａさんがおっしゃっているのは、私が「実質的な単価は個人によって違う」と書いたことが前提ではないかと思います。
　また、ある人…ある会社は「160時間かかる」と見積もり、ある会社は「200時間かかる」と見積もるなら、160時間で仕上げるという方に発注するでしょう。ここで、160時間を100万円という会社と、200時間を90万円という会社があったとき、どちらに発注するかは、迷うところではありますが。
　つまり、他社と比較することで是正されますよね。政治的な理由があるなら別ですが、「だらだらやる方が得」なんて事にはならないのではないでしょうか。
　しかし、だらだらやる方が儲かることもあります。それは、成果物が定められておらず、費やした時間が成果物とされているときです。ここでの問題は、「成果物を時間とする」ことであって、「一人が一月働くことで発生する費用を単価とする」こととは異なるのではないでしょうか。普通は、だらだらやることがないように、先に見積もりをして、見積もった作業期間内で終わるようにするのではないでしょうか。

みなさま、ありがとうございます。

　ここまで議論が白熱するとも思っていなかったのでちょっとびっくりしていま
す。最初に本コラムの主旨ですが、「エンジニアひとりひとりがコストを意識して
生産性を上げるように努力して、少しでも利益率をあげましょう」です。例によっ
て人月単価の是非だけを書いたつもりはあまりありませんが、結果として絡むので
書いてありますが。まぁ、お金の話になるとどうしても出てきてしまいますね。

　個人的に人月単価を100%否定はしませんし、これ自体悪い事ではないと思ってい
ます。ただ、単純な図式ゆえの弊害は多々あります。

　日本の企業論理では大企業になればなるほど「安いから他社」とはなりにくい現
状があります。実際、個人の生活では同じ物なら安い所で買うとなりますが、企業
の場合は仕入れを安いだけで決めてしまうと何かあったとき（事故など）に大ダメ
ージを受けてしまいますので、会社としての実績、信用度などスキル以外の部分も
重要になってきます。ですから安い他社に乗り換えるのではなく、下請けいじめと
言われるような従来の取引先に単価を引き下げるよう要求する事が多くなります。

　実際、私が会社を経営していた時に某大手企業の仕事を請けるに当たり信用調査
会社がやって来てあれこれ調べて行きました（内容的には決算書の提出と役員のイ
ンタビューかな）安すぎても高すぎても不信感を持たれます。これは経営者でない
と分かりづらいかも知れません。今は会社の資本金に制限はありませんが、当時は
有限会社は300万円、株式会社は1000万円必要でしたので、仕事を取るために無理
して増資して有限会社から株式会社にしました。

　現状ではおそらくAZさんのおっしゃる事が一番近いと私は思います。

　常々コラムにも書いていますが、一番の問題が「エンジニアの性能を測る基準が
ない」事だと考えています。請負なら見積時にメンバーがアサインされている事は
まずなく（予定はあっても）予想される構成でするため、そこの中での単価となり
ます。決まらなくて外部からも構成予定があればその分上乗せするでしょう。生産
性だけに限って言えば考慮するのは「最悪の場合」であり、一番良い状態での仮説
は危険なだけにまずしないと思います。

　現状のようにシステムが複雑になってくると、それも仕方ないとは思います。上
流工程で業務のヒアリングがうまくいかず、製造工程でいろいろな問題が発覚する
事も昔よりは多いと思います。エンジニアのスキルが低いと言うよりはエンジニア
に求められるスキルが高くなっているでしょう。

　技術者の派遣では、派遣する側が自由に単価を決められる事はなく、やはり派遣
される側の方が強いです。これも会社にネームバリューや付加価値がないと非常に
厳しいです。この場合は逆にスキルの高い生産性の良いエンジニアを派遣しないと
利益率が上がりません。でも、単価はスキルが低い人と変わりないでしょう。

　経営者やフリーの方が危機感を持っているのは、一度契約した企業で安くやって
しまうとそのままずーっと安くやる事になってしまう事でしょう。そこには生産性
もスキルの高さも関係ありません。「次から高くしたい」と言えば切られてしまう
可能性も高いですし、相手方から「おたくはスキルが高くて品質の高い物を短期間
に作れるから今度は単価を上げましょう」なんて言ってくれる会社はおそらくどこ
にもないです。逆に短期間で仕上げると「じゃあ、次はもうちょっと安くてもいい
よね？」なんて言われかねません。ですから会社はどこで安くしてどこで利益を上
げるかを考える訳です。

　インドリさんの意見は間違いなく経験則の話なので私も同意出来る考え方です。
書き方は少し極端だとは思いますが。

　「人月単価は仕方ない」「生産性も考慮している」と考えているのはどちらかと
言えば間接的に報酬をもらっているサラリーマンの方だと思います。フリーでやっ
てみると現状ではスキルアップは必要でも、生産性を上げる事が（報酬を上げると
言う意味においては）無駄な事は分かると思います。冗談抜きでキレイ事では生き
て行けませんから、死活問題なのです。

　もっとも、問題点の提起をしても「では、どうすればいい？」という部分は難し
いですね。ただ、ビガーさんの指摘にもありましたが、具体的な話も必要だとは考
えていますので、みなさまの意見を参考にしばらくしたらまた生産性や人月単価の
話を書きたいと思います。

　いろいろなご意見、ありがとうございました。

にゃん太郎さんへ
にゃん太郎さんの場合既に知っている可能性大ですが、何も言わないのも無責任かと思って書きます。
人月単価と生産性の続きを書く時、開発モデルに注目すればいいと思います。
人月単価はウォーターフォール・モデルゆえと因果関係があると思われます。
しかし昨今はアジャイル開発が考え出されました。
その結果アジャイルな見積もりが可能となっております。
ソフトウェア開発は事前に全ての仕様が決定する事なんてありえません。
ですから見積もり精度も自然と悪くなります。
だけど、アジャイルに段階的に見積もりをすればどうなるでしょうか？
そういった事が昨今では熟考されておりますので、次回書く時アジャイルと見積もりを参考にして下さい。

アジャイルを見積の根拠にするのは、主客転倒です。
ウォーターフォールやスパイラルといった手法の一つであり、効果が大きいのは事実です。
でも「見積」とは、顧客要件を満たすための開発手法です。
家を作る時に、プレハブで作ろうと、電気工具で作ろうと、現場で大工さんの手作業で作ろうと、関係ありません。
現場監督の監督手法が xxx法、yyy法、であっても、それは現場作業の効率化の話で、発注者とは無縁です。
粗利を算出して、アジャイル要員をアサインできるか、要員計画の話です。
顧客要件を満たす範囲で、廉価な開発手法を取るのは当然です。
「高価な開発手法で作ったので、高く請求できる」と考えるのは、「だらだら長時間開発して、要した時間を請求てきる。」と考えるのと同様で、間違った思考です。適切な利益を頂くのが商売です。
不要なサービスを付けて高くしたり、不要に長引かせて多額請求するのは、おかしいです。
人月単価制で適正な商売が成立しています。一部の業者か悪用している現象を指して「人月単価は悪」とするのは、
「手を切ったり、他人を傷つけたりするので、家庭から包丁をなくせ」と主張しているようにしか聞こえません。

Jittaさんが書いているように、「平均単価」で算出するしか、方法はないのです。
当然、個々でみると、差異が生じて、不公平が生じます。しかし、呉越同舟・大同小異で、小さな不公平には、目を瞑って大局的に利益が出るようにするのが「経営判断」です。
「人月単価」問題をは開発者目線だけで見ると、問題の本質を見失います。特にフリー要素の強い、技術者には、技術視点以外の視点が必要だと思います。

＞にゃん太郎さん
>「おたくはスキルが高くて品質の高い物を短期間に作れるから今度は単価を上げましょう」なんて言ってくれる会社はおそらくどこにもないです。逆に短期間で仕上げると「じゃあ、次はもうちょっと安くてもいいよね？」なんて言われかねません。

代わりに会社の評判が上がって依頼される仕事量が増えて結果利益が上がるってのは甘い考えですかね？

セロさん、ありがとうございます。

> 代わりに会社の評判が上がって依頼される仕事量が増えて結果利益が
> 上がるってのは甘い考えですかね？

　単価が変わらず仕事が増えると利益は増えますが、利益率は変わりませんよね。
ただ、私の経験上、ねぎらいやお褒めの言葉は社交辞令なので単価アップには繋が
らないと思います。よっぽど人なり会社なりがいなければ回っていかない状況にな
らないと「文句があるなら他に差し替える」というのが企業のスタンスでしょうから。

Axさんは開発モデルと見積もりの関連性に気付いておられないようですね。
これかなり関連性が強いのですが・・・
どの様に製品を開発するのかという事は、経費と利益に密接に結びついた話題ですので関係ないということはございません。
ソフトウェア開発は実のところ全ての見通しがつかないので、正確な見積もりが出来ないのです。
出来るのであれば失敗プロジェクトなんて存在しません。
特にウォーターフロール・モデルでは、上から下へと流れる様に進められますので、仕様の変更を考慮したものではなく、ドメイン分析が完璧である事を前提としたモデルであります。
しかし仕様に変更が生じない開発プロジェクトなんて現実には存在しません。
そこを勘で進めているのでこの業界は駄目なのです。
経験といえば聞こえはいいのですが、要するに丼勘定で見積もっているというだけなのです。
その観点から言いますと、人月単価は丼勘定を見栄えよくしただけのものともいえるでしょう。
一方仕様変更に強いのがアジャイル開発です。
アジャイル開発では、見積もりが細かい単位で行われますので、より高い精度で見積もりが出来ます。
すなわち、細かく随時契約をしていく事になります。
丼勘定で見積もりをするのと、細かく見積もりをするのとどちらが合理的なのかはひを見るより明らかです。
Axさんはアジャイル開発を学習せずに、「どうせスパイラルとかと一緒だ」と高をくくっていませんか？
スパイラルとかプロトタイプと同じという先入観からアジャイルをちゃんと学習しない人が多いんですよね・・・
ちゃんとソフトウェア工学を学習していれば、開発モデルと見積もりの関連性に気付き、アジャイル開発もちゃんと学習していれば見積もりが細かく出来る事がわかると思います。
先入観で判断するのは危険ですよ。

利益率が変えられないなら、薄利多売方式に転換すればいいのに、と思った次第で。
>一度契約した企業で安くやってしまうとそのままずーっと安くやる事になってしまう事でしょう。そこには生産性もスキルの高さも関係ありません。
生産性が上がれば時間に余裕ができるよなあ、と。
じゃ、空いた時間で別の仕事を受注すれば儲かるよなあ、という単純な思考でした。

セロさんとにゃん太郎さんの会話に人月単価と生産性の本質が凝縮されていると思います。
普通の商売は回転率で勝負します。
早く作って多くのお客様に売れば儲かりますよね。
しかし人月単価は、人数　＊　時間（単位：月）＊　単価（適当）　=　価格
なので早く生産する意義も能力が高い人が参加する意義も無いのです。
それ故に生産性が低くなります。
すなわちこの計算式は、普通に商売をする事を放棄しているといっても過言ではありません。
その計算式を死守しているこの業界の生産性が低いのは当然の結果です。

>人数　＊　時間（単位：月）＊　単価（適当）　=　価格
であるならば生産性向上によって時間を短くできる。
よって価格が安くなり、同業他社より仕事が受注しやすくなるかと。

>なので早く生産する意義も能力が高い人が参加する意義も無いのです。
ってことは無いと思うのですが。

>Axさんは開発モデルと見積もりの関連性に気付いておられないようですね。
Axとは俺のことかとAz聞き。

アジャイルに関して、無知でもなければ、否定もしません。適切な手法の一つと認識しているだけです。
アジャイルで工数を導き出すことが可能だとして、各個人の能力差をどのようにカバーするのでしょう。個人の能力評価という面で、人月単価と同類の壁にブチたるのですが。この点は、ここまで。

開発業界は建築業界と比較されがちですが、根本的な違いがあります。
ビルや家を作るときの見積もりは、積算で求めますが、見積もり段階で、使用部材と工事工数が確定するから積算できるのです。
ダムや鉄道などの土木工事は、当初予算と完成時の決算ではその差が大きく、昨今話題の xxxダムは当初予算が 1500億円だったのが 3300億円になったとか。
なぜそうなるか。計画つまり見積もり段階では、考慮されなかった事態が多発するからです。出水や湧水、軟弱地盤etc
システム開発にも言えますよね。開発に着手したら予想しなかった事案が発生したり、技術的に困難な設計があったり、要求変更、追加があったりします。
開発業界は土木業界に近いと言えます。

「アジャイル手法を適用すれば、コーディング開発時に確実な工数が算出できる」としましょう。
顧客から xxxシステムを作ってくれと依頼されてた場合。作業工数確定まで、どれ位の日数を要します?
作成物を洗い出すには、要望をサーベイして開発内容を洗いだすには相当に日数がかかります。
仮にそれに2か月かかったとしましょう。その見積もりした人の月給が50円だとします。
アジャイル見積もりに100万円のコストか掛かります。　見積額が 1000万円だったとします。
顧客の予算は 500万円だったら、どうします。しかも、に提示するのに 2ヵ月も費やして。
「高いから止める」となる可能性が大です。見積もりに費やした 100万円を請求するつもりですか。できないでしょう。
100万円の赤を蒙ります。
それよりか、初期に、このシステムなら 8人月*@100万 = 800万円という概算見積もりを提示し、予算に合わないことを明確化したほうが、互いに幸せになれます。

主張したいことは、どんな開発方法でも、製造段階までサーベイが進めば、誤差の少ない見積もりができますが、それでは、時期的に困るのです。
正確な値よりも概算を出すことが商談では重要になることを知ってください。

>であるならば生産性向上によって時間を短くできる。
よって価格が安くなり、同業他社より仕事が受注しやすくなるかと。

いえいえ。そこには落とし穴が存在します。
というのも、多重請負構造になっておりますので、にゃん太郎さんが仰っていた問題が浮上します。
つまり、上からの圧力によって価格が強制されるので、如何にして最低ラインを死守するかという問題が発生するのです。
仮に一人の技術者に仕事してもらって、

1人　*　3ヶ月　*　100万円　=　300万円

の破格の価格にして受注したとしても、一生その価格で受注しなくてはならない羽目になりかねません。
という事は・・・

一、その人が退社したらどうするのか？
一、他の人の人件費はどうやって賄うのか？
一、その他もろもろの経費はどうやって算出するのか？

という経営面の問題が発生します。
それを防ぐには、適度に駄目な人をある程度揃えて、一部のプロを配置することになり、小数の技術者に過剰な負担を強いる結果になります。
そうすると、優秀な技術者ほど辞めてしまい・・・と負のスパイラルに陥ります。
問題の根源は「会社としての適切な価格を算出できない」事と、「多くの人が開発時のコストに無関心である」事です。
それをこのコラムは指摘していると思います。

おっと失礼間違えました。
AZさんは会社の会計と開発工程をよくご存じないようですね。
丼勘定で不正確な見積もりを立てると会社にとっては大打撃なのです。
仕様変更などが生じれば、場合によってはただ働きという事になります。
AZさんは受注の事ばかり考えておりますが、その後の事も考えないと経営は成り立ちませんよ。
それに、受注の時に関しても、あやふやなままお客様に発注させるのでは、顧客満足度を下げる結果になります。
先をよく考えましょう。

正確な見積もりを出すのに2か月要して、受注できなかったときの、処理を教えてください。
仕事は、見積もりすれば、確実に受注できるものではありません。　　5件見積もり提出して、1件受注できれば御の字です。
ましてや、見積費用を請求できる業界ではありません。
つまり、4 件の見積もり作業は、無収入になります。1件の見積もり費用が　100万円だと800万円になります。
概算見積もりで商談をすすめ、設計段階で、予算との乖離がでたら、別途協議する。(仕様削減も含めて)という契約を結びます。
　つまり、予算に合わせて、作業員を調達するわけです。決して作業員の積算で請求するのではありません。
　議論の時間軸とタイミング゛が逆なのです。概算だから、平均人月単価 * 予想工数 が成立し、結果的に差異が小さくなります。
それでも乖離が生じるので、正確な工数は誰にも、どんな手法でも算出することはできません。

インドリさん

>Axさんは開発モデルと見積もりの関連性に気付いておられないようですね。
>AZさんは会社の会計と開発工程をよくご存じないようですね。

貴方の悪い癖です。
・相手の名前を間違う。
・自分と意見が違うと相手の否定から入る。

きちんとした議論をしたいのなら治しましょうよ。
今回(?)はなかなか面白いコラムなので、そこがちょっと残念です。

> 最初に本コラムの主旨ですが、「エンジニアひとりひとりがコストを意識して
> 生産性を上げるように努力して、少しでも利益率をあげましょう」です。
　なるほど。で、あれば、ここに突っ込みを入れます。
↓
> 　ただ、人月単価が当たり前のこの業界では会社もエンジニアもコストに関しては無頓着になりがちです。
　そうでしょうか。成果によって報酬が得られる方式になれば（成果が出来上がる前はどうなるんだろう？）、コストを意識するでしょうか。私は、違うと思います。コストを知らせていない（知っていない／知ろうとしない）ことが、コストに関して無頓着になる原因ではないでしょうか。
　「おまえが1時間働くとx円消費するんだ。」と、知らされている／知っているエンジニアが何人いるでしょうか。これ、わんくま勉強会でアンケートをしたことがあるのですが、30人ほどの参加者のうち、10人に満たなかったと記憶しています。残念ながら、ビデオ撮りしていない回なので、記録は残っていませんが。
（ 資料はここ http://www.wankuma.com/seminar/20071124osaka15/Default.aspx 12枚目のシート）
　「おまえが1時間働くとx円消費するんだ。」とは知らされず、「俺が1時間働くとy円になる。」という事は知っている。これが、コストに関して無頓着になる原因ではないでしょうか。
　経営者であれば、「一人これだけのコストがかかるから、それ以上の単価を付けないと利益が出ない」と考えるのは当然かと思います。しかし、労働者側からすると、労働者が払っているコストは自分の時間であり、労働力です。自分が払ったコスト＝時間に対して報酬を得るのは当然です。これに対して、会社経営という視点でのコストを知らせるのは、経営者（側の人間）の仕事だと思います。

> エンジニアに至ってはコストよりもいかに時間を延ばして報酬を多く取るか
　これはどうでしょう？不当に長く時間をかければ、評価が下がります。短期的にはいいかもしれませんが、中長期的には逆効果です。評定の時に、なぜそのような評価になったか、知らされると思います。ん？経営者であった時、そういうことを考えていらっしゃらなかったのでしょうか？
　また、コストを知れば、残業をしながら短期間で仕上げると、利益が出ることが分かるでしょう。もっとも、そうすると見積もりを多めにとるようになるのですが、そこは過去の実績から待ったをかけるのが上司の役目かと思います。このあたりは、生島さんの言われる「上流が技術を磨くこと」（ http://el.jibun.atmarkit.co.jp/g1sys/2009/08/post-ae94.html ）に繋がるところだと思います。生島さんは、請負関係の上流を指していらっしゃると読み取っていますが、指揮系統の上流も、当然技術を磨いておいてしかりだと思います。
　EV 図を出すと、コストを意識するんですよね。今いくら使ったのか。それに対していくらの成果物ができているか、見えますから。ただ、AZさんが書かれているように、途中で予想外のことが発生する。その時のコストをどう EV 図に反映するか。MS-Project では、当初から予想外込みの図になってしまいます。そこをなんとかしたのですけどね。

AZさんへ

>正確な見積もりを出すのに2か月要して、受注できなかったときの、処理を教えてください。

その様な事態を防ぐために細かく見積もりした方がいいと言っているわけです。
それと、AZさんは正確な見積もりが出来ないと放棄しているようですが、そんな事では経営は成り立ちません。
それこそこの業界に明日はありません。

ヴァン さんへ
>・自分と意見が違うと相手の否定から入る。
ソフトウェア工学などを踏まえていないから注意したまでです。
見積もりが出来ない＝考えないから人月単価でもいいというのは無茶な理論です。
技術者として黙ってられません。
ヴァン さんはちゃんとやり取りを見ていますか？

Jittaさんへ
>　そうでしょうか。成果によって報酬が得られる方式になれば（成果が出来上がる前はどうなるんだろう？）、コストを意識するでしょうか。私は、違うと思います。コストを知らせていない（知っていない／知ろうとしない）ことが、コストに関して無頓着になる原因ではないでしょうか。

見るに見かねていいますが、理論展開が無茶です。
成果によって報酬が得られる方式にするのであれば、当然労働者のコストを経営者は知らせるでしょう。
そうしない理由が思いつきません。

>これはどうでしょう？不当に長く時間をかければ、評価が下がります。

あとこれも・・・
残業すれば評価される職場が存在します。
それに、仮にJittaさんが言うようにちゃんと評価されているのであれば、そもそも労働者はコストに過敏になっている筈です。
無理な解釈が多すぎます。
さらに・・・

>評定の時に、なぜそのような評価になったか、知らされると思います。ん？経営者であった時、そういうことを考えていらっしゃらなかったのでしょうか？

これは失礼すぎると思います。
そういえば、私のブログで失礼なコメントを書きなぐっていましたね・・・
その時も注意したのにまだなおっていませんね。
マナーを守って書きましょう。

見積提出がすべて受注できないと言っているだけなんですがね。避難を受ける、心当たりがありませんが。

正確な見積もりって可能なんでしょうか。基本に立ち返ってください。
手作業で作成する作業効率は、作業員の能力や健康状態に左右されます。1週間費やしてできなかったことが、突然できたり、詳しい人に依頼したら、瞬時に解決したりすることは、頻繁にあります。
作業を進めていくと、前提条件が成立しなくなったり、サポートしていない動作環境に陥ったりしてモガクこともシバシバあります。
想定外の出来事は、その時点にならないと発覚しません。
　アジャイル手法でそこまで工数算出するということは、実質上、製造工程をシュミレートしていることに他なりません。
ですから、工数算出に相当日数を要することになります。

その結果、見積もり金額と予算の折り合いがつかず、商談破局になったら、元も子もないでしょう。そこを聞いただけです。曲解しないでください。
　作業シュミレートして積算見積もりは可能でも、あくまで、作業員の平均値での積算に過ぎません。言ってみれば概算です。　想定外の事態の発生率が高い業界です。危険率を加味するのは不可避てす。
　正確な開発額は、納品時でないと判明しません。なので、受注時に正確な開発費用の提示は不可能です。
予定開発額で見積もって、商談するしかありません。発注者 /受注者ともに見落としてていた不具合があれば、再見積もりになります。
受注者の見込み違いなら、赤を蒙るだけです。
　アジャイル方法、相当日数掛けてでシミレートして最適な価格を出して、これだけ掛かります。というのと
　時間単価でこれだけ工数かかったから請求します。というのか、同じに見えます。
発注者はそんなことは、望んでいない。
欲しているのは　xxxxの機能をyyyy円で作ってほしい。できるかてきないか。
もしくは、xxxxxxの機能を作るのに、どれくらいの期間と費用がかかるか。
それを短期間で知りたいのです。正確さより迅速さを求めています。誤差がx%程度の概算で十分なんです。

ようするに、内部設計が終わらないと、開発計画が立てられないのはわかりますよね。
インドリさんは内部設計が終わらないと、見積もり提示できなのですか?
その結果、商談がキャンセルになったら、どうするのですか?

Jittaさん、ありがとうございます。

　根本的なお話ですが、Jittaさんのおっしゃる事は正論でしょうし、そんな事は
私も分かっています。言いたいのは人月単価の否定ではなく、「エンジニア（労働
者）もコスト意識を持って、生産性の向上を考えましょうよ。」という事だけで
す。コスト意識なんてほとんどのエンジニアが持っていない事ぐらい分かっていま
すし、分かっているからあえてタイトルに「コストを意識して生産性を上げろ！」
と書いています。

　業界の傾向として時間をかけてたくさん仕事をしているように見えれば作業が早
い人よりも評価されています（くどいようですが、すべてではありません）ここが
問題かな、と思いそこに人月単価の話も絡めて書きました。評価の時にスキルはあ
る程度評価されるでしょうが、勤務時間は残業が多いと「減らせよ」ぐらいでしょ
うか。

　利益率にこだわったのは生島氏が書いている「解雇」に関係があります。給与カ
ット、ボーナスカット、そして倒産の道に進むのであれば、抗うために労働者が出
来る事は利益率の向上です。いろいろな作業形態があるのでひとまとめには出来ま
せんが、とにかく出るもの減らして利益を少しでも多くしよう、という事です。無
い袖は振れませんし、倒産は突然やって来ますよ（いや、まじで。社員として今年
経験しましたが、言われた瞬間はどうしようかな、と本気で考えました）解雇を認
める・認めないなんて議論は会社があるから出来る話であって、倒産してしまえば
全員「解雇」となんら変わりません。派遣労働者切りの時もそうですが、エンジニ
アも従属的な考えでは同じ道をたどる危険性があると思うからこそ、危機感を持っ
て欲しいと願っています。

　知らないから、知らせてくれないから、ではダメだと思っています。無頓着の原
因なんてここではどうでも良い事で（分かり切っているから）、経営者の考えだか
らとか言っていればエンジニアは無尽蔵にコストをかけても良いのでしょうか？
（極端ですが）

　本当は問題点をトータルで考えるべきなのですが、コラムという制約の中では1点
1点切り出しながら書くしかありません。極端な事を捉えて書いているので現状と照
らし合わせれば「違う」と感じる人もまた出てくると思いますし、それが当たり前
だと思っています。それに対して意見を言ってもそれは多分平行線でしょう。

　私がコラムで書きたいのは正論ではなく、道しるべです。今更、現状ある事を書
いても意味がないと（ここでは）思っています。世の中の情勢としてこれからまだ
少しずつ悪くなっていく中で、エンジニアが生き残っていく道を模索したいがため
に問題提起をしていろんなエンジニアの人に考えて欲しいだけであって、Jittaさ
んのようにわかりきった意見の議論がしたい訳では無い事だけは理解して下さい。
あくまでも建設的に行きたいだけです。

　よろしくお願いします。

>インドリさん

>>・自分と意見が違うと相手の否定から入る。
>ソフトウェア工学などを踏まえていないから注意したまでです。

人様の名前を間違えている時点で注意などできる立場でないことはわかっていらっしゃいますか？
それに注意ではないですよね。ただの罵倒です。
見ていて不快なので控えてくださいますようお願いいたします。

>おっと失礼間違えました。
本当に失礼だと思っているのならこんな一言で済ませません。
大半の人はこんな返答されたら怒ると思いますよ。

>ヴァン さんはちゃんとやり取りを見ていますか？
ここでまた否定ですよね。
ヴァンさんに言われた事、理解していますか？

>にゃん太郎さん
初コメントになりますがコラムと関係ないことですみません。
あまりにもひどすぎると感じましたのでコメントさせていただきました。

AZさん
もう言っている事が無茶苦茶です。
ウォーターフォール・モデルでの問題点を貴方は言っているようにみえますが？
それでアジャイルでその様なありえない見積もりを並べてると、余計にウォーターフォール・モデルに基づく人月単価を計算している事がおかしい事を指し示す結果になっております。
全体的に、貴方は一体に何を仰りたいのでしょうか？
言っている事が支離滅裂に見えます。
見積もりが出来ないと相強調されてもねぇ・・・
そういえば、貴方は私のブログで「騙されるお客が悪い。どんな金額でもいい。」と主張しておられましたね。
私は貴方のそういった意見に賛成出来ません。
何もかも出来ないと決め付けて現状維持を言っていると未来はありませんよ。

インドリさん
これには答えて下さい。
インドリさんは、顧客に、見積を提案して、受注できる確立はどれ位ありますか。
　見積もりしたけれど、受注できなかった案件は内のですか?
　仕事の話が発生して、見積もり提出まで、期間はどれくらいですか。短期間に実開発コストの"正確な"算定は可能なんですか。
　　見積ったけれど、受注できなかったとき、そのコストはどこから、回収するのですか。

>見積もりが出来ないと相強調されてもねぇ・・・
文意をキチンと書いてもらわないと、他の人が誤解します。勝手に誤省略しないでください。
　　>騙されるお客が悪い。どんな金額でもいい。」
　 これも、卑劣な「誤省略」です。
　　引用するときは、該当個所を全文引用してください。これでは、印象操作になります。

私は、『「正確な」見積もりはできない』と言っているのです。人による手作業仕事なので、掛かった原価は締めないと判明しません。
しかし、機能数の洗い出しと平均人月単価とで概算見積もりは算定できます。実際の費用との際は誤差内に収まります。

繰り返し言います。受注があって初めて、仕事になります。「遅い、少ない、美味しい」店ばかりが商売ではありません。
「早い、安い、まぁまぁ」なのも商売です。

「xxxのシステムをyyy円で作ってくれ」と言われて、採算が合わないとき、顧客と協議して「機能をおとす、品質をおとす、断る」それは自由です。
しかし、「採算が合わない」と判断した理由をハッキリさせないと行けませんよね。アジャイル工法で日数掛けて算出して、断ることになったら、見積もり工数分、赤字発生になるのですよ。

どのように、お考えでしょうか。

えーと、非常に書きにくい状態になっているんですが(^^;;;;
ざっと読んでみて、職場の違いで大きく異なるんだなーとは思いました。
私は主にフリーエンジニアや小企業など、小規模な視線で、にゃん太郎は大企業の視線なのかなと。
小さい会社では、元々コストを意識しないと食っていけないので、このコラムの趣旨はわかっているつもりです。

で、書き込みの動機は、「人月単価」の定義というか認識だけなんですよ。
間ですごーく、横道にそれた感じがしますが(^^;
AZさんやJittaさんの話もよくわかりますし、感覚としては、「人月単価」の認識が私と一致しているように思えます。

インドリさんに比べて、にゃん太郎さんの説明は、具体的なので、わかりやすいです。
大企業という前提のもとで考えれば、多くの事例は、そうかもなぁと共感できます。
一度設定した金額から上げることができない事情もよくわかります。

私が一番ひっかかっている、「生産性が低い者ほど利益を得られる」とされる「人月単価」ですが、

>技術者の派遣では、派遣する側が自由に単価を決められる事はなく、やはり派遣
>される側の方が強いです。

この部分でしょうか？
派遣される側が、派遣する人の能力には無関係で報酬を固定してしまうため、時間を長く取らないと利益が得られないという解釈でよろしいですか？
それとも、時給ベースだと、時間がかかるほど報酬が多くもらえるという労働報酬でしょうか？
個人的には、後者の話は、「人月単価」とは無関係であると考えていますが、関係するのでしょうか？

>　「人月単価は仕方ない」「生産性も考慮している」と考えているのはどちらかと
>言えば間接的に報酬をもらっているサラリーマンの方だと思います。

うーん、生産性≒コストと考えていいですよね？
どんな価格設定でも利益を出すにはコストを考慮しないわけにはいかないし(^^;
にゃん太郎さん自身も、

>請負なら見積時にメンバーがアサインされている事はまずなく（予定はあっても）
>予想される構成でするため、そこの中での単価となります。
（改行位置を調整させてもらいました）

コストを考慮しているじゃないですか。
違いは、「厳密な生産性」かどうかですかね？

>逆に短期間で仕上げると「じゃあ、次はもうちょっと安くてもいい
>よね？」なんて言われかねません。

うーん、必要以上に納期よりも早く納品したらそういわれても仕方がないと思いますが(^^;

>よっぽど人なり会社なりがいなければ回っていかない状況にな
>らないと「文句があるなら他に差し替える」というのが企業のスタンスでしょうから。

えーと・・・その前に書かれている・・・

>　日本の企業論理では大企業になればなるほど「安いから他社」とはなりにくい現
>状があります。

矛盾を感じるんですが(^^;;;
おそらくどちらもある話だと思いますが、状況により都合が良い例を抜き出されているように感じます。

ＰＳ．
>　インドリさんの意見は間違いなく経験則の話なので私も同意出来る考え方です。
>書き方は少し極端だとは思いますが。

インドリさんの見解＝にゃん太郎さんの見解として考えられても仕方が無い書き方だと思います。
えーと・・・そろそろ止めなくていいんですか(^^;
極端な意見はともかく、人を下に見ている書き方は、あまり良い印象を与えないと思うのですよ(^^;
正直、人に質問しておいて、それに回答したら、こっちの質問と共に完全無視されるとは思いませんでした。

あっ、にゃん太郎さんもソレが正しかったと判断されるのなら、話は別です。(^^;
その場合、私自身が気がつかない悪い点があるのでしょう。
今後の参考のために、どこが悪かったか教えてもらえるとありがたいです。

Ｓｏｄａさん、ありがとうございます。

　すでに最初の論点からずれているのでとりあえず今回は締めという事で。

　ここでコメントされている事柄は書かれている人の視点ですのでどれも正しいと
思っています。私自身、少し前にコメントしているように特に一部分だけを切り取
っているので人によっては違和感は感じるでしょう。

　それはそれで良いと思っています。

　今回、ひとつ失敗したと思うのはいろいろな立場を明確にせずに概論だけで述べ
た事だと思います。私としては人月単価を（今回は）問題にしたかったわけでもな
いですし、これに関しては以前から、そして生島氏のコラムでも書かれているので
ここではあえて論点の中心に据える気はありませんが、結果的に中心になってしま
いました。

　コラムに対しての反論は悪いとは思いませんが、「自分はこうだと思うから違
う」という角度で来られても正直答えようがありません。コラム自体は私の（勝手
な）意見なので「そう言われればそうですよね」としか言いようがないのもまた事
実です。なぜなら、コメントされている事が正しいのは分かり切っているからです。

　いまさら、全体をとらえてもとらえ切れる訳もないですし、一部を切り取っても
そりゃ私にとっての一部なので例えばＳｏｄａさんの感覚と違ってもなんらおかし
くない訳です。

　場外乱闘は基本的に構いませんが、中傷合戦だけは控えて欲しいと思います。コ
メント欄を開放しているのは意見があれば書いて下さいと思っているだけで、誰か
を攻撃するためではない事は大人なら分別がつくと思います。でも、以前あった投
稿間違い（他の人にするはずのコメントをしてしまった）以外に手をつけるつもり
もありません（このときは非表示にしました。削除はしません）

　あと、レスポンスの期待は結構ですが強要は勘弁して下さい。インドリさんの意
見が極端だとは思うときはありますが、それはそれなので仮にしゃくに障っても売
り言葉に買い言葉では何も解決しません。意見を言うのは良いですが、他人に対し
てそれを押し付けては議論にすらなりません。どうしても許せなければ申し訳あり
ませんが無視して下さいませ。私のコラムやコメントに対する意見は良いですが、
注意や喧嘩をするところではありません。ここはそういう場だと私は思っていま
す。

　この話、いずれちゃんとした形（少し間をおいてから。今やると間違いなく二の
舞なので）でもう一度きちんと書こうと思います。その時に改めてコメント頂けれ
ば幸いです。

　みなさま、ありがとうございました。

>なぜなら、コメントされている事が正しいのは分かり切っているからです。

周りから見ると、にゃん太郎さんがどう受け取っているかは、回答が無ければわからないんですよ。
沈黙はYesという考えもありますが、伝わっていないという誤解を生む可能性があります。

「自分はこうだと思うから違う」というのは、理由を明示した意見であり、反論の多くの場合はソレじゃないですか。
Yes/Noだけでも回答しないと、誤解が広がるんじゃないかなぁ(^^;

正直な話、今回のやり取りは、「お前はわかっていない」と一方的に切り捨てている感じを受けてたんですよ。
なぜならば、私は

>人月単価の問題点については前世紀から言われているに、まだこんな事を言う人が居るとは・・・

とバカにされているからです。
まぁ、バカにされるのは慣れましたから、別になんとも思ってないのですがｗ
にゃん太郎さんも同意されているので、私からみると同じように感じたわけですよ(^^;
後半にゃん太郎さんの意見をみて、あぁ、違うのかなーと思いましたが・・・

>あと、レスポンスの期待は結構ですが強要は勘弁して下さい。

あぁ、強要している気はまったくないんですよ。
純粋にマナーとしてどうかって捕らえ方の問題ですので、個人差があると考えています。
全部の質問に答えろーなんてバカなことを言う気はありませんので、安心してください。

私が感情的になって言い返していると見られていたのは、残念ですが(^^;;;;;

>私のコラムやコメントに対する意見は良いですが、
>注意や喧嘩をするところではありません。

なるほど、喧嘩はもちろん、注意なども禁止という考えですね、了承しました。
ただ、注意も禁止というと、コメント欄の品位が落ちることもあると思いますし、このコメントを見ていない方はやっぱり同じことをするかもしれません。
今以上に、にゃん太郎さん自身の介入が必要ではないかなーと(^^;

今回は、私の素朴な疑問から、変な流れになってしまい申し訳ありませんでした。

ＰＳ．
まだ私の疑問は解けていないし、同じような疑問を持っている人も沢山いるようです。
誰か解いてくれないかなーと・・・局部的な話題過ぎて駄目か？ｗ

Ｓｏｄａさん、ありがとうございます。

　正直、出てくる気はあまり無かったんですが･･･

　誤解されたくないので何点か。

　私はコメント欄の意見については基本的に自由だと思っています。注意や喧嘩は
するところではないと思っていますし、して欲しいとは思っていません。ただ、だ
からといって一方的にするなとか削除する事はしません。注意と喧嘩と意見が紙一
重だからです。

　バカにしているのか意見かも正直紙一重だと思っています。受け取り方が人によ
っていろいろなのでここでＳｏｄａさんが「バカにされている」と受け取ったなら
それは申し訳ないと思います。すみませんでした。

　介入に関しては気にはしますが、基本的にしないつもりです。もらったコメント
は当然全部読んでいますし、極力レスはしようと自分のペースで努力はします。反
論がイヤだ、荒れるのがイヤだ、私が自分の意見を一方的に押し通したいのなら初
めからコメント欄を解放しません。やはり、いろいろな人の意見が聞きたいのでそ
こに立ち入るのはどうかな、と言うのが私の考えです。

　疑問に関しては誰も解いてはくれないと思います。人月単価や生産性についても
私やＳｏｄａさんが異なる意見を持っているように個々の人で意見は異なると思い
ますから。そのためにコメント欄があり、意見や考え方を言いあう場であるとは思
いますが、疑問を解いたり、挙げ足を取る場ではないと考えています。

　これで誤解が解けるとも思いませんが、私の考え方だけ分かって頂けたら幸いで
す。コメント欄の品位が落ちたなら、それは私のコラムが良くなかったと反省材料
にします。でも、これに懲りず、また意見をお願いします。予告通り、この件はま
たいずれやる予定なのでその時までに私も少し論点の整理をしたいと思います。

>人月単価の問題点については前世紀から言われているに、まだこんな事を言う人が居るとは・・・

これを書いた理由ですが、にゃん太郎さんがコラムの性質上書いていないところから何癖をつけているように見えたからです。
私も記事を書いていますので「全てをかけない」という事がよく分かります。
限られた文章で前提から全ての視点までを書くことは不可能です。
それで怒りを少し込めて書きました。
このコラムが前提としている部分に、無理やり自分の解釈をねじ込んでもそれは揚げ足取りにすらなりません。
ただの何癖です。
にゃん太郎さんが明言しておりますが、人月単価は主題ではありません。
人月単価で安易にお金を考える所が問題なのです。
人月単価は一山いくらのものなので、真面目に働いている人程、生産性が無い人の負担を背負っている事になります。
ここが問題なので、「一人ひとりが生産性を高める必要がある」とこのコラムでは書いているわけです。
均一化された価格設定なので、全ての人がコストと自分の生産性を意識する必要があります。
日本は解雇し辛いので尚更です。

それとAZさんの質問はまるっきりこのコラムと関係ないですよね・・・
受注の成功率とこのコラムどう関係するのでしょうか？
この方はうちのブログでもかき回していましたので、どうやらそういう人なのだと思って返信しないことにします。

こんにちは、はじめてコメントいたします。nightRavenです。

どうしようか迷ったのですが、書かせていただくことにします。
ずいぶん昔になりますが（苦笑）、仕事をやりはじめてそれほど経っていない頃に、はじめて「自分の経費」を意識することを教えられました。
まぁ、私も高校を卒業したばかりのクソガキで、経費もコストもまったくわかっちゃいなかったので自分にかかるお金が予想外に大きかったのに驚きました。
その後も仕事をしていく間に、何度か自分に対するコストの話を教えられたこともあり、一応（この辺がダメダメなのですが）、常に頭のどこかに意識してやるという習慣がついたと考えてます。

#まぁ、そんな話はとてもとても余談なのですが...。

で、本題。
各自が己のコストを意識することができるか否かは、基本的に所属する会社の姿勢につながると思います。
会社全体が、上司が、先輩が常にコストを意識するようになっていれば、おのずとコスト意識は身につくでしょう。
各々がコストを意識せずに漫然と作業をするのか、少しでもコストパフォーマンスを高めるために動くのか、それは自己責任でもありますが、会社の負う責任でもあるかと思います。

にゃん太郎氏のコラムを読んで疑問に思ったのですが、コストを意識しなくなる原因のひとつに「人月単価」をあげられております。
そうでしょうか？私には疑問です。
コストは自分にかかっているお金ですから、「仕事をした対価」として「会社がもらえるお金」とは関係がありません。
当然その計算の元となっている「人月単価」も関係ありません。
なのに、さも「人月単価」が技術者を堕落させているかのような言い方をされていたことが気になりました。（すみません、言葉が悪いですね）
#その先の「利益」「利益率」を考えた場合には当然からんでくる問題であるということは認識しているつもりです。そしてもちろんそれが重要であることもです。

「人月単価」については、いろいろと思うこともありますが、本題ではないとのことでしたので触れないことにします。

拙い、まとまらない文章で申し訳ありません。

最後に、選挙の話ですが、私も昔は「オレひとりがいかなくても大勢に影響ないやー」と行かなかった人種ですが、これって良く考えると「オレひとりくらいサボってもいいやー」と同じかな...と。
人間の基本姿勢っていろんなところに表れるのかもしれませんね（苦笑）

にゃん太郎さん、特定の方を対象にした、投稿を書いてしまったことをお詫びします。
価格設定の抱える、構造的宿命を主張したかったのです。

いままでの投稿と重複するのですが、受注時に価格交渉します。このときは、予想工数です。確定工数は出せません。
開発担当者や人数すら不明な場合があります。ですので、
　見積額　　=予想工数期間　* 平均月額単価　*( 投入人数　+ 間接人数)+ 固定費+@ + 利益
となります。

人月単価は原価単価に過ぎません。時には、赤字にでも受注することもあります。個人の支払いを減額することは難しいので、赤字になります。
しかし、個人の能力評価とは別次元の話なので、技術評価は切り離して行うものですよね。
ですので、一連の人月単価論争を見ていると、異なる種類のデータを同列に論じているように見えます。
・予想原価(予想工数)と確定原価(確定工数)
・納品物性能は開発者の技術レベルで左右されるものではなく、受注時に確定するものです。
　予算に見合った性能になるのは、経済活動上、不可避(開発者の不満は別問題。その下で最善を尽くすのが雇われ開発者)
・労働雇用評価とスキル評価の不一致:
能力差と個人単価が比例できればベストですが、時間拘束という縛り等、があるから価格差が小さくなってしまう。
・納品後に綺麗に「客離れ」できるかも、重要で、製品性能に含まれますが、開発者の範疇でなく、顧客の性質で、長く引っ張られる場合もあります。
　その場合、予定工数に危険率を乗じますが、これなどは、開発者の与り知らぬ事です。

端的にまとめると、商売上の単価と個人のスキル単価は別もので、電話番号の大小を比較しているように見えます。
このように、商売上の受注金額と実原価は別次元のものです。受注時に人月単価が顔をだすから、話が不毛な混乱に陥ってしまったのだと思います。

nightRavenさん、ありがとうございます。

　コラムでも書きましたが「人月単価」を否定する気は毛頭ないです。良くない
な、と考える理由は単純な数式ゆえに単価の積み上げ方がどうにでもなってしまう
部分です。でも、給与と人月単価が繋がらないのはもっともな話で、同列にしてし
まうのは少し乱暴かもしれません。

　生産性を中心にしたハズなのですが、ここまでいろいろな人のコメントを読むと
なかなか意図が通じていないと実感します。これは完全に書き手である私の失敗で
しょう。本音を言えば、「そうだよね、生産性を上げるのも大事だよね」と考えて
くれる程度を目指したつもりなので、そういう意味では人月単価はおまけ程度です
（別のコラムでもう少し書いていたので）

　安易な考えは良くないと反省しています。でも、懲りずにまた意見して下さい。

AZさん、ありがとうございます。

> にゃん太郎さん、特定の方を対象にした、投稿を書いてしまったことをお詫びします。
> 価格設定の抱える、構造的宿命を主張したかったのです。

　AZさんにしても他の方にしても言いたい事があってそれを主張される事は基本的に構わないと思っています。時には意図しない方向に行ってしまいますが、それはそれでひとつの意見なので良いのではないでしょうか。

　エンジニアって基本的に自分の信念みたいなものがあり、それが時にぶつかるのはある意味自然な流れだと思います。対面なら相手の表情や声のトーンを伺いながら議論可能ですが、ネット上で言葉だけ、しかも（ほとんどの人が）匿名なので相手の持つバックグラウンドも分からないままその場の一部分だけで討論したらこうなると思いますし、仕方ないと思います。それだけを分かって頂ければあとは自由で良いと思います。

　この辺のテーマ、考え直して真面目に書こうと思いますので、その時はまた参加して下さい。

# コメントのレスではなくてすいません。でも、中身はしっかり読んでいるので次の
# 参考にさせて頂きます。