GitHubの「思想」と非IT分野
はじめに
筆者について
- とある企業で全く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の思想を応用することはできないものか。
次回
上記を踏まえて、非IT分野における最も普遍的なツールスイートであるMicrosoft 365を前提とした思想の実装を考えてみたい。
Discussion