Raccoon Tech Blog [株式会社ラクーン 技術戦略部ブログ]

株式会社ラクーン 技術戦略部より、tipsやノウハウなど技術的な話題を発信いたします。

エンジニア

第5回LT大会 開催

こんにちは、たむらです。

先日第5回技術部LT大会を開催しました。
今回はどんなものが飛び出したかといいますと・・・

~発表されたLTタイトル~
「僕の好きなもの(仮)」
「タダで手軽に本格スマホアプリを作るただ1つの方法」
「Rustに触れてみた」
「ZFSとVMwareでデータベース」
「Jshell」
「メモ帳から任意のコードを実行する」
「JSOX・ISMS担当から見た「システム設計で意識してほしいこと」」
「CORECの帳票の話」
「rasberry pi 3を使う」
「法人番号の検証」
「本当は怖いJavascriptとCSSのパフォーマンスの話」
「Google Cloud Natural Language APIを触ってみる」


LT大会の様子
20160908_162644631

20160908_162659001

20160908_161926201

20160908_152926247


みんなで選ぶ優秀発表者は、
1位:「法人番号の検証」
2位:「メモ帳から任意のコードを実行する」
3位:「rasberry pi 3を使う」
となりました。

1位の内容は、企業版マイナンバーと言われる法人番号の利用方法を検証したものでした。ラクーンではPaidを始めお客様やお客様の取引先情報を扱うサービスを行っているので、そちらへの利用も見据えた検証となっていて非常に意義のあるものになっていました。2位は、Windowsアプリのメモ帳で利用されるDLLをハックしてしまおうというもの。弊社ではWindows系はほぼ利用していないのですが、Microsoft関連に熱い情熱をもっているエンジニアからの発表でした。

次回は年始にまた行う予定です。

第4回技術部LT大会 開催

こんにちは、たむらです。

先日第4回技術部LT大会を開催しました。もう定着している感のあるLT大会ですが、
今回もみんなしっかり準備をしていて、内容も非常にバラエティに富んだものになっていました。

~発表されたLTタイトル~
「軽い気持ちでリモデ」
「SSL証明書やドメインなどの期限管理」
「パソコン少年の成れの果ての懐古(または、劣化移植への限りなき愛情)」
「キャッシュフロー計算書を作ってみた」
「URIHOの社内ツールのモック作成でLESS使ってみた感想」
「コレックウォッチ ~ログ監視のはなし~」
「YeomanでAngularの開発環境を構築して何か作ってみた」
「今年やりたいこと」
「個人事業主や中小企業の主に小の方に売掛保証を広めたいと思った結果」
「キーワードで振り返る2015年IoTトピックス」
「PayPal APIのネガティブテストを作ってみた」
「新監視体制について」
「Seasar2から卒業しよう」

LT大会の様子
注) 窓に貼ってある習字は会社の年始イベントの書初めです。こちらも毎年恒例となりつつあります(笑)。。
DSC_0943
DSC_0951
DSC_0953


みんなで選ぶ優秀発表者は、
1位:「今年やりたいこと」
2位:「キーワードで振り返る2015年IoTトピックス」
3位:「Seasar2から卒業しよう」
となりました。

1位の内容は、年始ということもあり自分の今年の抱負を語るというものでした。仕事に繋がることもプライベートなことも盛り沢山の話で、みんなの支持を集めていました。2位は、Raspbery Pi2からmyThings、SORACOMなどの2015年のIoTを自身の感想を含めて振り返るというもの。本当に多くのサービスと商品が増えてきたIoTですが2016年も更に賑やかになりそうですね。3位は弊社でも利用していて今年の秋にサポートが終了するSeasar2についての見解を述べたものでした。業務上の課題をみんなに共有できていて有意義な内容となっていました。

次回はまた夏から秋ぐらいに行なう予定です。

ここ数年で技術部で定着した制度2つ

こんにちは、たむらです。
今回は私が部門長になった頃に施行されて、今ではだいぶ定着した技術部の制度を2つご紹介しようと思います。

1.技術サポート制度

開発環境の増強及びスキルアップの資金として会社が補助金を支給する制度です。1名につき年度毎に10万円迄が利用できます。開発環境の最適化を支援したり、最新デバイスや技術トレンドをいち早くキャッチアップできることを目的として用意されました。

技術に関連するものであればメンバーが自由に利用目的を選択することができて、多くのメンバーが毎年利用しています。

