【ITニュース解説】How to Show Engineering Ownership When the Repositories Are Private

多くのシステムエンジニアが働く現場では、開発したソフトウェアのコードは会社の秘密であり、外部に公開することは許されない。これは、転職活動などで自分の技術力や貢献度を示す際に大きな課題となる。履歴書に「このWebアプリケーションの主要な開発者でした」と書いたとしても、その真偽を外部の人が確認することは難しいからだ。過去に勤めた会社のソースコードを安易に他社に見せる行為は、情報漏洩のリスクがあり、かえって信頼を失うことにもつながる。

この問題を解決するために提案されるのが、実際に開発したコードそのものではなく、「自分の貢献度をどのように測定したか」という方法論と、その測定結果を詳細に開示することである。これにより、コードの内容を知らずとも、相手はその測定方法の妥当性を評価し、主張の信頼性を判断できる。

具体的には、貢献度を測る方法として三つの段階的な測定方法がある。 最も単純なのが、「全てのブランチのコミット数」を数える方法である。コミットとは、コードの変更履歴を記録する単位で、ブランチとは開発の分岐点のようなものである。この方法は、開発者が行った全ての活動を数えるため、実験的な試みや本番環境にはデプロイされなかったコードの変更も含まれてしまう。そのため、貢献度を過大に評価してしまう可能性があり、実際に顧客に届けられた価値とは結びつきにくい。コミット回数が多い人が有利になるだけで、実際のコードベースへの貢献度を正確に示しているとは言えないため、この方法は推奨されない。

次に少し信頼性が高まるのが、「在籍期間に限定した本番ブランチのコミット数」である。これは、実際に顧客に届けられた本番環境のコードに対する変更（コミット）のみを対象とし、かつ自身がその会社に在籍していた期間に限定してカウントする。これにより、デプロイされなかった無駄な作業や、自分が在籍する以前の功績を不当に自分のものとすること、あるいは過去の負債の責任を負わされることを防げる。しかし、この方法もまだ課題を抱えている。コミットはあくまで「活動の単位」であり、「コードの単位」ではないからだ。細かく頻繁にコミットする開発者が有利になり、一方で大きな変更をまとめてコミットする開発者は不利になる可能性がある。そのため、この方法も貢献度を正確に測るには不十分な場合が多い。

最も信頼性が高く、推奨される測定方法が、「本番ブランチのgit blame」である。git blameとは、現在本番環境で動作しているコードの各行について、「誰がその行を最後に書いたか」を特定する機能である。これは、単にコードを書いた量だけでなく、「書かれたコードがデプロイされ、その後に行われた他の開発者によるリファクタリング（コードの改善作業）を生き残り、現在も稼働している」という、まさに「生き残った貢献」を測るものだ。真に価値のあるコードは、時間の経過と共に残り続けるため、この測定はエンジニアのコード品質や設計能力を示す強力な指標となる。ただし、この処理は非常に時間がかかるため、全てのファイルに対して実行するのではなく、特定の規則に従ってファイルを「サンプリング」（一部を抜き取って調査）する必要がある。

git blameの信頼性をさらに高めるためには、二つの重要な詳細がある。一つは、特定の「フラグ」を用いてコマンドを実行することである。具体的には、-wフラグで空白のみの変更を無視し、-Mフラグでファイル内で移動またはコピーされたコードの行を検出する。これにより、コードの書式を整えただけのリファクタリングや、コードの場所を移動させただけの変更であっても、元の作者に正しく貢献を帰属させることができる。このフラグを使うことで、一時的に自分のコミット数を増やすような行為を防ぎ、より厳密で正直な測定結果を得られる。もしフラグを使わなければ数値は高くなるが、その主張の信憑性は損なわれる。もう一つは「サンプリングの方法」である。ファイルを恣意的に選ぶのではなく、ソートされたファイルリストから「N番目ごと」といった決定論的な方法でファイルを選ぶ。これにより、都合の良い結果が出るまでサンプリングを繰り返すといった不正を防ぎ、誰でも同じ手順で測定を再現できるようにする。

筆者の具体的な経験を例にすると、ある会社でフロントエンドのコードにおける「生き残った行」のシェアが84.7%であったのに対し、本番ブランチのコミットシェアは80.7%であった。このわずかなギャップが非常に重要である。これは、単にコードを多く書いただけではなく、他の開発者が書いたコードを自身のコードで置き換えたり、統合したりして、コードベースのアーキテクチャ全体に影響を与えたことを示唆している。つまり、コードの量だけでなく、その「設計上のオーナーシップ」を示しているのだ。もしコミットシェアが生き残った行のシェアよりも高かった場合、それは多くのコードを書いたが、その多くが後に他の開発者に置き換えられた、という正直な評価となる。

また、特定のプロジェクトや機能に限定して貢献度を示すことも有効である。例えば、iOSやAndroidのプロジェクトの全コミットが自分のものである場合、それは算術的な事実として最も異論のない主張となる。バックエンドのコードのように全体への貢献度が低い場合でも、テストスイートや特定のドメインサービス、イベント処理のコンシューマなど、「設計判断が特に求められる部分」で高い貢献度を示していることを強調することで、単なるコード量以上の価値を示すことができる。

しかし、これらの測定方法でさえ、全ての貢献を測れるわけではない。例えば、AIのコアアーキテクチャ自体は別の専門家が担当し、筆者はその上に構築されるプロダクトレイヤー（ユーザーインターフェースや設定機能など）を担当した場合、「AIプロダクトに携わった」という漠然とした表現ではなく、具体的にどの部分に貢献したのかを明確にする必要がある。また、会社のビジネス成果（例：自動化率）を個人の成果として提示することは避けるべきである。それは会社全体の結果であり、個人の実績として語るべきではないからだ。

もしgit blameのような高度な測定ができない場合は、「コミットシェア」を提示するしかない状況もある。その場合は、それが最も弱い測定方法であることを正直に伝え、その限界を理解した上で結果を提示することが重要である。

最終的に、このような測定方法と詳細な開示は、採用担当者との議論の出発点をより良いものにするためのものであり、それ自体が「絶対的な証拠」ではない。本当にオーナーシップを裏付けるものは、以下の三つである。一つは、設計書や実装計画書、運用マニュアル、リリース記録といった、自分の説明とは独立して存在する「プロセス成果物」。二つ目は、元同僚や共同設立者など、自分の貢献範囲やオーナーシップを客観的に確認できる「信頼できる第三者の推薦」。そして三つ目は、自分が真に手掛けたシステムについて、改善点も含めて、コードを一行ずつ詳細に説明できる「深い理解と説明能力」である。

これらの測定方法は、「どうすれば自分の貢献度を客観的に見つけることができるか」という方法論を公開するものであり、それによって相手がその測定方法に異議を唱えたり、より深く質問したりすることを可能にする。これは、単なる自己主張を超えて、信頼と理解に基づく対話を始めるための重要な手段となる。