今回は「私の仕事の進め方」と題し、開発ディレクターの清河さんが書いたnoteの内容をそのままご紹介させていただきます！同じく、ディレクターをしている方や、チームで開発をされている方と共感ポイントがあれば嬉しいです。ぜひご覧ください！

清河さんの仕事の進め方

webプロダクトやモバイルアプリなどの企画、要件定義、設計などをしているとき、同僚や上司から「仕事が早い」「そつなくこなす」という評価を頂くことがあります。

自分自身もスピード感をもって仕事を進めるのは重要テーマであり、そのように言っていただけるのは大変ありがたいものです。

ちなみに「そつなくこなす」には「要領が良い」や「ムダがない」という意味合いが含まれているといいます。

コツや仕事術については何度かにわけてお話しできればと思いますが、今回は「スピード感と完成度のバランス」について。

物は完成度低くて問題なし

企画フェーズや検討フェーズでは「完成度」を求める必要はありません。そのフェーズでは何度もレビューや添削を繰り返し、作り直しを伴うものだから。

検討フェーズで大切なのは議論するために必要な資料をいち早く作り、より早くレビューの場を設けること。完成度よりもスピード感重視です。

なのでより早く作れるのであれば、体裁はもちろんフォーマットだってなんでも良いのです。例えばワイヤーフレームだってmiro、Cacoo、Figmaなどで時間をかけて丁寧に作る必要はなく、Googleスライドだって手書きだって良いのです。

解像度を上げすぎないこと

もうひとつ大切なポイントは解像度を上げすぎて細かい要所要所まで検討をしてしまわないこと。細かい箇所はデザインフェーズや開発フェーズで見直しが入るためこの段階でそこまで作りこむ必要はありません。言い方が悪いかもしれませんが「適当」で良いのです。

完成度を高くした場合の弊害

• 着手時のベクトルがずれていたり、見当違いな設計になっている場合、いちから作り直しになる可能性が高い
  （その際、完成度が高いと作り直してもらうのが申し訳ないという気持ちが芽生えてしまう。。。）
• ほんの少しの修正でも完成度が高い資料を手直しすると、修正作業自体に時間がかかる可能性がある
• 次の工程で詳細を詰めるはずが、完成度が高いが故に先行過程の成果物の先入観にとらわれてしまい、良いアイディアが出てこなくなる可能性がある

上記をイメージで表すとこんな感じでしょうか。横軸に時間、縦軸に完成度を置いています。

スピード感優先の方がレビューの回数は多いかもしれませんが、手直しの量は少なく結果的に所要時間の短縮が期待できます。

リーン開発手法の考え方に似ているかもですね。

結論。「時間をかけた100点」と「最短時間で仕上げた及第点」だと後者の方が効率が良いという話。
「及第点」となっているのがミソですね。いくら短時間で早く仕上げるとはいえ、最低限のクオリティに達していないと議論するための材料にならないですからね。

>> 過去の、清河さんの社員インタビュー記事も、ぜひご覧ください！

エニマリの「note」も始めました！こちらの掲載記事が、マガジンでも読めます。