クライアントワークのお作法 クライアントワークを行う上で エンジニア・デザイナーが知っておきたいこと 2021年1月 ver1.2 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）

はじめに 2

クライアントワーク（SI/制作案件）の難しさ 3 多様な登場人物間での期待値調整コストの高さ 受注者と発注者の相互理解不足 契約や法務関連で認識・調整すべき事項の多さ 本質にたどりつく前にクリアすべきことが結構ある

多様なステークホルダーの存在 4 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊） • 最終的に目指しているもの は同じだが、皆役割が違う • 役割が違うから優先順位も 違って当たり前（ただこの違 いがトラブルを生む種に） • 違いに嘆くのではなく違い を前提に物事を考えたい インフラ エンジニア アプリ エンジニア デザイナー システム 担当者 業務部門 担当者 コンテンツ 運用者 情シス部門 担当者 システムの ゴール 業務の 目標・成果 機能・要件 UIデザイン プログラム サーバーや ネットワーク システム 利便性 社内ITの 最適化

相手の関心にも関心を払うと話が通じやすい 5 お客様 自分や近くのメンバー PM・営業・管理部門 他社パートナーさんなど 関心の輪 (ほぼ自分しか見えていない状態） 関心の輪 （周りと自分が見えている状態）

なぜプロジェクトマネジメントをメンバー全員が学ぶべきなのか？ 6 https://note.com/yasuoyasuo/n/n7e8907e24366 “普段あまり幹事をやらない人たちが多い飲み 会の幹事役は本当に大変です。 ドタキャンは平気でする、遅刻は当たり前、前で 誰かが挨拶中も勝手に大声でしゃべる、お金 払わずに先に帰るなどなど幹事の苦労をわかっ てないからできる振る舞いです。 一方普段から幹事をやる人たちが参加者の飲 み会は、そうした苦労が少なそうことは想像で きますよね。“

システム開発PJを成功させるには、 異文化交流を避けて通れません それを円滑に行うには、様々な価値観の理解や知識が必要です。 それはプロマネや営業だけが知っておけば良いことではありません。 不確実性が求められる時代において、 各自が所与の役割を「越境」できる価値は、今後より大切になるでしょう。 エンジニアやデザイナーの皆さんにも より広い視点でPJに貢献できるようになってもらいたくて この資料を用意しました。 本資料の背景 7

お客様や自分以外の関係者の 関心事にも関心を持つ きっかけ作り この資料の期待 8

１．企業のシステム開発に関わる人達を知ろう ２．情シスの仕事を知ろう ３．システムに関する契約や法務を知ろう Agenda 9

企業のシステム開発に関わる人達を知ろう 10

企業システムに関わる取引構造 11 • 関係者（ステークホルダ）の 構造は顧客企業や案件ごと に全然違う • 我々と最終的なユーザー部 門との間にどういう登場人 物がいるのか？ 「情シス」 「現場・ユーザー部門」 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に一部加筆 ステークホルダ構造を知ることが プロジェクト戦略立案の第一歩

参考：「共通フレーム」ってご存知ですか？ 12 受注者と発注者の 共通の物差しを目指して 国（IPA）が作成 （2013が最新版） システムの企画，要件定義， 開発，運用，保守及びそれ らに係る諸活動を対象に それらの標準を定義 Amazonでも販売中 https://amzn.to/3gANIKf 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版）

関係者が多い分、コミュニケーションも複雑に 13 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） • 関係者が多い ＝コミュニケーションも複雑 • 最近は各種クラウド業者も • コミュニケーションの第一歩は 関係部署や人物の全体感を 把握すること コミュニケーションを制するものは プロジェクトを制する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者

なぜ「提案書」「議事録」が重要なのか？ 14 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 • 顧客担当者に出した資料は、 社内で稟議・決裁に利用され ることが多い • 重要事項は第三者にも誤解 なく伝わるよう資料化する （担当者の説明力に期待しない） 一人歩きしても誤解がないように 丁寧に資料化する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者

成果物を元に合意・承認・指示がPJの基本 15 言った言わない、理解の齟齬は手戻りの元。 とりわけ仕様に関するコミュニケーションは必ずドキュメントを元に行うこと 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊）

なぜ「ステコミ」が重要なのか？ 16 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に一部加筆 • ベンダーと顧客担当者との間 以上に、顧客社内で情報が 共有されていないことが多い （会社とはそういうもの・・・） • 主要関係者を招いて定期的 に認識を整えPJ重要方針の 意思決定する会議体が必要 顧客の自発的情報共有に期待せず プロジェクトとして能動的に計画する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者 主要キーメンバの集まる会議体＝ステアリングコミッティ（通称ステコミ）

情シスの仕事を知ろう 17

情シスのお仕事 18 引用： 情シスのキャリアについて考える｜吉田航｜note https://note.com/w_yoshida/n/nfe35807364e8 社内のIT全般の 企画から入手、 その運用までを 幅広く担当 セキュリティ対策や 統制などの役割も

企業におけるシステム開発業務分担（従来） 19 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に一部加筆 情シス＋ベンダーの 守備範囲

企業におけるシステム開発業務分担（最近） 20 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に一部加筆 業務部門が IT化を直接牽引する ケースも出てきた （DXの流れ後押し）

情シス組織の形態 21 https://www.ipsj.or.jp/10jigyo/seminar/2006/2006-1-5-hosokawa.pdf 企業によって 情シスの在り方も いろいろ そのクライアントは どういう形態か 確認する習慣を （先入観は危険）

RFP（提案依頼書）とは何か？ 22 RFPとは「発注元が提案してもらいたい内容をまとめた資料」のこと （Request For Proposal） 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊）

RFI（情報提供依頼書）とは何か？ 23 RFI （Request For Information）とは「提案の前段階として情報提供を依頼する資料」のこと 正式なRFP提示する先を絞る予選的位置づけが高い RFI RFI提示 RFPよりもラフな依頼内容 提案の方向性 各社の保有技術や実績などを 聞くことが多い 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊）

情シスが好むベンダー、好まないベンダー 24 彼らはITがわからない人に説明する必要がある。こちらが説明資料を用意する場 合は、専門用語を減らし、翻訳の手間をかけさせないようにすると効果的。 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊）

顧客が求めているものは何か？ 25 システムをつくりあげることは顧客にとっては最終ゴールではない。自分たちの 納期とシステム品質だけを目的とするベンダーは、長期的な信頼は得られない。 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス（エムディエヌコーポレーション社刊）

IT予算の年間計画 26 https://www.kobelcosys.co.jp/column/monozukuri/108/ 3月が年度末となる企業の予算編成スケジュールの例 • 一般的に企業であれば、 IT投資は年間予算で縛 られることが多い 予算化されていることが 非常に重要 • 3月末決算企業の場合 １～3月が予算編成時期 それを踏まえベンダーへ 見積依頼が活性化 秋から年末年始は積極 的に接点増やすべし （思い出してもらうため）

決裁稟議 27 https://doc.support- dreamarts.com/%E3%81%B2%E3%81%B3%E3%81%8DSm@rtDB/V45/%E3%81%B2%E3%81%B3%E3%81%8DSm@rtDB_Ver.4.5_%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9%E3%82%AC%E3%82%A4%E3%83%89%EF%BD%9E%E6%B1%BA %E8%A3%81%E3%83%AB%E3%83%BC%E3%83%88%E7%B7%A8%EF%BD%9E/overview/11000/index.html 決裁権限規定のサンプル • 一般的な企業には大抵 決裁権限に関する規定 がある • ITの場合、その種類と金 額によって決裁者が違う ことが多い • その提案は誰の決裁権 限範囲かは営業上確認 するのが望ましい（但し担当 者の面子を潰さないように注意）

その他 28 • 「情シス」の立ち位置や立場の強さは会社それぞれ • 「情シス」は自社の業務とシステムのことを何でも知っているわけではない • 「情シス」のメンバーはみんなエンジニアになりたかったわけではない • 「情シス」のメンバーはみんなITの専門家というわけではない • 顧客担当者はシステム化の目的を１００％理解しているわけではない • PJにアサインされている担当者の時間はいつでも抑えられるわけではない • J-SOXやISO、各種ポリシーなど無条件に守るべき制約が結構ある • お客様も当然組織の一員。保身もするし評価も気にするのは当たり前

システムに関する契約や法務を知ろう 29 • 契約形態の違い • 善管注意義務とは？ • 契約不適合とは？ • 基本契約と個別契約 • 契約書の重要チェックポイント • システム開発で注意したい知的財産 • 下請法（下請代金支払遅延等防止法）とは？

システム開発業界の実態 30 https://www.atmarkit.co.jp/ait/articles/1908/14/news006.html システム開発においては複数種類の契約が存在する サンプル事例

契約形態の違い 31 各契約形態の違いを理解しておく必要がある 【標準的な契約形態とその内容】 派遣 準委任 請負 報酬を支払う対象 労働 労働 成果物 成果物完成責任 なし なし あり 売主が負う責任 善管注意義務 善管注意義務 債務不履行責任 （期日までに成果物を提出する） 契約不適合責任 （旧瑕疵担保責任） （完成した成果物の不具合改修） 指示命令 委託者 受託者（業務責任者） （受託企業要員への直接指示は不 可、契約上の業務責任者に対して 指示を行う） 同左 報告義務 なし あり なし

善管注意義務とは？ 32 参考：JISA 法務・契約ハンドブック 準委任契約では、顧客に対して、その過程で軽率な判断をしたり、重大な判断ミ スやチェックの漏れがないように“注意深く“専門家として質の高いサービス（役 務）を提供することが求められる。 この注意義務を、善管注意義務（善良な管理者としての注意義務）という。 • 「準委任契約だから納期が遅れても責任はなく、無条件に追加費用はもら える」と考えるのは大きな間違い • 仮にお客様の責任であったとしても、事前のリスクアラートや対策を主体的 に打ち、それを議事録などのエビデンスに残すことが大切 • 「準委任なのでリスクはない」という考え方は大いなる誤り

契約不適合責任（旧 瑕疵担保責任）とは？ 33 納品した成果物に、後日、瑕疵（欠陥）が発見された場合、一定の期間、受託者 が負う瑕疵の修補、損害賠償や契約解除等の責任を契約不適合責任という。 2020年4月の民法改正前の瑕疵担保責任の存続期間は、目的物の引渡時／ 仕事の終了時から1年以内に権利を行使する必要があったが、改正後の契約不 適合責任では契約不適合を知った時から1年以内にその旨の通知をすればよい ことになり、注文者（ユーザ企業）が契約不適合を「知る」までの間は消滅時効一 般の規定に基づき、10年間権利の行使がされ得ることとなった。 従来通り「責任制限規定」を必ず設定すること ※ARI社内標準テンプレートには設定されている 参考：» 改正民法に対応した「情報システム・モデル取引・契約書」を公開
～ユーザ企業・ITベンダ間の共通理解と対話を促す～：IPA 独立行政法人 情 報処理推進機構 https://www.ipa.go.jp/ikc/reports/20191224.html

基本契約と個別契約 34 引用：ホームページ制作の業務委託契約書チェックの６つのポイント | Web幹事(https://web-kanji.com/posts/checking-contract) 個別契約を注文書/注文請書の形で代替し ても法的には同じ効力をもつ

契約書の重要チェックポイント 35 参考：JISA 法務・契約ハンドブック  資料と情報の扱い  知的財産の権利帰属  権利譲渡禁止  成果物受領の権利  債権の第三者譲渡  損害賠償  条件や金額上限を設定  契約解除  紛争解決と裁判管轄 PMと営業は自分でも確認すること （法務に丸投げしない）

システム開発で注意したい知的財産 36 参考：JISA 法務・契約ハンドブック • 特許権と商標権は出願が 必要 • 著作権の帰属については 契約書で明確にする • プロジェクトで知り得た顧 客の情報は不正競争防止 法における営業秘密となり うるので、取扱は十分に注 意する 参考：知的財産権について | 経済産業省 特許庁(https://www.jpo.go.jp/system/patent/gaiyo/seidogaiyo/chizai02.html)

下請法（下請代金支払遅延等防止法）とは？ 37 参考：厚生労働省・中小企業庁・公正取引委員会「働き方改革に伴う『しわ寄せ』への対策について」（https://www.chusho.meti.go.jp/keiei/koyou/2019/190612jinzai01.pdf） 下請け企業が親事業者に比べ、不利な立場になりがちになるため、その力関係を 是正するために設けられた法律。プログラム作成業務の場合は以下が該当する。  親事業者の資本金が3億円を超えていて、下請事業者の資本金が3億円以下  親事業者の資本金が1千万円を超えて3億円以下、下請事業者の資本金が1千万円以下 • 書面交付義務  契約時、親事業者は下請け事業者に対し、契約 に関する重要事項を記載した書面を交付する必 要があります。 • 書類の作成・保存義務  親事業者は、取引に関する重要な事項を記載し た書面を作成し、保存する義務があります。 • 代金支払期日を定めるべき義務 • 遅延利息の支払い義務 • 完成物の受領拒否の禁止 • 代金支払い拒絶の禁止 • 代金減額の禁止 • 返品の禁止 • 買いたたきの禁止 • 購入や利用強制の禁止 • 報復措置の禁止 • 割引が難しい手形を交付することの禁止 • 不当な経済的利益の提供を要求することの禁止 • 不当な給付内容の変更ややり直しを求めることの禁止 義務 禁止行為 参考：システム開発における下請法の重要ポイント | アサインナビ マガジン https://assign-navi.jp/magazine/engineer/e063.html

最後に 38

自分のことだけ考えて仕事をしているうちはまだまだ。 お客様や関わる人達の都合も考慮した上で（≠安易な迎合） 全体最適を提案できるようでありたい。 最後に 39 お客様 自分や近くのメンバー 関心の範囲（若手の頃） ←経験を積み余裕ができると関心の範囲が広げられるようになる→ PM・営業・管理部門 他社パートナーさんなど

早く行きたいなら、一人で行け 遠くまでいきたいなら、みんなで行け by アフリカのことわざ 大事にしたい

クライアントワークのお作法 クライアントワークを行う上で エンジニア・デザイナーが知っておきたいこと ＜完＞ 2021年1月 ver1.2 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）