実装ではなく、Pull Requestレビューから経験値を得るようになった話

パワーワード：経験値泥棒

君は分かるだろうか。

「経験値泥棒」という単語に衝撃を受けたオッサンの気持ちが。

 

2024年時点で、私は34歳です。約10年、エンジニアとして働いてきました。

まだまだ至らない所があると思いつつ、他の人からシニアエンジニアと言われる機会も増え、仕事の範囲にマネージメントや教育が入り込むのが当たり前になりました。

 

人前では、「一生エンジニアリング（設計、実装）の領域だけで食っていくが？」と公言しています。しかし、イケてるアプリを作るには、ソフトスキルが重要だと気づいています。つまり、ドメインに対する理解度を上げたり、メンバと共通認識を確立したり、チームメンバが気持ちよく働けるように配慮する重要性を理解しています。とはいえ、行動としては、設計や実装をしている時に分泌されるドーパミンに抗えないことが多かったです。

 

そんな私は、2024年6月に出版された“ソフトウェア開発現場の「失敗」集めてみた”に衝撃を受け、行動を改めることにしました。本書には、”つい自分でやってしまう　「経験値泥棒」”というエピソードがあります。「自分の行いが失敗扱いになってるぞ!?!」とショックを受けました。

設計力は経験からしか得られないのに、経験値泥棒がその機会を全て奪ってしまうと、若手は永遠に成長できません。会社の視点（長期的な目線）で見れば、経験値泥棒は好ましくない存在です。

当たり前の事実ですが、本書の「失敗」というフレーズは、私の心を動揺させました。

　　

お前の考える経験値って何よ?

経験値の定義は、「イケてるアプリを作るためのスキル（ハードスキル／ソフトスキル）」を獲得するためのキッカケとします。別の言い方は、「成長したな〜、自分」と思うために必要な事柄です。正直に言えば、本記事は息子の昼寝中に書き殴っているので、定義は雰囲気でお願いします。

　　　

新方針：可能な限り実装／設計をメンバに譲る

前述の書籍を読む前の私は、実装／設計タスクが残っていたら、巻き取っていました。自分が作業すれば進捗を出せ、脳内にある設計を共有する手間も減り、私が楽しいからです。作業遅延が発生した時も、嬉々として巻き取っていました。

 

しかし、今では若手中心に実装／設計のタスクをお願いする方針に変えました。アプリ／インフラを問わず、可能な限りメンバにお任せします。会社からも「作業遅延を巻き取るのはベターな解決策で、ベストな解決策（本来の期待値）は他メンバに実装させつつオンスケでタスクを終わらすことだ（意訳）」と言われたので、良いタイミングで方針変更できたと考えてます。

 

さらに言えば、設計／実装スキルはOSS開発を通して成長させられます。会社で経験値を稼ぐことに、躍起にならなくてよいです（私はドラクエで雑魚敵を必ず倒す性格なので、最初は「そのタスク、自分でやりたいな～」と不満が少しありました。今はあまりないです）

　　

経験値はPull Requestレビューから稼ぐ 

Pull Request（PR）は、設計力および実装力が如実に表れる場所です。

PRレビューを通して、視座を高め（ドメインの理解度を上げ）、視野を広げる（確認観点を増やす）ようなレビューをしようと考え始めました。ここ半年の気持ちとしては、PRが私の主戦場でした。

幸い、方針変更した時期に5案件のレビュー担当を受け持ち、1日あたり20件近くレビューしていたので、レビュースタイルを変えるための練習量としては十分でした。ただし、案件を反復横跳びしてコンテキストスイッチが辛かったので、「5案件は無理」と泣きつきました。

　

レビュースタイルの変化ですが、「要求や要件に対して設計意図が適切かどうか」を判断することを放棄しないようにしました。半年前までは自分が考えた設計を実装して貰うことが多く、設計のどの部分に魂がこもっているかが明確でした。今はメンバが設計しているので、設計意図を正確に把握するには対話が必要です（対話しなくても設計意図が分かる状態がベストですが、現職はまだその段階ではありません）。

今では、メンバに設計意図を尋ねる回数が増えました。「顧客が本当に必要だったもの」に対して、共通認識を持とうと試みています。実装の細かい部分は一先ず置いておき、意識的にメンバへ問いかけています。

 

このスタイルに変わってから、「PRのタイミングで、メンバが要求や要件、設計意図を正確に理解しているか（自分とメンバの間で共通認識があるか）を確認するのは遅い」という気持ちが強まりました。その理由は、手戻りリスクが高いからです。私が要求や要件、設計意図に関して質問すると、「分からない」や「参考にした実装に合わせた」という回答が返ってくることがあります。その状態で実装したコードが手戻らないとは考えにくいです。

　　　

次にやりたいこと

主戦場がPRになってから、要求に基づいてチームで開発することの難しさを再認識しました。正確には課題が二つあり、「①要求と開発した機能との間にトレーサビリティがない」「②チームが設計意図に関する共通認識を持てていない」が伸びしろポイントです。

 

エンジニア視点では、②に対する課題意識が強いです。

再現性のある開発プロセスの構築、ドキュメンテーションの強化などを推進することが、シニアエンジニアとしての役割なのだと2024年後半はぼんやりと考えていました。今まではリリースまでに顧客が納得するものが作れていますが（どこかのタイミングで軌道修正できていますが）、これからも同じ手法で上手くいくとは限りません。プロジェクト成功の再現性を高めるのが、私の仕事です。多分。

 

再現性のある開発プロセスを構築したい理由は、「何となく開発が上手くいく」からの脱却も視野に入れています。上流の工程からシステマチックに開発できるようになれば、新しい案件に取り組んでも成功確率が上がります。設計意図を共有するという観点では、振る舞い駆動開発（Behavior Driven Development）やワークショップ、ペアプロのように、同期を取りながら開発するスタイルを検証したいと考えています。

 

ドキュメンテーションに関しては、第一歩として、DBドキュメントの拡充に取り組みました。tblsによって生成したER図に対してviewpointsで設計意図（ドキュメント）を付与し、GitHub ActionsでHTML化して、ブラウザで閲覧できるような仕組みを導入しました。DBテーブル追加時にviewpointsを追加していないと、PRマージできないようにしてあります。このように、実装とドキュメントが乖離しないような仕組みをドンドン作り上げていき、ドキュメントに強いチームを構築したいです。

 

最後に

ここからは、取り留めのない話です。

　　

ドキュメンテーションに関して調べている時に、「文章を書くのが苦手な人は、文章を書くタスクを避ける」という話を目にして、目から鱗が落ちました。私は文章を書くのが苦ではないので、この発想がありませんでした。作文に苦手意識がある人から、苦手意識を取り除くことも仕事になりそうだなと感じた次第です。

　　

開発プロセスの変更は、合意形成の取り方で頭を悩ませています。「俺が良いと思っているから、色々と試すんだ」は、ハレーションが起きます。数年前、開発プロセスの正常化を試みて、アジャイル開発の導入を提案した時に一悶着ありました。上手な根回しが求められます。どうしましょうかね。