プロダクト2.5合目、開発体制4.5合目と評価する理由は？デザイナーによるインタビュー 前編
（この記事は、前編と後編があります。）
マネーフォワード クラウドのラインナップである「マネーフォワード クラウド人事管理」。これは、社内のHR領域においても注目されているプロダクトです。
今回は、開発チームの自己評価を職種別に聞いてみました！
（2022年10月時点）
他のプロダクトと併用することで価値が生まれるプロダクトを作っています。
モルカーをこよなく愛しています。
アビー推しですが、最近ペーターも気になっています！毎週欠かさずリアタイしています。
インタビュアー（以下、INT）：小野
早速ですが、プロダクトについて教えてください。
グループリーダー（以下、GL）：佐藤
私たちが開発している「マネーフォワード クラウド人事管理」は、従業員情報の収集や更新を一元的に管理できるようにするプロダクトです。
マネーフォワード クラウド給与やマネーフォワード クラウド勤怠と連携すると、従業員情報を通信して反映することができる。
利用が想定される業務例を一部挙げると、入社や退職、給与計算の業務です。
これらの業務を行う労務担当さんは、従業員から身上情報を収集します。また、会社で保管している従業員情報を手動で更新することもあります。これら管理をまだ紙でおこなっている事業者さんも多いと聞いています。
ここでポイントになるのは、業務によって従業員情報の種類や扱い方が異なる点です。異なるということは、従業員情報の管理の仕方もそれぞれに存在する。つまり、従業員情報の多重管理が発生し、運用コストが嵩んでしまいます。
この多重管理の解消が、マネーフォワード クラウド人事管理の開発で目指すゴールの一つになります。
テックリード（以下、TL)：玉井
他のマネーフォワード クラウドのプロダクトとセットで使うとより嬉しい、ですかね。
プロダクトマネージャー（以下、PdM）：高澤
マネーフォワード クラウド給与やマネーフォワード クラウド勤怠と一緒に使ってもらえると、労務担当さんのお仕事がサクサク進むと思います。
想像できるプロダクトゴールを山頂としたら、今は2~3合目くらい。
GL：佐藤
リリースから、１年３ヶ月くらい経ちましたね。
PdM：高澤
諸説あるけど、2~3合目くらいに思っていて。
ただ、着実に速いスピードで登っているように感じます。
プロダクトとしてはまだ「赤ちゃん」ではありますが、成長速度は速いと思います！
目指したいチームの状態を山頂としたら、4~5合目くらい。
GL：佐藤
チームづくりの目標では「自律的な組織」とよく言っています。既に自走できるメンバーも揃ってるけど。
デザイナーとエンジニアでスクラムの解像度を上げる。
「アジャイルな見積りと計画づくり」が参考図書。
スプリントの最終日に行う、全体のKPT式の振り返り会。
どんな内容でも課題があれば意見する。
次以降のスプリントでトライするアイディアを出す。
開発を回す構造はできていると思っていて。
スクラムの基本的な型でPDCAできている。PJ管理としての破綻も出ていない。開発スタイルは確立しつつある。
ただ、組織をスケールさせることも考えると4~5合目くらいですかね。
PdM：高澤
個人的には自律的な組織、わかる。
スクラムマスター（以下、SM）：三宅
そうですねー、やはり4~5合目くらいかなと。
まだ決まっていないのは、特定のドメイン専門家になるのかどうかです。
インターナショナルなチームはどうするか？などの検討や準備も、まだこれからですね。
品質管理も、着々と整ってきている。
テスト観点が整理されたドキュメント。
開発プロセスにも取り扱うフローが組み込まれている。
GL：佐藤
私が入社した１年前は、テストケースの作り方や管理について検討している段階でした。
今はテスト観点表もできた。
そこに漏れがあれば、アップデートする仕組みもできている。足りないところは、もちろんあるんですけども 笑
開発チームは、多くのロールを備える体制で構成されている。
GL：佐藤
今の開発チームは、
グループリーダー：GL
スクラムマスター：SM
エンジニア：ENG
テックリード：TL
プロダクトマネージャー：PdM
デザイナー：D
QAエンジニア：QA
サイトリライアビリティエンジニア：SRE
で構成されています。Money Forward Vietnam（以下、MFV）のメンバーも関わってます。
GLやPdMは、ビジネスサイドともコミュニケーションを取りながら開発する機能のロードマップを管理しています。
テックリード視点の評価を教えてください。
最近はちいかわとホラー映画が好きです。
品質とアジリティは担保できている。技術的なチャレンジも組み込んでいきたい。
TL：玉井
組織に関しては、佐藤さんと同感ですね。
よくできてるなと思うのは、品質とアジリティの2点だと思います。
細かい単位で実装を繰り返しています。
なるべく小さく機能を実装し、小さくFBをもらう感じです。
ロードマップ達成を優先するため、技術的な取り組みに余裕がちょっとないかなとは感じます。もちろん、ユーザーへ価値を提供するためには大事なのですが。
「ちょっと取り入れてみたいんだよな」という軽いテンションで開発に取り込むようなことにチャレンジしていきたいですね。
GL：佐藤
余裕ないのわかる。
達成がマストの案件があると、なかなかチャレンジしづらい力学が働くとは思っていて。
PdM：高澤
PdM的にも、みんなすきにやってほしい。
楽しいのが一番ですよ。
INT：小野
具体的にはどんなチャレンジ？
TL：玉井
これまで、GraphQLとApolloというコミュニティが活発な技術を使ってきました。
それぞれのコミュニティで作られている技術を取り入れていくとか、自分たちがコミットしていきたいとかは、個人的に思っています。開発でヘビーに使ってきているので。
まだ使っていない、知らない機能もあると思うので、開発にも取り入れていけると面白いなと。
GL：佐藤
マネフォって現場に判断の権限移譲はされているので。
目標にねじ込んでみるとか。
それができたとして、TLがやりたいことは変わる？
TL：玉井
そうですね。
やりたいことは、GraphQLとかに限らずですかね。
これから開発でRubyとRuby on Railsを使い続けるのであれば、その周辺でも良いですし。そうではない選択もあるかも。市場的にも流行っているGoとかですかね。
エンジニアメンバーのスキルと市場価値の向上を目指したい。
GL：佐藤
部分的に導入してみるとか？
TL：玉井
部分的に違う言語を導入するのは、生産的ではないなと思っていて。
新しい機構やサーバーが必要になった時、自分達が知識を取りに行けるようだと良いのかなと。知らない技術があれば自分達で勉強しながら導入する、みたいなのが楽しいんじゃないですかね。
INT：小野
エンジニアとしてのブランディングとかもあるかな。
TL：玉井
そうですね。外部へのアピールにもなると思いますし。
仮にですが、社内異動においても社外でチャレンジするにしても活きると思います。
メンバーの技術を上げる意味でも、エンジニアとしての市場価値を上げる意味でも、良いんでしょうね。
よく言われる話ですけど。
GL：佐藤
ブランディング、採用、市場価値、あと楽しい。
いいことばっかりですね。
INT：小野
あとは、ビジネス観点での翻訳もできると良さそうですね。
GL：佐藤
そうなんですよね！！
INT：小野
プロダクトのフェーズも考えつつ計画を練っていけると良いのかなとは思いました。
エンジニア視点の評価を教えてください。
スポーツ観戦が好きです！先日は鈴鹿でF1を観てきました。
雨の中でしたが、決勝の1コーナーのワクワクを楽しめてよかったです。
来年も行きたい...！
変化に適応する意見を言い合いやすいチームになりたい。
エンジニア（以下、ENG）：井之上
僕は普段MFVと一緒に開発してます。Money Forward Japan（以下、MFJ）、つまり日本拠点とベトナム拠点の協働ですね。
僕（MFJ）とMFVでのやり取りは、MFVのアクセラレーターさん（日本語を話せるベトナムの方）を通じて連携しています。
日本でやってる開発フローを、MFVでも実行できてるのは結構すごいなと思ってます。
テストもMFVで作ってるし、品質も高い。自律している。
このままMFVの組織が拡大しても問題ないんじゃないかなって思ってます。
TL：玉井
MFVのテスト、観点の網羅性が高くてすごいイメージ。
GL：佐藤
MFVのチーム作りもかなり上手くやれてた印象あります。
井之上さんごいす。
先人の開発にも感謝しながら、でも変えていける構造を作ったり意見できると良い。
ENG：井之上
プロダクトの特性として従業員の情報を扱うので、多くの人に利用してもらえると良いと思っています。ただ、今後もっといろんなユーザーの属性が増えて、要求も見えてくるものがあるだろうなと。
そうなると、その要求に応えられるような開発ができるチームになってると良いなと思っていて。既存の仕組みにも変更を加えなければならない時があるかもしれないし。実装してくれた先人には感謝しつつも。
玉井さんも言ってたけど、技術的なチャレンジというか。 MFJ・MFV問わず、そういった意見をカジュアルに出せるチームだといいなと思ってます。
TL：玉井
なんか、まだ日本からベトナムへ伝えた内容をそのままやってもらってるだけみたいなイメージありますよね。もっと提案してもらえるといいですよね。
D（デザイナー）：林
井之上さんが普通にめちゃいいこと言ってるのが新鮮すぎる。
PdM：高澤
普段ふざけてると、こういうとき得ですね。
ENG：井之上
ちょっとやめてください 笑
この続きは後編で。
QAエンジニア、デザイナー、エンジニア、スクラムマスター、PdM視点での自己評価を話します。
具体的な悩みや業界の話題もありますので、お楽しみに。
この記事が気に入ったらサポートをしてみませんか？