システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」 - 設計者の発言
◆設計図を見られたくない設計者たち 筆者もパネラーとして参加した「ＤＯＡ＋コンソーシアム第三分科会」の第１回会合「データモデリングって実際どうなの？(2005.2.15)」の議事録が公開された。読み物としてもなかなか面白いのでお勧めしたい（ただし閲覧するためにはＤＯＡ＋への会員登録が必要）。 とくに興味をそそられたのは、基調講演をしたテプコシステムズの國澤（くにさわ）氏のパネルディスカッションでの発言だ。社内での設計事例を集めたモデルライブラリーを作ろうとして挫折した理由として、彼は次のように語っている。 プロジェクトをやっている人自身が自分のつくったモデルを公開したがらないということがより大きな問題でした。自分が作成したモデルを公開して、周りから文句をつけられたくないというメンタリティが非常に強いようです。 ◆テクニカルレビューの困難 筆者も同じような経験をしたので彼の無念さがよくわかる
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
わたしが知らないスゴ本は、きっとあなたが読んでいる: 要求仕様戦争（その4）
■開発工程をどうこうする――「要求開発」というフェーズを設ける いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。 これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]。 例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC（品質管理）、生産物、バグトレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
