この記事の対象者
・開発会社の経営者（CEO/CTO）
・エンジニア組織のリーダー（VPoE/TechLead/Lead Engineer）
・その他のエンジニアに気持ち良くコーディングしてもらいたい人たち
記事の投稿者
iOS/Androidアプリを中心としたシステム開発会社の経営者です。最近までバックオフィスメンバーが皆無のエンジニアだけの組織で、「エンジニアに気持ち良くコーディングしてもらうこと」を目的として、過去にやって来たことをまとめました。
エンジニアに気持ち良くコーディングしてもらうために実施している11の施策
1. ディスプレイを用意しよう
コーディングする画面、ターミナルを触る画面、検索する画面が物理的に分かれていると生産性が上がる。1台で充分と言う人もいれば2台欲しいと言う人も。
2. 良い椅子を用意しよう
コーディングに詰まっている時に座り心地が悪いと気が散ってしまう一つの要因。長く座っても疲れない椅子を用意しよう。当社の椅子は全てHerman Miller社のセイルチェア。
3. 統合開発環境（IDE）へ投資しよう
こだわりのエディターがあるエンジニアもいるものの、特にこだわりがないようであればJetBrains社のIntelliJ IDEA Ultimateを契約しよう。主にコーディングしている言語以外の言語でコーディングする時はコード補完、Lint関連の機能は重宝するはず。
4. 重要な技術書は１冊以上購入しよう
エンジニアが増えれば増えるほど、その本を必要とするタイミングが重複することも多い。先人たちの知識には喜んでお金を払おう。
5. 関わりがありそうな技術書は現時点で読まなくても（決裁権者が進んで）購入しよう
今現在必要が無くとも、関わりがありそうな技術書は現時点で読まなくても、いつか必要となる可能性があれば購入しよう。そのいつかが訪れた時、「この本が今すぐ欲しい！無いと困る！」という未来を少しでも防ぐため。また、周辺知識が増えるのは個々の仕事、組織全体の仕事の領域が増える。ここで重要なのは技術領域のことがある程度分かるようであれば決裁権者が進んで購入すること。組織全体への重要度の説明責任の敷居を低くすることで、関わりがありそうな技術書の購入を促す。結果読まなかったとしても、エンジニア組織を経営する上での必要な経費と割り切る。
6. コードレビュー文化を根付かせよう
相互にコードレビューを実施しよう。コードレビュー時に指摘された際の謝罪を禁忌としよう。エンジニア組織のリーダーが実践できると、エンジニア同士でのマウンティングがなくなり、コードレビューの目的であるより良きコードにするということに組織全体で集中できる。他にも当社では実装経験が浅いメンバーが開発する研修プロジェクトでは三段階のコードレビューを実施している。多段階のコードレビューをすることで、前工程のコードレビュワーが後工程のコードレビュー内容を確認し、コードレビュー自体のトレーニングにもなっている。
7. カンファレンスのスポンサーになろう
開発言語、開発コミュニティへの感謝とこれからの発展を祈念して、活動をサポートしよう。スポンサーだけでなく、運営もサポートできればなおのこと。
8. 社内の勉強会を開催しよう
飽きないように勉強会のやり方・テーマを変えながら開催しよう。読書会、LT会、アウトプット共有会などを実施してみよう。
9. 社外の勉強会に参加しよう
やたら滅多に行くことを目的とすることはないが、年間に数回は参加しよう。その勉強会で喋ることができるのであれば尚更。そこでの出会いも意外に繋がることがある（仕事であったり、コーディングの相談できる相手としても）。
10. 視座を上げるために外部講師を招いた講演会を開催しよう
社内だけのエンジニアヒエラルキーに囚われないように、外部講師を招いた講演会を開催することでエンジニア組織全体の視座を上げて行こう。常に新しい発見がある組織であることを維持しよう。外部講師には講演料を払うことを前提とする。
11. 社内で必要そうなシステムを勝手に作るエンジニアをあたたかく見守ろう
当社では草の根活動と呼んでいるのだが、社内で必要そうなシステムを勝手に作るエンジニアがいた場合あたたかく見守ろう。何かする必要はない、何もしないことこそがサポートになる。必要は発明の母であり、自発的に何かが生まれる組織を作って行こう。