📄

MS365環境での「Poor Man's GitHub」を法務業務に

2024/10/15に公開

前回までのあらすじ

前回
GitHubの「思想」と非IT分野

  • 非IT産業の組織で大規模なドキュメント(契約書)を多数部署にレビューしてもらうの、規模がデカくてしんどい!
  • ITの世界の思想で切り分けたらGitHubの親和性が高そうだぞ?
  • GitHubみたいなバージョン管理とイシュートラッキングをドキュメントレビューに実装したいな!

「Poor man's GitHub」のススメ、または持たざるもののDX

さて、思考の実装である。

思想を実際のフローに落とし込むために最も簡単な手段は「その思想で作られたツールを導入すること」である。要はGitHubを導入してしまえばいいのだ。実際Wantedlyはそういうことをやっているらしい。

これは最初からボツにする。

エンジニア諸氏からは「じゃあGitLabは?」「GitHub Desktop使えば」という思いつきが発生するかもしれないが、そういう次元の話ではない。そもそも素養がないところにそんなものを導入するのは、異常な量の教育コストがかかってしまい、現実的ではない絵空事になってしまう。そもそも筆者は下っ端である。

CLIを触ったことも、バージョン管理の思想に触れたこともないような人に、高度に発達した魔法のような文明の利器について教え、使わせ、管理し、アカウントセキュリティを含めたHousekeepingを行うリソースは膨大である。これを他部署間でお金をかけてやる、ということができるのは、牛が球体であったり、空気抵抗がゼロであったりするHypotheticalな環境である。少なくとも現状にはそぐわない。

ではリーガルテック分野にはそうしたものがないか。法務分野の類似ツールとしてはHubbleという「法務向けGitHub」みたいなツールがある。これを導入すればいいのでは?

これは短期では実現が難しいので、中長期的な目標にする。

たとえ非エンジニアでも使いやすいとしても、それの手前にはツール導入というのはお金の問題がある。IT企業でも簡単ではないところに、非エンジニア「しか」いない環境におけるITツールの導入というのは、OSI参照モデル第8層以上でのとんでもない量の調整と問題解決が必要になってしまう。そもそも筆者は権限がほぼない下っ端なのである。

サイゼリアのステップワイズなDX

この件についてはサイゼリアのオーダーシステムの電子化をお手本にしたい。あれはまず品目番号を核として、紙の注文票→店員のiPod Touchという流れでスタートして、客と店のオーガニックなシステムを「調教」したことによって成功している。長期的には次のステップを見据えて、店員用のUIを流用して客のスマホで番号を入れさせる、というステップワイズな進め方をしていた。これは大いに参考になる。

それぞれの階段の高さを最小限にすることで破綻を起こさずに徐々に変革を進め、長期的な戦略で全体的なコスト(ハード、開発、クレーム対応、全体の人件費)を下げるというのは、持たざるもののDXな気がする。

目の前の問題を解決するには、思想をそのままに、今あるツールセットと工夫で実装するのが最も早く、障害もなく、それでいて専用ツールがもたらす70%くらいの幸せをもたらすことができる…はずである。

加えて、サイゼリアをお手本にするなら、今のワークフローを徐々にGitHubに思想レベルで寄せていくことで、将来的にGitHubそのものやHubbleなどの思想が近いツール導入のための土を作り、そうした種が芽吹くかもしれない状況を作ることができる。

思想をそのままに、今ある手札でワークフローを改善すること

まずは課題として下記を設定する。

  1. Issueの数が膨大であること
  2. Wordのコメントとかいう進捗管理機能もなく、他ツールとの連携も人力コピペおじさんがいないと実現できない機能への依存

そして解決に至る道として下記を条件とする。

  • その解決を他のMS365ツールでできる範囲内で行う
  • 他部署業務フローには最小限の変更と負担とする
    • 教育コスト・調整コストの低減
  • 新規ツール導入はなし
    • 金銭的・調整コストを考慮したくない

