1. GlueWorkとは何か
システム開発の現場では、ソースコードの実装やインフラ構築以外にも、ドキュメント整備、打ち合わせの設定やファシリテーション、オンボーディング支援など、チームを動かすための様々な仕事が存在します。
こちらのブログ記事で、これらの仕事に GlueWork という名前が付いていることを知りました。Glue とは接着剤の意味で、チームを結び付け、機能させ、継続的に成果を生み出すための仕事を指します。
記事の中でGlueWorkは 「プロジェクトの成功に不可欠なのに、成果としては目立たず、社内評価や転職市場価値の観点では軽視されがち」 と評価されてしまう問題が指摘されていました。
この記事では、GlueWork がなぜそのような扱いを受けるのか、そして貧乏くじとみなされないためにどのように評価していくべきかを考えていきます。
2. GlueWorkが評価されにくい理由
Glue Work が過小評価されるのは構造的な理由があります。
記事の中では以下のようなものが紹介されていました。
- 成果が見えにくく定量化されにくい
- 技術的な貢献と評価されず技術者としての昇進に繋がりにくく、PMへのキャリアチェンジを勧められがち
たとえば中途採用の文脈では、ドキュメント整備やチーム調整といった貢献よりも、以下のような「見えやすい成果」を重視されることがほとんどでしょう。GlueWorkの貢献はあくまで補助的なものとして位置付けられがちです。
- 言語やフレームワークなどの経験年数
- 上流工程の経験
- ポートフォリオ
- コーディングテストの成績
その結果、エンジニアが技術職としてキャリア構築を目指す場合、GlueWork は相対的に避けたい仕事と評価されることも多くなります。
オリジナル記事でも、Glue Work に注力することがキャリアを制限する可能性があると警告されています。
3. GlueWorkはなぜ必要なのか
GlueWork が不足すると、チームが機能不全に向かうことは想像に難くないと思います。個人的にも経験があります。
- オンボーディングに手が回らず、新メンバーの戦力化が進まない
→ 結果的に作業進捗が遅れる - ドキュメントがない
→ 正しい仕様把握に時間がかかる - 打ち合わせが足りない、もしくは進まない
→ 開発に必要な情報が遅れて出てきて手戻りが発生する
そのため、新メンバーの世話をしてくれる人、ドキュメントを書いてくれる人、必要な打ち合わせを提案、調整、設定してくれる人はとてもありがたい存在です。こうした働きのおかげでチームとして開発を進めていくことができます。
オリジナル記事では、
Glue work is the difference between a project that succeeds and one that fails.
とも述べられています。
4. GlueWorkを誰が担っていくか
とは言えGlueWork 誰が担うかは難しい問題です。
現場でありそうな失敗パターンをまとめると以下の通りです。
得意な人・好きな人が担い続ける
「あなた得意そうだから」「好きだから」という理由で特定個人が固定化されるケースです。
短期的には回りますが、その人が抜けたり燃え尽きたりすると一気に崩壊します。
専業 GlueWorker を置く
GlueWork自体が評価体系や市場価値と結びつきにくい特徴を持つため、
- 割に合わない役割とみなされる
- キャリアの停滞を招く
- 押し付けられ感が生まれる
という問題に陥りやすいです。
シニアエンジニアやPMにまかせる
実は記事の中では、すでに社内や市場から評価を受けているシニアエンジニアがGlueWorkを率先して担うとよい、という考えが書かれていますが、個人的にはあまり賛成できません。
チーム規模によっては キャパシティ的に持続しないと思います。シニアエンジニアになったとしても技術職としての業務がなくなるわけでは当然ありません。GlueWorkに注力した結果、重要な設計の検討がおろそかになれば本末転倒だと思います。
同じようにPMも、要件定義、顧客折衝、開発スケジュールの管理といった多くの責務があり、一人でチームのGlueWorkを担っていくには限界があります。さらに言えば、プロジェクト内でのドキュメント作成やオンボーディングには技術的な知見が必要になることもあり、能力的にそもそも厳しいこともあるでしょう。
結論としてはシンプルで、誰か一人に寄せようとすると破綻する、と考えています。
Glue Work は 分担・循環するべき仕事 と捉える必要があります。
5. GlueWorkを分業するにはどうするか
では、Glue Work を持続可能に分担するためには何が必要でしょうか。
GlueWorkを可視化する
まず必要なのは、Glue Work を暗黙化から明示化することです。
- 何が Glue Work なのか
- 誰が担っているのか
- どのくらい時間を取られているのか
といった認識がなければ、分担も評価もできません。
プロジェクトのタスクとして扱う
Glue Work を「雑務」ではなく 明確なタスク として扱い、
バックログや WBS に含め、レビューやスプリント計画の対象にします。
Glue Work も仕事であるという前提を
プロセスに埋め込むことが重要です。
技術力の一種として捉え直す（リフレーミング）
GlueWork が価値ある仕事として評価されない限り、積極的に担おうとする人も減ります。
そのため GlueWork を エンジニアの専門性の一部 として捉え直すことが必要だと感じています。
そもそも企業や顧客がエンジニアに求めているのは、技術そのものではなく「技術を活用して課題を解決する力」です。
その観点に立つと、プロジェクトの機能不全によって開発が進まず、期待した成果を出せないのであれば、どれほど高度な技術力があってもその価値は発揮されません。
技術的知見を効果的に活かすための チーム基盤を整える能力 も、「技術力」の一部として評価するのは一つの手だと思います。
また、GlueWork 自体が技術力を育てるきっかけになり得ます。
例えばオンボーディングでは、新メンバーにシステムのアーキテクチャや開発ルールを説明する必要がありますが、これは自分の理解を深め、考えを整理する機会にもなります。
他人に教えることは最も効果的学習方法とも言われるように、GlueWork の中には 技術力向上と相性が良いもの も存在します。
ただ、エンジニアにとってGlueWorkを開発業務より高い優先順位に置かせるのは色々な意味で現実的ではないと思います。現状の低評価から 相対的に評価を引き上げるだけでも 担い手の不遇感は減り、プロジェクト運営は安定します。
参考
備考
参考記事の中では設計レビューなどもGlueWorkの一部として取り上げられていますが、これが技術的貢献として評価されにくい仕事かというと少し微妙な気がします。具体例に着目するよりは、「プロジェクトの成功に必要だが、評価されにくい仕事」をGlueWorkとして位置付けた上で、各チーム内での"GlueWork"について議論をする方が賢明だと思います。