エンジニアを最高に幸せにする、Incrementsのサービス「Qiita」「Qiita:Team」の開発・運用現場
DevOps Hubでは、DevOpsを実践している企業のインタビューをお届けしています。第4回は、Increments株式会社が提供するサービス「Qiita」「Qiita:Team」の開発と運用について、お話を伺います。
(写真:Increments株式会社 エンジニア 荻原一平氏)
Increments株式会社は、2012年 東京に設立。プログラミングに特化したオープンな情報共有コミュニティ「Qiita」、社内向け情報共有サービス「Qiita:Team」の企画・開発・運営を行っています。
エンジニア全員が、開発と運用を分け隔てなく対応
──荻原さんが、担当されている業務について教えてください。
荻原:主に、Qiita:Teamの開発とインフラを担当しております。弊社全体のインフラの運用も担当しています。
──エンジニアのチームは、どのような構成なのですか。
荻原:エンジニアは、開発と運用でチームを分けておらず、全員が開発と運用の両方を見ています。比較的小人数で、プロダクトもそこまで多い訳ではありませんので、メンバーが密接に関わって一緒に議論しながら進めていますね。
──開発と運用を分け隔てなく対応しているとのことですが、貴社の中でDevOpsの定義はありますか。
荻原:弊社として、特に定義はありません。「これがDevOpsだ」ですとか「DevOpsをしている」という認識はないのですが、アプリケーションは開発してレビューしたら、すぐにデプロイするという、ショートスパンでの開発と継続的なデプロイを行っています。ですので、実際はDevOpsを行っていることには、なっているかなと思います。
──ショートスパンで開発をするために、いつ頃からどのような取り組みをされていたのですか。
荻原:私が入社する前なのですが、2013 年頃からインフラ構成をコードで管理しています。きっかけは、なぜかデザイナーが使っている Mac の開発環境がしょっちゅう壊れていたので、開発者の開発環境を boxen を使って管理し始めたことでした。
そして、2013年の年末に、Chefのcookbookを書いて、プロダクションのインフラ管理をし始めました。インフラを手作業で構築していて煩雑だったので改善したいと考えていたところ、伊藤直也さんの 「入門Chef Solo」が出版されて、業界でも DevOpsが話題になっていましたので、その波に乗りたいと思って始めたようですね。
2014 年の後半には、DevOps の派生で ChatOpsが流行ってきましたので、 Qiita も Chatからデプロイできるようにしました。
──業界のトレンドを取り入れながら、新しい取り組みを積み重ねているのですね。荻原様が開発チームにジョインされた時に、これは便利だと思った仕組みは、ありますでしょうか。
荻原:私が半年前に中途入社した時に助かったのが、運用やインフラに関わる部分は、概ねコードとしてGitHub上で管理されていることでした。実際に動いているものが定義されていることで、作った人の意図をちゃんと把握して、適切にメンテナンスしていくことができます。組織変更に対応したり、フルリモートで働く社員と業務を行う上でも、暗黙知ではなく、コード化されていることは重要だと思いますね。
開発を効率化することで、変更に強いシステムに
──現状はどういったツールを活用されているのでしょうか。
荻原:今では、自動的にデプロイできる仕組みができ上がっています。GitHubでコード管理・ビルドして、テストは Circle CIで自動化しています。その上で、Terraformでインフラのコード化を行って、Circle CI で変更を適用していますね。
──コミュニケーションツールも活用されているのでしょうか。
荻原:Qiita:Team、GitHub、ZenHub 、Slackを使い分けています。
──複数のツールを、どういった用途で使い分けているのですか。
荻原:Qiita:Teamには、日報や実施したことの周知。読み返すべき情報や記事を蓄積しています。
GitHubは、コードのリポジトリ、イシューでのタスク管理、プルリクエストでレビューしてマージするGitHub Flowで運用しています。
ZenHubも導入して、タスクをカンバンに並べたり、EpicでまとめたりとGitHubでのタスク管理を強化しています。
Slackはアラート、連絡ツールや、リモートの人とテレビ会議に利用しています。新規の投稿がフィードで流れてくるのでSlackを見ていれば、今何が起きているのか、すぐに分かるようになっていますね。
──緊急時にアラートが飛ぶようなモニタリングの仕組みはあるのでしょうか。
荻原:DataDogでシステムを監視していて、問題があった時にはPagerDutyで電話がかかってくるようになっています。
DataDogはAWS等のサービスとの連携を有効にし、インスタンスにエージェントを入れて各種モニタリングをしています。たとえば、AWSでロードバランサーにエラーが多く出ている場合や、何か問題があってbotでのデプロイに失敗した場合にアラートが上がってくるので、確認していますね。
アプリケーションは、Sentryでモニタリングして、エラーを検知できるようにしています。
──様々なツールを駆使して、監視しているのですね。貴社ではアジャイル的な文化は、浸透しているのでしょうか。
荻原:はい、スクラムを取り入れています。「Qiita」の開発メンバーは、リモートメンバーを交えて毎日昼会で進捗確認、毎週リーダーと対話をしながら進めていています。
「Qiita:Team」の開発メンバーは、スクラム開発を行っています。お客さまからいただいた課題やご要望から、新規のお客さまに使っていただくための機能、エンジニアに刺さる機能まで、リリースしていきたい機能がたくさん上がってきますので、QAをしっかり回して、プロダクトオーナーが優先順位を決めて実装しています。
──「Qiita」では、ユーザーからのフィードバックはどのように受けていますか。
荻原:「Qiita」では、お問い合わせフォームでユーザーさまからのご意見を受け付けております。フィードバックを元に開発を進めている機能もありまして、現在は、新しいトップページのベータサービスをオプトインで提供しています。チームで議論をしてサービスを作っているのですが、ユーザーさまから色々なご意見をいただくことで、発見できることがたくさんあります。サービスを利用されている方は、エンジニアの方がほとんどですので、非常に建設的なご意見をいただけて、助かっていますね。
──開発を効率化していくことで、どのような効果が得られましたか。
荻原:今は、開発者がレビューを終えてマスターにマージした後、botに呼びかけると勝手にデプロイされるようになっていますので、テストも回して、一日数回デプロイが継続的に行われているみたいなことができています。それによって、頻繁にアップデートができますし、何か問題があれば元に戻すことがしやすい、つまり変更に強いシステムにすることができました。
Qiita、Qiita:Teamで、エンジニアのコミュニケーションをより活発に
──開発を進めていく上で課題はありますか。
荻原:一日数回のリリースができている分、テストに時間がかかるようになったことですかね。加えて、サービスの規模が大きくなるとテストの時間が増えてしまうので、短縮できるよう頑張っているのですが、一回のテストに30分ほどかっているので、もう数分くらいは落としたいです。
あとは、インフラの作業はアラートが飛んでくるとやっている作業を中断して対応するのですが、それに時間を取られてしまうことです。何も起こらなければよいのですが、何か問題があった時は、丸々一週間かかってしまうことがあります。少なくとも同じ問題を再発させたくないので、原因を調査したり、対応をするのに時間がかかってしまうんですよね。
──都度再発しないように、対応されているのは、素晴らしいと思います。次に問題点が出てきたとしても、システムとしてはどんどん成熟していきますね。
荻原:大きくシステムを変えていくことはもちろん良いことですが、少しずつ良くしていくことはサービスの価値を高めていく上で、非常に大事だと思います。CI/CD をさらに高速化するなど、開発、サービス改善のスピードをさらに早くできるようにしていきたいです。
──今後のQiita、Qiita:Teamの展望を教えてください。
荻原:弊社は、「エンジニアを最高に幸せにする」ことをミッションとして、ユーザーさまが、Qiita、Qiita:Team を通じて情報共有をすることで、より便利に、コミュニケーションが活発になるようにしていきたいと考えています。
具体的には、Qiitaで蓄積している投稿データや、利用データのリアルタイム分析や人工知能での解析を進めています。おすすめ記事や関連記事を表示したり、検索機能を向上したりすることで、ユーザーの皆さまが欲しい情報、適切な記事を、素早く調べられるようにしていきたいです。
開発と運用を理解されているIncrementsさまだからこそ、エンジニア視点で便利なサービスを提供できるのだなと思いました。お話しいただき、ありがとうございました!
- 関連キーワード:
- GitHub Enterprise
- Slack
- インタビュー
DevOps Hubのアカウントをフォローして
更新情報を受け取る
-
Like on Facebook
-
Like on Feedly