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

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

以下のnaoya氏のツイートを見て思ったところを書いてみる。書かれている文字通りのことには完全に同意で、自分自身の行いも反省する余地があろうかと思われた。一方で、多分この発言を読んだひとが誤解するだろうなということもあるので、そのことについて。 マネジメントって業績伸ばすためにやるんですよね？ 業績伸びてないのに俺たちはマネジメントうまくやってますって語るの意味あるんですかね— Naoya Ito (@naoya_ito) December 22, 2016 結論 結論から先に書くと、マネジメントについて語ることは、業績云々に関わらずおおいにやるべきだと思う。それは、たとえばソフトウェアエンジニアリングについての文書などと同様に、世の中にとって大きく役立ち得る。 ただし、それは一般化・抽象化された(つまり、組織が違っても役立ち得る)マネジメントの理論やテクニックに限る。自分たちがそれをうま

役職が変わったりしたこともあって、取締役会のみなさんに説明したりエンジニアのみなさんに考えを伝えたりなど、社内向けにもいろんな資料を作る必要も増えてきて、そういうのが増えること自体どうかというのはともかくとして、エンジニアとしてより活動を広げていくためには、そういう文脈における資料の作り方を身に付けるというのも、ひとつのスキルアップではあります。 これまでもかなりの量のスライドを作ってきたわけですが、そのほとんどが技術イベントで話すためのもので、それはそれでいろんな工夫をしてきたつもりではあっても、コンテキストが違うと、ただ一本調子で同じようにやってもうまくはいかないわけです。上述の通り、昨年後半以降、そういうことが増えてきて限界を感じたので、あらためてものの本を読んだりして学習してみました。 コンテキストの違い ここでいうコンテキストとは、エンジニアだけを対象にしているというよりは「経営

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

GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる

首都大学東京ビジネススクールの2014年度入学試験を受験し、不合格となりました。本エントリでは、この日をもって終わった久々の受験生生活をふりかえります。 受験の経緯 このブログでしばしば書いている通り、去年は勤務先でスクラムを導入したりしていました。ソフトウェア工学的な意味での開発プロセスとして興味深いのはもちろん、僕にとってそれはむしろ、組織とはなんなのか、企業組織とはいかにして可能なのか、そしていかにしてそれを良くし得るのかという、どちらかというと組織論(とか組織社会学？)的な問いを喚起するものでした。 ちょうどそういうことを考えていた折り、尊敬するジム・コープリエンさんらの『組織パターン』という本が訳されて、さっそく読みました。それがとても面白く、実践的にも役立ったので、もう少し組織論を学習してみようと思ったのです。次に読んだのが『組織論 補訂版 (有斐閣アルマ)』という教科書。簡潔

本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が

専門を極めるとか職人技を鍛錬し続けるとかにすごく憧れつつもついついあれこれ手を伸ばしちゃって、よくいえばジェネラリストなんだけど、まあ普通にいって器用貧乏みたいな感じになっちゃうのは、性格的な問題もあるのでしかたないのかもとは思うけど、これだけはひとに負けないと誇れるみたいなのもやっぱほしいよなあとは思う。 とはいえ、では、誰でもがジェネラリストたり得るかといえば、そういうこともない。ジェネラリストであることと、なんでも中途半端ってのとは違うし、そもそもジェネラリストであることには適正があるんだとは思う。そうした適正というものを自分がそれなりに持っているのだろうとは思うので、それはそれでよい。 先日、まきもとさんと飲んでた時にそういう話になったのだけど、彼もまたそういうタイプで自分に近いと思っていたので、その点について話が合って面白かった。まあ、タイプという面で近いだけで、ジェネラリティの

