効率的に新しいことを学ぶ方法 - Kentaro Kuribayashi's blog
社内SlackやTwitterなどで、自分が新しいことを学ぶ時に実践していることを書いたりしていたのだが、今日メンバーと1 on 1をしていて、あらためて新しいことの学び方について訊かれたので、ブログにも簡単にまとめておく。 まず前提として、学ぶ対象の「新しいこと」とは何かについて述べておく。ここでいう新しいこととは、研究やイノベーションに関することではない。そういうのは、ググっても出てこないレベルの新しさなので、このエントリで述べる対象ではない。ここでいっているのは、自分にとって新しい知識であり、かつ、既に一定の蓄積があるような内容のことである。 それをひとことでいうと、入門書があるような領域ということになる。たとえばプログラミング言語はメジャーなものはたいてい当てはまるし、DockerとかKubernetesのような技術要素も入門書があるし、もっと広く学問一般についても当てはまる定義で
時間は有限なのでHabitifyを使って能力を高めることで一日を実質48時間にし圧倒的なパフォーマンス向上を実現する - Kentaro Kuribayashi's blog
本記事では、パフォーマンスを高める目的でよい習慣をみにつけるために必要な考え方、ツールを用いた実践について述べる。 良い習慣が限られた時間におけるパフォーマンスを高める 「人間は習慣の生き物である（Humans are creatures of habit）」とは、アメリカのプラグマティズム哲学者であるジョン・デューイの言葉だという。出典にあたって確かめたわけではないので、そのフレーズのいわれている文脈はわからないため誤解している可能性は否めないものの、習慣について語る文章では頻繁に引かれる言葉であるため、多くの人々の心を捉え続けていることは確かだろう。経験的にも、悪い習慣によってこれまで無駄にしてきた様々なことが思い浮かぶし、良い習慣を身につけることが高いパフォーマンスにつながることは普通にありそうなことだ。 また、時間は誰にとっても平等であるみたいなこともよくいわれる。長い目で見れば早
ソフトウェアエンジニアとして成長するために自分を見据えること - 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
昔っから「拙速は巧遅に勝る」なんていいまして。うちの大親分の受け売りなんですが。 これは早い話が、たとえ拙いことであろうと、巧くても遅いよりは速い方がずっとマシであるというわけですな。現代風には、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人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
「エンジニア実績システム」を導入した - 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
今晩、同僚との飲みの場で行った会話を、以下に再現する。 きたけー: 週末、炊飯器でピラフ作ったんですよ。 あんちぽ: どういうレシピで作ったの？ きたけー: まず、米をよくといで水を切った後に、溶かしたバターを絡めます。そこにコンソメの素、シーフードミックス、グリーンピースを加えて炊きました。 あんちぽ: なるほどね。美味しそうだね。 きたけー: 美味しかったです。 あんちぽ: ところで、ピラフとチャーハンの違いってなんだろう？ きたけー: (少し考えて)ピラフは材料を加えて米を炊くのに対して、チャーハンは炊いた米と材料を一緒に炒める、ということですかね。 あんちぽ: その通りだね。つまりは、材料と米のコンビネーションのしかたの違いってことだね。 きたけー: なるほど。 あんちぽ: そう考えてみると、ピラフを炊飯器で作るのは当たり前のことだよね。炊飯器は白ご飯を作るだけのものじゃない。 き
全社的に使っているチャットツールをSlackに移行した話 - delirious thoughts
ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。 追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。 IRCの利用程度 そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。
エンジニア専門職のグレードについて詳細な役割定義は必要か？ - Kentaro Kuribayashi's blog
様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長
Slack用のIkachanを作った - Kentaro Kuribayashi's blog
最近、社内のチャットツールをSlackに移行しつつある。ペパボではIkachanをヘヴィに使っているので、移行に際してはそこをどうSlackに移行するかが問題となった。というわけで、Ikachanと同じインタフェイスでSlackにメッセージを送れる簡単なツールを作成した。 kentaro/takosan Ikachanを使っているひとには特に説明の必要もない感じ。詳しくはREADMEを見てほしい。go getしたら、 $ SLACK_API_TOKEN="YOUR SLACK API TOKEN" takosan [-host string] [-port int] [-name string] 以下のように起動して、あとは $ curl -d "channel=#channel&message=test message" localhost:4979/privmsg とかするだけ。簡単で
Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - Kentaro Kuribayashi's blog
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog
この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。
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
「酒を飲みながらコードを書く」というLTをした - Kentaro Kuribayashi's blog
「ハックガールズpresents システムライトニングトークBar Vol.2」というイベントにお誘いいただき、LTをしてきました。話す方も聴く方もお酒を飲みながらという感じとのことなので、技術的な内容というよりは、軽く聴けるカジュアルな内容がよかろうというわけで、「酒を飲みながらコードを書く」というタイトルで話をしました。 イベントは、渋谷・道玄坂にある実験型イベント企画スペース ヒミツキチラボ Produced by SCRAPで行われました。いらっしゃったのは20人ぐらい？いつも参加するようなイベントとはやや違った感じのお客さんだったように思われましたが、反応もよかったし、もちろんトークしてくださった方々も面白かったし、いいイベントになったように思います。 貴重なご機会を与えていただきまして、ありがとうございました。ハックガールズとあまり近しくなれなかったのが心残りでした。
ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
リリースの高速化は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編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
A/Bテストでいちばん大切なこと - Kentaro Kuribayashi's blog
「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば: 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか テスト結果の統計的有意性をどのように検定すればよいのか 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは: 「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」 ということです。どういうことか。 視野狭窄的なA/Bテスト A/Bテスト、あるいは同様の最適化技法については、かつて
最近のImmutable Infrastructureに関する議論(Orchestration編) - Kentaro Kuribayashi's blog
この分野について議論する際には、インフラ系技術の流れ - Gosuke Miyashitaで紹介されている Bootstrapping Configuration Orchestration という整理を前提に議論すると、どのレイヤについて話しているのかごちゃごちゃにならなくてよいと思う。ただ、 上記は階層を成す概念なのだけど、それぞれが必ずしも排他的ではなく、重なる部分が多々ある(たとえば、(1)に該当するDockerやPackerにも(2)の要素が含まれている等) Orchestrationというネーミングがいまやミスリーディング(な面がある) ということもあって、一部に混乱をきたしている。ここでは、特に(2)について、時系列を追って論ずる。 時系列の整理 インフラ系技術の流れ - Gosuke Miyashitaによる整理 Rebuild: 25: Immutable Infrast
Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装について - Kentaro Kuribayashi's blog
本稿では、"Immutable Infrastructure"時代におけるconfiguration management tool(以下、CMT)の要件およびそれを満たすツールについて議論する。 背景の整理 "Immutable Infrastructure"とは、2013年6月、Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowlerにより提唱された概念だ。ある種のプログラミング言語における不変性がプログラムにおける厄介な問題を解決するように、サーバの状態を不変な(正確には、状態を変更しない)ものとすることで、成長し続けるソフトウェアにとって避けられない、時間の経過によりもたらされる種々の問題が、解決可能であるとする。 そもそもどのような
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
