Advent Calendar 2023

フロントエンド特化の​生存戦略と​しての​イネイブリングチーム考

この記事はyamanoku Advent Calendar 2023の14日目の記事になります。

今回書かれていることは私の中でもまだ理解が浅い状態で書き記している話のため、書いている内容自体が間違っている可能性がある。その点留意して読んでいただけると幸いである。

フロントエンドが担うことは多い？

フロントエンドの進化は速くそれに追従していくのが大変だ、という話をよく耳にする。その事自体が明らかであることの確たる証拠はないのだが、現代のWeb開発においてはフロントエンドの開発環境構築やビルドフローの整備、フレームワークの選定・導入、テスト設計やVRTの整備などの基盤を支えるための知識が必要であったり、HTML/CSS/JavaScriptの知識やWebブラウザの挙動やAPIについての理解について、そしてバックエンドとの接続についても必要だったりと、フロントエンドにまつわる知識は多岐に渡ってくる。

そうした領域の広さを請け負いつつ、何らかのドメインについての知識や開発、機能のデリバリーのことも考えていくとなると過度に認知負荷が高くなってしまう。その領域や責務をフロントエンド専任のチームをつくり、移譲していく形になっていくのがよくある形なのかと思う。そこで必要となる役割が「フロントエンドエンジニア」になると思われる。

具体的な役割への分化

フロントエンド専任も1つのチームの形ではあるが、その場合はバックエンドとフロントエンドとで分かれることによりチーム間の情報の透明性が低くなったりコミュニケーションコストが高まっていく可能性がある。また、チーム内も人が増えてくることで力関係ややっていくことも変化していく。そうした中でチーム機能がうまく働いていないとそもそもの機能提供や価値創造が遅れることに繋がりかねない。そうしたことを避けるためにも全体的に自律的なチームを作っていくことが求められ、フロントエンド専任を置き続けることは事業価値の提供においてはボトルネックになるかもしれない。

そうした単なる「フロントエンドエンジニア」としての役割から派生して今は別の役割も生まれてきている。デザイナーとの架け橋としてのデザインエンジニアのような役割、フロントエンドのツールやビルド環境を整えるOpsエンジニアのような役割、バックエンドの知識も取り入れたフルスタックエンジニアとしての役割などがある。これらが上位互換ということではないが、いずれも自身の役割をより事業に活かせるものとして発展させてきている印象がある。

こうした様々な道がある中で、私自身はWebやフロントエンドにまつわる領域のドメインに特化していき、それをチームや組織、そして事業全体の中で活かせるように振る舞っていきたいように思ってきた。

何故そのようなことをしたいかについては、私が特定の領域に尖りすぎているためであるという至極単純な理由だ。もっともらしい理由をつけるとするならブラウザの今後を憂いているので事業者サイドから相互運用性や品質を守っていきたいし、Webでの良い体験を産み出し続けてそれを事業価値にしたいし、我々から仕様提案をしていくことなどもやっていきたい。

しかし、そうした先鋭的な振る舞いができそうな役割とは具体的にどういうものかを考えてみたが、今ひとつピンと来ず、どういったものなのかは浮かばなかった。

そんな中で「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」という本を知り、その中で紹介されたチームの中でそうした役割が活かせるのではないかと最近考えている。

イネイブリングチームの中での役割

コンウェイの法則やDevOpsの観点から効率的なデリバリーができるようチームに明確な責任と境界をもたせるように考えるチームトポロジーという方法がある。その中で「イネイブリングチーム」というチームの形がある。

イネイブリングチームは、他のチームが障害を克服し、新しいスキルを習得し、プロセスを改善し自律的で進められるような支援を目的としている。実際のチームはどういったことをするのか、あるいはどう振る舞うのかは以下になる（一例）。

このチームにおける役割を考えてみると、先言った私が考える役割がちょうど良い形でハマってくれそうな気がしている。実際に組織内で決まったイネイブリングチームとしての存在なのかは定かではないが、サイボウズ株式会社のフロントエンドエキスパートのような存在なのかと思っている。

もちろんフロントエンドのエキスパートだけの構成でなくても良い。Classi株式会社も現在はチームトポロジーを参考に組織編成をしており2、その中でフロントエンドエキスパートの役割をもつ人が各チームへサポートしているといった話を聞いたことがある3。

フロントエンドへの認知負荷を減らす

チームトポロジーを読んでいて私の中でピンと来たキーワードは「認知負荷」であった。私自身もWeb制作出身でフロントエンドだけしかできないところから現在の事業会社に転職し、様々な知識やコンテキストが必要となってきて非常に疲弊した覚えがある4。そうした経験が強く残り、全体の認知負荷を減らすことについて興味をもっていたりする。

今はコロナ禍を経てフルリモート、あるいはハイブリットな出社をするなど働き方の形も多様になってきた。かつては出社して隣で作業をして情報共有や知識継承ができていた場も、やり方を考えないと途絶えてしまうことは往々にして起きてしまう。それをチームの形から解決していくことができれば、持続的に全体の生産性を上げることがつながるのではないかと思っている。

こうしたフロントエンドへの知識継承の入口から、フロントエンド開発ないしWebそのものについてのドメイン知識を保有したスペシャリストの道も広がっていければいいなとは妄想しつつ、まず今は私の役割が組織内でフィットするやり方についてを模索していければいいなと思っている次第である。

参考情報

脚注

  1. 「象牙の塔(ぞうげのとう)」の意味や使い方 わかりやすく解説 Weblio辞書 ↩

  2. チームトポロジーを参考に新組織の編成を考えた話 - Classi開発者ブログ ↩

  3. vol.14 - 【ゲスト：lacolaco】ソフトウェアエンジニアよ、哲学を学ぼう by お元気ですか.fm ↩

  4. なぜそうなったかの要因は色々とあるのだがここでは割愛する ↩

この記事に関する修正依頼
トップへ戻る