企業法務マンサバイバル : 【雑誌】BUSINESS LAW JOURNAL No.26 5月号 ― 仕様書のチェック、してますか?で、
僕は今まで、システム開発やソフトウェア開発を営んだり発注する会社に法務として3社所属したことがありますが、そのいずれでも、契約締結段階で検査基準や瑕疵の基準として有効に機能しうる程度に仕様がしっかりと定められていることは稀だったと思います。
そしてこれは、発注側の怠慢、つまり、まともな要求仕様やRFPを書かない(というか、書けない)ことに起因していたように感じます。
このような状況下では、契約書に添付されている仕様書という名の「よろしくやっといてよ」をちょっと長くしたような書面を精査できることよりも、どのようにして(本来の意味の)仕様が定まり、変更されるのかを現場に即してしっかり定められることのほうが有意義なんじゃないかと思うのです。
よく「現場を知らなければ良い法務にはなれない」と言われることがありますが、この「現場を知る」というのは、現場の営業や技術者と同じようなスキルを持つという意味ではなく、どのように営業や技術者が動くのかを把握するということのはずです。
その意味では、法務がプログラミングをできるようになっても、直接のメリットはほとんど無いと思うのです。
というわけで、プログラミングに縁遠い法務の皆様、ご安心下さい&もっと現場の話を聞こう!という趣旨のエントリーでした。
ではでは。
@kataxさんみたいに、自身でプログラムを書けるぐらい技術に通じて仕様書の中身もチェックできる人が、法務パーソンとしては理想的なんでしょうと言及をいただいたので、返信代わりに自分が感じていることをポストします。
僕は今まで、システム開発やソフトウェア開発を営んだり発注する会社に法務として3社所属したことがありますが、そのいずれでも、契約締結段階で検査基準や瑕疵の基準として有効に機能しうる程度に仕様がしっかりと定められていることは稀だったと思います。
そしてこれは、発注側の怠慢、つまり、まともな要求仕様やRFPを書かない(というか、書けない)ことに起因していたように感じます。
このような状況下では、契約書に添付されている仕様書という名の「よろしくやっといてよ」をちょっと長くしたような書面を精査できることよりも、どのようにして(本来の意味の)仕様が定まり、変更されるのかを現場に即してしっかり定められることのほうが有意義なんじゃないかと思うのです。
よく「現場を知らなければ良い法務にはなれない」と言われることがありますが、この「現場を知る」というのは、現場の営業や技術者と同じようなスキルを持つという意味ではなく、どのように営業や技術者が動くのかを把握するということのはずです。
その意味では、法務がプログラミングをできるようになっても、直接のメリットはほとんど無いと思うのです。
というわけで、プログラミングに縁遠い法務の皆様、ご安心下さい&もっと現場の話を聞こう!という趣旨のエントリーでした。
ではでは。