国内最大手の電子書籍取次企業である株式会社メディアドゥさんでは技術部門での情報共有にQiita Teamを導入されています。
どういった経緯や意図でQiita Teamを導入し、どのように使われているのか。エンジニアチームならではのお話をしていただきました。
インタビューいただいたみなさま
坂井健治（さかいけんじ）Kenji Sakai
技術本部 VP of Engineering
濱口賢人（はまぐち けんと）Kento Hamaguchi
技術本部 エンジニア
室岡直紀（むろおか なおき） Naoki Murooka
技術本部 エンジニア
導入前の課題
「必要な情報がどこにもない」の改善を目指して
早速ですが、Qiita Teamを導入された経緯について教えてください。
私たちはもともと少ない社員でフェイス・トゥ・フェイスだけで情報共有を行なっていました。しかし、組織の拡大、ひいてはシステムの統合が必要となるような複数人が関わる中〜大規模の開発をするフェーズに入り、そのような経緯の中で情報共有のやり方が整っていなかった。という状況がまずありました。
その当時は、情報が集約されておらず、共有されるべき情報が全てそれぞれの頭の中にあるという状態だったんです。私は弊社に転職する前に社員間の情報共有としてWikiやDispatcher Phoenixを使用していたので、その経験をベースにコラボレーションツールの選定をはじめました。
メディアドゥさんでもまずはWikiやDispatcher Phoenixを導入されたのですか？
いいえ、これまでの経験からそれらも課題があると感じていたので、それに近い有償のものをということで最初はConfluenceを試用してみました。ただこちらも入れてはみたものの利用にあたって学習コストが予想よりかかりそうだったのと、運用にはそれなりの体制や定期的にアップデートしていくフローが必要ということも分かりました。弊社の技術部門は50名以上いるので、学習コストや運用コストがネックとなり導入を見送りました。
その他のサービスも一通り見てみたのですが、最終的に「気軽に情報を上げてもらえるものを」ということでQiita Teamを導入することになりました。
その他のナレッジツールも使っていたのですが、Qiita Teamの方がUIなどの使い勝手がいいので現在、情報共有はQiita Teamに一本化しています。
弊社の現在の導入ツールは、タスク管理にJira、コミュニケーションは全社的にSlack、技術部門の情報共有はQiita Teamという感じですね。
もともとオープンにサービスが提供されているQiitaのユーザーが多かったようで、Qiita Teamの導入はスムーズでした。
導入におけるポイント
ルールは設けず「まずは知識をアウトプット」を優先
情報共有に特化してQiita Teamをご利用されているということですが、運用にあたってルールなどは設定されたのでしょうか？ たとえば3日に1回は何か書き込みするようにとか、日報をQiita Teamにアップするようにとか。
いいえ、特に設定はしませんでした。最初期に日報をやってみたのですがイヤだという声もあってすぐにやめ、いまは書き込み頻度や内容に関するルールは設けていない状態です。
では全く書かない、使わないという人もいたりするんでしょうか？
ゼロではないですね。でもそれを咎めたりはしていません。Qiita Team上に整理された情報だけを集めたいというよりは、まずは情報をどんどんアウトプットしてもらえるようにしました。全くアウトプットしない人が初めてアウトプットするという場にしたかったんです。
そのためには、まずはそれに適した「場所」が必要ですよね。Slackだけ導入してもそこで技術について書くか？ と言われればみんな書かないじゃないですか。だからまずは自由に情報共有できる場があることが大事だと考えていて、Qiita Teamはそういう意図で導入しました。
Qiita Teamに情報をアウトプットするということは、必ず他人に見られるので読み手を意識する必要があります。そのためアウトプットする過程でその人自身が物事を深く考えるようになれば、という期待もありました。
実際にQiita Teamに記事を書く立場として、工夫されたことはありますか？
私は普段からQiitaやブログに技術関連の記事を投稿しているので、記事を書くことには抵抗はありませんでした。ただ、チームとしては最初はなかなかみんな書きたがらないので、まずは自分が率先して書いて投稿するように意識的にやっていましたね。
無理強いしてルールを設けたり仕掛けたりするのではなく、積極的なアクションを引き出すというスタンスですね。
普段そういった記事を書かないメンバーからすると「業務内容について書かなければいけない」「間違った内容を書いてはいけない」など、制約をつけると1記事書くのに何時間もかかってしまうんですよね。
ですので「間違ってもいいので、みんなでキャッチアップしてブラッシュアップして、最終的に正しい情報が残ればいいよね」というスタンスにしています。雑多な内容でもいいからまずは書く、アウトプットしてみる、というマインドを少しずつ浸透させていった感じです。
導入におけるメリット
Markdown記法でコードが書けるメリット
それでは最後の質問です。気軽に記事が書ける点やUI、Qiitaで慣れている人が多いことなど、いくつかの点でQiita Teamがよかったということはご説明いただきましたが、実際に導入してみ感じているメリットはどんなところになりますか？
Markdown記法で書けるという点は大きいと思います。Markdownなら学習コストは必要ないですからね。気軽に投稿できて、仰々しくないですよね、Qiita Teamって。
いまではプログラミングに関する記事だけでなく、オフィス周辺のおすすめランチスポット情報など、みんな自由に投稿しています。いいね！が多くつくのは、そういった業務に直接的な関係のない記事の方だったりします。それ以外だとロジカルシンキングについて、社内の働き方改善プロジェクトについて、あとはイベントレポートなんかも人気です。
Markdown記法でプログラムのコードを直接載せられるという点が強みと感じています。そうでない場合、要件を詰めてさあ開発という段になって初めて実際のコードが出てきて「こんなはずじゃなかった」となることがありますが、実際のコード設計のイメージを早い段階から記事としてアウトプットしていくことで開発効率が上がりますし、作業ストレスも減らせます。
広く使っていただけるツールではありますが、やはりエンジニアの方にとっての使い勝手は特に大きな長所だということですね。ありがとうございました。
PRエリア
Media Do Tech Do Blog
https://techdo.mediado.jp/
