早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…
はてなブログ | 無料ブログを作成しよう
早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…
人月計算とExcelとスーツの世界より・アフター
http://anond.hatelabo.jp/20080323175904 半年前に「人月計算とExcelとスーツの世界より」を書いた増田だけど、この増田が他人に思えなかったので、半年ぶりに自分の話をしたいと思う。 半年前のエントリの内容、読んでない・読むのたるいって人のために簡単にまとめておく。 俺はCOBOLっていう昔々の言語を使って巨大な金融システムのお守りをしていた。それは誇らしい仕事（「これ読んで「転職考えろ」とか言ってるやつってアホだろ」的な意味で。これももっともな話だよね）ではあるんだろうけど、俺はやっぱりキャッチーな新技術がやりたくてたまらない。 そんなふうに増田に愚痴ったところ、なんか400以上のブクマがついた。以上がこれまでのあらすじ。 話の続きを始める。 あれほどのブクマを集めたことなど初めてだった。戸惑いながらも、日々増えていく皆のコメントを噛み締めた。 転職を
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
言語が解ることと言語を使いこなすことの違い
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45674 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
【XDev】「とりあえず作って，後から作り直せ」，Rubyのまつもと氏が語るエンタープライズ開発：ITpro
写真●「X-over Development Conference 2007」で講演する，まつもとゆきひろ氏 「結局のところ，顧客に何が必要かは，顧客にも開発者にも理解は不可能だ。そうならば，まずアプリケーションを作って，それを使ってもらい，顧客に合うように直すしかない。これからのエンタープライズ開発も，とにかく速く安く作って，直すことが重要になる」－－。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日，ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは，「YouTube」に代表されるように，「仕組みそのものよりも，データがどれだけ集まっているかが生死を分けている」（ま
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
受託会社とソフトベンチャーでは、そもそもスタートラインが違う - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さいきん、 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む http://blogs.itmedia.co.jp/repedant/2007/06/post_c660.html というブログが話題のようだ この議論自体は、１０年以上前だったとおもうけど（雑誌名が思い出せないし、資料が手元にないので、いった人ははっきり書かないけど）某会社社長が「受託開発は麻薬である」といったのと、ま、似ていると思う（ちなみに、コレは当時、受託とパッケージの両方をやっていた会社があり、当時の人は、どこの会社を批判したことか明確にわかる話だった）。 で、上記のブログのお話は、 （以下斜体はブログからの引用） １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受
MS、Oracle、IBMも本格参入？ 注目されるビジネスルール管理システム
「Microsoft、Oracle、IBMなどが、ビジネスルール管理システムに強く興味を持っています。今後、この市場が盛り上がることは必至です」と話すのは、Forrester Researchのシニアアナリスト、ヘンリー・ペイレット氏だ。BRMS市場の重要性と今後の展開について、フランス・パリのILOG本社で取材した。 ビジネスルール管理システムとは、ルール設定、変更、操作、管理を包括的に提供することにより、企業の業務プロセスを効率化するシステムと定義される。例えば携帯電話のキャリアの場合、「3年以上利用しているユーザーの場合、基本料を10％割り引く」などがビジネスルールである。企業のシステムはこうしたさまざまなルールが集まって構成されており、それがシステム内でいわゆる「ハードコード」（関連記事）されているケースも多い。そこで、BRMSによって、ルールとシステムを分離して管理することにより
真髄を語る：重要なソフトは外注せず自分で作る
ソフトウエア開発の経験が全くない素人集団を率いて、100％外注に頼っていた、基幹業務を支えるソフトウエアを内製に切り替えるプロジェクトに取り組んだ。この時の経験から言うと、ゼロからのスタートであっても、5年間真剣に取り組めば、ソフトウエアを自社内で開発・維持する体制を構築できる。現在、本業そのものを支えるソフトウエアに関してまで安易な外注が進んでいる。基幹部分は他人任せにせず、当事者が自らの手で内製できる力を持つべきである。 「交換機を作っているコンピュータ・メーカーに、交換機のソフトウエアを自分たちの手で作りたいと言ったら、『我々が手を引いたらNTTなんて成り立ちませんよ。お分かりなんですか』と脅されたよ。頭に来たな。石井君、どう思う。今のままでいいのか」 日本電信電話公社の真藤恒総裁は初対面の私にこうまくし立てた。電電公社が民営化され、NTTになる直前のことである。大阪の現場にいた私は
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
チームリーダー日記 : [メモ]日本人エンジニア派遣業
システム開発の日本人エンジニア派遣業は エンジニアのレベルに関係なく もうそろそろなくなるんじゃないかと感じる。 ＃何を今更、といわれそうなんだけど、 ＃両面とも臨界点に達した感じがする。 ---- これは悲しむべきことじゃなくて、 チャンスだと思ってます。 ---- 自分がどっちに転がるかは、自分の行動次第。 自分の周りがどっちに転がるかも、自分の行動次第。 ---- 今は、Web2.0とは何か？ なんてことを後付けで考えるよりも、 同時代、同年代のエンジニアとして こっちから切り込んだほうが感覚的にわかることが多い気がする。 就業形態とかそういう点。いやもっと前段の話か。 両者はたぶん、どっかで繋がる。 ---- なんというか、 ベテランの方はどちらも肌で感じ取ることができないらしい。 ---- 「目線は自分の進みたい方向に向ける。」 とオートバイの教習所と、スキー学校の両方で習ったな
仙石浩明の日記: なぜ人月見積もりが優れているのか
人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。 人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。 そもそもこれだけ嫌われ者の「人月見積もり」が
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：SaaS時代のベンチャー経営に求められる情報システムとは
現在発売中の月刊ComputerWorld10月号のSaaS特集に、著者の一人として寄稿しました。 「『サーバのないオフィス』でイノベーションを実感する」と題して全8ページ、渾身の記事です。 SaaSという言葉は、これまた例によって定義の広すぎるコトバですが、いわんとすることはソフトウェアを買ってきてインストールして使うというモデルからウェブ上にあるサービスをそのままブラウザ上でソフトウェア的に使うようになりますよー、という意味ですから、これまでの外しまくりな業界のバズワードに比べればリアルなトレンドをはるかにうまく捉えています。イメージ的にはWeb 2.0とも若干かぶるのですが、SaaSはどちらかというと「従来のガチなソフト屋から見たウェブへの進化願望」みたいな気分が表れたコトバだと理解しておけば間違いありません。（現にピュアでネイティブなウェブ界隈でSaaSというコトバが会話に出てくる
パッケージソフトは、コストが高いのよ。ダウンロードにしてもコスト０じゃないのよ！！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ウサギと亀の共通項が見えますか？ 「特殊への執着」が日本のソフトを弱くする http://it.nikkei.co.jp/business/news/index.aspx?n=MMITzv000018082006 について、批判されているようだが、その批判はさておき、いくらなんでも、これは・・・ と思う言葉がある。今回は、そこを問題にしたい。 それは （以下、斜体は上記IT+PLUSの記事より引用） ソフトウエア製品の複製は材料費と手間費と流通費がほとんどかかりません。普遍性が高く適用範囲の広いソフトウエアがあれば、膨大な利益を手にすることが可能です。 これが、真っ赤なうそだっていうことは誰でも知ってるだろう。 もし、本当ならＬｉｎｕｘのディストリビューターは、大もうけだ。 なの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームリーダー日記 : コード量＝借入金の額
http://chikura.fprog.com/index.php?UID=1186645498