見出し画像

インターン生が抱えるチームワーク課題の解決ポイント



はじめに

はじめまして、マネーフォワードでインターンをさせていただいている、なのです。

公立はこだて未来大学(情報系の単科大学)にてデザインを学んでおり、ハッカソンに出たり、エンジニアとのチームワークでプロダクト開発を学んでいます。

アイデアの引き出しや効率よく技術を集結させるためなどに、チームワークはプロダクト開発には必要不可欠だと考えています。

この記事では、より良いチームワークのために、私がエンジニアやデザイナーとチームで開発をする上でぶつかってきた課題について、マネーフォワードのデザイナーにお聞きしたことをご紹介します。

マネーフォワードでの開発フロー(例)

より良いチームワークについて知る前に、まず、マネーフォワードの開発フローをご紹介します。

チームによって異なりますが、MFBCデザイン室 債権債務・経費デザイン部 副部長のゆきねぇさんの場合についてお聞きしました。

MFBCデザイン室 債権債務・経費デザイン部 副部長のゆきねぇさん

マネーフォワード福岡拠点では、アジャイル開発のスクラム手法を用いてプロダクト開発を行っています。

アジャイル開発のスクラム手法
福岡拠点での開発プロセス1
福岡拠点での開発プロセス2

デザイナーは要件定義を具体化するところから参加し、キックオフ、設計に主に携わっています。実装フェーズでも、デザイナーがスプリントレビューや振り返りに参加することで、エンジニアと連携を図りながら開発の精度を上げています。

要件定義の具体化はディスカバリープロセスを、キックオフはインセプションデッキに則り行っています。

インセプションデッキについては、福岡開発部のおかむさんが詳細なnote記事を書いています。

インターン生が抱えるチームワーク課題

  1. アイデアが出ても、どのように優先順位をつけたらいいかわからない

  2. 画面設計の抜け漏れが発生してしまう

  3. レトロスペクティブがただのタスク報告会になってしまう

  4. ユーザにとって価値のある改善策がわからず、議論がチームで収束しない

  5. チーム全体のモチベーション維持が難しい

これらは、私がエンジニアやデザイナーとチームで開発をする上でよくぶつかる5つの課題です。

これらの課題にぶつかったとき、マネーフォワードの人たちはどうしているのでしょうか?
マネーフォワードでエンジニアと共に働く機会の多いデザイナー2人にお聞きしました。

MFBC デザイン室 基盤デザイン部のしげさん
MFBC デザイン室 経理財務デザイン部 個人・SMBグループのさえさん

1. アイデアが出ても、どのように優先順位をつけたらいいかわらかない


なの:
アイデア出しの際に、たくさんアイデアが出ても、どれが最善の策なのかメンバーで一致させるのが難しいです。

しげさん:
最初にアイデアをたくさん出したら、開発工数のかかるもの〜かからないものを3案ずつくらいに絞ります。松竹梅みたいに。そして各案のメリットデメリットや、そのアイデアを出した理由を見て決めていきます。

💡一つのアイデアに対してメリットデメリットの両方を見る

さえさん:
PDMからもらったタスク依頼から、ユースケースなどの根拠を調べ、エンジニアと相談しながら方向性を固めます。
エンジニアにアイデアを説明するときは、なぜこういう課題があるのかや、使用時のユーザの状況を整理した上で、デザイン提案の理由を伝えるようにしています。
実際の業務では開発の工数、スキルなどもアイデアの優先順位づけに関わってきますね。

💡アイデアの根拠や背景を固め、共有する

2. 画面設計の抜け漏れが発生してしまう

なの:
デザインプロトタイプを完璧に作れた!と思っても、開発し始めてから、画面が足りなかったりデザインプロトタイプに不備があることに気付くことがあり、困っています。

しげさん:
エンジニアと相談しながらつくることはもちろん、UIスタックを考えながら画面をつくると、必要な画面の網羅性が上がり、実装中に足りないケースが未然に防げたり、エンジニアとのコミュニケーションがしやすくなります。
また、画面遷移ではなくGUIの状態遷移では、業務におけるオブジェクトを見出し、それらがどのような状態を持ち、どのように遷移するのかを定義するのが大切です。

💡画面遷移はUIスタックを考え、GUIの状態遷移はどれがどのような状態や遷移があり得るかを考える

