実際に読んで選んだマネジャーのための100冊 - Kentaro Kuribayashi's blog
このエントリでは、僕がこの2年弱で読んだ約300冊のマネジメント関連本から、100冊を選んでカテゴリ別に紹介します。 背景 2014年8月に、それまで前々職から現職に至るまでいちエンジニアとしての経験しかなかったところから、総勢70人を越えるエンジニア組織のマネジャーになりました(参照: GMOペパボ株式会社の技術責任者に就任いたしました)。 僕は、決して地頭がいいわけでもなければ、コミュニケーション力に長けているわけでもなく、他人以上に努力をして初めて人並みに近づけるかもしれないというぐらいの人間です。それに加えて、冒頭に書いた通り、エンジニアとしては多少の経験は積んだものの、マネジメントについては完全に門外漢。経験に頼るわけにもいきません。諸先輩方にOJTしてもらいつつ身に付けるにも、既にマネジメントの業務は始まっているわけです。 「さて、どうしよう？」と考えた時、まずはとにかくマネジ
効率的に新しいことを学ぶ方法 - 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さん）。 そもそもなぜ鹿児島で話しているのかというと、
『設計の設計』を読む #1 - 設計プロセスの継続について - Kentaro Kuribayashi's blog
柄沢祐輔、田中浩也、藤村龍至、ドミニク・チェン、松川昌平各氏による『設計の設計』について、読みながら感想を書いていくかもしれないし、これでよすかもしれない、ともあれ、その第1回目。 メタボリズムの代表作とされる中銀カプセルタワービルは、「それぞれの部屋の独立性が著しく高く、部屋（カプセル）ごとに交換することも、技術的には可能な設計になってい」たが「実際には、2010年に至るまで一度も交換されたことはな」かった。なぜか。 建築は、たとえばアジャイル開発のようなものとも違って、流動的な集合知をやはりどこかで切断する、つまり無限のバージョン・アップを止めてしまう行為です。それは、メタボリズムの理論でつくられた建築が、実際には更新されなかったという問題ともパラレルです。 『設計の設計』p.14 柄沢祐輔氏の発言より また、「メタボリズムもカプセルをつくる工場の生産ラインまで確保しておかなくてはいけ
マルコフ連鎖による文章の自動生成 - Kentaro Kuribayashi's blog
「PEAR::Net_SmartIRC を使って、一定間隔でニュースを配信する IRC BOT を作成する」で作成したごく簡単な BOT はしかし、外部のリソースをひっぱってきて、それを単にそのまま流すことしかできません（RSS をパースする処理はあるけど、本質的には垂れ流してるだけ）。通常 IRC BOT というと、チャンネルのメンバが喋った言葉を憶え、それらをアレンジしたデータを用いて、時には当意即妙に会話に介入することもあればまるで的はずれな発言で場を微妙な雰囲気に陥れることもあるといったものですし、また、なかには日記や Blog を書くすごい BOT さんもいます。 そうなると当然、次の目標は「おしゃべりをする、あるいは日記を書く BOT を作成する」というものになるわけですが、まぁ僕の頭ではいきなりそんなことを実現することは不可能ですし、また、そのような方向で BOT を作成する
図解・拙速は巧遅に勝る - Kentaro Kuribayashi's blog
昔っから「拙速は巧遅に勝る」なんていいまして。うちの大親分の受け売りなんですが。 これは早い話が、たとえ拙いことであろうと、巧くても遅いよりは速い方がずっとマシであるというわけですな。現代風には、Facebookの創業者、マーク・ザッカーバーグさんなんて方がDone is better than perfectなどといってるそうで、あれだけのサービスを作り上げた方のお言葉とあってみりゃ、ひとつ傾聴しようじゃないかと、そういう気持ちになるわけです。 もとはといえばこの言葉、古代中国の孫武てぇお方が、最古の兵法書と呼ばれる『孫子』ってぇ本でいったと、そういうことになっておるわけです。 新訂 孫子 (岩波文庫) 作者: 金谷治出版社/メーカー: 岩波書店発売日: 2000/04/14メディア: 文庫購入: 17人 クリック: 64回この商品を含むブログ (101件) を見る 原文はこんな感じです
マネジメント語りについて - Kentaro Kuribayashi's blog
以下のnaoya氏のツイートを見て思ったところを書いてみる。書かれている文字通りのことには完全に同意で、自分自身の行いも反省する余地があろうかと思われた。一方で、多分この発言を読んだひとが誤解するだろうなということもあるので、そのことについて。 マネジメントって業績伸ばすためにやるんですよね？ 業績伸びてないのに俺たちはマネジメントうまくやってますって語るの意味あるんですかね— Naoya Ito (@naoya_ito) December 22, 2016 結論 結論から先に書くと、マネジメントについて語ることは、業績云々に関わらずおおいにやるべきだと思う。それは、たとえばソフトウェアエンジニアリングについての文書などと同様に、世の中にとって大きく役立ち得る。 ただし、それは一般化・抽象化された(つまり、組織が違っても役立ち得る)マネジメントの理論やテクニックに限る。自分たちがそれをうま
新卒スタッフ向けに「ペパボのエンジニア2016」という話をした - Kentaro Kuribayashi's blog
今年もまた、新しい仲間が増える季節がやってきました。新しく総合職・エンジニア・デザイナ*1たち、計13名が入社し研修の毎日を送っています。しばらくは職種関係なく、会社全体の成り立ちや共通してみにつけてほしいスキルについて学んでいるところです。 さて、今年もその研修の中でなにかしらお話をする機会をいただきました。技術部長という組織の長と、CTOという技術あるいはエンジニアという職種のトップという、直接には一致しない役職を兼任しているので、なにを紹介したらいいのかいつも迷います。話をする相手も、エンジニアだけではなく、全職種の人々ですし。 そこで、技術やエンジニアという職種をとっかかりにしつつも、より広い視点から我々がどうありたいのか、なにを目指しているのかという話を、これまでほうぼうで話したり書いたりしてきたことをまとめつつ述べてみました。 去年のスライドとかぶるところもあれば、今年初めて話
エンジニア採用したさ過ぎて迷走している話 - Kentaro Kuribayashi's blog
ペパボではエンジニアを積極採用中なわけだが、エンジニアがいろいろと面白いことをやれる環境(具体的には、たとえば、今日リリースされた鼎談「次世代ホスティングの話 - 福岡から支えるサービスインフラ」などをご覧いただきたく思う)ではあるものの、私の力が及ばず、その魅力を十分にお知らせできているとはいいがたい。 そこで、どうにかして面白みをアッピールしようとここ数ヶ月あれこれ考え、採用担当者とディスカッションし、提案を重ねてきた。結果は、以下のツイートの通りである。 エンジニア採用をすすめるためにあれこれと提案をしているのだが、そのほとんどが却下されるという悲しい憂き目にあっている。以下に、ボツ案を紹介していこう。 https://t.co/zm1Aok1rJZ— あんちぽくん (@kentaro) October 19, 2015 というわけで、以下がボツ案である。 「YouTuberになりた
「エンジニア実績システム」を導入した - 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
本日6月28日、大安吉日ということもあり、目黒区役所に婚姻届を提出しました。特に書類上の不備等がなければ、受付日の本日が受理日となり、すなわち婚姻の成立日ということになります。 かねがねインターネット上で「結婚したい」と書いておりましたところ、「結婚しましょう」というお申し出がありました。私が結婚したいという意志を述べていたことが本心からなのであるとすれば、呼応したお申し出に関してはこれを受けるのが合理的です。 物事を合理的に判断するというのが私の信条ですので、その観点から本件について考察を行いました。その結果、現に私の意志が本心からなのであってみれば、すなわちお申し出を受けることは合理的であると判断し、婚姻届の提出に至りました。 なお、お相手につきましては、一般の女性ですので公開は差し控えさせていただきたく存じます。何卒ご了承くださいますようお願い申し上げます。 というわけで、今後ともみ
エンジニアtypeで本を紹介するインタビューにこたえました(+その補足) - Kentaro Kuribayashi's blog
みんな大好きエンジニアtypeさんに、「エンジニアとして錆びないために読む本」というインタビュー連載コーナーがあるのですが、その3回目として下記の通り登場いたしました。是非、ご笑覧くださいませ。 engineer.typemag.jp インタビューの補足 僕の主張としては上記にいい感じにまとめられている通りなのですが、大事なことなのであらためて強調しておくと、 仕事という面においては、成果を出すことが目的なのであるから、本を読むのは手段に過ぎない。読まなくても成果が出せるなら、それが一番効率的なのは自明 ただし、これまでに起きた問題のうちたいていは書籍に書かれているのもまた事実なので、本を読むのが効率的ならそうする方がよいし、そういう場面は普通に思われているよりずっと多いだろう 本を読めば解決できることはそうやってさっさとスキップして時間と余裕を作り、マジで頭使って考えるべきことに注力して
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -
「代表的プロダクト」について - Kentaro Kuribayashi's blog
ひとくちに「Webエンジニア」といってもその内実は様々だし、得意分野や成果の出し方も違う。ここではそのような多種多様のいずれが良いとか悪いとかそうしたことをいいたいのではないということをあらかじめ注記しておく。 職業生活において成果を充分に上げている(あるいは上げようと努めている)ことは前提として、組織上公式にプライベートな時間(要するに業務時間外)における技術的活動について、組織の外部との接点のある場所で活動することを好むひともいれば、あくまでも職業生活の糧となる活動に重きを置く(つまり寝ても覚めても仕事のことを考えているような)ひともいるだろう。 前者はOSSやプライベートなWebサービス開発などに深くコミットするだろうし、後者は組織の成果を直接に志向するだろう。そのいずれにしても、プライベートな時間における技術的活動が、エンジニアの成長にとって大きな糧になり、そのことが所属する組織に
情報価値の高いスライドを作るために - Kentaro Kuribayashi's blog
役職が変わったりしたこともあって、取締役会のみなさんに説明したりエンジニアのみなさんに考えを伝えたりなど、社内向けにもいろんな資料を作る必要も増えてきて、そういうのが増えること自体どうかというのはともかくとして、エンジニアとしてより活動を広げていくためには、そういう文脈における資料の作り方を身に付けるというのも、ひとつのスキルアップではあります。 これまでもかなりの量のスライドを作ってきたわけですが、そのほとんどが技術イベントで話すためのもので、それはそれでいろんな工夫をしてきたつもりではあっても、コンテキストが違うと、ただ一本調子で同じようにやってもうまくはいかないわけです。上述の通り、昨年後半以降、そういうことが増えてきて限界を感じたので、あらためてものの本を読んだりして学習してみました。 コンテキストの違い ここでいうコンテキストとは、エンジニアだけを対象にしているというよりは「経営
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もとにかくたくさんいて、賑やかな状態です。
façadeでGitのようなサブコマンドをディスパッチする - Kentaro Kuribayashi's blog
Gitには、git fooと実行すると、$PATH内のgit-fooを実行するというサブコマンドの機能がある。そのため、その規約に則りさえすれば、Gitのサブコマンドをいろんな言語で書けるというメリットがある。それを簡単に実現するために、façadeというごく単純なライブラリを書いた。 使い方 これを使うと以下のように書くだけで、コマンド名がyour-commandだったとして、your-command foo bar bazと実行すると、your-command-foo bar bazという呼び出しに変わる。 package main import ( "github.com/pepabo/facade" ) func main() { facade.Run() } なぜ作ったか ある目的に利用するツール群があるとして(たとえばEC2を操作するような各種コマンド群)、以下のような問題を解
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