アカデミックな組織論に位置づける感じでアジャイル開発プロセス(特にソフトウェア開発プロセスとしてのスクラム)について書いた研究について知りたい。 ここ2ヶ月、組織論周りの教科書や研究書、それらを学者たちが一般向けに咀嚼して書いた本を集中的に数十冊読んできて思うのは、スクラムでもなんでもいいんだけど、アカデミックな組織論が提供するバリエーションの範囲から出るところはそんなにはなさそうということ。そのうちのいくつのパラメタをいじると、たとえば「スクラム」と呼ばれるものになるという感じ。 なので、これまでの組織論の積み上げをちゃんと学習すれば、議論の余地のないところと議論するべきところがはっきりするんじゃないかなと思うわけだ。議論の余地のないことについて議論しても無駄なので、そういうのはさっさと本を読んで吸収し実践すればよいわけで、そこに時間をかけるべきではない。 で、議論の余地がありそうだなあ

社内で、Ruby開発環境勉強会を行いました。趣旨としては、 Rubyプログラマ歴ひと月未満の僕が、最近自分でやってみた開発環境について説明・実演する それを聞いているひとが「こんなことも知らないのか」とあきれて、いろいろ教えてくれる という会です。いろいろ勉強になったので、とてもよかったです。開発環境やツールまわりの勉強会、面白いので、次回以降もなんかしら開催したいと思います。また、 西園寺おんじ氏: http://p.booklog.jp/book/51223 刺身氏: http://blog.kyanny.me/entry/2012/05/30/164601 の2名も発表してくれました。 とはいえ、単に「教えて」というだけいっても意味ないので、以下の軸に沿って問題を整理しつつ、それぞれについて説明・実演をしつつ、みなさんの意見をうかがう感じですすめました。 シェルの設定 irb/pry

I saw a documentary titled はじまりの記憶, which features Hiroshi Sugimoto. I was so impressed by the movie. I've been thinking of him sort of weird and odd; his works always make me kind of uneasy. His photos blur and emit something doomful aura. I think he is, so to speak, a speculator. He surfs on a wave of modern art capitalism better than anyone and he's been releasing polemic works during decades.

10/14, 15に開催されたPerlの祭典、YAPC::Asia 2011に参加してきました。今年で6回目の開催にして、なんだかんだで今回ようやく初参加。これまでネットで眺めていていたのと、やっぱり実際行ってみると全然違いますね。 PrePANについてのトーク せっかくなのでなんか話そうというわけで、先日オープンしたPrePANについて「PrePAN - DISられないCPANizeを目指して」という題でトークを行ってきました。 PrePAN - DISられないCPANizeを目指して View more presentations from kentaro トークのふりかえり 資料や構成、伝えたい内容を伝えることについてはできるだけがんばったつもりだけど、しゃべり方をもっと練習しないとだめだなー、というか、場数を踏んで慣れる必要があるなあと思った PrePANは、なんかネタ的なモジュー

Perl Mongersの皆様へ: PrePANというサイトをオープンしたので、お知らせいたします(実装は僕、デザインは同僚のスーパーデザイナid:kudakurage)。 http://prepan.org/ PrePANとは？ 社内でこんな話をしたことがありました。 業務や個人的な活動なので、便利モジュールができた〜ということがあった時、んじゃ、せっかくなのでCPANize(CPANに公開)しよっかなと思っても、いくつか不安に思うことがあったりします。 既に似たようなものがあるのでは？ 実装について不安が……。 CPANizeするに際しての名前やファイル構成の慣習がわからない 誰かにちょっとチェックしてもらいたい そのような問題に対する解決の一助となればと思い、サイトを作ってみました。「こんなの作ったけどどうだろう？」とか「こういうモジュール他にある？」とか、いろいろなことに使ってもら

同僚が、perlbrewを使っている時に、MacのCocoa Emacsで意図したperlのバージョンが動かなくて困ってたので、flymakeの設定を見直してみた。 perlbrew.el まず、Cocoa Emacsから利用するperlのバージョンをあらかじめ指定できるよう、以下のような簡単なelispをでっち上げた。 https://github.com/kentaro/perlbrew.el こんな感じで書いておけば、起動時に`perlbrew switch 5.12.3'が実行されるので、いい感じに使える。 (require 'perlbrew) (perlbrew-switch "perl-5.12.3") まあ、(shell-command "perlbrew switch perl-5.12.3")するのと同じなので、perlbrewを実行したいだけなら、わざわざ使わなくても