初めまして。Sansan EU Master Dataグループ所属の金子です。
私の所属しているMaster Dataグループはデータ活用部門として、プロダクトで活用されるさまざまなデータを扱っています。私はその中でも、企業関連データを作成するチームに所属しています。新卒でこのチームに配属され、現在は3年目になります。一通り業務にも慣れた頃ですが、そんな私に別チームで働く機会が舞い込んできました。
背景
データ活用部門では、「流動性向上施策」なるものを推進しています。我々のグループは複数のチームからなっており、それぞれが異なるシステムの開発・運用を行っています。流動性向上施策では、チームに関わらずどのメンバーも、すべてのシステムを扱えるように取り組んでいます。この施策の狙いとして、次の点があります。
- チーム間で柔軟に人的リソースを配分できるようになること
- 異なる技術に触れるなどの技術的な挑戦を発生させること
- 自チームの知見を他チームに横展開する機会が生まれることで、チーム間での良い相互作用を促進させること
私はそんな施策の一環として、データの名寄せを担うNayoseグループに3カ月間の留学をすることにしました。NayoseグループはMaster Dataグループとは異なる部署です。しかし、マスターデータを整備する上で、データが適切に名寄せされていることが重要なため、切っても切り離せない関係です。 この留学を通して私はさまざまなことを学びました。その中でも今回は「チームの壁を乗り越える」と題して、留学中に私が発見した、チーム間で連携する時に陥りがちな課題、そしてそれを解消した話をます。
チームの壁1. 「コンウェイの法則」を実感する
留学する上で、私の主目標として設定されたのが、「双方のシステム連携上における技術的負債の解消」です。Master DataグループのシステムとNayoseグループのシステムは連携しており、定期的にデータを同期することが必要です。しかし、今まではその同期が手動のファイル連携で行われており、次の課題が存在しました。
- 作業に時間がかかる
- 手動作業によるミスの発生リスクがある
- 繁忙期などに作業が後回しにされたり、忘れられたりする
これらの課題を解消するために、同期作業の自動化プロジェクトを進めました。そして、このプロジェクトを通して、今まで用語としてしか知らなかった「コンウェイの法則」を実感しました。
コンウェイの法則とは
コンウェイの法則とは、システムの構成が、開発チームの組織構造、コミュニケーション構造を反映してしまうという法則です*1。両システム間の連携方法は、まさに「コンウェイ的」になっていました。
原因
自動化前の手順では、連携用のCSVファイルとして、3種類のCSVを使用していました。それぞれが「データの削除・作成・更新」というユースケースに対応しています。 自動化に取り組むにあたって処理を整理したところ、CSVファイルが3つに分かれている必要は全くないことに気づきました。既存の手順をそのまま採用するとしても、CSVファイルを1つ提供すれば済んだのです。では、なぜ3つのファイルを連携する仕様になったのでしょうか。それこそまさに、コミュニケーション構造の問題でした。 この手順を作った際のMaster Dataグループ側の担当者は私で、その時は次のようにプロジェクトが進んでいました。
- システム間でデータを連携する必要があり、連携には大きく分けて3つのユースケースが存在する
- 3つのユースケースごとにプロジェクトを立て、担当者を決め、実現の方法を検討する
CSVが3つに分かれたのは、まさにこの進め方に由来していたのです。双方のシステムの構造を知っている人間が1人でもいれば、ファイルは1つだけで済むことに気づけたでしょう。
1つのチームで仕事をしていると、どうしても関心事が自チームで持っているシステムに閉じてしまいがちです。相手のシステムは相手が語る以上のことは分からないため、その限られた情報の中で物事を進めていくしかありません。 気づいていないだけで、おそらくこうした例は氷山の一角なのでしょう。
チームの壁2. 「車輪の再発明」を防ぐ
「車輪の再発明」は、ITエンジニアなら一度は聞いたことがあると思います。それも、大抵は「車輪の再発明をするな」という論調で。今まで耳が痛いほど聞かされてきたこのフレーズですが、車輪というのは身近なところに潜んでいました。
発見した車輪
では、私が発見した車輪を紹介します。
私が留学先のNayoseグループの朝会に出席していると、企業の法人格を抜き出すロジックの話になりました。法人格というのは、株式会社や有限会社などの会社形態を表す用語です。これを実装するには、まずどんな会社形態が存在するか、そしてそれぞれの省略表記がどうなっているかを調べる必要があります。 その調査タスクが切られようとした時、私はあることを思い出しました。 Master Dataグループでは企業関連データを製造する関係上、企業に関係する多くのロジックを持っています。その中に同様のロジックが既に存在します。そのロジックを参照すれば、調査する手間が省けるのです。このロジックの存在を伝えることで、車輪の再発明を事前に防げました。
この件から、過去に読んだ『達人プログラマー』という本に出てきた、こんな話を思い出しました。
合衆国政府のコンピューターシステムが西暦2000年に対応できているかどうかを監査した時の話です。この監査を行ってみて初めて、10,000本以上のプログラムが社会保障番号(SSN)をチェックする機能をそれぞれ独自に実装していたことが判明したのです。
ここでは防げましたが、この話にあるように、組織全体で見たら同じようなロジックは大量に出てくることでしょう。
まとめ
今回は、留学することで見えたチームの壁というテーマで、2点の学びを紹介しました。お隣さんのチームとして密接に仕事をしているつもりでも、非効率なコミュニケーションを取ってしまっていたり、同じ課題を解いたりしていることがあるのは驚きでした。こうした問題を完全に撲滅することは難しいですが、問題の存在を知っているだけで取れるアプローチも変わってくると思います。 「あのチームならこの処理を持ってそうだな」とか、「本当にこのインターフェースが必要なのだろうか」といった具合です。
また、細かいことを挙げるとキリはないですが、他にも学びはたくさんありました。使っている言語、フレームワーク、チームの雰囲気、プロジェクトの進め方、設計書のフォーマットからPRレビューの方法まで、両チームにはさまざまな違いがありました。こうしたものはチームの文化として統一すべきだとは思いませんが、良いものは元のチームに持って帰り、逆に不便だなと思った点は自分のチームの方法を紹介したりしました。
自チームでの業務に慣れてきた3年目というタイミングで他チームでの業務を体験できて本当によかったです。
今後は数少ない「両チームの事情を知っている者」として、今回紹介した事象に気をつけながら、チームに縛られない柔軟な動き方をしていきます。
私たちのチームでは Web アプリ開発エンジニアを募集しています。Web アプリ開発だけではなくデータエンジニアリングなど、幅広い業務を経験できます！
