効率的に新しいことを学ぶ方法 - Kentaro Kuribayashi's blog
社内SlackやTwitterなどで、自分が新しいことを学ぶ時に実践していることを書いたりしていたのだが、今日メンバーと1 on 1をしていて、あらためて新しいことの学び方について訊かれたので、ブログにも簡単にまとめておく。 まず前提として、学ぶ対象の「新しいこと」とは何かについて述べておく。ここでいう新しいこととは、研究やイノベーションに関することではない。そういうのは、ググっても出てこないレベルの新しさなので、このエントリで述べる対象ではない。ここでいっているのは、自分にとって新しい知識であり、かつ、既に一定の蓄積があるような内容のことである。 それをひとことでいうと、入門書があるような領域ということになる。たとえばプログラミング言語はメジャーなものはたいてい当てはまるし、DockerとかKubernetesのような技術要素も入門書があるし、もっと広く学問一般についても当てはまる定義で
北陸先端科学技術大学院大学先端科学技術研究科博士前期課程に入学しました - Kentaro Kuribayashi's blog
タイトルの通り、長い名前の大学院（以下、略称のJAISTを用いる）に社会人学生として入学しました。といっても、実際に入学したのは今年（2020年）の4月なのでしばらく時間が経っているのですが、ブログに書いてなかったのを思い出して、いまこうして書いているわけです。 JAISTは、本校は石川県の能美市にあるのですが、品川に東京サテライトがあり、わたくしはそこの所属ということになります。研究面では、篠田陽一先生に主研究の指導を仰ぐことになりました（といっても、まずは所定の単位を取得することが先決ではありますが）。 ただ、新型コロナウィルスのこともあり、授業もゼミもオンラインであるため、入学してからは一度もキャンパスに出向いておらず、誰ともお会いできていない状態です（追記: この記事を書いた翌日に、ゼミへの参加のために初めて品川の東京サテライトへ出向くことができました）。 なぜ社会人学生になったの
2019年に読んだ本 - Kentaro Kuribayashi's blog
2019年は169冊読んだようだ（参照: kentarokさんが2019年に読んだ作品 - ブクログ）。昨年末ぐらいから、本ばかり読むのをやめてもっと別のことをやろうと思っていたのだが、結局、例年に比べると少ないとはいえ、そこそこの数を読んでいたのであった。 （kentarokさんが2019年に読んだ作品 - ブクログ） 以下、ブクログで★5つをつけた本を紹介する。 福田和也『俗ニ生キ俗ニ死スベシ 俗生歳時記』 この本は、刊行当初に買って読んで、それから折に触れて何度も繰り返し読んでいる。福田和也さんからは大きな影響を受けた。 俗ニ生キ俗ニ死スベシ 俗生歳時記 作者:福田 和也出版社/メーカー: 筑摩書房発売日: 2003/04メディア: 単行本 君塚直隆『ヨーロッパ近代史』 まったく記憶にないのだが、読んだ時は感銘を覚えたようだ。 ヨーロッパ近代史 (ちくま新書) 作者:君塚 直隆出版社
ソフトウェアエンジニアとして成長するために自分を見据えること - Kentaro Kuribayashi's blog
先日、鹿児島で行われたq-tech Meeting X #1というイベントのパネルディスカッションに参加させていただきました。テーマは、アウトプットを通じていかにエンジニアとして成長していくかということについて。その中で様々な論点とやり取りがあったのですが、このエントリでは、時間の関係もあって話せなかった内容について、簡単に紹介したいと思います。 #qtech トークセッション聞いてる pic.twitter.com/zfhgw2Rd1n— Yuta Kurotaki (@kurotaky) January 29, 2019 上記のツイートは、当日のパネルディスカッションの様子。左から、わたくし、株式会社W・I・Zの松岡さん、SYNAPSEの中野さん、リモート参加のさくらインターネットの松本さん（が映るMacをかかえるペパボのpyamaさん）。 そもそもなぜ鹿児島で話しているのかというと、
書評『エンジニアのためのマネジメントキャリアパス』 - Kentaro Kuribayashi's blog
『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』を、版元のオライリー・ジャパンよりいただきました。ありがとうございます。 エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド 作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ出版社/メーカー: オライリージャパン発売日: 2018/09/26メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 結論からいうと、インターネットに関わるソフトウェアエンジニアの方は、ぜひ読まれるとよいと思います。マネジメントへのキャリアパスを考えている人にはおおいに参考になるだろうし、コードをバリバリ書いていきたいという方にとってもエンジニア近辺の登場人物の特性を知っておくことは損にはならないでしょう。 ソ
「ミドルウェアにmrubyを組み込む方法」についてまとめた - Kentaro Kuribayashi's blog
ミドルウェアの設定を書いたり運用したりしている時に、リクエストに対して動的にあれこれしたいなーという気持ちになったことは一度や二度ではないと思います。たとえば、nginxにおけるngx_mrubyのような感じで、リクエストに応じてmrubyで処理を書くみたいな。 自分自身もそういう気持ちに何度かなったのでそういうコードを書き始めたのですが、その過程で、ミドルウェアにmrubyを組み込む方法について簡潔にまとめられた資料を見つけられなかったので、できるだけわかりやすくまとめてみようと思って以下のようなスライドを作成しました（これを用いて、社内の技術勉強会で話しました）。 speakerdeck.com mrubyの組み込みをやってみようと意気込んでみたところで、いきなりnginxなどのような大きなミドルウェアに対峙してしまうと、Cやmrubyの知識に加えて、そもそもそのミドルウェアの内部仕様
図解・拙速は巧遅に勝る - Kentaro Kuribayashi's blog
昔っから「拙速は巧遅に勝る」なんていいまして。うちの大親分の受け売りなんですが。 これは早い話が、たとえ拙いことであろうと、巧くても遅いよりは速い方がずっとマシであるというわけですな。現代風には、Facebookの創業者、マーク・ザッカーバーグさんなんて方がDone is better than perfectなどといってるそうで、あれだけのサービスを作り上げた方のお言葉とあってみりゃ、ひとつ傾聴しようじゃないかと、そういう気持ちになるわけです。 もとはといえばこの言葉、古代中国の孫武てぇお方が、最古の兵法書と呼ばれる『孫子』ってぇ本でいったと、そういうことになっておるわけです。 新訂 孫子 (岩波文庫) 作者: 金谷治出版社/メーカー: 岩波書店発売日: 2000/04/14メディア: 文庫購入: 17人 クリック: 64回この商品を含むブログ (101件) を見る 原文はこんな感じです
技術組織をスケールするための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つを伝え、お互いに内面化し、その考えを元に実行していくことがよかろうと思っ
ペパボインフラの独特に面白いところ - Kentaro Kuribayashi's blog
さわのぼりーさんのツイートを見て、うちのインフラのポジションはけっこう特殊、かつ、面白いなということをあらためて思ったので書いておく。 今後はカーネルとかガッツリ見て独自のリソーススケジュールをできる基盤か、クラウドサービスにごっそり乗っかるかの二極化しそうと思ってる。両方面に話聞きたい。— sawanoboly (@sawanoboly) June 11, 2016 上記のツイートであげられているのは2点。 カーネルとかガッツリ見て独自のリソーススケジュールをできる基盤 クラウドサービスにごっそり乗っかるか このうち1.については、@matsumotoryが「なめらかなシステムのアイデアと設計概要」で書いているような話とか、さらには@udzuraが「haconiwaの室内楽 - Re: 自作Linuxコンテナの時代 - ローファイ日記」で書いているhaconiwaのような話がある。 2.
「エンジニア実績システム」を導入した - Kentaro Kuribayashi's blog
はてなさんの「実績を解除してエンジニアスコアを上げろ！はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog」というエントリにある「エンジニア実績システム」がすごくいいなと思ったので、うちの会社でも導入してみました。 「実績」について 上記のエントリに紹介されている項目を取捨選択した上で、以下のようなものを追加したりしました。 プライベートでWebサービスを運営する(Paas or Shared Hosting, VPS, IaaS, 自宅サーバ) プライベートでモバイルアプリを公式ストアへリリースする(ダウンロード数) GitHubの年間アクティビティ数(100, 500, 1,000, 3,000) 勉強会の開催 修士号取得 博士号取得 論文誌への論文掲載 また、後述する「意義」に沿うよう、追加すべき「実績」を募集し、内容を更新しています。 ソーシャル要
「代表的プロダクト」について - Kentaro Kuribayashi's blog
ひとくちに「Webエンジニア」といってもその内実は様々だし、得意分野や成果の出し方も違う。ここではそのような多種多様のいずれが良いとか悪いとかそうしたことをいいたいのではないということをあらかじめ注記しておく。 職業生活において成果を充分に上げている(あるいは上げようと努めている)ことは前提として、組織上公式にプライベートな時間(要するに業務時間外)における技術的活動について、組織の外部との接点のある場所で活動することを好むひともいれば、あくまでも職業生活の糧となる活動に重きを置く(つまり寝ても覚めても仕事のことを考えているような)ひともいるだろう。 前者はOSSやプライベートなWebサービス開発などに深くコミットするだろうし、後者は組織の成果を直接に志向するだろう。そのいずれにしても、プライベートな時間における技術的活動が、エンジニアの成長にとって大きな糧になり、そのことが所属する組織に
GMOペパボ株式会社の執行役員CTOに就任しました - Kentaro Kuribayashi's blog
昨日(3/21)、GMOペパボ株式会社の執行役員CTO*1に就任しました。昨年8月に技術責任者に就任したのですが、今後はより一層、経営に近い立場で「技術」という切り口において会社の成長に貢献していきたいと思います。 今後やっていくこと 今後やっていきたいことを整理すると、以下の3つになります。 成長のための技術戦略の策定・実行 1.を実現するための技術基盤づくり 1.を実現するための組織づくり これまでも「GMOペパボ攻勢の裏側にあった「技術的負債を抱えない開発体制づくり」3つの布石 - エンジニアtype」にある通り、あれこれやってきましたが、より踏み込んだ戦略を立て、実行していくつもりです。また、それぞれにおいて各論的にいろいろ考えていることはあるのですが、細かいことをここで述べてもしかたないでしょう。このブログでもこの1年あまり、上記についてあれこれと書いてきたので、是非そちらをご覧
全社的に使っているチャットツールをSlackに移行した話 - delirious thoughts
ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。 追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。 IRCの利用程度 そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。
文系プログラマでもコンピュテーションをアンダースタンディングできた！！１ - 書評『アンダースタンディング コンピュテーション』 - Kentaro Kuribayashi's blog
タイトルは煽りです。 『アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで』をご恵贈いただきました。ありがとうございます。 アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 本書の扱う計算理論と呼ばれる分野には、前職の同僚たちがそういうのに詳しかったこともあってずっと興味を持ってはいたものの、いくつかの教科書的な本を繙いては読み進めずに挫折することを繰り返していました。その意味で、監訳者あとがきの「これなら私でも読める」という言葉は、自分自身の思いでもあると感じました(もちろん、笹田さんの「私でも」と、僕のそれとではおおいに異なることはいうまでもあり
リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog
インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
【無料】「継続的Webサービス改善ガイド」(WEB+DB PRESS Vol.75)【公開】 - Kentaro Kuribayashi's blog
以前寄稿したWEB+DB PRESS Vol.75の特集を、Web上でも読めるよう公開しました。 継続的Webサービス改善ガイド：特集｜gihyo.jp … 技術評論社 今日は、僕の書いた「第1章 なぜ「継続的Webサービス改善」が必要なのか～変化に対応し，10年後も生き残るWebサービスのために：継続的Webサービス改善ガイド｜gihyo.jp … 技術評論社」が公開されました。 特集全体の趣旨は以下のような感じです。 本特集のテーマは「継続的Webサービス改善」です。できるだけ長い間，ユーザに価値を提供し，利潤を生み続けるWebサービスを運営するためには，継続的な改善を行うことが必要です。Webサービスを改善するには，技術的な取り組みはもちろん，開発投資とそのリターンという経営的な観点，チームビルディングなどの開発プロセス，ビジネスメトリクスへの注視など，考慮すべきことがたくさんありま
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
Webサービスにおける費用対効果 - Kentaro Kuribayashi's blog
コードを書いたり機能を追加したりせずにお客さんが増えたり儲かったりするなら、その方がいいことは自明である。コードや機能が増えることはシステムの複雑性を増加させるため、当初の開発工数という意味におけるコストだけでなく、将来にわたってコストが増えるということ。 コードや機能が増えることによるコストは、やればやるだけ増えることもまた自明である。コードの一行一行、機能のひとつひとつが、将来の開発者に対する負担となる。一方で、一般にWebサービスにおけるベネフィットは、なにかやればその分儲かるというものではないため、費用対効果がよくわからないことが多い。単にひたすら作っているだけだと、コストばかりが増えていくということになりがち。 ではどうするか。できるだけコストをかけないでベネフィットを増やす必要がある。しかし、コードを書いたり機能を追加したりすると、上述の通り、コストが増加することは避けようがな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
