engineers_blogはじめまして、エンジニアの中村です。実は今年の1月1日にマネーフォワードに入社したばかりの新参者です。前職ではRubyやJavaでBtoC向けのWebサービスの開発・運用に携わっていました。マネーフォワードに入社してからは、先日リリースした給与計算ソフト「MFクラウド給与」を担当しました。そこで今回は、入社してからサービスリリースまでに経験したイケてるTipsを紹介します。エンジニア向けの業務仕様まとめもともとお金が絡むサービスの開発経験がなかった私は、「入社後には業務知識の理解に凄く苦労するかもしれない・・・」と漠然とした不安を抱えていました。ところが、マネーフォワードでは、サービスの仕様・用語集など必要な情報がQiita:Teamに集約されており、早期のキャッチアップが可能でした。今回担当した「MFクラウド給与」については、難しい仕組みや仕様がエンジニアに理解しやすい言葉に置き換えて書かれていたため、非常に助けられました。効率良くテストを書く今回の開発で特に注意したのは、サービスの根幹でもある給与計算処理の正確さです。この正確さを担保するために、計算処理部分には特にテストコードを十分書くように意識していました。各データの状態ごとにテストケースを揃えると、テスト件数が非常に多くなりテストコードを書くだけで力尽きてしまうので、どんなテストデータにすれば十分処理ロジックの検証ができるのか考えるようにしました。組み合わせは十分検証しているか、境界値のチェックは十分か、条件分岐で通ってない分岐はあるか、などなど。結果、テスト件数はそれほど多すぎず給与計算処理ロジックのテストカバレッジをほぼ100%にして効率よくテストを書くことができました。(とは言え、現在はテスト総件数が3000件を超えてそろそろテストの高速化を考えなければと思っているところですが。)ちなみに今回使っていたテスト用のgemは主に以下です。給与計算処理は仕様が複雑なため、それをコードに落とすのは非常に難しいことでした。そこで、どのようなクラス設計にすると良いかをコーディング前にチームの方針として決める必要がありました。今回行ったことは、チーム全員で一つのモニターに向かって議論しながらクラス設計/コーディングを進めたことです。9個の事」の8番目ですね。ペアプロならぬペア設計(チーム設計)は、生産性向上に有効な手法の一つだなと改めて感じました。実装方針についてもチームで意思統一がされ、ソースレビューがスムーズに進めらたという効果もありました。必要ならコメントは沢山書くコードを見れば容易に仕様が分かる箇所に於いてコメントを強要することはありませんが、給与計算処理ロジックは複雑な仕様であるため、後からソースコードを読む人向けにコメントを充実させました。思いやりの一環ですね。(自分も仕様を忘れてしまうかもしれませんし(笑))最後に他にも様々な施策がありましたが、印象に残っているものを紹介さえていただきました。如何でしたでしょうか。マネーフォワードでは、Railsエンジニアを募集しています。