当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC

このブログを書き始めたのは8/31で、一夜で語り尽くせないので思いついたときにただただ書いていく。途中で公開してしまったら本当にあれだから、ボタンの押し間違えだけは気をつけたい。 まず近い時間のところから話すと、matsumotoryが夏休みに入る前に二人で飯を食ったときから、そうなるだろうなと思う気持ちはあったけども、その3日後くらいに旅先の本人に決断を聞いてから、1週間位まともに寝付けないくらいにはショックだったんだと思う。普段生きてる分には全然考えないんだけど、眠れなくなったのは多分そういうことなんだろうと思った。心に反して体は正直である。それくらい僕は松本さんと働いて多くの影響を受けた、多くを与えてもらったなと思うし、本当に感謝しかないし、彼自身が次のステップに進んでくれたことにも感謝している。 もともと松本さんが入ってきたのは僕がペパボに入ってしばらくしてからで、 「なんかngx

本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。 現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。 2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。 レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やア

2018年9月6日、ビジネスエアポート六本木にて「米国アップル社、マイクロソフト社、そして国連本部も認めた83歳のアプリ開発者 若宮正子氏登壇！『MY SMART WORK LIFE』セミナー②。世界を魅了する理由に迫る!!」が開催されました。本パートでは、若宮正子氏の生い立ちからアプリ開発に至るまでのエピソードについての講演模様をお送りします。 突然世界中で有名人になってしまった、若宮正子氏の講演 若宮正子氏：みなさん、こんばんは。若宮正子です。どうぞよろしくお願いいたします。だいたいの人はみんな「マーちゃん」って言っているみたいなんですけども、戸籍上の名前は若宮正子です。 今日お話しすることは、まず自己紹介。それから、今日のテーマであります「私は創造的でありたい」というお話。それから最後に、最近の活動から得られたものです。といいますのも、私は1年半ぐらい前に、急に「にわか有名人」になっ

以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。 上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか？」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1。 あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。 想定読者 良いエンジニアを採用したい偉いひと、もしくは人事のひとです。 前提: 良いエンジニアとは このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニ

先日福岡にて開催されたグローバルスタートアップイベント、Waraku SummitにてWiLのパートナーである琴 章憲氏との対談をする機会をいただいた。スタートアップをはじめとして、日本企業のグローバル展開に関するトピックにてのディスカッションを行った。 そこで、彼が日本企業がシリコンバレーの企業に勝てない一つの大きな理由として挙げていたのが、決断と実行スピードの違いだ。例えば彼が前職で出向していたTwitter社でのエピソード。 それまではプログラミング言語としてRubyを利用していたが、ユーザー数の増加と今後のスケールを念頭に、ある日突然エンジニアリングトップよりScalaに切り替えることが決定された。これでTwitterのエンジニアは問答無用で翌日からScalaを利用しなければならない。さもなければ会社に残れないからだ。 これがもし日本企業で似たような事があったとしたら、内部調整とエ

こんにちは、デザイナーのNottyです。 みなさんは、DI（ダイナミックアイデンティティ）という言葉を聞いたことはありますか？ ロゴは普遍的で永く使われることを前提として、VI（ビジュアルアイデンティティ）などの静的イメージを創り上げるアプローチが主流でした。 今回は、それとは全く異なるアプローチとして注目を集め始めている、DIという概念、手法について実例を交えてご紹介します。 現在、プロダクトやサービスがデジタルにシフトしていっていることにより、めまぐるしく変化する世の中に対応できる有機的なVIを求められる場合があります。 それが流動的・可変的にブランドメッセージを発信するDIという概念です。従来は、ロゴマークは競合他社の違いや企業の理念や思いを示す静的（変わらない）なロゴマークが主流でしたが、動的なロゴや制約の中でコンテンツ・環境・時代に合わせて変化を求められる場合があります。

――米国や中国に比べ、日本は人工知能開発で遅れているといわれています。なぜ日本はこの競争に負けているのでしょうか。 松尾さん　それは、日本がインターネットで世界に負けた理由と似ているのではないでしょうか。 一つは、技術の取り入れ方が非常に遅い点。1990年代後半には若者たちが「これからはネットの時代だ！」と言っていたのに、上の年代の人たちが理解しませんでした。「信用できない」「オタクが使うだけ」と否定し、新しいものが生まれなかった。 今もそれは同じです。一口にAI、人工知能といっても、新しい技術の中心であるディープラーニングに対して、従来の分野へのこだわりが強く、拒否感が強い人も大勢います。 もう一つは、若い人が力を持っていない点。若い人が自分の裁量で自在に動けるような社会環境になっていません。彼らに裁量を与えて何かやらせれば絶対に何か起こるんですけど、それをやらせないから変化が起こらない

天才プログラマー・佐藤裕介は限界を感じていた――知られざる過去、そこで得たメルカリ対抗策：2社を上場に導くも（1/6 ページ） カード決済を簡単にする「Coiney」と、オシャレなネットショップが2分で開設できるサービス「STORES.jp」が2018年2月に経営統合して生まれた新会社、ヘイ株式会社（以下、hey）。「こだわりのある作り手」を決済とEC運営で支援するこの会社の代表取締役にはプログラマーの佐藤裕介さんが就任しました。 佐藤さんはGoogle出身、株式会社フリークアウト、株式会社イグニスの2社を上場に導いた、34歳にして一流の経営者。しかし、そんな彼がheyを設立したのは、順風満帆に見えるキャリアの陰で抱えていた、自分のある「限界」を突破するためだったそうです。 その限界を超えるため、佐藤さんが答えを求めて訪れたのは、ある「意外な場所」。そこで彼の内面に起きた変化、そこから生ま

