社内SlackやTwitterなどで、自分が新しいことを学ぶ時に実践していることを書いたりしていたのだが、今日メンバーと1 on 1をしていて、あらためて新しいことの学び方について訊かれたので、ブログにも簡単にまとめておく。 まず前提として、学ぶ対象の「新しいこと」とは何かについて述べておく。ここでいう新しいこととは、研究やイノベーションに関することではない。そういうのは、ググっても出てこないレベルの新しさなので、このエントリで述べる対象ではない。ここでいっているのは、自分にとって新しい知識であり、かつ、既に一定の蓄積があるような内容のことである。 それをひとことでいうと、入門書があるような領域ということになる。たとえばプログラミング言語はメジャーなものはたいてい当てはまるし、DockerとかKubernetesのような技術要素も入門書があるし、もっと広く学問一般についても当てはまる定義で

本記事では、パフォーマンスを高める目的でよい習慣をみにつけるために必要な考え方、ツールを用いた実践について述べる。 良い習慣が限られた時間におけるパフォーマンスを高める 「人間は習慣の生き物である（Humans are creatures of habit）」とは、アメリカのプラグマティズム哲学者であるジョン・デューイの言葉だという。出典にあたって確かめたわけではないので、そのフレーズのいわれている文脈はわからないため誤解している可能性は否めないものの、習慣について語る文章では頻繁に引かれる言葉であるため、多くの人々の心を捉え続けていることは確かだろう。経験的にも、悪い習慣によってこれまで無駄にしてきた様々なことが思い浮かぶし、良い習慣を身につけることが高いパフォーマンスにつながることは普通にありそうなことだ。 また、時間は誰にとっても平等であるみたいなこともよくいわれる。長い目で見れば早

先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。 研修について コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。 研修の内容は

昔っから「拙速は巧遅に勝る」なんていいまして。うちの大親分の受け売りなんですが。 これは早い話が、たとえ拙いことであろうと、巧くても遅いよりは速い方がずっとマシであるというわけですな。現代風には、Facebookの創業者、マーク・ザッカーバーグさんなんて方がDone is better than perfectなどといってるそうで、あれだけのサービスを作り上げた方のお言葉とあってみりゃ、ひとつ傾聴しようじゃないかと、そういう気持ちになるわけです。 もとはといえばこの言葉、古代中国の孫武てぇお方が、最古の兵法書と呼ばれる『孫子』ってぇ本でいったと、そういうことになっておるわけです。 新訂 孫子 (岩波文庫) 作者: 金谷治出版社/メーカー: 岩波書店発売日: 2000/04/14メディア: 文庫購入: 17人 クリック: 64回この商品を含むブログ (101件) を見る 原文はこんな感じです

こんにちは、あんちぽちゃんです。GMOペパボで執行役員CTOや技術部長やペパボ研究所長をやっております。 Pepabo Managers Advent Calendar 2016の第1日目の記事を担当します。 www.adventar.org あなたにはリーダーシップはありますか？ 突然ですが、リーダーの皆さんに質問です。 「あなたにはリーダーシップはありますか？」 そう質問されて「私はリーダーシップに満ち溢れている」と100%自信を持って答えられる人はわりと少ないんじゃないかと想像します。「そういう面もあるけど、足りてはいないかもしれない……」と反省する人が多いでしょう。 私だって、リーダーシップにあふれるリーダーになりたい！ リーダーシップのロバストな2軸 そもそもリーダーシップとはなんでしょうか。様々な人々があれこれと自説を述べていますが、それらを総覧すると、畢竟「Performan

GMOペパボにおいて、チーフテクニカルリード(略称: CTL)という職位を作りました。既に以下のブログエントリで新任の2人がエントリを書いているところですが、制度設計者として、その背景を述べてみたいと思います。 diary.shu-cream.net ten-snapon.com GMOペパボの執行役員CTOになって1年半*1、その前に技術責任者に就任してから早2年*2が経過しました。その間、組織面においては、「いるだけで成長できる環境」*3、技術面では「事業を差別化できる技術」*4というコンセプトでやってきました。まだ道半ばではあるものの、逆にいえば、通るべき道は見えているともいえます。 そんな中で、この2年間、ずっと気にかかっていることがありました。 組織的にはエンジニアの人数が90人弱になり、近いうちに100人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい

