開発会社におけるエンジニアスキル向上施策の過去と今

morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。

しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての本業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。
今回は、最近社内で（というか主に僕のいるWebチームで）取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。

※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録を残しておくのも必要だなと思い記事にしました。

勉強と業務のバランス問題

恐らく他の開発会社でも似たような悩みを抱えている所は多いのではと思う、勉強と業務のバランス問題について、まずは取り上げます。

開発会社におけるエンジニアスキルの重要さ

弊社はWeb開発事業では受託開発、電子書籍関連事業では自社製品＋お客様向けのカスタマイズ等を事業としている、いわゆる開発会社です。
ご相談を頂くのは、SIベンダで開発力が足りない部分を依頼される方、自社で新しくサービスを立ち上げるが、開発の一部をご依頼される方、自社にエンジニアはいないため、開発の全工程を任せたいと仰られる方様々ですが、弊社に期待されるのは開発力・技術力であることは共通しています。

そうした性質上、自社エンジニアのスキルはそのまま会社としての競争力、差別化に直結するためエンジニアの継続的なスキルアップは至上命題です。
特に、ここ数年は新卒採用も強化してきていることもあり、そうした新人をいかにして稼げる「プロ」として育てるられるのかは、弊社が今後も成長していくためには必須であると考えています。

目先の仕事 v.s. スキルアップ投資

しかし、成長するために必要とはいえ、目先の利益も上げていかなければ会社としての事業継続に支障が出ます。
僕もフリーランスをやっていた時期もあったので分かりますが、キャッシュやリソースに充分な余裕がない状態ではそもそも成長投資をしている余裕がありませんし、ある程度余裕が出てきても「今稼いでおかないと、次また不況の波が来るかもしれない」と思ってしまい、なかなか大きく踏み出せない部分もあります。

また、直近の仕事というのはその時仕事ができる戦力メンバが主体となって回していくのですが、新人や後輩に仕事を教えられるのもまた戦力メンバであることがほとんどです（戦力メンバでも教えるのに不向きな人はいますが、逆はまずない）。

OJT（On the Job Training）という便利な言葉がこの業界にはありますが、戦力メンバが新人教育をしながら案件をメインで回していくというのは大抵の場合で無理があり、その結果、短期的には優先度が「現在動いている案件 > 新人教育」となってしまいます。
「見て覚えろ」「自力で勉強しろ」といった状態はこうしたときに発生しやすく、その結果として新人が放置気味になってしまうというのはあちこちであるあるな話なのではないでしょうか？

僕もそういう状態に入ってしまう経験がありますが、これは実際に経営上仕方ない時があるので、一概に非難できることではないと思っています。ただ「これはまずい」という問題意識は持ち続けるのもまた大事なことだと思います。現場が諦めたら後は腐るのみ、ですしね。

過去にやってきた取り組みとその感触

そんなわけで、弊社でもこうした問題意識の中、エンジニアの底上げ＆スキルアップに向けた支援・教育を実施してきました。色々とやってみてはうまくいかなくて自然消滅、ということも多くあったので全部網羅できているか分かりませんが、覚えているものを幾つか挙げてみます。

1. 自己学習のための書籍購入支援

これは主に技術書・ビジネス書等の書籍等の購入について会社で負担するというものです。
技術書は高いものだと5,000円超えのものもあるため「これちょっと面白そう」レベルの書籍を見つけたときに、価格が購入（=学習）のためのハードルになっていは良くないということから、こうした書籍については別途申請（と言ってもSlackで軽く確認するくらい）の上であれば購入できる制度を設けています。

この制度は割と長い間運用してきていますが、思ったよりも使われていない印象を受けます。僕自身は技術書は電子書籍で購入してしまうことが増えたので、それも原因の一つかもしれません。
流石に社員の個人アカウントで当人しか読めない電子書籍購入を認めるのはどうなんだろう、というところもあり難しいですね。
回し読みできる（またはアカウント間で受け渡しができる）電子書籍の様なものがあればもっと購入しやすいのですけど、まだ難しそう。
また、社内決裁の都合上図書カードで決済するようにしているため、物理本を買いに行くこと自体が面倒臭い、というのも抑制原因になっているかもしれません。

