法的な壁が何か調査する

[masskaneko]

私の経験では、インナーソースを始めるのには法的な壁があります。例えばこういうものです。

• 多国籍の拠点間で自由に高頻度にコードやドキュメントを共有しながら開発するには、外為法における輸出管理をどうすればいいのか
• 複数のグループ会社で共通するコードというのは考えられるが、不正な利益供与に接触しないのか。どのように資産計上すればいいのか。
  • Slack#general の関連発言

これを調査すれば新たな pattern になるかもしれません。

[yuhattor]

@masskaneko 価格移転も重要ですよね。
ご存知の通り日本の製造業とかは巨大なホールディングス・グループになっているケースが多く
こういうところが間違いなくボトルネックになります（なっています）
これが解決されない限り、大規模なインナーソースは絶対に実現されないと思います。
#19 とかもそうなんですが、日本初、日本発のパターン産みたいですね。

@hirotakatoya もメンションしてみます

[yuhattor]

@hirotakatoya ここら辺って、項目あげるとしたらどうでしょう？？

[hirotakatoya]

@yuhattor

どうも、こんにちは。法的な壁のテーマ、面白いですね。法的な壁だけでなく社内手続き上のよくある壁も一緒に考えられると面白そうです。法律は専門ではないのですが、思いつく範囲で書き出してみました。どうやって対処していけば良いのかについても、コミュニティで一緒に知恵を絞っていけると良いですね。海外の事例で日本でも転用できること、日本初で海外でも転用できることもあるのでしょうね。

＞・複数のグループ会社で共通するコードというのは考えられるが、不正な利益供与に接触しないのか。どのように資産計上すればいいのか。
→税務上の資産計上では、グループ法人税制、移転価格税制等に対応した税務対応を考える必要がありそうですね。会計的に無価値だからといって、利益供与にならないわけではないので。会社によっては、部門予算と絡むと気軽に使えなくなる問題もありそうですよね。IFRS対応もあるでしょうか。不正な利益供与以外に、不正な利用（税務上計上していない実験的なISSを他の部門が実用で使ってしまったり）も場合によっては抵触しますね。やり方を考えていけると良いですね。

＞・多国籍の拠点間で自由に高頻度にコードやドキュメントを共有しながら開発するには、外為法における輸出管理をどうすればいいのか
→都度申請するとなると大変ですね。アジャイル開発の事例など参考にできるのでしょうか？

・複数の会社がコントリビュートしたコードを利用したい場合は、どのように利用許諾契約の手続きを進めればよいのか。
→複数の会社と契約手続きをするのはとても煩雑になりそうですよね。いろいろな工夫が考えられそうですね。契約以外にも、特定商取引法などありそうです。

・他社からの委託開発の中で作成したソースコードの一部をISS化したい場合、他の業務で活用したい場合は、どのような手続き（会計、税務、委託先との間のスキーム）を行えば良いのか。
→他社からの委託開発の中で作成したものは、通常、委託元の資産となるため、勝手に使う事はできないですよね。一方、共通ライブラリとして転用したい場合があることも当然です。ユーザから著作権の一部を譲渡してもらう契約など、委託開発のものを他でも使いまわせるよう工夫している会社もありそうですね。

・他社からのコードを取り込む際の法的リスクをどのように扱うのか
→取り込もうとしているコードが、特許権・著作権を侵害している場合もありますよね。

・データをISS化したいが、情報保護の観点はどう扱うのか？
→個人情報保護法などが壁となりISS化できない場合もありそうです。

・ISS開発において内部統制はどう図るのか？
→ものによっては、J-SOX法対応などありそうですね。やり方によっては下請法なども気をつけるべき点があるでしょうか？

・悪意ある従業員がISSソースコード盗んで外に持ち出してしまうリスクにはどう対処するのか？
→法律でなく知財保護ですね。フルオープンでなく希望者から連絡をしてもらって加入してもらうような招待制にしているISS事例もありましたよね。

[yuhattor]

おお、、、、論点がめちゃくちゃ上がりますね。ありがとうございます！！！

結局のところ、法的なところはどうにか解釈でなるとしても (なったらいいなという希望もありますが)
会計的なところと、運営上のルール・とらえかた
と言う意味に大変な障壁があるように感じます。

[hirotakatoya]

どうもありがとうございます！これだけ論点があるというだけでも、日本のインナーソース・コミュニティを立ち上げる意味がありますよね。運営上のルールという意味では、従業員の自主的な活動をどのように担保できるのか、どう管理すべきなのかというのがあるでしょうかね。各社すでにいろいろなボトムアップ活動の事例がありそうなので、参考にできるものがあるといいですね。
将来的には、行政への働きかけの活動が効果的になる場合もあるでしょうし。Slackの#jp-generalでも現状把握や解決策について検討をすすめていけるといいですね！

