書きやすくコードも埋め込めるMarkdown記法で手軽に情報共有。開発効率アップと作業ストレス減
株式会社メディアドゥ

国内最大手の電子書籍取次企業である株式会社メディアドゥさんでは技術部門での情報共有にQiita:Teamを導入されています。
どういった経緯や意図でQiita:Teamを導入し、どのように使われているのか。エンジニアチームならではのお話をしていただきました。

会社概要:https://www.mediado.jp/

インタビューいただいたみなさま

坂井健治(さかいけんじ)Kenji Sakai
技術本部 VP of Engineering
濱口賢人(はまぐち けんと)Kento Hamaguchi
技術本部 エンジニア
室岡直紀(むろおか なおき) Naoki Murooka
技術本部 エンジニア

導入前の課題

「必要な情報がどこにもない」の改善を目指して

ーーQiita:Team

早速ですが、Qiita:Teamを導入された経緯について教えてください。

ーー濱口

私たちはもともと少ない社員でフェイス・トゥ・フェイスだけで情報共有を行なっていました。しかし、組織の拡大、ひいてはシステムの統合が必要となるような複数人が関わる中〜大規模の開発をするフェーズに入り、そのような経緯の中で情報共有のやり方が整っていなかった。という状況がまずありました。

ーー坂井

その当時は、情報が集約されておらず、共有されるべき情報が全てそれぞれの頭の中にあるという状態だったんです。私は弊社に転職する前に社員間の情報共有としてWikiやDispatcher Phoenixを使用していたので、その経験をベースにコラボレーションツールの選定をはじめました。

情報が集約されておらず、共有されるべき情報が散逸していた(坂井氏)
ーーQiita:Team

メディアドゥさんでもまずはWikiやDispatcher Phoenixを導入されたのですか?

ーー坂井

いいえ、これまでの経験からそれらも課題があると感じていたので、それに近い有償のものをということで最初はConfluenceを試用してみました。ただこちらも入れてはみたものの利用にあたって学習コストが予想よりかかりそうだったのと、運用にはそれなりの体制や定期的にアップデートしていくフローが必要ということも分かりました。弊社の技術部門は50名以上いるので、学習コストや運用コストがネックとなり導入を見送りました。

その他のサービスも一通り見てみたのですが、最終的に「気軽に情報を上げてもらえるものを」ということでQiita:Teamを導入することになりました。

ーー室岡

その他のナレッジツールも使っていたのですが、Qiita:Teamの方がUIなどの使い勝手がいいので現在、情報共有はQiita:Teamに一本化しています。

ーー坂井

弊社の現在の導入ツールは、タスク管理にJira、コミュニケーションは全社的にSlack、技術部門の情報共有はQiita:Teamという感じですね。

ーー室岡

もともとオープンにサービスが提供されているQiitaのユーザーが多かったようで、Qiita:Teamの導入はスムーズでした。

導入におけるポイント

ルールは設けず「まずは知識をアウトプット」を優先

ーーQiita:Team

情報共有に特化してQiita:Teamをご利用されているということですが、運用にあたってルールなどは設定されたのでしょうか? たとえば3日に1回は何か書き込みするようにとか、日報をQiita:Teamにアップするようにとか。

ーー坂井

いいえ、特に設定はしませんでした。最初期に日報をやってみたのですがイヤだという声もあってすぐにやめ、いまは書き込み頻度や内容に関するルールは設けていない状態です。

ーーQiita:Team

では全く書かない、使わないという人もいたりするんでしょうか?

ーー坂井

ゼロではないですね。でもそれを咎めたりはしていません。Qiita:Team上に整理された情報だけを集めたいというよりは、まずは情報をどんどんアウトプットしてもらえるようにしました全くアウトプットしない人が初めてアウトプットするという場にしたかったんです。

アウトプットしたことない人が初めてアウトプットする場にしたかったと語る坂井氏