とまあ、そこまで有効に使われていない印象は受けますが、少しずつでも使われていることと、運用側の負荷が小さいことから今後もこの制度は続けていくと思います。

2. 資格取得に対するインセンティブ制度

弊社採用ページにも記載されていますが、現在弊社ではIPAの高度情報処理技術者試験の一部について、合格時に一時金のインセンティブを与えています。
特に、30歳未満で入社後3年以内の場合には大きめのインセンティブにし、対象となる全試験に受かれば100万円もらえるという制度です。

※年齢で差違を設けているのは、30歳以上（それなりの業務に慣れたレベルの年齢）で高度試験を保有していてもそれほど珍しくないためです。ただ、最近社内でも30歳以上のメンバが増えてきたこともあり、30歳以上メンバに対するルールも見直し中です。

情報系資格については「業務には大して役に立たない」「勉強が得意な奴が有利なだけ」など色々と賛否があることは理解していますが、それでも「ニンジンをぶら下げることでやる気を出す」タイプのメンバがいて、それがきっかけで勉強をしてくれるのであればそれで良いと思っています。
CS（Computer Sciense）の基礎教育を受けてこなかった人の場合、情報処理の基礎教養レベルが抜け落ちていることがあるため、エンジニアの知識の前提条件を揃える役に立ってくれれば、という期待があります。

IPAの高度試験についてはどんなに要領が良くてもそれなりに真面目に学習しないと受かることは難しいですし、午後二の問題などはある程度業務を理解する想像力がないと解けない様な問題が出ます。資格試験を目の敵にしている方も、過去問をチラッと見てみると良いのではないでしょうか。

本取り組みは3年以上運用していると思いますが、それなりにうまく作用している様に思えます。もちろん全然受験しないメンバもいますが、受験してちゃんと受かるメンバも実績として出ているので、初期の思惑通りとも言えます。

しかし、情報処理技術者試験とは別に、Ruby技術者認定試験についても同様のインセンティブ施策を行いましたが、これは受験したメンバもほぼおらず、結果として失敗しました。なぜ失敗したかの考察は後半で。

3. 学習して欲しいスキルセット一覧の明示化と、社内認定制度の実施（かなりがんばった）

2〜3年前に時間を作ってゼロから構築に取り組んだCDP（Carrier Development Planning）制度です。
※2014年度に主に取り組みましたので、一部内容は現在に比べると古い部分もあります。

初期メンバからエンジニアの数が増えていく中で（といってもこの時は10〜20名程度）、なるべく公平に、納得感のあるエンジニア評価をできる仕組みを目指して構築しました。
当時の問題意識としては以下の様なものがあったと記憶しています。

• 前述したような目の前の開発を優先することでスキルアップについて（悪い意味での）OJT的な雰囲気が強まってしまっていたことに対する危機感
• エンジニアから見て納得感のある、本人の実力がなるべく客観的に評価できる方法が欲しかった（売上ベースとしてしまうと、プロジェクトによって大変さの大小は変わるし、技術難易度と売上が比例するわけでもないため）
• エンジニアに対して「会社が価値があると評価するスキル」を明示することで、社内スキル評価（≒給与）を上げたい人が何を勉強すべきかがわかり、エンジニアの成長と会社としての成長に誤差が出ないようにしたかった
• 新卒・第二新卒のメンバも採用していく中での必要スキルの地図の様な物が欲しかった。特にWeb業界は学習すべきスキルが多岐に渡るため、何から勉強して良いのか分からなくなりがちな所があり「今の自分に最も必要なスキル」を見つけられるようにしたかった

本施策は社内の主要メンバの中で相談しつつ、以下の様なことをやっていきました。

会社が求めるスキルの可視化とレベル分け