使われ方としては、大体みんな最初にノートPCを買っています。開発メンバーのメインPCはデュアルモニター+(スペックを考えて)デスクトップという構成なので、ミーティングで利用できるノートPCのニーズが高いためです。その後は開発環境のディスク増設やキーボード、技術書の購入などに利用されていることが多いようです。また、資格試験の受験費用やセミナーの参加費用などにも使われています。

matome3















購入したものの一部。ノートPCやキーボードではかなりメンバーの好みや個性がでます。

予想外の効果も

エンジニアの好奇心を満たす為の福利厚生として生まれたこの制度ですが、思わぬところで予想外の効果もありました。

それはハンズオン系の勉強会が増えたことです。今迄デスクトップPCしか無かったので会議室などで集まって行う勉強会では講義形式が主流でした。それがノートPC保有者が増えたことにより、ハンズオン形式の勉強会が行い易くなり頻繁に開催されるようになっています。勉強会の一例は社内勉強会をご参照下さい。



2.ユニットチーム制度

技術部の開発チームは現在17名の大所帯となっていますが、実際にはユニットというチームで開発業務にあたっています。

ユニットチームの概要
  • 2名~4名の小チーム制
  • プロジェクトや開発業務はこのユニットの単位で行う
  • ユニットセンターという代表者が1ユニットに1名存在。報連相の仲介役
  • ユニットは緩やかに担当するサービスが決まっている
  • ユニットの再編やユニット間の人の移動は年に1回程度人事異動的に行う
  • ユニットには名前を付ける(←大事!名前があると思い入れが違います

このユニットチーム制になったことで、以下の様な効果がありました。

スモールチームによるチーム力の向上!

言うまでもなく、チームは大きくなれば大きくなる程コミュニケーションコストが加速度的に増加する傾向にあります。小さなチームであればそのコストを小さくすることができます。また少人数のチームメンバーで継続して業務にあたることでそれぞれのスキルや性格の理解も深まり、「jsなら彼に任せるのが良い」など、経験に則した信頼関係が築けてチームとして相乗効果が生まれます。スクラムでいうベロシティが測りやすいメリットもあります。

多角化したサービスに柔軟に対応できる

ラクーンでは「スーパーデリバリー」、「Paid」、「T&G売掛保証」、「COREC」と4つのサービスを展開しています。それぞれのシステムには当然開発言語や環境、仕様といったシステム面でのナレッジの他、各サービスについての業界知識も必要となり、とても一人で全てを把握することはできないボリューム感となっています。そこで、各ユニットにはそれぞれメイン担当となるサービスが"緩やかに"割り当てられています。この"緩やかに"というのがミソで、基本はメイン担当となっているサービスの開発をするのですが、大規模なプロジェクトが企画され複数のユニットで担当する時や他のサービスでヘルプが必要な際には別のサービスの開発にも参画できるような運用としています。これによりメンバーが技術的にも業務的にも深く掘り下げて軸になる部分を作るニーズと、会社的にダイナミックな開発計画をとれる柔軟性のニーズの両方を満たせられるようにしています。

業務仕様を現場で判断しスピードUP+やる気UP

ラクーンにもリーダや部長といった役職はあるのですが、一般的な会社の役職者は人事的なマネジメントだけでなく、業務仕様的なイニシアチブもとることが多いと思います。ですが、マネジメント業務もかけ持ちしている状態の役職者が業務仕様まで見ようとするとボトルネックになる上、現場との認識の乖離が起きやすくなる傾向にありました。そこでユニットチーム制を開始するに際して、役職者はあくまで人事マネジメントに注力し、業務仕様面での権限は担当するユニットチームにできるだけ移管し現場チームで仕様決定できるようにしました。ユニットは細かな仕様の決断は勿論、開発案件リストの中で何を実施するかという点も含めて判断を任されています。結果的に開発パフォーマンスが上がり、且つメンバーがやりがいを持てる体制になっていると思います。

教育や研修が実施しやすい

ユニットチームは教育や研修でも効果を発揮しています。少人数のチームなので教育する側とされる側が密にやりとりができる為、目が届いた研修が行えます。また、「個」に合わせた対応が取りやすいことや、教育のサイクルを多くのメンバーが担当することで教える側のスキル向上にも繋がりやすいこともメリットだと言えます。

スケールの調整がしやすい

サービスの誕生やメンバーの増減に対してスケールしやすい構成です。2014年にサービスを開始したCORECも新規事業として一気に立ち上げがありましたが、各チームから人を集めて担当チームを作る形で対応でき、フレキシブルにチームの構成を変化させやすい人数になっています。そんな意味で、例え部門の人数が2倍になってもボトルネックを産みにくく生産性を落としにくい仕組みになっているかと思います。



ラクーンでは、エンジニアが楽しくやりがいを持てて、仲間と共に成長できる環境こそがより良いサービスを生むと本気で考えています。今回はそんな考えの中から生まれてきた2つの制度を紹介させていただきました。

こんな技術部やラクーンに興味を持ち、是非働いてみたい!という方、私達は一緒に働く仲間を随時募集しています。ご応募お待ちしております。

ラクーンのエンジニア評価制度について

こんにちは、たむらです。
今回は、ラクーンのエンジニア評価制度についてのアレコレを書こうと思います。
ラクーンがエンジニアに活き活きと仕事してもらう為にどの様に評価制度を考えているかを知ってもらうキッカケになればと思っています。

評価制度の一般論
 さて、会社の評価制度というものはエンジニアという職種に限らなくてもどの会社でも非常に苦慮して作り上げているものです。働くすべての人のあらゆる状況を正しく評価することはとても難しく、過不足やいびつさを抱えているものが殆どなのではないかと思います。みなさんの会社ではどの様な評価制度で評価されているでしょうか?またその評価制度に満足されていますか?
 私は人事の専門家では無いので正確性は危ういところがありますが、経験上エンジニア界隈で適用されている評価制度は以下の様なものが一般的かと思います。
1. 職能給制度
  スキルレベルにより評価されるものです。号棒と呼ばれるレベル表を定義し、その昇降により給与(=評価)を決めるような方式になります。スキル評価としての建前がありますが、実際にスキルを詳細に定義することは難しく、得てして年功序列的な運用になりやすい面があります。
2. 成果主義による評価制度
  その名の通り、業務の過程は考慮せず、成果のみによって評価する方式です。売上や利益といったもので定義されることが多く、評価基準の分かりやすさがメリットと言えます。エンジニア職種に対しては絶対的な評価基準は定義し難い為、指標が多岐にわたることが殆どです。その為分かりやすさは一段劣る印象があります。
3.目標管理との連携
  多くは期初に業務に則した目標を立て、その達成度により評価をします。個々人のレベルに合せてそれぞれが定義することが多く、成果主義を属人化させたものといえるかもしれません。売上等の統一の評価基準を用いない場合はメンバー間での絶対的な評価が分かりにくくなる傾向にあります。

実際のところ多くの企業では、上述のどれかを適用しているというよりは、それぞれの良い所をうまく取り入れつつ評価制度を組み立てているところが殆どなのではないかと思います。中には名目上は「成果主義」だが、実際にはろくに予実管理も面談もせずに上司の胸先三寸で決まる「ブラックボックス評価制度」というところもあるのかもしれません。


過去のラクーンのエンジニア評価制度
 ではラクーンではどうなのかというと、過去ラクーンでは上で述べたものの1つである「目標管理と連携した評価制度」をエンジニアの評価に利用していました。しかし、この制度には職務的に合わない部分があり見直されることになりました。
 合わない点は2点あります。1つ目は業務内容が目標設定時から変化することが多い点です。例えば目標設定時はプロジェクトAに参画することが予定されていた為、「プロジェクトAでの不具合摘出率を前回参画プロジェクトの半分にする」という目標を立てたが、プロジェクトA自体が実施されなかった、というようなケースです。ラクーンでは実施する案件はその時の状況により都度見直しが入るので、この様な目標倒れがしばしば起きました。
 2つ目は実業務との乖離です。1つ目の反省を踏まえて、目標を実業務から離れたものに設定したことがありました。例えば「未経験のRuby on Railsをマスターし、公開アプリを作成する」などです。業務の隙間時間でスキルを向上させてもらい、その成長を評価しようとの目論見でしたが、逆に本来評価の対象とすべき実業務の評価と離れたものとなってしまい、妥当性を欠く結果となってしまいました。


評価制度見直しに際してのポリシー
 この様な経緯から然るべき評価制度に対しての必要性が高まったのを踏まえて、評価制度の見直しが行われることになりました。策定にあたりポリシーとしたのは以下の点です。
「エンジニアのスキルアップの指針(キャリアパス)となり得るもの」
「客観性・納得感があるもの」
「エンジニア以外に対しても分かり易い評価軸を持ったもの」
「モチベーションの向上に繋がるもの」

このポリシーに則り、実際に働くメンバーにも検討に加わってもらいながら、評価制度の見直しを行いました。
その結果、現在適用している評価制度は「スキルベース評価」、「スキルシート管理」、「資格制度」、「360度評価」に表されるものです。順に概要を説明させてもらいます。


スキルベース評価
 まず、前提とするのはラクーンでのエンジニア評価はスキルをメインとしているということです。エンジニアという職種である以上、その技術力を評価の中心に据えようという思いがあります。そこで観点とする「スキル項目」を選定し、それに沿って評価することを評価の主軸としました。「スキル項目」は大きく分けて5つのカテゴリに分かれており、①技術スキル、②言語スキル、③ヒューマンスキル、④業務スキル、⑤アドオンスキル となっています。①~③は6段階評価、④、⑤は3段階評価としています。

スキルカテゴリの概要
スキルカテゴリ














評価の際に一番重きを置かれるのは ①技術スキル になります。なぜ ②言語スキル や ④業務スキル が入らないのかというと、言語やシステムは新陳代謝がある為です。そこで、よりエンジニアスキルの本質となる要素にターゲットを絞ることで、評価に恒常性をもたせることを意図しています。


スキルシート管理
 スキル項目に沿って、全エンジニアのスキルをスキルシートという表にまとめ、一覧できる様にしています。これは部門内で誰でも参照できる様にしていてスキルの見える化に繋げています。但し、過剰に上下関係を表し人間関係が崩れてしまうことがないように、①技術スキル~③ヒューマンスキル に関しての数値は評価者及び本人以外には公開せず、全体公開するのはある一定のレベル以上かどうかのみ公開するようにしています。
 元々見える化というのは会社にエンジニアの評価を分かり易く伝えたいという意図の他に、メンバー間での教育関係が生まれやすくすることも目的の一つとしています。その為メンバー間においては上下関係を知るというよりも誰に聞けばいいのか?誰が教えるべきなのかが分かることが見える化の大事なポイントだと考えています。

実際のスキルシート
スキルシート


















資格制度
 ラクーンでは会社独自の資格制度を持っていて、その中に「特定分野の専門知識、経験を持つ人」に与えられるスペシャリスト資格(社内では通称S資格と呼んでいます)が存在します。レベルによりS1,S2と2段階あり、年収の想定レンジで言えば750万円~1000万円以上をイメージしています。
技術戦略部のS資格としては、シニアエンジニアや、プロジェクトリーダ、インフラエンジニア等が定義されています。
 さて、このS資格はそれぞれ資格取得条件を定義することになるのですが、それをスキルレベルと紐付ける形で定義しています。それにより、「自身の現在のスキル」、「伸ばすべきスキルの方向性」、「会社的な評価(S資格の取得)」が同じ軸で考えられるようにしています。


技術部で現在用意しているS資格とその資格条件
スキルマップ1







スキルマップ2









360度評価
 評価査定は年に2回半期毎に行いますが、その時に上述のスキルシートの更新を行い、評価資料として用います。
スキルシートの更新の際にはなるべく多角的な評価を集めるため、メンバー間相互評価を集めたり、資格所有者に更新内容の妥当性の検証をしてもらったりといった360度評価の仕組みを取り入れています。
上司からの評価だけだと実業務の目線から離れていることも多く、実際の技術スキルを測るには限界があります。その補完としてメンバー同士からの評価を用いています。また、いつも進捗が遅れがちだが、実際には他メンバーの相談や質問に親身にのっていて他メンバーからの信頼がとても厚い人等、目に見える成果では測れない貢献者を認知する手段にもなっています。

まとめ
 ザックリとした説明になってしまいましたが、こんな仕組みでラクーンではエンジニア評価をしています。
この評価方針はここ1年位で見直した結果なのですが、この事実が物語る通り、今後も必要があれば都度見直しをしてどんどん変化していくことになると思います。ただ、あくまでその目的は、エンジニアが活き活きと仕事ができることや、長くラクーンで働いていきたいと思えることに繋がるべきであると思っています。

最後に・・・
私達は一緒に働く仲間を随時募集しています。
この評価制度の話なり、ラクーンのビジネスモデルなりをちょっとでも面白そうだなと思ってくれた方、是非一緒に働いてみませんか?
ご応募お待ちしております!!

記事検索