何を得るために読んだか？読んだ目的
SEとして働くなかで、ユーザから見るとシステム開発がなぜ不満の種になるのかを知るため。
読んでどう感じたか？読了後に一言
軽妙な語り口でネタや比喩が多め。SEという生態がある意味的確に描かれている。
実際に得たものは何か？刺さったポイント
- 情報システムへの不満の根っこは技術ではなく、技術者の作りたいものと顧客の欲しいもののずれにある
- 手作業で最適だった仕事のやり方が、IT化したあとも最適とは限らない。むしろ違うことの方が多い
- かみ合わない言葉でもよいから、よく議論する
- 顧客は「専門用語で分からないので、一般的な言葉で言い直してください」と言ってよい
- オペレータなくしてシステムなし。開発側は、運用側と喧嘩をする不毛さを胸に刻む
- 要件定義での修正コストを1とすれば、でき上がってからの修正は100を超える。最初が肝心
- 具体的な目標が示されると、技術者は強い
- 同じ言葉でも、業界によって意味が違うことがある
- 問題が明確になった時点で、その問題は半分解決している
- 専門家の提案のいいなりにならず、議論を重ねてリスクを検討し、最後は顧客が判断する
- 機器は買い換えられても、データは代わりがきかない
- 検収では、システムが望んだ通りに動くかを自分の目で確かめる
- SEは錬金術師でも小間使いでも詐欺師でもなく、肩を並べて仕事をする仲間
目的を満たしたか？読んだ結果
ユーザから見てシステム開発が不満の種になるのは、技術より前に、技術者の作りたいものと顧客の欲しいものがずれたまま進むからだった。ずれを防ぐ手は、要件定義で具体的な目標を示し、かみ合わない言葉でも議論を重ね、検収で自分の目で確かめることにある。
今日から何をするか？読了後の第一歩
- 提案、要件定義のフェーズにおいては、顕在ニーズ、潜在ニーズを押さえるため、多様なステークホルダーとコミュニケーションし、文章化して、こちらから提案していく。