まずは、必要となるスキルセットを具体的にしようということで以下の定義を行いました。

• 業務で必要な各スキル（全143項目）の書き出しを行いました。例えば「HTML初級」は「90年代と馬鹿にされない程度のHTMLコーディング（floatレイアウトの理解と構築）、View組み込み」、「HTML中級」は「HTML5の新しいタグの理解、意味を理解した正しいマークアップ」など
• 各項目について「到達度合い」としてSABCDの5段階指標を設定しました。例えばSは「原理から理解して、講義できるレベル　または　上位のエンジニアと対等な議論ができるレベル 」、Cは「当該技術については新人・見習いレベル。SやAランクの人と一緒に小間使い程度はできるが、まだ一人で仕事できない」などです。
• 各エンジニアの大まかな役割を「Web開発（フロント）」「Web開発（バックエンド）」「Web開発（インフラ）」「Android開発」「iOS開発」に分け、さらにその中をlv.1〜lv.3の3段階に区分けしました。
  その上で、それぞれの役割とレベルでどの項目がどれくらい必要とされるかの必要度を設定しました。これはMUST/SHOULD/MAYの3段階になります

これらを実施した結果が以下になります。興味のある方は拡大して見て下さい（抜粋です。そのうち公開するかもしれません）。こちらを社内エンジニアに配布したうえで、現在の自己評価をしてもらいました。

社内スキル認定制度と試験の実施

次に、スキル到達度にある程度客観性を付けるため、スキル認定をするための制度に取り組みました。これは、自分にやたら厳しい人と甘い人で同じスキル項目でもS〜Dのばらつきを防ぐための意味合いもあります。
具体的には以下のような取り組みを行いました。

• 前記のスキル項目それぞれについて、ペーパー試験の問題を作成。ペーパー試験では「単一選択」「N個を選択」「任意選択」「記述式」の問題を作成。問題はなるべくエンジニア以外でも採点可能にするため、回答のブレ幅のないものとして作成ました。
• ペーパー試験だけではカバーできない要素を評価するものとして「説明課題」「実践課題」を用意。「説明課題」はある程度ざっくりとした問題に対して口頭＋ホワイトボードや図を書いて仕組みなどを説明する課題。「実践課題」はプログラミング実装などの実際に手を動かす課題としました。
• これらの問題を使い、社内で認定試験を定期的に実施。自己評価のレベルとは別に社内で公式に認定したレベルを記録するようにしました。

なかなか説明だけではわかりにくいと思いますので、以下にサンプルを載せてみます。

ペーパー試験

• Git

• Rails初級

• SQL初級

説明課題

• HTTP初級

実践課題

• プログラミング初級

中身を見ると分かるかと思いますが「なんとなく毎回ググって調べている」だと解けない程度の難易度にすることで、中途半端な理解のままになってしまっている分野は高得点が取れないようになっています。
問題作成は社内の当該分野に詳しいメンバで手分けして作りましたが、かなり大変でした。

試験についてはペーパー試験のみで認定してしまうと丸暗記や運で合格してしまう可能性があるということから、ペーパー試験に合格したら説明・実践課題の試験を行うようにしました（情報処理技術者試験の午前・午後試験みたいな感じです）。

やってみた結果と反省

かなり大規模に企画して実施したこの制度ですが、実際に運用してみていくつかの課題が出てきました。

• 試験という制度があまり好きじゃないという声が出た：当初から想定はしていたのですが「仕事はできるけど試験というやり方で実力が出しづらい人」にとってはあまり価値が見いだせない制度だったため、印象はまちまちな部分がありました
• 業務と勉強時間捻出のバランス：業務が忙しくなると勉強時間も取りづらくなり、一度勉強時間を取れなくなってしまうとなし崩し的に勉強時間が確保できなくなるという問題がありました（これは制度というよりは社内での取り組みの問題ですが）
• 運用の重さによる継続性の問題：前述の業務とのバランスと被る部分がありますが、本取り組みで試験問題を作ったり説明・実践課題の試験監督をやっていたのはエンジニア側の主力メンバでした。そのため、通常業務が忙しくなるとどうしても業務優先とのバランスが取りづらくなってしまう問題がありました

