お金が多ければいいわけじゃない。金銭的な報酬がもたらすマイナスの影響 | ライフハッカー・ジャパン
99U：金銭的な報酬が大きいほど、やる気がアップする。これが事実であれば、ある人物やチームのやる気を高めるのに必要なものは、多くのお金ということになります。ですが、物事はそうシンプルではありません。 お金のことに少しでも言及するだけで、私たちの考え方は変化します。お金が絡むと、私たちはより自己中心的になり、他人をライバルとみなすようになります。そして、大切な社会的関係をないがしろにすることがあります。また、大きな報酬が約束されると、かつては情熱やクリエイティビティを原動力に取り組んでいたことが、感情の入り込まない金銭の交換に変化してしまいます。 たとえば、余暇を使って本を書くとします。それは、大好きなことであり、あなたがずっとやりたいと思っていたことでした。 そんなとき、誰かがまだ途中のあなたの原稿を読んで、あなたに小切手を渡し、本を仕上げるように依頼したとします。余暇のプロジェクトは、い
僕と君とSIerの生きる道 - ひがやすを技術ブログ
SIerに対するバッシングは、高まる一方です。 私もSI業界からはさっさと抜けだしたほうがいいのエントリでSIerには未来がないからサービスを作る側に回ったほうが良いと書きました。 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 これは、自分でやってみての正直な感想。やらなきゃわからなかったことなので、自分のしたことに対する後悔はありませんが、日々ものすごいプレッシャーです。 チャレンジし続けないと落ちぶれてしまうのエントリの通り、私は現状維持を嫌い、常に新しいことにチャレンジする前向きな性格ですが、それでもこのプレッシ
2012-01-27
富士通の打ち出した方針をきっかけに色々と盛り上がっていますね。 以下のエントリには中堅SIerに勤めている身としては思うところがたくさんあります。引用しつつ少し議論してみたい。 ただし、一方でより本質的に重要なことは、クラウドの普及により、要件の定義から実現、運用までの期間が大幅に短縮できるようになったり、基盤構築など多くの仕事が自動化されることで、上流から下流まですべてを担当できるような真のソフトウェア技術者の役割がシステム開発で重要になってきているというところにあると思います。 ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して ちょっと前提の議論だけど、クラウドの普及で減る時間は、基盤の設計・導入コスト（ミドルウェアまで含む）が中心でその上で動くパッケージについてはクラウド云々ではないよね。もちろん、サービスそのものがクラウド上にある
上流設計はなぜあるのかとどうすればよいか。 - 水まんじゅう2
@ryoasai74 さんの開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？を読んでみて考えたこと。 上流設計が害になっているというお話ですが、これを考えるにはなぜ今のようなウォーターフォールという開発方式がでてきたのから考える必要があると思っています。 昔はコンピューターはすごい高価だった 誰もが書籍等では知っていて、今前線で活躍している人のほとんどが知らなくなってしまったことですが、昔はコンピューターはものすごい高価でした。それこそサーバー一台数億円という世界。そういった時代では動かしながら作るなんてことは非常にコストが掛かることであり、それこそ人間が机上で一度書いて書面でレビューをして、正しそうだということが判ってから打ち込んで実際にコンピューターで動かしてみたほうが安上がり、つまり、人の給料が誤差になるほどのお金がコンピューター
受託開発業界に本当の競争がないだけだ - Sean_SF’s blog
このブログ記事「人月は悪どころか、ものすごい善かもしれない」を読んでとても違和感があった。 筆者は、スマフォアプリは安いからヒットしても500万円程度で、かかる手間に対してリターンが少なすぎる、人月商売でかかった時間に対してお金をもらえる仕組みの方がもしかしたら善なのではないかと言っている。 それは違うと思う。価格はコストや競争で決まる。 コスト（原価）が100円だから利益を50円のせて150円にしようとか。ライバル会社が150円で販売しているからうちは140円で販売しようとか。 価格を決める根拠が人月であるか他のものであるかはどうでもいい。そこに競争があれば、自然と価格は決まっていく。あるいはその価格で作れないメーカーは勝てないだけだ。 日本のSI業界、受託業界で人月計算がまかり通っているのは本当の競争がないからだ。一方、スマフォアプリは世界中のデベロッパーを相手に、オープンなプラットフ
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
色んな意味で示唆的なエントリ。山本さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山本大＠クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日本のIT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し
「プログラマー」≠「PG」 - * untitled
私にとって、日本の中でだけ使われていると言われている「SE」・「PG」という役割は全て、プログラマーが担う職能だと思う。 「SE」・「PG」を別の人間が専任で従事する環境を善しとは思わない。 職種はあくまでもプログラマーという技術者・エンジニア。 プログラマーは自ら顧客と対話し・プレゼンもし本当に何が欲しいのかを自ら知り、そこから仕様を決め実装もテストも出来ないと務まらないと思う。 これから生き抜いて行く上で、また、自らの価値を高める為にもどちらか一方しかできないのではなく、どちらも必要に応じて役割を担えるようでありたい。決して「口」だけでも「作る」だけで終わらずに成果や対価となる結果をコンスタントに出すことを追求したい。 日本式の「SE」と呼ばれる状況がすでに不健全だと感じる。最近は万が一そう呼ばれると屈辱に似た感情を抱くようにもなった。文脈上「SE的な工程」という意味で他人に説明すると
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
Anything We can imagine,We can make real. - FC2 BLOG パスワード認証
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
「面白い仕事がしたい」は本当に大事なのか - takeborutaのブログ
仕事は面白いと思った方が楽しいだろうというのは、多くの人が賛同してくれるだろうと思いますが、人によって何が面白いのかはバラバラだと思います。よく面白い仕事だったらやりたいという話を聞きますが、面白い仕事とはそもそも何だろう？と思います。 面白いからハマルというのは大事なことですが、ずっと続けるとなるとどんなに面白い事でも飽きることはあります。 仕事が面白いと感じる時には、周囲からの評価、会社で重要な案件を任されているなどの所謂承認欲求が大事な要素であるとも思いますし、仕事の結果などに比例して、給与などに反映されるなどもあると思います。 面白い仕事をしていて周囲から羨ましがられる人は、与えられた仕事だけでは満足しない人が多いと思います。面白くない仕事のように見えても、自分から積極的に関わって面白い仕事に変えることができる人の方が最終的には強いと思います。 他人から面白い仕事だよなんて言われて
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
How to become a great software developer
Start with design patterns – Always start with a design pattern, then try to make your problem fit it. Ideally start with the pattern you have most recently read about as this is most likely to be the best one. Do programming Katas – Repeatedly solving the same simple problem is the best way to improve your coding skills. The faster you can do it, and the more you sense a feeling of ‘flow’ when
目からうろこ、工場のトラブルを解決した「ある工夫」が注目を浴びる : らばQ
目からうろこ、工場のトラブルを解決した「ある工夫」が注目を浴びる エンジニアの仕事はトラブル解決に多くの時間を取られますが、とある歯磨き粉会社のトラブル解決法がためになると話題になっていました。 その内容ですが、歯磨き粉チューブの入った箱が、ときどき空っぽのまま出荷されてしまうことを防ぐというものです。 チューブが入らず空っぽの箱ができてしまうのは生産ラインに問題があり、タイミングなどを調整しても100％箱に入るようにデザインするのは困難を伴いました。 工場にいるエンジニアは手がいっぱいだったので、会社のCEO（最高経営責任者）は経営陣を集め、外部からエンジニアを雇い新しいプロジェクトを立ち上げることにしたのです。 その流れで予算と計画を組み、6ヶ月の期間と800万ドル（約6億円）をかけて質の高いプロジェクトが実施されました。 これによって空っぽの箱ができるたびに重量不足を検知してベルが鳴
優れたプログラマになる秘訣は「我慢して他人のコードを読む」 - DailyJS | エンタープライズ | マイコミジャーナル
DailyJS - A JavaScript blog. Google CodeやGitHubをはじめさまざまなプロジェクトホスティングサービスが存在する現在では、オープンソースプロジェクトはとても簡単にはじめられる。ただし、そういったプロジェクトのすべてが優れた結果を残せるわけではない。大半のプロジェクトは終わらせることもできず、ただ誰にも触られることのない存在になっていく。 プログラマであれば誰しもより優れたプログラマになりたいと考えるだろう。WebにはプログラミングテクニックやTIPS、デザインパターンやアンチパターンなど、さまざまなプログラミングに関するノウハウがあり、多くのプログラマがそうしたノウハウを活用している。しかしながら、いくら努力してもいまいち自分のスキルの上達を感じられない方も少なくないだろう。 以前からよく言われていることだが、Alex Kessinger氏が7月2
Fearless Change 第一章の非公式翻訳 - kawaguti’s diary
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
プログラミング言語の簡単さ/むずかしさ
Scala をディスると PV が増えると聞いて。Scala、難しいよね（棒読み）。 そういう冗談さておき。プログラミング言語が簡単/難しいって何だろう。 How vs. What C# もよく言われるんですよね、「C# は簡単だ」というのも、「C# は難しい」というのも両方。で、よくよく話を聞いてみると、だいたい以下のような感じ: C# は文法が多い。概念覚えるのが大変だから難しい。 C# はやりたいことをやれるから簡単。 文法の簡単さ 「プログラミング言語マスター ＝ 文法を覚える」だというなら LISP でも使ってなさいってば。あの言語、超簡単ですよ。() の中にトークン並べるっての以外に何も文法持ってないから。 こういう意見って、要するに、How（どう書くか）ベースの簡単さなんですよね。 やりたいことをやる簡単さ プログラミングって手段であっても目的ではないわけで。What（何をし
「プログラミングへのこだわり」を方向づける - 設計者の発言
業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 いっぽう、そんな方針と明らかにそぐわない人たちがいる。彼らはプログラミングそのものに強いこだわりを持っていて、より良いコードをより多く生み出すことに生きがいを感じる人たちだ。チャーミングな彼らの姿を個別案件の開発現場で見るたびに、私はキャスティングの失敗事例を見る思いがして切なくなる。 それは全国チェーンの外食店の厨房に、新しい料理を生み出すことに情熱を覚える若者が働いているようなものだ。彼がどう工夫しても、全国一律の料理メニューを改変するのは難しいだろう。そんな才能あふれた若者には、本部の企画部門で働いてもらったほうがい
プログラミングに必要な６つの才能 - 久保清隆のブログ
ロシアの研究者 A.P.Ershovは、プログラミングに必要な才能として、６つを挙げた。 これは、確かにそうだなと思った。才能は磨いていけるものと信じて、これらの才能を磨いていけるように、メモをしておく。 プログラミングに必要な６つの才能 第一級の数学者の論理性 エジソンのような工学の才能 銀行員の正確さ 推理作家の発想力 ビジネスマンの実務性 協同作業をいとわず、経営的な関心も理解する性向 第一級の数学者の論理性 出現するケースをもれなく拾いあげる能力 実行の条件を正確に決める能力 この能力を高めるための書籍 プログラマのための論理パズル 難題を突破する論理思考トレーニング 作者: Dennis E. Shasha,吉平健治出版社/メーカー: オーム社発売日: 2009/03/26メディア: 単行本購入: 21人 クリック: 412回この商品を含むブログ (63件) を見る論理トレーニン
クラウド時代の人材とは、設計もできて運用も分かる人
「クラウド時代のIT人材像」という特集が日経コンピュータ5月12日号に掲載されています。 クラウドの時代になると、システム開発をして納品すれば終わり、というこれまでのビジネスから、システムを開発して納品してからもずっとクラウド上でその運用と改善を続けていく、という新しいモデルに変わっていきます。国内の大手ベンダーが、そうした変化を見据えて人材育成に取り組んでいることを伝える特集になっています。 運用重視、アーキテクチャ重視 クラウドに対応した人材とは、具体的にはどのようなスキルを身につけた人なのでしょうか？ 誌面から各社の声を拾ってみましょう。 富士通はライフサイクル全般についての精通を重視しています。 「クラウド時代のすべてのIT人材は、クラウドサービスの企画や設計、構築から稼働後の運用、改善まで、ライフサイクル全般について精通する必要がある」 NECはシステムインテグレーション＋運用ス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