さえさん:
エンジニアと相談をしながら画面をつくっていきます。詳細の画面についてはエンジニアの得意分野であり、エンジニアだからこそできることなので、協力してやっていくことが大切です。

💡エンジニアとコミュニケーションを取りながら画面をつくる

3. レトロスペクティブがただのタスク報告会になってしまう

なの:
短いスパンで改善を繰り返せるよう、私もアジャイル開発をしていました。しかしスプリントレビューやレトロスペクティブなどの振り返りの場で、「もっとこうしよう!」という改善提案は少なく、「こんなことをやったから次も引き続き頑張ろう」という報告会になってしまいます。

しげさん:課題感があれば持ち寄ってきてくれるメンバーが多いため、開発とは別軸で解決策を考え、それを実際に試してみたりしています。 エンジニアだけでいうと、KPTをスプリントレビューのときに行っているらしいです。
対面で会う機会や、チームメンバーが一同に集まる機会を増やし、距離感を近づける施策は効果的でした!

💡計画とは別にチームのことを考える時間を設ける

さえさん:
デザイナーやPO・PDMだけでなく全員が同じ方向を向いていることが大切だと思います。デザイナーが一番ユーザに詳しい人というわけではなく、目的意識や根拠、背景を全員で共有し、全員がより良くしていこうという気持ちを持っています!
そのためにも、チームの仕組みとして、職種をまたいで議論する場が用意されています。例えば、デイリースクラムではデザインの相談を持ち込む時間があったり、スプリントの振り返り会ではチームの全員が参加したりしています。
密にコミュニケーションを取れる環境があることが、全員が同じ方向をむいて行けることに繋がっていると思います!

💡全員が同じ方向を向いて議論できる場をつくる

4. ユーザにとって価値のある改善策がわからず、議論がチームで収束しない

なの:
プロダクトの改善を行なっていくときに、メンバー同士で意見が異なり、議論を収束させるのが難しいです。
ユーザにとって何がいいのかを判断するために、ステークホルダーからフィードバックをいただいても、どの意見が重要なのか、本質の課題は何なのかをチームで一致させるのに苦労しています。

しげさん:
現状を調べ、それに対する課題解決のための開発をし、それが実現できたかどうかのフィードバックをもらっています。
そもそも何かをチームで開発するときやスプリントを回すときは、課題解決のための開発という目的(仮説)を持っています。

💡根拠のある仮説を立て、それに対してフィードバックをする

さえさん:
チームでは、ユーザビリティテストを行うこともあります。ある一つの機能に絞ってこういう理由でここが使いづらいのでは?という仮説を立ててからテストを行なっているようです。
また、UTの機会がなくても、CSさんのやりとりやデスクリサーチ、既存のマーケのデータなどの根拠を集めて仮説を立て、何が最善かを考えます。

💡テストも、仮説を立ててから実施する

5. チーム全体のモチベーション維持が難しい

なの:
長期的な開発になると、私も含めて、チームのモチベーションが落ちてきます。マネーフォワードではどのように取り組んでいますか?

さえさん:
ユーザからの評価がなかなか見えにくいプロダクトに関わっているため、ユーザビリティテストでの評価や、CSの方からお問い合わせ内容の共有など、チーム全体としてユーザからのフィードバックをシェアする動きがあります!
その際に、改善点だけではなく好評だった点もシェアされています。

💡好なフィードバックをシェアしてモチベーションを上げる

しげさん:
メンバー同士、良かったところを賞賛し合うようにしています。
また、チームとしてのミッションなど、チームメンバーの指針となるものを作るようにしています。

💡指針を常に持ち、チーム内で褒め合う

まとめ

今回は、インターン生の私が抱えているチームワーク課題について、マネーフォワードのデザイナーがどのように向き合っているかについて書きました。

  • 意思決定をする際は、仮説を立てたり、根拠を持って議論する

  • チームメンバーは同じ目標に向かって動く意識を持つ

  • 一つのアイデアにはメリットもデメリットもある

  • チームで褒め合うことも大事

インタビューを通して、チーム全員がユーザのことを考えたより良いプロダクトづくりという目的のために動いていることはもちろん、何か行動するときは仮説や根拠を立てたりと、デザインし始める前にたくさんの検討がなされている点に、感銘を受けました。


マネーフォワードではデザイナー新卒採用のエントリーを開始しています!ご興味のある方はこちらよりご応募ください!

この記事が気に入ったらサポートをしてみませんか?