そんなわけで、この試験制度は半年ほど集中的に運用した後、社内的には運用を停止してしまっている状態だったりします。

しかし、この取り組みが無駄だったかというとそんなことはありませんでした。スキル一覧はエンジニアのスキルマップの俯瞰図として、認定試験問題は中途採用時の試験問題として利用するなど、今でも資産として使えている部分はあります。

4. 技術ブログに記事を書き、チーム内でレビューを行い公開する

エンジニアはインプット型の人が多いのですが、アウトプットすることで得られるものも大事ということで、Webチーム内で毎週担当者を決めてTechRachoに技術記事を書こう、という取り組みを行いました。

それまでも（今も）TechRachoには好きなときに記事を書いて良いルールだったのですが、やはり元々習慣的に書く癖がないと続かないもので、記事のUPはまちまちになってしまいがちでした（この記事もすごく久しぶりなのですが :p）。
また、特に当時は小規模な案件（1〜2人規模）が多く回っており、チームメンバー内で一緒に開発するという機会が少なくなってしまっていたこともありました。せっかくRailsをメインとして開発している開発会社なのだから、お互いのノウハウを共有しようよ、という意図もあります。

記事の作成については、週1回のチームMTGで皆でレビューすることで、文章を書き慣れていないメンバでもできるだけ品質の高い記事を書けるようにしていました。「ここの説明は具体的なソースがあった方が分かりやすい」「この記事には使ってるRubyやGemのバージョンを書くべき」など、クオリティアップのための議論ができる場として良いものだったと思います。

本取り組みはそれなりにうまく行っていた様にも思いますが、継続性の面で以下の様な問題が発生し、今は一時停止中です。

• 業務が忙しくなりすぎると記事を書く余裕（気持ち・時間共に）がなくなってしまう問題：他でも上げられているものです。難しい。
• 月1回くらい回ってくると「書くネタがないです」という意見が出た：本当にちょっとしたTipsとかでも良いとは思ったのですが、品質を上げに行ったことが逆に書きづらくしてしまったのかもしれません。

個人的には本取り組みは近々また別の形ででもリベンジしたいと思っているので、なんとかしたいです。

これまでのまとめ

そんなわけで、危機感を覚えていただけではなく、やれることにも取り組んできたのがこれまででした（たぶんこれからも）。

こうしてみると、継続できた施策とできなかった施策で命運が分かれたのはやはり通常業務との兼ね合いによるものだということが改めて分かります。実は、継続できなかった施策も当初は「業務時間のN％はこれに費やしていこう」といって始まったのですが、やはり開発案件が佳境に差しかかると一時停止してしまいます。
これは、施策を実施・運営しているメンバ自体がそもそもメインの開発者でもあるため、そういったときに真っ先にヘルプのお呼びがかかってしまうというある意味当たり前の事情によるものです。
このあたりは正直どうしようもないと思っているので良いのですが、そうした一時的な負荷増によって一時停止してしまった施策の流れを取り戻すのがうまくできていない、というのが継続できていない要因だと思っています。一度失速した流れを取り戻すのは本当に難しいですね。

また、忙しさによって停止してしまうまで一時的にでもうまくいった施策はどれも推進するメンバが率先して動いたものでした。例えば、資格取得支援でも情報処理技術者試験は弊社babaや僕自身が上位資格の保持者であり、実際に試験を受験した上で奨励していたのに対し、失敗したRuby技術者認定試験は奨励した僕自身がちょうど業務ピークに入ってしまって受験する時間が取れず、結局受験できていませんでした。
どのくらいかの大小は分かりませんが、提案した施策に対して言い出しっぺである上司がまずは動く（または動いたことを見せる）というのはメンバのモチベーションに対して影響があるのではないかと思います。

