取り留めのない話ですが、エンジニアとしての「技術的な成長」や「やりがい」を自社のサービス開発と上手く方向性をマッチさせる為に出来ることって何だろうと思うところの話です。特に答えのある話ではありません。

日本のエンジニアは労働時間が長く、やりがいが少ない

半年ほど前の記事になりますが、「日本のエンジニアは労働時間が長く、やりがいは低い」
という国際比較を同志社大学が発表したそうです。

この記事によると他国に比べて日本のエンジニアは週あたりの労働時間が長く、

「今の仕事は面白い」というような満足度がかなり低いことがわかります。

エンジニアにとってのやりがいとは

一口にやりがいと言っても、何が仕事のやりがいであったりモチベーションとなるかは人それぞれだと思います。

私個人で求める開発におけるやりがいを挙げてみるとするならば、

・コードを書くことに専念できる

・知的欲求を満たしてくれるような技術的な成長ができる

・モダンな開発環境が整えられる

・新しい技術を取り入れられる

・新しい技術や言語を身に付けられる

などといった感じでしょうか。

これらがサービスの成長と一緒に達成できるといいなと思います。

日本のエンジニアは自主的にスキルアップをする時間が少ない

やりがいを求めるからにはエンジニアとして価値を生み出せないといけません。
色々調べている中で、国が出している統計を見つけたので貼っておきます。

2016年に経済産業省が発表した「今後のIT人材の活用・確保に向けた提言」によると、

日本のエンジニアは、諸外国のエンジニアに比べて「自己研鑽の頻度」が低い
すなわち自主的なスキルアップの頻度が低いとの調査結果でした。

このような背景には

・労働時間が長い
・新しい技術への関心がない
・新しい技術を使いたくても社内で理解を得られない

など、ここには書ききれない様々な理由があると思います。

とはいえ他の諸外国の同じエンジニアに比べると、
日本のエンジニアは業務以外で自己投資に時間を使うことが少ない傾向にあるようです。

もはや「勤勉な日本人」というイメージを持っているのは日本人だけかもしれませんね。

社内研修や業務だけでは限界がある

また先ほどの「今後のIT人材の活用・確保に向けた提言」によれば、

「会社の教育・研修制度や自己研鑽支援制度に対する満足度」に関しても
日本のエンジニアは満足していない人が多いという回答結果が出ています。

言い換えると、社内の教育制度やスキルアップ支援制度が不十分だと思う人が多いようです。

大きい企業などでは長期間の研修があったり、OJTなどで実践を通して学ぶといったことが実施されたりするかと思いますが、現状では多くのエンジニアがそれに満足できていないということが見てとれます。

社内の研修制度を整えたり、業務を通して新しい技術に触れていくことでもエンジニアとしてはある程度は技術的成長につながるでしょう。

満足していない人が多いからといって、必ずしも他国に比べて質的にあるいは量的に劣っているとは個人的には思いません。これは会社の研修にどれだけのサービスを求めるかによっても答えは変わってくると思います。具体的にその辺どうなのか気になるところです。

いずれにしても先にあげたエンジニア個人の自己投資の時間にせよ、社内研修の制度にせよ、エンジニアという専門職に近いような職業においては、技術的成長ややりがいというものは結果として会社全体の技術力に跳ね返ってくると思います。エンジニアの技術的な成長や、やりがいを持てるような環境を提供できるといいなと思う次第です。

会社の技術レベルは、エンジニアの技術レベルで決まる

会社の技術レベルに焦点を移すと、自社開発・受託開発を問わず、いち会社の開発技術のレベルは、その社内にいるエンジニア一人一人の技術レベルによって決まります。

会社の技術レベルやサービスの技術レベルを担保できるのは、最終的には社内のエンジニアしかいません。技術の良し悪しも開発の良し悪しもつまるところ、ここに懸かっています。

加えて社内の技術に対する理解や、一見すると利益へ直結しないような技術的取り組みへの理解があって、初めて高い技術レベルを担保出来ると思っています。

