イントロダクション

こんにちは。プロダクト開発部でエンジニア・マネージャーをやっている島本（ @diskshima ）です。

前回は

と、ちょっと業務から少し外れた技術の話をしてしまったので、今回は技術の話でありつつ「想い」に寄せたものを書こうと思います。

伝えたいメッセージ（TL;DR）

今回は企業におけるエンジニアチームをマネジメントをする上で大事にしたいな、と思っているものを経験を元に書きます。

伝えたいメッセージは（TL;DR）：

• 継続開発における「基盤」作りは大事

という話です。

継続開発における「基盤」作りは大事

自分は普段からプロダクトの開発をしている際に「基盤」作りにも力を入れることがとても重要だと思っています。
「基盤」という言葉だと少しイメージしにくいかもしれませんので、「仕組み」とか「土台」と読み替えていただくと分かりやすいかもしれません。

僕は元々、大手の外資系証券会社のIT部門でエンジニアをしていたのですが、「基盤」がかなりしっかりしていたな、と今振り返っても思います。

開発面においては

• 各種プログラミング言語（C++、Java、C#、Perlなど）の専用チーム
• 社内専用フレームワーク
• • サーバ側のコンポーネントをGUIで線をつないでいくとサーバプログラムができあがるEclipse Pluginとかは秀逸でした。
• APLをベースにした独自言語
• 社内システム間でデータを配信するための独自のPub-Subシステム
• 独自開発したサーバプロセスのモニタリングツール

などなど、共通部分は専用チームを作ったり、専用のシステムを作ったりして、僕のような事業に近いエンジニアはアプリケーション部分の開発に注力できるようにしていました。

背景にあるのは「効率化」と「満足度」

なぜこの規模までやっていたのか勤めている当時は考えたこともなかったのですが、10年近く経ってマネジメントの仕事をしていく中でキーワードは

• 効率化
• 満足度

だったんだな、と思っています。

効率化：人のコストは馬鹿にならない

「人」のコストは高く、特にエンジニアに関しては採用コストや給与の面でも上がってきており、いかにエンジニアのみんなの効率を高く保つかが重要です。
社内でしか利用しない専用の言語やシステムは、一見、重厚長大で無駄に見える面もあるかもしれませんが、必要なものを異なるエンジニアチームが別で実装することの方が無駄であり、そういうものは共通化していくべきです。

JIRAで有名なAtlassianと、eコマースプラットフォームShopifyの元CTOである Jean-Michel Lemieux さんも

と「研究開発費」のうち、50%がプラットフォーム（＝基盤）作りに充てるべき、と語っています（注：なお、ここでいう「r&d」を「研究開発費」としていますが、実際には運用しているものの費用なども含んでいるのだろうと思います。ツイートを読んでいると、そう捉えるほうが自然でした。）。

ちなみに、こちらのスレッド、21ツイート含まれていますが、上記の解説となっており、いずれも示唆に富むものなので、是非一度読んでみることをオススメします。

満足度：エンジニアは面倒が嫌い

「満足度」の観点でも非効率なことをさせることによるエンジニアのモチベーションダウンも無視できません。「またこれやるのか、面倒だな」と思わせてしまうと、少しずつですがモチベーションを削ってしまい、最後の最後は「辞める」という選択肢だけになってしまいます。

こちらも先程と同じJean-Michel Lemieuxさんのツイートですが、

と語っているとおり「エンジニアが快適に働けるように道具と仕組みを用意しないと辞めるよ」というのが現実です。

「快適に働くための道具と仕組み」なのですが、これは多岐にわたると思います。

• 無駄なコードを書かないで済むようなフレームワーク
• 共通で利用するライブラリ
• CI/CD
• タスクなどが明確で見える化されているような開発プロセス
• スペックの高いPC
• 大きいディスプレイ
• 有料で便利な統合開発環境IDE
• …

いずれもある程度、時間やお金をかければ、達成できるものですが、機能開発やバグ修正を優先して改善されなかったり、そもそも企業として理解が得られておらず予算をかけてもらえなかったりしがちです。

1つ1つはそれほど大事（おおごと）ではないように映るかもしれませんが、相関性がある事象なので、1つできていない場合は他もできていないことも往々にしてあります。そして、1つ1つのちりが積もり、最後はエンジニアの「退職届け」に繋がります。

プログリットでの取り組み

少し抽象的な話でしたので、自分が実際に取り組んだ「基盤」作りについて書こうと思います。
大小含めると様々あるのですが、「効率化」や「満足度」のために大きかったなと自分で思っているのが

開発プロセスの確立

です。

具体的には

• ドキュメントツールの統一化と徹底
• GitHubのPRレビューの徹底
• デプロイの自動化
• 各種ツールの権限整理

などです。
無論、自分がJOINする前から一定やっていたのですが、確立されたものではなく、都度お互いにコミュニケーションを取って調整することが多く、上の方で述べた「効率化」とはまだ言えない状態でした。
これをより明確にして、徹底していくことで、不要なコミュニケーションや伝達や手作業によるミスが減りました。
先程述べた「満足度」という観点でも開発プロセスの細かいところをスムーズにしていくことにより、細かいところで作業が詰まったりするのを減らして、より快適にできたかな、と思います。

正直に言うと、かなり「大変」ですし「評価されにくい」部分ではあるのですが、その後のメリットは長く続きますし、継続開発を行うようなプロダクトにおいては長い目で必ずメリットがデメリットを上回ります。

詳細な開発プロセスについては以前書いたものも是非見ていただけると幸いです。

まとめ

基盤作りの大切さについて、自分の経験を交えながら、書かせていただきました。

エンジニアの採用コストや給与が上がっている中、一層

• エンジニアの効率化
• エンジニアの満足度を上げて辞めさせない

ということが会社としても重要なトピックですし、自分としても大切にしたいな、と思います。

みなさんの開発現場などで少しでもプラスに変わえられるようなヒントができていたら幸いです。