よくある物語仕立てだが、情報漏洩など事件がなかなかシビア。
ITコンサルタントに求められる要求が高く、プレッシャーになる。
ツンデレな美人コンサルタントの設定は余計な気がする。

発注者の責任が前面に押し出されている。
発注者は「お客様」ではなく「プロジェクトメンバー」である、というスタンスだ。
確かにそれはその通りで、業務の内容はベンダーには分からないので、そこを発注者がはっきりさせないことで、失敗するプロジェクトは多いと思う。

「システム作りは業務フローから」というのも納得出来る考え方だ。
業務の流れも考えず、技術的な問題から検討を始めるシステム開発は上手くいかない。
業務フローに「その他」は使わないという指摘もよく分かる。
詰まると「その他」は使いがちだが、結局は仕様が曖昧になってしまう。
「システム化するのは効果が明確なところだけ」もその通りで、あれもこれもシステム化しようとするとコストばかりかさむが、誰も使わない機能が増えたりする。
「新システムを使う人と企業の『喜び』を表現する」というのも面白い。

プロジェクト参加者の意欲を上げるのは難しい問題だ。
本書では、システム導入後の関係者の表情を描く「フィーリングマップ」の作成を勧めている。
やったことはないが、面白いかもしれない。

社内の協力を得る方法や要件の必要性・十分性をチェックする方法など、実用的なノウハウが紹介されており、試してみたくなる。

[amazonjs asin=”4478065799″ locale=”JP” title=”システムを「外注」するときに読む本”]