[yuhattor]

@masskaneko @hirotakatoya @ystk
これ、アクションどうするのが良いですかね。

• たとえば海外の Bosch な人とかにインタビューしてみるのどうでしょうね。
  「会計系って、どうしてるの？」「ベストプラクティスちょうだい」みたいな
• 既存のリソースをまとめてみる
  https://dirkriehle.com/wp-content/uploads/2021/04/Inner-Source-Transfer-Pricing.pdf
  ここら辺の話題とか、改めて整理してみる。
• 各企業の社内へのインタビュー 上記を踏まえた上で、社内の調整するときの法務部門・会計部門などにもインタビューしたいですよね。

最終的なアウトプットとして、InnerSource Commons の流れに則るなら以下のようになるんじゃないかと思います

• 手法論が Pattern としてまとまっている
• Pattern からリソースが参照できて、テンプレートなど (日本語も)がダウンロードできて雛形に使える

これだけだと
足りなそうですが。

ちょっとこの活動は上手く体系立ててチーム？のようなかたちで進めたいですね。
ソフトウェア法務関連の著名人にも InnerSource の活動に参加していただきたい...

[masskaneko]

まずは、法的な壁 (あるいは、おそらく日本企業に多い社内手続き上の壁) として何があるのか整理しましょう。
すでにこの #27 だったり、先日の InnerSource Commons Meetup 1 だけでもそのヒントは多く出ています。

私は以下のように整理を進めています。

• 外注
  • 請負契約が主体の協力会社が契約先の事業会社のインナーソースにコントリビューションできるか？
  • 請負契約が主体の協力会社内でのインナーソースを実現できるか？
• 会計
  • インナーソースはどのように資産計上するべきか？
  • 単年度会計とインナーソースは整合するのか？
• 輸出 (外為法)
  • インナーソースに適した輸出管理の方法があるか？
• 情報セキュリティ
  • 会社全体での情報共有と need to know 原則は整合するか？コードの機密レベルをどう設定するか？
• 情報インフラ
  • どの部署、どの国内拠点、どの海外拠点の社員、自宅/オフィスからでも高頻度に貢献できるような情報インフラを構築できるのか？情報通信白書を見るに、多くの企業はまだゼロトラストネットワークではなく、クラウドの採用に二の足を踏んでいる企業も多いだろう。
• 人事評価
  • インナーソースへの貢献と所属部署・担当製品への貢献をどう評価するか？
• 組織構造
  • 組織構造には、1社の1事業部門、1社の多事業部門、国内グループ会社複数、国内海外問わずグループ会社複数というバリエーションが考えられるが、インナーソースの実現可能性とどのように関係するのか？
• 製品群
  • 1つの大きな製品開発でのインナーソースと多製品間でのインナーソースはどう異なるか？
• 予算
  • インナーソースを推進する予算はコーポレート予算？推進部署の予算？各開発部署が持ち寄り？
• 工数
  • インナーソースへの貢献工数と所属部署・担当製品への貢献工数に分かれるとき、従来の工数見積りにどう影響するか？

この整理は完全ではないですし、1項目に閉じて議論できる項目ばかりではないでしょう。
ですが、議論の明確な切り口にはなるはずですし、どの分野のソフトウェアエンジニア 以外の専門家 にコンタクトすればよいかも見えてくるでしょう。

これを踏まえてどうアクションするかというと、general チャンネルで軽く聞いてみるのは手をつけやすいアクションだと思います。

「アメリカではこうやってる会社が多いんじゃない？」 「ドイツにはそんな法律ないよ」 程度の軽い回答を得るのが目的です。
もしかすると、具体的な事例や、準拠している法律を示す政府の Web サイトを教えてくれるかもしれませんが、Slack では限界がありそうにも思えます。上記の項目の中から、はっきりしている壁、突破に難航している壁を選ぶのがよいでしょう。相手からも理解できそうな表現にするのも必要だと思います。例えば輸出と情報セキュリティは大きな壁ですし、どの国の方にも理解してもらいやすいものだと思います。

そして、法務部門・会計部門などにもインタビュー というのはぜひやりたいところです。ソフトウェアエンジニアの専門性では限界がありますので。社内IT部門 (情シス) であれば、Connpass で勉強会を開いている程度のオープンなコミュニティがありますので (例：日本の Office 365 Users Group) 、そこに議論を持ちかけてみるアイデアを思いつきました。

[yuhattor]

@masskaneko Microsoft でどのように処理しているのか。調べてみます。
(限界はあるかもしれません)
例えば、マイクロソフト ディベロップメント株式会社 で開発している Windows のパーツは、会計上どのように処理されて Microsoft Corporation の提供する "Windows" になっている？