どうして、システム屋は、システムの機能でしか物をいわないのか。 業務フローがすごく大事で、業務ルールが大事で、それを設計できる力があってはじめて、システムの必要性や重要性、効率の勘所がわかってくるんだけど、まったく聞かない人たちだ。って、誰…

十分に開発の事前条件（対象業務が明確）であれば、基本設計＋反復型の実装＋システムテスト、リリーステストで十分ではないかと。 いつでもリリースできる考え方ではなく、もちろん、アーキテクチャ確立のためだけど、もうひとつ、開発のリズムを高めるため…

久しぶりに書く。 新年早々（じゃないな、もう２月だから、新年１発目）、あまり面白くもない話。 品質保証。今の品質保証の考え方って汎用機での開発を前提に、JavaとかC#とかVBとか、言語レベルでの応用をしているだけじゃないのか？って思った。今のオー…

設計でしかわからないのであれば先にやる。 あらかじめやったほうがいいものは先にやる。 作るために最適の工程を考える。原則はこう。・作りたいものはどういうものかを考える（要求定義とか要件定義）・作ったものがいいのかどうかを評価する（総合試験と…

要件定義でスコープを明確にしろといわれて、機能の範囲は確かに決まった。 でも、詳細な粒度に当然落ちていないので、どれくらいの深さというか、どのくらい作りこみが必要なのかは決まっていない。 それによって、製造量が違うんだけれど、それって、設計…

ここでいうインテグレーションとは、 EAIとかSOAとかじゃなく、もうちっと組み立て的なイメージ。コンポーネント基盤（プラットフォーム）とコンポーネント。 車の車台、車体？と各パーツ（シートとかエンジンとか、なんとか。。。）と各パーツを構成する部…

今でも（ソフトウエア）コンポーネントの再利用ができると信じている人がいるらしい。たしかに、ＥＪＢが出たときには、コンポーネント再利用の話が出た。ビジネスコンポーネントとか、ソフトウエア機能コンポーネントとか、いろんな粒度のいろんな目的がご…

アジャイルと一言で言っても、手法にはいろいろある。XPでしょ、クリスタルでしょ、スクラムでしょ、リーンでしょ、・・・全部入りだと収拾付かないよね。 だから、教科書的な本が今のところバイブルになっていて、プロジェクトマネジメントフレームワークと…

言語仕様はシンプル。構文を覚えるのはそれほど難しくない。 英語的だから。でも、おまじない的メソッドがあまりないので すべてロジックとして作らないといけない。おまけに、データベースもすこし前までは、RDBじゃなく、 ロジックで一貫性を保つとか、い…

いよいよ最後。そういや・・・ いつから、要件定義や設計でドキュメントしか作らなくなったんだろう？きちんとウォータフォールを守るようになったんだろう。プロジェクトによって工夫をさせなくなったんだろう。スタートを改めよう。間違ったやり方の評価の…

前回のつづき。だめなものを使ってどうするっていっていたんだけど、、、 聞こえてくるわけさ・・・ウォーターフォールをやって皆が失敗しているわけじゃない。うまくいくプロジェクトはうまくいく・・・ってね。失敗するのは、ドキュメントがきちんとかけて…

アジャイル手法に取り組んでいかないといけない、とか軽量プロセスが必要とか、いろいろいう人がいるわけさ。じゃあ、ウォーターフォールはだめなのか？といえば、それはそれで必要だという。 じゃあ、どういうところに何を適用するのか？といえば、大規模は…

SOAを開発技術として捉えたら、サービスバス連携なんだろうか。サービスバスって、メッセージングバスだったけか。 ポイントは、サービスをレジストリ登録して、サービスを動的とはいわなくても、 かんたんなメッセージにより、経路とか変換とか気にしなくて…

開発をシンプルに考えると、デザインとプログラミングだけだよな。 作るものの設計をして、実装する。それだけ。 テストってよくわからないんだけど、まあ、それはおいといて、 要件定義ってなんだろう？ 何にも開発していないし。何を開発すべきか、その目…