初心者エンジニアの備忘録

プログラミング・インフラ構築関連、読んだ本の記録などを書いていきたいと思っています。そして株などの投資関連にも興味があります。

【読書】システムを「外注」するときに読む本 細川義洋(ダイヤモンド社)

[ç´°å· ç¾©æ´]ã®ã·ã¹ãã ããå¤æ³¨ãããã¨ãã«èª­ãæ¬

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 ★★★★