Cluexも決してまだまだ高い技術力があると自負出来たものではありませんが、それでもDockerをProduction環境へ導入したり、APIのバックエンドにgo言語を導入したりといった取り組みを行っています。

エンジニアと会社にとってwin-winなものを

エンジニア個人にとっては、新しい技術のキャッチアップや習得は技術的成長ややりがいに直結するものの一つだと思います。技術好きな人は放っておいても勝手に新しいことを常に吸収すると思いますし、それをサービスにうまく役立てることが出来ればやりがいに繋がるはずです。

会社から見れば、それぞれのエンジニアが個々の専門性を持ち合わせ、社内に持ち寄ることでサービスに新たなシナジーを生み出す可能性があると思います。

エンジニアの技術的な成長ややりがいをサポートしてあげることは結果としてエンジニアにも会社にもいい影響をもたらすwin-winなものだと思います。

Cluexで取り入れている制度

Cluexには大企業のような研修制度とまで言えるものは用意していません。

その見返りと言ってはなんですが、自ら課題を見つけて解決するようなタイプの人にとってはいい環境が整っていると思います。

新しい技術を試す場があったり、業務として社内で使用していない新しい技術を触ることもできます。

常にベストなアーキテクチャを保ち、ユーザーにとってもエンジニアにとってもよりベストな環境を保っていく為には、「日々情報をキャッチアップし、より良いものを社内へ取り込んでいくサイクル」を作ることが会社にとってもエンジニアにとっても必要だと思います。

そうした技術的な面から新しいものを社内へ取り込むサイクルを回すために、社内で実施している取り組みのいくつかを紹介します。

会社負担の書籍購入制度

社内で既に使用している技術に関してより深く知りたい時ってあると思います。

また実際の業務に直接関係のないような技術でも、知りたいことってあると思います。

エンジニアの知的探究心を会社がこうした側面からサポートすることで、技術好きなエンジニアは勝手に勉強し始めますし、社内に取り入れる技術となることもあるので、結果としてエンジニアにも会社にもいい影響があると思います。

業務時間をインプットに充てる

業務時間の一部を新しい知識の習得に使うことを推奨しています。

アサインされたタスクなどの業務における開発とは別に、興味のある新しい技術を試してみたり、書籍を読んだりといったことを業務時間中に行うことができます。

新しい技術も実際に触ってみないと、どんなものか分かりません。新しい技術を試す環境も、会社で提供出来るといいなと思っています。実験材料となるようなリソースもありますし。

タスクが早く終われば、次回のスプリントまでの残りの時間は全部これに充てることも可能です。

社内LT大会

自分の興味のある分野の最新動向や、開発をしていて困ったことなどを共有する場として活用しています。

LTのテーマは個々人に任せているので、フロントエンド、バックエンドからインフラまで、幅広いトピックのLTが行われます。

自分の知らない分野に関しては、LTを行った人に色々聞くことで解決できます。またLTをする側もプレゼンでアウトプットしてフィードバックをもらうことで更に深掘りをしていくこともできると思います。

発表するまでは言語化されていなかった一連の思考プロセスも含めて、エンジニア同士でLTによる情報共有が出来るのがLT大会だと思います。

合宿

半年に1度、合宿に行きます。

開発メンバーとしてはこの場を利用して、新しい技術の導入からリリースまでを目標として取り組んだり、サービスの改善を行ったり、合宿中のテーマを決めて2泊3日で行っています。

新しい技術を取り入れるタイミングは合宿だけではないです。合宿ではまとまった時間を取れて、短期的な目標に向かって一丸となって取り組めるので、技術的負債の返却や新しい技術の導入にはもってこいだと思います。

まだまだ発展途上の会社でありチームであり、「IT×教育で世界を変える」という理念に辿りつくにはまだまだ長い道のりです。チーム開発をされている方など、どんな取り組みをされているのかぜひお話を聞いてみたいなと思います。