「ソフトウエア・ファクトリー最前線」というのが、ITProで始まり、第1回が「エンジニアを悲惨な状況から救う」だったのだが、「エンジニアを悲惨な状況に陥れる」と皮肉りたくなってしまった。内容はひどいと言うほどでもない。だが、「ファクトリー」とい…

ん〜、IQ低いからよくわからんのですけど、「生産性は測定不可能」ってことは良い・悪いって判断はまったく出来ないってことですよね。でも定性的には「あいつ生産性低いな〜」とか感じたりするのも事実ですよね。だから生産性の優劣というのは現実にはある…

「コーディングは設計か製造か」というエントリに対して。 コーディングは製造で、 プログラミングが設計だ。 という回答があったが。「プログラミングにおいて、頭でやるのが設計で、手でやるのがコーディングである」 と、言った方がいいように思う。 ハー…

「進行基準が日本のIT産業の“ガラパゴス化”を止める」だろうか？むしろ、IT版建基法改悪になるおそれが多分にある。 日本のIT産業の商習慣に問題が多いことは確かだが、「工事進行基準」を適用するのも、それはそれで問題がある。何度も指摘していることだが…

「ソフトウエア・ファクトリー」という言葉を聞くと、「鵜の真似をする烏は水に溺れる」とか「猿真似」といった言葉を連想してしまう。ソフトウェア開発が製造業から学べる点は少なくないと思う。だが、単に真似するのはむしろ有害だと、過去の失敗からも言…

行数はコストの指標 「作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！」という記事。スラッシュドットジャパンでも、「日本のソフトウェア開発者の作業スペースや待遇は劣悪？」として取り上げられており、付け加えることは少ないのだが、一箇…

となると、大規模開発の鍵は「コミュニケーション」ということになる。 規模を問わず、「コミュニケーションがソフトウェア開発の鍵である」と言っても過言ではないと思う。

ある程度までは、人数を増やすことによって開発期間を短くすることができるが、それ以上に開発期間を短くしようとすれば、人数を減らすしかない。もちろん個人一人当たりの能力はより高いものが要求されるが、「ソフトウェア開発ではコミュニケーションが大…

ソフトウエアの機能が増加するだけならそれほど問題はないでしょう。しかし，ソフトウエア開発においては，仕様変更がほぼ確実に発生します。紙の上でソフトウエアの振る舞いを打ち合わせたときには納得しても，いざプログラムを見ると「やっぱり違う，直し…

「サマータイム、導入の動き再び」や「サマータイム関連2題」を疑問に読んでいて感じるのは、サマータイム制導入を推進しようとしている人々は、はたしてサマータイム制導入のコストがどの程度になるか、考えたことがあるのかということだ。日時はコンピュー…

サマータイム制を導入しようという動きがまたあるようだ。 http://slashdot.jp/articles/07/06/03/0939245.shtml 以前にも書いたことがあるが、サマータイム制導入は、Y2K以上のコストがかかる確率が高い、国内の企業の協力だけでは導入できない、などの問題…

野球選手をスカウトする時に、その選手のプレイを見ずにすませたりはしないと思う。プログラマの扱いは、アマのスポーツ特待生以下である。ということを「プログラマの面接」というエントリを読んであらためて思った。

命名規則全般が無い方がマシとは言わないが、無い方がマシな命名規則は存在するようだ。 「クラス名をC001などと命名する」のを否定できないような命名規則なら意味が無い。作るだけムダだから無い方がマシだろう。ましてや、「クラス名をC001などと命名する…

マニュアルや手順書を整備しておけばいいという主張をする人は少なくないが、一方ではマニュアルがきちんと読まれていないという事実がある。 技術を共有して普遍化しておくこと。しかし難しいよな。機械に備え付けのマニュアルを読まない人たちに、当院ＮＩ…

経営に貢献しない情報システムはゴミ同然である。大金を使ってゴミを作った情報システム部門は解散させられても文句は言えない。逆にシステムのできはまあまあだったにもかかわらず，事業部門が使いこなせずにゴミにした場合，その事業部門は懲罰ものだ。ゴ…

