はじめに
遅れてしまいましたが、この記事は Money Forward Fukuoka Advent Calendar 2023 の 23日目の記事です。
私はマネーフォワードのテックリードとして「全体の生産性向上させること」を今年の目標としていました。 しかしこれは特定のプロジェクト責任者と違って、何に責任を負っているのかわかりにくいです。 日々の活動も想像しにくいものになっています。 社内でも「この人は何をしている人なんだろう？」と思われがちです。
そこで、何をしている人かわかってもらうために、ここ一年の仕事をまとめてみました。
コードを書いた
基本的にどこかのチームで何かのプロジェクトを掛け持ちしており、ずっとコードを書いていました。 おそらく業務の50%くらいはただのプログラマとして働いていたのではないかと思います。 「ただのプログラマ」ではありますが、良いコードを素早く書く努力はしていたつもりです。
クエスト制度を始めた
開発ロードマップには載せられないものの、内部改善をしていくことは重要です。 そういった内部改善にちょっとした面白さを加えて、クエストという制度を始めてみました。 クエストは GitHub issue で管理する依頼です。そこには why/what/how/達成条件 を書き込みます。 クエストの例は、下記です。
タイトル: 📜 Ruby3の型を使ってみよう！
why: 補完、テスト、可読性などの面で、型があると便利な場面があるため
what: Ruby3 の型導入と運用方法を提案してください
how:
- Ruby3 の型について調査する
- 試験的にプロダクトに導入する
- メリットとデメリット整理して、運用方法を考えレポートする
達成条件:
- B: Ruby3の型に関する情報をまとめていること
- A: 型を導入できていること
- S: 上記に加えて、運用方法を提案していること
クエストは下記の体制で運用しています。
- 誰でもクエストを作成して良いが、運営レビューは必須とする
- クエストに assignee をセットすることで、着手しているものとする（報告不要）
- 完了した時は運営に報告する
今年は170個のクエストが作られ、うち70個が達成されました。
いくつかのクエストは、ビジネスで実現したい事柄とつながっていて、業務時間が使えるケースもありました。 クエストの価値の高さ、作業の重さがわかっていれば、もっと本気で取り組みたいという声もちらほらと上がっています。 まだ改善する余地はありそうです。メインの業務とは切り離されている点が、難しさではあります。
コーディングルールの会を続けた
2022年の6月から、コーディングルールの会というイベントを開いています。 この会は「みんなもっと一貫性のある良いコードを書いてくれ！」という私のエゴから始まりました。 ただそれだけの話です。けれど、大人数でそれだけの話を実現するのは非常に難しいのです。 誰しも自分なりの「良いコード」を持っています。 その価値観を擦り合わせるために、このイベントを作りました。
初めは、本当に手探りでした。私の提案をぶつけてその是非を問うような形式を何度か試しました。 ブレインストーミングのような形式で開催したこともあります。 最終的には、運営でテーマを定め、グループで議論する方式で落ち着きました。
たとえば「サービスクラスに対する共通理解を作ろう」は興味深いテーマだったと思います。 ここで言うサービスクラスとは 「サービスクラス」は 3 種類ある で語られているものです。 こういった曖昧な概念をコードだけで語ることは困難です。 そして、短時間の議論で完璧に理解することも不可能です。 でも、少なくともその入り口に立つきっかけにはなっているのではないかと思います。
このイベントはチームメンバーから好意的に受け止められ、今も継続しています。 ただ、今では参加者が多くなり、全ての参加者を満足させるようなイベントにすることが難しくなっています。 もはや私一人の持ち物ではなくなっているので、どういう方向性に持っていくのかは今も悩みの種です。 議論したことに満足してしまい、次のアクションに繋げにくいというのも弱点だと思っています。
リアーキテクチャに取り組んだ
マネーフォワードでリアーキテクチャといえば、共通DBからの分離を行う「桃園の誓い」の話が代表的です。 これ自体かなり興味深いトピックですが私の担当はもう少し別な話です。 （桃園の話に興味のある方は 技術的負債解消チームで1年半活動して分かった、動くコードを削除する大変さ をお読みください）
私が毎日コードを書いているプロダクトのコードベースはかなり複雑化しています。 特にコア機能については改修難易度が非常に高くなってしまっていて、皆よく苦戦しています。 それには、私のこれまでの仕事も一因となっているのでなんとかしたいと考えました。
フロントエンドに関して
私たちのプロジェクトにおけるフロントエンドのコードは、 新しい技術を追加導入することはあったのですが、古い技術を廃止することがうまくできていませんでした。 jQuery だったり、React だったり、異なるパラダイムの技術が存在していました。 技術的には React でも、異なるアーキテクチャを持っているコードも混在しています。 私はこれらを明確に線引きし「第一世代」「第二世代」「第三世代」と名前づけしました。 これによって、コミュニケーションが明確になりました。たとえば下記のような会話ができるようになりました。
- 「そこのコードは第一世代だからディレクトリはここです」
- 「その機能は第二世代で実装してください」
さらに、古い世代をどう取り扱っていくか議論し、ある程度方向性を定めることができました。 このように、細部を言語化し、チームに浸透させていく活動は今後もやっていきたいと思います。
サーバーサイドに関して
まず「ソフトウェアアーキテクチャの基礎」を読みました。 そうして得た知識を使って、巨大なコードベースを論理的に分割できないかと考えました。 たとえば「ログイン機能」「管理機能」「基本機能」といったような機能単位での分割を考えていました。 しかし、コードベースがあまりにも巨大で、どうしても全体像がイメージできませんでした。 そこで、思い切って、実際に手を動かしてみることにしました。 私たちが扱っているプロジェクトは Ruby on Rails で書かれているため、下記の記事が非常に参考になりました。
オートロード機能の置き換えにかなりの時間を使いましたが、この一年でどうにか最初の一個のパッケージ分割を実現できました。
実際に手を動かしてパッケージ分割することで、技術的課題がはっきりわかりました。 また、どのような利点があるのかもわかってきました。 この分割を続けていくことでどういった姿を目指しているのかも明確になってきたと思います。 次は、ここで得た知見をチームに共有し、パッケージ分割を本格化させることが課題だと考えています。
スキルマップを作成した
メンバーが今持っている能力を分析し、成長の方向性を定めるために、スキルマップを作りました。 下記の手順を踏みました。
- スキルにはどのような種類があるかを見つけるブレインストーミング
- グループに分かれてスキルの分類と系統樹を作成する
- テックリード二人でレーダーチャート風のスキルマップのサンプルを作成
- 各自、自己申告でスキルマップを作成
- 現在のスキルを踏まえて、伸ばしていきたいスキルを決定
しかし、スキルというものは二次元的に表現できるものではなく、かつ人によって多種多様なものでした。 関心のあるメンバーがどんどん集まり大所帯となってしまったため発散しやすく、ハンドリングが難しかったです。 なんとか形にして着地させたものの、自信を持って「今後もそれを使っていける」クオリティまでは到達できませんでした。 それでも、自分が今持っているスキルを分析することは重要だと思うので、 まずは自己分析するところから考え直してみたいと思います。
軽量 ADR を書き始めた
調査したことや説得のため整理したことが埋もれてしまい、もったいないと感じたので、軽量 ADR を書き始めました。
まだ個人利用に止まっているので、全体で合意を取るといった状態管理はできていません。 ときどきテーマを見つけては「このテーマで書いてみませんか」とお誘いしているのですが、実らずです。
その他
- ときどきslackで困っていそうな人を見かけたらアシストをしていました
- ときどき設計の相談を受けていました
- パフォーマンスチューニングに関して呼び出されて対応することもありました
- 障害が起きた時にもよく呼ばれていました
- 採用面では、技術課題の評価や面接などやってました
- 人事面では、1on1や半期評価をやってました
- 英語化が進んでいるため毎日30分以上の英語学習をしていました
- ドキュメントの整備をやろうとしていたのですが、あまりうまくいきませんでした
- 生産性指標の分析について考えていますが、着地点を見つけられていないため勉強中です
最後に
こうして書き並べてみると、本当にいろんなことをしていたのだなぁと感慨深くなりました。 ただ、いろんなことをしているだけではダメで、成果を出さなければいけません。 全体の生産性を向上させるという目標は、私一人の努力では実現できず、かなり苦しみました。
今年の私は、取捨選択が甘かったと思います。 どこにボトルネックがあるのかを見つけきれないまま、手当たり次第に色々な課題にタックルしていました。 協力してくれたメンバーのおかげで、手酷い失敗は避けられましたが、疑問符の残る部分もあります。 理想をいえば、課題の重さや、効果の分析が必要だったのだと思います。 来年はもう少し広い視点から組織を見つめていきたいと思います。
Discussion