delirious thoughts

A blog about anything that I can feel delirious from

GMOペパボのエンジニア新人研修 #lldiver

LL Diver | Dive into Lightweight Languagesで、「GMOペパボのエンジニア新人研修」というタイトルで話をしてきました。エンジニア新人研修については、その実施自体には、僕は既にあんまり関わっておらず、主にid:hibomaや新卒出身の若者たちが担っているのですが、その背景となっている考え方について一度まとめる必要があるなと思っていたので、この機会にまとめてみました。

いろいろ書いていますが、エンジニアがより楽しく働けるようにし、そのことでより高い成果を出すためにあれこれとやっているところです。ご興味を抱かれた方は、是非、以下をご覧いただきたく思います。

RESTが日本で受け入れられていった頃の話( #mozaicfm の補足)

mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。

まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。

また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:secondlifeの話が語られるわけですが、日本での受入の端緒の情景としては、Jxckさんの回想に同感を覚えます。

ただ、若干時間の感覚にズレがあって、Podcastの中でAjaxの文書が2006年だと述べられていたけれども、それは2005年の2月で、さらには前述の「第八回XML開発者の日」はその年の11月にあって、わりと早い時期から日本のWeb開発者はRESTを受け入れていったわけです。

なんで僕がそんな細かいことをいちいち憶えているかというと、

といったことがあったからなわけです。その頃の様子は、たとえばこのブログの以下のエントリに記されている。

その流れから発して、以下の様な文書を書いたりした。

その頃のアツかったWeb界隈の動きがtumblr 創世記 その四 (ヤバイ、JavaScriptマジヤバイ の巻) - tumblr - たんぶら部 - Tumblove -にまとめられていて、懐かしい思いを感じる。

日本でのRESTの受け入れには、JavaScript界隈の動きが大きく関わっていた。なぜなら、Ajaxが現れたことで、フロントエンドとバックエンドとの区別が意識されることになり、そのことでRESTというアーキテクチャスタイルの存在が浮かび上がってきたからだ。少なくとも、僕の見ていたところでは、そういう流れであったように思える。

というわけで、別になにかのオリジンを主張したいわけではなくて、そういうことがあったなあという、Webおじさんの昔話でした。

`gate`をGitHub対応した

Google認証なリバースプロクシ&静的コンテンツ配信サーバー「gate」 - unknownplace.orgで紹介されている、typesterさんのgateという、GoogleのOAuth2認証付きプロキシサーバがとても便利そうだったので、即座に使いたくなった。

これは、昨今増えつつあるメトリクス系のツールだとかの、インターネット上に置きつつも、社内のみに提供したいサービスを立てるに際して、フロントにnginxをおいた場合に、認証のことを考えるのがだるい、というか、nginxの設定自体がだるいみたいなときに役立つツールです。その際、自分とこ的にはGitHubのorganizationでアカウント管理できるとさらによいので、GitHub対応をしてpull requestを送ったところmergeされました。ありがとうございます。

会社で運用しているorganizationがfoo_organizationbar_organizationとあって、それらのメンバーだけにアクセスを許可したい場合、設定ファイルに以下のように書くといいかんじになります。

auth:
  info:
    service: github
    client_id: your client id
    client_secret: your client secret
    redirect_url: https://yourapp.example.com/oauth2callback

# restrict user request. (optional)
restrictions:
  - foo_organization
  - bar_organization

早速、社内ツールのサーブに使ってみたいと思います。

RailsでTypeScriptを使う

JavaScriptは設計が難しい。経験上、すぐグシャグシャになってしまう。よくわからなくなる。もちろん、私のスキル不足というのはあるだろうけれども、スキルが不足してるのはしかたないので、学習は続けることは前提であるにしても、技術的に解決できるなら技術に頼りたい。そうした意味で、いわゆるAltJSの中ではTypeScriptが有望だろうと思う。

RailsとTypeScript

TypeScriptを使うにしても、それ単体で使うというシーンは、Webアプリケーション開発という文脈ではあまりない。たとえば、Railsで開発しているWebアプリケーションのフロントエンドを構成する言語として使うことになるだろう。その際、まず考えるべきことは、Asset Pipelineとどう折り合いをつけるかということだろう。

Asset Pipelineは、以下の機能を担っている:

  • 拡張子(例:application.js.coffee)により、各種言語のフロントエンドを判別し、最終的なプロダクトとしてのJavaScriptCSSを書き出す
  • 多数からなるそれらのファイルを、任意の数にまとめる
  • 一意のsignitureをファイル名に付与することで、ブラウザキャッシュとの折り合いをうまいことする

技術要素のライフサイクル

Railsから、フロントエンドを成す言語(coffee scriptやSassなど)を使う場合、一般には、それらに対応したRailsプラグイン的なものを使うことになる。それはそれでよいのではあるけれども、それらの処理系、あるいは、それがライブラリをも含む場合(jQueryとかBackboneとか)においては、Railsのライフサイクルとそれらのライフサイクルが異なりうる。すなわち、JavaScriptのライブラリやその派生言語であれば、それらのライフサイクルに基いて管理する方が適切であるという判断があり得る。

TypeScriptの場合、typescript-railsというプロダクトにより、Asset Pipelineの仕組み上でいい感じにしてくれるものがあるのだが、上記した通り、そもそもRailsとライフサイクルの異なるものを扱うのであれば、わざわざRailsに合わせる必要もないというのもひとつの考えだ。その場合、Railsの外で、自前でビルドする仕組みを用意することで、Asset Pipelineに頼らない環境を作るという選択肢もあるだろう。

Gulp + Rails

そのような環境を構築するに際して、それはそれでいろいろな選択肢が考えられるが、ここではgulp.jsを使ってみたいと思う。これは、単に私がそもそもフロントエンドまわりの技術に明るくないため、流行っていそうなものがよさそうだと思ってしまう偏向の現れである。

gulp.jsは、makeやrakeやその他もろもろそういった、処理の自動化を担当するツールである。まあ、rakeでもなんでもいいんだろうけど、今回使用するのはTypeScriptであるし、また、フロントエンド周りの各種言語、ツールへの対応が充実しているようなので、gulpを使うことにした。

全体としてはkentaro/gulp-for-railsに書いた通り。

gulpによるTypeScriptのビルド

TypeScriptは、JavaScriptコンパイルすることによって最終的な実行ファイルを生成するタイプの言語なので、Web開発においては、できるだけ楽な方法を採ることにより、開発スピードをさまたげないようにしたい。そこで、以下のようなgulpfile.jsを用意した。やっていることは単純で、app/assets/typescript以下にあるTypeScriptで書かれたファイルを監視して、JavaScriptコンパイルするというだけのものである。

var gulp = require('gulp');
var plumber = require('gulp-plumber');
var typescript = require('gulp-tsc');

gulp.task('typescript', function(){
  gulp.src(['app/assets/typescripts/*.ts'])
    .pipe(plumber())
    .pipe(typescript())
    .pipe(gulp.dest('public/javascripts/'))
});

gulp.task('watch', ['typescript'], function() {
  gulp.watch('app/assets/typescripts/*.ts', ['typescript'])
});

ちなみに、gulp-plumberを使っているのは、TypeScriptのコンパイルエラー時にgulpプロセスが落ちないようにするためのものである。詳細は、このGistの通り。

しかし、これをいちいち手動で起動するのは面倒なので、config/initializers/gulp_wathcer.rbに以下のような記述を行うことで、rails s時に自動的にgulp watchするようにした:

if Rails.env.development?
  pid = fork { exec 'gulp watch' }
  Process.detach(pid)
end

Asset Pipeline置き換えに向けて

上述のAsset Pipelineの機能のうち、上記だけだとTypeScriptをコンパイルし適当な場所に配置しただけであり、その機能の置き換えにはなっていない。とりあえず、RailsとTypeScirptを使ってみたかったぐらいの感じで試したので、上記はそこまでに留まっているが、それ以上に事を進めるためには、たとえば以下のエントリが参考になると思う。

まとめ

  • Railsと、JavaScriptあるいはそのライブラリとはライフサイクルが違うので、別に管理するという選択肢があり得る
  • TypeScriptとってもいいので、Railsや他のフレームワーク/言語に基づくプロダクトでも使いたい
  • いろんなツールを使えば、Asset Pipelineを置き換えることもできそうなので、がんばろう

しかし、Asset Pipelineを置き換えようと思うと自前でやることが多すぎるので、もっといい感じの仕組みがあるとよいなあとは思う。というか、Railsにもフロントエンド周りの現状にも明るくないので、こうやるのがベストプラクティス!みたいなのを知りたいところ。

GMOペパボ株式会社の技術責任者に就任いたしました

標題の通り、8/1付けでペパボの技術責任者に就任しました。あわせて、@hsbtさんがチーフエンジニアに就任しました。技術者の体制を強化したことで、Webサービス事業者、すなわち、技術の会社として、さらに高い成果を出していけるよう努めたいと思います。

ちなみに、CTOでも役員でもありません。たとえていえば、技術部長みたいな感じの立ち位置です(うちには技術部という部署はありませんが)。

ところで、その技術責任者の主な役割を、以下のように定義しています。

  • 技術的な会社の意思決定に貢献し、また技術面における中長期的な計画の策定・執行を行う。
  • 経営陣、幹部会議、技術基盤チーム及び技術専門職へ情報の橋渡しを行う。
  • 技術専門職の人事、技術基盤チーム予算に関する責任を有する。

会社におけるエンジニア出身の幹部として、適切な経営判断に貢献するとともに、それを技術者に橋渡しをし、また、技術者がより力を発揮できるような組織づくりをしていく、そうした役割です。技術と経営とを、どちらにもコミットしつつ直接つなぐという意味で、一歩踏み込んだ体制を、今回つくり上げることができました。

また、その一方で、ペパボのNo.1技術者として社内外において代表的な役割を担うのが、@hsbtさんのチーフエンジニアという役割です。技術マネジメントと技術的実行力とを我々ふたりが分担することで、さらに強力な体制になったと思います。


……といった社内のことはさておき、みなさんに特に関係するのは、以下2点でしょう。

  • 技術的プレゼンスの向上
  • 技術者の採用

このふたつも、もちろん技術責任者がその責任を担っている事項です。持続的成長を可能にするためには、社内外から優秀なエンジニアを増やしていくことが絶対条件です。そのためには、対外的には技術的プレゼンスの向上を果たし、対内的には各種制度の整備を通してエンジニアが成果を出しやすい環境を作る必要があります。

対外活動については縷々行っているところですが、対内的な活動についても、たとえば評価制度などをこのブログでも何度か書いたりしているところです。

そうした活動の結果、ペパボのことを知って興味を持っていただき、結果として入社につながることでエンジニアが増える。そして、エンジニアたちが適切な制度の元で大いに力を発揮し、成長ができる。そうした環境を作りつつあるつもりです。是非、我々と一緒に成長していきましょう。

2014年7月に読んだ本をブクログでふりかえる

今月は18冊。

経営コンサルタントの書いた小説というジャンルがあるわけだけれども、そうしたものをちょっと読んでみようと思って、代表的なものを4冊ほど読んだ。三枝さんはほんとにすごいなーとあらためて驚嘆したので、伊丹先生との対談本もついでに読んだり。

その他、会計やファイナンスについての知識を多少は持っておく必要がいろんな意味であるよなと思っているところなので、入門書的なものをいくつか読んだ。かっちりした教科書も買ってあるので、ぼちぼち読んでいきたいとこおr.

『ボヴァリー夫人』をあらためて山田訳で読みなおしたので、いよいよ蓮實重彦先生の『『ボヴァリー夫人』論』へと読み進めていく。

その他、出色だったのは『エッセンシャル・スクラム』と『クリエイティブ人事』。おすすめ。

kentaroの本棚 - 2014年07月 (18作品)
戦略参謀
稲田将人
読了日:07月20日
評価3

人事の定量分析
林明文
読了日:07月26日
評価4

経営参謀
稲田将人
読了日:07月27日
評価3

powered by booklog

ペパボの2014年上半期エンジニア評価について

ペパボの新しいエンジニア評価については、ペパボのエンジニア評価制度をパワーアップしたで既にお知らせしたところです。さて、今回その評価が終わり、総評を書いたので、さしつかえない範囲で公開します。

ちなみに、技術上級職については既に「ペバボのエンジニア職位制度のアップデートについて」で紹介しています。そちらも御覧ください。

制度の概要

そのエントリにもある通り、新しい制度では、以下の特徴があります。

  • エンジニア全員を、エンジニア集団である技術基盤チームが評価する
  • GitHubに評価用の提出資料をまとめpull requestを出してもらい、それに基いて、結果も含めて全員にオープンな状態で評価する

あらためて上記のエントリを引用すると:

今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させていくには、やはりそれを現に行う個々人(ここではエンジニア)の特殊な観点も必要と考えます。

そうした「観点」について、今回の制度はエンジニア全般に対して適用されるものなので、みんなにとって納得感のあるものでなければなりません。そこで、エンジニア全員に対して行ったアンケート結果を元に、技術基盤チームにおいてとりまとめ、以下の画像にあるようないくつかの軸を抽出しました。その過程で、自然と「大切にしてほしい3つのこと | 採用情報 | GMOペパボ株式会社」にあるような3軸にすんなりとハマったので、それをそのまま使うことにしました。

本エントリの目的

そのような、いってみれば内輪の話の共有を、ある意味わざわざ行う目的は、エンジニアとしての将来をあれこれと検討している社外のエンジニアのみなさんに対して、ペパボについて考慮の範囲に入れる材料としていただき、ひいてはよい形で入社していただくことで、ともに会社の成長を実現していきたいと考えるからです。


評価過程

  1. 新しいエンジニア評価制度について、経営会議を経て決定
  2. 4/17,18 福岡、東京で説明会
  3. 中間の成果について記入告知
  4. 評価スケジュール告知
  5. 7/4 資料記入締め切り
  6. 7/7〜7/9 福岡にて面談
  7. 7/14〜7/18 東京にて面談
  8. 上記面談後、最終結果をantipopの責任において決定

評価基準

以下の基準に基づき、各人の等級に沿った期待との比較のもとで、評価を行いました。

  • みんなと仲良くすること
    • まわりを巻き込もう
    • 遠慮はしない
  • ファンを増やすこと
    • 形にしよう
    • 技術はユーザーのため
  • アウトプットすること
    • なんでもオープンに
    • まず手を動かそう

詳細な内容については、スライド「ペパボのエンジニアの仕事を「もっとおもしろく」する」に掲載した通りです。

評価指標について

指標自体は、これまで同様、以下の4種類です。

  • S: Excellent 期待を上回る
  • A: Good 期待通り達成
  • B: Average 普通
  • C: Poor 悪い

この時、「期待」とは何かということが問題になります。評価者は、期待とは、職務上求められること以上のことを成し遂げてほしいという思いであると認識しています。イメージにすると、以下の図のように考えています。

期待と成果に関するイメージ

すなわち、職務上求められていることを行ったというのはB、上記の定義における「期待」通りであればAという結果をつけています。なぜそのように「期待」を捉えるのかについては、Aが昇給と結びついていることからして、明らかでしょう。

総評

新しい評価制度を運用し始めて、まずはひとサイクルまわりました。いろいろと不足があってみなさんにはご迷惑をおかけすることもありましたが、改善するべき点ははっきりしましたので、よりよい制度となるよう今後も改善を続けるとともに、ひいては業績向上に資するものとしていきたいと思っています。

よかったこと

さて、2014年上半期評価をふりかえってみたいと思います。まず、評価者としてやってよかったと思っている点について。

提出資料について

今回の制度から、シニア、アドバンスドシニアエンジニア同様の資料を提出するようにしたのですが、そのことで、以下の良さがあったと思います。

  • 毎日の日報でのアウトプットの質・量が向上した
  • 資料フォーマットをあらたに策定したことで、半期ふりかえりの質・量が向上した

ほうぼうで何度もいっていますが、評価制度というのは、単に最終的な結果を確認すればそれでよいというものではありません。そこにいたるまでのアウトプットを改善しなければ、最終的な結果がよくなることはありえませんし、ひいてはそれを次期の改善につなげなければ業績向上に資することもあり得ません。

その意味で、エンジニアのアウトプットの質・量が向上したのは目に見えてよかったことだと思いますし、他の職種や役職の方々にも真似していただきたいと思います。

エンジニア目線の評価

エンジニア集団である技術基盤チーム主体の評価制度になることで、面談等を通じてのコミュニケーションにおいて、これまでとは違った視点が入ることになり、以下の良さがあったように見受けられます。

  • エンジニアとしてどうあるべきか、今後のキャリア、技術的側面から評価が行えた
  • 上記6つの評価軸に基いて、適切な評価基準を各自の中に持てるよう働きかけが行えた

エンジニア目線での評価ということで、技術的な詳細に気を配って評価を行えたのは、この制度の一番の利点でしょう。また、エンジニアとして事業にどう関わっていくべきかについて議論を行い、また、こちらからも考えをお伝えできたのもよかったです。

また、これはたくさんのひとにお話していますが、自己評価は適切に持たなければなりません。自己評価が低過ぎるのも高過ぎるのも、よりよい成果を出すに際して、マイナスになると考えます。そのような考えに基いて、自己評価と1次評価とのバランシングをできたことも良かったと思います。

改善してほしいこと

次に、改善てしてほしいことについて。

評価にのぞむ姿勢

どんな評価でもそうである、あるいはそうであるべきだと思いますが、この評価も単に「上」のひとが一方的に点数をつけるようなものではありません。

評価の説明会の時から再三述べているように、日々の振り返り、定期的なふりかえりを通じて、最終的なアウトプットを高めるのが制度の目的です。そして評価の場に、そのアウトプットを持ち込んで、よりよい評価結果というアウトプットを、評価者と被評価者との協働でつくり上げる、そういうものとして制度をとらえてほしいです。自分で成果を説明し、説得するぐらいのつもりで臨むのが望ましいです。

そういう姿勢で臨むことにより、前述したような適切な自己評価が可能となり、6つのそれぞれの軸において、自分の果たすべきこと、それが誰のどのような価値になっていくのかというストーリーが、自分の中で明確にできあがっていく。そのことでよりよい成果と、結果としての評価につながるのだと思います。

アウトプット

「みんなと仲良くすること」「ファンを増やすこと」とくらべて、「アウトプットすること」が全般的に評価が低めになっています。面談の中で多くお話した内容を、以下にまとめておきます。

アウトプットといった時に、たとえば外部のカンファレンスで技術発表を行うというようなものが想起されると思います。もちろん、それはそれでアウトプットとして高く評価しますが、そのイメージだけにしばられるのはそれはそれでよくないと考えます。たとえば、ちょっと考えるだけで、外部イベントでの発表以外にも、これぐらいはできることがあります。

  • 内部: GitHub/GH:EのissueやWikiや社内ブログにチーム内/チーム外で役立つ技術情報を書く、社内勉強会を行う、コードレビューやissueで議論をする
  • 外部: 技術に関するブログを書く、OSSにコントリビュートする、OSSを開発する、社外のエンジニアと交流する

他にもあげていけばキリがないほどあるでしょう。こうしたことを多くのみなさんが積極的に行っていけば、エンジニアの仕事ぶり、ひいては全社的なそれが飛躍的によくなっていくものと確信しています。

エンジニアがアウトプットすべき理由 | 外道父の匠」というエントリも是非ご参照ください。評価者はこれに100%同意します。

まとめ

エンジニア個々人としては、より意義のある働き方ができるように、会社としては結果としての業績向上のため、この制度をよりよく運用していきたいと思っていますので、上記を各自でよく含まれた上で、下半期以降も張り切ってやっていきましょう。よろしくお願い致します。


というわけで、ペパボではこんな感じの制度を運用しながら、エンジニアがよりよく働ける環境作りを大切にしつつ、ひいてはそのことが事業の成長につながることを確信して日々やっていっています。興味のあるかたは、是非以下をご覧になっていただきますよう、お願いいたします。もちろん、僕個人に直接ご連絡くださってもかまいません。