企業法務マンサバイバル : 【雑誌】BUSINESS LAW JOURNAL No.26 ５月号 ― 仕様書のチェック、してますか？で、
僕は今まで、システム開発やソフトウェア開発を営んだり発注する会社に法務として3社所属したことがありますが、そのいずれでも、契約締結段階で検査基準や瑕疵の基準として有効に機能しうる程度に仕様がしっかりと定められていることは稀だったと思います。
そしてこれは、発注側の怠慢、つまり、まともな要求仕様やRFPを書かない（というか、書けない）ことに起因していたように感じます。
このような状況下では、契約書に添付されている仕様書という名の「よろしくやっといてよ」をちょっと長くしたような書面を精査できることよりも、どのようにして（本来の意味の）仕様が定まり、変更されるのかを現場に即してしっかり定められることのほうが有意義なんじゃないかと思うのです。
よく「現場を知らなければ良い法務にはなれない」と言われることがありますが、この「現場を知る」というのは、現場の営業や技術者と同じようなスキルを持つという意味ではなく、どのように営業や技術者が動くのかを把握するということのはずです。
その意味では、法務がプログラミングをできるようになっても、直接のメリットはほとんど無いと思うのです。
というわけで、プログラミングに縁遠い法務の皆様、ご安心下さい＆もっと現場の話を聞こう！という趣旨のエントリーでした。
ではでは。
@kataxさんみたいに、自身でプログラムを書けるぐらい技術に通じて仕様書の中身もチェックできる人が、法務パーソンとしては理想的なんでしょうと言及をいただいたので、返信代わりに自分が感じていることをポストします。
僕は今まで、システム開発やソフトウェア開発を営んだり発注する会社に法務として3社所属したことがありますが、そのいずれでも、契約締結段階で検査基準や瑕疵の基準として有効に機能しうる程度に仕様がしっかりと定められていることは稀だったと思います。
そしてこれは、発注側の怠慢、つまり、まともな要求仕様やRFPを書かない（というか、書けない）ことに起因していたように感じます。
このような状況下では、契約書に添付されている仕様書という名の「よろしくやっといてよ」をちょっと長くしたような書面を精査できることよりも、どのようにして（本来の意味の）仕様が定まり、変更されるのかを現場に即してしっかり定められることのほうが有意義なんじゃないかと思うのです。
よく「現場を知らなければ良い法務にはなれない」と言われることがありますが、この「現場を知る」というのは、現場の営業や技術者と同じようなスキルを持つという意味ではなく、どのように営業や技術者が動くのかを把握するということのはずです。
その意味では、法務がプログラミングをできるようになっても、直接のメリットはほとんど無いと思うのです。
というわけで、プログラミングに縁遠い法務の皆様、ご安心下さい＆もっと現場の話を聞こう！という趣旨のエントリーでした。
ではでは。
コメント
コメント一覧 (3)
それと、これは伺いたいのですが、
「まともな要求仕様やRFPを書かない（というか、書けない）」のは、必ずしも「発注者側の怠慢」だけではなく、ヒアリングして仕様書に落とし込む受注者としての能力不足や怠慢もあるのではないでしょうか。
そんなときに法務からも、「こんな曖昧な仕様書でウチ受けられるの？／発注しちゃって大丈夫？」って突っ込むことは普通にあると思いますし、やるべきだと思ってますけど・・・。
的外れという趣旨ではなくて、たとえまるっきりプログラミングに関する知識がなかったとしても（多くの方はそうだと思います）、それが大きなディスアドバンテージになるとはかぎらないですよ、という、プログラミングを趣味とする法務担当者からの回答だったのです。
→例え仕様書が読めなくても、仕様書の成り立ちを知っていれば、キモは押さえることができるのではという意味です。もちろん、読めた方がベターなのは確かだとは思います（笑）
ろくに推敲もせずちゃちゃっと書いてしまったので、改めて読み返してみると誤解を生むトーンになっちゃってたような気もしますが、あしからずご了承ください。
なお、ヒアリング…の点については、発注者側にしっかりとしたシステム部門がある場合はともかく、そうでない場合は、発注者側が早い段階で仕様を固めるのを嫌がる傾向があり、受注者側の努力だけではなかなか難しいということをお伝えしたかったのでした。
ではでは〜