DX on 極度乾燥しなさい3.0

GitHubの「思想」と非IT分野

Fri, 14 Feb 2025 23:46:41 +0900

はじめに

筆者について

とある企業で全くITエンジニアとは関係ない業種、業務をやっている立場。作業者の立場であり、CxOの方々やVPoXみたいなエグゼクティブなレベルでのDecision-Makingには関われない程度の下っ端。
職種としては法務関連が近いため、普段法律文書、特に契約書を扱う作業をしている。
業務内容としては、契約書をプロダクトとしたPdMか、締結というプロジェクトゴールまでに必要なすべてをやるPjMという感じ。ラベルはどうでも良いがそういう「ゴールのためのお膳立てと円滑進行のために全てをやる」立場になってしまった。
個人的には論文の執筆管理に使った関係でGitHubを使ったバージョン管理はなんとなくわかるが、他人と共同作業に使ったことはない。
コーディングは経験があまりなく、作られたものを眺めて３割理解できるぐらい。VBAは触りたくない。

法務領域における作業のサイクル

法務業務というのは、法律の社内エキスパートとしての自分の部署、業務を担当する法律のエキスパートではない部署、そしてライセンスのある社外エキスパートである顧問弁護士、という社内ステークホルダー、そして契約書の場合は、それを締結する相手先という社外ステークホルダーが存在する。

一般的な契約書業務というのは、この文書のレビューのためにMicrosoft Wordを使うことが圧倒的に多い。それらは主にコメント機能と変更履歴の記録機能を使って回している人が多い（はず）。

実務的には…

このファイルに社内外のエキスパートがコメントをつけ論点指摘
そのコメントを事業担当部署が確認
最終的に修正内容を考えた上で第n校を作成し
第n+1校を締結先に提示する

というのが1つのサイクルになってくる。以下これを繰り返して、最終校に至るまでに交渉をする、というのが目標になる。

場合によっては、契約書やコメントの翻訳、複数のステークホルダーとの利害調整、付随するレイヤー8以上との調整、目標に至るまでの交渉戦略立案と、それに基づいた変更提案の仕方についての議論など、結構手間のかかる作業が多い。

問題意識

このレビュープロセスは、シンプルな数ページの契約書であれば、Microsoft Wordだけでもちょっとした工夫でどうにかなる。ただ、これが数十ページ、関わるステークホルダーが10に近くなると、論点が100を超え、それぞれについて人間の処理能力で回すことに限界が出てくる。タスクによっては翻訳が挟まることもあり、作業工数はどんどん上がっていく。

そのために業務量が増大していて、コミュニケーションに問題が起きていて、全体の管理に過大なコストがかかってしまっている、という混沌とした状況をどうにかしたい、という欲求だけがあった。

コメントスレッドに進捗管理と議論と実際の変更点の議論が同じところで行われているのが問題に思えた。

漠然と

「論点の進捗トラッキング」
「論点についての検討・意見集約」
「実際に作業するファイルに加える変更」

の間に存在することはわかったが、問題の切り分け方の指針が、いくら探してもしっくり来るものが出てこない。

法務領域というのは、様々な兼ね合いで表に情報が出せなかったり、IT業界と遠い諸々の理由があり、いまいちオンライン空間に情報が出てこないというのが現状である。逆にIT業界側からの記事は往々にしてツールそのもの、技術そのもの、また思想レベルであっても、その実装については「IT業界における」という枕詞がついていることが常で、参考にできそうな情報というのは案外転がっていない。

GitHubの思想を移植する

IT業界で仕事をしている友人にこういう問題意識をぶつけてみて、こうしたコミュニケーションの混沌に秩序をもたらす手法のベストプラクティスを聞いてみた。

出てきたのは「GitHubの思想なんじゃね？」というところだった。特にIssueとPull requestの切り分けの思想ではないか、と指摘を受ける。GitHubを組織的なコンテクストで使ったことがないのでIssueもPull Requestも使ったことがなかったが、友人の話と自分で調べた感じ、下記のような感じらしい。

Issue：今リリースされているコードの問題、新規機能追加要望といった「変更のための問題提起」 Pull Request：BranchしてIssueを解決するための変更を加えたコードを、Issueと紐つけて確認依頼をする「解決策の組み入れ依頼」

そしてこのIssueとそれにぶら下がるコメントも「原因特定などを通して問題提起の内容の精度を高め、それを論点として開発のタスクリストに加えるかどうか」という機能を持っているようである。 Pull Requestにもコメントがあるが、これは逆に「Issueを解決するためのコードの変更点についてのみ議論し、新規の論点は立てない」という運用思想がどうもあるらしい。

もちろんローカルルールかもしれないが、ここで重要なのは「混沌に秩序をもたらす思想」のあり方であって、実際にどう線を引くか、というディティールは、IT業界の常識とは異なる分野に適用するにあたっては、全く重要ではない枝葉末節でしかない。

思想を踏まえたうえでの現状

今の業務フローを見ながら、GitHubの思想の用語でそれを表現すると、

レポジトリたる契約書について、Issueが100＋個立っていて、
Issueについての議論と、方針が決まったあと契約書を変更して交渉するためのPull Requst的な領域の議論が同じところで切り分けなく行われていて
フィルタや検索、優先度タグといった可視性のコントロールの聞かない、ほかツールとの連携もないプラットフォームで作業をせねばならず
やむを得ず作業者が人力Power Autmateコネクターとしてそれぞれ連携していないツール間を繋いでいて
その環境で社内外ステークホルダー4階層30+人ほどの進捗管理とコード修正をミスなく行う

みたいになっている、ということになる。マジ？

適性があったとしても人力コネクター（ルビ：コピペおじさん）やりたくないし、IssueとPull Requestが混沌と混ざり合って100＋件のアクションアイテムが溜まったリポジトリ、誰も見たくないはずである。

これが幸せを生んでいるはずがなく、現に同僚が死にそうな顔をしているし、エキスパート部署もかなり面白い顔になってしまっている。さて、このカオスに秩序をもたらすために、GitHubの思想を応用することはできないものか。

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

MS365環境での「Poor Mans GitHub」を法務業務に

Fri, 14 Feb 2025 23:46:41 +0900

「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などの思想が近いツール導入のための土を作り、そうした種が芽吹くかもしれない状況を作ることができる。

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

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

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

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

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

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

法務にExcelでコメントの一覧を作ってもらう（Issueの自動化対応のためのデータ整形）
ExcelからPlannerへPower Automateで移行（Issueのステータストラッキング）
PlannerタスクをベースにTeamsで議論して方向性を定める（Issueコメントの機能）
議論の結果をクリーンに反映し、Pull Request相当のファイルとして分離する（修正案の実装）
それについて法務と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周する。

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

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