SIにおける異文化入門（越境するために知っておきたい基礎知識）

システム開発PJは多くの人が関わる仕事です。PJを成功させるには、技術は勿論重要だけど、技術以外にも色々な価値観や知識を得ておくことも大切です。それはプロマネや営業だけが知っておけば良いことではありません。不確実性が求められる時代において、各自が所与の役割を「越境」できる価値は、今後より大切になるでしょう。そのためにもより広くシステム開発を捉えられるようになってもらいたくて、この勉強会を企画しました。

Transcript

1. SIにおける異文化入門 ～越境するために知っておきたい基礎知識～ 2020年7月 ver1.0 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）
2. 自己紹介 twitter/note/Qiita で情報発信中。 良かったら覗いてみてください♥ 中野 康雄（なかのやすお） 兵庫県宝塚市出身 S49年生 ARアドバンストテクノロジ株式会社 取締役執行役員（事業担当） 兼TechCoE事業室長  全社戦略、事業管理、PJ品質管理 人材育成、中途採用、一部PJ業務 などを担当  元流通経済大学 非常勤講師 （Eビジネス論）  PMP/情報処理安全確保支援士 AWS認定ソリューションアーキテクトアソシエイト JDLA G検定 2
3. ARIってどんな会社？ 創業11年目のSI＆サービス提供 社員数390名、国内3拠点 （渋谷、大阪、名古屋） 仮想化、音声、クラウド基盤、 アプリケーション、AIへと領域拡大 近年はデザインやITコンサル体制拡充 パッケージ製品や自社SaaS提供も Biz Tech Creative 三位一体提供型の 次世代DXファームを目指し奮闘中 ARI で検索！ 3
4. はじめに 4
5. システム開発PJは多くの人が関わる仕事です。 PJを成功させるには、技術は勿論重要だけど、 技術以外にも色々な価値観や知識を得ておくことも大切です。 それはプロマネや営業だけが知っておけば良いことではありません。 不確実性が求められる時代において、 各自が所与の役割を「越境」できる価値は、今後より大切になるでしょう。 そのためにもより広くシステム開発を捉えられるようになってもらいたくて、 この勉強会を企画しました。 今日のテーマ 5
6. 相手の立場にたってみる 別の言い方で言うと 6 お客様 PM 営業 管理部門 エンジニアの立場 の立場
7. １．企業のシステム開発に関わる人達を知ろう ２．情シスの仕事を知ろう ３．システムに関する契約や法務を知ろう 今日のAgenda 7
8. 企業のシステム開発に関わる人達を知ろう 8
9. 企業システムに関わる取引構造 9 • 関係者（ステークホルダ）の 構造は顧客企業や案件ごと に全然違う • 我々と最終的なユーザー部 門との間にどういう登場人 物がいるのか？ 「情シス」 「現場・ユーザー部門」 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 ステークホルダ構造を知ることが プロジェクト戦略立案の第一歩
10. 関係者が多い分、コミュニケーションも複雑に 10 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 • 関係者が多い ＝コミュニケーションも複雑 • 最近は各種クラウド業者も • コミュニケーションの第一歩は 関係部署や人物の全体感を 把握すること コミュニケーションを制するものは プロジェクトを制する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者
11. なぜ「提案書」「議事録」が重要なのか？ 11 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 • 顧客担当者に出した資料は、 社内で稟議・決裁に利用され ることが多い • 重要事項は第三者にも誤解 なく伝わるよう資料化する （担当者の説明力に期待しない） 一人歩きしても誤解がないように 丁寧に資料化する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者
12. 成果物を元に承認・合意・指示がPJの基本 12 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス
13. なぜ「ステコミ」が重要なのか？ 13 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 • ベンダーと顧客担当者との間 以上に、顧客社内で情報が 共有されていないことが多い （会社とはそういうもの・・・） • 主要関係者を招いて定期的 に認識を整えPJ重要方針の 意思決定する会議体が必要 顧客の自発的情報共有に期待せず プロジェクトとして能動的に計画する クラウド ベンダ テスト ベンダ 脆弱性 診断 業者 主要キーメンバの集まる会議体＝ステアリングコミッティ（通称ステコミ）
14. 関係者はみんな役割が違う 14 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス • 最終的に目指しているもの は同じだが、皆役割が違う • 役割が違うから優先順位も 違って当たり前（ただこの違 いがトラブルを生む種に） • 違いに嘆くのではなく 違いを前提に物事を考える
15. 情シスの仕事を知ろう 15
16. 情シスのお仕事 16 引用： 情シスのキャリアについて考える｜吉田航｜note https://note.com/w_yoshida/n/nfe35807364e8
17. 企業におけるシステム開発業務分担（従来） 17 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 情シス＋ベンダーの 守備範囲
18. 企業におけるシステム開発業務分担（最近） 18 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） に加筆 業務部門が IT化を直接牽引する ケースも出てきた （DXの流れ後押し）
19. 情シス組織の形態 19 https://www.ipsj.or.jp/10jigyo/seminar/2006/2006-1-5-hosokawa.pdf 企業によって 情シスの在り方も いろいろ
20. RFP（提案依頼書）とは何か？ 20 RFPとは「発注元が提案してもらいたい内容をまとめた資料」のこと （Request For Proposal） 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス
21. RFI（情報提供依頼書）とは何か？ 21 RFI （Request For Information）とは「提案の前段階として情報提供を依頼する資料」のこと 正式なRFP提示する先を絞る予選的位置づけが高い 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス RFI RFI提示 RFPよりもラフな依頼内容 提案の方向性 各社の保有技術や実績などを 聞くことが多い
22. 情シスが好むベンダー、好まないベンダー 22 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス 彼らはITがわからない人に説明する必要がある。こちらが説明資料を用意する場 合は、専門用語を減らし、翻訳の手間をかけさせないようにすると効果的。
23. 顧客が求めているものは何か？ 23 システムをつくりあげることは顧客にとっては最終ゴールではない。自分たちの納 期とシステム品質だけを目的とするベンダーは、長くは選ばれない。 引用：Webディレクションの新・標準ルール システム開発編ノンエンジニアでも失敗しないワークフローと開発プロセス
24. IT予算の年間計画 24 https://www.kobelcosys.co.jp/column/monozukuri/108/ 3月が年度末となる企業の予算編成スケジュールの例 • 一般的に企業であれば、 IT投資は年間予算で縛 られることが多い 予算化されていることが 非常に重要 • 3月末決算企業の場合 １～3月が予算編成時期 それを踏まえベンダーへ 見積依頼が活性化 秋から年末年始は積極 的に接点増やすべし （思い出してもらうため）
25. 決裁稟議 25 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の場合、その種類と金 額によって決裁者が違う ことが多い • その提案は誰の決裁権 限範囲かは営業上確認 するのが望ましい（但し担当 者の面子を潰さないように注意）
26. システムに関する契約や法務を知ろう 26
27. システム開発業界の実態 27 https://www.atmarkit.co.jp/ait/articles/1908/14/news006.html システム開発においては複数種類の契約が存在する サンプル事例
28. 契約形態の違い 28 各契約形態の違いを理解しておく必要がある 【標準的な契約形態とその内容】 派遣 準委任 請負 報酬を支払う対象 労働 労働 成果物 成果物完成責任 なし なし あり 売主が負う責任 善管注意義務 善管注意義務 債務不履行責任 （期日までに成果物を提出する） 契約不適合責任 （旧瑕疵担保責任） （完成した成果物の不具合改修） 指示命令 委託者 受託者（業務責任者） （受託企業要員への直接指示は不 可、契約上の業務責任者に対して 指示を行う） 同左 報告義務 なし あり なし
29. 善管注意義務とは？ 29 参考：JISA 法務・契約ハンドブック 準委任契約では、顧客に対して、その過程で軽率な判断をしたり、重大な判断ミ スやチェックの漏れがないように“注意深く“専門家として質の高いサービス（役 務）を提供することが求められる。 この注意義務を、善管注意義務（善良な管理者としての注意義務）という。 • 準委任契約だから、予定した納期が遅れても責任はなく、 無条件に追加費用はもらえると考えるのは大きな間違い • 事前のリスクアラートや対策を主体的に打つことが求められる • 「準委任なのでリスクはありません」という考え方は誤り
30. 契約不適合責任（旧 瑕疵担保責任）とは？ 30 納品した成果物に、後日、瑕疵（欠陥）が発見された場合、一定の期間、受託者 が負う瑕疵の修補、損害賠償や契約解除等の責任を契約不適合責任という 2020年4月の民法改正前の瑕疵担保責任の存続期間は、目的物の引渡時／ 仕事の終了時から1年以内に権利を行使する必要があったが、改正後の契約不 適合責任では契約不適合を知った時から1年以内にその旨の通知をすればよい ことになり、注文者（ユーザ企業）が契約不適合を「知る」までの間は消滅時効一 般の規定に基づき、10年間権利の行使がされ得ることとなった 従来通り「責任制限規定」を必ず設定する ※ARI標準テンプレートには設定されている 参考：» 改正民法に対応した「情報システム・モデル取引・契約書」を公開<br />～ユーザ企業・ITベンダ間の共通理解と対話を促す～：IPA 独立行政法人 情 報処理推進機構 https://www.ipa.go.jp/ikc/reports/20191224.html
31. 基本契約と個別契約 31 https://web-kanji.com/posts/checking-contract ARIはこちら （但し個別契約を注文書/注文請書の形で代替）
32. 契約書の重要チェックポイント 32 参考：JISA 法務・契約ハンドブック • 資料と情報の扱い • 知的財産の権利帰属 • 権利譲渡禁止 • 成果物受領の権利 債権の第三者譲渡禁止 • 損害賠償 • 条件や金額上限を設定 • 契約解除 • 紛争解決と裁判管轄 PMと営業は自分でも確認すること （法務に丸投げしない）
33. 相手の立場に立って見る 最後に 33 お客様 PM 営業 管理部門 エンジニアの立場 の立場
34. SIにおける異文化入門 ～越境するために知っておきたい基礎知識～ ＜完＞ 2020年7月 ver1.0 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）