2017年12月03日 12:49

拾い読み Business Law Journal 2018年1月号


 BLJ2018年1月号から。
 独禁法の道標3「事業者団体の参加者におけるコンプライアンス」
 個人的に非常に思うことある記事で、というのはよろず諸々の業務についている中で事業者団体の消費者関連の分科会のメンバーというのがあるからです。共同リコールの経験を通じて、消費者関連の問題について業界中位からちょっと下あたりをうろうろしている企業が単独でなんとかできるものではないというのが実感としてあります。時の上司には承諾を得て「渉外の顔」で参加しているのですが、常に「自戒」の意識を抱えていることはいうまでもありません。(いくらその意識を抱えたところで自己矛盾の文字はつきまとうかもしれませんが)まあ、担当を変わればよいことではあるのですがね。


 実務解説「NTT東日本対旭川医大事件」
 自社はユーザーの立場です。とある事情からこの判決は非常に重い気分で受け止めました。早速この記事は早速直接ベンダーの窓口となるIT部門に読んでもらうことにしました。そして、さらにはシステムやら何やら需要家である社内の事業部門、管理部門にも展開するのがモアベターというか、しておくべきだと考えています。

 業務システム等を外部ベンダーに委託する企業がほとんどと思いますが、ベンダーの窓口になるのは社内のIT部門といったところでしょうか。社内すべての人間がシステム開発というものに通じているわけではありませんし、特に中高年以上の幹部社員にITリテラシーを期待しても限界があります。自部門の業務状況も把握できないまま、システム化さえすれば万事OKと思っているレベルの人間もいるでしょう。これはシステム開発の決裁が下りた後には「あとは頼む」とIT部門に「丸投げ」というケースですね。
 一方、社内IT部門が会社のビジネス(製品、役務にとどまらず、商習慣、社内業務のウラオモテ、自社の担当者の業務スキルなど)に通じているとは限りません。「あとは頼む」といわれても本来の「需要家」である事業部門や管理部門から具体的なオーダーが示されなけば「要件」すらまとまりません。
同じ請負形態である建築の世界だと「基本設計」「仕様書」「特記仕様書」などは(設計者に委託するとはいえ)発注主から提示するものですが、要件定義作成も請負業務に含まれるITシステムの世界ではどうなのだろうと思ってはいたのですが、今般の「ユーザーの協力義務違反」の判例で今後風向きが変わるかもしれません。

 システムの業務発注契約にどこまで法務が関与できるかというところですが、業務委託契約書の作成なりレビューまででよしとするのか、その後のプロジェクトまで関与し少なくとも要件定義書まで関与すべきなのか、というところ。
 民法改正を真面目にフォローしていない身でいうのもなんですが、システム開発委託において「契約の内容」とは「要件定義書」が「本丸」ではないかと。そうであれば、IT企業ではない企業の法務担当者もある水準まではシステム系のことも理解しておく必要があると思ったのでした。
 





 


 
 



    このエントリーをはてなブックマークに追加

コメントする

名前
 
  絵文字
 
 
プロフィール

msut

QRコード
QRコード
アクセスカウンター

    • ライブドアブログ