効率的に新しいことを学ぶ方法 - Kentaro Kuribayashi's blog
社内SlackやTwitterなどで、自分が新しいことを学ぶ時に実践していることを書いたりしていたのだが、今日メンバーと1 on 1をしていて、あらためて新しいことの学び方について訊かれたので、ブログにも簡単にまとめておく。 まず前提として、学ぶ対象の「新しいこと」とは何かについて述べておく。ここでいう新しいこととは、研究やイノベーションに関することではない。そういうのは、ググっても出てこないレベルの新しさなので、このエントリで述べる対象ではない。ここでいっているのは、自分にとって新しい知識であり、かつ、既に一定の蓄積があるような内容のことである。 それをひとことでいうと、入門書があるような領域ということになる。たとえばプログラミング言語はメジャーなものはたいてい当てはまるし、DockerとかKubernetesのような技術要素も入門書があるし、もっと広く学問一般についても当てはまる定義で
北陸先端科学技術大学院大学先端科学技術研究科博士前期課程に入学しました - Kentaro Kuribayashi's blog
タイトルの通り、長い名前の大学院（以下、略称のJAISTを用いる）に社会人学生として入学しました。といっても、実際に入学したのは今年（2020年）の4月なのでしばらく時間が経っているのですが、ブログに書いてなかったのを思い出して、いまこうして書いているわけです。 JAISTは、本校は石川県の能美市にあるのですが、品川に東京サテライトがあり、わたくしはそこの所属ということになります。研究面では、篠田陽一先生に主研究の指導を仰ぐことになりました（といっても、まずは所定の単位を取得することが先決ではありますが）。 ただ、新型コロナウィルスのこともあり、授業もゼミもオンラインであるため、入学してからは一度もキャンパスに出向いておらず、誰ともお会いできていない状態です（追記: この記事を書いた翌日に、ゼミへの参加のために初めて品川の東京サテライトへ出向くことができました）。 なぜ社会人学生になったの
技術組織をスケールするための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人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループには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でも役員でもありません。たとえていえば、技術部長みたいな感じの立ち位置です(うちには技術部という部署はありませんが)。 ところで、その技術責任者の主な役割を、以下のように定義しています。 技術的な会社の意思決定に貢献し、また技術面における中長期的な計画の策定・執行を行う。 経営陣、幹部会議、技術基盤チーム及び技術専門職へ情報の橋渡しを行う。 技術専門職の人事、技術基盤チーム予算に関する責任を有する。 会社におけるエンジニア出身の幹部として、適切な経営判断に貢献するとともに、それを技術者に橋渡しをし、また、技術者がより力を発揮でき
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
インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした
ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog
このブログを提供している「はてなブログ」もそうであるような、一般ユーザ向けのWebサービスのようなプロダクトについての議論を知りたいんです。ここでいう「Webサービス」とは、以下のような特徴を持っているものをいいます(これが全部ではないですが、少なくともこれらを全部満たします)。 不特定多数のユーザが共通の物理的実体にアクセスし、サービスを利用する 継続的に機能が追加されていく(削除されることもある) 一般に、いつまで使われ続けるのかあらかじめ決められていない コア技術の多くを外部に依存しているため、外部環境の変化を受けやすく、またその変化が非常に早い Webサービスの構成要素の一番大きなものはソフトウェアですが(もちろん「サービス」なのでソフトウェアだけで完結するとは限らない)、WebサービスとMicrosoft Officeなどのようなソフトウェアとを比べると、(1)が一番大きく違いま
Growth Hack(グロースハック)における3点の特色について - Kentaro Kuribayashi's blog
昨年(2012年)半ば頃からGrowth Hackという言葉が流行し始め、海外はもとより、日本においても先日Onlab [Growth] Hackers Conference 2013というイベントが開催されるなど、ますますの盛り上がりを見せています。本稿では、Growth Hackの何が新しい(あるいは新しくない)のかについて述べます。 Growth Hackが流行りかどうかはともかくとして、Growth Hackが目的とするところには、自分自身問題意識を抱いていることもあって、すこし調べてみているところです。 「Growth Hackとは何か？」要するに、できるだけ多くのユーザを獲得するための取り組みという意味ととらえて間違いはありませんが、内外の文献を元にもう少し整理すると、特に、以下の3点の特色を持ちます。 いわゆるビッグデータドリブンであること AARRRフレームワーク、特に"R
書評『Webサービスのつくり方 - 「新しい」を生み出すための33のエッセイ』 - Kentaro Kuribayashi's blog
和田裕介(yusukebe)著『Webサービスのつくり方 - 「新しい」を生み出すための33のエッセイ』をご恵投いただきました。ありがとうございます。本を書いているという話はYAPC::ASIA 2012のトークなどでうかがっており、楽しみにしていたので、うれしく思います。 Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus) 作者: 和田裕介出版社/メーカー: 技術評論社発売日: 2012/11/20メディア: 単行本（ソフトカバー） クリック: 85回この商品を含むブログを見る 和田さん、というか、yusukebeさんとは、もちろん彼我の差は歴然としてあるにせよ、プログラミングの学習過程や時期がだいたい重なっていて、第1章の「心構えと下準備」で述べられている内容など、自分もそのように歩んできた身なので、共感を覚えます。そのあ
サーバ管理の仕組みを作り始めた話 - Kentaro Kuribayashi's blog
先日(10/9)、riywoさんさんの呼びかけにより、サーバ管理をどうやったらいい感じなるかを話し合う会がもたれました。僕は、直接サーバ管理をやっているわけではないのですが、社内でそういうの欲しいという話をしていて、ツールを作りたいといっていたので、参考になればというわけで、お誘いいただいて参加してきたのでした。 riywoさんから、叩き台としてホストのキーを元にした統合的なAPIの構想を図式化したスライドを提示していただいた後、管理システムの主なユースケースや、各社の実際の管理手法などをいろいろお話をうかがいました。僕など、インフラ的な知識に乏しいもので、これはなかなか大変なことだなあというのがあらためてわかりました。 組織体制や経理ルールの複雑性が各社でだいぶ違う サーバの情報として必要な属性が各社でだいぶ違う そもそもサーバの情報が複雑 既にあるなんらかの管理の仕組みとの整合性を取る
「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - Kentaro Kuribayashi's blog
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
ぼくがかんがえたさいきょうのAmon2のつかいかた - Kentaro Kuribayashi's blog
新プロジェクトで、それなりに自由にいろいろやれる感じの状況になったので、好きにやろうと思って、いままで実務では使っていなかったツールをあれこれ試しています。 2012-02-17追記: エントリを書いた後、状況がだいぶ変わったので、実際にはずいぶん違う感じになりました。 WAFをどうしようかなーと思った時に、ドメインスペシフィックなぼくがかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーくを作成するということも考えたのですが、そんなにスペシフィックな用途でもないし、WAF自体はPlackを薄くラップしたぐらいのものでよいと思うので、自分でがんばって作る必要もないと考え、信頼と実績のAmon2を試用してみることにしました。 いくつか、こうだったらいいのになという点を反映して、こんな感じでやってみています。試しながらやってるとこなので、全然「さいきょう」でもないし、不十分なところはいろい
株式会社はてなを退職しました - Kentaro Kuribayashi's blog
本日4/18は、2008年の5/1より4年間奉職した株式会社はてなの最終出社日でした。正式な退社日は今月末日になります。 思えば、入社する前は、僕は奄美大島という田舎で市役所の職員をしていて、Webとはまったく関係ない、なんというかまあ、とにかくいまとはまったく別の仕事をしていました(具体的には、生活保護の担当をしていて、毎日いろんな問題のあるひとびととおしゃべりなどするという仕事をしていました)。それが、京都という、それまで住んでいたところからするとはるかに都会の、さらにはITベンチャという、まさに地理的、環境的に、あらゆる面で正反対の仕事をすることになって、人生なにが起こるかわからないものです。 大学の頃までは、インターネットになどまるで興味がなく、親のおさがりのMacを所持してはいたもののネットにつなぐことなく、単にレポートや小説などを書くためのワープロとしてしか使っていませんでした
PrePANをAmon2化した + Amon2で気になった点など - Kentaro Kuribayashi's blog
PrePANのWebアプリケーションフレームワークをAmon2に変更しました。閲覧者的には何も変わるところはないので特に意味はないですが、今後の機能開発がしやすくなったので、結果的にはよい影響はあると期待しているところです。 WAFは、YAPC::Asia 2011でのcho45さんの発表「ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく」にあるように「薄いフレームワーク」がより良いと最近は感じています。PrePANはまあ、特に変わったこともしていないアプリなので、ドメインスペシフィックに対処するべきこともなく、また、下手に自作するよりも、Amon2の方がずっといいものであることが明白なので、今回はAmon2を使うことにしました。 というわけで、Amon2作者のtokuhiromさんに「Amon2使いますよ!!1」と話したのを実行できたし、PrePANはいろいろと機能追加の
Perlモジュールのレビューサイト PrePAN をオープンしました - Kentaro Kuribayashi's blog
Perl Mongersの皆様へ: PrePANというサイトをオープンしたので、お知らせいたします(実装は僕、デザインは同僚のスーパーデザイナid:kudakurage)。 http://prepan.org/ PrePANとは？ 社内でこんな話をしたことがありました。 業務や個人的な活動なので、便利モジュールができた〜ということがあった時、んじゃ、せっかくなのでCPANize(CPANに公開)しよっかなと思っても、いくつか不安に思うことがあったりします。 既に似たようなものがあるのでは？ 実装について不安が……。 CPANizeするに際しての名前やファイル構成の慣習がわからない 誰かにちょっとチェックしてもらいたい そのような問題に対する解決の一助となればと思い、サイトを作ってみました。「こんなの作ったけどどうだろう？」とか「こういうモジュール他にある？」とか、いろいろなことに使ってもら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
