一つ聞いてみたい。皆さんの会社では、有給の取り方がどこに書いてあるか、すぐに言えるだろうか。
言えたとして、その申請ルートが「なぜ今の形なのか」まで説明できる人は、恐らくもっと少ないと思う。（というより、そんなことを聞かれる場面が、そもそも無いのかもしれない。）
自分は2025年1月に、その二つとも誰も答えられない会社にいた。
2025年1月、有給の取り方さえ分からない会社にいた
フリーランスとして2社目の現場で、VTuber 事務所のグループ会社にエンジニアとして入っていた。VTuber グループのファンクラブサイトとかを簡単に作れる基盤みたいなものを作っていた。
その会社は急成長中で、毎月のようにいろんな会社を買収していて、子会社の人たちがたくさんいた。だから子会社ごとにドキュメントの管理の仕方がバラバラで、Notion を使っている会社もあれば、Notion を使わず Google ドライブで管理している会社もあった。
子会社の社長が「うちの会社では有給の取り方さえ、どこに何をすればいいのかよくわからない」と言っていた。
自分はフリーランスとしてただ開発業務をやっているだけだったので、正直、そんなに困らなかった。（そもそも有給を取る立場ですらない。）
ただ、その一言だけがずっと引っかかっていた。有給の取り方が分からないのは、その会社の Notion の書き方が下手だからではないんじゃないかと思った。
5社で働いて、どこも同じだった
あの会社が特別にだらしなかったわけではないと思う。自分はソフトウェアエンジニアとしてベンチャー企業から上場企業まで、計5社で働いてきた。
どこの会社も社内のドキュメントは古い情報と新しい情報が混ざり合っていて、何が正しい情報なのかというのは、そこで働いている正社員でさえ全てを把握できていない。
だから結局、人に聞くことになる。古株の人が組織の「歩く辞書」みたいに扱われて、本来やるべき仕事に集中できなくなる。
その人がいるうちはいい。でも有給の申請ルートが今の形になった理由は、その人の頭の中にしか無い。
組織のソースコードには、コミットメッセージが無い
自分はずっと、組織は巨大なソフトウェアであると考えている。ソフトウェアも組織も、目的とするアウトプットを出すためのアルゴリズムの集合体であるからだ。
社内規定や業務マニュアルがソースコードで、社員がそれを読んで解釈するのがコンパイルで、日々の業務がその実行にあたる。
ここで、ソフトウェアにあって組織に無いものがある。コミットメッセージだ。
コードには「なぜこう変えたのか」を書く場所がある。GitHub で誰かの Pull Request を開けば、その変更にどんな議論があって、なぜ通ったのかまで後から読める。
でも会社の決まりごとには、その場所が用意されていない。Notion のページに残るのは決まった結論だけだ。変更履歴を開いても「誰が」「いつ」「何を」変えたかまでは分かるが、「なぜ」はどこにも書かれていない。
つまり組織のソースコードは、Git 管理されていない。その中で一番痛いのが、コミットメッセージが無いことだ。本記事ではこの状態にある組織を「コミットメッセージのない組織」と呼ぶことにする。決まりは今日も動いているのに、その決まりに至った変更の理由がどこにも残っていない。
意図が不明なコードでも、書いた本人がいる間は困らない。でも書いた本人に聞けなくなった瞬間に、そこは誰も触れない場所になる。会社の決まりごとも同じではないだろうか。
そして、そのソースコードを読むのが人ではなく AI になったとき、この差はもっと大きくなると思う。AI に社内のドキュメントを読ませて答えが的外れになるのは、AI の性能の問題ではなくて、渡しているドキュメントにコミットメッセージが無いからだ。
2025年4月、GitLab の Handbook を知った
たまたまネットサーフィンをしているとき、安野貴博さんが GitLab Handbook という文化について解説する記事を見た。
その頃はちょうど、自分のドキュメント管理のビジネスをどうやるかを探していた。Handbook はそれと相性があるものだなと感じ、千田和央さんの本を2冊買った。
1冊は『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』。もう1冊は『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術』。
GitLab の Handbook は、社内文書なのに誰でも読める形で公開されている。会社のルールも、何をどう決めたかも、全部そこに書いてある。分量は2,000ページを超える。
しかも Handbook を直すのは、コードと同じやり方だ。誰でも merge request（変更提案）を出して直せる。だから変更のたびに、なぜそう変えたかが議論ごと残る。
そして GitLab はオフィスを持たない会社だ。2,500人以上の社員が65か国以上に散らばっていて、経営陣ですら毎日顔を合わせることはない。勤務時間も固定されておらず、仕事と仕事以外の時間を非同期に行き来する「non-linear workday」という考え方だ。これで会社が回るのか、と正直思った。（回っていた。）
読んでいて、システマチックで、会社というものがちゃんと仕組み化されていて美しいと思った。会社として利益を生むための関数がしっかり回っていて、実行可能な状態になっている。
つまり GitLab は、組織のソースコードを全部公開したうえで、コミットメッセージ付きで回している会社だった。
エンジニアには Git がある。ほかの人には無い
ただ、本を読み終えて一番引っかかったのはそこではなかった。GitLab は GitLab という自社製品でドキュメント管理をしている。自社製品だからビジネス職にも Git を強制して使わせることができる、という一点だった。
GitLab ではない会社に、その手は無い。エンジニアには Git がある。何が正しい版なのかが一つに決まっていて、しかも変えた理由が全部残る。でも非エンジニアには、それに相当するものがない。
だから、非エンジニアでも使えるドキュメントアプリ版 GitHub みたいなものがないのかと探した。でも、無かった。それなら自分で作ろうと思った。
作るときに決めたのは、非エンジニアに Git を覚えてもらう形にはしない、ということだった。Git の Branch や Commit、Pull Request といった概念を隠蔽した画面にして、Git を知らない人でも同じことができるようにする。
GitHub の wrapper を4か月半作って、捨てた
2025年4月18日、GitHub API を叩くコードを最初に入れた。フロントエンドだけ非エンジニアでも使える簡単な感じにして、バックエンドは全部 GitHub にすればいいんじゃない？という構想だった。GitHub の wrapper でやれば簡単に作れるでしょうと思って、3か月くらいで作ろうと思っていた。（この見積もりは当たらなかった。）
画面では Word のように書けるようにしていたが、GitHub の中では、文書は Markdown という記号混じりのテキストだ。二人が同じ場所を別々に書き換えると、GitHub はどちらを残すか選ばせてくるのだが、その画面に出てくるのは保存されている生のテキストで、太字は ** で囲まれ、見出しには # が付いている。
つまり、有給の取り方を直しに来た人に、その画面で Markdown を読ませることになる。
バックエンドを GitHub API にして早期にリリースしようと思ったが、それでは非エンジニア向けに Git の概念を隠蔽した UI/UX にはできなかった。
2025年8月30日と31日の最後のコミットでは、アプリ自体に「有給取得の方法を提案」という文書を入れて動作確認をしていた。ログインも、ドキュメントの編集も、差分表示も、変更提案のレビューも通っていた。ただ、あの子会社の社長に見せられる画面ではなかった。
GitHub の wrapper に手を付けた4月18日から、最後の8月31日まで約4か月半。そこで手を止めて、ゼロから作り直すと決めた。その翌々月、2025年10月に会社を作った。
「信頼できるページは1%未満」と言われた
社内のドキュメントを誰も信じていないのは、あの会社だけの話なのか。それを確かめたくて、作りながら、別の5社に需要ヒアリングをさせてもらった。社内の Notion や Wiki の中で「本当に信頼できる」ページの割合は体感でどれくらいですか、と全部の会社に同じことを聞いた。
答えは割れた。SaaS 企業のエンジニアと政府系金融機関の担当者は「8〜9割は信頼できる」と答えた。一方で、製造業グループの金融子会社（社員150人ほど）の担当者は「1%未満」と答えた。
議事録のようなフロー情報の蓄積が中心で、AI が参照しても確実に合っていると確信できる最新のストック情報がほぼ存在しない、というのがその理由だった。
その人にデモを見せて一番刺さった機能を聞いたら、書きやすさではなく「1つの正解となるメインブランチ（マスター情報）を作れること」だと言われた。
別の日、政府系金融機関の担当者にも同じデモを見せた。一番刺さった機能はどれかと聞いたら、「意思決定の履歴が残るのが一番重要。これが大きい」と返ってきた。
2026年8月22日、Traceity を出した
有給の取り方の話に引っかかった2025年1月から、19か月が経っていた。
Traceity を簡単に言えば、Notion のようなブロックエディタの UI で、GitHub と同じフローでドキュメントを管理できるシステムだ。フローというのは、変更提案（Pull Request）→ レビュー → マージのことだ。自分としては、会社の決まりごとにコミットメッセージを付けるための道具だと思っている。
有給の申請ルートを例にすると、誰かがブロックエディタで文書を直すと、その編集は「変更提案」（Pull Request）としてまとまる。担当者が差分を見て、コメントや承認をつける。承認されて反映されたあとも、誰が・なぜ変えたかまで、すべて履歴に残る。
変更を確認する画面。追加は緑、削除は赤
変更提案には「変更の理由・経緯」を書く欄がある。これが組織のコミットメッセージになる
だから冒頭の問い、「その申請ルートはなぜ今の形なのか」に、決めた人に聞かなくても答えられる。そこへ至った提案と議論が、そのまま残っているからだ。
履歴の画面。どの決定も、そこに至った変更提案と議論までさかのぼれる
一つ書いておくと、wrapper として GitHub に丸ごと任せるのはやめたが、GitHub 連携自体は残した。Traceity と GitHub のリポジトリは双方向に同期していて、エンジニアは手元のエディタから、ほかのメンバーは Traceity のブロックエディタから書ける。
エンジニアは IDE、ほかの人はブロックエディタ。同じ文書が一つに保たれる
そのうえで、想定している使い方は3つある。一つ目は、GitLab Handbook のように、社内のストック情報を GitHub で一元管理すること。招待したメンバーの誰もが、既存の仕組みに対して変更提案を出せる。
二つ目は、社内で作った業務アプリのドキュメントを、そのアプリのリポジトリで管理すること。Traceity とリポジトリ側のドキュメントのディレクトリを同期するので、コードと文書が別々の場所で古くなっていかない。
三つ目は、AI に「なぜこうなったのか」という意思決定の背景をコンテキストとして渡すことだ。Traceity の MCP を通して、Claude などにマニュアルを読み込ませられるのだが、このとき渡るのは本文だけではない。変更提案やコミットとして意思決定の経緯が残っているので、「なぜ今の仕組みになったのか」まで含めて AI に渡せる。
AI が参照しても確信が持てない、とあの担当者は言っていた。組織がソフトウェアなら、ソフトウェア開発に「正となる main ブランチ」があるように、ドキュメント管理にも main ブランチの概念が必要だ。AI に読ませるのは、その main ブランチだけでいい。
おわりに
ここまで、「コミットメッセージの無い組織」という見方と、そこから作った Traceity について書いた。
正直、この見方がどこまで正しいのかは、まだ自分でも分かっていない。
「保存＝即反映」に慣れた組織に、変更提案と承認のフローは受け入れられるのか。信頼できるページが1%未満だと言ったあの会社は、珍しい方なのか、それとも普通なのか。
だから、自分の会社の決まりごとを一つ選んで、なぜそうなったのかを誰かに聞いてみてほしい。答えられる人がいなければ、それがコミットメッセージの無い組織だ。
そのときは、traceity.com を触ってみてほしい。そのうえで、どこが使いづらかったかを教えてもらえると嬉しい。
この記事は Zenn にも同じ内容で書いた。