ナレッジワークのフロントエンドグループについて
ナレッジワークのフロントエンドグループでマネージャーをしております、aoshiと申します。
弊社のエンジニア組織は普段全エンジニア1チームで開発しておりますが、組織的には職種に応じてグループ※が作られております。
その中で「フロントエンドグループ」の取り組みや課題を紹介できればと思っています。
フロントエンドグループは、ただフロントエンドの開発を行うだけでなく、プロダクトとして重要視しているUXの実現を担っています。
ナレッジワークのフロントエンドに興味ある方はもちろん、チームをもっと良くしたいと思っている方にもお役にたてる内容だと思いますので、最後まで読んでいただけたらうれしいです。
※ 他に「バックエンドグループ」「インフラグループ」がある
誰が何を決めるのかを明確に
フロントエンドグループでは「チームリード」「テックリード」という役割を設けて、誰が何に責任をもつか(=何を決めるか)をある程度定めています。
決める人がいないと、衝突や責任逃れ等で決定に時間がかかってしまったり、決定できたとしても中途半端な折衷案になってしまったりと、意思決定のスピードやクォリティが損なわれると考えています。
フロントエンドグループにおける、「チームリード」「テックリード」の考え方はこちらです。
チームリード
目的: 事業を成功させるために、チームの成果を安定的に創出する(ベロシティの安定 → 向上)
開発：追加開発
採用：チーム面接(チームの一員として一緒に働けるかどうかの見極め)
安定的な成果
フロントエンド開発プロセスの策定や運用
メンバーマネジメント
オンボーディング
テックリード
目的: 事業を成功させるために、担当領域における品質の継続的担保
開発: 基盤開発、新機能開発
採用: スキル面接(ナレッジワークが求める水準のスキルを有しているかの見極め)
品質担保
技術課題の見える化
技術戦略の策定と推進
コードレビューオーナー
JIRA運用術と改善活動
フロントエンドグループではグループ専用のJIRAプロジェクトを運用しています。
このJIRAに、開発中に気になったことはどんなことでも起票して良いことにしています。
起票されたJIRAチケットは隔週のグループの定例MTGで以下のことを確認し、定期的に整理を行っています。
内容をグループ共有
着手する時期を仮で決める
着手する時期の決定は、いずれかから選択するようにしています。
今期でやりたい
来期でやりたい
いつやるか決めれないけど、早めにやりたい
一旦寝かせる
こうすることで、起票されたまま放置されてしまうことを防ぎ、改善活動の優先順を緩くつけるようにしています。
今期にある改善チケットは副業メンバーにお願いしたり、PdMと交渉したりして消化していっています。
また、期初にグループのOKRを決めているのですが、その際に「今期でやりたい」の積み残しと「来期でやりたい」の中から優先的に決めるような運用にしています。
フロントエンド会
4半期に1回ぐらいの頻度で、フロントエンドのことについてざっくばらんに雑談する会(通称フロントエンド会)というのを開催しています。
フロントエンドグループにはいまお手伝いしていただいている副業メンバーが数人いらっしゃいます。どの方もとても優秀でとても助かっています。
が、副業メンバーの方々は働く時間がバラバラで、お互い交流がないのが勿体ないかなと感じてました。
そこで、
優秀な方同士でフロントエンドのことについて話せれば楽しいし、お互いの知見を知れれば、勉強にもなるのではないか？
しかも副業の方同士お互いの顔を知るきっかけにもなっていいのではないか？
というアイデアが浮かび、フロントエンド会を開催しました。
成功するかどうかドキドキしながら企画した会ではあったのですが、いい意味で期待を裏切ってくれて、とても充実した会になっています。(言葉だけでは楽しさを表現できないのが歯がゆい。。)
今まで全3回開催しており、話した内容を抜粋することこのような内容をざっくばらんに話しております。
WebAssembly(Wasm)やrustの話
State of JSを眺めて、ざっくばらんに話
Viteやesbuildきてるね！とか
ユーティリティライブラリの話
lodash, remedajs, ramdajsあたりの話
→ remeda導入することになった
Componentの設計の話
componentのディレクトリ構成や、書き方など各々の経験を話す
→ 今後のComponent設計のルール化のヒントに
勉強会や、LT大会だと、だれかが資料を用意しないといけないので、ハードルが少し上がってしまうのですが、トピックだけ設けて、あとは参加者全員でざっくばらんに話すという形にすると、全員が参加できる上、特定の誰かが大変になったりしないので満足度の高いものになったのではないかと思っています。
今後のやりたいこと
社内のイネーブルメントの強化
現在、テックリードが1人の状態で、コードレビューや技術的な意思決定をすべて回している状態です。
テックリード1人体制ですと、レビューの負荷が大きかったり、意思決定のための壁打ち相手がいなかったりと、このままでは大きなボトルネックになってしまいます。特に開発チームが複数になった場合に対応ができない可能性があります(現状は開発チームは1つ)。1つの開発チームに1人のテックリードがいて、そのチームの開発のフロントエンド開発を推進していってもらうのが理想です。
テックリードを増やすためには、採用・イネーブルメント※1とどちらも継続的に取り組んでいかなくてはいけないと考えております。
採用は常に取り組んでいるものの、社内メンバーのイネーブルメントという点ではまだ足りないと感じています。
社内でテックリードまで育てることはもちろん、そういったメンバーが将来別の会社で働くことになったとしても活躍できるようにしたいと思っています。
入社時のイネーブルメントとして、オンボーディングは整備されてきています。
それだけでなく入社から半年後、1年後、3年後もイネーブルメントを感じられるような組織にしたいと思っています。
少し話が逸れますが、いまはまだ「テックリード」「チームリード」という役割のみなのですが、フロントエンドの領域はひろく、デザインに強いフロントエンドエンジニアもいれば、ブラウザやネットワークに強いフロントエンドエンジニアもいます。そういったフロントエンドの様々な興味のある領域を伸ばせる体制や、リーダーシップを発揮できる体制も作っていきたいと思っています。
※ イネーブルメント
能力を向上や成果の創出を指す言葉。(= できるようになる)
ナレッジワークでは「できる喜びが巡る日々を届ける」というmissionのもと、すべての働く人がイネーブルメントを感じられるようなプロダクトを提供していきます。
詳しくはCEO麻野の記事をご覧ください。
さらなる顧客価値を提供するために解決したい技術課題
弊社のフロントエンド開発では、日常的にリファクタリングや再設計、ライブラリのアップデートなど改善に取り組んでいるため、今のところ、改修に数ヶ月を要するような根が深い技術的負債は存在しません。
ですが、顧客価値を向上するために解決したい技術的な課題は存在します。
フロントエンドのパフォーマンス
課題：今のところ体感ではストレスは感じず、ユーザから遅いとの声は頂いてはいないのですが、これを維持するための仕組みが存在しない
解決案：Core Web Vaitalの計測、フロントエンド版SLI/SLOの設置とエラーバジェット運用等
オフラインやPush通知の対応
課題1：更新にリアルタイムに気づくことができない。(コメント機能など)
課題2：ネットワークが不安定な場所で弊プロダクトにアップロードした資料が閲覧できない
解決案：ServiceWorkerの活用
最後に
私はフロントエンドエンジニアとして働くなら「ナレッジワーク」がぱっと頭に浮かぶような、日本を代表するようなフロントエンドグループを作りたいと思っています。
それを考えるとナレッジワークのフロントエンドグループはまだまだ道半ばです。
やりたいこともたくさんありますし、これからきっと様々なハードルを超えつづけないといけないと思います。
そして、私はこれからの道をつくったり、出てきたハードルを超えるのを一人ではなくチームで成し遂げたいと思っています。
今回ブログに書いた内容でも良いですし、書ききれなかったことも多くありますので、もし少しでも興味があればこちらからご応募のほどよろしくおねがいします。
(カジュアル面談もウェルカムです！！)