昨日のエントリで取り上げた富士通のソフトが、“設計書からコードを自動生成できるという基幹システム開発支援ソフト、「プログラマーが不要」に？”と話題になっていました。その中に以下のようなコメントがありました。 これって、同じ設計書から全く同じ動…

富士通は金融機関や企業の基幹システムの開発を大幅に簡素化する支援ソフトを開発した。手掛ける業務の内容を日本語の一定の書式で入力すれば、コンピューター用のプログラム言語に自動変換する。システム開発費の４割を占めるプログラミング費用が不要にな…

一方、ＩＴ投資の売り上げに占める割合は、日本（1％）、アジア（3％）、北米（4.3％）、欧州（3％）と日本が世界で最も低く、アジアと欧州とは約3倍、米国とは約4倍の開きがあります（日本ユーザー協会）。 単純に計算すると、米国は、売り上げに対して4％…

趣味と化したオブジェクト指向 プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない…

色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 でもそれ以…

昭和44年度(1969年度)に実施された情報処理技術者認定試験(情報処理技術者試験の前身)では、対象とするプログラム言語は、「FORTRAN、ALGOL、COBOL、PL/I、アセンブラ言語のうちから一言語を選択」となっていました。この時点で既に高級言語によるプログラミ…

PC-9801の発売は1982年だし、Macintoshの登場は1984年だし、IBM-PCは1981年。これらのアプリケーションの開発はやっぱ当時アセンブラが主流だったと思うよ。Macintoshの場合Pascalの純正開発ツールがあったかな。「一太郎」の前に日本語ワープロソフトとして…

「例外中の例外」は言い過ぎだったと思いますが、1980年代はアセンブラが主というのもごく一部しか見ていない意見でしょう。 ん〜その言語が発表されるやいなや、普及したと勘違いしてるんじゃ？実態を考慮していない。たとえばAdaってほとんど普及しなかっ…

20年ほどずれている歴史認識 1980年代はアセンブラが主だったんだよね。これは職人芸の世界で、おいそれと誰でもプログラミングできるようなものではなかった。しかしその後高級言語(C言語とかC++とかJavaとかPerlとか)が主流になっていき、それに比例してプ…

全日空で10万席以上の座席指定の予約データを消してしまう事故が起きたようです。 全日本空輸は2012年11月28日、予約システムの誤設定により、2013年2月の国内線を予約した顧客の座席指定を取り消したと発表した。11月26日午後6時までに購入された2013年2月…

バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。 残っているのが「修正前」だという保障は無いので、ムダどころか、有害無益ですね…

最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 ソフトウェア開発はハードウェアで言えば設計に相当し、工場で行う…

そしてもし，顧客側がスキルもあって，行動も伴っていれば，IBM側がどれだけ低スキルであろうと，自分達のビジネスについての要件定義はスルガ銀側だけで独立して実行し完了できるはずなんですよ．通常はスキルもやる気もないから分析も何もかも全部SI側にお…

効果が疑わしく、費用が莫大なサマータイム制導入 今年は見送られましたが、エネルギー節約という名目でサマータイム制導入が今後も提唱されるおそれがあります。サマータイム制導入という愚策の息の根を止めるため、サマータイム制導入がなぜだめなのか、明…

「ソフト生成の自動化」は疑問。ただ、ソフトウェア工場（工業化論）は根強い人気を誇っていますね。設計と製造の区別が付いていない人が多くてげんなり。設計書があれば製造するだけだと思ってるからオフショアが大人気です。 「設計と製造の区別が付いてい…

相互依存する無責任な顧客企業と人月ビジネス SIビジネスと人月単価は鶏と卵の関係だから． どこか國の馬鹿大臣も言っていたが，「（一般競争入札にして）透明性の確保が重要」と考える人も世の中にはいるのだ．こういう人のいう「透明性(のある価格)」とは…

「リスクを漏れなく抽出し，対処方法を事前に決める」って……。リスクを漏れなく抽出できたかどうか何を根拠にわかるのだろうか?漏れなく抽出できたのか、それとも、漏れがあったがリスクが現実化しなかっただけか、区別できるのだろうか?

要件定義が充分かどうかは作ってみないとわからないんだってば。 世の中には宝くじにあたる運のいい人もいるのだから、「要件定義が充分」だった運のいい人もいる。「要件定義が充分」というのは、つまるところ、そういう話。運を実力と勘違いする人は多い、…

しかし、日本のソフトウェア開発では一般的に要件定義や仕様が固まらないまま、開発を開始し、要件を変更しながら作っていくケースが多い。その場合には、最初の段階で正確な見積もりを作ることが難しい。そのようなケースについて、篠氏は「そのようなケー…

ITproに「コンピュータの仕組みを知るのは，いつも楽しい」というCPUエミュレ−タ関連の記事があった。こういうのを読むと、ソフトウェアにおける開発はハードウェアにおける設計であることがよくわかる。ある機能をソフトウェアで実現するかハードウェアで実…

使いたい無料の有用ツールが使えないという不合理 「ぜひ使ってみたい，不満だらけの逸品を」という記事の利用しているツールの総合満足度ランキングで、Subversionが総合満足度77.5で5位になっていた。さらに、今後使ってみたいツール・ランキングでは、回…

言っていることは間違いではないけど、あまり意味がないように思える。 「ガミガミ屋」「マゾヒスト」を減らし、良い“システム屋”を増やすための鍵は、「評価」だと思います。 「減点法」などに代表されるように評価が適切に行われていないからこそ、“システ…

ソフトウェアの開発生産性の向上は、開発組織にとって永遠のテーマといえるでしょう。さまざまな言語やフレームワークが“生産性の向上”をうたい文句に、世に現れては消えていきます。しかし、それら新しい道具立てへの関心は、主に、「ゼロから構築するとき…

ところが。この本では、そういった変化に、驚くほど欠けているんですよ。おそらく10年以上も前から作って来た文書を、今もそのまま作ろうとしているように見えます。それはないんじゃないか、と。 もちろん、私のよく知らない開発現場はあるはずです。そこで…

一番いいのは、仕様の書き方を統一して、各社実行エンジンは、それを解釈して実行する機能と性能で競ってもらうという方法だ。COBOLやjavaは、言語だが、各社のOS上で動く。ただ、こういった言語ではなく、もっと業務に近い仕様書記述方式を定め、そのルール…

お客がお金を払うもの 技術が高度であればあるほど客との価格評価は大きくずれていく（加速度的に悪い方向に！）。 それが分かっていながら、プログラムの本当の値打ちとやらを高い報酬に結びつけようとするのか？ ありえない。 得られる報酬をもって自己の…

どんなものも経済的価値減少のリスクを抱えている 経済的価値など所詮他人が決める事だ。 その通り。だから。 直接的に利益を生む仕組みは、よりよい代替案があろうともその価値が減ることは無い。 これは成り立たない。よりよい「代替案」を他者(他社)が提…

後出しが反則なのはジャンケンだけではない 後から勝手に前提を付け加えたら議論にならない。 運用コストがかかるシステムは、「負債」という定義らしい。すなわち、この定義に従うと、会社も政府や自治体も、それどころか人間自身も「負債」ということにな…

やっと先日話題にしたとんでもないエントリに書いてあることがわかった気がする*1。 なぜなら「プログラム」は本質的に経済的価値を持っているわけではないので、プログラムを作る人、すなわちプログラマーは本質的に経済的価値をもつ存在ではないからです。…

ウォーターフォール大好き人間達にいつも言われたことは 「リスクと問題点は全て洗い出して解決しなきゃいかんのです。 随時解決するなんてリスクはとれませんよ」 よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。…