【読書】システムを「外注」するときに読む本 細川義洋(ダイヤモンド社)
https://www.amazon.co.jp/dp/B071J1WQGS/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
システム発注者側の人間が、システムを構築する上で気をつけるべきことがストーリー仕立てで描かれています。
最初は初めてのシステム発注者として、そしてその後、システムコンサルの会社に出向し、コンサルタントとして様々なシステムに関わっていきます。
その中で、様々なシステム発注者 ・ベンダと仕事をしながら、失敗を通してシステム発注者として必要な素養を学んでいくストーリーです。
ストーリー仕立てであっという間に読めました。
私はベンダ側の人間ですが、発注者側の気持ちに触れることができたと思います。
気になった部分(知識部分も含めて)の備忘録。
◆備忘録
・要件定義:システムと、それを使う人の動作(業務)を決める作業。
・業務要件定義(発注者が全面的にリード):システムを導入して、どんな業務を実現するかを決める。
・システム要件定義:業務要件定義を実現するために、システムが持つべき機能を書き出す。
・機能要件(決めるのは発注者):社内のどの部門がどのように使って、そのために情報をどんな形で出力するか。
・非機能要件:処理時間、想定されるデータ件数、セキュリティに関する要望。
・システム化するのは、効果が明確に説明できるところだけ。
・システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えて決める。
・ベンダは発注者が決めることを決めないと何もしないし、PJの状況確認をしない発注者は見捨てられる。
・システム開発請負の見積もりでPJ管理工数は全体の10%程度。
・リスク管理表の対応策発動の閾値を決める(作業遅延5日を超えたときなど。定量的に)。
・システム化の目的を社長自ら全社員に刷り込む。ユーザ部門のキーマンの意識を変える。システム開発への参加を本業にするための体制を作り、その姿勢や実績を人事考課に組み込む。
・一度でも自社内のリスクを突き返されたベンダは、それ以降リスクを開示しなくなる。
・発注者が、ベンダが勝手に作業をしていることを知っていながら放置すると、それが事実上の要件合意と捉えられることがある(H15 5月8日東京地方裁判所 判決)。
・技術的な話は最終的にベンダが責任を持つけど、それを決める過程では発注者だって口出しして構わない。
・発注者はモヤモヤが消えるまで質問、注文を繰り返すことで、ベンダも今のやり方の正しさに自信が持てる。
・トリアージ:情報を、機密性の高さと漏えいしたときの影響の大きさを考量して分類し、それに応じた対応方針を決めておくこと。
・業務に必要不可欠なシステムであっても、セキュリティ上の不安が拭いきれないとあらば、即座に切り捨てる。
2018/7/19 ★★★★