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

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

ラクーン

第3回技術部LT大会 開催

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

先日第3回技術部LT大会を開催しました。
昨年から部内研修として開催しているLT大会ですが、今回も個性溢れるテーマが取り上げられました。普段あまり接点のない部内メンバーの業務内容も伺えるものになっていて、メンバー間の相互理解にも一役買いそうな内容になっています。今回のLT大会では今年の新人が早速発表したり、来年度の内定者を招いたりと賑やかなイベントとなりました。

~発表されたLTタイトル~
「はじめてのSOAPへGo」
「NetBeansのプロファイラを使ってみた」
「PowerShellを使ってみた」
「ピュアSQLで数独を解いてみた」
「fumiのマスコットを作ってみた」
「「クエストフェーズ解決ミニアプリ」ではなぜRIot.jsを採用したか?」
「オラクルマスター12Cのブロンズを受験する為の基礎の参考書を読んでみた」
「あのAmazonも使っているApache FOPで請求書を作る」
「SDのSVNをGit&GitHubに移行したい件」
「ぼくと
の100日戦争」
「backlog APIとWebhookを使った家庭内タスク管理」
「ラクーンに入社して」
「俺のオンラインストレージ ~ ownCloud on AWS ~」

LT大会の様子
DSC_0796
DSC_0806
DSC_0814
DSC_0803

今回の結果は、
1位:「ぼくと○○○の100日戦争」
2位:「ピュアSQLで数独を解いてみた」
3位:「NetBeansのプロファイラを使ってみた」
となりました。

1位のネタは、スピーカーのエンジニアが、とあるスマホゲーム攻略アプリを作った際に実際に起きたエピソードで、会社オフィシャルの当Blogにはちょっと詳細を書けない様な内容でした(笑)。ただ、誰もが知っているスマホゲームで内容も技術的な知見を含むリアリティのあるトークだったことから、ダントツの1位となりました。
2位は「数独問題をバインド変数でインプットデータとして与えると、答えを返してくれるSQL」を作成するという、ちょっと宇宙人的な発想と超人的なSQLスキルを持ったスピーカーならではと言える内容でした。

次の開催は来年の1月頃を考えていますが、段々レベルが上がってきているので次回も楽しみです。

ここ数年で技術部で定着した制度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つの制度を紹介させていただきました。

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

第2回技術部LT大会

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

先日第2回技術部LT大会を開催しました。
今回も個性的な発表が多く、実際に業務に使えるものからメンバーの趣味趣向が伺えるものまで幅広いテーマが取り上げられていました。


~発表されたLTタイトル~
「Spring Batch」
「WSHによるPC管理」
「Selenium。基礎の基礎から。」
「5分じゃ分からない内部統制」
「Windows Phone 8のハナシ」
「Raspberry Piで遊んでみた」
「社会学におけるネットワーク」
「Heroku使ってWEBアプリ1つ作ってみました」
「業務効率とUI」
「パズルを解くアルゴリズム」
「GIT DIFFのマニュアル読んでみた」
「ある2日間ハック」
「目の前の仕事を目的にしないための取り組み」


LT大会の様子

25 - 425 - 1325 - 1525 - 5

























































投票結果は以下の通り。
1位:「ある2日間ハック」
2位:「5分じゃ分からない内部統制」
3位:「Raspberry Piで遊んでみた」

1位になった「ある2日間ハック」は、請求書にカスタマーバーコードやEANバーコードを付けたいという要求にgo langを使ってさらっと対応できたというもの。発表者は社内のプレゼン研修等でもいつも上位にいるメンバーで、内容もプレゼンも素晴らしいものでした。

余り仕事で接点のないメンバーの興味や考え方を知る意味でも面白いイベントなので来年以降も続けていこうと思っています。

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

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

評価制度の一般論
 さて、会社の評価制度というものはエンジニアという職種に限らなくてもどの会社でも非常に苦慮して作り上げているものです。働くすべての人のあらゆる状況を正しく評価することはとても難しく、過不足やいびつさを抱えているものが殆どなのではないかと思います。みなさんの会社ではどの様な評価制度で評価されているでしょうか?またその評価制度に満足されていますか?
 私は人事の専門家では無いので正確性は危ういところがありますが、経験上エンジニア界隈で適用されている評価制度は以下の様なものが一般的かと思います。
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年位で見直した結果なのですが、この事実が物語る通り、今後も必要があれば都度見直しをしてどんどん変化していくことになると思います。ただ、あくまでその目的は、エンジニアが活き活きと仕事ができることや、長くラクーンで働いていきたいと思えることに繋がるべきであると思っています。

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

記事検索