これはなに

この記事は、以下の記事たちに触発されて、「Qiita社の1つの事業を統括している（タイトルは事業開発とします）自分が、エンジニアと協働するためにどのような取り組みを実施したのか」を語ってみよう！という内容です。

サービスやプロダクトを一緒につくるために、エンジニアと協働していくことは不可欠です。
お互い遠慮がちに距離をとって、それとなく仕事する…なんてことにはなりたくありません。
価値を提供するために、言いたいことを言い合えるような関係性で取り組みたいと思い、さまざまな試みをしてきました。

まだまだ改善の余地はありつつ、これまでの取り組みをここに記載します。

対象読者

• ビジネス職と協働するにあたり、何らかの課題を感じているエンジニアの方
  • もし参考となる箇所があれば、ビジネス職に対して具体的にこうしてほしい、みたいな要求をする際の参考としてご利用いただけたらと思います
• エンジニアと協働していきたいビジネス職の方
  • 少しでも参考になれば嬉しいです

取り組んだこと

なんでもかんでも依頼しない

まずはこれです。「ユーザーが言ってるから」「クライアントに言われたから」と言って、なんでもエンジニアに依頼したり、Issueにしないことです。
確かにその「ニーズ」が最適解の可能性はありますが、ただ単に表層的なニーズをそのまま右から左へ受け流さないことは常にやってきました。

顧客は得てして本当の課題に気づいていないことが多いです。だからこそ顕在化した「ニーズ」の源泉である「ジョブ」を確認してきました。
例ではありますが、以下のような質問をして、ジョブを発見してきました。

• そう思ったきっかけを教えて下さい
• それを実現することによって、何を手に入れたいと思っていますか
• 現在どのような代替手段で対応されていますか
• もしこのままその機能がなければ、どんな状態になりますか

ジョブを理解さえすれば、さまざまな手段でそのジョブを満たす方法が見えてきます。いただいた声の対応をそのままするのか、あるいはそれよりも適切な方法があるのか、最適解を見つけ出すことが可能です。

ジョブを特定し、ある程度手段を検討した上でエンジニアと議論します。その後何をいつどのように対応するのかを決め、Issueを立て、エンジニアに依頼することをしてきました。

顧客と接点を持つ機会が多いビジネス職としては、このようなプロダクトマネジメントも1つの役割だと考えています。

スプリントに合わせてIssueを立てる

弊社のプロダクト開発チームは、スクラムを導入しています。ですので、ある程度依頼の見通しがついているIssueに関しては、スプリントプランニングまでにIssueを立てます。

突発的なIssueは絶対に生まれてしまうものですが、その都度エンジニアはどのIssueをこのスプリントから外すのか、など修正を余儀なくされます。次のスプリントで取り組んでもらいたいIssueは必ずプランニングに間に合わせて作成することが配慮だと思っています。

エンジニア文化を取り入れる

スクラムの話を上記でしましたが、ビジネス職の僕たちもスクラムを取り入れています。

ツールもエンジニアが利用しているツールをそのまま使っています。具体的には、GitHubとZenHubを利用しています。
自分たちで新たなツールを探して導入から運用を進めるよりも、すでにノウハウがあり、使い方がわからなければ周りに質問できることの方がメリットは大きいと考えました。

MVPで考える

ご存知の方も多いと思いますが、MVPとはMinimum Viable Product の略称です。実験を実行するのに最低限必要な機能を備えた製品、という意味です。
有名なのは以下の記事です（画像を引用させていただきました）。

新しいサービスを作る、新しい機能をつくる際に、最初から理想を作ろうと思いがちです。となると顧客への価値提供は遅れてしまうし、もしそれが顧客に価値と見なされないなら、利用されないものをずっと作り続けることになる。だからこそMVPです。

じゃあこのMVPを考えるときの最低限とはどのようにジャッジしていくのか。狩野モデルで考えてきました。

• 届ける顧客ターゲットを決める
  • どんなジョブを抱えている人たちに届けるかを決める
• 今考えている価値を定義し、それを実現するストーリーとそれに合わせた機能を洗い出す
• その機能を狩野モデルで品質の定義をする
• 最初の開発スコープでは、何を着手するのか決める

ターゲットも都度変わりますし、最初に設定する品質も変わってきますが、「どう考えるか」をプロジェクトメンバーで揃えておくと迷いなく進めることが出来ます。また、万が一迷ってもゼロ地点（戻れる場所）があると認識を揃えやすくなります。

アウトカムを定義する

機能をリリースししたら、価値が提供出来た！と考えていまいがちです。ビジネス職としても、一緒に進めてきた機能がリリースされることはとても感慨深いです。

ただしここで忘れてはいけないのが、リリースしただけでは顧客は価値を感じていない、ということです。価値そのものに集中するのではなくリリースに集中してしまうこと、これがいわゆるビルドトラップです。
ビルドトラップについては、以下の本に詳細が記載されています。

そうならないためにも、必ず以下を実施しています。

• この機能やプロジェクトを通してどんな成果を掴むのかを、キックオフ時に決める
• リリース後、継続的に検証可能な環境を用意する

正直必ずしもすべての機能が効果的だったとは言えません。マーケティングやセールスを含め取り組むべきことをやったとしても、価値が届かないこともあります。その場合はその機能を落とすことも検討しなければいけません。

これまで費やしたコストなどを考えると本当に辛く、サンクコスト効果を感じてしまいます。が、あくまでも目的はアウトカムを掴むことです。今あるアウトプットに固執する必要はありません。反省しつつアウトカムに執着していくことが求められます。

主導したプロジェクトだと本当に申し訳ない気持ちと悔しい気持ちが残りますが、切り替えて次に進んでいくことも協働するのに必要だと学びました。

最後に

拙いですが、これまで取り組んできたことを記載しました。まだまだ改善の余地はありますし、記載している内容も完璧ではありません。引き続き精進していきます！

ビジネス側よりもエンジニアはどんな気持ちで取り組んでるの？ときになった方もいらっしゃるかもしれません。
現在Qiita株式会社では、採用文脈ではないカジュアル面談を開催中です！もし気になる方がいらっしゃれば、ぜひ弊社エンジニアと面談してみてください。