こんなことを書いた。 私のマネジメントスタイル、「いいじゃん」「いい感じに」「バーンと」の3つしか話してない。— あんちぽちゃん (@kentaro) July 6, 2016 というだけだと雑過ぎて酷い人間にしか見えないので、補足する。 世の中にはいろんな環境があるだろうが、そもそもうちのような採用を重視している会社では、基本的に信用できる人々で構成されていることが前提。その上で、たくさんの人々との関係性の中で、成果を最大化するに際して重要だとおもうことに、以下の3つがある。 つねに肯定的・ポジティブ 仲間を信頼して任せる 大きなスケール観を持つ 細かいことや短期的な観点からいうと「もうちょっとどうかしてほしい」という気持ちになることはある場合もあるだろうが、そこはいったんぐっと引いて置いておく。その上で、上記の3つを伝え、お互いに内面化し、その考えを元に実行していくことがよかろうと思っ

このエントリでは、僕がこの2年弱で読んだ約300冊のマネジメント関連本から、100冊を選んでカテゴリ別に紹介します。 背景 2014年8月に、それまで前々職から現職に至るまでいちエンジニアとしての経験しかなかったところから、総勢70人を越えるエンジニア組織のマネジャーになりました(参照: GMOペパボ株式会社の技術責任者に就任いたしました)。 僕は、決して地頭がいいわけでもなければ、コミュニケーション力に長けているわけでもなく、他人以上に努力をして初めて人並みに近づけるかもしれないというぐらいの人間です。それに加えて、冒頭に書いた通り、エンジニアとしては多少の経験は積んだものの、マネジメントについては完全に門外漢。経験に頼るわけにもいきません。諸先輩方にOJTしてもらいつつ身に付けるにも、既にマネジメントの業務は始まっているわけです。 「さて、どうしよう？」と考えた時、まずはとにかくマネジ

本日6月28日、大安吉日ということもあり、目黒区役所に婚姻届を提出しました。特に書類上の不備等がなければ、受付日の本日が受理日となり、すなわち婚姻の成立日ということになります。 かねがねインターネット上で「結婚したい」と書いておりましたところ、「結婚しましょう」というお申し出がありました。私が結婚したいという意志を述べていたことが本心からなのであるとすれば、呼応したお申し出に関してはこれを受けるのが合理的です。 物事を合理的に判断するというのが私の信条ですので、その観点から本件について考察を行いました。その結果、現に私の意志が本心からなのであってみれば、すなわちお申し出を受けることは合理的であると判断し、婚姻届の提出に至りました。 なお、お相手につきましては、一般の女性ですので公開は差し控えさせていただきたく存じます。何卒ご了承くださいますようお願い申し上げます。 というわけで、今後ともみ

GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -

DeNAのZIGOROuさんによる技術選択とアーキテクトの役割というスライドを拝見して、大いに感じるところがあったので、少し書く。といっても、技術的な話というよりは、もうちょっと違うレイヤの話(技術選択についても思うところはあるのだけど、それはそれについて述べたスライド*1を参照していただきたい)。 経験曲線効果 経験曲線効果という言葉がある。元は、ボストン・コンサルティング・グループ(BCG)のコンサルタントによって提唱されたものだ*2。このような図*3を見たことがあるだろう。 Wikipedia*4には以下のように説明されている。 経験曲線効果(けいけんきょくせんこうか、experience curve effect)とは、経験と効率との間の関係を示す経験則である。単に経験効果とも呼ばれる。一般に個人や組織が特定の課題について経験を蓄積するにつれて、より効率的にその課題をこなせるように

様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長

Nexus 5を常用しているAndroidユーザになってしばらく経つので、そろそろAndroidアプリを作りたい気持ちになってきた。先日、そのためにMacBook Proを新調したほどの、気の入れようである。ちょうど3連休だったので、2日目・3日目を使って、あれこれ調べながら、初めてのAndroidアプリ開発をしてみた。 kentaro/palimpsest · GitHub やりたかったこと まずは簡単なタスク管理ツールを作ってみようと思った。こんな感じ。 毎日習慣的に行いたいタスクがいくつかあるので、ちゃんと習慣的に行えるよう管理したい タスクは、名前と回数からなる(例: 腕立て伏せを30回する、英和辞典を5ページ読む、みたいな) また、ちゃんとしなかった場合は、前日以前の回数が今日の分に加算されるので、ちゃんと毎日やらないと大変なことになる 画面 ほぼ「sqliteのテーブル1つに対

