＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
大学でコンピューター工学を習ってもシステムが出来ない理由、逆に習わなくても出来る理由 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 大学で、情報処理学科で勉強しても、現場ですぐに役立たない、一方、情報処理学科でないひとが、コンピューターの会社に入って、それも情報処理学科の人と一緒に研修をうけて、ＳＥとしてやっている。おかしいじゃないかという意見をきいた。 おかしくないとおもう。 情報処理学科で習うのは、コンピューターサイエンスであって、 会社で、システム開発でＳＥが行う作業は、「業務のモデル化」であって、それは、情報処理学科とも、いや、理系とも関係ない、というか、もっというと、文系に近い。 コンピューター工学は、コンピューターの（要素）技術をならう。 ＣＧとか、ネットワークとか・・・ でも、システムを開発するとき、それらの要素技術を使ってもいいけど、使わなくてもいい（ローテクで固めてもシステムである。例：Ｅｘ
何故か使われないUNICODE項目
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45675 トラックバック - 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)
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
小野和俊のブログ:そして、ペア･プログラミングが始まる
ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 １セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends
受託会社とソフトベンチャーでは、そもそもスタートラインが違う - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さいきん、 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む http://blogs.itmedia.co.jp/repedant/2007/06/post_c660.html というブログが話題のようだ この議論自体は、１０年以上前だったとおもうけど（雑誌名が思い出せないし、資料が手元にないので、いった人ははっきり書かないけど）某会社社長が「受託開発は麻薬である」といったのと、ま、似ていると思う（ちなみに、コレは当時、受託とパッケージの両方をやっていた会社があり、当時の人は、どこの会社を批判したことか明確にわかる話だった）。 で、上記のブログのお話は、 （以下斜体はブログからの引用） １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受
Geekなぺーじ：エンジニアは下らない質問をする
「バナナはおやつに入るんですか？」という質問をしたことがあるエンジニアは多いと思います。 私も真っ先にそのような質問をした覚えがあります。 で、実際にバナナを持ってくる人がいるかというと、私は見たことがありません。 エンジニアって一般人から見ると変な、もしくは下らない質問が大好きな人種なのではないかと思う事があります。 エンジニアというよりもプログラマかもしれませんが、全ての事をswitch case文で考えて、条件分岐の白黒をはっきりさせたがってしまうのではないかと思うのです。 以前、マンション営業をする友人に「職業がエンジニアな人がお客さんだと面倒なときがある」と言われた事があります。 最後に契約書を確認する際に、非常に細かいところを確認したがって面倒であるそうです。 (私は細かく確認しない大多数の人の方が間違っているとは思いますが。。。) 細かい話になってくると、例えば受け渡しの前に
MS、Oracle、IBMも本格参入？ 注目されるビジネスルール管理システム
「Microsoft、Oracle、IBMなどが、ビジネスルール管理システムに強く興味を持っています。今後、この市場が盛り上がることは必至です」と話すのは、Forrester Researchのシニアアナリスト、ヘンリー・ペイレット氏だ。BRMS市場の重要性と今後の展開について、フランス・パリのILOG本社で取材した。 ビジネスルール管理システムとは、ルール設定、変更、操作、管理を包括的に提供することにより、企業の業務プロセスを効率化するシステムと定義される。例えば携帯電話のキャリアの場合、「3年以上利用しているユーザーの場合、基本料を10％割り引く」などがビジネスルールである。企業のシステムはこうしたさまざまなルールが集まって構成されており、それがシステム内でいわゆる「ハードコード」（関連記事）されているケースも多い。そこで、BRMSによって、ルールとシステムを分離して管理することにより
「ＰＧは卒業を迎えちゃう」を考える
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45676 トラックバック - 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)
「売上伝票の取消をやめた」の実装
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45676 トラックバック - 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)
デスマーチになるのは、プログラムが書けないからでなく、”おじさんの運動会”だからだ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さいきん、これ どうしてプログラマに・・・プログラムが書けないのか? http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm がはやっているようだ。 この文を読んで。。 あー、この書いた人がプロジェクトマネージャーになったら、開発はデスマーチ、プログラマは地獄だろうなと思った。 どうしてか。。を書く前に、まず、ここで話題になっている話を１つ （以下斜体は上記サイトより引用） ここでは、「Fizz-Buzz問題」というのを取り上げている。 それは、 1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、
真髄を語る：重要なソフトは外注せず自分で作る
ソフトウエア開発の経験が全くない素人集団を率いて、100％外注に頼っていた、基幹業務を支えるソフトウエアを内製に切り替えるプロジェクトに取り組んだ。この時の経験から言うと、ゼロからのスタートであっても、5年間真剣に取り組めば、ソフトウエアを自社内で開発・維持する体制を構築できる。現在、本業そのものを支えるソフトウエアに関してまで安易な外注が進んでいる。基幹部分は他人任せにせず、当事者が自らの手で内製できる力を持つべきである。 「交換機を作っているコンピュータ・メーカーに、交換機のソフトウエアを自分たちの手で作りたいと言ったら、『我々が手を引いたらNTTなんて成り立ちませんよ。お分かりなんですか』と脅されたよ。頭に来たな。石井君、どう思う。今のままでいいのか」 日本電信電話公社の真藤恒総裁は初対面の私にこうまくし立てた。電電公社が民営化され、NTTになる直前のことである。大阪の現場にいた私は
OPC Diary: 天才に凡人の苦悩はわからず、凡人に天才の苦悩はわからず
« 確かに5年間主流でいられる実装技術は少ない | メイン | まぁなんていうか » 2007年03月25日 天才に凡人の苦悩はわからず、凡人に天才の苦悩はわからず 登 大遊＠筑波大学情報学類の SoftEther VPN 日記 僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 彼がこれを実現できるのは、単純に普通の人が努力して考えなければならないことを無意識下でできるからだ。 なぜ無意識下でできるかというと、彼はプログラミングに対する適正を並のプログラマの1000倍ぐ
「はてな」で考える・・・ミッションクリティカルか否かの選択 - システムエンジニアの晴耕雨読：楽天ブログ
2007.03.10 「はてな」で考える・・・ミッションクリティカルか否かの選択 (3) テーマ：ビジネス・起業に関すること。(19346) カテゴリ：システム・ソフトウェア ３月６日のサン・マイクロシステムズ主催のセミナーで、 はてなのＣＴＯ、伊藤直也さんの講演「はてなのインフラ」の話を聞いて、 改めて再認識したこと。 「ウェブ進化論」の梅田望夫さんが取締役となり、 また、「人力検索はてな」や「はてなダイアリー」で有名な「はてな」さん。 社員２０名のベンチャー企業です。 ２００１年に、社長の近藤さんら３名の仲間が、資本金３００万円でスタート。 立ち上げ直後は、人力検索がヒットせず（いまは１０数万の利用者あり）、 残金３万円までに落ち込んだこと。 途中、受託開発で食い扶持を稼いだこと・・・等の苦節の時を経て、 ２００５年頃からブレイク・・今日にいたる。 面白かったのは、 伊藤さんもこだわっ
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
ハンター×ハンターに学ぶ自動化のススメ - 最速配信研究会(@yamaz)
レオリオ「なぜだ!?事実だぜ.トラブルさえなけりゃオレの友達はフラれることはなかった!!」 クラピカ「フラれたのか?」 レオリオ「決して仲が悪い訳じゃなかった.問題は法外な数のトラブルさ!!」 レオリオ「オレは単純だからな.トラブルを完全になくそうと思ったぜ. トラブル復旧も全部自動化してトラブル起こしても大丈夫なシステムを構築して "今日もノートラブルだな.こんな所にいないでさっさと愛する人のもとに帰れ帰れ" と言ってやるのがオレの夢だった」 レオリオ「笑い話だぜ!!そんな状況を作り出したら,今度は営業が新たな仕事を持ってきやがった!!」注. この話はフィクションですが,一部事実を含んでたりいなかったりします. あわせて読みたい WEB+DB PRESS Vol.37 作者: WEB+DB PRESS 編集部出版社/メーカー: 技術評論社発売日: 2007/02/23メディア: 大型本購
今日は楽しいバグ修正の日 : 小野和俊のブログ
昨日でこのところ取り掛かっていた大きな仕事が一段落したので、 今日からは待ちに待ったバグ修正の作業を始められる。 この1ヶ月、私はバグ修正がしたくてしたくてたまらなかった。 今朝は出社してすぐにバグレポートの一覧を表示して、 これは早く直さないとまずいな、とか、これはちょっと後でいいかな、とか、 レポートの内容を見ながら優先度順にバグを並び替えていく。 これからこれらのバグが次々に修正されていくのだと思うと、 もうこの時点でワクワクしてくる。 新しいソフトウェアのアイデアを考えるのは大好きだし、新機能を実装するのも大好きだ。 でもバグ修正には他の作業にはない独特の快感がある。 新しいソフトウェアを開発するのは見た目にも派手だし、世間の注目を集めやすい。 それに比べると既存のソフトウェアのバグ修正というのは地味で注目されない作業だ。 だが、バグ修正は確実に誰かの役に立つ。 もちろん、自分の考
はぶにっき - [Goya][Cuppa]Goyaを継ぐ者
はてなブログには、同じ話題でつながる「グループ」があります。まずはこちらの「2024年開設ブログ」に入りましょう。同時期に始めたブログとつながることができます。 「2024年開設ブログ」のグループ
![はぶにっき - [Goya][Cuppa]Goyaを継ぐ者](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
「ソフトウェアの仕様書は料理のレシピに似ている」へのフィードバックをいくつか集めてみた
一年近く前に書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリー。今になってもトラックバックやコメントが送られて来るのは、実際に日本のIT業界に働く人たちの間にも「今のやりかたはおかしい」という疑問や不満があるという証拠だろう。 そこで今日は、シオレットの引用機能のテストも兼ねて、よせられたフィードバックを新しい順にいくつか紹介してみる（それも、昨日になってやっとシオレットが動き始めたSafariブラウザーを使っての投稿だ^^）。 まして、優秀でないエンジニアがコードを書かずして、仕様書を作ることが出来ようか？ソフトウェア開発はウォーターフォールでは上手くいきません。 【さくねこの”チラシうら”にっきより引用】 別会社のSEが設計して、それを請け負った会社のPGが実装する。こんなやり方でまともなプログラムが作れたらある意味凄い。物凄いオーバーヘッド作業をこなして作るわけだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Technical documentation
