iCARE開発部が大切にしていること

株式会社iCAREのVPoE安田です。
今日は弊社開発部の採用についてお話したいと思います。
採用といってもいろいろな側面がありますので、今日はその中でも弊社開発部が「大切にしていること」についてお話したいと思います。

大きく分けて以下の３つのテーマにおいて大切にしていることをお話したいと思います。

- チームメンバー同士の関わり方
- 開発者体験について
- 他部署を巻き込み全社で開発すること

チームメンバー同士の関わり方

助け合う、協力し合うこと

iCARE開発部ではメンバー同士がお互いに助け合う、協力し合うことを非常に大切にしています。
もちろん一人ひとりのメンバーがどんな問題でも自力で解決することができるのであれば、それはそれで価値あることだと思います。
ところがそうした「なんでも自力で解決」しようとするスタンスは多くの場合に、開発に弊害をもたらしていると思われます。
この「なんでも自力で解決」できるエンジニアは、エンジニアにとっては理想のエンジニア像となりがちです。
他人に頼ることなくすべての問題を最速で解決できる。万能、神のような存在。
多様な知識、技術を扱わなければならない現在のWebの世界では、一人の人間がすべてのことを知り、扱うなど到底不可能です。

そう考えると一つの組織やチームは、それぞれのメンバーが適度に情報を共有しつつ、適度にそれぞれの得意分野をもち、その情報をうまく組み合わせながら開発をすることがもっとも効率的だと考えられます。
そうした状況にも関わらず「なんでも自力で解決」できるエンジニア像にこだわることは、逆に問題解決に余計な時間をかけることになったり、チーム内に情報を流通させることを阻害することになります。
言い換えると、表面的には非常に価値のある理想像ではあるのですが、実世界では弊害の多い虚像であると思われます。

また多くの場合、一人での問題解決よりも複数人で問題解決をしたほうが、複数の案をぶつけ合うことで、より創造的に、より高度な問題解決ができます。加えて、コミュニケーションの仕方さえ間違わなければ、一人で問題解決を図るより、より楽しくやりがいをもって仕事を遂行することができます。

より創造的に、より楽しく！

なのでiCARE開発部では、困った問題にぶつかったら、過度に「自力で」解決しようとせず、どんどん他のメンバーを頼り「チームで」問題を解決することを強く推奨しています。

この協力し合う開発は、具体的にはペアプログラミング、ピアレビュー、ドキュメンテーション、ファンダンラーンによる振り返り等を通して実現するようにしています。
一人のエンジニアがなにかの問題解決で困っていたりすると、解決力を持っている、もしくは解決法を知っているメンバーから関連情報のURLが共有されたり、ペアプログラミング、モブプログラミングが提案されたりします。
ペアプログラミング、モブプログラミングが提案されると、問題に直接関与しているメンバーだけでなく、それ以外のメンバーもよくそこに参入しますが、そのこともチームとしては強く推奨しています。
そうすることで情報がより共有されますし、より創造的により楽しく開発できるからです。

開発者体験について

弊社開発部では、事業を最速で進めるためには、開発者がモチベーション高く仕事ができる必要があると考えています。
開発者のモチベーションが高ければ、集中力、持続力が上がり高い生産性を実現することができます。また離職も防ぐことができます。
そのため、開発者が安心して快適に開発できる開発環境作りを大切にしています。

その一つとしてCIや開発支援のクラウドサービスの活用が挙げられます。
サービスに対する品質確保のためだけではなく、開発者体験の向上も強く意識しながら、開発者の提案に基づき、CIや開発支援のクラウドサービスをたくさん利用しています。

問題箇所を速やかに特定し、最短で問題を改善できる

例えば、弊社ではトラブルシューティングのツールとして、Sentry、Datadog APM、Datadogによる監視を活用しています。本番サーバーで例外や異常な速度の処理があれば、Sentry, Datadogを通じてそれらは開発者に速やかに通知されます。
なので、もし問題が発生した場合でも、それらのツールを通して問題箇所を速やかに特定し、最短で問題を改善することができます。

安心してプログラムをマージ、リリースできる

また、プログラムコードをgithubにpushしたタイミングでCircleCIを起動し、RspecやJestによるテスト、Storybookのsnapshotによる変更の検知などを実行させて、不具合や期待しない動作を発見することができるので、その点でもエンジニアは安心してプログラムをマージしたり、リリースしたりすることができます。

フラストレーションなく、プログラムコードを読み書きできる

不具合や期待しない動作だけではなく、ESLintやRubocopといったコードの品質担保のためのツールもしっかり活用していますので、コードの記述の仕方にばらつきがなく、フラストレーションなく、プログラムコードを読み書きすることができます。

仲間と協力して最高のコードベースを作る

ツール以外の面でも、ピアレビューを大切にすることでプログラムコードの品質担保やメンバー間の情報共有に努めています。
PRのレビューは、二人以上のレビューを基本にし、PRのサイズ、コミットのサイズやメッセージといった点にも配慮しながら開発を進めています。
ピアレビューを通して、ボーイスカウト・ルールの徹底や恒常的なリファクタリングを図っています。

他部署を巻き込み全社で開発すること

当たり前の話ではありますが、開発者だけではいいプロダクトを作ることはできません。
とはいえ組織が複雑化すると、部署の垣根を越えてメンバーが協力しつつ開発をすることは難しくなっていきます。
iCAREでは以下のような取り組みを通して、常に部署の垣根を越えて全社で最高の価値を顧客に届ける努力をしています。

プロダクトオーナーの部屋

全社でプロダクトを作るという姿勢を象徴しているのが、週に一回一時間開かれる「プロダクトオーナーの部屋」の時間です。
この時間はメンバー誰でも参加して良い、自由参加の時間で、誰でもプロダクトオーナーにプロダクトに対する意見、要望をぶつけることができる時間です。
自由参加の時間なので、出ても出なくても良いのですが、弊社の場合、各部署から、たくさんのメンバーが参加しており、それぞれが持っている課題感や意見が活発に議論されます。
顧客、見込み客の要望、ペイン、社内メンバーの運用上のペイン、開発上のペイン等、様々な立場のメンバーが様々な意見を持ち寄り、プロダクトオーナーがそれに対して優先づけをしたり、説明をしたりします。
メンバーは自分たちの意見がきちんと議論されたり、プロダクトに反映されるので、自分の仕事にやりがいや誇りを持って仕事をすることができます。

他部署のメンバーと一緒に仕様策定

プロダクトオーナーの部屋で挙げられた意見や要望はその後、実開発に移されていきますが、その中でも他部署のメンバーとの協同は続きます。
開発プロジェクトの初期段階で仕様策定のプロセスがありますが、その打ち合わせでも、その要望と関わりの深い他部署のメンバーを加えることで、顧客の要望や他部署メンバーのアイデアが誤解なくプロダクトに反映されるように努めています。

iCARE開発部にご興味お持ちいただけた方へ

iCAREでは上記のような価値観を大切にして開発をしています。
こうした価値観に共感してくださる開発者の方々と一緒に、最高のプロダクト開発を実現したいと考えています。
今日は、iCARE開発部が「大切にしていること」をテーマに記事を書きましたが、引き続き数回にわたって「採用」をテーマに記事を書いていく予定です。ご期待ください。

iCARE開発部にご興味お持ちいただけた方、よろしければ弊社サイトおよび弊社開発部のサイトも御覧ください。