はじめに
この記事について
この記事は私（なりあい）がマネーフォワードで実務インターンを経験して培った「実務開発の型」を共有する記事になります。実際の実務でどのような流れで開発を行ってきたかを書いているので、これからインターン生として入社する方々、入社して間もない方々、インターンに応募するか迷っている方々の手助けになればいいなと思っています。
自己紹介
初めまして！マネーフォワード福岡開発拠点で2024年8月〜2026年2月まで学生インターンをしていました「なりあい」です！所属はERP開発本部 > 福岡第一開発部でした。主に「クラウド経費」のバックエンド開発に携わっていました。
大学は福岡の九州工業大学大学院 情報工学府に在学しています。学部も同大学の情報工学部です。学部・修士では、「宇宙天気 × 統計・機械学習」をテーマに研究を行っていました。大学の講義で基礎的なプログラミングには触れていましたが、いわゆる「現場」での実務経験は、このマネーフォワードでの長期インターンが初めてでした。
私が担当していたタスクについて
先述した通り、私は「クラウド経費」というプロダクトの開発に携わっていました。これは、経費精算にまつわる一連のワークフローをオンライン上で完結させるSaaSで、バックエンドにはRuby on Railsを採用しています。 私の主な役割は、Railsを使った新規機能のバックエンド開発でした。 基本はバックエンドがメインでしたが、タスクの性質に合わせてフロントエンドのコードに触れることもあり、領域を限定せず幅広くチャレンジさせてもらいました！
インターンを通して築いた自分なりの開発プロセス
「実装」ではなく、「調査」から始める実務開発のサイクル
実務では、タスクをもらったらまず最初に調査とドキュメント化を行うようにしていました。私の中では、ここが一番重要なポイントだと思っています。実務経験を通して一番痛感したのは、タスクをもらったときにいきなり手を動かすのではなく、まずはしっかり調査して、それをドキュメントとして整理することが大事だという点でした。最初の頃は、タスクをもらったらシュッと手を動かしてパッとプルリクエスト（以下、PR）を出したいと考えていました。しかし、年間何万人ものユーザーが利用する大規模プロダクトの開発において、実務未経験の自分の感覚だけに頼った進め方では不十分だということを痛感しました。そもそも実装するべきクラスがわからず、自分なりに考えた実装でも、後から他の開発者との認識のズレが発覚してしまうなど、結果的に進めづらくなる場面が多くありました。
調査報告書（以下、調査doc）を作成するメリットは自分と他の開発メンバー両方が享受できると考えています。まず自分に対しては、調査docを作成することで、自分が実装を進める上で「何がわかっていて、何がわかっていないか」を明確にすることができます。特に学生インターンの場合、毎日出勤することが難しくなってくるので、「この前自分は何をやってたっけ」を防ぐこともできます。一方で、他の開発メンバーにとってもメリットがあります。実装に入る前に調査docを共有しておくことで、事前に認識をすり合わせることができ、実装後にレビューしてもらう際の前提説明が減ります。その結果、レビュー時の認知負荷をある程度下げることにもつながると感じています。
私が所属していたチームには、調査docのテンプレートが用意されていました（もっと早く活用しておけばよかった……）。このテンプレートでは単に「調査内容」をまとめるだけでなく、背景や目的といった前提条件から、既存実装の分析、さらにはリスクや懸念点までを整理できる構成になっていました。他のチームでも似たようなものが用意されていると思うので、探してみるといいかもしれません。
実際に調査を進める
私が対応したタスクはデータのCRUD操作が起点になるものが多かったです。そのため、まずは実際にローカルでサービスを立ち上げて、タスクに関わる操作を実際に行い、そのときに出力される「リクエストログ」を特定します。そのログをもとに、どのコントローラにリクエストが届くのか確認してから……といった形が多かったです。コントローラさえ分かれば、Railsだとそれに紐づくビュー、モデル、インクルードされているモジュール、 呼びだされるジョブ、 サービスクラスなどがある程度把握できます。そこからはコードリーディングに移り、処理の流れやシステム全体の構造を追っていく、といった形です。私の場合、ある程度Rubyが読める状態になると、大規模システムとはいえ、コードを追う作業自体はそこまで苦に感じませんでした。
チーム開発における「越境」するコミュニケーション
異なる役職の方々とのコミュニケーション
調査を進めていく中で、自分がまだ把握できていない部分が見えてきたら、次のステップはチームメンバーとのコミュニケーションになります。最初に調査docを作っていると、何が分かっていて、何が分かっていないのかがある程度整理されている状態になるので、質問もしやすくなります。
まずはサービス全体の仕様を確認するために、PdM（Product Manager）とコミュニケーションを取ることが必要になります。 質問する時は以下のことを念頭に置くと話しやすいかと思います。
- なぜこの新機能が必要になるのか
- 今までこの機能を実装しなかったのはなぜか
- 実装するにあたってのリスク
開発に夢中になりすぎると、つい最初から「どうやって実装するか」というHowの思考に入りがちです。私自身もまさにそうでした。ただ、そこで一度立ち止まって上記のように「そもそも、なぜこの機能が必要なのか」というWhyの視点を持つと、実装の方向性や取るべき選択肢が自然と見えてくることがあると感じています。
また、自分の中でやりたい実装の方向性やアイデアがある場合は、それを先に共有したうえで相談を始めると、相手もこちらの意図を踏まえて話を進めてくれます。その結果、お互いの認識が揃いやすくなり、やり取り全体の認知負荷も下げられると感じています。
UIの変更が出る場合は、デザイナーの方々と認識をすり合わせながら進めていました。 私は下画像のようにFigma上でやり取りを行っていました。
タスクによっては他のチームの方々とも連携を取っていました。皆さん、初めましての関係であっても快く話し合いに参加してくれました。
開発メンバーとのコミュニケーション
PdMやデザイナーとコミュニケーションを取って仕様が固まったら、自分で実装案を考え、同じチームの開発メンバーに共有します。ここでは既存のデータフロー、どのクラスを修正・追加するかなどの実装案を提示して、コメントをもらいます。ここですり合わせを行っておくと、実装が楽になります。ここも開発docを使って伝えるのもいいですが、私は複雑な実装の時は、下記のようにデータフローマップにしてチームメンバーに共有していました。
「読み手」と「将来」を意識したコーディング
調査・チームメンバーとの認識すり合わせが完了したら、いよいよ実装に移ります。 私は技術力が特別高いわけではなかったので、正直PRでも多くのコメントをもらうことが多かったです……（絶えずレビューしてくださったチームメンバーの方々本当にありがとうございました🙇） そんな中でも、特に実務を行う上で重要だなと感じたのが、「適切な責務分担」です。
この重要性を強く感じたのは、最初の頃に担当したタスクがきっかけでした。内製のMLモデル用に、アプリ側のデータをAPI経由で1日1回送信する、という内容です。実務に入って間もない時期だったこともあり、どのクラスにどの処理を書くべきかは、メンターの方と綿密に相談しながら決めました。 結果として、処理を開始するジョブクラス、送信データをAPI用に整形するサービスクラス、実際にAPIへ送信するクライアントクラス、といった形で責務を分けて実装しました。タスク自体はこれで完了したのですが、実装後に「この処理を拡張してほしい」という追加要望が入りました。 このとき、前回の実装で責務ごとにクラスを分けていたおかげで、どこに手を入れるべきかをすぐに把握できました。また、変更点も責務単位で分割できたため、1つ1つのクラスの差分が小さくなり、PRも意味のある単位で出しやすくなりました。こうした経験から、大規模な開発を進めるうえでは、特に適切な責務分担が効いてくると実感しました。
もちろんコーディングにあたって、重要なのは処理を記述するだけでなくテストも同じくらい重要です。 テストについても当たり前ですが、正常系だけでなく、境界値分析、外部APIのダウンなど異常系を徹底的に考慮するように心がけるといいです。実際、新規機能を開発してて、自分では気づかないデグレにテストで気づくこともありました。
レビュー負荷を小さくするPRの作成
実装が終わって次はPRのレビューになります。 実装をやっていると、自分の中ではそのタスク周りの知識がつくので、PRのdescriptionも不足しがちになります。（私もそうでした🥲）descriptionの粒度は意識するといいと思います。 特にUIの変更などでは、認知負荷を軽減するためにも、操作画面のBefore/AfterスクリーンショットをPRで共有するといいと思います！
クエリ周りの機能追加や修正をする場合、発行されるクエリ計画などを提示しておくと、レビューする側も理解しやすくなります。
加えて、なぜそのPRの出し方なのか、という視点も意識するといいと思います。たとえば特定の機能を開発する時に、その機能に関するFeatureブランチを作成して、そのブランチから最小単位の機能を実装するtopicブランチを作成するなどしてそのPRの処理がどの処理に付随しているか関係性をあきらかにすることができます。
メインブランチ <--- リリースブランチ <---- feature/epic <-+-- topic/add-model-logic
|
+-- topic/extend-service-layer
|
+-- topic/extend-job
ついにリリース🎉
PRでレビュー担当者からapproveをもらえたら、いよいよリリースです。まずは検証環境で動作確認を行い、その後に本番環境へマージする、という流れになります。これまで何度かリリースを経験してきましたが、リリース直前の緊張感と、無事にリリースが終わったときの安堵感や達成感は、何度経験しても変わらないものだなと感じています。
以上が一例ですが、私が実務開発を通して経験してきた一連の流れです。細かい部分まですべて伝えきれているわけではありませんが、実務でどのような流れで開発が進んでいくのか、その全体像だけでもなんとなく伝わっていれば嬉しいです。
補足：情報発信について
直接の業務とは離れますが、インターン生も学んだこと、感じたことなどをブログ、LTなどで発信することが大事だなと感じました。インターン生だからこそ発信できる情報もあるかなと思いますし、何よりそうして発信することで自分がどのようなことを意識して実務を行っていたか、今足りない部分などを整理するいいきっかけになると思います。（就活の時にめちゃくちゃ役立ちました笑）
私は福岡開発拠点のアドベントカレンダーでのブログ執筆・同拠点開催のLT会に登壇させていただきました。（お誘い、サポートしてくださったshimamuさん、sekkyさん、tositeさんありがとうございました🙇）
最後に
関わってくださった全ての方に感謝
実務未経験から飛び込んだ私を手厚くサポートしてくださった皆さん、本当に1年半ありがとうございました。開発経験があまりない私からすれば大規模すぎる開発現場に携わらせていただいたなと感じています。私からの質問攻めになった場面も多々ありましたが、その度にたくさんの方からの手助けをいただきました。メンターとして支えてくださったgotoさん、実装を手助けしてくれたチームメンバー、福岡拠点拠点長のtsutsumiさん、EMのAshiharaさん、Tech Leadのmiyamuさん、LT・ブログ投稿のサポートをしてくださったshimamuさん、sekkyさん、tositeさん、インフラ周りで質問に応じてくださったSREチームの皆さん。挙げていくとキリがないメンバーの方々に助けていただきました。本当にありがとうございました！！
今後入社するインターン生へ
今回の記事はあくまでも私が1年半インターンを通して身についた「型・考え方」なので、人によっては「え〜そーかな〜？」と思うところも多々あると思います。あくまで実務を行う上での流れの一例として捉えていただくとありがたいです🙇そして自分で経験して自分の型を作っていくことが大事になってくると思います。 私は実務未経験だったので、実務参加当初は何をやっていいかもわからず、「これってやっていいの？」と悩んでばかりでした。ただ、根気強く開発に向き合うことで自分の型が見つかり現在に至りました。この記事で紹介した内容も、あくまでその一例にすぎませんが、これから実務に入る方にとって、何から始めればいいのかを考えるきっかけになれば嬉しいです。
