システム開発
作ったシステムを評価するために大金をつぎ込む。で、それに対する評価とか、その評価に対する評価とか考えると、評価する項目そのものを減らしたり、評価する閾値を下げたりすると、必要な金額が劇的に変わるんじゃないかなぁ…。何てことを、予告.inの話題…
プロジェクトは何を持って成功という？ http://d.hatena.ne.jp/AWAWA/20080604/1212599115#c1212624725 事業の継続性がカギな気がします。今後とも自分達が収入を得られるべく、最低限置いていかれない程度には進歩する必要があるし、収入を増やしたいならさ…
ダメなプログラムなら見たことあるけれども。 問題を人に付けてるだけだよね。
業務システム、特にSI屋が商品としているシステムではなくユーザ企業が自社システムとして開発したシステムをオープンソース化する流れになれば、もしかしてメリットが大きいんじゃないかと思ったりする。その企業の核となるシステム…例えば製造業なら生産管…
単価の高い少数の人が管理をして、単価の低い多数の人が手順どおり作業をすることは、経営者から見れば理想的でしょう。しかし、ソフトウェア開発はそれを100%可能にするほど進化していません。大規模開発が知識集約化するとは到底思えません。エンジニアリ…
うらやましい…。石川県の同業者ブロガーってあまり聞かないんですよね。隣の富山県だと凪瀬さんとか、福井県だとボタリカルLOVEとかも活発みたいだし。石川県の方、いらっしゃいます？すぐ顔見知りに当たりそうだけどｗ
SI屋は天才を必要としていないなんて、バカなこと言わないで下さい。 凡才やそれ未満だけでも仕事が回るような業界にしたツケを払わされてるのは、他ならぬ天才と顧客なんですから。 こんなの、いつまでも続くと思ったら大間違いです。
マネージメント面の問題がまだまだ多すぎて、効率よいアルゴリズムとか綺麗な設計とかを語るのはほとんど開発者の趣味程度にしか扱われないんだよね。実際にはそれほど必要とされてないし、「綺麗に越したことはないが、取り合えず動けばいい」ってのが現場…
標準技術の採用といっても特定ベンダ所有のパッケージを使う時点で切れないし、信頼性だって大した違いはないどころか、フレームワークやパッケージを直接修正できる可能性が残ってる分、緊急事態への対処が幅広い。オープンソースな業務システム作ったら、…
システム開発トラブルの原因のほとんどがマネジメントに起因すると言われているが、IPAといえば情報処理技術者試験だけど、PM試験問題を見たら愕然とするしかないし、経済産業省といえばIPAの監督省だけど、システム調達仕様書を見たら愕然とするしかない。
以前から規模と開発プロセスの関係について考えてきたんですが、結局、「開発プロセスは契約に依存する」という結論になるような気がしてきました。規模と契約は影響しあう、規模に影響を受けた契約が求める開発プロセスは自ずと変わる、そんなところじゃな…
6000人が作ったシステムは必ず動く | 日経 xTECH（クロステック）の記事は、 「2500億だろうが6000人だろうが11万人月だろうが8万テストケースだろうが232移行判定基準だろうが、そんな膨大な資源を突っ込んだからと言って、「必ず成功する」という根拠には…
e-messe金沢というイベントに行ってきた。「今後のITビジネス環境」と題して経済産業省の奥家敏和さんという方の講演があるらしいので、それ中心に。 今後のキーは「情報の集約と信頼性の確保」だとか。他にも「Web2.0」だとか。はてな村のみんな、はてブは…
開発チームの編成と機能のカプセル化を一致させた方がいいと思う。異なるチーム間のコミュニケーションは、同一チーム内のそれよりも当然コストがかかる。隣のチームの開発範囲をカプセル化することによって、コミュニケーションコストを抑える。規模によっ…
で、そう考えると「業務システムなんてTransaction Scriptで十分」ってのも納得できる。元々システムが小さかったり、サブシステム単位とかで機能分割がそれなりにされていれば、ヘタに多層化して冗長な構成にする必要はない。オレオレカプセル化というか、…
取引ができなかったのは、取引対象が旧東京三菱銀の店舗の口座で、かつ通帳に未記入の明細が10件以上あるときに限られる。この条件を満たす場合、三菱東京UFJ銀のシステムは、通帳記帳を促す案内文を取引結果データに加えて、セブン銀に送信する。この案内文…
と言ってしまうと身も蓋もないってか何も言ってないのと同じなので、もう一歩踏み込んだほうがいい。
ソフトウエアが大規模化すると等比級数的に生産性と品質の確保を難しくする。したがって小さなシステムと大規模な基幹系システムを同等に捉えることはナンセンスだ。構築にかけた金額で言えば1000万円のシステムと、１億円または数十億円以上のシステムは、…
通りすがり 2008/04/17 10:34 どうやら、「単体テスト」の認識も食い違っているようです。 このへんで私は退散します。 oredoco 2008/04/17 13:30 オレ認識の単体テストというのは、一般的だと思います。 http://d.hatena.ne.jp/oredoco/20080415/1208222548…
確かに面倒ですよね。試験表だろうとxUnitだろうと何だろうと。いやいや、テストのメリットはわかりますよ。十分にわかります。でも、面倒なんです。 書くのが面倒 頭の中に入ってるし 動かせばわかる 作りながら動かしてるし 保守とか、心配しすぎだろ 今、…
「ソフトウェアの部品化」が失敗する理由という記事を呼んで。再利用は茨の道なんかじゃない。prototype.jsは？commonsは？wicketは？RoRは？大きさは違えど、みんな部品化され、広く利用されている。JavaとかRubyとかの言語レベルでも、広い意味では部品だ…
根本的には関係ないはず。なのに、巷では開発プロセスは規模の大小の影響を受けるというような言質は多い。「アジャイルは大規模に向かない」って、真実かどうかは別として、聞いたことない人いないですよね。開発プロセスが理想に程遠いのか、それとも新し…
ギークは新しい技術に目がないが、スーツは枯れた技術が大好きだから。 考察（蛇足） スーツはシステムを作らない人ということで、特にマネージャを指すと考える。ギークはシステムを作る人とする。直接部門と間接部門。*1で、スーツの主戦場であるマネージ…
確立したシステム開発プロセスが存在していないなら、必要です。枯れた技術を用いた枯れたプロセスで進めるなら、マネージャの負担は軽くなります。マネージャの負担は、枯れた技術に対する新しい技術の割合に比例します。
細部を作りこまずに抽象的な概要をコード化するって大事だと思うし、それがオブジェクト指向設計の醍醐味だと最近ようやく気付いたんだけど、プログラム＝具体的で詳細な実装で慣れきった人からすれば、意識の転換をしなきゃ難しかったりするんだよね。まぁ…
だよなあと思うけど… - Kowの日記という記事から言及されたので、もうちょっと考えてみた。 それがダメなのかといえば、それでいいと思う。建築家が製図だけしてとび職やらないみたいに、そういうのはうまくやれればうまくいく方法なのだと思う。 設計をどう…
到着記念。すべて日本語なので、ご安心くださいｗ http://www.ogis-swe.jp/process/am-res/am/artifacts/ モデリング（＝モデル化＝業務設計？）のtips。具体例があり、かなりわかりやすい。 からの抜粋らしい。 モデリング成果物の欄の順番は、粒度順や作成…
仕様書やプログラムを書く大変さ - GeekFactory http://d.hatena.ne.jp/oredoco/20080415/1208222548 プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - yvsu pron. yas 上の方々の記事を読んで、その「プログラム設計書」って何な…
要件を決めるのは技術力以外のことが求められることが多いし政治的な領域であるため、要件定義は実装に強い人をアサインしても何にも生まれない。「御社の事業において今回このシステムをどう使わせるのですか」というのが要件定義。そこでは実装の話は不要…
って何なんだろう？ 良い ⇒全てを同時に満たすのが可能かは考慮しない。 開発環境と連携できる。 環境設定が簡単。 制約がわかりやすい。暗黙の制約がない。 コードの記述は少ないほうがいい？ 何をどこに書けばいいかわかりやすい。 動作が追いやすい。 低…
