delirious thoughts

A blog about anything that I can feel delirious from

ペパボの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%同意します。

まとめ

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


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

「酒を飲みながらコードを書く」というLTをした

ハックガールズpresents システムライトニングトークBar Vol.2」というイベントにお誘いいただき、LTをしてきました。話す方も聴く方もお酒を飲みながらという感じとのことなので、技術的な内容というよりは、軽く聴けるカジュアルな内容がよかろうというわけで、「酒を飲みながらコードを書く」というタイトルで話をしました。

イベントは、渋谷・道玄坂にある実験型イベント企画スペース ヒミツキチラボ Produced by SCRAPで行われました。いらっしゃったのは20人ぐらい?いつも参加するようなイベントとはやや違った感じのお客さんだったように思われましたが、反応もよかったし、もちろんトークしてくださった方々も面白かったし、いいイベントになったように思います。

貴重なご機会を与えていただきまして、ありがとうございました。ハックガールズとあまり近しくなれなかったのが心残りでした。

Gyo - Yo for Go

「Yoはコンテキストだ」。

新時代のコミュニケーションに触れてみようってんで、手遊びに、GoでYo APIのクライアント + Webhookを書いた。まあ、「書いた」とかいうほどのものでもないけど。

こんな感じで使う。以下は、Yoされたら、YoしてきたひとにYoをそのまま返す例。echoサーバみたいなやつ。

package main

import (
    "flag"
    "github.com/kentaro/gyo"
    "log"
)

var apiToken = flag.String("token", "", "API Token")
var port = flag.Int("port", 8080, "Port of the server")
var path = flag.String("path", "/callback", "Callback URL of the server")

func init() {
    flag.Parse()
}

func main() {
    if *apiToken == "" {
        log.Fatalln("API token is required")
    }

    gyo := gyo.NewGyo(*apiToken)
    gyo.Server(*path, *port, func(username string) {
        gyo.Yo(username)
        log.Printf("Sent Yo to %s\n", username)
    })

    return
}

Herokuにデプロイしてみようと思ったけど、面倒になったので、手元で動かしてみて満足した。

どうぞご利用ください。

ペバボのエンジニア職位制度のアップデートについて

ペパボで行っているエンジニア職位制度について、最新情報を共有します。

本エントリの背景

ペパボで行っているエンジニア職位制度(シニアエンジニア、アドバンスドシニアエンジニアの選考)については、制度の運用当初に、当時の責任者であるmizzyさんがPaperboy's engineer evaluation system - Gosuke Miyashitaというエントリで紹介しています。その頃から2年半ほどが経過し、また、責任者が変わったこともあるので、あらためていまはどういう感じなのかお知らせしたいと思います。ちなみに、一般のエンジニア評価制度については、新たに運用開始した内容を、既にペパボのエンジニア評価制度をパワーアップしたでお知らせしています。

本エントリの目的

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

制度の概要

本制度をひとことでいうと、技術専門職(この場合だとエンジニア)における、上級職へのステップアップを定めたものです。その特徴としては、以下があります。

  • 全職種共通の等級から、専門上級職へのステップアップであること(シニアエンジニア、アドバンスドシニアエンジニア)
  • 誰かの任命によるのではなく、本人の立候補により選考過程が始まること
  • これまでの実績、自分を昇格させるべき理由を主張する文書をGitHubのpull requestによって提出し、全社員公開の元にプロセスが進むこと

以下に掲げる文章は、今半期の評価結果について社内向けに書いた文章のうち、完全に社内向けのものを除いたものです。


選考過程

  1. 6/6告知、6/18立候補締め切り
  2. 6/20〜6/24面談
  3. 面談に参加した技術基盤チーム各自の意見を参考にしつつ、antipopの責任において決定
  4. 6/25一次評価結果公開

このあと、6/30の経営会議において、最終決定します。

選考基準

mizzyさんのエントリにある基準に基づき評価を行いました。その際、そこで謳われている「技術力」を以下のように分解しました。

  • 作り上げる力
  • 時間の経過に耐える力
  • 影響を広げる力

作り上げる力

これは、一般に技術力といった場合に想像しやすい能力でしょう。「他の人にはない、技術的に優れた何か」を用いて、技術的に困難な問題を、素早く、確実に解決することができる、ということです。

時間の経過に耐える力

一方で、我々が作るものは、単に一度作れば済むものではなく、継続的に価値を届け続けるべきものです。つまり、ある特定の時点における線の価値のみが高いだけでは不十分です。それに加えて、時間の経過に対して積分的な面の価値を増大させる必要があります。そのためには、設計力、テストを書く能力が必要です。

影響を広げる力

さらには、上記の能力に基づいて、自分や身の回りだけではなく、エンジニアリングにおけるリーダーとして影響力を広い範囲に及ぼせることも、シニア、アドバンスドシニアには求められます。技術的には技術レイヤーの上下方向へ、プロセス的には広い範囲の人々を巻き込んでいく左右方向へ、それぞれ影響を広げていける能力です。

(社内向け文面略)

講評

先述の選考基準に基づき評価を行い、上記の通り1次評価を決定しました。基準のうち、3点とも満たしていることがもちろんよいのですが、今回、すべてにおいて文句なしというひとはいませんでした。そうした条件をすべて満たし、かつそれ以上の成果・能力・影響力を持つ人が、アドバンスドシニアということになるんだと思います。

逆に、不通過とした方々についても、それぞれにおいてもう一歩というところまできていると思います。その点、今後どうしていけばいいのかということについて、面談やコメントを通してお伝えしたつもりです。是非、また次を目指してください。

