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

弊社が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を使っていただけるように、チームとして頑張っていきたいですね！(了)