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

ヒトメディアの3人による『Webエンジニアの教科書』をご恵贈いただきました。ありがとうございます。 Webエンジニアの教科書 作者: 佐々木達也,瀬川雄介,内藤賢司出版社/メーカー: シーアンドアール研究所発売日: 2015/03/26メディア: 単行本（ソフトカバー）この商品を含むブログ (3件) を見る 桜の満開に咲き誇る今日このごろ、新入社員が入ってくる季節です。やることに濃淡はあれ、各社それぞれで新人研修をどう行っていくか、あれこれと考えを尽くしているところでしょう。ペパボでも「GMOペパボのエンジニア新人研修」に書いた通り力を入れていて、今年もまた、新しく入ってくる人々に対して円滑な組織社会化をもたらせるよう、受け入れ準備をしているところです。 エンジニアの研修カリキュラムとしては、大きくはRailsによるWebアプリケーションの基礎、構成管理ツールを用いたサーバ構築のふたつをや

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

今日発売のKindle Voyageが早速届いた。 Kindle Voyage届いた Kindleは、Fire初代 → Touch → Paperwhite初代と使ってきて、いまは amazon.comの本はPaperwhite amazon.jpの本はiPadのKindleアプリ で読んでいる。なぜ分けているかというと、アカウント統合がうまくいかなかったからというのと、jpで買うのは漫画もあるのでという理由。今回Voyageを買ったので、jpについても書籍はVoyageで読むことにする。 で、早速空き時間に数十分ほど本を読んでみたのだけど、Paperwhiteとくらべて2倍ぐらい高いけど、なんでそんな高いのかはよくわからなかった。 Paperwhite初代に比べると反応はやいのはいい ページ送りのハードウェアボタン(？)は悪くはないけど、なくても困らない 他なんかいいところあるの？ とい

社外のある技術者たちと「会社のエンジニア、あるいは、エンジニアリングがどうなっていくべきかというビッグピクチャみたいなものがあるか？」という話になった。その場ではいろいろな内容が出てきたわけだが、不詳わたくし、技術責任者という役職を務めている者としてどう思うかというと、そんなにかっこいいことを考えているわけではなかったりする。実際にかねがねいっていることがあるとすれば: 変化に対応できるよう、エンジニアとして成長しつづけよう 他のひとにない、何か自分が一番の得意分野を作ろう というぐらいである。このフレーズだけでいえば、なんのことはない、いってみれば当たり前、というか、誰でも思いつくような話だ。しかし、ことはそう簡単ではないと思っている。 ひとくちに「成長」といったところで、どれぐらい成長すればいいのかという問題がある。一番わかりやすい基準は、我々は上場企業であるということからいうと、市場

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

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

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