Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

こんにちわ、5年前にお世話になっていた開発者のものです

こんにちは マネーフォワードでVPoEをしています、渋谷(@ryoff) です。

この記事はマネーフォワードアドベントカレンダー2021🎄の1日目の記事です。

私は戻ってきた

アドベントカレンダーなにか書こうかな、って悩んでたんですが、実は最近、VPoE業をしつつも、とあるプロダクトのチームリーダーも兼務し始めたので、その話を書こうと思います。

実はこのプロダクト、自分が2014年にマネーフォワードに入社後に立ち上げを経験したプロダクトでして、2016-2017年ぐらいに次期リーダーに託して自分は別の業務に移っていきました。

エンジニアのキャリアにおいて、1つのプロダクトに関わり続ける事はむしろ珍しく、数年で別の業務、もしくは、別の会社へと移っていくことも多いのではないかと思います。 過去自分が関わったプロダクトに戻ってくる、という経験は珍しいので、 過去自分が関わったコード・設計・チームは、自分が抜けた後の数年でどう変わっていったのか という体験レポートをお届けしようと思います。

当時のプロダクト

添付の画像はこのプロダクトの first commit message です。 ※ ちなみにこのコミットをした開発者は、自分の後任の次期リーダーになってくれました。

月面着陸時のアームストロング船長の「That's one small step for [a] man, one giant leap for mankind.」をもじったものですが、こういうエモい感じいいですよね。お気に入りです。

さて、当時の状況ですが、開発者は3名。リリースまでの開発期間は4ヶ月。 会社全体でも開発者は20名前後。

チームで話し合った設計思想は

  • 書きやすさより、読みやすさ
  • 冗長でも、迷わない記述
  • 早すぎる共通化をしない
  • 個人の最適解よりチームの最適解
  • コメントを書き過ぎということはない

と言ったものでした。

当時はそれなりに時間をかけて議論をし、メンテナンス性を意識したつもりになっていましたが、今現在改めて振り返ってみると、間違った意思決定・設計や、当時最強と思った仕組みが負債化している場面もあり、いざチームに戻ってくると申し訳ない気持ちになることばかりです。

あなたの書いたコードは、あなたが抜けた数年後にどうなっているのか

さて、本題です。 当時のコード・設計と、自分が抜けた数年後のコード・設計を両方見た経験から、気づきを書いていこうと思います。

コアの設計・思想は維持されていた

良くも悪くも、コアの設計はあまり変化していませんでした。

もちろん、並列化・高速化・リファクタリング・機能改善など、多くの進化がおこなれていたのですが、全体的なクラス設計やコード思想などは変化が少なかったです。

これは当時のチームが「個人の最適解よりチームの最適解(※ 俺が考える最強のコードを書くのではなく、チーム全員にとって理解しやすいコードを書く)」を意識していたからかもしれません。

新しくチームに加わるメンバーは、既存プロダクトコードを読んだ上で、その設計思想に合わせたコードを書くことが多いので、既存メンバーのコードレビュー等を通じて、コアの設計・思想は維持されていたようです。

これは逆に言うと、既存設計に大きな変化を生み出したい場合には、一部コードだけの最適解や一部メンバーだけの行動ではなく、全体的にリプレイスをやりきる必要性や、チームメンバー全員の意識を統一するところまでやりきらないと、なかなか成功しないんだろうなという気付きにもなりました。

コードの説明より、背景の説明

比較的コメントを多く書いていたのですが、今あらためて見直すと、意味のないコメントになっているな、というものは多かったです。

コードは呼び出し元がなくなれば比較的迷わず消されますが、コメントは「なくてもいいけど、あってもいい」というレベルのコメントは残り続けていました。

あまり意味がないと思うコメントだけど、わざわざ消す理由もない場合、書き換える・消す、というモチベーションは生まれにくいのだと思います。

また、逆にあってよかったなと思うコメントは「コードを書いていた当時の思考メモ」や「その設計に至った背景」などでした。

例えば、

  • NOTE: 本当はXXという設計にしたいが、yyライブラリの制約上この記述が必要
  • NOTE: このmoduleは、xxとyyの目的のために作成した。よって、その目的のみに使用し、たとえ用途が似ていても、それ以外の機能ではincludeしない想定
  • NOTE: xxライブラリの1.2.3にはyyというバグがありversion upできないのでversion制約をつける。修正PRが出ているので、取り込まれて最新に更新されたのち、version制約を外す。

などです。 説明がどうしても長くなってしまう場合には、slackやドキュメントツールのURLの記載なども、非常に有益だなと感じました。

TODO(コメント/issue)では3W1Hを意識すると良さそう

