会社法、金商法、その他の法律は技術的負債か。その対応はリーガルテックで可能か。

会社法、金商法、その他の法律は技術的負債か。「技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。」
https://qiita.com/erukiti/items/9cc7850250268582dde7

シンプルであり、国民に分かりやすくすべきという観点からすると、理想から離れたものという理解は間違っていない。

どうやって技術的な負債と戦うか。

「コードを追加する時に少しずつ綺麗にする (ボーイスカウトルール)
チームの誰かを技術的返済要員にする
定期的に返済タイムをもうける
見積もりに合わせて閾値を超えたら返済する」

つまり、変化の時に一緒に直すほうが良いというのが分かりやすい。しかし、コードと違うのは、コードは技術者だけが分かればよいが、大幅な変更を何度もすると、国民はより混乱をするかもしれない。この点の改善が必要で、GitHubを使い、いつでも、改正その他をたどることが容易にできる状況を作るのが望ましい。

「知見をスムーズに共有する
そのプロダクトに必要な知識(ドメイン知識)は、スムーズに共有されていなければ圧倒的な技術的負債になる。特に見えにくい要素だけに注意が必要だ。」

広報手段がより分かりやすいものが必要になる。ここはリーガルテックの部分と言える。

「ドメイン言語を確立する
同じ言葉を、皆がばらばらの呼び方をしていないだろうか？できる限りそれらを一つの言葉に統一すべきだ。もちろんこれは設計やソースコード内部にも言える。呼称する言葉をうまく英訳してソースコードの中で使いたい。」

これは、上と同じことをいっている。

「Wikiなどを活用する
誰もが共通で見られて編集が行える、統一した文書システムが望ましい。ドメイン知識を文書化していこう。」

技術的な施策はそうしたものになるのだろう。

「コミュニケーションを密にする
技術者とステークホルダーのコミュニケーションが足りなければ、的外れなモノを作ってしまいがちなのでコミュニケーションを充実にする必要がある。この時、スループットよりもレイテンシを重視すべきだ。」

関係者とのコミュニケーションを密にすることは大事。大体８０％の問題は２０％の部分（一部）なのだから、この部分のコミュニケーションを怠らないことは大事。

「VCS(バージョン管理システム)を使う」

上述の通り、github

「CI(継続インテグレーション)を構築する」

半自動化、クラウド、シミュレーションをすぐにできる仕組みができないか。

「開発する環境と本番環境の差異をなくす」

シミュレーションをより、現場と近づけることができないか。

「個人環境を簡単にセットアップできるようにする」

それぞれの思考を一体化するツールを作る。これ一番大変そう。各々の頭は３０代、４０代、５０代でOSが異なる。少なくてもコミュニケーションツールくらい一緒にするか。

「コード静的解析を行う」

ここはリーガルテックでできるのではないか。

「ライブラリ・フレームワークや言語のバージョンアップ
テストを書く」

つねに、既存のバージョンを疑う。。。これはできるのか。。。

「テストを書く」

自動テストプログラムを作る。

「リファクタリングを行う」

「常日頃からプログラムを整理し、仕様変更にも対応できる整理されたプログラムを書いていく考え方が生まれた」

やはり、分かるものが何度も提案をする仕組みが必要なのだろう。これも、技術的には可能であろう。

「コンパイラ警告や静的解析の結果に対応する」

分かりにくくなっているもの、裁判例などがでたら、自動的に警告が出る仕組みも考えられる。しかし、判例で蓄積する手法もあるのでこれはどうか。。

「コーディング規約に合わせる」

もう少しコーティングのお手本について意識することは必要なのかもしれない。

以下も参考になりそうだ。

貯まった問題との付き合い方——割れた窓の法則、エントロピーの法則に見る技術的負債が起こる理由 (4/4)

http://www.mext.go.jp/b_menu/daijin/detail/1414447.htm
これを見る限り、コミュニケーションツールは少しずつ変わりそうだ。