最近取り組んでいる施策とその状況

さて、これまでの振り返りをしてみたら思ったより長くなってしまいましたが、昨今の社内施策や状況についてまとめてみます。

1. コードレビューの文化が根付き始めたことによる、ソースコードベースでのエンジニア間コミュニケーション

何を今更、と思うかもしれませんが、弊社ではこれまでソースコードレビューに対して大きな時間を割くことができていませんでした。これは別にコードレビュー自体が不要だと思っていたわけではなく、リソース的にレビューを行う時間を捻出することが難しかったことや、そもそもプロジェクトの担当者が1〜2名で役割分担をして進めることが多かったため「コードレビューしないと駄目だよなあ、でも今の状況じゃあやる余裕ないよなあ」というセルフ言い訳状態になってしまっていたという状況でした。

しかし、ここ最近以下の様な変化があり、ソースコードレビューが機能するようになってきました。

• 今年に入り採用活動を強化して人数が増えたことにより、小規模な案件も2人以上のチームで対応できるようになってきた
• 超短期間で走り抜ける案件以外にも、SI的な動きを求められる案件の割合が増えたことにより、ゆっくりでも着実な成果と品質が求められるようになってきた（以前書いた「最近のRails受託開発案件相談とエンジニアに求められるスキル傾向」参照）
• 経営的に多少余裕が出てきたため、目先の短期利益だけを目的にする所から、多少中長期的な動きを考えて動けるようになってきた
• 社内で利用していたGitLabがどんどん良くなり、ソースコードコメントやMR（Merge Request）レビュー周りの機能、Slack連携が拡充されてきた

どれも大事な要素ですね。

ソースコードレビューによる利点は既にあちこちで語り尽くされているかと思いますので基本的な部分は省きますが、僕が事前に本や記事を読んで理解していたつもりよりも効果があったと思えた点は以下です。

• 圧倒的に実装レベルでのコミュニケーションが増えた：今までは設計レベルでの大枠のすり合わせを行った後はメンバ毎に手分けをして実装していっていたのですが、MRベースでのソースレビューにより「ここはどういう意図？」「今後ここは変わりそうなので、拡張の余地を残しておいた方がよさそう」などの中身に関するコミュニケーションが増えました。
• feature branchを使ったgit-flow開発フローの定着：MRレビューがあることで、ある程度人に見てもらえる単位でfeature branchを作る意識が生まれたのか、それまでに比べてfeature branchによる運用がうまく回っているように感じられます（それまでもgit-flowは採用していましたが、1人で開発する状態になっているとMRを作るのが煩わしくなって省略されたりすることがありました）。
• レビューによるコード品質の改善：特にRailsでは沢山の「これやるならこのメソッドが用意されてますよ」的な便利メソッドやDSLが用意されていますが、正直ありすぎて知らないメソッドが沢山あります。これを相互レビューすることで「こっちの書き方の方がon the railsだよ」というやり取りがされるようになりました。アプリのビジネスロジックについては当該プロジェクトに入っていないと正しいかどうか分からない部分がありますが、Rails的、Ruby的かどうかであればソースだけ見てもレビューできる部分があります。一度指摘されればその人も次は別の人に伝えていけるので、良いノウハウの共有の場となっている印象です。
• 各エンジニアの得意分野やクセの把握：MRレビューをすることで、普段話しているだけでは分からなかった部分がよく見えるようになりました。書いているコードの命名規則やロジック面でのクセ、設計面での信仰など、MRを読んでいると気づかされることが多いです。各エンジニアの特性を知っておくことで、今後より適切なチーム編成や役割分担に役立てていけるような気がします。

コードレビューにはレビュー工数がかかる、feature branchを意識して作っていくため慣れていないとその辺りに手間取ってしまうなどのデメリットはありますが、僕としては失われがちだったエンジニア間のコミュニケーションやノウハウの共有が取り戻せている実感を持てているので、これは長期的には良い成長に繋がるのではないかと感じています。

