<?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/"
	>

<channel>
	<title>せつないぶろぐ &#187; 提案・開発・運用</title>
	<atom:link href="http://blog.setunai.net/category/%e6%8f%90%e6%a1%88%e3%83%bb%e9%96%8b%e7%99%ba%e3%83%bb%e9%81%8b%e7%94%a8/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.setunai.net</link>
	<description>ソフトウェア開発、アジャイルなどについてＳＥ兼ＰＧが思った事を書いてます。たまにプログラムも</description>
	<lastBuildDate>Mon, 06 Feb 2012 15:04:45 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>デッドラインのよいまとめ</title>
		<link>http://blog.setunai.net/20090726/%e3%83%87%e3%83%83%e3%83%89%e3%83%a9%e3%82%a4%e3%83%b3%e3%81%ae%e3%82%88%e3%81%84%e3%81%be%e3%81%a8%e3%82%81/</link>
		<comments>http://blog.setunai.net/20090726/%e3%83%87%e3%83%83%e3%83%89%e3%83%a9%e3%82%a4%e3%83%b3%e3%81%ae%e3%82%88%e3%81%84%e3%81%be%e3%81%a8%e3%82%81/#comments</comments>
		<pubDate>Sun, 26 Jul 2009 03:29:08 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/?p=567</guid>
		<description><![CDATA[デッドラインはデマルコ氏の書いた小説風のプロジェクト管理本です。 内容は「ピープルウェア」「ゆとりの法則」そのまま。 3回以上読んだけどいつ読んでもホントに面白い。 こちらで綺麗に纏めてあるのでご紹介。 http://a [...]]]></description>
			<content:encoded><![CDATA[<p>デッドラインはデマルコ氏の書いた小説風のプロジェクト管理本です。<br />
内容は「ピープルウェア」「ゆとりの法則」そのまま。</p>
<p>3回以上読んだけどいつ読んでもホントに面白い。</p>
<p>こちらで綺麗に纏めてあるのでご紹介。<br />
<a href="http://anond.hatelabo.jp/20090725154202">http://anond.hatelabo.jp/20090725154202</a></p>
<p>興味持った方はぜひ読んでみて下さい。</p>
<p><iframe src="http://rcm-jp.amazon.co.jp/e/cm?t=happyfutsal-22&#038;o=9&#038;p=8&#038;l=as1&#038;asins=4822280535&#038;fc1=000000&#038;IS2=1&#038;lt1=_blank&#038;m=amazon&#038;lc1=0000FF&#038;bc1=000000&#038;bg1=FFFFFF&#038;f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20090726/%e3%83%87%e3%83%83%e3%83%89%e3%83%a9%e3%82%a4%e3%83%b3%e3%81%ae%e3%82%88%e3%81%84%e3%81%be%e3%81%a8%e3%82%81/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>コードレビューでレビュアーが気をつける事</title>
		<link>http://blog.setunai.net/20071023/%e3%82%b3%e3%83%bc%e3%83%89%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%81%a7%e3%83%ac%e3%83%93%e3%83%a5%e3%82%a2%e3%83%bc%e3%81%8c%e6%b0%97%e3%82%92%e3%81%a4%e3%81%91%e3%82%8b%e4%ba%8b/</link>
		<comments>http://blog.setunai.net/20071023/%e3%82%b3%e3%83%bc%e3%83%89%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%81%a7%e3%83%ac%e3%83%93%e3%83%a5%e3%82%a2%e3%83%bc%e3%81%8c%e6%b0%97%e3%82%92%e3%81%a4%e3%81%91%e3%82%8b%e4%ba%8b/#comments</comments>
		<pubDate>Mon, 22 Oct 2007 15:25:17 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[お仕事]]></category>
		<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20071023/%e3%82%b3%e3%83%bc%e3%83%89%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%81%a7%e3%83%ac%e3%83%93%e3%83%a5%e3%82%a2%e3%83%bc%e3%81%8c%e6%b0%97%e3%82%92%e3%81%a4%e3%81%91%e3%82%8b%e4%ba%8b/</guid>
		<description><![CDATA[最近うちのチームでコードレビューがいい感じに運用できています。 「コードレビューってこうするんですね」ってメンバーに言われてとても嬉しかったので調子にのってコードレビューで気を付けている事を書いてみます。 ■レビュアーが [...]]]></description>
			<content:encoded><![CDATA[<p>最近うちのチームでコードレビューがいい感じに運用できています。<br />
「コードレビューってこうするんですね」ってメンバーに言われてとても嬉しかったので調子にのってコードレビューで気を付けている事を書いてみます。</p>
<p>■レビュアーが気をつける事</p>
<p>１．解決方法は１つだけではない<br />
レビューする前に仕様が判っている事がほとんど。<br />
そうするとレビュアーはコード見る前に自分の中で勝手にコードを予想してしまう。<br />
これがあまり良くない。自分の予想と違うとついつい誘導したくなる。そこはぐっと我慢。<br />
レビュアーの予想が正しいとは限らない。</p>
<p>２．断定せずに質問を投げかけるようにする<br />
なぜその様にコードを書いたのか理由を聞く様にする。<br />
その際「なぜ？」の使い方を気をつける。レビューを受ける人は責められている様に感じてしまう。</p>
<p>３．褒める<br />
褒めなれてないと難しい。慣れてないと照れくさい。<br />
でもこれができないと良い点がシェアできないのでがんばる。</p>
<p>４．議論の対象はあくまでもコード<br />
これは耳タコ。でも難しい。<br />
問題はコードにあり開発者ではない。わかってるんだけどね。<br />
最近は上手くいっているかも。</p>
<p>５．間違い探し<br />
スペルミスやコーディング規約に沿っていない（軽い逸脱）ぐらいなら許す。<br />
そんなことをコードレビューで指摘するのは勿体無い。もっと見るべき点がある。</p>
<p>６．誰が優れたプログラマーかコンテスト<br />
気をつけないとほんとに陥り易い。自分の自慢は呑み会にでもとっておく。<br />
コードレビューには必要ではない。</p>
<p>途中まで優先度順に書いてみたんだけど見直したら順番付けられなくなった。<br />
どれも重要でどれも難しい。</p>
<p><span id="more-405"></span><br />
これが３分の１でもできるとチーム内でのコードレビューに対する評価が変わってきます。<br />
進んでコードレビューを依頼してきたり、メンドクサイって空気が薄れます。（まだちょっと思ってしまうけど:p）<br />
どれも充分では無いので改善してがんばる！</p>
<p>今でこの効果なのできちんとできたときの効果は計り知れないね。きっと！</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20071023/%e3%82%b3%e3%83%bc%e3%83%89%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%81%a7%e3%83%ac%e3%83%93%e3%83%a5%e3%82%a2%e3%83%bc%e3%81%8c%e6%b0%97%e3%82%92%e3%81%a4%e3%81%91%e3%82%8b%e4%ba%8b/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>不具合は基本的に原因療法で</title>
		<link>http://blog.setunai.net/20070620/%e4%b8%8d%e5%85%b7%e5%90%88%e3%81%af%e5%9f%ba%e6%9c%ac%e7%9a%84%e3%81%ab%e5%8e%9f%e5%9b%a0%e7%99%82%e6%b3%95%e3%81%a7/</link>
		<comments>http://blog.setunai.net/20070620/%e4%b8%8d%e5%85%b7%e5%90%88%e3%81%af%e5%9f%ba%e6%9c%ac%e7%9a%84%e3%81%ab%e5%8e%9f%e5%9b%a0%e7%99%82%e6%b3%95%e3%81%a7/#comments</comments>
		<pubDate>Wed, 20 Jun 2007 01:24:50 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070620/%e4%b8%8d%e5%85%b7%e5%90%88%e3%81%af%e5%9f%ba%e6%9c%ac%e7%9a%84%e3%81%ab%e5%8e%9f%e5%9b%a0%e7%99%82%e6%b3%95%e3%81%a7/</guid>
		<description><![CDATA[不具合見つけて短絡的に対症療法を選ぶ人が多すぎて困りものです。 不具合を見つけた場合、症状ではなく原因に目を向け対応するべきです。 しかしある時点までいった場合に、原因に対して対応することが難しくなることがあります。 そ [...]]]></description>
			<content:encoded><![CDATA[<p>不具合見つけて短絡的に対症療法を選ぶ人が多すぎて困りものです。<br />
不具合を見つけた場合、症状ではなく原因に目を向け対応するべきです。</p>
<p>しかしある時点までいった場合に、原因に対して対応することが難しくなることがあります。<br />
それはコストとリスクの問題です。</p>
<p><span id="more-367"></span></p>
<p>直接開発しているメンバーからすればきちんと原因に対して対応したいと望みますが<br />
マネージャーなどの管理側からすればコスト、リスクを考慮して症状に対する対応にとどめる事があります。</p>
<p>ここら辺はいつも悩みどころでもやもやして纏めきれていなかったのですが<br />
下記の記事は非常によく纏まっていてす。</p>
<p><a href="http://proger.blog10.fc2.com/blog-entry-74.html">職業としてのプログラミング  このバグ直しますか? &#8211; 原因療法と対症療法</a></p>
<p>みんながこれくらい考えて対応すると良くなると思うんですけどね。</p>
<p>注意として対処療法を選択した場合、原因の解決は行われていない事を意識し続ける必要があります。<br />
これは機能の追加・変更などの際に必ず起こる問題なので潜在的コスト、リスクになるでしょう。</p>
<p>まずは不具合を見つけたら原因と範囲を特定して対応を決めるよう心掛けたいところです。</p>
<p>» 関連<br />
<a href="http://blog.setunai.net/20060622/%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e9%96%8b%e7%99%ba%e3%81%ae%e3%83%88%e3%83%aa%e3%82%a2%e3%83%bc%e3%82%b8%e3%81%af%e4%b8%8a%e6%b5%81%e5%b7%a5%e7%a8%8b%e3%81%a7%ef%bc%81/">システム開発のトリアージは上流工程で！ : せつないぶろぐ</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070620/%e4%b8%8d%e5%85%b7%e5%90%88%e3%81%af%e5%9f%ba%e6%9c%ac%e7%9a%84%e3%81%ab%e5%8e%9f%e5%9b%a0%e7%99%82%e6%b3%95%e3%81%a7/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>ツールの制限によるリスクを考える</title>
		<link>http://blog.setunai.net/20070510/%e3%83%84%e3%83%bc%e3%83%ab%e3%81%ae%e5%88%b6%e9%99%90%e3%81%ab%e3%82%88%e3%82%8b%e3%83%aa%e3%82%b9%e3%82%af%e3%82%92%e8%80%83%e3%81%88%e3%82%8b/</link>
		<comments>http://blog.setunai.net/20070510/%e3%83%84%e3%83%bc%e3%83%ab%e3%81%ae%e5%88%b6%e9%99%90%e3%81%ab%e3%82%88%e3%82%8b%e3%83%aa%e3%82%b9%e3%82%af%e3%82%92%e8%80%83%e3%81%88%e3%82%8b/#comments</comments>
		<pubDate>Wed, 09 May 2007 15:29:03 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070510/%e3%83%84%e3%83%bc%e3%83%ab%e3%81%ae%e5%88%b6%e9%99%90%e3%81%ab%e3%82%88%e3%82%8b%e3%83%aa%e3%82%b9%e3%82%af%e3%82%92%e8%80%83%e3%81%88%e3%82%8b/</guid>
		<description><![CDATA[プログラマの生産性について個人差があるのは周知の事実で 仮に５人のプログラマが所属するチームがあったとする。 そこに所属する凄いプログラマが全体の５０％以上の業務をこなしたと想定すると Ａさん：５０％（凄い） Ｂさん：２ [...]]]></description>
			<content:encoded><![CDATA[<p>プログラマの生産性について個人差があるのは周知の事実で<br />
仮に５人のプログラマが所属するチームがあったとする。</p>
<p>そこに所属する凄いプログラマが全体の５０％以上の業務をこなしたと想定すると</p>
<p>Ａさん：５０％（凄い）<br />
Ｂさん：２０％（普通）<br />
Ｃさん：１５％（普通）<br />
Ｄさん：１０％（しょぼい、新人）<br />
Ｅさん：５％（ダメな人）</p>
<p>合計：１００％</p>
<p>だったとする。</p>
<p>ここでチームのリーダが全体の生産性を上げたい為に<br />
エディタ「hoge editor」を各プログラマに利用する旨を通達した場合何が起こるかというと、普通な人は当たり前にエディタ「hoge editor」を利用していたので生産性は向上しない。<br />
しょぼい人or新人は利用することにより５％の生産性が向上した。<br />
ダメな人は何を使ってもダメなので生産性はそのままだとすると<br />
以下の様になる。<br />
<span id="more-359"></span></p>
<p>Ａさん：３０％（凄い）<br />
Ｂさん：２０％（普通）<br />
Ｃさん：１５％（普通）<br />
Ｄさん：１５％（しょぼい、新人）<br />
Ｅさん：５％（ダメな人）</p>
<p>合計：８５％</p>
<p>１５％減だ。</p>
<p>凄い人は自分に合ったエディタを使っている為、リーダーが導入したエディタでは<br />
生産性が減少する。</p>
<p>これは野球選手のグローブやサッカー選手のスパイクと同様に<br />
そのツール自体の機能は他から見ればかわりがないが利用する本人にとっては大きな違いとなる。</p>
<p>なのでチームリーダの勝手な判断でエディタはこれを使いなさいと押し付けてることはチームとして非常にリスクになる事に気付いて欲しい。</p>
<p>現在はいろいろな面で自分の端末にアプリを導入するのも申請制になっているところも多いと思われるが、チームにとって何が大事かを判断しリーダーには体を張って欲しいものだ。</p>
<p style="color:red">※2008/01/29 記事内で全作業量と生産性の値がごっちゃになって記載されています。よって「hoge editor」利用時の数値は間違っております。詳しくは「とおりすがり」さんのコメントを参照下さい</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070510/%e3%83%84%e3%83%bc%e3%83%ab%e3%81%ae%e5%88%b6%e9%99%90%e3%81%ab%e3%82%88%e3%82%8b%e3%83%aa%e3%82%b9%e3%82%af%e3%82%92%e8%80%83%e3%81%88%e3%82%8b/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>ソフトハウスをカイゼン</title>
		<link>http://blog.setunai.net/20070509/%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9%e3%82%92%e3%82%ab%e3%82%a4%e3%82%bc%e3%83%b3/</link>
		<comments>http://blog.setunai.net/20070509/%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9%e3%82%92%e3%82%ab%e3%82%a4%e3%82%bc%e3%83%b3/#comments</comments>
		<pubDate>Tue, 08 May 2007 16:14:45 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070509/%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9%e3%82%92%e3%82%ab%e3%82%a4%e3%82%bc%e3%83%b3/</guid>
		<description><![CDATA[うちの会社は派遣８割、受託２割ぐらいなんだけど 社長に聞くとやっぱ受託はきついらしい。 派遣でのビジネスを考えてみると一人の社員を単価80円で派遣。 月々の費用を50円と考えると30円の儲けになる。 この場合利益を増大さ [...]]]></description>
			<content:encoded><![CDATA[<p>うちの会社は派遣８割、受託２割ぐらいなんだけど<br />
社長に聞くとやっぱ受託はきついらしい。</p>
<p>派遣でのビジネスを考えてみると一人の社員を単価80円で派遣。<br />
月々の費用を50円と考えると30円の儲けになる。</p>
<p>この場合利益を増大させようとすると単価を上げるか<br />
費用を下げるって選択肢もあると思うが手っ取り早いのが人を増やす。<br />
そうすればすぐに30円が手に入る。<br />
顧客に嫌な顔されて単価交渉するより増員の方がよっぽどやりやすい。</p>
<p>でもこれって派遣会社ならいいけどソフトハウスがはりっきってやっちゃうと<br />
社員のモチベーション落ちるよね。</p>
<p><span id="more-358"></span></p>
<p>派遣会社に登録して派遣社員でやる分には自分で選んだ事なので問題ないと思うけど会社から一方的に派遣され自社のメンバーと疎遠になりスキルアップもままならないとやっぱ辛くなるだろう。</p>
<p>入社して１～２年目で飛ばされちゃったりすると考えちゃうよね。<br />
またこの時期を乗り越えても５～６年目ぐらいになると先行きが不安になって転職したりする。ソフトハウスの中堅所が抜けたりするのもここら辺が理由なんじゃないかな。<br />
自分もそうだったし。</p>
<p>でこうならない為に受託をがんばればいいのかと言うとそれも辛かったりする。<br />
ベンダーからの受託の場合、合い見積によって値切られたりして辛かったりもするって話をよく聞くし自分もそう思うけど、これはどの業界にもあるので愚痴りにくい。</p>
<p>それよりも改善活動が行い難いのが原因だと思う。<br />
ベンダー側は品質保持の為にいろんなプロセスがあったりしてそれ守るように押し付けてくる。<br />
その為、必要の無いドキュメントを向こうのフォーマットで持ってきたり開発プロセスやツールなんかまで押し付けられちゃって社内で改善活動しようにも効率悪すぎてどうにもならない。</p>
<p>取引先のベンダーが１社であればなんとか手順作ることもできるかもしれないけど複数あると手に追えない。</p>
<p>押し付けられた手順を改善するにも契約の範囲内でしかできないので効果が限定的になってしまう。<br />
しかしそれでもなんと改善できてもまだ油断できない。<br />
ひどいところは見積もった人月分の人が働いているかどうかチェックするベンダーもいる。</p>
<p>これではソフトハウスが受託開発で利益を得るのは相当難しい。<br />
うまくいっている会社の人、方法教えて下さい。</p>
<p>そうなると残るは直顧客との受託開発。<br />
合い見積はあるだろうけど相手から開発プロセスや製品を押し付けられる事は<br />
かなり減りそう。<br />
そうなれば改善活動も進み利益を得ることができそうな気がする。</p>
<p>直契約をとる為に、ISOやプライバシーマークを取得する必要はありそうだけれど<br />
会社として納得して取得に挑めるし自発的な点が社員としても良いと思う。</p>
<p>しかし直顧客と契約しているソフトハウスは少ない。<br />
たぶんベンダーが間に入らなくなる為だ。<br />
今までベンダーがいる事により顧客から仕事をとれたし大半のリスクはベンダーが<br />
受け持ってくれた。</p>
<p>なので利益を得られるソフトハウスは<br />
・顧客からベンダーの名前無しで仕事を見つけてくる営業<br />
・リスクを受け入れる経営<br />
が求められのかもしれない。</p>
<p>纏まるには纏まったので今度社長に提案してみよう。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070509/%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9%e3%82%92%e3%82%ab%e3%82%a4%e3%82%bc%e3%83%b3/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>プログラマの格差</title>
		<link>http://blog.setunai.net/20070508/%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9e%e3%81%ae%e6%a0%bc%e5%b7%ae/</link>
		<comments>http://blog.setunai.net/20070508/%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9e%e3%81%ae%e6%a0%bc%e5%b7%ae/#comments</comments>
		<pubDate>Mon, 07 May 2007 16:03:08 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070508/%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9e%e3%81%ae%e6%a0%bc%e5%b7%ae/</guid>
		<description><![CDATA[プログラミングの6大10項目リスト http://www.aoky.net/articles/jeff_atwood/top_6_list_of_programming_top_10_lists.htm こういった記事は [...]]]></description>
			<content:encoded><![CDATA[<p>プログラミングの6大10項目リスト<br />
<a href="http://www.aoky.net/articles/jeff_atwood/top_6_list_of_programming_top_10_lists.htm">http://www.aoky.net/articles/jeff_atwood/top_6_list_of_programming_top_10_lists.htm</a></p>
<p>こういった記事は面白いのだけれどSIerのプログラマにはちょっと辛い。<br />
わかっているのだけれどなかなか実践し難い。</p>
<p>SIerのプログラマは言語どころか実装も自分の思うとおりに作れなかったりする。<br />
ここら辺がIT業界とSIer業界プログラマの格差が大きいところ。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070508/%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9e%e3%81%ae%e6%a0%bc%e5%b7%ae/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>これは読んどけ</title>
		<link>http://blog.setunai.net/20070424/%e3%81%93%e3%82%8c%e3%81%af%e8%aa%ad%e3%82%93%e3%81%a9%e3%81%91/</link>
		<comments>http://blog.setunai.net/20070424/%e3%81%93%e3%82%8c%e3%81%af%e8%aa%ad%e3%82%93%e3%81%a9%e3%81%91/#comments</comments>
		<pubDate>Tue, 24 Apr 2007 01:33:04 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070424/%e3%81%93%e3%82%8c%e3%81%af%e8%aa%ad%e3%82%93%e3%81%a9%e3%81%91/</guid>
		<description><![CDATA[ブックマーク的なエントリー はてな：人力検索 プログラマの方、もしくはプログラミングに興味のある方に質問です。web上の文章でこれは読んでおいた方がよい、あるいはこの文章は面白いという文章を教えてください。文学、エッセイ [...]]]></description>
			<content:encoded><![CDATA[<p>ブックマーク的なエントリー</p>
<p>はてな：人力検索</p>
<blockquote><p>
プログラマの方、もしくはプログラミングに興味のある方に質問です。web上の文章でこれは読んでおいた方がよい、あるいはこの文章は面白いという文章を教えてください。文学、エッセイ、哲学、宗教、経済、科学、コンピュータ等、分野は問いません。
</p></blockquote>
<p><a href="http://q.hatena.ne.jp/1176811441">http://q.hatena.ne.jp/1176811441</a></p>
<p>半分くらいは読んだことあるページで残り半分は知らないページだった。</p>
<p>またチェックするページ増えたな^^;</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070424/%e3%81%93%e3%82%8c%e3%81%af%e8%aa%ad%e3%82%93%e3%81%a9%e3%81%91/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ゆとりのないソフトハウス</title>
		<link>http://blog.setunai.net/20070316/%e3%82%86%e3%81%a8%e3%82%8a%e3%81%ae%e3%81%aa%e3%81%84%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9/</link>
		<comments>http://blog.setunai.net/20070316/%e3%82%86%e3%81%a8%e3%82%8a%e3%81%ae%e3%81%aa%e3%81%84%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9/#comments</comments>
		<pubDate>Fri, 16 Mar 2007 03:35:21 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070316/%e3%82%86%e3%81%a8%e3%82%8a%e3%81%ae%e3%81%aa%e3%81%84%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9/</guid>
		<description><![CDATA[無駄、無駄、無駄！ →効率化 リスク、リスク、リスク！ →リスク回避（出来る事しかやらない、利益率が低い） それはそれで間違ってはいないのですが、そこから利益が出ているのかが問題。 効率化とリスク回避を進めた結果として利 [...]]]></description>
			<content:encoded><![CDATA[<p>無駄、無駄、無駄！<br />
→効率化</p>
<p>リスク、リスク、リスク！<br />
→リスク回避（出来る事しかやらない、利益率が低い）</p>
<p>それはそれで間違ってはいないのですが、そこから利益が出ているのかが問題。</p>
<p>効率化とリスク回避を進めた結果として利益に結びついているのならひとまずＯＫ。<br />
上記と違って予算の低下に伴って効率化とリスク回避を進めているのであれば将来は暗い。</p>
<p>前者であれば生み出された利益から次への先行投資に繋がると思うのだけれど<br />
後者であれば企業的に全く余裕が無い。よって次に繋がる先行投資ができない。</p>
<p>全く当たり前のことなのだが周りを見回しても後者のソフトハウスが多すぎる気がする。<br />
みんな効率化を求めて余裕がない。営業はリスクの少ない案件を求めて利益が出ない。</p>
<p>一部社員は個人の時間を利用して次の技術を取得するが会社としてその技術が生かせる案件を<br />
受けないので意味が無く、結局やる気のある社員を流出させてしまう。</p>
<p>必要なのはゆとりなのだが、後者のソフトハウスにそれを求めるのは酷。<br />
陥ったら抜け出せないのかもしれない。</p>
<p>そうならない為にも効率化やリスク回避以外のものを企業は求めないといけないと思う。<br />
<span id="more-344"></span><br />
棚橋弘季さんの記事は秀逸。オススメです。</p>
<p>クリエイティビティ（創造性）の必要条件：DESIGN IT! w/LOVE<br />
<a href="http://gitanez.seesaa.net/article/35092849.html">http://gitanez.seesaa.net/article/35092849.html</a></p>
<p>セレンディピティと創造性：正しいやり方など存在しない：DESIGN IT! w/LOVE<br />
<a href="http://gitanez.seesaa.net/article/35166335.html">http://gitanez.seesaa.net/article/35166335.html</a></p>
<p>経営戦略における創造性と生産性：DESIGN IT! w/LOVE<br />
<a href="http://gitanez.seesaa.net/article/35231425.html">http://gitanez.seesaa.net/article/35231425.html</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070316/%e3%82%86%e3%81%a8%e3%82%8a%e3%81%ae%e3%81%aa%e3%81%84%e3%82%bd%e3%83%95%e3%83%88%e3%83%8f%e3%82%a6%e3%82%b9/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>経営の自立</title>
		<link>http://blog.setunai.net/20070308/%e7%b5%8c%e5%96%b6%e3%81%ae%e8%87%aa%e7%ab%8b/</link>
		<comments>http://blog.setunai.net/20070308/%e7%b5%8c%e5%96%b6%e3%81%ae%e8%87%aa%e7%ab%8b/#comments</comments>
		<pubDate>Thu, 08 Mar 2007 02:54:30 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070308/%e7%b5%8c%e5%96%b6%e3%81%ae%e8%87%aa%e7%ab%8b/</guid>
		<description><![CDATA[日本のソフトウエア産業、衰退の真因 http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/ 結論までがやたら長いがまとめに書かれている「経営の自立」が気にな [...]]]></description>
			<content:encoded><![CDATA[<p>日本のソフトウエア産業、衰退の真因<br />
<a href="http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/">http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/</a></p>
<p>結論までがやたら長いがまとめに書かれている「経営の自立」が気になったのでエントリー。</p>
<p>いろいろなプロジェクトでいろんなソフトハウスの人と話すがやはり請負の業務を減らす方向になっているようだ。<br />
確かに請負はリスクが高い。経営者としては避けたい気持ちは痛いほどわかる。<br />
私自身、いくつかの請負プロジェクトで赤字を出したこともある。</p>
<p>それでも請負プロジェクトをやるべきだと思う。<br />
なぜなら派遣での経験は個人に蓄積されその個人が抜けてしまうとゼロになってしまう。<br />
請負ではチームで仕事することができ会社として経験を蓄積することができる。<br />
さらに蓄積される経験にもかなりの違いがある。</p>
<p>請負では確実に人、時間、金そしてリスクを意識しなくてはならない。<br />
そういった経験はなかなか派遣では蓄積することができない。できたとしても個人レベルの範囲となる。</p>
<p>短期的にみれば派遣が確実だと思うがこのままでは勝負する力もなく価格競争に巻き込まれて消えていくだけではないだろうか。</p>
<p>個人の自立も必要だが<strong>経営者の自立は必須</strong>だと思った。<br />
<span id="more-345"></span><br />
■TB先</p>
<p>furyaの日記<br />
<a href="http://d.hatena.ne.jp/furya/20070306/1173189838">http://d.hatena.ne.jp/furya/20070306/1173189838</a></p>
<p>CMAP21の独り言～IT業界について考える: 日本のソフトウエア産業、衰退の真因<br />
<a href="http://blogs.dion.ne.jp/cmap21/archives/5217695.html">http://blogs.dion.ne.jp/cmap21/archives/5217695.html</a></p>
<p>morioXのもくもく日記 &#8211; しつこく風邪でお休み<br />
<a href="http://d.hatena.ne.jp/morioX/20070307#p3">http://d.hatena.ne.jp/morioX/20070307#p3</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070308/%e7%b5%8c%e5%96%b6%e3%81%ae%e8%87%aa%e7%ab%8b/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>代替可能な人員と言われる事</title>
		<link>http://blog.setunai.net/20070125/%e4%bb%a3%e6%9b%bf%e5%8f%af%e8%83%bd%e3%81%aa%e4%ba%ba%e5%93%a1%e3%81%a8%e8%a8%80%e3%82%8f%e3%82%8c%e3%82%8b%e4%ba%8b/</link>
		<comments>http://blog.setunai.net/20070125/%e4%bb%a3%e6%9b%bf%e5%8f%af%e8%83%bd%e3%81%aa%e4%ba%ba%e5%93%a1%e3%81%a8%e8%a8%80%e3%82%8f%e3%82%8c%e3%82%8b%e4%ba%8b/#comments</comments>
		<pubDate>Thu, 25 Jan 2007 09:09:39 +0000</pubDate>
		<dc:creator>t</dc:creator>
				<category><![CDATA[提案・開発・運用]]></category>

		<guid isPermaLink="false">http://blog.setunai.net/20070125/%e4%bb%a3%e6%9b%bf%e5%8f%af%e8%83%bd%e3%81%aa%e4%ba%ba%e5%93%a1%e3%81%a8%e8%a8%80%e3%82%8f%e3%82%8c%e3%82%8b%e4%ba%8b/</guid>
		<description><![CDATA[「アート・オブ・プロジェクトマネジメント」を読んでプロジェクトでの信頼関係が いかに大事かを再認識したのだけど 実際の現場ではこう思われてるの？ 代替可能なシステムエンジニア 代替可能なプログラマ リスクを管理するうえで [...]]]></description>
			<content:encoded><![CDATA[<p>「アート・オブ・プロジェクトマネジメント」を読んでプロジェクトでの信頼関係が<br />
いかに大事かを再認識したのだけど</p>
<p>実際の現場ではこう思われてるの？</p>
<p><strong>代替可能なシステムエンジニア</strong><br />
<strong>代替可能なプログラマ</strong></p>
<p>リスクを管理するうえでプロマネが考えなくてはいけないことかも知れないが<br />
自分がそう思われていると思うと辛い。</p>
<p>ksh Days &#8211; プログラマのスキルレベルに依存しない体制ができたらプログラマはいらないような気がする件について<br />
<a href="http://d.hatena.ne.jp/ksh/20061230/1167490514">http://d.hatena.ne.jp/ksh/20061230/1167490514</a></p>
<p>304 Not Modified: ＳＥの理想とプログラマの理想<br />
<a href="http://maname.txt-nifty.com/blog/2007/01/skill.html">http://maname.txt-nifty.com/blog/2007/01/skill.html</a><br />
<span id="more-327"></span><br />
関連記事</p>
<p>せつないぶろぐ : アート・オブ・プロジェクトマネジメント<br />
<a href="http://f56.aaa.livedoor.jp/~tdnr/ppblog/index.php?id=06120007">http://f56.aaa.livedoor.jp/~tdnr/ppblog/index.php?id=06120007</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.setunai.net/20070125/%e4%bb%a3%e6%9b%bf%e5%8f%af%e8%83%bd%e3%81%aa%e4%ba%ba%e5%93%a1%e3%81%a8%e8%a8%80%e3%82%8f%e3%82%8c%e3%82%8b%e4%ba%8b/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 1.043 seconds -->

