エンジニアが幸せに開発できるように。
エンジニアが嬉しいと思ってくれるために。
私たちはソフトウェアを開発しています。
幸せにするには、どのように仕事をしていくべきか。
どのような会社であるべきか。
自分たちが最善だと思うやり方に、
私たちと挑戦していきませんか?
Qiita開発チームでテックリードとプロダクトマネージャーを兼務しています。テックリードとしては他のメンバーの技術的な相談に応じたり、一人の実装者としてコードを書く機会も多くあります。
IncrementsやQiitaは開発チームとユーザーとの距離が非常に近いことが特徴です。新しく機能を出すと、SNSで多くの方が言及している様子を知ることができますし、サービスが止まれば、深夜であっても日本中の開発者が悲鳴を上げます。そういうユーザーの声を目にした時、よりいっそう頑張ろうと奮い立ちます。
プロダクト開発は、ユーザーに届かなければ意味がありません。 "Done is better than perfect" とよく言われますが、完璧を期していつまでもリリースしないのではなく、とにかく前進することをいつも心がけています。かといって後先考えずに走るだけでは、いずれ自分の首をしめることにもつながっていきます。バランスの問題ではありますが、いかに素早く保守性の高いシステムを作るかがエンジニアリングの良し悪しなのだと思います。
私がIncrementsに入社したのは、Qiitaというサービスが好きで、その好きなサービスをもっと成長させたいと思ったからでした。Incrementsは、同じような想いを持って開発に取り組んでいるメンバーがいます。
入社した当初はKobitoの開発を主に担当。現在はQiita:Teamの機能開発に携わっています。
自分がよく使っているサービスの開発に携われることにやりがいを感じます。また、開発環境の最適化やワークフローの効率化など、業務に関わる部分を改善していくのが楽しく、気晴らしにもなります。
設計や実装についてフラットに議論でき、同僚に恵まれていると思います。口頭で議論した内容をドキュメントに落とし込む文化があるため業務がやりやすいです。
青沼の語る働き方の工夫についてはこちらでご覧いただけます
【働き方改善・ワタクシ流/Vol.1:uasiさん】
「OmniFocus(デジタル)」と「測量野帳(アナログ)」を併用して、タスクとモチベーションを管理する!
https://zine.qiita.com/work-improvement/how-to-manage-tasks/
Qiita:Teamの開発、またインクリメンツ全体のインフラを担当しています。
インフラの観点では、障害が発生した時に発生を検知し、早急に復旧させること、また再発しないように対策を打っていくことは、起きては欲しくないものではあるが達成感があります。また、障害を見据え、短期的・長期的な両方の観点で対策を立てて、問題を減らしていくのも楽しいです。
アプリケーションでもシステムでも、なんとなく動いているからOK、ではなく、なぜそのようなコードを書くのか、この設定は必要なのかということを常に考えて、調べるようにしています。なぜかが分かると、視野が広がり、どのように作っていくのがよいのかや未知の問題に対応していけます。
何かやりたいことがあった時には社長にその場で聞いたりして、スピード感を持って決定して進めることができる会社です。
荻原の語るIncrementsのカルチャーについて詳しく知りたい方はこちらでご覧いただけます
Incrementsの働き方カルチャーってどんな感じですか? 入社したての社員に聞いてみました。
https://zine.qiita.com/work/increments-culture/
Qiitaのサーバーサイドを担当。最近ではQiitaのHTTPS化やQiitadonの開発をリードしました。
やりがいとしては、多くのエンジニアに使ってもらっているQiitaのサービスを改善できるというのがあります。ほかには、社内の優秀なエンジニアと仕事ができるというのも挙げられます。開発経験が豊富な方から、視野の広い大局的なアドバイスをもらえます。HTTPS化のプロジェクトでも学ぶ点が多くありました。
属人化させないこと、または自動化することを心がけています。少人数で効率よく開発できるように、自動化できるところは自動化し、それ以外のところもドキュメントや変更内容を残すことで学習コストを下げ、他の人も改善に参加しやすいようにしています。
「エンジニアがエンジニアのために開発をする」というカルチャーを持った会社です。
「エンジニアのため」というのは、1つは「自分たちのために開発環境を作る(=開発環境の改善)」、もう1つは「世の中のエンジニアのために便利なサービスを作る(=Qiita/Qiita:Teamの開発)」の2通りの意味があります。
例えば開発中に気づいたことをQiita:Teamに記事を書いて残しておく、Qiita自体もコードの品質を上げる、使っているライブラリのバージョンを積極的に更新したりというような取り組みを実践しています。
Qiitaでは、エンジニアが使いやすくなるように、情報集めしやすくなるようにといった目線で開発を進めています。Qiita:Teamでは、エンジニアはもちろん、エンジニアと関わるエンジニア以外の方も対象にして、気持ちよく使ってもらえるようにいろいろと開発に取り組んでいます。
千葉の働き方を詳しく知りたい方はこちらでご覧いただけます
【Incrementsで働く Vol.5:千葉知也(エンジニア)】
QiitaのHTTPS化やQiitadonプロジェクトをリードする若手エンジニア
https://zine.qiita.com/work/increments-tomoya-c-engineer/
最新の技術やツールをどんどん積極的に試して取り込んでいくのも、 Incrementsの文化の一つです。
ソースコードはGit管理、タスク管理はGitHubのPull Requestやissueで行っています。masterからブランチを分岐させて開発し、Pull Requestを投げ他のエンジニアにレビューをしてもらいつつCIを走らせます。問題なければmasterブランチにマージしすぐデプロイしています。ツールを組み合わせて開発することの弊害として、情報が分散してしまうという問題があります。そのため各種ツールのイベントをSlackに集約、またデプロイ自体をSlack経由から行うことで、何の開発が行われているのかがリアルタイムに分かるようにしています。
Incrementsではさまざまなレイヤーで自動化を推し進めています。自動化できる作業は自動化することで、ユーザーヒアリングや設計など、自動化できない創造的な仕事により多くの時間を充てられるようにしています。また自動化して作業がコード化されると、作業内容が可視化されるため作業フローを改善しやすくなります。効率化のための改善は継続的に行っています。
ミーティングの議事録はもちろん、口頭で話したようなことも価値がありそうならばQiita:Teamへすべてきちんと残し、特定の人達しか知らないという状況を防いでいます。困ったことはデイリースクラム(朝会)や日報などでこまめに共有、チームみんなで解決していくことを徹底している環境です。
Incrementsは「本当に必要かどうか」を考えることをとても大事にしています。リーン・スタートアップを元とした開発フローを構築しており、実装する前に価値仮説を立てて、提供したい価値や解決したい課題を明確にすることに時間をかけています。またユーザーヒアリングを非常に大事にしています。エンジニアでも直接ユーザーからフィードバックを受ける機会が多いので、自分の考えだけに寄らずユーザーのニーズに沿った開発を無駄なく行えます。そのため、エンジニアでもユーザー体験を重要視しています。
HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で、Humility(謙遜)、Respect(尊敬)、Trust(信頼)の3つを意味しています。「驕り高ぶらないようにしよう」「相手を尊敬しよう」「人を信頼してまかせよう」といったHRTの概念を意識することで、コミュニケーションの衝突が避けられるようになりました。また導入した結果、元々気をつけている文化だったことに気づくことができました。
京都大学在学中にプログラマとしてGoogleやはてなのインターンを経験し、在学中の2011年にプログラマのための技術情報共有サービス「Qiita」をリリース。大学卒業後の12年2月Increments株式会社を設立し代表取締役に就任。17年にはForbesのアジアを代表する30歳未満の起業家30人エンタープライズ部門に選出される。
海野の語るIncrementsについて詳しく知りたい方はこちらでご覧いただけます
【Incrementsで働く Vol.1:海野弘成(代表取締役社長)】エンジニアを幸せにすることがより良いソフトウェア開発につながっていく
https://zine.qiita.com/work/happiness-of-engineers-leads-to-better-software-development/
まずは気軽にお話してみませんか?