• 株式会社MUGENUP
  • 代表取締役
  • 伊藤 勝悟

エンジニアも営業も!ユーザー体験を「全員で」考え抜くための、ITツール活用法

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

今回のソリューション:【Cacoo/カクー】

少人数のチームでWebサービスを開発・運用する場合、チーム内での役割分担はどこまで必要だろうか? イラスト制作を展開する株式会社MUGENUPは、2015年5月にプロジェクト管理ツール「Save Point」を正式リリースした。現在はエンジニア、デザイナー、そして営業から成る6名のチームで、サービスの成長へ向けてまい進している。

同社の代表取締役である伊藤 勝悟さんは、少人数だからこそ「チーム全員が情報を共有し、プロダクトを通じて実現したいことを考える」ことが大切だと語る。

実際にSave Pointのチームでは、ビジネスサイドも含めて全員でタスク管理ツール「Pivotal Tracker(ピボタルトラッカー)」を活用して個人の業務を可視化している。更に、ワイヤーフレーム作成ツール「Cacoo(カクー)」を営業も含めて全員が使うことで、ユーザー体験を深堀りするための土台を作成しているのだという。

伊藤さんに、具体的なチームでの業務の進め方についてお伺いした。

大学院在学中にMUGENUPを立ち上げ

大学院に入学した2011年に、創業メンバーの1人としてMUGENUPを立ち上げました。そこから2年ほどはずっと1人でエンジニアとして開発をしていたのですが、一番最初はソーシャルギフティングのサービスを運用していました。

それなりに色々なメディアやイベントでも取り上げていただいたのですが、マネタイズの部分が難しくて。結局半年でサービスを閉じることになりました。

その後は当時流行っていたソーシャルゲームの開発を行っていたのですが、その中でイラスト制作の領域における課題とニーズに気が付いたんですね。そういった経緯で、現在のサービスにシフトしていきました。

ずっとCTOとしてエンジニアチームのマネジメントをしてきましたが、2015年8月より、代表取締役を務めさせていただいております。

「技術を上げることがカッコいい!」という組織を作る

弊社が2人目のエンジニアを採用したのは2013年2月のことです。ずっと1人で大変でしたが、気合と根性で全て乗り切ってきた感じですね!辛いこともありましたが、何もないところから始めたので楽しかったですよ。

現在、エンジニアは私を含めると4名体制です。私自身は開発で手を動かすというよりはレビューをしたり、ビジネスサイドとの橋渡しのような役割をしています。

残りのメンバーのうち2名は、2015年5月に正式リリースした、イラスト制作に特化したプロジェクト管理ツール「Save Point」の開発を行い、もう1名はその原型になった「Work Station」という社内システムに携わっています。

エンジニアを採用していくにあたり、元々の私の考え方の中には「最初の5人まではこの会社の基盤になる人間だ」という意識があります。自分の中で本当に納得できる人でなければ、採用しないことにしているんです。

現時点での技術レベルも大事ですが、それ以上に「エンジニアとして生きていくことを決めている人か」ということを重視しています。

エンジニアという職種自体にわりと「人種」的な要素があると思っていて。休みの日であっても情報収集をしていて、技術を磨くことが生活の一部になっているような人が良いですね。エンジニアとして上を目指していくこと自体がカッコいい、という組織文化を作りたいと考えています。

少人数だからこそ効率化、そして記録を残すことを意識

特にエンジニアはまだ非常に少人数なので、一番価値を生むところに人の時間を割く仕組みを作るということは常に考えています。お金を払ってツールを導入することで効率化できることは、できるだけそうしていきたいという意識がありますね。

例えばテストはCircleCIを使って自動化しています。ローカル環境では修正点と関係ある部分のみテストを実行し、残りのテストはGitHubにpushしたタイミングで、自動的にCircleCI上で実行されるようになっています。

ローカルで全てのテストを実行してしまうと数十分はCPUを全部使ってしまうので、効率が悪いんですね。

CircleCIでテストを実行している間にPull Requstの内容を書くようにすると効率的です。そしてテストが通ったかどうかもGitHub上で判断できるので、問題なければそのままデプロイします。

他にも気にかけているのは、将来人が増えた時にわかりやすいように、コードをメンテナンスのしやすい状態にしておくことです。rubocopというRubyの静的解析ツールを使い、コードを保存した瞬間にコーディング規約に準拠しているかどうかが自動でチェックされるようにしています。

コードって一度書いたらずっと残るわけじゃないですか。だからこそ、後で何も知らない人が見てもわかるようにしておくことが大切だと思っています。「なぜここに至ったか」ということがコードだけでは判断できない場合には、必ずコメントを残すようにしています。