プロデューサーとして駆け出しで売り出し中のころ、 カンヌ広告祭に行く機会に恵まれました。 カンヌに着いてホテルのロビーにいたら その当時メチャクチャ売れてて、いい仕事していて、威張っている感じの 他の会社の名物プロデューサーに声をかけられました。 「おう、お前が櫻木か、最近名前聞くなあ、生意気なんだって？」 プロダクションのプロデューサーは、実は他社のプロデューサーとの 横のつながりはあまりありません。 引き抜きやプロダクション間の移籍の疑いがかけられるし いろんな機密を持っているので、他の会社の人と仲良くするのは よくないとされていました。 コンプライアンスにうるさくなった今でもそうですが。 そういう意味で、他社のプロデューサーの話を聞ける機会は 飲み屋でたまたま出会うか、日本から遠く離れたカンヌ広告祭ぐらいしかありませんでした。 カンヌでのプロデューサーの役割は、建前は広告の勉強ですが

Rails Developers Meetup 2018 Day 3 Extreme で発表させていただきました - https://techplay.jp/event/679666 - 質問: https://railsdm.herokuapp.com/issues/76 協力: FlyTeam: https://flyteam.jp/ レイルラボ: https://raillab.jp/

スマホアプリの分析プラットフォーム「F.O.X」が主催する、スタートアップで働くエンジニア向けコミュニティイベント「F.O.X Meetup」の第3回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としている本イベント。今回は、「スタートアップのチームビルド」をテーマに、経験豊富なプロジェクトリーダー達が自身の知見を披露します。株式会社マクアケの吉田慶章氏は、「さぁ！今すぐプロジェクトリーダーに立候補しよう」というテーマでプレゼンテーションを行いました。チームの特性に合わせたチームビルディングやマネジメント手法について、自身のノウハウを明かします。 プロジェクトをリードする技術 吉田慶章氏（以下、吉田）：こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思い

エンジニア組織をリードする人に、大きく3つの責務を求めたい そんな風に考えるようになったという話をします 求める3つの責務 テクニカルマネージメント ピープルマネージメント コミュニティマネージメント 1. テックリード 品質、生産性、技術的な承認、技術的な評価等、組織の専門性について責務を持つ人 2. エンジニアリングマネージャー 教育、採用、人事的な承認、人事的な評価等、組織の人間性について責務を持つ人 3. コミュニティマネージャー 提起、反応、支援、新陳代謝等、組織の社会性について責務を持つ人 コミュニティマネージャー？ これが今回話したいことです エンジニア組織に1と2が重要な事は、多くの方が言葉にしてくれています プラスで僕はエンジニアコミュニティをリードする責務が必要なのではないか？と思うようになりました コミュニティをリードするということ リードすると書きましたが、コミュニ

早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの？という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク

直面する問題を解決したらkaminariができた。Ruby / Railsコミッター松田明のOSS開発の実像 世界中のRubyプログラマに使用されるOSSであるkaminari。これを手がけたRuby / Railsコミッター松田明さんに、開発背景を聞きました。 「これがあったら便利なはずだ」という予測。 あるいは、「これが問題だから、解決する」という現状認識。 新たな技術が生み出される源流にあるものとは、一体なんでしょうか。 Ruby on Rails（以下、Rails）を用いたWebアプリケーション開発において、圧倒的な存在感を放つページネータであるkaminariを開発した松田明（まつだ・あきら／ @a_matsuda ）さんの場合は、“絶対に”後者であると語ります。 Rails、そしてRubyのコミッターでもある松田さんは、まさにRubyを用いた開発の最中、先行するソフトウェアに感

これは2018年に書いたnoteですが、2023年4月28日に「山の上のパン屋に人が集まるわけ」という本がサイボウズ式ブックスより出版されました！ 内容はこのnoteの内容ではありませんが、タイトルはこちらから取りました。私の幼少期から創業期、現在の経営までストーリーとしてお読みいただけます。こちらのnoteが気に入ってくださった方はぜひご購入していただければ幸いです！ ⏩Amazonではこちらから 初めまして。株式会社わざわざの代表の平田はる香と申します。これからnoteに経営のことを中心に書き綴っていきたいと思います。最近の趣味は、会社の現状分析です。夜に好きなお酒を飲みながらデータを見ながら会社のことを考えるのが大好きです。 このnoteにはパンと日用品の店「わざわざ」の経営から考えたことを書いていきたいと思っています。note一つ目の記事はまずこちら「山の上のパン屋に人が集まるわけ

僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた

一区切りつけたかったのでまとめておくことにした。 誰かの参考になれば幸いである。 表題の通り 800日間毎日コードを書き、コミットし続けた。 正確には805日、計算してみると2年2ヶ月15日らしい。 とはいえ、仕事としてコードを書いた日は含めていない。 あくまでプライベートの時間を使って趣味として書いた日数である。 始めたきっかけ 始めたのは2016年1月1日。 当時、今後もソフトウェアエンジニアとして生きていくためには、業務時間だけでなくもっとコードを読み書きし、インプットとアウトプットを増やしていく必要があると思っていた。 ふと、John Resig さんの Write Code Every Day の活動が話題になっていたことを思い出し、自分も GitHub 上で始めてみることにした。 リポジトリは下記にある。 https://github.com/emsk ルール 毎日コードを書い