こねくり回したうえで、概ね、下記のような流れを想定すればいけそうな感じになった。

  1. 法務にExcelでコメントの一覧を作ってもらう(Issueの自動化対応のためのデータ整形)
  2. ExcelからPlannerへPower Automateで移行(Issueのステータストラッキング)
  3. PlannerタスクをベースにTeamsで議論して方向性を定める(Issueコメントの機能)
  4. 議論の結果をクリーンに反映し、Pull Request相当のファイルとして分離する(修正案の実装)
  5. それについて法務とMTGやTeamsで議論する(Pull Requestのコメント)

1. コメントのExcel化

これはまずエキスパート部署からExcelでももらうことで、ちょっと楽をする。

当初の構想ではPower Automateを使用することで、Planner等の進捗管理ツールに移行させることを考えたが、WordのコメントをPower Automateで抽出するのはかなり大変そうなので、最初からExcelにしてもらう。この負担はエキスパート部署に飲んでもらう。

下流フローや社外環境のことを考えて、Wordファイルへのコメントも入れてもらうかどうかは要検討。

2. Plannerタスクへの転記

その上でExcel上のコメントを機械さんが読めるデータとしてPower Automateに食わせてPlannerタスクに転記する。

またもし1.でExcel化が難しければ、コメント機能ではなくて、文中にコメントタグの運用を徹底(e.g. 【法務コメント】みたいなタグ)してIn-lineなコメントにしてもらって、そこからPower Automateで抽出をかけて、Plannerに転記する、ということもできるはず…多分。筆者はコードが書けないが、多分機械さんとしてもやりやすいはず。Validationのことはとりあえず考えないことにする。

ここでタスクごとに必要部署の担当者をアサインして、デッドライン、進捗、ステータスを管理する。

3. Plannerタスクと議論

Issueは立てたあと、コミュニティ・ステークホルダーとの議論がある。これは契約書でも同じである。
指摘の入った箇所について、必要に応じてTeamsチャンネルや他のコミュニケーションツールを通して議論する。
このときにそれぞれの議論が相互に見えつつ、一つの論点ごとに集中できるような可視化のコントロールができると良い。Teamsのスレッド機能が適任なように思われる。親ポストにPlannerタスクのリンクを貼っておけば良い。

4. 変更の実装

議論の結果取りまとめられたそれぞれのステークホルダーの意向が明らかになったら、交渉のための実装が始まる。
これはクリーン版に新たに変更点を追記していく形で行う。

ここで作業ファイルを分けることで、Issue階層の議論とPull Requestのレビューコメントの層をファイルレベルで分離し、関わる部署をエキスパート部署と自分に制限して無理やり人間が取り扱える規模の情報量に落とす。

おそらくここで作業ファイルと見えている情報をワークフローの前後で分離することで、擬似的に棲み分けができるだろう、という算段である。

この作業ファイルは原則としてエキスパート部署と締結先のみとやり取りをするので、純粋に契約書言語の方向性のみに集中した議論をする。

5.それについて法務とMTGやTeamsで議論する

最後はこれである。エキスパート部署とのみ4.のファイルを触るので、その議論についても数名で実施すれば終わる。
小さくTeamsチャットや、IRLのMTG等で詰めていくことができるだろう。

最終的に5. を踏まえて実装した修正案を第n+1校として、締結先に提示すればサイクルが1周する。

レポジトリの作業ディレクトリなどの試案

上記のワークフローを実装するために、下記のツリー構造を使うことを想定する。

  • 案件フォルダ
    • 社内ドラフト(Issue階層)
      • 第1校_YYYYMMDD
        • 契約書ファイル(エキスパートコメント付き)
      • 第2校_YYYYMMDD
        • 契約書ファイル(1校提案+締結先コメント付き)
    • 社外提示ドラフト(Pull Request階層)
      • 第1校_YYYYMMDD
        • 契約書ファイル(1校提案付き)

加えてそれぞれの階層に属するファイルとしてのPrefixを定義して付番して、それとタイムスタンプによるバージョンコントロールを実現する

Discussion