なぜか http://www.amazon.co.jp/dp/4822281108/ が読まれているように、システム開発の特に人にまつわる問題は相変わらず変らないように思える。 品質や生産性に関する議論も、60年代あたりの調査や考え方から大きく変っていないようにも思える。（すべての…

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

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

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

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

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

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

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