人月は悪どころか、ものすごい善かもしれない - レベルエンター山本大のブログ
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね？」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
インターンシップとか募集してみるテスト | fladdict
「寄付ハック」であったり、変なウェブサイトであったり、弊社ノベルティであったり、あまりお金にならない実験的なプロジェクトを色々したい！！ でも、ちょっと生計をたてる為のプロジェクトもやらなければならない。手が二本しかないのが口惜しい今日この頃です。 なので僕の悪巧みを色々と実験してくれるインターンさんとかを大募集したいのですが、どなたか暇な人はいませんでしょうか？ 業務内容 ・僕が印刷やサーバーや光造型の予算を出すので、僕のかわりに、僕の変な実験を色々と代行してくれる人。 募集要項 ・暇な人 (社会人可、学生可）。 ・たまに飯田橋、牛込神楽坂に通える人。 ・ノートパソコン持ってるとステキ。 ・業務・趣味どちらでもいいので、自分で手を動かしてなんか作った事ある人。 報酬 ・iPhoneとかiPadアプリに関する助言、ノウハウあげる ・ブログとかTwitterとかに関する助言、ノウハウあげる
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
成功するベンチャーと失敗するベンチャーの違い | きらら2号
以前書いたスリム ベンチャー（原題は lean startup）の Eric Ries さんの講演ビデオがあったのでご紹介します。 （英語） 全部で一時間なのですべてを紹介できませんが、エッセンスだけ箇条書きでかきます ・これまで多くのベンチャーが生まれているが、そのほとんどがなくなっている ・なぜ彼らは失敗したのか？ → ユーザが望まないものを提供していたからだ ・ベンチャー（スタートアップ）は不確実な状況で新しい製品やサービスを生み出す人間の集まりだ。 ・企業家精神とはマネージメント科学である ・成功するベンチャーも失敗するベンチャーも初めはよくないアイデアで始まっている ・成功するベンチャーは少しずつ変化している、そして、変化しながらも明確なゴールへ向けて進んでいる ・成功するベンチャーは少しずつ変化している、そして、その変化のスピードがはやい ・ビジネスプランを作る時に「シャドービ
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PC