加藤章太朗さん
  • コラボレーター
  • SELECK(取材チーム)
  • 加藤章太朗

GitHubは誰でも使える!? 営業と開発の溝を埋める、GitHubの使い方

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

SELECKで先日公開した「『モノが悪いから売れない』とは言わせない。営業マンがGitHubを使うと組織が変わる」という記事に、おかげさまで多くの反響をいただきました!

実はSELECKチームでは、このインタビューでお伺いした「チーム全員でGitHubを使ってプロダクトを改善する」というワークフローを既に実践しています。そこで今回は、その結果をまとめたいと思います。

▼Githubの使い方についてはGithub入門の連載記事をご覧ください。

チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】

記事の要約

1.まず必要なのは、営業と開発で情報の非対称性をなくすこと

チーム全員で同じ情報を共有できていれば、価値のないアイデアが出ることはなくなる。そこでまずは、徹底した情報共有の仕組みを作ることが重要。

情報の非対称性がある中でアイデアを出し、結果出てくるアイデアがしょぼかったり、既に検討済のものだと無意味ですよね。「それはマネージャーミーティングで話している内容です」と言われてしまうと、せっかくアイデアを出した人もテンションが下がります。

2.プロダクト改善のアイデアは、「顧客の課題」ベースでGitHubにあげる

ビジネスサイドも含めて改善アイデアをGitHubにあげる。重要なのは、機能の提案ではなく「顧客が実際に困っていること」をベースにすること。そうすればセンスのないアイデアは上がってこない。

お客さんと話していてぶち当たった問題や、運用上の違和感のようなものを単純にIssueに上げていくだけなので、非エンジニアにも難しいことはなにもありません。むしろ「クライアントが困っている!」とか、「売上のためにこれが重要なんだ!」とか、気持ちを込めて書けるので(笑)。実際に困っていることがベースになるので、センスの無いIssueはほとんど出てきません。

3.全員がプロダクトマネージャーになり「プロダクトが悪いから売れない」と言わない組織に

全員で仕様を考える体制になれば、プロダクトマネージャーとしての意識が芽生える。全員がプロダクトへの責任を持つことになるので「プロダクトが悪いから売れない」という意見は出なくなり、協力してプロダクトを改善していけるようになる。

大切なのはアイデアが無視されない状況をつくることで、それによってまた次のアイデアを出そうという気持ちになることができます。このように、たとえ1%であっても改善を多く積み重ねていくことで、結果的に競争優位性を築くことにつながると考えています。

まずは全メンバーが「取り組みの意義」を理解する

SELECKチームでは、このM.T.Burnさんの取り組みが素晴らしいと感じ、一連のフローを実践してみました。

まずはチームでこの記事を読み込み「自分たちのチームにどう生かせるか?」というディスカッションをしました。

チームに新しい取り組みをいれる上で重要なのは、全員が意義を理解することだと思っています。SELECKには取材を通じて素晴らしい知見が集まってくるので、それらをなるべくチームにも取り入れるようにしています。

GitHubイシューを立てる

チーム全員がやる意味を理解したところで、早速ビジネスチームも含めてGitHubのイシューを立てはじめました。

GitHub画面

改善したいと思った人が右側のNew Issueを押し、改善のタイトルとその中身を書き込みます。

GitHub画面

イシューを立てる上で気をつけているのは、数値目標を入れることです。例えば「コンバージョンを増やしたい」というイシューをあげるときは、必ず「現状がどのくらいでどのくらいまであげたい。なぜならば〜」という形式であげるように努力しています。

もちろんすべてが目標数値に紐づくものばかりではないんですが、なるべくやろうというマインドが大切かなと思っています。

Slackに流れてくる議論に参加

イシューを立てたら、その情報がチャットツールのSlackに飛ぶようになっています。Slackで流れてきたイシューを見て、メンバーが議論に参加していきます。ただ、チャットは流れてしまうので、GitHubを見る習慣がつくまでは、何回もSlackでメンションをつけて「GitHubを見てね」という「地道な努力」が重要でした。

Slack画面

定例会議で優先度をつける

ビジネスチーム、コンテンツチーム、開発チーム、すべてのメンバーが定例会に出て、GitHubで議論をした改善項目をふくめ開発優先度をつけます。全員が参加するのは少し非効率ですが、全員がプロダクトマネージャーなので、会議に出て優先順位の決定の場にいることは重要だと感じています。

GitHubで議論をした内容やそれ以外の細かい改善要望などをスプレッドシートにまとめておき、一覧を見ながら優先順位をつけ、この1週間で開発や実行する項目を決めます。

スプレッドシート画面

開発もしくは実行して結果を見る

開発や実行した結果をGitHubイシューに追記していきます。議論をして終わるのではなく、しっかりと結果まで数値で記していき、全メンバー(プロダクトマネージャー)で確認する作業が経験値になっていくのだと思います。

GitHubイシュー画面

結果として全員がプロダクトへ責任を持つ

このような取り組みを2ヶ月ほど続けた結果、だんだんと全員がプロダクトに責任を持つような状態に近づいている気がしています。

いきなり「全員がプロダクトマネージャー」という状態になるのではなく、地道な取り組みを続けていくことで、チームのマインドが少しずつ変わっていくのだと思います。

▼Githubの使い方についてはGithub入門の連載記事をご覧ください。

チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet