現代のソフト開発の生産性は1920年代の自動車産業並 － ＠IT
サイクスの代表取締役兼プリンシパルコンサルタント 宗雅彦氏は2月13日、DevPartner User Forum（主催：日本コンピュウェア）で「アジャイル開発2.0と自動化」と題する基調講演を行った。 宗氏の講演は、日本の製造業における生産方式の変遷と現代のソフトウェア開発における生産方式の状況を比較検討しながら、効率的なソフトウェア開発手法の解を提案するというもの。宗氏によると、（現代の）ソフトウェア開発の生産性は、1920年代の（米国の）自動車産業並だという。 モデルとなる企業はフォードだ。1913年に最初の移動組み立てラインを導入し、1927年までに「28時間で」（イタリア・トレント大学エンリコ・ザニノット氏の講演から）鉄鉱を自動車に組み立てることが可能になった。この時期、自動車業界における生産方式の常識は、製品の品質が個人のスキルに依存する「クラフト生産」方式から、「大量生産」方
「何かと便利」な設計方針？ - 設計者の発言
データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。 たとえば、次のような関数従属要件があるとする。 これが、たとえば次のように物理設計される。 なぜテーブルＤやＤＦに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度１のテーブル上に載っている項目（テーブルＤから見ればＡ、ＤＦから見ればＡとＤ）のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
UIEngineのデザイン・プリンシプル
このブログを書き始めて約１年が経つが、考えてみれば私の会社（UIEvlution Inc. 本社シアトル）がビジネスのコアに置いているUIEngineについてまだ一度もちゃんと解説していなかったことに気がついた。そこで、これから何回かのエントリーにまたがって、UIEngineとは何かどんな発想のもとに作られたのか、を書いていこうと思う。 第一回の今日は、UIEngineのデザイン・プリンシプル（良い日本語訳が無いのだが、あえて訳せば、設計理念）。デザイン・プリンシプルを持っておくことは、どんなソフトウェアを作る場合でも大切だが、特にUIEngineのようなプラットフォーム・ソフトウェアを作る場合には、しっかりと筋の通ったものを設計当初から持っておくことがものすごく大切である。 UIEngineのデザイン・プリンシプルは、ひとことで言えば、「いつまで経っても小さくて軽くてシンプルなウェブ・ア
東大での講演 - squeakerのブログ
(ちょっとだけ追記しました。その他1/25のあたりも見てみてください。) "Can programming be reinvented?"というタイトルでの発表。東工大と東大で似たような発表をしたのだが、ストーリーラインが比較的新しいため、先にやった東工大での発表には反省点がいろいろあり、それが東大での発表に生かされた形になったのは否めない、かもしれない。以下は、かなり再現性の低いメモ。詳細はさらに聞いてください。「私」はもちろんAlan Kayを指します。 近所の人から、「なんで新しいコンピュータのほうがWindowsの起動やMS Wordの起動が遅いの?」、「大きいディスクがついているはずなのに、なぜ使える容量が少なくなるの?」、「アップデートをしたら、何で再起動しなくてはいけないの？」という質問をされる。なかなか良い質問である。 私自身も、コンピュータに関する疑問がある。「なぜ、コン
販売管理システムの「会計３要素」 - 設計者の発言
卸売業向けの販売管理システムは、ソフト技術者がシステム設計を学ぶためには最良の案件である。まず卸売業の企業数が多いということがその理由のひとつだが、もっと重要なのは、骨格が共通している点だ。個々の企業の特性に合わせて販売管理システムにはさまざまな違いが生じるが、基本的な骨格は同じである。 その骨格とは、筆者が呼ぶところの「会計３要素」、すなわち「仕入」、「売上」、「受払」だ。販売管理システムはこれらの要素を周到に取り扱って、その数字を財務管理システムに渡さなければならない。それらが集計される過程で企業の特殊性は捨象されてしまう。そういうわけなので、その骨格を正しく理解しておけばシステム設計はぐっと楽になる。武道において腰や腹の安定が基本中の基本であるようなものだ。 「３要素」のそれぞれを説明しよう。「仕入」は買掛残高、「売上」は売掛残高、「受払」は在庫残高をそれぞれ増減させる取引である。も
チームリーダー日記 : [メモ]日本人エンジニア派遣業
システム開発の日本人エンジニア派遣業は エンジニアのレベルに関係なく もうそろそろなくなるんじゃないかと感じる。 ＃何を今更、といわれそうなんだけど、 ＃両面とも臨界点に達した感じがする。 ---- これは悲しむべきことじゃなくて、 チャンスだと思ってます。 ---- 自分がどっちに転がるかは、自分の行動次第。 自分の周りがどっちに転がるかも、自分の行動次第。 ---- 今は、Web2.0とは何か？ なんてことを後付けで考えるよりも、 同時代、同年代のエンジニアとして こっちから切り込んだほうが感覚的にわかることが多い気がする。 就業形態とかそういう点。いやもっと前段の話か。 両者はたぶん、どっかで繋がる。 ---- なんというか、 ベテランの方はどちらも肌で感じ取ることができないらしい。 ---- 「目線は自分の進みたい方向に向ける。」 とオートバイの教習所と、スキー学校の両方で習ったな
もう、class名やid名で悩まないんだからっ！！｜CSS HappyLife
class名やid名って付ける時悩みませんか？ 今でもボクは結構悩むんですが、そんな悩みを解決する為に、人さまのソース覗きまくってよくあるclass名とid名を拾ってきました。 これで、チョットだけ作業効率アップ！？ 2010年6月10日追記： この記事自体、2007年 1月15日に書かれてるんでかなり古いです。 あくまでも参考程度に留めてもらうのが良いかと思います。 今だったら、html5の要素を参考にしたりして付けるのが、今後の事を考えると良いのかなーと思います。 また、善し悪しの判断はせずに公開しているものですが、位置に関するのは仕様変更に弱くなるのでオススメはしません。 全体に使えそうな感じ wrap wrapper top-wrapper wrapperAll frame mframe all-frame container page pagetop all allContent
それでも設定が大事な理由 (arclamp.jp アークランプ)
ひがさんのエントリ「規約ベースのフレームワークのほうが覚えることが増える? 」を読んでいて、ふとした気づき。 暗黙的な規約は直感的ではない 結論から言えば、僕は"暗黙的な規約（Tacit Convention）"ではなく"形式的な設定（Articulable Configuration）"が重要だと思っています。ちなみに、Tacit Knowledgeは暗黙知でArticulable Knowledgeは形式知のこと。 なぜなら"暗黙的な規約"は、ある意味で直感的ではないからです。 人間が情報に反応するためには、情報が何らかの形で形式化されていなくてはいけません。 たとえば何かの操作を方法を学ぶ場合を考えてみます。説明書というのは操作方法を形式化したものです。しかし、直感的ではない。それは操作対象そのものに触るわけではなく、絵などで遠まわしに説明されているからです。 一方、説明書なん
ペアで働くと効率4倍 (ビジネス基礎体力)：NBonline(日経ビジネス オンライン)
「ペアプログラミング」と呼ばれる手法で、伊藤さんらプログラマーの間ではよく知られている。仕事の効率は「4倍、5倍にもなる」というのが実感だ。誰でも1人の時はついついメールをチェックしたり、ウェブサイトを見たりして、さぼってしまいがち。でも他人が横で見ているとさぼれないため、100％仕事に集中できる。 例えば数カ月前に作ったプログラムを見直して修正を加えるなど、あまり気が進まない作業をする際、伊藤さんはペアプログラミングをよく利用している。 メリットは「速さ」だけではない。仕事の質も向上する。横で見ている人がミスを指摘するので、間違いが起こりにくい。また、1人の時なら使わない、新しい技術を使おうという誘因が働く。「人が見ていると格好いいところを見せたいと思うから」と伊藤さんは言う。 伊藤さんは「仕事のエンジンがかかるのが遅い方」と自認している。自分を鼓舞して仕事にすぐ取りかかるために、ペアプ
分裂勘違い君劇場 - 大多数が余裕を持って暮らせる豊かな社会の作り方
世界には、労働力マーケットが２つある。 高能率労働者マーケットと低能率労働者マーケットだ。 高能率労働者マーケットでは、慢性の人手不足のせいで、賃金が上がり続けている。 企業と労働者の力関係は、圧倒的に労働者の方が強く、 企業は、労働者に頭を下げて、お願いして企業に来てもらっている。 当然だ。 企業は、その労働者から、給料以上の価値を受け取るのだから。 交渉では、常に、より多くのメリットを相手に与える方が、優位に立つ。 当然、高能率労働者の待遇はすごくよい。 これは、単純な需給バランスの問題でもある。 需要が大きいのに、供給が小さいから、労働力の価値が上がっていく。 労働者がでかい顔をする。圧倒的なパワーを持つ。 一方で、低能率労働者マーケットでは、世界的に、労働者の数はどんどん増えている。 その需要を上回るスピードで。 そのせいで、賃金は下がり続ける。ワーキングプアに転落する。 これも、
JavaWorld最終号 - なぜなくなるのか (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと遅くなってしまいましたがお知らせです。2007年2月号をもって最終号を迎えるJavaWorldですが、少しだけお手伝いさせていただきました。 GPL Javaのインパクトを探る まずはSpecial Report「GPL Javaのインパクトを探る」。これは何よりも星さんの記事が面白いです。客観的な歴史的事実に立ちつつSUNによるJavaOSS化 格闘の歴史を知ることができます。特に後半では、GPL化といっても、そこには曖昧さがある点も指摘され、これからおこる未来への予感が書かれています。オススメ。 で、ちょろっとだけコメントをさせていただきました。 JVM実装に選択肢が増える可能性がある。JBoss（LGPL）に対してGeronimo（ASL v2）が作ら
後藤弘茂のWeekly海外ニュース - 任天堂 岩田聡社長インタビュー(4) Wiiでは門外不出のノウハウをどんどん出す
■後藤弘茂のWeekly海外ニュース■ 任天堂 岩田聡社長インタビュー(4) Wiiでは門外不出のノウハウをどんどん出す 新世代のゲームコンソールWiiを発売した任天堂。Wiiでは、任天堂の内部で開発したソフトウェアのノウハウを、積極的に公開することでゲームデベロッパのサポートも充実させる。また、欧米のデベロッパにもアピールし、海外での成功も狙う。任天堂の岩田聡氏(代表取締役社長)に、ソフトウェア開発とそのサポートについて伺った。 ●任天堂のソフトウェアノウハウを社外に提供 【Q】 9月の合同記者会見の際に、私は開発環境について質問をしました。デベロッパ側のハードルを下げるために、任天堂がどのような取り組みをしているのか。それについて、次のように答えていただきました。 【岩田氏(9月)】 当然ながらゲーム開発の敷居を下げることは、私たちも非常に重要と思っています。Wiiでは、開発キットのハ
仙石浩明の日記: なぜ人月見積もりが優れているのか
人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。 人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。 そもそもこれだけ嫌われ者の「人月見積もり」が
Windchase: ソフトウェアの抽象性と具体性
ソフトウェアの抽象性と具体性 少し前に，ほぼ日刊イトイ新聞「智慧の実を食べよう。」より「第11回 私たちの『普遍性』ってなんだろう?」を読んで，普遍性と特殊性について少し考えていた．タイムリーに，今日うちの会社のCTOと部長の 3人で話をしていたのだが，その場で話題に上ったソフトウェアの分野での抽象性と具体性と，宇宙科学での普遍性と特殊性のトレンドに何か関連があるような気がしたので，忘れないうちに書いておく． これまでのソフトウェアの世界では，物事をどんどん抽象化していくことで，品質や再利用性が高まるということが当たり前のように言われてきた．しかし，ソフトウェアの目的によって，必要な物事の抽象度というのは，全然違うレベルになるのではないだろうか． たとえば，.NET Frameworkなどのライフサイクルが非常に長く，多くの人に使われるライブラリに求められる抽象度は高いと思う．.NET F
無視されているソフトウェアの価値の見積 - 酔狂人の異説(新館)
ソフトウェア開発における見積と言うと、ソフトウェアの開発コストの見積ばかりが話題になって、それと同等に重要な見積が無視されていることが多い。それは、開発するソフトウェアの価値の見積である。ソフトウェアの価値がソフトウェアの開発コストより低ければ、開発するのは無意味である。ビジネスとしては有害ですらある。 ソフトウェアの価値を無視しては、本来開発コストの評価などできない。 また、ソフトウェアの価値を無視しているから、単に開発コストを減らすことしか考えられず、ソフトウェアの価値を高めること、価値の高いソフトウェアを開発することを考えられない。結果として価格競争に陥り、ジリ貧になっている。
ウォーターフォール型開発が失敗する理由 - 酔狂人の異説(新館)
ウォーターフォール型開発が失敗する最大の理由は、コミニュケーションの難しさにある。 開発が成功するには意図を正しく伝える必要があるが、意図が正しく伝わっているか確認するには出来上がったもので確認するしかない。仕様書に意図が正しく反映されている保証はない。「プログラムは、意図した通りに動くのではなく、書いた通りに動く」というように書いた内容と意図した内容とを厳密に一致させることは極めて困難である。書いた内容と意図した内容とが仮に一致したとしても、その仕様書を正しく読み取ることもまた同じくらい困難である。 「ウォーターフォール」という言葉自体が、コミニュケーションの難しさをあらわしている。下記のページに書かれているように、ウォーターフォール型開発のもととなったのは Winston W. Royce の "Managing the Development of Large Software Sy
Dashi Blog - Variety Of Information at One blog
Diabetes is a condition which requires constant monitoring. Keep in mind that when it comes to screening your blood sugar people who are diabetic are advised to ensure that they buy testing kits. When you receive the test strips they are usually in a box, someone only needs a couple of them and then other Read More
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OPC Diary: いや、だから安易に自動車生産との比較はしても仕方ないというか、しちゃだめだろう
「レクサス」動かす1000万行――ソフトの品質を議論すべき時が来た【新連載】 ビジネス-最新ニュース:IT-PLUS