そのためには、まずはそれに適した「場所」が必要ですよね。Slackだけ導入してもそこで技術について書くか? と言われればみんな書かないじゃないですか。だからまずは自由に情報共有できる場があることが大事だと考えていて、Qiita:Teamはそういう意図で導入しました。

Qiita:Teamに情報をアウトプットするということは、必ず他人に見られるので読み手を意識する必要があります。そのためアウトプットする過程でその人自身が物事を深く考えるようになれば、という期待もありました。

ーーQiita:Team

実際にQiita:Teamに記事を書く立場として、工夫されたことはありますか?

ーー室岡

私は普段からQiitaやブログに技術関連の記事を投稿しているので、記事を書くことには抵抗はありませんでした。ただ、チームとしては最初はなかなかみんな書きたがらないので、まずは自分が率先して書いて投稿するように意識的にやっていましたね。

ーーQiita:Team

無理強いしてルールを設けたり仕掛けたりするのではなく、積極的なアクションを引き出すというスタンスですね。

ーー室岡

普段そういった記事を書かないメンバーからすると「業務内容について書かなければいけない」「間違った内容を書いてはいけない」など、制約をつけると1記事書くのに何時間もかかってしまうんですよね。

ですので「間違ってもいいので、みんなでキャッチアップしてブラッシュアップして、最終的に正しい情報が残ればいいよね」というスタンスにしています。雑多な内容でもいいからまずは書く、アウトプットしてみる、というマインドを少しずつ浸透させていった感じです。

最終的に正しい情報が残ればいい。アウトプットしてみるというマインドを少しずつ浸透させていった(室岡氏)

導入におけるメリット

Markdown記法でコードが書けるメリット

ーーQiita:Team

それでは最後の質問です。気軽に記事が書ける点やUI、Qiitaで慣れている人が多いことなど、いくつかの点でQiita:Teamがよかったということはご説明いただきましたが、実際に導入してみ感じているメリットはどんなところになりますか?

ーー室岡

Markdown記法で書けるという点は大きいと思います。Markdownなら学習コストは必要ないですからね。気軽に投稿できて、仰々しくないですよね、Qiita:Teamって。

いまではプログラミングに関する記事だけでなく、オフィス周辺のおすすめランチスポット情報など、みんな自由に投稿しています。いいね!が多くつくのは、そういった業務に直接的な関係のない記事の方だったりします。それ以外だとロジカルシンキングについて、社内の働き方改善プロジェクトについて、あとはイベントレポートなんかも人気です。

ーー濱口

Markdown記法でプログラムのコードを直接載せられるという点が強みと感じています。そうでない場合、要件を詰めてさあ開発という段になって初めて実際のコードが出てきて「こんなはずじゃなかった」となることがありますが、実際のコード設計のイメージを早い段階から記事としてアウトプットしていくことで開発効率が上がりますし、作業ストレスも減らせます。

Markdownが使えることがエンジニアチームにとっては強みがあった(濱口氏)
ーーQiita:Team

広く使っていただけるツールではありますが、やはりエンジニアの方にとっての使い勝手は特に大きな長所だということですね。ありがとうございました。

PRエリア

Media Do Tech Do Blog
https://techdo.mediado.jp/

取材にご協力いただいたエンジニアチームのみなさん

<原稿構成 石島英和、編集 佐伯幸治>

生産性が向上するノウハウ集をプレゼント!

Qiita:Team導入ガイド(無料)

500チーム以上で利用されている情報共有ツール「Qiita:Team」の基本機能から生産性を向上させるためのノウハウを1つの資料にまとめました。
資料ダウンロード(無料)

導入事例

300人のエンジニア組織を横断したQiita:Teamの活用術とは!?
サイバーエージェントのゲーム&エンターテイメント事業部 のみなさま
情報発信する文化の根付かせ方がすごい!
株式会社リクルートジョブズ のみなさま