読者です 読者をやめる 読者になる 読者になる

Connehito開発者ブログ

Connehito Engineer's Blog

スタートアップ入社1ヶ月で実践した「低コストでデキる!開発を加速させる情報共有」の始め方

f:id:fortkle:20141210080057j:plain

こんにちは!今月12月から中途入社したエンジニアの高野フォートクル (@fortkle) です。

今日は、私が入社して実践した情報共有に関する取り組みのうち、効果があったものを「『低コストでデキる!開発を加速させる情報共有』の始め方」と題して共有したいと思います。

tl;dr

  • 関係者全員が情報共有ツールを使える環境を整える
  • 「この1ページだけ見ればOK」という情報の集約場所を作る
  • slackの分報でそのページの質をチェックし、足りない部分を更新してメンテナンスする

Connehitoの状況

まずは私が入社した直後のConnehitoの状況を列挙します。

人数 CTO 1名 + 開発者(エンジニア・デザイナー) 3名
ドキュメント GithubのPRに詳しく仕様は書かれているが、ドキュメントとしてまとめていない
情報共有
ツール
Slack, Docbase(あまり活発には使われていない, 全員分のアカウントがない)

当時は人数も少なく、1つのプロダクトにつき担当者が1~2名だったので、自分自身が知っていれば全く問題がありませんでした。つまり、情報共有の必要性が低かったのです。

また、スタートアップのため完璧なドキュメント作成はしない意思決定をしており、ユーザーに価値のあるサービスの提供を優先して日々の開発業務を進めていました。

これから発生が予想される問題

Connehitoが運営しているママリママリQは、いま物凄いスピードで成長をしており、やりたい施策も日々増えてきています。それに伴って開発者が増えていくことは容易に想像できますが、現状の情報共有のままでは今の開発スピードを維持したまま開発チームをスケールさせることが難しくなる事が予想されます。

具体的には下記のような問題が発生する可能性があります。

  • 会社の 開発フローや開発文化を理解 するのに 時間がかかる
  • 既に効率化された方法があるのに 共有されなかったせい無駄な時間 を使ってしまう
  • 新しく入ってきた人が、 「なぜ」 現在の実装・設計になっているか理解できない  

「開発を加速させる情報共有」の始め方

上記の問題に対して、あまりコストを掛けずに効果のある施策をできないか考えた結果、下記取り組みを実施し効果がありました。順を追って説明します。

1. 情報共有のための環境を整える

チャットツールがいかに有用か、という話は他の記事に譲るとして情報共有ツールを使うことは非常に重要です(ここでいう情報共有ツールというのは、Qiita:Teamやesa.io、Docbase等のブログとWikiを組み合わせた様なツールをイメージしています)。

Connehitoでは以前からDocbaseを使っていたものの、契約プランの関係で全員にアカウントを発行することができていませんでした。

情報共有ツールは一部で導入しても効果が出にくいので、私が入社して数日経ったタイミングでCTOに相談し、 開発者全員分のアカウントを発行できるプランまでアップグレード してもらいました。
 
~余談~
情報共有のもたらすメリットから考えると月額数千円は低コストだと思いますが、このあたりの交渉が難しいこともあると 思います。その場合は私も参加している「情報会議」という情報共有のコミュニティで話し合いがされているので、ぜひそちらの情報を御覧ください。

さて、こうしてConnehitoでは開発者全員がslackとDocbaseを使えるという環境が整いました。

2. 「この1ページだけ見ればOK」という情報の集約場所を作る

言葉より先に見てもらったほうが早いと思うのでまずはご覧ください。

f:id:fortkle:20151224155818p:plain

こちらはDocbaseに用意した、いわば「Connehito開発まとめページ」です。

開発に関するドキュメントや日々の業務で使っているツールなど、入社時に知っておきたい情報を全て網羅する目的で作成されています。 またそれだけでなく、日々の開発で使いそうな便利なリンク集やテスト用アカウントの共有などにも活用されています。

このページの良い所は 既存の資産を活用できる点です。

例えば、Connehitoではコードレビューを投資と捉え、時間をかけてしっかりと行っているため、Github上で行ったPR/コードレビュー周りの情報がそのままドキュメントとして有用なケースが多くあります。

新たに仕様書を作成するのではなく、このまとめページからGithubのPRに「仕様書/設計書」としてリンクを貼ることで、新しく入ってきたエンジニアが「PRに仕様が書いてないか検索してみよう」と思う状態を作り出すことができます。

新しく入社した開発者はこのページを一通り見ることで、頭のなかにConnehitoでの開発に関する情報の「インデックス」を作ることができるのです。

3. "分報"を活用して、情報共有を促し、陳腐化を防ぐ!

"分報"という手法をご存知でしょうか?少し前にバズっていた下記記事に詳細が書かれています。

c16e.com

私が入社してお試しで導入してみたところ、記事にあるように「10分以内に課題が解決できる」や「個人の学びが自然とチームに広まる」など効果を感じることができました。また、記事とは別にもう1つ効果がありました。

それは、「まとめページの質をチェックすることができる」 点です。

新しく入ってきた人は、個人の分報チャンネルを渡され、まとめページの「はじめての方へ」の項目をこなしていきます。当然、ドキュメントは書かれた瞬間から古くなっていくので、項目通りに進めていて問題が発生することがあります。

経験的にこういったとき、これまではたとえ問題が発生していたとしてもそのまま放置されることが多かったのですが、分報を導入することで作業が見える化され、「質問するほどではないけど詰まったところ・違和感を感じたところ」が共有されるようになりました。

その結果として、「○○さん、その詰まったところの更新おねがい!」とか「△△の記述が足りなかったので追記しておきました!」といったやり取りが行われるようになりました。

これで、低コストでドキュメントが陳腐化することをある程度防ぐことができるようになりました。

まとめ

「ドキュメントを残す」という作業はたしかに重要ではあるものの、そのコストは意外と大きなものです。特にスピード感を持ってフットワーク軽く進んでいかないといけないスタートアップにとって、その作成コストはある意味、死に直結する可能性もあり、無視できないものです。

一方で、成長途中のスタートアップにとって組織の拡大と情報共有の課題は解決すべき問題です。今回はそういったスタートアップでも出来る低コストかつ効果のある手法の1つだと思います。

同じような問題を抱えている方はぜひ試してみてください!


「わたしはこんなやり方でやってましたー!」というアツイ情報共有トークをしたい方はぜひ一緒にランチでも行きましょう!お待ちしております!