【渡されたデザインを再現することだけが仕事ではない】 オハコのエンジニアが考える、理想のプロジェクトへの取り組み方

こんにちは、フロントエンドエンジニアの菅です。
今回は「オハコのエンジニアが考える、理想のプロジェクトへの取り組み方」をご紹介させていただきます。

現在、オハコにはフロントエンドエンジニアが2名、iOSエンジニアが3名、バックエンドエンジニアが1名在籍しています。フロントエンドエンジニアが担当するプロジェクトは、サービスの新規立ち上げや改修のプロジェクトへのアサインが主で、サービスに関わるwebサイトの構築や管理画面のフロント実装を担当しています。

エンジニアがこれまで直面した課題

問題が全く発生しないプロジェクトはごくごく稀と思います(オハコも例外ではありません...!)

オハコのエンジニアがこれまで直面した課題としては、以下のものが例として挙げられます。

  • デザインが完成して、初めてエンジニアへの共有が行われた
  • エンジニアの実装期間に、デザイナーがプロジェクトから外れていることで、デザイナーへの確認に時間がかかった
  • プロジェクトマネージャから聞いた要件がクライアントの要望とずれていた
  • 現在プロジェクトがどのようなフェーズなのか、エンジニアが把握できる環境が準備できていなかった

もし、渡された完成版デザインが工数内で実装できないものだったらと考えると背筋が寒くなりますね…。

また、デザイナーがプロジェクトから途中で外れてしまうと、実装中に生じた疑問点をすぐに解決できないかもしれませんし、エンジニア側で認識している要件が本来の要件とずれていたとすると、クライアント含めプロジェクトチーム全員で思い描いていたプロダクトが作れるはずもありません。

このような状況では、エンジニア負担が大きくなるだけでなく、最終的なプロダクトのクオリティ自体が下がってしまいます。

では、これらの問題が発生しないようにするにはどうすれば良いのでしょうか?


これらを克服したプロジェクトのフロー

実は、オハコにはこれらの問題を克服した、あるプロジェクトがありました。そのプロジェクトでは、以下のようなコミュニケーションを積極的に実施していました。

毎日プロジェクトメンバー全員での夕会

  • クライアントとの打ち合わせ内容の共有、それぞれの作業の進捗、今抱えている問題の共有 など

週に一度の振り返りMTG( KPT [ Keep / Problem / Try ] の洗い出し)

  • 直近1週間で起きた「良かったこと」「課題と感じていること」「課題に対して改善できると思う施策」の洗い出し
  • 列挙する内容はどんな些細なことでもOK!(例)今週は体調が良く、いつもよりいい感じにコードが書けた。

上記をきちんと継続して実施することで、メンバー間で話す機会が多くなり、あらゆる情報の共有が随時行われて、プロジェクト全体での認識のずれも解消されました。そして、メンバーが集まるタイミングが必ず発生するので、それに合わせてデザインレビューを行うことで、実現可能性の確認をフローに取り入れることができました。


今後、定着させていくプロジェクトのフロー

この経験をきっかけに、今後オハコでは下記のような体制構築を進めていくことを決めました。


プロジェクトチームとして行うこと

1. 全ての工程に全てのメンバーが関わる体制を作る。

  • プロジェクト開始当時から関係者全員でプロダクトについて考え、よりよいプロダクトを生み出す為にはどうすればいいのか、プロジェクトを円滑に進めるにはどうすればいいのかを意識して行動できるチームを作ります。
  • そのため、オハコではデザイナー・エンジニアは 複数案件を同時期に並行しない方針 を取っています。

2. プロジェクトメンバー全員参加のデイリーMTG、週1回のプロジェクト振り返りMTGを行う。

  • 毎日、Zenhubやスチレンボードを使い、チーム全体のタスクを可視化し、それを基に職種関係無くメンバーの状態を共有します(目安:10〜15分程度)
  • プロジェクトの作業進捗だけでなく、メンバーの体調や精神面の状態も感じられように極力対面での実施を心がけています。

3. ワイヤーやデザインをプロジェクトメンバー全員でレビューする。

  • 職種関係無く、プロジェクトメンバー全員がデザインに関わる意識を持ち続けるために実施します。
  • 「自分がこのプロダクトのユーザーだったらどう使うか、何が困るか」などをユーザー目線に立ち、より良いプロダクトに向けて磨き上げていきます。


その中でも、特にエンジニアが心がけること

1. 自分の目の前の作業だけに集中せず、プロジェクト全体の進捗や成果にも目を向ける。

  • エンジニアの仕事はコーディングだけではなく、プロダクトを生み出す上での技術面からのサポート全般に及ぶと考えるからです。

2. クライアントのビジネスやプロダクトの将来に興味を持つ。

  • より良いプロダクトを考えるためには、UI設計・ユーザビリティを考える必要があり、それらはクライアントのビジネスに直結しています。
  • なので「そもそもどのようなビジネス、世界観なのか」「その中で、このUIは適しているのか」といったことまでエンジニアも意識する必要があると考えています。

3. デザイナーやPMが助言できない技術的な問題でもプロジェクトメンバー内で共有する

  • 技術的な話だと「言っても無駄だ」という意識があると思います。しかし、技術的な面では無く、「まず〇〇という困っている問題がある」といった状態を共有することが大事だと考えます。
  • そのような状態であることが共有できるだけでも、デザイナーやPMは何かしらの間接的なフォローを考える余地が出来、結果としてチーム全体で柔軟に動くことができると考えています。

さいごに

オハコが掲げているVALUEには、下記のような項目があります。

  • 垣根を超えた働き方への追求と目的の共有
  • 私たちだからこそ提供できる品質に対して情熱と責任を持つ

オハコのフロントエンドエンジニアは、渡されたデザインをただ再現することだけが仕事ではないと考えており、開発(コーディング)以外にも目を向け、興味を持ち、課題を探り解決していくことがより良いプロダクトが生み出せると考えています。

そして、プロジェクトチームとしても「最良の接点 [ インタフェース ] を生み出すにはどうすればいいのか」という視点で、それぞれの役職や所属の垣根を超えて議論や行動ができるよう、個々人が自発的に関与することが、大事であると考えています。

株式会社オハコ's job postings
Anonymous
C554c3da bb99 48f3 987c bd0a559f15d2?1527593378
54b33faa 7cfc 4780 b4a0 79e38aaeded7?1531172831
3adc842c 61b0 4e11 b953 4123d5baa5a1?1560491523
Dec129a1 dad6 49b1 9fd1 6c57f2ab3d54?1502877332
C8abce5f 372e 4ea9 9e8b ddbe484b40f0
9 Likes
Anonymous
C554c3da bb99 48f3 987c bd0a559f15d2?1527593378
54b33faa 7cfc 4780 b4a0 79e38aaeded7?1531172831
3adc842c 61b0 4e11 b953 4123d5baa5a1?1560491523
Dec129a1 dad6 49b1 9fd1 6c57f2ab3d54?1502877332
C8abce5f 372e 4ea9 9e8b ddbe484b40f0
9 Likes

Weekly ranking

Show other rankings

Page top icon