今回1次通過した人に関しては特に、シニアエンジニアとなった暁には、さらに以下についてのコミットを求めていきます。

  • 他のエンジニアをリードし、技術的な成長を支援すること
  • 社内外(特に社外)へのアウトプットをすること

シニア、アドバンスドシニアエンジニアは、役職上のリーダーとはまた異なる意味において、技術的な知見・能力に基づくリーダーシップを発揮すべき存在です。そこには年齢や社歴はまったく関係ありません。自らの成果を出すことは当たり前、その上で、他のエンジニアたちを引っ張り、成長を支援する存在となることを求めます。

また、ひとそれぞれの性格や取り組んでいる内容などによって打ち出し方は異なってくるとは思いますが、社内で影響力を及ぼしていくことは必須として、社外に対しても、活発に技術イベント等を通してプレゼンスを発揮するとか、あるいはそうしたことが苦手なひとに関しては、OSSを通してアウトプットを行う等、技術の会社としてのペパボという立場をアピールすることに貢献をもとめます。

また、いま現在シニア、アドバンスドシニアエンジニアであるみなさんについても、今回の結果と自分の能力・成果等について振り返り、いまも自分がシニア、アドバンスドシニアという職位にふさわしいかどうかを、真剣に考えてみてください。この職位は「資格」のようなものとは違います。制度の運用から2年半以上が過ぎました。今後の適正な運用と全社の成果向上のために、制度とともに個々の職位についても、適宜見直していきます。


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

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

今月は18冊。最近、雑駁な感じにしか読めてなかったのでよくなかったのだけど、今月は比較的マシな感じで読めたのでよかったかな。

『浅田孝―つくらない建築家、日本初の都市プランナー』は、メタボリズム運動のファンとしては、よく出してくれた!とうれしかった1冊。丹下健三とメタボリストたちのちょうど間の世代に位置する浅田孝は、その知性のあり方やひととなりが、自分的になんだか好きな感じの人物なのであった。

その他、仕事関連であれこれと考えていることがあっていくつか必要な本を読んでいたのだけど(『強い調達』『企業内人材育成入門』『人事管理入門』あたり)、いろいろと学習するべきことは多い。本だけではもちろん足りないが、本を読まなければそれはそれで足りないのである。

今後の予告としては、マネジメントや経営戦略に関する知見の歴史みたいなのに興味を覚えてきた(そのモチベーションは、実用というよりは、純粋に歴史に対する興味の方にずっと近い)ので、そのへんをちょいちょい掘っていこうかなと思っているところ。『マネジメントの世紀』あたりはそういう本。

kentaroの本棚 - 2014年06月 (18作品)
経営を見る眼
伊丹敬之
読了日:06月25日
評価3

powered by booklog

書評『Chef実践入門 コードによるインフラ構成の自動化』

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)』をご恵贈いただきました。毎度ありがとうございます。

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chefについては、先日「書評『Chef活用ガイド - コードではじめる構成管理』」にて、ほぼ同時期に刊行された別の本について述べたところです。僕自身のChefやInfrastructure as Codeへの考えについては、繰り返す必要もないでしょう。そちらのエントリをご覧ください。

さて、こちらの本は「実践入門」というだけあって、実際に手を動かしながらChefに慣れていこうという構成です。Vagrantを用いて、本の記述に沿って試してみるうちに、次第にChefがわかってくるという寸法。『入門Chef Solo - Infrastructure as Code』からブラッシュアップした章もありますし、そのアップデート版といった感じでしょうか。概要を把握しつつ手を動かしていくうちに、ちょっとしたシステムについてなら、それなりにInfrastructure as Codeできるようになりそうです。

また、Chefにあんまり詳しくない僕としては、細かいお作法みたいなものがちょいちょい書かれているのが便利でした。たとえば、以下。

なお、Ohaiの値のキーは:platformとしてシンボルで指定するのに対し、Nodeオブジェクトに定義したものはnode['httpd']['port']とキーに文字列を使うのが慣習です。

(本書p.83)

ifを使うとインデントが深くなり、可読性を落とします。このようなときは、条件付きアクションを使うことでスマートに処理を記述できます。

(本書p.229〜230)

こうしてひと通りのレシピを書けるようになったあと、実際の複雑なシステムに立ち向かった時、読者はその複雑さをどのように読み解き、モデル化し、メンテナンサブルなクックブックに落としていくのかという現実に突き当たると思います。その答えの一端について触れていないわけではないものの、それは本書の範囲を超えるでしょう。その際は、コミュニティのクックブックで設計を学んだり、『Chef活用ガイド コードではじめる構成管理』を読んでさらに知見を深めたりといったことが必要でしょう。

ともあれ、Chefを学びたいひとにとっての最初の1冊として、間違いなくおすすめできる本だと思います。

Casto: 史上最速にライブコーディングができるサービス

CastoというWebサービスがあります。史上最速に、インターネット経由でライブコーディングができる、非常に素晴らしいサービスです。その素晴らしさのわりにまだあまり知られていないので、紹介します。

Castoでライブコーディングを始めるには、ふたつの方法があります。

後者のコマンドの例は、作者によって以下の様なアニメーションGifで紹介されています。

↑の画像では、Casto上のURLをコピペしてブラウザで開いていますが、--browseオプションをわたすと自動的にブラウザで開くよう、pull requestを送って、マージされております。

コマンドについては、最近追加されたのですが、さらに利便性が高まったと思います。是非お試しいただきたいサービスです。