「ユーザーの弱体化がIT業界を駄目にした！？」という記事がある。「ITベンダーはこれ以上悪くならない」とか頷けない部分もあるが、「ユーザーの弱体化」と「IT業界の弱体化」との関係に言及している点で「IT業界の弱体化」だけを批判する多くの記事より、…

和訳された「プログラマの権利宣言」が話題になっている。 http://slashdot.jp/developers/07/04/13/0159204.shtml http://d.hatena.ne.jp/textfile/20070412/rights http://blog.livedoor.jp/dankogai/archives/50808441.html 「すべてのプログラマは静かな…

JavaBlackさんの「モデリングと設計の違い」で紹介されていた。 こうやって考えると、ソフトウェア「設計」と呼ばれている工程は、実はモデリングであることが大半なんじゃないかな。だってそのままじゃ作れないんだもん。「これだけの情報があれば作れる」…

うちの会社に入ったときにまず教えられたのは、大きなプロジェクトでは優秀なプログラマの影響は限定的であるというものでした。つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限りなく小さくなり、プロジェクトは全て人月で計算するのが当…

木走日記に「日本のソフトウエア生産性と品質は世界最高水準」というエントリが書かれているが、残念ながら、品質はともかく、日本のソフトウェア開発の生産性が世界最高水準というのは誤解である。そもそも、ソフトウェア開発の生産性については、評価に耐…

昨日、「サマータイム制導入という愚行(2)」を書いたが、アメリカのサマータイム延長による混乱は、ミニチュア版Y2Kの様相を呈してきているようだ。 http://www.itmedia.co.jp/enterprise/articles/0703/13/news015.html

「夏時間延長に伴うプログラム修正に苛立つMicrosoftユーザーたち」という記事でサマータイム延長による混乱が紹介されている。「サマータイム制導入という愚行」というエントリを書いたことがある。サマータイムを延長するだけで混乱が生じる、ましてや、サ…

@ITの「開発をもっと楽にするNAgileの基本思想」という連載の第4回 「プチ・パラダイムシフトせよ！」が公開されている。内容については、おおむね賛成なのだが、一箇所非常に気になる台詞があった。「頭で考えるでない。感じるのぢゃ」という台詞である。こ…

ソフトウェアファクトリ研究会発足の報道に関してJavaBlackさんが、「大失敗に終わる」と予想しているが、全くそのとおりだと思う。ソフトウェアファクトリは1970年代から1980年代に試みられたが失敗に終わっている。失敗の原因もきちんと分析せず、同じこと…

「ソフトウェア開発に進歩がない理由」に関して批判があったので、回答しておこう。 もともとの話題になったITプロジェクトの実態とは！に紹介されている漫画を見てみるとわかるが、その名のとおり「プロジェクト運営」の問題を皮肉っている。この状況が変わ…

システムの効果が正確に見積もれないからシステムの開発コストが高く思える システムの開発コストが高く思えることが話題になっている。 http://blog.livedoor.jp/nulab_hashimoto/archives/50317318.html http://d.hatena.ne.jp/satoshis/20061021/p1 http:…

「ITプロジェクトの実態とは！」というエントリで取り上げられていたソフトウェア開発を皮肉った絵をきっかけに、ソフトウェア開発では30年以上も前の本が通用するという話題になっている。 http://www.dashiblog.com/blogs/000140.php http://blogs.itmedia…

「意図が伝わる設計書作成の心得【第1回】」って、タイトルからして大丈夫かと思わせる。意図は伝わらない、意図のかなりの部分は伝わらない、と割り切り、伝わらなかったということを如何に確認していくかがソフトウェア開発のポイントだと思う。そもそも、…

ソフトウェア開発における見積と言うと、ソフトウェアの開発コストの見積ばかりが話題になって、それと同等に重要な見積が無視されていることが多い。それは、開発するソフトウェアの価値の見積である。ソフトウェアの価値がソフトウェアの開発コストより低…

ソフトウェア開発において、「プロセス改善に関する意見の食い違い」が起きる理由の一つは、「良いプロセス」というものが充分に明確になっていないことにある。 「本当に欲しいモノは顧客自身もよく判っていない」という要求に関する見解は、「プロセス」に…