はじめに
この記事は フラー株式会社 Advent Calendar 2022 の最終日の記事です。24日目は @SaturnR7 さんで 縦書きの日本語をウィジェットで表現したい でした。
テックリードになって半年経った
Android ユニットのテックリードになって半年経ったので、その間にやってきたことを書こうと思います。
テックリードについて
会社によってテックリードがやることは様々だと思いますが、弊社のテックリードが行う業務をまず説明します。
と言っても、明確に業務として行うと明文化されているものについては「Androidメンバーのスキル評価」これぐらいです。
それ以外には Android ユニットで標準的に採用する技術の選定なども行いますが、あくまで基本的な指針（アーキテクチャは MVVM を推奨するなど）を定める程度で、技術選定の裁量は各案件をメインで担当するメンバーに委ねています。
それ以外の業務は明確に「これをやれ」と定められているわけではなく、自然と「自分たちでユニット内や会社の（主に技術的な）課題を見つけて改善していく」というような動きになります。良く言えば裁量の大きい、悪く言えばふんわりとしたポジションです。（テックリードというポジション自体が出来て1年ぐらいなので、わりとまだ手探りな状態です）
なので、業務として行う「スキル評価」の説明プラス、何に力を入れてこの半年やってきたのか、を書いていきます。
スキル評価とは
2022年12月時点でのフラーの評価制度には「パフォーマンス評価」と「スキル評価」の2軸があり、この2軸を総合的に判断して昇給や賞与額が決定されます。
「パフォーマンス評価」というのは、雑に言えばプロジェクトや会社に対してどれぐらいバリューを発揮できたか？という評価で、各職種のユニット長が行います。例えば「プロジェクトの一メンバーとしてタスクをこなした人」と「プロジェクト全体をリードした人」であれば後者の方が評価が高くなるという感じです。
「スキル評価」は、エンジニアとしてのスキルがどれぐらい高いか？という面を評価するもので、このスキル面をテックリードが評価します。こちらは例えば「あらかじめ決められた設計に従ってコードを書ける」人と「自分で一からアーキテクチャを設計できる」人であれば後者の人の方がスキル評価が高くなるという感じです。
と言っても（怒られるかもしれませんが）「スキル評価とか何とか言っても最終的には結局お給料が上がるかどうかでしょ？」というひねくれた視点で評価制度を見ている部分があるので、「どうすれば皆の評価を上げられるか」という視点から逆算して目標を立てることが多いです。
もちろん本人の伸ばしたいスキルは尊重しますが、それを「いかに会社（最終評価者）が評価しやすい形で目標・実績として言語化するか」という部分が評価する自分のお仕事かなという気がしています。成長する人は何してても成長するし
その他やったこと
今期力を入れた事は、「ドキュメンテーション」と「技術の標準化」です。（と言っても、どちらもまだ道半ばですが…）
背景
弊社はいわゆる受託開発をメインにしている企業です。そのため複数の案件が常に並行して動いており、現在進行形で Android の開発業務が発生するプロジェクトだけ数えても10件近くはあります。（もちろん全ての案件がバリバリ新規開発として走っているわけではなく、保守運用フェーズなどでそこまで大きなタスクが発生しない案件もあります）
これだけプロジェクトの数が多くなってくると、採用している技術やアーキテクチャもかなりバラつきが出てきます。開発開始時期が古く、Android の標準的な MVVM 構成になっていないプロジェクトもありますし、かと思えば新しいプロジェクトはフル Jetpack Compose で作られていたりします。
捉えようによってはその時その時のトレンド技術を貪欲に取り入れていっていると言えなくもないのですが、やはり案件を跨いだ際のコンテキストスイッチなども大変ですし、今後も各プロジェクトを思い思いに管理していったら本当にカオスになる事は目に見えているので、せめて今後のプロジェクトだけでも（※）ある程度メンバー間で共通認識を持って開発を進めていきたいよね、という思いを持ったのが上記2点を推進した背景です。
※理想は古いプロジェクトもどんどんリファクタなどを進めていける事なのですが、お客様からお金を頂戴して作業するのが受託開発の基本なので、歴史あるプロジェクトは各メンバーが手が空いた隙に本当に少しずつリファクタなどを進めているのが実情です。でもそんな制約がある中でもみんな頑張ってます。みんなえらい
【やったこと1】ドキュメンテーション
Android ユニットのメンバーが少しずつ増えてきたこともあり、今まで各メンバーが案件ごとによしなにやっていた部分に関しても明文化した方がいいな、という雰囲気が生まれてきました。そういった誰かの「暗黙知」のようになっている部分をドキュメントとしてしっかりまとめて、運用方法が分からなくなった時などにその情報にアクセスできるようにする、というのが力を入れたこと1つ目です。
直近でまとめたのは、「ライブラリの更新ってどういうタイミングでやればいい？」とかです。小さいことではありますが、開発プロジェクトが複数走る弊社のようなスタイルだと、こういう部分も言語化した方が後々助かるかと思ってまとめました。
一つ大きなものとしては、「プロジェクトの初期環境構築時に Android エンジニアがやるべきこと」というドキュメントをまとめています。
自社サービスの会社と違い、1年に2〜3件程度は新規開発プロジェクトが発足するので、「Android Studio で New Project する」〜「 build.gradle 周りを整備する」〜「CIやプロジェクトに必要なライブラリなどを入れる」などのいわゆる「環境構築作業」をする機会がまあまああります。それこそ入社1年目の社員に、経験としてこれらの環境構築を担当してもらうこともあります。
そういう時に「はい、やっといて」ではあまりにも不親切ですし（※）、作業の指針になるものが無いと、慣れている人でも絶対に抜け漏れが発生するので、初期環境構築のやり方としてドキュメントにまとめることにしました。これは後述する「技術の標準化」とも関わってきます。
※ちなみに今までは過去プロジェクトのPRを覗きながらやってました。プロジェクトもメンバーも多くなかったからこれでも回っていたんですね
【やったこと2】技術の標準化
「ある程度メンバー間で共通認識を持って開発を進めていきたい」という部分に対するアクションの1つとして、「なるべく採用する技術を各案件で揃えよう」という取り組みを行っています。これは元 Android テックリードであった @okuzawats さんが「標準設計の策定」や「ライブラリ選定基準の制定」などで進めてくださっていましたが、もう一歩進めて、 テンプレートリポジトリ を運用できないか？と考えて少しずつ準備を進めています。
これは Android プロジェクトを新規作成する際に、テンプレートリポジトリから作成すれば、基本的な CI/CD の構築や、Version Catalog の導入、主要なライブラリ（99%の案件で使う Retrofit や Dagger Hilt など）の導入などが予め完了している状態のプロジェクトが出来上がる、というものを目指しています。
これで何が嬉しいかというと、例えば今までだと、「案件AではPRをオープンした時に ktlint と Android Lint が動くようにCIが設定されているが、案件Bでは ktlint しか動いていない」というような事があったのですが、今後の案件ではそのようなバラつきが可能な限り抑えられる、という効果を期待しています。
そして、どうしてもボイラープレート的な部分が多くなってしまうこれらの作業時間を短縮し、浮いた工数を更なる改善に充てていきたいという意図があります。
「プロジェクトの初期環境構築時に〜」と内容が被ってないか？というご意見もあるかと思いますが、テンプレートリポジトリに含まれる内容の実装手順がドキュメント化されたものが「プロジェクトの初期環境構築時に〜」なイメージです。これらを同時に進めることで、仮に今まで環境構築の経験が全く無いような Android エンジニアがアサインされたとしても、「このプロジェクトにはどういう設定がされているのか」がドキュメントから追えるようにしたいという気持ちがあるので、両方を同時に進めています。
これらの施策がうまくいくかどうかは、実際に運用に乗せてみないと分かりませんが、「ひとまずやってみて、ダメだったらまた別の改善策を考えよう」というノリで進めています。
以上が、テックリードになって半年でやったことです。
おまけ
あともう一つ頑張ったことを忘れていまして、それは「Androidユニットの雰囲気を良くしよう！」です。どうせ働くなら楽しい方がいいに決まっているので（個人の感想）、ユニットのメンバーが困っていそうだったらすぐに飛んで行ったり、Slack や Zoom などで積極的にふざけるコミュニケーションをとるようにしました。
もともと会社の中でも雰囲気のよいほうのユニットだったとは思うのですが、ここ半年で「Androidユニットの雰囲気、いいね」と社内のいろいろな人たちが言ってくださるようになり、非常に嬉しい限りです。
もちろんこれはわたしだけの力ではなく、色々なコミュニケーション施策を考えて実施してくれた Android ユニット長や、その施策に積極的に関わってくれたメンバーのみんなのおかげだと思っています。ありがとうございました。これからもよろしくお願いします。
おわりに
これで今年の フラー株式会社 Advent Calendar はおしまいです。毎年最終日は @okuzawats さんがトリを務めていましたが、今年は最終日を奪ってやりました。下克上です（？）。来年も最終日を狙っていきたいと思います。