GMOペパボにおいて、チーフテクニカルリード(略称: CTL)という職位を作りました。既に以下のブログエントリで新任の2人がエントリを書いているところですが、制度設計者として、その背景を述べてみたいと思います。 diary.shu-cream.net ten-snapon.com GMOペパボの執行役員CTOになって1年半*1、その前に技術責任者に就任してから早2年*2が経過しました。その間、組織面においては、「いるだけで成長できる環境」*3、技術面では「事業を差別化できる技術」*4というコンセプトでやってきました。まだ道半ばではあるものの、逆にいえば、通るべき道は見えているともいえます。 そんな中で、この2年間、ずっと気にかかっていることがありました。 組織的にはエンジニアの人数が90人弱になり、近いうちに100人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい

さわのぼりーさんのツイートを見て、うちのインフラのポジションはけっこう特殊、かつ、面白いなということをあらためて思ったので書いておく。 今後はカーネルとかガッツリ見て独自のリソーススケジュールをできる基盤か、クラウドサービスにごっそり乗っかるかの二極化しそうと思ってる。両方面に話聞きたい。— sawanoboly (@sawanoboly) June 11, 2016 上記のツイートであげられているのは2点。 カーネルとかガッツリ見て独自のリソーススケジュールをできる基盤 クラウドサービスにごっそり乗っかるか このうち1.については、@matsumotoryが「なめらかなシステムのアイデアと設計概要」で書いているような話とか、さらには@udzuraが「haconiwaの室内楽 - Re: 自作Linuxコンテナの時代 - ローファイ日記」で書いているhaconiwaのような話がある。 2.

@matsumotoryさんがmruby-changefinderってのを公開していたので、試してみた。元になる時系列データとして、異常検知でGo！と同じものを流してみる。 結果 以下の青いラインがGoogle TrendでのGolangという単語の検索トレンド。赤いのがChangeFinderによるスコア。大きな変化が起こったその時にだけビクンと反応して、そのあとはなだらか。 (最初の方で反応してるのは、学習し始めだから) スコアだけで見ると以下のような感じ。いい感じに変化点検出できているようですね。 結果データの作成方法 mruby-changefinderを組み込んだmrubyにより、こんな感じでデータを作成した。 cf = ChangeFinder.new(5, 0.01, 10, 0.01, 5) File.open('result.tsv', 'w') do |f| File.

昨今、Goのような言語が注目されているのにはいろんな理由があるかとは存じますが、こと運用の面に関していうと、バイナリをビルドしてポン置きすればマルチプラットフォームで動くということが簡単にできることも大きい。Goは、個人的には好きな言語だが、Rubyで書けると楽な場面も多々ある(Concurrencyが問題でないツールなどは特に)。そんな時に有用なのが、mruby-cliだ。 github.com 具体的な利用例としては、「mruby-cliを使ってプロセスのfdをリソース使用率を元に解析するワンバイナリなツールpfdsを作った - 人間とウェブの未来」に詳しい。ローカル(Mac OS Xなど)でさっとビルドして、本番環境(x86_64上のLinuxなど)にポン置きしたら動く。便利。 mruby-cli特有のお作法と、mrbgemに対する知識が必要ではあるものの、そのあたりをクリアしさえす

ペパボではエンジニアを積極採用中なわけだが、エンジニアがいろいろと面白いことをやれる環境(具体的には、たとえば、今日リリースされた鼎談「次世代ホスティングの話 - 福岡から支えるサービスインフラ」などをご覧いただきたく思う)ではあるものの、私の力が及ばず、その魅力を十分にお知らせできているとはいいがたい。 そこで、どうにかして面白みをアッピールしようとここ数ヶ月あれこれ考え、採用担当者とディスカッションし、提案を重ねてきた。結果は、以下のツイートの通りである。 エンジニア採用をすすめるためにあれこれと提案をしているのだが、そのほとんどが却下されるという悲しい憂き目にあっている。以下に、ボツ案を紹介していこう。 https://t.co/zm1Aok1rJZ— あんちぽくん (@kentaro) October 19, 2015 というわけで、以下がボツ案である。 「YouTuberになりた

GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -

ひとくちに「Webエンジニア」といってもその内実は様々だし、得意分野や成果の出し方も違う。ここではそのような多種多様のいずれが良いとか悪いとかそうしたことをいいたいのではないということをあらかじめ注記しておく。 職業生活において成果を充分に上げている(あるいは上げようと努めている)ことは前提として、組織上公式にプライベートな時間(要するに業務時間外)における技術的活動について、組織の外部との接点のある場所で活動することを好むひともいれば、あくまでも職業生活の糧となる活動に重きを置く(つまり寝ても覚めても仕事のことを考えているような)ひともいるだろう。 前者はOSSやプライベートなWebサービス開発などに深くコミットするだろうし、後者は組織の成果を直接に志向するだろう。そのいずれにしても、プライベートな時間における技術的活動が、エンジニアの成長にとって大きな糧になり、そのことが所属する組織に

この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。

