Incrementsに seigoがJoinしました++

seigoこと石野正剛は、これまでユーザーを中心とした製品開発とコンサルティングをしてきました。今後は「ソフトウェア開発をよくすることで世界の進化を加速させる」というIncrementsのミッションに基づいて、ユーザー・エンジニアリング・ビジネスのバランスを取ってQiita:Teamの成長に全力で取り組んでいきます。

今後のIncrementsの進化をお楽しみに++

Incrementsでは引き続きメンバーを募集しています。

• Qiita:Teamや新規事業のグロースを担うWebマーケター募集！
• 法人向けサービスQiita:Teamや新規事業に携わるセールス職を募集！
• 「広告」を通じて価値ある情報をユーザーに届けるアカウントプランナーを募集
• 500チーム以上が利用中「Qiita:Team」カスタマーサクセス担当募集
• QiitaやQiita:Teamの開発を支えるチームをつくる採用責任者募集

まずはランチをしながらお話しませんか。
興味がある方は jobs@qiita.com またはWantedly経由経由でご連絡下さい:)

Incrementsにk-imuraがJoinしました++

今後もユーザーの皆さんにより良いサービスを提供していくため、またソフトウェア開発をよくしていくために++の事業面での人材強化は不可欠です。これまでの経験を活かして++の事業サイドも強くし、++が次のステージに躍進していくために尽力してくれるでしょう！

今後のIncrementsの進化をお楽しみに++

Incrementsでは引き続きメンバーを募集しています。

• Qiita:Teamや新規事業のグロースを担うWebマーケター募集！
• 法人向けサービスQiita:Teamや新規事業に携わるセールス職を募集！
• 「広告」を通じて価値ある情報をユーザーに届けるアカウントプランナーを募集
• 500チーム以上が利用中「Qiita:Team」カスタマーサクセス担当募集
• QiitaやQiita:Teamの開発を支えるチームをつくる採用責任者募集

まずはランチをしながらお話しませんか。
興味がある方は jobs@qiita.com もしくはWantedly経由でご連絡下さい:)

こんにちは、@tshunskです。
風邪やインフルエンザの流行が気になる季節ですが、Incrementsでは先日予防接種の出張に来てもらって、ほとんどのメンバーがそこで予防接種を済ませてしまいました。予約が1回で済んだので、手配する側としても今年のインフルエンザ予防接種はすごく楽でした。

さて、今回はIncrementsのリモートワークとフレックスタイムについてご紹介します。

各自が最大のパフォーマンスを発揮するためのリモートワーク

Incrementsでは本年6月から全社員を対象にリモートワークを導入しています。取得日数の上限はなく、またリモートワークをする際の申請や許可などは一切不要な制度となっています。

本格導入の前には週に１日だけ実施し、検証を重ねた上で「リモートワークによるパフォーマンスの低下は見られない」ということが確認できたため、6月から全社で実施しています。

「リモートワーク」という名称にはなっていますが、意味合いとしては「Work Wherever（どこで働いてもいい）」に近く、家でも、会社でも、カフェでも各自が最大限のパフォーマンスが発揮できる場所を選択して働くことができる制度となっています。

家で仕事をすることが多いメンバーは椅子や机、ディスプレイなどに結構な投資をしていたり、逆に家では一切仕事しないというメンバーは毎日普通に出社していたりします。会議もリモートで行えるように、各会議室には大きなディスプレイとGoogleハングアウト用の機材が設置してあり、どこからでも会議に参加できるようになっています。

京都にいてすべてリモートワークというメンバーもいれば、週に2、3日だけリモートワークを使うメンバー、ほとんどリモートワークをしないメンバーなど、この制度の使い方は人それぞれです。なかには、スノーボードが大好きすぎて、冬の間だけ長野に移住する強者までいます。

社内のコミュニケーション

社内のコミュニケーション手段は、Slack、Qiita:Team、GitHubなどがメインですが、現在のところ大きな支障もなく業務をすることができています。もちろん、月に1回の全社ミーティングには出社してもらうようにしたり、ディスカッション時などは会議室に集まってもらうなど、すべてをリモートで完結できるようには厳密にはなっていない部分もありますが、「会社に来なくても働ける」制度としてすっかり定着しています。

また、オフィスTGIFやミートアップを開催するなど直後会って話せる時間も大事にしています。

働く時間に柔軟性を持たせるフレックスタイム

リモートワークとあわせて、働き方に柔軟性を持たせるためにフレックスタイムを導入しています。ルールは「コアタイムの13〜17時は必ずオンラインとなり、業務を行うこと」「月間所定労働時間（8時間×営業日）以上は必ず働くこと」の2つです。また、翌日の業務への影響を考慮して、午前0時以降の業務は原則禁止しています。

