図解・拙速は巧遅に勝る - Kentaro Kuribayashi's blog
昔っから「拙速は巧遅に勝る」なんていいまして。うちの大親分の受け売りなんですが。 これは早い話が、たとえ拙いことであろうと、巧くても遅いよりは速い方がずっとマシであるというわけですな。現代風には、Facebookの創業者、マーク・ザッカーバーグさんなんて方がDone is better than perfectなどといってるそうで、あれだけのサービスを作り上げた方のお言葉とあってみりゃ、ひとつ傾聴しようじゃないかと、そういう気持ちになるわけです。 もとはといえばこの言葉、古代中国の孫武てぇお方が、最古の兵法書と呼ばれる『孫子』ってぇ本でいったと、そういうことになっておるわけです。 新訂 孫子 (岩波文庫) 作者: 金谷治出版社/メーカー: 岩波書店発売日: 2000/04/14メディア: 文庫購入: 17人 クリック: 64回この商品を含むブログ (101件) を見る 原文はこんな感じです
antipop.partyというセミクローズドなコミュニティを始めた - Kentaro Kuribayashi's blog
Mastodonが話題になって数週間ほどが経過した。連邦的なTwitterというコミュニティ設計上の利点はともかくとして、SNSを半ばクローズドにすることで、Web上で新しい形の言論を組織することができるかもしれないというところに、個人的には興味を持つところだ。 ここで「半ばクローズド」であるとは、例えば『ネット炎上の研究』で提案されているような事態のことをいう。すなわち、書き込みは誰からも見られるが、書き込みそのものを行えるのはあらかじめ承認された者に限られるという仕組みである。個人的には、Mastodonに良さを感じるのは、それがTwitterに似ていて、かつ、そのような半ばクローズドなコミュニティを簡単に作れるところ。 ただ、いざその目的のためにインスタンスを立ち上げてみようかと思うと、それなりにコストがかかる。ぽんっと置けば動くほどには単純な仕組みではないからだ。Twitterに似
マネジメント3題噺: いいじゃん・いい感じに・バーンと - Kentaro Kuribayashi's blog
こんなことを書いた。 私のマネジメントスタイル、「いいじゃん」「いい感じに」「バーンと」の3つしか話してない。— あんちぽちゃん (@kentaro) July 6, 2016 というだけだと雑過ぎて酷い人間にしか見えないので、補足する。 世の中にはいろんな環境があるだろうが、そもそもうちのような採用を重視している会社では、基本的に信用できる人々で構成されていることが前提。その上で、たくさんの人々との関係性の中で、成果を最大化するに際して重要だとおもうことに、以下の3つがある。 つねに肯定的・ポジティブ 仲間を信頼して任せる 大きなスケール観を持つ 細かいことや短期的な観点からいうと「もうちょっとどうかしてほしい」という気持ちになることはある場合もあるだろうが、そこはいったんぐっと引いて置いておく。その上で、上記の3つを伝え、お互いに内面化し、その考えを元に実行していくことがよかろうと思っ
リーダーシップはフォロワーシップから - Kentaro Kuribayashi's blog
こんにちは、あんちぽちゃんです。GMOペパボで執行役員CTOや技術部長やペパボ研究所長をやっております。 Pepabo Managers Advent Calendar 2016の第1日目の記事を担当します。 www.adventar.org あなたにはリーダーシップはありますか？ 突然ですが、リーダーの皆さんに質問です。 「あなたにはリーダーシップはありますか？」 そう質問されて「私はリーダーシップに満ち溢れている」と100%自信を持って答えられる人はわりと少ないんじゃないかと想像します。「そういう面もあるけど、足りてはいないかもしれない……」と反省する人が多いでしょう。 私だって、リーダーシップにあふれるリーダーになりたい！ リーダーシップのロバストな2軸 そもそもリーダーシップとはなんでしょうか。様々な人々があれこれと自説を述べていますが、それらを総覧すると、畢竟「Performan
技術組織をスケールするための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人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
久保達彦・道井俊介『nginx実践入門』 - Kentaro Kuribayashi's blog
福岡出張にいっていたら、ちょうど福岡にいらしていた@kazeburoさん経由でご恵贈いただきました。ありがとうございます。 nginx実践入門 (WEB+DB PRESS plus) 作者: 久保達彦,道井俊介出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本書は、nginx関連で多数のプロダクトを作っている@cubicdaiyaさんと、pixivのインフラを支える@harukasanさんによる共著とあってみれば自然と期待が高まるわけですが、nginxのアーキテクチャについての簡潔な説明から、基本的な設定や大規模なコンテンツをさばくためのスケールアウトの方法、さらにはngx_luaによる拡張まで、Webサービスにおけるnginxの実践的活用に必要な内容が、わかりやすく述べられています。 「秒間50kリクエ
エンジニア採用したさ過ぎて迷走している話 - Kentaro Kuribayashi's blog
ペパボではエンジニアを積極採用中なわけだが、エンジニアがいろいろと面白いことをやれる環境(具体的には、たとえば、今日リリースされた鼎談「次世代ホスティングの話 - 福岡から支えるサービスインフラ」などをご覧いただきたく思う)ではあるものの、私の力が及ばず、その魅力を十分にお知らせできているとはいいがたい。 そこで、どうにかして面白みをアッピールしようとここ数ヶ月あれこれ考え、採用担当者とディスカッションし、提案を重ねてきた。結果は、以下のツイートの通りである。 エンジニア採用をすすめるためにあれこれと提案をしているのだが、そのほとんどが却下されるという悲しい憂き目にあっている。以下に、ボツ案を紹介していこう。 https://t.co/zm1Aok1rJZ— あんちぽくん (@kentaro) October 19, 2015 というわけで、以下がボツ案である。 「YouTuberになりた
技術的な抽象性のレイヤについて - Kentaro Kuribayashi's blog
ネットワークにおけるOSI参照モデルや、アプリケーション実行環境におけるハードウェア→OS→ミドルウェア→アプリケーション→UI(ブラウザ・モバイル)というレイヤ(こういうのに名前あるのかな。「フルスタックエンジニア」という言葉があることからして「技術スタック」とでもいうのだろうか)のように、ある技術的まとまりを、フラットにではなく階層をなすものとして考える習慣が存在する。それぞれのレイヤの独立性・簡潔性を担保するためだ。 今日、いろんなひとと話をしていて、こういう風にも考えられるよなと思ったことがあったので、以下にメモしておく。 それぞれについての贅言は必要なかろう(念のため、「デザイン」はいわゆる設計のこと)。また、抽象度が高低に、なにかしら技術的な優劣があるというわけでももちろんない。単に、階層を成しているものとして捉えると整理がつくだろうというだけのこと。ただし、上述の例とは異なり
目黒区役所に婚姻届を提出しました - Kentaro Kuribayashi's blog
本日6月28日、大安吉日ということもあり、目黒区役所に婚姻届を提出しました。特に書類上の不備等がなければ、受付日の本日が受理日となり、すなわち婚姻の成立日ということになります。 かねがねインターネット上で「結婚したい」と書いておりましたところ、「結婚しましょう」というお申し出がありました。私が結婚したいという意志を述べていたことが本心からなのであるとすれば、呼応したお申し出に関してはこれを受けるのが合理的です。 物事を合理的に判断するというのが私の信条ですので、その観点から本件について考察を行いました。その結果、現に私の意志が本心からなのであってみれば、すなわちお申し出を受けることは合理的であると判断し、婚姻届の提出に至りました。 なお、お相手につきましては、一般の女性ですので公開は差し控えさせていただきたく存じます。何卒ご了承くださいますようお願い申し上げます。 というわけで、今後ともみ
書評『pixivエンジニアが教えるプログラミング入門』 - Kentaro Kuribayashi's blog
著者のid:catatsuyさんよりご恵贈いただきました。ありがとうございます。 pixivエンジニアが教えるプログラミング入門 (星海社新書) 作者: 金子達哉出版社/メーカー: 講談社発売日: 2015/03/26メディア: 新書この商品を含むブログを見る 本書は、先日紹介した『Webエンジニアの教科書』とは異なり、プログラミングの基礎が多少はある人に向けてWebプログラミングの概要を教える本ではありません。 例えば次のような方にオススメをします。 システムエンジニアやプログラマーとプロジェクトを共にする、Webディレクター/デザイナーの方 プログラミングに興味はありつつも、なんとなく難しそうではじめるきっかけが掴めない方(10年前の著者) 就職/転職の結果、全くの未経験からシステムエンジニアになることになった方 プログラミングによって何か動くものが作ってみたい方 (本書p.2) その
全社的に使っているチャットツールをSlackに移行した話 - delirious thoughts
ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。 追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。 IRCの利用程度 そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。
Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - Kentaro Kuribayashi's blog
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
Androidアプリ開発をはじめた - Kentaro Kuribayashi's blog
Nexus 5を常用しているAndroidユーザになってしばらく経つので、そろそろAndroidアプリを作りたい気持ちになってきた。先日、そのためにMacBook Proを新調したほどの、気の入れようである。ちょうど3連休だったので、2日目・3日目を使って、あれこれ調べながら、初めてのAndroidアプリ開発をしてみた。 kentaro/palimpsest · GitHub やりたかったこと まずは簡単なタスク管理ツールを作ってみようと思った。こんな感じ。 毎日習慣的に行いたいタスクがいくつかあるので、ちゃんと習慣的に行えるよう管理したい タスクは、名前と回数からなる(例: 腕立て伏せを30回する、英和辞典を5ページ読む、みたいな) また、ちゃんとしなかった場合は、前日以前の回数が今日の分に加算されるので、ちゃんと毎日やらないと大変なことになる 画面 ほぼ「sqliteのテーブル1つに対
GMOペパボのエンジニア新人研修 #lldiver - Kentaro Kuribayashi's blog
LL Diver | Dive into Lightweight Languagesで、「GMOペパボのエンジニア新人研修」というタイトルで話をしてきました。エンジニア新人研修については、その実施自体には、僕は既にあんまり関わっておらず、主にid:hibomaや新卒出身の若者たちが担っているのですが、その背景となっている考え方について一度まとめる必要があるなと思っていたので、この機会にまとめてみました。 いろいろ書いていますが、エンジニアがより楽しく働けるようにし、そのことでより高い成果を出すためにあれこれとやっているところです。ご興味を抱かれた方は、是非、以下をご覧いただきたく思います。 キャリア採用 / アルバイト採用 | 採用情報 | GMOペパボ株式会社
RESTが日本で受け入れられていった頃の話( #mozaicfm の補足) - Kentaro Kuribayashi's blog
mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。 まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。 また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:seco
GMOペパボ株式会社の技術責任者に就任いたしました - Kentaro Kuribayashi's blog
標題の通り、8/1付けでペパボの技術責任者に就任しました。あわせて、@hsbtさんがチーフエンジニアに就任しました。技術者の体制を強化したことで、Webサービス事業者、すなわち、技術の会社として、さらに高い成果を出していけるよう努めたいと思います。 ちなみに、CTOでも役員でもありません。たとえていえば、技術部長みたいな感じの立ち位置です(うちには技術部という部署はありませんが)。 ところで、その技術責任者の主な役割を、以下のように定義しています。 技術的な会社の意思決定に貢献し、また技術面における中長期的な計画の策定・執行を行う。 経営陣、幹部会議、技術基盤チーム及び技術専門職へ情報の橋渡しを行う。 技術専門職の人事、技術基盤チーム予算に関する責任を有する。 会社におけるエンジニア出身の幹部として、適切な経営判断に貢献するとともに、それを技術者に橋渡しをし、また、技術者がより力を発揮でき
ペパボの2014年上半期エンジニア評価について - Kentaro Kuribayashi's blog
ペパボの新しいエンジニア評価については、ペパボのエンジニア評価制度をパワーアップしたで既にお知らせしたところです。さて、今回その評価が終わり、総評を書いたので、さしつかえない範囲で公開します。 ちなみに、技術上級職については既に「ペバボのエンジニア職位制度のアップデートについて」で紹介しています。そちらも御覧ください。 制度の概要 そのエントリにもある通り、新しい制度では、以下の特徴があります。 エンジニア全員を、エンジニア集団である技術基盤チームが評価する GitHubに評価用の提出資料をまとめpull requestを出してもらい、それに基いて、結果も含めて全員にオープンな状態で評価する あらためて上記のエントリを引用すると: 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。
「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
Webサービスにおける費用対効果 - Kentaro Kuribayashi's blog
コードを書いたり機能を追加したりせずにお客さんが増えたり儲かったりするなら、その方がいいことは自明である。コードや機能が増えることはシステムの複雑性を増加させるため、当初の開発工数という意味におけるコストだけでなく、将来にわたってコストが増えるということ。 コードや機能が増えることによるコストは、やればやるだけ増えることもまた自明である。コードの一行一行、機能のひとつひとつが、将来の開発者に対する負担となる。一方で、一般にWebサービスにおけるベネフィットは、なにかやればその分儲かるというものではないため、費用対効果がよくわからないことが多い。単にひたすら作っているだけだと、コストばかりが増えていくということになりがち。 ではどうするか。できるだけコストをかけないでベネフィットを増やす必要がある。しかし、コードを書いたり機能を追加したりすると、上述の通り、コストが増加することは避けようがな
Software and Spiritual Ability - Kentaro Kuribayashi's blog
Thanks to @kenjiskywalker, we had an opportunity we went to Kayac's office and gave our talks to them. I talked about software development process based on my recent thoughts. Here's the slides I used then: In short, working process is to visualize invisibility (霊的存在). The more we visualize things, the more we can get accurate values. Since we're working in some organisation with many colleagues,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