過去自分が書いたコメントを数年ぶりに見た時に、5W1Hのうち、When(いつ)、What(なにを)、Why(なぜ)、How(どのように)の3W1Hが意識できていれば良かったな、と感じました。

  • TODO: ここの設計イケてないから直したい
  • TODO: 現状の設計では今後の機能開発の対応が難しいのでリファクタを検討

こんなコメントよくありました。誰でしょうねこれ書いたの(僕です)。

当時は、自分のコードの課題を少しでも後世に伝えようという思いで書いたコメントだと思いますが、残念ながら数年後に戻ってきてもそのまま残ってるコメントが多かったです。

理由は、後任の開発者が何をしたらいいのかわからないのと、どうなったらこのコメントを消せるのか判断がつかないからじゃないかと考えています。

もしいま書くなら、

# TODO:
#  (what)このmoduleは、(why)include元であるxxクラスとの依存関係があり、再利用性もテストの書き方にも課題感がある。
#  (when)次このmoduleに機能拡張する場合は、(how)yyメソッドのロジックはPOROに切り出す

こんな感じに書くかもしれません。

当時の背景や考えを引き継いでいく難しさ

チームとプロダクトは変化を恐れず、状況に合わせて変わっていくべきだと思っています。

そして、当時と今の状況にはどんな差分があるのかを正しく把握する事は、変化の成功率を上げる上で非常に有益です。

コアの設計思想やクラス構成など、コードに反映されているものは、(良い部分も悪い部分も)比較的自然と引き継がれるます。また、コメント・Issue・ドキュメントなど、文字として残るものも、工夫次第で多くの情報を時を超えて伝えることができます。

一方で、全てを設計と文字で残すのは難しいです。 コードに複数の設計思想が混ざった状態の場合には、どちらが今後推奨したい設計なのかわからなくなりがちですし、ドキュメントは増えれば増えるほど、メンテナンスの難しさの課題に直面します。

そんな中、自分が今回経験したプロダクトの開発チームでは、自分が抜けた後、コードでもドキュメントでもなく、「チーム自体に知見が溜まる状態」をうまく作る仕組みができているな、と感じる部分があったので、最後にそれを紹介して終わろうと思います。

チームに知見を溜める

プロダクトのコードを読む会

文字通りチームメンバー全員で、定期的にプロダクトコードを読む会です。

普段の開発ではあまり変化が起きにくい基盤ロジックを読んでみたり、リリース当初のcommit番号まで遡ってリリース当時のコードを読んでみたり。

新しいメンバーが入ってきた場合には、そのメンバーが主になってコードを読みながら情報共有をしたりと、チーム全員のコード・設計に対する共通認識を作るいい取り組みだな、と感じました。

言語・FWのversion upモブプロ

開発言語・ライブラリ等のversion up業務を、誰か一人のタスクとせず、毎週時間を決めて、みんなでモブプロをしながら実施していました。

犬を愛でる会

datadogをチームメンバー全員で見ながら、パフォーマンス・エラー傾向・負荷状況などを議論する会です。 こちらも、誰か一人のタスクではなく、メンバー全員で一緒に同じ情報を見ます。

多くの会がメンバーの持ち回りになっていた

上記に上げたような定期的な取り組みが、リーダーによる推進ではなく、チームメンバーの持ち回りで運用が回るようになっていました。

これら定期的な取り組みは、チーム内の共通認識を自然と作り上げることに貢献しているな、と感じましたし、自分が抜けた後のプロダクト開発を、このように良い仕組みを作ってくれていた開発チームには、尊敬と感謝の気持ちでいっぱいです。

まとめ

最近はますますプロダクト開発の難しさを感じています。 市場環境は刻一刻と変化しますし、技術進化に合わせてプロダクトもチームも変化し続けなくてはいけません。

だからこそ「変化するための知見共有」の重要性も感じますし、変化を楽しんで開発したいなと思います。

一緒に変化を楽しんでくれる方いましたら、是非カジュアル面談しましょう。 twitter DMでも、下記募集から応募いただいても大丈夫です。

【サーバサイドエンジニア】_東京(田町) | 株式会社マネーフォワード 【フロントエンジニア】_東京(田町) | 株式会社マネーフォワード

最後までお読みいただきありがとうございました。


マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。

【サイトのご案内】 ■マネーフォワード採用サイトWantedly京都開発拠点

【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android

ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』

おつり貯金アプリ 『しらたま』

お金の悩みを無料で相談 『マネーフォワード お金の相談』

だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』

金融商品の比較・申し込みサイト 『Money Forward Mall』

くらしの経済メディア 『MONEY PLUS』