この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。

タイトルは煽りです。 『アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで』をご恵贈いただきました。ありがとうございます。 アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 本書の扱う計算理論と呼ばれる分野には、前職の同僚たちがそういうのに詳しかったこともあってずっと興味を持ってはいたものの、いくつかの教科書的な本を繙いては読み進めずに挫折することを繰り返していました。その意味で、監訳者あとがきの「これなら私でも読める」という言葉は、自分自身の思いでもあると感じました(もちろん、笹田さんの「私でも」と、僕のそれとではおおいに異なることはいうまでもあり

LL Diver | Dive into Lightweight Languagesで、「GMOペパボのエンジニア新人研修」というタイトルで話をしてきました。エンジニア新人研修については、その実施自体には、僕は既にあんまり関わっておらず、主にid:hibomaや新卒出身の若者たちが担っているのですが、その背景となっている考え方について一度まとめる必要があるなと思っていたので、この機会にまとめてみました。 いろいろ書いていますが、エンジニアがより楽しく働けるようにし、そのことでより高い成果を出すためにあれこれとやっているところです。ご興味を抱かれた方は、是非、以下をご覧いただきたく思います。 キャリア採用 / アルバイト採用 | 採用情報 | GMOペパボ株式会社

標題の通り、8/1付けでペパボの技術責任者に就任しました。あわせて、@hsbtさんがチーフエンジニアに就任しました。技術者の体制を強化したことで、Webサービス事業者、すなわち、技術の会社として、さらに高い成果を出していけるよう努めたいと思います。 ちなみに、CTOでも役員でもありません。たとえていえば、技術部長みたいな感じの立ち位置です(うちには技術部という部署はありませんが)。 ところで、その技術責任者の主な役割を、以下のように定義しています。 技術的な会社の意思決定に貢献し、また技術面における中長期的な計画の策定・執行を行う。 経営陣、幹部会議、技術基盤チーム及び技術専門職へ情報の橋渡しを行う。 技術専門職の人事、技術基盤チーム予算に関する責任を有する。 会社におけるエンジニア出身の幹部として、適切な経営判断に貢献するとともに、それを技術者に橋渡しをし、また、技術者がより力を発揮でき

ペパボの新しいエンジニア評価については、ペパボのエンジニア評価制度をパワーアップしたで既にお知らせしたところです。さて、今回その評価が終わり、総評を書いたので、さしつかえない範囲で公開します。 ちなみに、技術上級職については既に「ペバボのエンジニア職位制度のアップデートについて」で紹介しています。そちらも御覧ください。 制度の概要 そのエントリにもある通り、新しい制度では、以下の特徴があります。 エンジニア全員を、エンジニア集団である技術基盤チームが評価する GitHubに評価用の提出資料をまとめpull requestを出してもらい、それに基いて、結果も含めて全員にオープンな状態で評価する あらためて上記のエントリを引用すると: 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。

ペパボで行っているエンジニア職位制度について、最新情報を共有します。 本エントリの背景 ペパボで行っているエンジニア職位制度(シニアエンジニア、アドバンスドシニアエンジニアの選考)については、制度の運用当初に、当時の責任者であるmizzyさんがPaperboy's engineer evaluation system - Gosuke Miyashitaというエントリで紹介しています。その頃から2年半ほどが経過し、また、責任者が変わったこともあるので、あらためていまはどういう感じなのかお知らせしたいと思います。ちなみに、一般のエンジニア評価制度については、新たに運用開始した内容を、既にペパボのエンジニア評価制度をパワーアップしたでお知らせしています。 本エントリの目的 そのような、いってみれば内輪の話の共有を、ある意味わざわざ行う目的は、エンジニアとしての将来をあれこれと検討している社外の

インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした