【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） - やまもといちろうBLOG（ブログ）
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
ユーザーが消えたシステム開発の末路 プロジェクト成功に欠かせない「システムイニシアティブ」 | JBpress (ジェイビープレス)
前回、「システムイニシアティブ」についての話をした。システム開発はユーザー企業と開発側（ベンダーやシステム開発会社など）との「共同作業」であり、本来はユーザー側がイニシアティブを取るべきだという点を強調した。 「共同作業」が行われず、ユーザー側がイニシアティブを取らなかった場合、システム開発はどうなるのか？ 過去にあった事例で説明しよう。 ある会社（A社）が経営危機に陥った。A社の再建に当たることになった会社から、当社に依頼があった。 A社には自社で構築した汎用機のシステムがあった。だが、業務縮小に伴いシステムも縮小することになった。ついては汎用機から小規模サーバーにシステムを移し替えてほしいという依頼だった。 当社は受注するに当たって、以下の条件を受け入れてもらうことにした。 （1）まずは必要最小限の帳票機能の実現を目指す。要件定義後に、必要があれば追加設計と別見積もりを行う。 （2）従
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