2. 定期的な社内発表・勉強会の開催

週1回のチームMTGでは以前までは案件進捗の共有をメインとしてきたのですが、人数と案件が増えたことにより関わっていない案件も増えました。そこで、案件情報の共有は別途マネージャー、ディレクターMTGを開いてそちらで行い、エンジニア参加のチームMTGではプレゼン形式での発表会・勉強会・新人向け講義的なものをやるようにしました。

以下は最近僕が話した内容からのタイトル抜粋です（そのうちTechRachoの記事にまとめられるといいなあ）。

• Gitやバージョン管理の話：なぜバージョン管理が必要なのか、どういう運用・使い方をすると良い/悪いのかなど
• Webアプリの実行環境に関する話：静的ファイルで動作するWebサーバからPHPなどのmoduleで動くもの、Rails/unicorn等のアプリケーションサーバ形式などの解説
• 仕事を進める上での勘所集的なもの：新人向けにタスク管理や計画の立て方などの話
• 良い（質問｜相談｜MR）をできるようになろう：色々な質問・相談・MRをするときのコツなどの話
• Web開発者のためのLinux基礎：嗜みと一般教養
• エンジニアとしてのキャリアを考える：これからまだ数十年ある人生をエンジニアとして生きていくべきなのか、食っていくためにはどうすればいいんだろう的な話

その他、僕以外でもチームメンバで話せるネタを募り、10〜30分程度のコマで発表を続けています。

この施策も実は以前はやろうと言ったことがあって力尽きたものの一つなのですが、以下のような取り巻く環境の変化によってまだ続けられています。

• 人数が増えて聞いてくれる人が増えたことによる発表側モチベーション増加：5人のためでも15人のためでも資料作りの大変さは同じなので、聞いてくれる人が多い方ががんばれます。
• 人数が増えたことによる発表者側の負荷分散：それぞれの分野に詳しい人が発表側にも回ってくれることで、発表自体の手分けができるようになってきました。
• 新卒・第二新卒メンバが増えたことによる「新人向け」チュートリアルの相対的重要度アップ：OJTだと基礎的な部分が疎かになりがちなので、底上げ系発表の重要さも上がったと思います。

この施策は大変な部分もあるのですが、チームMTGはプロジェクトに関係なくエンジニア同士が顔を付き合わせて話をできる良い機会なので、なんとか続けたいと思っています。
僕が大事にしているものに価値観・空気感の共有というのがあるのですが、そういった意味でも普段エンジニアはSlackでの文字コミュニケーションが多いので、貴重な場の共有機会なのではないかと思います。

また、採用活動の過程で中途で入社される方も出てくる中、チームメンバの顔と名前を一致させる機会としても良いなと。一度発表すれば簡単に顔と名前を覚えてもらえますしね。

3. その他

他にもSlackに技術系channelを作ってコミュニケーションの機会を増やしてみたり、協力会社も含めた勉強会を企画してみたりと色々と画策・実施していることはありますが、その辺りはまたある程度評価ができる段階になったら紹介していければと思います。

まとめ

そんなわけで、僕がBPSに入って5年以上？の間に色々とやってきたこと、やっていることを紹介してみました。
うまくいったのもいかなかったものもありますが、結果としてうまくいかなかったものでも実際にやってみることで教訓と経験を得ることもできましたし、こうした取り組みを会社側としても大事にしているということがメンバーに伝わることが重要だと思っています。

エンジニアが足りない足りないと嘆かれる昨今、ネット上にはSIやエンジニア間の話題も閉塞感や停滞感を憂うものが散見されますが、少なくとも弊社は問題を見つけて解決していこうという意思と気合・投入すべきリソースの確保はできる会社だと思います。
そんな弊社に興味のあるエンジニアの方は弊社採用フォームからお気軽にお尋ね下さい。

ではでは、久々に真面目な話を沢山書いたら疲れましたが、またTechRachoの記事執筆は再会していこうと思います。