<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
		xmlns:xhtml="http://www.w3.org/1999/xhtml"
>

<channel>
	<title>watermint.org &#187; programmer</title>
	<atom:link href="http://watermint.org/tag/programmer/feed" rel="self" type="application/rss+xml" />
	<link>http://watermint.org</link>
	<description>Takayuki Okazaki&#039;s blog</description>
	<lastBuildDate>Tue, 20 Dec 2011 14:10:12 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://watermint.org/tag/programmer/feed" />
		<item>
		<title>プログラマ度診断結果</title>
		<link>http://watermint.org/2009/03/17/875.html</link>
		<comments>http://watermint.org/2009/03/17/875.html#comments</comments>
		<pubDate>Mon, 16 Mar 2009 16:01:43 +0000</pubDate>
		<dc:creator>Takayuki Okazaki</dc:creator>
				<category><![CDATA[その他]]></category>
		<category><![CDATA[programmer]]></category>
		<category><![CDATA[test]]></category>

		<guid isPermaLink="false">http://watermint.org/?p=875</guid>
		<description><![CDATA[現実逃避もかねてプログラマ度診断。結果は80%でした。プログラミングは苦手ではないけど、得意でもないので妥当な結果かも。 あなたのプログラマ適正は　RANK A　で現在の適正としては　適正あり　となります。 解説 あなたは「創造的プログラマレベル」です。現段階で非常に適性があります。もしあなたが今、プログラミングに従事しているのならほぼ敵はいない状況でしょう。今のまま頑張れば、すごいソフトウェアを作ることも可能です。しかしながら、今の力に満足して怠けてしまうと一気に適性が落ちることもあります。技術系にはおごりは禁物です。 性格診断 あなたは考えつつ行動するタイプです。常に考えて行動するので失敗することは少ないでしょう。しかしながら、素早く行動すべきときに足が重くなりがちで、チャンスを逃していることはありませんか？なにか成功するには、時々は思い切った行動に踏み切るのも必要なことです。 あなたは人に対して、つかず離れずの微妙なバランスのコミュニケーションが取れる人です。人に合わせつつも、客観的な見方が出来る人でしょう。人に対してまた公平的な見方をするので、好かれることも多いはずです。しかしながら、より密着したコミュニケーションを取ろうとする人たちからは、その公平さを物足りなく感じ、非難の対象になることもあります。また人に合わせることも上手で、逆にいえば人の話で意見を変えることもあるので、ふとすると話に一貫性がなくなることもしばしばあるようです。 あなたは物事に対してバランスよく付き合える人のようです。押すべきところは押し、引きべき所は引くということが出来る人です。予期せず自分に不利な出来事が起こったとしても、うまく対処していけるだけの力を持っています。物事を計画通りに、予期しない事には臨機応変に対応できます。 あなたは、物事を道理を通して捉える人のようです。筋が通っているかどうかを見極める力を持っています。しかしながら、感情にも流されやすいようです。自分では正しくないと思いつつも他人の感情や義理人情に流されて行動していることはありませんか？時には信念を貫いて、周りの人に対して断固とした態度を取ることも人付き合いのスパイスとして必要です。 あなたは、色々な物に興味を持つようです。また興味を持ったものに対して、それを追求していくということもするようです。ただ、１つのものに集中しているときでも、面白いものが出てくればそちらに気が移ってしまい、やることなすこと全て中途半端になることも多いようです。物事に腰を据えて取り組むことも重要です。 この結果については、質問事項からの大体の傾向によって導出しています。質問のサンプル数の少なさなどから、ある程度の誤差はありますので、参考程度にとどめておいてください。 また、診断結果は「今の時点での」スナップショットに過ぎません。 経験や知識を取り入れたり、行動パターンを変えることによって、 変わってきます。時間がたったら、またやってみてください。]]></description>
			<content:encoded><![CDATA[<p>現実逃避もかねて<a href="http://www7.plala.or.jp/keny01/consult/exam.html">プログラマ度診断</a>。結果は80%でした。プログラミングは苦手ではないけど、得意でもないので妥当な結果かも。</p>
<blockquote><p>
    あなたのプログラマ適正は　RANK A　で現在の適正としては　適正あり　となります。</p>
<p><strong>解説</strong></p>
<p>    あなたは「創造的プログラマレベル」です。現段階で非常に適性があります。もしあなたが今、プログラミングに従事しているのならほぼ敵はいない状況でしょう。今のまま頑張れば、すごいソフトウェアを作ることも可能です。しかしながら、今の力に満足して怠けてしまうと一気に適性が落ちることもあります。技術系にはおごりは禁物です。</p>
<p><strong> 性格診断</strong></p>
<p>    あなたは考えつつ行動するタイプです。常に考えて行動するので失敗することは少ないでしょう。しかしながら、素早く行動すべきときに足が重くなりがちで、チャンスを逃していることはありませんか？なにか成功するには、時々は思い切った行動に踏み切るのも必要なことです。</p>
<p>    あなたは人に対して、つかず離れずの微妙なバランスのコミュニケーションが取れる人です。人に合わせつつも、客観的な見方が出来る人でしょう。人に対してまた公平的な見方をするので、好かれることも多いはずです。しかしながら、より密着したコミュニケーションを取ろうとする人たちからは、その公平さを物足りなく感じ、非難の対象になることもあります。また人に合わせることも上手で、逆にいえば人の話で意見を変えることもあるので、ふとすると話に一貫性がなくなることもしばしばあるようです。</p>
<p>    あなたは物事に対してバランスよく付き合える人のようです。押すべきところは押し、引きべき所は引くということが出来る人です。予期せず自分に不利な出来事が起こったとしても、うまく対処していけるだけの力を持っています。物事を計画通りに、予期しない事には臨機応変に対応できます。</p>
<p>    あなたは、物事を道理を通して捉える人のようです。筋が通っているかどうかを見極める力を持っています。しかしながら、感情にも流されやすいようです。自分では正しくないと思いつつも他人の感情や義理人情に流されて行動していることはありませんか？時には信念を貫いて、周りの人に対して断固とした態度を取ることも人付き合いのスパイスとして必要です。</p>
<p>    あなたは、色々な物に興味を持つようです。また興味を持ったものに対して、それを追求していくということもするようです。ただ、１つのものに集中しているときでも、面白いものが出てくればそちらに気が移ってしまい、やることなすこと全て中途半端になることも多いようです。物事に腰を据えて取り組むことも重要です。</p>
<p>    この結果については、質問事項からの大体の傾向によって導出しています。質問のサンプル数の少なさなどから、ある程度の誤差はありますので、参考程度にとどめておいてください。 また、診断結果は「今の時点での」スナップショットに過ぎません。 経験や知識を取り入れたり、行動パターンを変えることによって、 変わってきます。時間がたったら、またやってみてください。
</p></blockquote>
]]></content:encoded>
			<wfw:commentRss>http://watermint.org/2009/03/17/875.html/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://watermint.org/2009/03/17/875.html" />
	</item>
		<item>
		<title>プログラマの単価の関係</title>
		<link>http://watermint.org/2009/02/17/838.html</link>
		<comments>http://watermint.org/2009/02/17/838.html#comments</comments>
		<pubDate>Tue, 17 Feb 2009 14:07:55 +0000</pubDate>
		<dc:creator>Takayuki Okazaki</dc:creator>
				<category><![CDATA[テクノロジー]]></category>
		<category><![CDATA[programmer]]></category>
		<category><![CDATA[work]]></category>

		<guid isPermaLink="false">http://watermint.org/?p=838</guid>
		<description><![CDATA[蛇足ながら、前エントリ「Re: プログラミングに誇りを持ちたいなら単価を上げること」に少し補足しておきます。前エントリではプログラマの単価が、プログラマの能力や成果にほとんど関係せず、組織の力によって決定されると書きました。この顕著な要因として、与信とバックアップ体制があります。どちらも仕事がうまくいかなかった場合にはじめて実質的な効力が発揮されますが、商談前から検討項目としてあげられる重要な要素でもあります。単価に、ある程度のリスクに対する対応料金が含まれると考えることができるかもしれません。ある程度、大規模な開発案件になれば個々のスキル差による生産性の違いよりも、よりわかりやすくリスク回避できる方法が好まれるように感じるので、プログラマの単価とスキルの関係性はますます薄れるはずです。 この問題の難しいところは、生産性の高いプログラマ、アーキテクト、テスターに対して実際の生産実績と報酬を結びつける恒常的で有効な方法が発見されていないことにあると思っています。たとえばEarned Value Management System (EVMS)によって生産を管理しても、バグ発生による手戻りの影響は統計的な推測ぐらいしかできず、生産時やバグ修正時における各個人の働きがどの程度生産に影響をもたらしたかを管理することはできそうに思えません。生産活動を管理するという視点ではEVMSは強力なツールでえすが、知的財産の生産管理や評価に対して最適なツールであるとは思えません。数年前にPMBOKの講習を受けたままで、あまりプロジェクトマネジメントの知識はアップデートしていませんが、知的財産の生産に対して有効な管理手法が発見されたとは聞かないので、まだ発見までには時間がかかるのでしょう。]]></description>
			<content:encoded><![CDATA[<p>蛇足ながら、<a href="http://watermint.org/2009/02/13/833.html">前エントリ「Re: プログラミングに誇りを持ちたいなら単価を上げること」</a>に少し補足しておきます。前エントリではプログラマの単価が、プログラマの能力や成果にほとんど関係せず、組織の力によって決定されると書きました。この顕著な要因として、与信とバックアップ体制があります。どちらも仕事がうまくいかなかった場合にはじめて実質的な効力が発揮されますが、商談前から検討項目としてあげられる重要な要素でもあります。単価に、ある程度のリスクに対する対応料金が含まれると考えることができるかもしれません。ある程度、大規模な開発案件になれば個々のスキル差による生産性の違いよりも、よりわかりやすくリスク回避できる方法が好まれるように感じるので、プログラマの単価とスキルの関係性はますます薄れるはずです。<br />
<a href="http://www.flickr.com/photos/okazaki/3257467012/" title="Lunch of Jan 23rd by Takayuki Okazaki, on Flickr"><img src="http://farm4.static.flickr.com/3134/3257467012_4125257b30.jpg" width="375" height="500" alt="Lunch of Jan 23rd" /></a><br />
この問題の難しいところは、生産性の高いプログラマ、アーキテクト、テスターに対して実際の生産実績と報酬を結びつける恒常的で有効な方法が発見されていないことにあると思っています。たとえばEarned Value Management System (EVMS)によって生産を管理しても、バグ発生による手戻りの影響は統計的な推測ぐらいしかできず、生産時やバグ修正時における各個人の働きがどの程度生産に影響をもたらしたかを管理することはできそうに思えません。生産活動を管理するという視点ではEVMSは強力なツールでえすが、知的財産の生産管理や評価に対して最適なツールであるとは思えません。数年前にPMBOKの講習を受けたままで、あまりプロジェクトマネジメントの知識はアップデートしていませんが、知的財産の生産に対して有効な管理手法が発見されたとは聞かないので、まだ発見までには時間がかかるのでしょう。</p>
]]></content:encoded>
			<wfw:commentRss>http://watermint.org/2009/02/17/838.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://watermint.org/2009/02/17/838.html" />
	</item>
		<item>
		<title>Re: プログラミングに誇りを持ちたいなら単価を上げること</title>
		<link>http://watermint.org/2009/02/13/833.html</link>
		<comments>http://watermint.org/2009/02/13/833.html#comments</comments>
		<pubDate>Thu, 12 Feb 2009 16:32:47 +0000</pubDate>
		<dc:creator>Takayuki Okazaki</dc:creator>
				<category><![CDATA[テクノロジー]]></category>
		<category><![CDATA[business]]></category>
		<category><![CDATA[programmer]]></category>

		<guid isPermaLink="false">http://watermint.org/?p=833</guid>
		<description><![CDATA[ひがさんの記事が盛り上がっているようなので話題に参加しておきます(^^; 個人的な感覚として、単価を上げる原動力は組織の力であって、プログラマーの能力とは直接関係しないと思っています。ひがさんはコミュニケーションオーバーヘッドから品質と単価の関連性を指摘されていますが、それは直接的にプログラマーの単価に影響を及ぼすことはほぼないというのが個人的な感覚です。なぜならば、一人のプログラマーがいかにすばらしい成果を出すとしても、それが単価、つまり通常発注する平均価格を吊り上げるためにはあまりにも影響力が少ないと感じるからです。今日のシステム構築は大規模かつ複雑なものが多く、一人二人ですべてを作り上げることはほとんど無理です。このため、仕事は社内であっても、社外であっても組織に対して発注されます。単価とは、この組織が働くときの評価額であって、個人の評価や、成果物の評価とはあまり関係しません。 ある組織のAさんが、常によい成果をもたらすとしても、Bさんが足手まといとなるなら単価をあげる交渉をすることは難しくなるでしょう。このとき、Aさんをシニアプログラマ、Bさんをアシスタントプログラマというようにジョブタイトルを分けて単価評価を分けることもできますが、それは組織をジョブタイトルによって分割しただけで、プログラマー個人のAさんとしての評価ではありません。あるスタープログラマーの知名度を利用して、ジョブタイトルや組織のブランド力を高めることができるかもしれませんが、実際にそこまで一個人のプログラマーが組織に対して影響力が与えられるケースはあまり多く見かけません。 あるプログラマがご指名で、単価を提示されることがあるかもしれません。これは、確実にそのプログラマ個人の評価です。ただ、組織としてご指名でプログラマを切り売りするのは、ビジネスとして難しいかもしれません。組織には、ベースラインとなる能力レベルはあっても、個々に見れば能力の高い人もいれば低い人もいて、安定的に仕事をすることを考えれば、相対的に能力の低い人がしばしば仕事がない状態では組織としてうれしくありません。能力の低い人にも、現場で活躍し、売り上げをあげ、また能力を伸ばしてもらいたいと考えます。このため、営業やプログラマのマネージャはまんべんなく仕事が割り振られるように、ご指名での差別化された単価で仕事を受注することに躊躇すると思います。単価が決まる過程は組織、業種、業態によってさまざまかと思いますが売る側、売られる側という最低二つの側面から考えても、個人の能力や成果によって単価を向上させるのはかなり難しいだろうというのが個人的な感覚です。プログラマがいかにがんばろうとも、ビジネス上うまく行かなかったシステムに対して多くの単価を支払うことは、心理的に抵抗感が生まれて不思議はありません。プログラマがいかに成功しようとも、ビジネスコンサルに失敗していたら十分な対価を気持ちよく支払ってもらうことは難しいはずです。お客様からみれば、ビジネスコンサルもプログラマも、自分のビジネスを支える「組織」です。 ところで、今回のもともとの話はプログラマの地位についての話だったと思います。地位とは、いろんな解釈があります。給与や単価もそうでしょう。しかしながら、プログラマ個人として単価の向上が難しいため、方向性としては別の価値観を模索すべきではないかと思っています。単価はあくまで組織として向上を目指すべきですし、組織を管理する者の責任でもあるはずです。小規模な、売り切りのソリューションを構築する以外の場合、個人の努力によって単価を向上させるのはかなり難しいはずです。このため、プログラミングに対する誇りは間接的な「お客様の評価」を向上させたこと以外に難しく、直接的な対価として数値化することは不可能とは言わないまでも、ほとんどの場合無意味でしょう。地位とは、単価だけでなく、尊敬されることによっても確保されると思います。個人的に、いちプログラマとしては単価が向上するよりも、より尊敬される存在になるほうを重視したいと思っています。より尊敬されるためには、より美しいコードを書くよりも、よりビジネスに役に立つコードが必要なことを理解していなければならない点に注意しなければならないのですが、報酬を向上させるためだけに働くのならば、いずれ売る側と買う側の対立という基本的なビジネス構造の壁にぶつかり「プログラマの地位を向上させる」という基本的な目標を忘れ、場当たり的な行動に出るか、単に仕事を投げ出してしまうことになりかねません。抽象的な結論ですが、プログラマは尊敬によって評価されるべきであり、単価向上を目標とすべきではないと考えます。]]></description>
			<content:encoded><![CDATA[<p><a href="http://d.hatena.ne.jp/higayasuo/20090212/1234416037">ひがさんの記事</a>が盛り上がっているようなので話題に参加しておきます(^^;<br />
個人的な感覚として、単価を上げる原動力は組織の力であって、プログラマーの能力とは直接関係しないと思っています。ひがさんはコミュニケーションオーバーヘッドから品質と単価の関連性を指摘されていますが、それは直接的にプログラマーの単価に影響を及ぼすことはほぼないというのが個人的な感覚です。なぜならば、一人のプログラマーがいかにすばらしい成果を出すとしても、それが単価、つまり通常発注する平均価格を吊り上げるためにはあまりにも影響力が少ないと感じるからです。今日のシステム構築は大規模かつ複雑なものが多く、一人二人ですべてを作り上げることはほとんど無理です。このため、仕事は社内であっても、社外であっても組織に対して発注されます。単価とは、この組織が働くときの評価額であって、個人の評価や、成果物の評価とはあまり関係しません。<br />
<a href="http://www.flickr.com/photos/okazaki/3256646809/" title="Dinner of Feb 3rd - Jai Thai - Pla Gung by Takayuki Okazaki, on Flickr"><img src="http://farm4.static.flickr.com/3441/3256646809_f1f2e3b699.jpg" width="500" height="375" alt="Dinner of Feb 3rd - Jai Thai - Pla Gung" /></a><br />
ある組織のAさんが、常によい成果をもたらすとしても、Bさんが足手まといとなるなら単価をあげる交渉をすることは難しくなるでしょう。このとき、Aさんをシニアプログラマ、Bさんをアシスタントプログラマというようにジョブタイトルを分けて単価評価を分けることもできますが、それは組織をジョブタイトルによって分割しただけで、プログラマー個人のAさんとしての評価ではありません。あるスタープログラマーの知名度を利用して、ジョブタイトルや組織のブランド力を高めることができるかもしれませんが、実際にそこまで一個人のプログラマーが組織に対して影響力が与えられるケースはあまり多く見かけません。<br />
<a href="http://www.flickr.com/photos/okazaki/3256648617/" title="Dinner of Feb 3rd - Jai Thai - Kuai Tiao Neva by Takayuki Okazaki, on Flickr"><img src="http://farm4.static.flickr.com/3331/3256648617_2cde3e99ac.jpg" width="500" height="375" alt="Dinner of Feb 3rd - Jai Thai - Kuai Tiao Neva" /></a><br />
あるプログラマがご指名で、単価を提示されることがあるかもしれません。これは、確実にそのプログラマ個人の評価です。ただ、組織としてご指名でプログラマを切り売りするのは、ビジネスとして難しいかもしれません。組織には、ベースラインとなる能力レベルはあっても、個々に見れば能力の高い人もいれば低い人もいて、安定的に仕事をすることを考えれば、相対的に能力の低い人がしばしば仕事がない状態では組織としてうれしくありません。能力の低い人にも、現場で活躍し、売り上げをあげ、また能力を伸ばしてもらいたいと考えます。このため、営業やプログラマのマネージャはまんべんなく仕事が割り振られるように、ご指名での差別化された単価で仕事を受注することに躊躇すると思います。単価が決まる過程は組織、業種、業態によってさまざまかと思いますが売る側、売られる側という最低二つの側面から考えても、個人の能力や成果によって単価を向上させるのはかなり難しいだろうというのが個人的な感覚です。プログラマがいかにがんばろうとも、ビジネス上うまく行かなかったシステムに対して多くの単価を支払うことは、心理的に抵抗感が生まれて不思議はありません。プログラマがいかに成功しようとも、ビジネスコンサルに失敗していたら十分な対価を気持ちよく支払ってもらうことは難しいはずです。お客様からみれば、ビジネスコンサルもプログラマも、自分のビジネスを支える「組織」です。<br />
<a href="http://www.flickr.com/photos/okazaki/3257482826/" title="Dinner of Feb 4th by Takayuki Okazaki, on Flickr"><img src="http://farm4.static.flickr.com/3080/3257482826_9c7ba9925d.jpg" width="500" height="375" alt="Dinner of Feb 4th" /></a><br />
ところで、今回のもともとの話はプログラマの地位についての話だったと思います。地位とは、いろんな解釈があります。給与や単価もそうでしょう。しかしながら、プログラマ個人として単価の向上が難しいため、方向性としては別の価値観を模索すべきではないかと思っています。単価はあくまで組織として向上を目指すべきですし、組織を管理する者の責任でもあるはずです。小規模な、売り切りのソリューションを構築する以外の場合、個人の努力によって単価を向上させるのはかなり難しいはずです。このため、プログラミングに対する誇りは間接的な「お客様の評価」を向上させたこと以外に難しく、直接的な対価として数値化することは不可能とは言わないまでも、ほとんどの場合無意味でしょう。地位とは、単価だけでなく、尊敬されることによっても確保されると思います。個人的に、いちプログラマとしては単価が向上するよりも、より尊敬される存在になるほうを重視したいと思っています。より尊敬されるためには、より美しいコードを書くよりも、よりビジネスに役に立つコードが必要なことを理解していなければならない点に注意しなければならないのですが、報酬を向上させるためだけに働くのならば、いずれ売る側と買う側の対立という基本的なビジネス構造の壁にぶつかり「プログラマの地位を向上させる」という基本的な目標を忘れ、場当たり的な行動に出るか、単に仕事を投げ出してしまうことになりかねません。抽象的な結論ですが、プログラマは尊敬によって評価されるべきであり、単価向上を目標とすべきではないと考えます。</p>
]]></content:encoded>
			<wfw:commentRss>http://watermint.org/2009/02/13/833.html/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://watermint.org/2009/02/13/833.html" />
	</item>
	</channel>
</rss>

