↓システムを「外注」するときに読む本
「システムを「外注」するときに読む本」を読んでみました。
それなりに、面白かったので、自分の経験なども踏まえ、その感想などをまとめてみました。
目次
システムを「外注」するときに読む本 とは
この本は、ITのシステム開発関連の本では珍しく「システムの発注者」向けの本です。
システム開発とかプロジェクトマネージメントとか、システムを受注してシステムをどう成功裏にカットオーバーするかについて書かれた本が多い中で、システムの発注者向けの本は珍しいと言えるでしょう。
システムを「外注」するときに読む本の目次
本書の目次は次の通りです。
はじめに
発注者は「お客様」ではなく「プロジェクトメンバー」
PART１
第１章 システム作りは業務フロー図から 「本当に役に立つシステム」を作るために、まずやるべきこと
第１章で学べること
・システム担当者が最初にやるべきこと
・要件定義の出発点「業務フロー図」に書くべきこと
・システム化する範囲の定め方
・発注者側のシステム担当者が持つべき「心構え」第１章の読み方
「どんなシステムを作るか」を決めるのは誰か？
要件定義は２つの「業務フロー図」を作るところから
業務フロー図を書く人がつい、やってしまいがちな「ワナ」
システム化する範囲を間違えないたった１つの「判断基準」
そのシステムで本当に会社が幸せになりますか？
新システムを使う人と企業の「喜び」を表現する
業務フロー図を書く人に必要な「メンタリティ」がある
新しい技術に振り回されて「本当の強み」を軽視していないか？ＡＰＰＥＮＤＩＸ
・業務フロー図には「目的」を書き込んでおくと良い
・「懸念と理想」もできる限り書いておく
・システム開発プロジェクトにおける発注者の役割
・プロセス別：発注者のおもな作業第１章まとめ
PART２
第２章 発注者がこれだけは知っておくべき最低限のこと 自社の業務を「正確に」知っているか？
第２章で学べること
・システム担当者が最低限持っておくべき知識
・要件定義工程でシステム担当者が行なうべきこと
・システム作りに興味のない担当者に意欲を持たせる方法第２章の読み方
「本当の責任者」をハッキリさせないとベンダは「やる気」をなくす
一緒に仕事したくなる発注者見捨てたくなる発注者
不自然な出来事の裏にはヘタな「シナリオライター」がいる？
ベンダに協力せずに失敗したときの損害は発注者が保障する
要件定義に必要な発注者とベンダの「協力関係」とは？
システム担当者の「知識不足」が会社に大打撃を与える
メンバーのモチベーションを上げる「フィーリングマップ」ＡＰＰＥＮＤＩＸ
・要件定義で最低限確認しておくべきチェックリスト
・要件の必要性・十分性をチェックするための３ステップ
・フィーリングマップの使い方
・同心円状のフィーリングマップ活用法
・要件の必要性・十分性をチェックする方法
・「Goサイン」を出す社長の思考を予測する第２章まとめ
PART３
第３章 失敗しないベンダの選び方 プロジェクト管理能力の見極め方
第３章で学べること
・本当にプロジェクト管理ができるベンダを見極めるポイント
・発注者が知っておくべきIT導入プロジェクト管理項目
・ベンダの管理能力を知るうえで知っておきたいポイント
・追加費用や納期延長の依頼があったとき、発注者がとるべき態度第３章の読み方
システム開発には「不測の事態」と「リスケジュール」がつきもの
プロジェクトを適切に「管理」するために絶対に外せないポイント
要件の変更に追加費用や納期延長を求めてくるベンダは○か×か？
そのベンダは「言いにくいこと」を伝えてくれますか？
トラブルを乗り越えるための発注者の「聞く力」ＡＰＰＥＮＤＩＸ
ベンダが作るプロジェクト計画書とプロジェクト管理計画書の記載項目例第３章まとめ
PART４
第４章 社内の協力を得るために みんながシステム担当者に協力するしくみ作り
第４章で学べること
・システム担当者とは、社内でどんな存在なのか
・エンドユーザーにヒアリングするときに気をつけるべきこと
・社内一丸となってシステム作りに取り組むために必要なこと第４章の読み方
「社員が協力してくれない」はシステム開発最大の危機
システム担当者が「孤立」する理由
壊れかけたプロジェクトはどう立て直せばいいのか？
エンドユーザー社員がシステム開発に協力する風土としくみ
社員の意識を変えるために「経営トップ」がやるべきこと第４章まとめ
PART５
第５章 リスク管理で大切なこと 「ベンダ側のリスク」の引き出し方
第５章で学べること
・ベンダ側が自社のリスクを開示しない理由
・ベンダが抱えているリスクへの対応法
・ベンダ側のリスクを検知する評価軸第５章の読み方
システム開発はアタリ／ハズレで勝負が決まる「バクチ」か？
エンジニアが突然「抜けてしまう」ことがある理由
ベンダはなぜ、自社内のリスクを隠したがるのか？
「そっちが悪い」と言ったところで得られることは何もない
アメリカにあって日本にない一番大切な「考え方」
発注者側からリスクを「引っ張り出す」メリット
ベンダのリスクを検知するための「プロセス」ＡＰＰＥＮＤＩＸ
・プロジェクトのリスクを管理するプロセス
・要件定義に関するリスクチェックポイントの例
・リスク管理表の記載項目例
・プロジェクトのリスクを発見するチェックリスト例第５章まとめ
PART６
第６章 ベンダとの適切な役割分担 発注者はどこまで「ワガママ」でいられるのか？
第６章で学べること
・期限までに要件をまとめきれないときの対処法
・ベンダに対してどこまで質問して良いのか？
・パッケージソフトと自社の長所のバランスの取り方
・ベンダとの役割分担において心がけること第６章の読み方
ベンダが勝手に作業を進めても黙認すると「合意」したとみなされる
要件定義終了時に「宿題」と「方針」を確認する「チェックポイント会議」
「システムの専門家」相手に発注者はどこまで質問するべきか？
発注者の質問がベンダを「育てる」ことになる？
パッケージソフトを自社に適した形で導入するために
「７：３で自分たちが損してる」とお互いが思うくらいがいい第６章まとめ
PART７
第７章 情報漏えいを起こしてしまったら ダメージを最小限に抑える対応法
第７章で学べること
・情報漏えいに備えてやっておくべきこと
・情報漏えい時の賠償額の相場
・情報を扱う運用担当者に必要なケア
・情報漏えいを起こしてしまったときに捨てるべきもの第７章の読み方
漏えいしてからでは何もできない立ち上げ段階の「準備」がカギ
情報漏えいが起きた場合の補償額・見舞金の相場とは？
機密性と漏えい時の影響度を基準にした「情報のトリアージ」
セキュリティ対策の立案時に考慮すべき運用担当者の「気持ち」
被害を最小限にとどめるために行なうべきこと
企業を存続させるために何を捨てて、何を残すか？第７章まとめ
エピローグ
システムを「外注」するときに読む本の著者
本書の著者は、細川義洋氏です。
目次と「はじめに」を読んでみて、たぶんIBM出身だろうなと思ったのですが、やっぱりIBM出身の人でした。
考え方がIBMっぽいです。
経歴は、まぁすばらしいですね。
細川義洋（ほそかわ・よしひろ）
政府CIO補佐官。ITプロセスコンサルタント。
元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。
立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜擢され、政府系機関システムのアドバイザー業務に携わる。
著書に『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』『「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』（ともに日本実業出版社）、『プロジェクトの失敗はだれのせい？』『成功するシステム開発は裁判に学べ！』（ともに技術評論社）などがある。
システムを「外注」するときに読む本のポイント
本書は最初に、とある裁判事例の紹介から始まっています。
システム開発のプロジェクトではよくある、成功裏に稼働しないプロジェクトにおけるシステムの発注側と受注ベンダーとのトラブル。
プロジェクトが納期通り稼働せずにキャンセルになります。
そして、発注側が稼働しないプロジェクトの責任をベンダー側に訴えます。
しかし、訴訟の結論として、受注ベンダー側の勝ちで、プロジェクトが稼働していないにも関わらず、発注側が開発費を払うことになりました。
トラブルの詳細までは明らかではないものの、発注側がベンダ側にシステムを丸投げして、システム開発の「協力義務」を怠った結果ではないでしょうか。
そして、本書では、システム開発の発注者は、プロジェクトメンバーとしてプロジェクトに積極的に関わるべきであると説いています。
本書の各章では、架空のプロジェクト、人物、団体、企業を使って物語風にまとめてあります。
物語風に書くのは一つのやり方ですが、人によってはあまり好きではないかもしれません。
私も会話のやり取りを読んでみて、実際はこうはならないだろうって思ったことありましたからね。
例えば、第6章で、受け入れ側のプロジェクトマネージャーがシステム担当者を責めるっていうシーン。
実際のシーンでは、発注側の相手を責められず、ベンダー側は受け入れざるを得ないでしょうね。
実際、IT業界で有名なIBMとスルガ銀行の訴訟では、IBM側が議事録を書き換えるように要求されたと言っています。
「議事録や提出資料の内容を、スルガ銀行にとって都合がいいように変更するよう求められた。『日本IBMが悪かった』という表現を議事録などに織り込むようにも迫られた」。日本IBMの金田治副会長は3月4日午後2時40分、東京地裁の411号法廷で証人尋問に臨み、こう主張した。
閑話休題。
第1章、第2章は、発注者側が自社の業務をよく理解し、業務フローを図としてまとめて理解すべきであることを説いています。
発注側の担当者には、これを理解していない人が実は多い。
担当者が、自社の業務を理解していないのに、エンドユーザーとベンダで要件をまとめさせようとする人がいたりします。
第3章は、失敗しないベンダの選定方法について書かれています。
本書では一般的な、ベンダの選び方のみにしか書かれていない模様。
ただ、実務においてはベンダ選びは非常には難しい。
私が考える最大のポイントして、ベンダと同様にベンダの担当者も重要。
発注側の担当者と受注ベンダの担当者がどれだけ理解しあえるかがプロジェクト推進のポイントになると考えます。
第4章は、社内協力を得るために必要なことが書かれています。
第5章は、リスク管理で大切なことが書かれています。
第7章は、情報漏えいを起こしたときの対応について書かれています。
あっ、第6章を飛ばしたのはワザとで、「第6章 ベンダとの適切な役割分担 発注者はどこまでワガママでいられるのか？」については、次に私の見解をまとめます。
発注者はワガママでもいいが、傲慢になってはいけない
本書の著者の意図とは異なるかもしれませんが、私が本書で最も注目したのは第6章です。
「ベンダとの適切な役割分担 発注者はどこまでワガママでいられるのか？」
です。
本書の中身には触れずに、私が過去携わった某巨大案件のプロジェクトの経験を説明します。
私は、数年前、ベンダー側のプロジェクトマネージャーとして、某巨大案件を担当しておりました。
このプロジェクトは、ベンダー側開発の既成のWEBシステムのパッケージをカスタマイズして、お客様に納品するというもの。
実は前任のプロジェクトマネージャがいたのですが、このプロジェクトで相当疲弊したようで、退職したために、途中交代で私が担当することになりました。
このプロジェクトは既に何度も遅れたり、さまざまな困難があったものの、私は第一段階をカットオーバーする直前ぐらいに引き継いで参加しました。
さて、私がプロジェクトを担当してみて最初に驚いたのが、オリジナルパッケージからの乖離の多さ。
おそらく、顧客からの一方的な要求で、特に議論せずに変更されたのでしょうが、不思議なことに要件定義書もなければ、詳細設計書もなかったです。
あるのは、ソースコードと基本設計と自社のテスト結果のみ (UAT、ユーザー受け入れテストなし) で、第一段階を運用しようとしている段階でした。
おいおい。
私の最初の疑問は、
「これ、ちゃんとユーザー環境でテストされているんだろうか？運用できるんだろうか？」
でした。
とはいえ、ちゃんとお客さんからの検収が済んでいるらしいので、まっいいっかって感じで本番を迎えます。
プロジェクトの最後の方からPMをやると、なかなかストップはかけられないものです。
ところが、いざ、運用を始めると私の予感は的中します。
このパッケージソフト、WEBブラウザで動くものなのですが、多人数で運用を始めると、すぐに固まって動かなくなる人が続出しました。
で、全く運用出来なくなって、私は土曜日にユーザーの現場に呼び出されました。
現場で中身を調べてみると、データベースは正常で問題ないようでした。
問題は、どうやら、JavaScriptのロジックの問題でロックしているか、プログラムがネットワークから値を取り出せていないらしいことは分かりました。
このロジックの部分は、パッケージソフトをそのまま使わずに、新規にカスタマイズして作ったものなので、多人数での受け入れテスト(UAT) を行わずに納品されていました。
単純には発生しないけれど、多人数だったり、ネットワーク負荷が多いと発生する、複雑系な不具合。
すでに導入実績のあるパッケージをそのまま使うならまだしも、新規でカスタマイズして作ったものを、UAT (ユーザー受け入れテスト) もせずに使えば、そりゃ、トラブるわな。。
そこで、私は、ユーザーの担当者に、
- 今回の不具合の調査には、かなり時間がかかること。
- パッケージのカスタマイズの受け入れテストは、ユーザー環境、ユーザーの協力が必要で保守契約対象外で別費用がかかること。
を説明しました。
ところが、最初の運用がうまくいかなかったことで、発注側の担当者はすでに逆上状態。
何を言っても、反発してきます。
そして、だんだんと、この担当者はベンダー側である我々に横柄な態度を取り始めました。
UATはユーザー側の作業で、ベンダー側の瑕疵とは言えない部分であるにも関わらず、
- 不具合の調査結果を週次で報告しろ ⇒ おいおい、保守契約対象外なんだけど。。
- ソースの修正は事前に許可を取ってから行え ⇒ プログラムを解らないやつにどうやって説明するの？
- 修正できなかったらどうするのか？(どう責任をとるかってことか？) ⇒ 逆にどうして欲しいの？
とか、なかなか横柄な態度で無茶な要求をしてきます。
言葉の表現や態度もなかなかダダっ子の子供っぽくなってきました。
ここまでくるとシステム運用とか本筋の議論ではなくて、単なる発注担当者が相手を蔑ませる心の満足のためだけのプロジェクトになってきました。
その後、我々開発者側の努力で、半年ほどで不具合を修正したにも関わらず、逆上したユーザー側から再稼働は見送られました。
ただ、契約上の判断 (契約上、我々に瑕疵がない) からか、訴訟等には発展しませんでした。
かくして、このプロジェクトは、2年ぐらいの開発費をかけたにも関わらず、失敗する運命のまま失敗します。
(私は当初から失敗すると思っていました)
このプロジェクトを経て、私の教訓は、発注者ユーザーとベンダーは、プロジェクトにおいては互いに協力する必要があり、一方が他方の家来ではないということです。
当然ですが、互いに相手を批判したり、横柄な態度を取ってはいけません。
お互い「人」であるということですね。
ベンダーにシステムの不具合を修正する義務はありますが、内容、契約により、有償のものと無償のものがあります。
例え、お金を払っていても、発注者は「お客様」「神様」ではなくて、対等なプロジェクトメンバーなんです。
プロジェクトのどのメンバーであっても、傲慢な態度、横柄な行動を取ればプロジェクの成功は難しいでしょう。
また、別のプロジェクトの例を紹介しましょう。
ある時、私が担当した別のプロジェクトでは、朝と昼と夕方に報告の打ち合わを行うように指示されたプロジェクトがありました。
朝と夕方ならともかく、昼は不要じゃねぇ？っと思ってその旨を説明するのですが、このお客様は頑として引きません。
結果として、毎日、報告書を作ることと、打ち合わせだけのために時間を使うプロジェクトになりました。
打ち合わせは必要に応じて行えばよいのですが、問題の本質を見間違えると、打ち合わせだけの打ち合わせになって、結果として何の意味もない会合になってしまいます。
また、このプロジェクト、請負契約ではなく、工数提供型の契約にも関わらず、発注側は仕事を定義せずに、今日何をするのか？を聞いてくるようになりました。(⇒ おいおい、工数提供の場合、仕事内容を決めるのはお前なんだけど。)
請負契約と請負 (SES) 契約については、以下をご覧ください。
発注者は、ワガママであっていいんです。
ただし、傲慢になってはいけません。
私自身はこのような傲慢な態度を取るお客様とはつき合わないように、プロジェクトを選ぶようになりました。
まとめ
改めて「システムを外注するときに読む本」の表紙カバーを読んでみると、書いてありますね。
発注者が「お客様」から「プロジェクトメンバー」になったとき、
システム開発はグッと成功に近づきます。
この本当の意味が分かっている発注者少ないだろうな。。
↓システムを「外注」するときに読む本
コメント
[…] 「システムを「外注」するときに読む本」 書評、感想、ネタバレ、目次、… […]