技術組織をスケールするためのCTL = チーフテクニカルリード - Kentaro Kuribayashi's blog
GMOペパボにおいて、チーフテクニカルリード(略称: CTL)という職位を作りました。既に以下のブログエントリで新任の2人がエントリを書いているところですが、制度設計者として、その背景を述べてみたいと思います。 diary.shu-cream.net ten-snapon.com GMOペパボの執行役員CTOになって1年半*1、その前に技術責任者に就任してから早2年*2が経過しました。その間、組織面においては、「いるだけで成長できる環境」*3、技術面では「事業を差別化できる技術」*4というコンセプトでやってきました。まだ道半ばではあるものの、逆にいえば、通るべき道は見えているともいえます。 そんな中で、この2年間、ずっと気にかかっていることがありました。 組織的にはエンジニアの人数が90人弱になり、近いうちに100人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
マネジメント3題噺: いいじゃん・いい感じに・バーンと - Kentaro Kuribayashi's blog
こんなことを書いた。 私のマネジメントスタイル、「いいじゃん」「いい感じに」「バーンと」の3つしか話してない。— あんちぽちゃん (@kentaro) July 6, 2016 というだけだと雑過ぎて酷い人間にしか見えないので、補足する。 世の中にはいろんな環境があるだろうが、そもそもうちのような採用を重視している会社では、基本的に信用できる人々で構成されていることが前提。その上で、たくさんの人々との関係性の中で、成果を最大化するに際して重要だとおもうことに、以下の3つがある。 つねに肯定的・ポジティブ 仲間を信頼して任せる 大きなスケール観を持つ 細かいことや短期的な観点からいうと「もうちょっとどうかしてほしい」という気持ちになることはある場合もあるだろうが、そこはいったんぐっと引いて置いておく。その上で、上記の3つを伝え、お互いに内面化し、その考えを元に実行していくことがよかろうと思っ
Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - Kentaro Kuribayashi's blog
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
2014年のふりかえり - Kentaro Kuribayashi's blog
年の瀬なので、2014年をふりかえる。 2014年の抱負 「2014年の抱負」で抱負を述べた(いま初めて再読した……。本来、こういうのはもっと定期的にふりかえるべきだろう)。ちょっと長いが、引用。 私の本業はなんでしょうか。それはソフトウェアエンジニアです。もうちょっと広くいうと、問題の発見・解決をするに際して、技術的観点からそれを行う専門家といったものです(まあ、それをソフトウェアエンジニアというのでしょうけれども、ちょっと違う)。そのように自己認識を行うと、単にソフトウェアエンジニアというところからは、いろいろとやるべきことが広がってきます。いつかtagomorisさんがいっていたように、自称が自認を決定するわけです。 もちろん上述認識は、ソフトウェアエンジニアという自己規定を包含している、というか、それに基礎づけられているわけですから、まずはその方面においてさらに自己研鑚を行っていく
組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog
この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。
エンジニア/エンジニアリングのビッグピクチャ - Kentaro Kuribayashi's blog
社外のある技術者たちと「会社のエンジニア、あるいは、エンジニアリングがどうなっていくべきかというビッグピクチャみたいなものがあるか？」という話になった。その場ではいろいろな内容が出てきたわけだが、不詳わたくし、技術責任者という役職を務めている者としてどう思うかというと、そんなにかっこいいことを考えているわけではなかったりする。実際にかねがねいっていることがあるとすれば: 変化に対応できるよう、エンジニアとして成長しつづけよう 他のひとにない、何か自分が一番の得意分野を作ろう というぐらいである。このフレーズだけでいえば、なんのことはない、いってみれば当たり前、というか、誰でも思いつくような話だ。しかし、ことはそう簡単ではないと思っている。 ひとくちに「成長」といったところで、どれぐらい成長すればいいのかという問題がある。一番わかりやすい基準は、我々は上場企業であるということからいうと、市場
GMOペパボのエンジニア新人研修 #lldiver - Kentaro Kuribayashi's blog
LL Diver | Dive into Lightweight Languagesで、「GMOペパボのエンジニア新人研修」というタイトルで話をしてきました。エンジニア新人研修については、その実施自体には、僕は既にあんまり関わっておらず、主にid:hibomaや新卒出身の若者たちが担っているのですが、その背景となっている考え方について一度まとめる必要があるなと思っていたので、この機会にまとめてみました。 いろいろ書いていますが、エンジニアがより楽しく働けるようにし、そのことでより高い成果を出すためにあれこれとやっているところです。ご興味を抱かれた方は、是非、以下をご覧いただきたく思います。 キャリア採用 / アルバイト採用 | 採用情報 | GMOペパボ株式会社
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
ペパボのエンジニア新卒採用説明会向け資料 - Kentaro Kuribayashi's blog
ちょっと前のことになりますが、エンジニアの新卒採用プロセスにおいて、技術基盤チーム + 新卒で入社した若いエンジニアという組み合わせで、エンジニア志望の学生向けに説明会を行ったりしていました。その時に使ったスライドを、その時からspeakerdeckで公開していたのですが、アナウンスしていなかったので、あらためてお知らせいたします。 お喋りで補う、というか、そちらの方が多かったので情報価値はあまりないかもしれませんが、新卒採用に限らず、ペパボのことがちょっと気になっているという方向けに少しは役立つこともあるかもしれません。 あわせて読みたい: キャリア採用 / アルバイト採用 | 採用情報 | GMOペパボ株式会社
リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog
インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした
ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて
「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
組織パターンを実践する - Kentaro Kuribayashi's blog
先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。 研修について コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。 研修の内容は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