更にこのようにコード上に貯まらない部分に関しては、情報共有ツールのQiita:Teamに記録を残すようにしています。

チーム全員でPivotal Trackerを使って情報共有

Save Pointのチームは6名体制です。エンジニアが2名、デザイナーが2名、リーダー兼営業が1名、CSが1名になります。実は弊社では、開発系のツール同士をあまりがっつり連携させていません。

その理由の1つとして、情報をエンジニアだけで完結させずにビジネスサイドとも共有したいと考えていることがあります。

開発ツール全てを連携させてしまうと、エンジニア側の結合が密になりすぎて自由にできない部分もあるので…。まだ少人数ですし、できるだけプロダクトチーム全員で色々な情報を共有することを心がけています。

例えばタスク管理については、チーム全員でPivotal Trackerを使っています。機能開発まわりのToDoは全てここにまとめていて、その進捗を日々、全員が確認しています。

誰が何を今しているのか、という個々の活動を可視化するためにも、全員でPivotal Trackerを使っているんですね。また日々の細かい気付きなども、まだ優先順位付けされていないタスクを入れる「icebox」に全員がバンバン投稿していくようにしています。

▼チーム全員で活用中のタスク管理ツール「Pivotal Tracker」

ITツールが苦手でも大丈夫!直感的に図が描ける「Cacoo」

もう1つ、チーム全員がアカウントを持って活用しているのがCacooです。Cacooは主にワイヤーフレームを作成するためのツールですが、弊社では営業も含めて「図を作りたい」時に使っています。結局、図にしたいというニーズを突き詰めるとワイヤーフレームなんですよね。

他のツールでも図は描けますが、例えばPowerPointの場合だとMacの人は入っていない場合もありますし。Excelでがんばって作ることもできますが、ちょっとだるい(笑)。

Cacooはブラウザベースで作業が可能で、非常に直感的に扱えるので、ITツールにあまり強くない人でも問題なく使うことができます。

手書きで紙に描く感覚で図を作って、それをデジタル化して残していくことができるイメージです。更に作成したデータは、URLを送るだけで簡単に共有することができます。

▼ワイヤーフレームを簡単に作成できる「Cacoo」

元々は、エンジニアがインフラ側のアーキテクチャーを考えるために使い始めたんです。

インフラは色々なものが結合していってわけがわからなくなってしまいがちなので、「整理して書き出してみよう!」ということで始めました。それがだんだん拡大していって、今では全員が使うようになったんです。

ユーザーの具体的なプロダクト体験を考えることが重要

Cacooを良く使うケースには、例えばクライアント様の業務フローの分析があります。そもそも自分たちが誰のどんな課題を解決しようとしてサービスを作っているのか、ということを全員がきちんとわかっている必要があります。

そのためにはまず、ユーザーのことを深く理解する必要があるので、そのための情報共有や、ディスカッションするための下地として、Cacooで作成した図を使っています。

▼実際にCacooで作成したクライアントの業務フロー分析図

そもそもクリエイティブの業務ってどういうことをやっているんだろう? ということから始めて、営業がヒアリングしてきた「1日の仕事の流れ」をまとめていきます。

どのフェーズで誰が何の仕事をしていて、その業務分担はどうなっているのか、ということを可視化していくと、様々なことが見えてきます。例えば「辛いと思ってる作業ってここだよね」ということがわかれば、それを楽にするための具体的なSave Pointの機能に落としていくことができます。

この作業って、プロダクト開発そのものなんですよね。だからこそ大切にしていて、定期的にこういったディスカッションをチーム全員で行うようにしています。

「プロダクトを誰に届けてどうするか」は全員で考える!

エンジニアのわかりやすいアウトプットは「コードを書いて開発する」ことです。でもSave Pointのように、初期フェーズで少人数のチームの場合には、エンジニアもそれだけではダメなんですよね。

それぞれが役割分担をするのはチームが大きくなってきた時で、今は「プロダクトを誰に届けてどうするのか」ということはチーム全員が考えるべきだと思っています。エンジニアが、チームで決めたことを実現できる開発能力を持っていることは大前提なのですが。

だからこそ弊社では、業務フローだけに留まらず、実際にSave Pointが組織の中のどこで、どんな方に使われているのか、といったことを月に1回は全員で話し合っています。 そして常に、1年後2年後の世界観も皆で出し合っているんです。今後もより多くの方にSave Pointを使っていただけるように、チームとして頑張っていきたいですね!(了)

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