• 株式会社モンスター・ラボ
  • ゲーム事業部 テクノロジスト
  • 加藤 悠

1人ではQiita、組織ではQiita:Team!情報発信と共有が手軽に実現できるサービスとは

今回のソリューション:【Qiita:Team/キータチーム】

〜情報の属人化を防ぎ、情報共有を浸透させる「Qiita:Team(キータチーム)」の使い方〜

仕事をしているうちに、個人個人に蓄積されていくノウハウ。これをどのように共有し、組織の財産として蓄積していくかということに課題を抱える企業は多い。

グローバルなWEB開発を展開する株式会社モンスター・ラボでフロントエンジニアを務める加藤 悠さんは、以前より個人の情報発信の場所として「Qiita(キータ)」を活用していた。

そして現在は、平行して「Qiita:Team(キータチーム)」を組織の情報共有に活用している。同社では社員数の急激な増加に伴い「情報が散乱し属人化している」という課題を抱えていたが、今やその状況も徐々に変わりつつあるのだという。加藤さんに、詳しいお話を伺った。

日本と中国で分業してゲーム開発を行う

2014年の5月に中途採用でモンスター・ラボに入社しました。現在はゲーム事業部で、ブラウザゲームの開発・運営を行っているプロジェクトでフロントエンジニアとして働いています。

日本側はディレクター、デザイナー、プランナーなどのチームで、サーバーサイド側の実装はリモートで中国の青島(チンタオ)のチームが担当しています。両国合わせると10名ほどの開発体制になっています。

情報発信のモチベーションが持てる技術者向けサービス「Qiita」

Qiitaを個人的に使い始めたのは2年ほど前です。TwitterやFacebookで情報収集している時に、たまたまリリース記事を見つけました。

当時は日本にあまりそういったサービスはなかったので、調べ物をする時は他のエンジニアのブログや、「Stack Overflow」という海外のサイトを利用していました。Qiitaであれば日本語で検索もできますし、いいなと思って少しずつ使い始めました。

以前は自分でブログを書いていたこともあったのですが、1度止めてしまったんです。それでまたブログを開設するのも面倒だな、と思った時に、Qiitaを使えば簡単に情報発信ができると考えました。

マークダウンで書くことができて手軽ですし、コードに簡単にハイライトをつけて見やすくすることもできるので、非常に技術者に向いているサービスだと思います。

それに自分の投稿に対して他の人が「いいね」や「ストック」といったアクションを起こしてくれるので、記事を書くモチベーションを保つことができます。そこでQiitaを知ってからは、1ヶ月に1度ほどの頻度で投稿をするようになりました。

▼プログラミング知識を共有する「Qiita」

これまで、自分がプログラミングでハマった箇所やエラーの解決方法などを中心に投稿をしてきました。例えば昨年にHubot(ヒューボット)の導入記事を投稿した時は、はてブにも掲載され、50人ほどにストックもしていただけて非常に嬉しかったですね。

組織で情報共有を行うために導入したのは「Qiita:Team」

Qiitaは個人用のツールですが、組織やチームで情報共有をするためのQiita:Teamに関しても、2014年の秋頃に弊社に導入しました。最初は5名ほどの、興味があるメンバーだけで無料版をトライアル的に使っていたんですね。

その時は技術系の尖った記事が多かったこともあって、なかなか社内全体での活用には至りませんでした。それが弊社内で広まったのは、社内体制の改善やより品質の高いものを生み出すことをミッションとする「QAチーム」が立ち上がったことが大きかったと思います。

QAチームは、社内体制に危機意識を持った2人のエンジニアが立ち上げたチームです。そもそもここ半年ほどで社員数が急増し、社内に情報が散乱してどこにもまとまっていないという課題が出てきていました。

情報が属人化して、「暗黙知」のようなものが生まれてしまっていたんですね。それに対してQAチームで、もっと会社として情報をまとめて蓄積していこうということになりました。

その情報を貯める場所として、まずは既存のサービスを使ってみようということでQiita:Teamを使う人数を増やしていきました。

Qiita:Team導入で徐々に社内の状況が変わり始めた

今はまだQiita:Teamはテスト導入中ではあるのですが、少しずつ情報が蓄積されるようになってきたと実感しています。これまでのように「どこに何があるかわからない」という状況も徐々になくなってきましたね。

今は例えば、案件ごとの実績や運用のノウハウ、使っていたツールなどについての記事を投稿し、それをタグで紐付けてひとつの「プロジェクト」を立てて情報を集約しています。

「プロジェクト」別に記事の管理が可能

コメント欄も活用しています。弊社はリモートで働くメンバーが多いので、コメント欄でひとつの記事について議論することもありますね。

また、社内で使っているツールについてのTipsを投稿すると、それに対して社内の他のメンバーが「俺はこうしてる」「私はこうしています」という感じでどんどんコメントをしていって、最終的にみんなが新しい発見ができたりもしています。

エンジニアメンバー以外にも拡大する工夫を

今、Qiita:Teamを中心に使っているのはやはりエンジニアメンバーです。技術的なノウハウや問題点に対する解決策などを投稿していっています。

また、読んだ技術書や見ておくべきサイトについてのまとめを上げているので、新しい人が入社してきた時に「まずQiita:Teamのここを読めばいい」という場所ができています。

実際に作業に入る前に、技術的に必要なスキルを記事を読むことで理解してもらっている形ですね。

ただ、エンジニアだけではなく全員で使っていきたいと思っているので、一度社内のデザイナーを集めて、エンジニアに実装作業を引き継ぐための指示書をQiita:Teamで共有していこうという話をしました。

それからは議事録のようなものや、実際のデザインフローやそれに対する改善要望などもデザイナーから投稿されるようになりました。できるだけいろいろな人に使ってもらえるように工夫していきたいなと考えています。

Qiita:Team上での議論を実際のPDCAに落としていきたい

今はまだQiita:Teamをうまく活用するための方向性が見えてきたような段階ですが、情報がまとまっていない会社がそれを集約したいと考えた時に、Qiita:Teamは役立つツールだと思います。

今後はコード規約などの決まり事を1度Qiita:Teamに上げて、コメント欄で議論してブラッシュアップした上で、実際に全体に適用していくようなフローを想定しています。コメント欄で活発な議論が今もされているので、それを活かして実際のPDCAに落としこんでいくようにできるといいなと思っています。(了)

;