社内会議などはなるべくコアタイムに行い、それ以外はツール上で緊急度に応じて適切にコミュニケーションをとるようにしています。メンションなどの通知は受け取り側が制御する前提で、必要であればいつでもメンションしていいように社内でガイドラインを設けています。

朝早くから働き始めて夕方以降はジムに行ったり、家族と過ごしたりするメンバーもいれば、午前中に自分の用事を済ませて午後から働き始めるメンバーもいます。生活スタイルはそれぞれですが、1日4時間は同時に働く時間を設けることでコミュニケーション上での問題はほとんど生じていません。また、いろいろな業務についてGitHubやQiita:Team上でとにかくドキュメントを残していくことによって、非同期コミュニケーションの精度を高めるようにしています。

おわりに

Incrementsのリモートワークとフレックスタイムについてご紹介してきましたが、いかがだったでしょうか。現在の体制が完璧だとは思っていませんので、まだまだいろいろな制度やツールを試行しながらチューニングをしていくつもりですが、これらの制度を検討されてる方々に少しでもご参考になれば幸いです。

私たちが働き方について考える時に常に意識しているのは「どうすれば各自のパフォーマンスを最大限に発揮できるか」ということです。働く場所と時間に柔軟性を持たせることでパフォーマンスが発揮しやすくなるのであれば、そのためのサポートは会社として惜しむつもりはありません。

最後にIncrementsでは、このようなリモートワークとフレックスタイムのもとで働きたい仲間を絶賛募集中です。もしご興味があればこちらからご応募してください。

こんにちは、@tshunskです。

Incrementsではエンジニアでないスタッフも全員がGitHubアカウントを持っていて、社内の稟議もGitHub上で起票しています。

今日は稟議のシステム化をご検討されている方のためにIncrementsが行っているGithub稟議のやり方と導入する際の手順を簡単にご紹介したいと思います。

背景

会社の規模がある程度以上になると社内の承認プロセスとして稟議という手続きが間違いなく必要になってきます。いくつかのワークフローシステムも試したのですがいまいちパッとしたものがなかったため、それではGitHub上でやってしまおうということになりました。

GitHubに決めた理由

• スタッフ全員がアカウントを持っていて、使い慣れているので導入・運用のコストがかからない。
• 稟議の内容に対するコメントや修正履歴なども後から見ることができるし、誰がいつ承認したのかという記録もシステム上でしっかりと残る。
• 承認後の改竄が不可能。

稟議承認までの流れ

弊社では、GitHub上での稟議の起票から承認を以下のような流れで行っています。

• テンプレートに沿って稟議内容をPull Requestとして作成し承認者にメンション
• 承認者は内容を確認後、Pull RequestをMergeする。
  • 複数の承認者がいる場合、各自Approvedで承認の意思を明示し、最終承認者がMergeをする。

次は、GitHub稟議をはじめる際の手順をご紹介します。

GitHub稟議の導入の仕方

1. GitHub上に稟議専用のリポジトリを用意する
   当たり前ですが、稟議専用のプライベートリポジトリが必要になります。
   名称は「ringi」でも「request-for-approval」でも、みんなが分かりやすいもので設定しましょう。

2. READMEに「稟議フォーマット」や「タイトルの書き方」などルールを記載する
   フォーマットを用意してあげると、稟議を書き慣れていない人でもスムーズに起票することができるので、ここをしっかりと準備しておくことが大事です。

タイトルは、それを見ただけで概要がわかるように書いてあると良いでしょう。
例) 2016●●●●_◯◯◯法律事務所との顧問契約.md

フォーマットについては弊社は以下のものを利用しています。

稟議を出す人と承認者では稟議対象について同じレベルの情報は持っていません。
そのうえで、承認者が「目的や検討のプロセスが適切かどうか」で判断できるように、「代替案やリスクについては検討されているか」などの内容が網羅できるようなフォーマットになっています。

---
申請日: 20●●年●月●日
申請者: 申請者の氏名
承認者: 承認者の氏名
---

## 実施の経緯及び目的 (必須)

## 実施内容 (必須)

## 結論にいたった理由 (必須)

## 必要な費用 (必須)

## 実施日時 (必須)

## 期待される効果 (必須)

## 他の選択肢

## 実施しなかった場合の影響

社内への周知

日常的にGitHubを利用していないスタッフもいるので、READMEに簡単な解説を書くだけでなく、IncrementsではQiita:Team上でも画面キャプチャ付きのドキュメントを用意し稟議の作成手順を周知していきました。

結果、全社的にスムーズにGitHub上で稟議の承認フローを回すことができています:)
稟議のシステム化をご検討されている方のご参考になれば幸いです。