エンジニア少ない問題
こんにちは id:kotamat です。 このブログを見ていただいている方は特に実感されていると思いますが、現在日本市場においてエンジニアは引く手あまたの完全売り手市場です。 また、エンジニアリングというのは、人数をただ増やせば線形的に開発工数が削減されるわけではないので、「今の開発スピードを2倍にするために2倍の人数を採用しよう」という話にはなりません。 いかに最小の人数で最大の効果を上げられるかというのは、他の職種以上にシビアにならなければならない技術組織の課題であり、どのIT企業も頭を悩ませている問題かなと思います。
開発効率向上のために真剣に考えられているか
思い通りの開発スピードができていないときに、まずマネージャー層が思うのは、「もっとできる人は採用できないか」でしょう。実際入社直後のSCOUTER社はそのようなオーダーが来てたこともありました。 とはいえ、「採用媒体に出していっていっぱい面接していこう」「福利厚生いい感じに見せていこう」「みんな仲いい感じを演出していこう」等小手先のことをやったとしてもあんまり効果は無いことは、自分がエンジニアであるからこそわかっていたことであり、時間のムダになりそうというのが目に見えていました。 真剣にエンジニア組織として効率を上げるにはどうすればいいかを考え、実行していく事によって、多少なりとも今いるメンバーだけでも効率を上げることができるようになると思います。 今回はSCOUTER社の開発組織として、効率向上の切り口でやったことを紹介したいと思います。
最大の理由: 経営陣の技術に対する理解
まず、ここは後に紹介する要素のベースになる重要な要素です。 よく言われることですが、エンジニアとビジネスメンバーは生息環境が違うという話があります。 もともと経営陣はエンジニア出身者ではないのですが、エンジニアの重要性と特性をよく理解してもらっているため、無意味な配慮をすることなく技術分野に対して集中して考え実行することができました。
SCOUTER社はVue Nuxt領域でもNo.1のポジションを明確に目指して、どんな会社よりも投資していきます。興味ある方々うちのエンジニアに気軽にお声掛けください! @kotamats @ryotakodaira #nuxtmeetup
— TaroNakajima (@Scouter_Taro) May 19, 2018
SCOUTER社のオフィスはエンジニアに設計権があります。よって、エンジニアの命により広い机を新調いたしました。理想の仕事環境を作りたいエンジニアの皆様、お待ちしております。 https://t.co/kkCTVZvMPj
— 山田浩輝 (@Scouter_yamada) May 29, 2018
エンジニアから経営陣に歩み寄るというのも大事ですが、このように経営陣からもエンジニアを理解し尊重するという行動が実体を伴う形で取れているかどうかは、非常に大事かなと考えています。
施策
1: 事業に集中できる技術選定
以前soussuneでもお話させていただいた内容です。
事業に集中するための最も大事なことは、「やりたいことを最小限の工数で実現できる」というところになります。 これは分解すると「やりたいを形にする人の学習コストが低い」「責務範囲が正しく分割できる」「事業ドメインに合わせてカスタマイズできる」「その他アプリケーションによって変わらないところはサクッと作れる」という点になります。 弊社はソリューションとしてLaravel, Vue.jsを選定しておりますが、上記要素はLaravel, Vue.jsともに実現可能であり、最近でてきたNuxt.jsももれずに適応できるため、技術として選定しエンハンスしております。
一点注意点としては「事業ドメインに合わせてカスタマイズできる」という点で、ここを担保するということはある程度自由度がある前提となるため、設計方針などは選定時にしっかり検討しておく必要があります。
2: 攻めのインフラ
攻めのインフラに関しては、前回のスタートアップ×インフラの勉強会にて発表させていただきました。
このインフラ領域において重要視すべき点は「繰り返しとなる作業を機械に任せる」というところです。 インフラ構成は各社多種多様であり、解決すべき課題も各社異なっている領域で、あんまり情報が流通していない、実はものすごく難しい領域かと思います。 考えるべきは「繰り返しとなる作業を機械に任せる」というコンセプトのもと、全体の開発フローの中で自動化できるところがないかを一度見直すことで、長期的な目線をもって適切なタイミングで適切な施策を取っていく必要があります。
3: アトミックデザインとコンポネ志向フレームワーク
自社サービスを扱っている会社では特に、デザインの領域に関しても着手したほうがいいでしょう。 デザインにおいて開発効率を上げる方法は、「デザインの基本構成と、その派生を分割する」ことです。 原子となるボタンやフォーム等、どこのページでも使用されるような基本となるデザインや、カード・モーダル等の分子構造をデザインとして最初から定義しておき、Sketchのシンボル等で簡単にデザインできるようにしておきます。 ここで、Vue.js等のコンポネント志向のフレームワークを使うことによって、デザインのプラグインとして各種アプリケーションで使用可能な状態にできますし、Storybookを使うことでスタンドアロンでデザインを動的に確認できる環境が整備できます。
4: 技術発信する
最後に技術発信です。技術発信の大きな目的として上げられる「会社or個人における技術的認知向上」があることは当然なのですが、開発効率向上にも大きく寄与すると考えています。 理由としては、技術発信することによって「技術的なチャレンジを半強制的に行う必要がある」「使用した技術を体系的に理解する」という効果があるためです。 Webの技術は日進月歩であり、常に勉強していないとすぐにレガシーになってしまうものです。技術的なチャレンジを行うということが前提にあることによって、最新の技術を取り入れる文化ができ、最適な解決策をバランス感覚をもって採択できるようになります。 また体系化の話ですが、初心者に多いですが、なにかを実装しようとしたときにそのコードの意味を理解せずに他のソースコードをコピペしてくることをすることがあると思います。システム開発においてコピペかどうかは関係なくソースコードが正常であれば動きますが、本質的に理解しているかどうかでトラブルシューティングの解決スピードは変わってきますし、なにかを実装しようとしたときにすぐに実装できるかというのはその技術を体系的に理解しているかどうかに大きく影響してくるとかんがえています。
なので、弊社では初心者だろうが業務委託だろうが積極的に技術発信していいよという方針をとっており、それがブランディングにつながっているかどうかは技術発信の必須要件として考えているわけではありません。 エンジニア個人としても、技術発信をすることによるメリットは明確に存在するため、発信することによる双方のメリットは確実にあるかなとおもいます。
まとめ: 時間がかかっても手を打っていく
上記紹介させてもらった理由・施策は一朝一夕で構築できるものではありません。 ただ、ここにおいて構築する方針を掲げ実行できるかどうかは、後々の開発効率だけではなく採用やブランディングにも大きく影響してくるところなので、開発の責任を負っている方は全体の工数をみながら少しずつ改善していくといいと思います。 また、上長がそのような方針を掲げない限り、舵を取っていくのは非常に手間がかかることも自明なので、不満がある方はそのような環境に寛容な組織や会社に転職するなり話を聞きにいくのが手っ取り早くていいかなと思います。
最後に
SCOUTER社では一緒に頑張ってくれる方を募集しております。 デザイン、エンジニアの皆さん興味のある方はご応募お願いします!
また、一日就業体験も募集しておりますので、お気軽にご応募ください!
DM等などで反響を頂いたので、bosyuつくってみました。お気軽にご参加くださいー
— kotamat Laravue NuxtMeetup (@kotamats) 2018年5月24日
SCOUTERで1日就業体験したい人募集
https://t.co/JeyX3jbV5A #bosyu