はじめに
この記事はtechtekt アドベントカレンダー2021、24日目の記事です。
こんにちは。 テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしております、吉次（よしつぐ）と申します。
普段はサラリーズというサービスの開発・プロジェクトマネジメントをしています。 サラリーズは2021年5月に正式版をリリースし、日々機能追加や改善に取り組んでいます。
不確実性の高い新規サービスの開発をマネジメントする中で、
Done is better than perfect
という言葉について考える機会があり、自分なりの整理をしてみたので記事にしてみました。
Done is better than perfectの意味
Meta社（前Facebook社）のマーク・ザッカーバーグ氏の言葉と言われています。 素直に翻訳すると「完璧にするよりもまず終わらせた方が良い」というような意味になります。
意味は簡単で感覚的に理解はしていたものの、新規サービス開発のなかでどのように実践していくか、実践するために具体的にどういった観点をもって、チームをまとめてサービスを前にすすめるかは言語化できずにいました。
【結論】『今、サービスにとって重要なこと』の認識を合わせる
記事が長くなりそうなので、先に端的な結論です。 結論としてはほとんどこの一言に尽きます。
サービスがどのフェーズにあるかや、どんな性質を持つかによって、何を重要視して開発を行うかが変わってきます。
あくまでも例ですが、イメージとしてはこんな感じです。
| フェーズ | 状況 | 重要なこと |
|---|---|---|
| 初期 | ユーザ数を一定水準まで増やさないとサービスが継続できない | 必要な機能をできる限り早く作ってリリースする |
| 成熟期 | 使ってもらっているユーザの満足度を高めないとサービスから離脱していく | 最適なUXの実現 / パフォーマンスの最大化 |
今どういう状況で、何を重要視してパワーをかけるべきなのか、BTC（Business / Technology / Creative）それぞれが目線を合わせ、適切に役割を果たすことでサービスの価値を最大限引き上げられると考えています。
本章以降でこの結論に至った背景や考えたことを掘り下げていきます。 サービスの初期フェーズであることを前提にして書いています。
考えることになったきっかけ
デザイナー、Webエンジニア、データエンジニア、データサイエンティストなどが協業してシステムを作っていく中で、チームによっては遅れが生じることがあります。
場合によってはもともと想定していたリリース日をずらさざるを得ないこともあります。
その際に、予定通り進めていたチームは『時間があるのならより良い設計にして作り直したい』と思うのは自然な発想です。
私がプロジェクトマネジメントをする中でも似たようなことが起こり、 「ひとまずはもともと定めていたスケジュールで作りきってください」 という旨のことを伝えました。
このとき、自分でもなぜそのような判断なのかをきちんと言語化して伝えることができませんでした。 プロジェクトマネージャとしての思いとプレイヤーとしての思いにギャップがあったように感じ、自分の判断とその理由についてを整理することにしました。
専門職プレイヤー・チームのミッション
1つのサービスの裏には、様々な職能のチームがいます。 そしてそれらのチームが専門性に沿ったそれぞれミッションを持っています。
例えば、UXデザイナーのチームであれば『ユーザー体験価値の最大化』、営業のチームであれば『最適なアプローチでユーザ獲得につなげること』などが考えられます。
これらは単体で見ると正しく、一見それぞれのチームのミッションに沿ってやればうまくいくように思えます。 一方で、それぞれのチームのミッションを果たすことがそのままサービスの価値に繋がりにくい状況も起こり得ます。
ミッションに基づく行動（正しい）とサービスとしての成果（上手くでない）のギャップがそのままプロジェクトマネージャとプレイヤーの『思い』のギャップの根底にあるように感じました。
サービスの成長戦略に基づいてミッションを再定義する
これまでの思考のプロセスを経て、 『それぞれのチームのミッションの方向性が合ってないとサービスとしての成果が上がりづらく、各プレイヤーも気持ちよく仕事をするのが難しくなる』という仮説を立てることにしました。
もちろん上述したようなチームの根幹を成すミッションを持つことは必要不可欠です。 一方で、そういった根幹を持ちつつもサービスの置かれている状況に応じて臨機応変なミッションを定めるのも同じくらい重要だと思いました。
そこで、改めてBusiness、Technology、Creativeそれぞれに属するメンバーで集まって、
- 今、サービスがどういう状況でどのような重要課題があるのか
- その重要課題を解決するためにそれぞれのチームがどのような姿勢で仕事をする必要があるか
といったようなことについて話し合い、認識を合わせる機会を持ちました。 目線が揃ったことにより、プロジェクトの一体感が増したように思います。
極端な例ですが、これからどんどんユーザ獲得していく必要があるサービス初期のフェーズにおいて
- できること（機能）は1つだけど最高のUX
- UXはそこそこだけどできること（機能）が10個ある
という2つの選択肢があった場合、後者のほうが売り込みやすくユーザ獲得につながると考えられます。 また、潜在ユーザがまず考えることは「何ができるか・できないか」や「持っている課題が解決できるか」を重視することが多く、その部分にアプローチする方が有効であると考えられます。
何かを重視すると何かを切り捨てたり妥協したりするシーンも出てきますが、 前向きに意思決定し、重要なところに注力することができるようになりました。
『どこまでやるか』問題と向き合う
とりわけデザインやエンジニアリングの領域は、突き詰めればどこまでも追求できるもの多くあります。
例えば
- Web APIやページ表示速度の改善
- プログラムのリファクタリング
- セキュリティレベルの向上
- 最適なUXの検討
- UIのアニメーションや装飾、レイアウト等の調整
などです。
- 致命的なバグがなく機能が使える
- セキュリティ要件を満たしている
- マニュアルを熟読しなくてもある程度使える
といったような状態は最低限担保すべきものになるので当たり前にクリアする必要があります。
一方で、どこまで突き詰めて良くしていくかは線引きをしなければゴールにたどり着けません。エンジニアやデザイナーはある種の職人気質があるので、突き詰めたくなってしまう生き物です。
このような『どこまでやるか問題』に直面したとき、ビジネスに対して最も有効に作用するラインの見極めが重要となります。
このラインの設定は、サービスの性質やチームのスキル・キャパシティ、予算などの様々な要因に影響されます。
これも極端な例ですが、とある処理に10秒かかっていたのを1秒にすることと、1秒を更に改善して100ミリ秒にすることは、かかる労力と得られる効果に差があります。
その処理が1秒で終われば十分であればそこで線引して、他の機能追加に時間をかけて短期間により多くのソリューションを届けることで、ユーザ獲得につなげた方がビジネスに有効に作用します。
もちろんサービスが成熟してくると、1秒を100ミリ秒に改善することが大きな価値を持つタイミングも将来的には来ることがあるかもしせません。
完璧を犠牲にするのはなぜなのか
ここで改めて
Done is better than perfect
に立ち返り、『完璧』の方に着目してみます。 特にサービスの初期フェーズでは、以下のような理由から完璧を犠牲にしてでも完了を目指すべきだと考えています。
完璧は定義できない
上述したように、『最低限』は可視化できても『完璧な状態』を定義することは極めて困難です。 絵画や音楽などの芸術分野でもそうかもしれませんが、ものづくりをしていると今日は「これ完璧だ！」と思っても次の日には「やっぱ微妙だな...」となることが往々にしてあります。 また、Aさんにとっては完璧でもBさんにとってはそうでな場合も当たり前にあります。
市場は待ってくれない
完璧を突き詰めている間にも世の中は動いています。 ルールが変わったり、顧客の持つ課題が変わったり、競合サービスが出てきたりします。
限られた時間の中で、できるだけ多くのトライアンドエラーをくり返して 完璧ではなくとも尤もらしい解を導き出す方が現実的ですし、エラーの部分も糧にすることができます。
『課題はわかっているんだけどどう解決していいかわからない』といった領域を狙ってサービスを出して、最適なアプローチをユーザのフィードバックを元に模索していくようなフェーズでは特に重要だと思います。
シビアなビジネスの環境下でエンジニアやデザイナーが『やりたいこと』を実現していくには
サービスを成功させるためのDoneを中心に書いてきましたが、一方でデザイナーやエンジニアがやりたいことを実現する環境を作るのも重要です。
例えばエンジニアの場合、
- 新しいプログラミング言語に挑戦したい
- パフォーマンス向上やセキュリティの知識を身に着けて実践したい
- リファクタリングしたい
などが考えられます。
『やりたいこと』は短期的な成果は得られにくいものが多いですが、 長期的にはビジネス面・個人のスキル面などおいても大きく寄与し、結果的にサービスの価値を高めることになります。 また、成長機会を作ることは持続可能な強いチームを作ることにもなります。
これらのことを実際のプロジェクトの中でやっていくには次のようなことが必要になってくると考えています。
- プロジェクト・チーム・会社としての課題に昇華させる
- 程度を決める
* 例えばリファクタリングでは、新規機能の開発に対してどの程度リファクタリングに時間を使うかを考えます。これもBusiness / Technology / Creativeがそれぞれ認識を合わせてちょうどいい塩梅を模索します
会社やチームでやりたいことをどう実践しているかは、いろいろな方に話を聞いてみたいと思っています。
おわりに
今回課題に感じたことがきっかけで自分の頭の中を整理し、実際に人と話して認識をあわせたことでサービスに対する愛のようなものが深まり、1つになって目指す世界観に向かって突き進む準備ができました。
いろんな職種の人が協業するシーンでは、自分の言ってることを理解をしてもらえなかったり、相手の言ってることが理解できなかったりすることはよく起こります。 そこで膝を突き合わせてしっかりと議論することの重要性を改めて感じました。
これからもプロジェクトをマネジメントする立場として、状況に応じた最適な選択ができるよう精進していきたいです。
P.S. 実はもっと書きたいことがありましたが、Doneを重視してアドベントカレンダーの公開に間に合わせました。
吉次 洋毅 Hiroki Yoshitsugu
エンジニアリング統括部 サービス開発部 第2グループ シニアエンジニア
2014年に高専専攻科を修了後、飲食店検索サービスを提供するWeb企業に入社。PHPをメインにバックエンドの領域の開発やプロジェクトマネジメントに従事。2016年にインテリジェンス（現パーソルキャリア）に入社。「doda AIジョブサーチ」の開発などを経て、現在はSalariesの開発を担当している。
※2021年12月現在の情報です。