タイトルは煽りです。 『アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで』をご恵贈いただきました。ありがとうございます。 アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 本書の扱う計算理論と呼ばれる分野には、前職の同僚たちがそういうのに詳しかったこともあってずっと興味を持ってはいたものの、いくつかの教科書的な本を繙いては読み進めずに挫折することを繰り返していました。その意味で、監訳者あとがきの「これなら私でも読める」という言葉は、自分自身の思いでもあると感じました(もちろん、笹田さんの「私でも」と、僕のそれとではおおいに異なることはいうまでもあり

Google認証なリバースプロクシ＆静的コンテンツ配信サーバー「gate」 - unknownplace.orgで紹介されている、typesterさんのgateという、GoogleのOAuth2認証付きプロキシサーバがとても便利そうだったので、即座に使いたくなった。 これは、昨今増えつつあるメトリクス系のツールだとかの、インターネット上に置きつつも、社内のみに提供したいサービスを立てるに際して、フロントにnginxをおいた場合に、認証のことを考えるのがだるい、というか、nginxの設定自体がだるいみたいなときに役立つツールです。その際、自分とこ的にはGitHubのorganizationでアカウント管理できるとさらによいので、GitHub対応をしてpull requestを送ったところmergeされました。ありがとうございます。 会社で運用しているorganizationがfoo_orga

ペパボの新しいエンジニア評価については、ペパボのエンジニア評価制度をパワーアップしたで既にお知らせしたところです。さて、今回その評価が終わり、総評を書いたので、さしつかえない範囲で公開します。 ちなみに、技術上級職については既に「ペバボのエンジニア職位制度のアップデートについて」で紹介しています。そちらも御覧ください。 制度の概要 そのエントリにもある通り、新しい制度では、以下の特徴があります。 エンジニア全員を、エンジニア集団である技術基盤チームが評価する GitHubに評価用の提出資料をまとめpull requestを出してもらい、それに基いて、結果も含めて全員にオープンな状態で評価する あらためて上記のエントリを引用すると: 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。

以前寄稿したWEB+DB PRESS Vol.75の特集を、Web上でも読めるよう公開しました。 継続的Webサービス改善ガイド：特集｜gihyo.jp … 技術評論社 今日は、僕の書いた「第1章　なぜ「継続的Webサービス改善」が必要なのか～変化に対応し，10年後も生き残るWebサービスのために：継続的Webサービス改善ガイド｜gihyo.jp … 技術評論社」が公開されました。 特集全体の趣旨は以下のような感じです。 本特集のテーマは「継続的Webサービス改善」です。できるだけ長い間，ユーザに価値を提供し，利潤を生み続けるWebサービスを運営するためには，継続的な改善を行うことが必要です。Webサービスを改善するには，技術的な取り組みはもちろん，開発投資とそのリターンという経営的な観点，チームビルディングなどの開発プロセス，ビジネスメトリクスへの注視など，考慮すべきことがたくさんありま

「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば: 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか テスト結果の統計的有意性をどのように検定すればよいのか 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは: 「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」 ということです。どういうことか。 視野狭窄的なA/Bテスト A/Bテスト、あるいは同様の最適化技法については、かつて

本エントリでは、2013年の主にエンジニアリング面での活動について、外部に公開されたリソースに基づいて、定量的・定性的なふりかえりを行います。 数字によるふりかえり まずは数字によるふりかえり。イベント登壇、GitHub上の活動、執筆活動を見ていきます。 社外イベントでの登壇 今年は、社外での発表は以下の5件(パネラーなども含めると7件)でした。去年はもう少し多かったので、あんまり話せなかったなあ。 Fluent Casual Talks #2: Log Everything with Fluentd // Speaker Deck カヤックさんとの勉強会: Software and Spiritual Ability // Speaker Deck DCI Hansei Meetup: A Missing Part of OOP // Speaker Deck Provisioning

本稿では、"Immutable Infrastructure"時代におけるconfiguration management tool(以下、CMT)の要件およびそれを満たすツールについて議論する。 背景の整理 "Immutable Infrastructure"とは、2013年6月、Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowlerにより提唱された概念だ。ある種のプログラミング言語における不変性がプログラムにおける厄介な問題を解決するように、サーバの状態を不変な(正確には、状態を変更しない)ものとすることで、成長し続けるソフトウェアにとって避けられない、時間の経過によりもたらされる種々の問題が、解決可能であるとする。 そもそもどのような

先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。 研修について コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。 研修の内容は

よくある話ですが、コマンド一覧とかを表にして憶えようとしたって、絶対に無理です。そんなの、異常の記憶力の持ち主しか憶えられません。まずは、理屈はなんでもいいからとにかく30分でいいので集中できる時間を取って、以下のコマンドを実行し、チュートリアルをひと通りやってみるのが一番の近道です。 $ vimtutor その後『実践Vim 思考のスピードで編集しよう!』などを読むといいと思います(達人出版会から電子書籍版も出ています)。 ref: これから使い始めたい人のためのEmacs講座 全1回 実践Vim 思考のスピードで編集しよう! 作者: Drew Neil,新丈径出版社/メーカー: アスキー・メディアワークス発売日: 2013/08/29メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る

PHPカンファレンス2013で「PHPアプリケーションの継続的アップデート」というタイトルで話をしてきました。僕は、いまでこそPerlやRubyの人みたいな感じですが、もともとはPHPからプログラミングを始めたので、PHPカンファレンスで話すというのは、感慨深いものでした。「ぺちぺ」「ぺちぱー」という言葉の創始者でもありますし。 トークの内容は、最近仕事でやってきたことのまとめみたいな感じです。PHPといいながら、2/3ぐらいはPHPには直接関係ないことばかりでしたが。トーク中でもいったように、言語そのものというよりは、システムの複雑性をいかに減らすかが「継続的な」取り組みには必要なので、いたしかたありません。それなりに面白いものになっていると思います。 スライドは以下。 これまで『WEB+DB PRESS Vol.75』『入門Puppet - Automate Your Infrastr