Kindle読み放題の本でサクッと読めそうなタイトルが目に付いたので読書メモ。
システム開発を発注する側の目線で書かれていて、必要と思われる内容はひと通り触れられている印象です。また、受注する側としても目を通しておくと良い内容なのかな、と。
システム外注の基本的な考え方を知る
「何をシステム化したいのか」を具体的に定義（暗黙知→形式知に）して、業務フロー図を作成する。
業務フロー図などで現状の業務を見える化できたら、その結果を踏まえて「あるべき理想像（要件）」を決定する。その際には「理想と現実の落としどころ」を模索し、実現不可能なもの（絵に描いた餅）にしないことが大切。
要件はRFP（提案依頼書）として見える化する。RFPはベンダーのためだけでなく、発注者のためにも役立つ。（伝言ミスを防ぐ、発注者側の最終合意を助ける、紛争時の法的証拠となる等）
最低限の共通言語を身につける
非機能要件は曖昧になりがちなので、明確に定義する。
特に成果物の満足度に直結するUXはシステム外注における要注意ポイント。
システム開発プロセスについても理解しておこう。主にウォーターフォール型とアジャイル型。
システムをゼロから開発する「スクラッチ開発」はコストも失敗のリスクも高い。パッケージソフトの利用も検討しよう。
クラウドの概念はもはや欠かせないものとなっており、クラウドサービスであれば社外でも自社システムを利用できることになる。今後は自社専用のクラウドサービスを、システム外周でスクラッチ開発するケースが多くなるだろう。
「DevOPS」で開発者と運用者が協調できる体制を作ることが大切。開発と同じくらいに開発後の運用体制も考慮する必要がある。
外注先のベンダーはこうして選ぶ
ベンダーの選定はお見合いに似ているとのこと。うーん、確かに。。。
- いったん選ぶと長い付き合いになる
- 問題があっても分かれづらい
- 強引に関係を解消するとダメージが大きい
選定時点での面談でベンダーの本性を引き出す質問をしよう。嫌味に感じられるくらいの質問でも、力のあるPMは上手にさばくもの。確かに、こういうこと聞かれるとイヤーな気もします。。。
「意地悪な質問あれこれ」
- 御社の離職率はいかほどですか？
- 残業時間の多さはどれくらいですか？
- 過去に失敗事例はありませんか？
- 説明が専門的すぎてよく分かりません。もう少し易しく話して貰えませんか？
- お話に現実味が薄いように思うのですが、何か根拠はありますか？
- 当社のRFPについて疑問点はありませんか？
- 類似のプロジェクトに参加された経験はありますか？
YESマンよりも、あえて苦言を呈してくれるベンダーの方が貴重な存在。全て100点満点のベンダーはいない。自社なりに「譲れないこと」「いざとなれば諦めてもいいこと」に優先度を付け、ベンダーの評価基準（ベンダー採点表）を設けよう。
４つの評価ポイントをもとにベンダーを選定しよう。
- ベンダー採点表に基づく評価結果
- PMの素質（主に人物像）
- 見積の詳細や根拠等のオープン度
- 積極性（指示待ち型のベンダーが多い）
発注者とベンダーのすれ違いを防ぐ
まずは発注者側から正確な情報伝達に努めよう。
GIGO（Garbage in Garbage out）＝ゴミを入力すれば、結果としてゴミが出力されるのは当然。
出来上がるシステムの質は発注者が要件をベンダーに説明する能力に大きく依存することを肝に銘じることが大切。（「空気を読め！」は説明責任の放棄）
発注者とベンダーは対等の関係。特に昨今はベンダーに有利な売り手市場でもあり、時代遅れの「発注側の上から目線」は開発や運用保守契約を拒否されたりと大きなダメージを負いかねないことに注意。
ベンダーは技術の専門家であり、発注者の業務には詳しくない。発注者がベンダーに対して、自社の現状をレクチャーする「勉強会」の機械を設けるなどにより、多くのトラブルの発生を未然に防げるようになる。
ベンダーは発注者が思っている以上に進捗状況や懸念事項などを発注者に報告したくないと思っている。発注者はリスクマネジメントのために、情報を自ら積極的に取りに行く姿勢を持つべき。
ベンダーに丸投げするとプロジェクトの主導権を奪われる。最低限でも要件定義は発注者が主導して実施すること。
発注者が主体的に行うべき仕事を押さえる
発注者が”やるべきこと”は法律や判例で決まっている。
ベンダーのアウトプットのためには、しかるべきインプット（ベンダーに提供する各種資料）を作成することが法的な責務を果たすために必要となる。
必要なドキュメント個々について、どんなことを記述すれば良いかが軽く説明されていますが、詳細は本書を参照してね、と。
ベンダーと結ぶ契約で注意すべき法律上のポイント
システム外注でよくでるキーワード
まー、よく出てくる言葉ですね。これらの言葉は知っておいて損は無いかと。
・債権、債務
・瑕疵
・修補
・故意、過失、重過失
・担保
・善管注意義務
「請負」と「準委任」の違いを把握して適切な契約形態を選択しよう。
◆請負契約での注意点（発注者にとっても諸刃の剣）
- 要件定義は発注者の自己責任である
- 契約締結後の「要件」の後付けは困難である
- 「偽装請負」に抵触しないようにすること（直接指図できないからこそ要件定義が大事）
- 「検収」には責任を持つこと
◆準委任契約での注意点
- 要件の肥大化抑止に努めなければならない（費用を払えば要件の後付けも可能な点に注意）
- ベンダーの仕事ぶりの管理を怠らないこと
- 「偽装請負」に抵触しないようにすること（要求はベンダーの管理者（PM）に伝達）
全体を一括で請負契約とするのはリスクが非常に高いため、個々の工程に応じて「請負」と「準委任」を個別に契約する「多段階契約」を考慮すべき。
意外と見落としがちなのが、ベンダーの瑕疵担保責任は「任意規定」であるため、当事者間の契約によって「無過失責任」を「過失責任」に変更することも出来る点。そのため、契約書では「過失責任」に変更されていないかの確認が必要。
知的財産権について、ありがちな落とし穴
・契約書に明記しなければ、移転の対象から漏れる権利がある
特に「翻訳権、翻訳権等」「二次的著作物の利用に関する原著作者の権利」。
たとえ「著作権をすべて譲渡する」と契約書に書いても、権利譲渡の対象外と判断される点に注意。
・「著作権」を譲渡しても、「著作者人格権」は譲渡されない
「著作者人格権の不行使」の特約を契約書に盛り込んでおかないと、ベンダーの許諾なしではシステムを一切改変できなくなってしまう。
秘密保持と再委託に関する規定も必ず契約書に入れよう
特に直接取引するベンダーだけでなく再委託先にもベンダー同等の秘密保持契約を遵守させるよう、ベンダーにぎむずける規程を契約に盛り込む必要がある。
プロジェクトに全社員を巻き込み味方にするコツ
現場社員を巻き込むには「他人事」を「自分事」に変えることが大切。
新システムについて「教える」よりも「脅す」くらいのレベルがちょうど良いかも。
まとめ
最後に出てくる「事実に基づくフィクション」として、いかにもありそうなトラブル事例が会話形式で紹介されている。詳細は本書を読んでもらうとして、ホントにありそうな内容で笑えるような笑えないような。。。
タイトル通り、システム開発にあたって発注者目線で気をつけるべき内容をザッと把握するには良い本だなー、と。
コメント