7年間のCTO人生を振り返ってみる
2015年8月、株式会社ビズリーチにおいてCTOから事業責任者へと職務が変わり、もうすぐ半年が経過しようとしているところですが、一度、7年弱に渡るCTO人生を振り返ってみようかと思います。 CTOとは何をする人ぞCTOとはChief Technology Officerの略。最高技術責任者とも言われます。AWSさんや、TechCrunchさんなどが主催する、CTOを集めるイベントに参加させて貰うと、たくさんのCTOの方とお話する機会もあり、時々、CTOの役割って何なんでしょうね？なんていう話になることがあります。お話を聞くと千差万別、まだ役割が完全に決まっていないくらい、歴史の浅い役割であるということと、結局はトップの一人なので、最終的にはその人ができる限界値が役割になっているのだと思うのですが、ひとつのケーススタディということで、僕がやってきたことを綴ってみようと思います。 サービスの立
僕、28歳「お金を稼ぎたいです、何でもやります、お仕事ください」
8年も会社をやっていると社員も増えて、新規事業を社員に頭から任せていくなんてことも出来るようになりました。僕自身、こういうことが出来るようになるなんて、凄いなぁと思うわけです。誰かに事業の決裁権を任せるというのは、きっと失敗も沢山するだろうと思いながらも信じて、ある程度のロスも含んで任せるわけなので、会社に体力が無ければこういうことは出来ないので、そういうところに会社の成長を感じるのです。 さて、こうなると新規事業のアイデアを良く聞くことになりますが、「爆発的で大きな利益を出します」という話を聞くことはほとんどありません。今世の中に無いもの、あったら良いもの、理念、考え方、そういうものを沢山聞くことにはなりますが、事業計画を見ると、ガクっとなることや、突っ込みどころ満載なパターンが多くて非常に面白いです。 話は少し変わりますが、企画系を主業務に持っている社員から、時々ビジネスやサービスに対
武器増やすため、ベクトルを定める
エンジニアリングマネジメントを思考している中で、エンジニア・デザイナー・プランナー・PMなどのロールに限らず、キャリアや目標を考えることが多いが、わかりやすい考え方と日本語として視座・視野・視点で語るのがシンプルだと思われる。 視座は物事を見る姿勢・高さ。視野は広さ・範囲。視点は位置・方向性（ベクトル）視座の変化。抽象度を上げる作業。例えば、いちサーバーサイドエンジニアとしてキャリアをスタートしたとするとまずは単独でコードをかけてインクリメントを作る上げるのがファーストステップになることが多い。その時の視座は「個」で十分であり、ぶっちゃけそれ以外はそこまで考えなくても良い。もちろん考えてもよいがチームが個に期待している部分としては、まず単独で生産性を生むまでが必要である。 特にこうしたシニアエンジニアではないジュニアの段階では、とにかく武器を増やしていくことが目標になることが多いので比較的
10 Tips for Eager Loading to Avoid n+1 Queries in Rails
Eager loading to prevent n+1 queries is great if you know how to do it! However, the syntax and use cases can be a little nuanced. Here are 10 tips for getting it right. 1. Use the Bullet gem to identify n+1 queries to fixInstall the gem, configure the settings, then browse around your app in development. You’ll get a popup alert on every n+1 query and see an indication of how to resolve it by sho
エンジニアのキャリアに責任を持つためのスタンスとスキルの評価指針
わかりやすく伝えようとすれば、それらのロールをキャリアとして伝えると思います。ただし、『あなたは〇〇がキャリアとして向いています』と伝えたとしても、自分と相手とではその職種の守備範囲の認識が違う可能性があります。そのため、『A, B, C があなたは得意なので、〇〇がキャリアとして向いている。〇〇の責務は D, E, F がある』のように具体的な Responsiblity に着目して伝えていくのが良いでしょう。 キャリアなんてあってないようなものさて、引用文の中に『このご時世、キャリアなんてあってないようなもの』ということも記載しています。キャリアという用語は上で述べたようにとても曖昧で認識齟齬が発生しやすい用語です。 キャリアとしてロールを伝えるよりは職責の範囲（＝スキル）を共通認識するためにフィードバックをするのと、そのスキルが所属する会社や事業に依存しないファンダメンタルなスキルを
「良いエンジニア」を言語化してみました
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を
スタートアップでのプロダクト開発はRailsで必要十分
僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 本格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドはReact+Redux
プロダクトマネジメントの歴史と進化 by Martin Eriksson – Waicrew – Medium
BY MARTIN ERIKSSON ON OCTOBER 28, 2015 以下は、Martin Erikssonによる「The History and Evolution of Product Management」の翻訳です。本人の許可を得て掲載します。プロダクトマネージャーになりたての方も経験豊富な方も「プロダクトマネージャーという役割はどこから来たのか？」「なぜマーケティングやUXなどの多くの分野と交差しているのか？」といった質問をよくしている。プロダクトマネジメントに確固たる歴史があるわけではないが、そのルーツについて考え、時間の経過とともにその役割がどのように進化したかを理解するのは有益だろう。少なくとも、我々の能力や思考が発達するにつれて発生する、組織のトレードオフを理解するのに役立つはずだ。 歴史現代のプロダクトマネジメントは、1931年にP&GのNeil H. McEl
AWS LambdaでRailsを動かす
［速報］AWS LambdaがRubyに対応。さらにカスタムランタイムであらゆるプログラミング言語にも対応へ。AWS re:Invent 2018 Amazon Web Servicesはラスベガスで年次イベント「AWS re:Invent 2018」を開催中です。 Amazon.com CTOのWerner Vogels氏による基調講演では、AWS… これまでLambdaを使う時はNodeやPythonを使ってきましたが、これからは一番書き慣れたRubyも使うことができるので嬉しい限りです。 Web上に「やってみた」記事は既にたくさんあるのですが、Railsを動かした系はまだ少なそうだったのでやってみました。 ゆくゆくは、Wheneverの代わりなどに使いたいという野望があります。 事前準備S3バケットを用意して BUCKET_NAME環境変数に入れておくIAMユーザーを用意して PRO
AWS AppSync + GraphQL + DynamoDB: Building Objects from a Single Table from Multiple Table Entries
Photo by Sasha Lebedeva on UnsplashI’ve really been playing around with AppSync/noSQL since discovering it. As a developer I love having control of my tools, and I have the personal goal of attempting to understand why and how things are built to be used. AppSync provides a nice simple tool to test and learn. It also provides a nice level of documented complication that allows me to think through
Authenticating an AWS AppSync GraphQL API with Auth0
In this tutorial, we’ll walk through how to implement OIDC authentication for your AWS AppSync endpoint using Auth0 as the authentication provider. AWS AppSync has multiple ways to authorize users in order to do things like general user authorization & fine grained access control. The service supports a built-in OIDC provider in Amazon Cognito User Pools as well as allowing you to bring your own a
LayerXのプロダクト開発：チーム・開発プロセス・技術スタック
こんにちは。LayerXのリードエンジニアの@MasashiSalvadorです。今回のブログではLayerXの事業の概要を説明した後に、実際に事業を進めていく中でどのようにプロダクト開発をしていくかを書いていきます。2020年初頭版、LayerXの開発のざっくりとした全体感という感じになるかと思います。開発の進め方、技術スタックとその選定方法とか、社内のチーム開発の様子などを紹介できればと思います。 利用している技術達LayerXの事業とアジャイルな開発プロセスLayerXはブロックチェーン技術を基軸にソフトウェアを用いることで企業のDX(Digital Transformation) を推進し、共同で新しい事業を作り出そうとしています。今現在、多くのクライアント企業様とお仕事させていただいています。 各プロジェクトは コンサルティング実証検証の前提や要件モノを作ることによる実証検証の実
GitHubがGraphQLを採用した理由とは？ – gurateku – Medium
GitHubがGraphQLを採用した理由とは？ 初投稿です。稚拙な文章で至らぬところも多いですがよろしくお願いします; ; 私なりに原文(https://githubengineering.com/the-github-graphql-api/)を読み進めて日本語にしてみました。間違いやおかしいところがあればドンドン指摘をいただけるとうれしいです！ GitHub announced a public API one month after the site launched. We’ve evolved this platform through three versions, adhering to RFC standards and embracing new design patterns to provide a clear and consistent interface. W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
成長するということ
Passwordless Authentication with React and Auth0
Setting Up GraphQL Subscriptions and Push Notifications with Nest JS
How to create AppSync DataLoader
PlantUMLをリアルタイムにレンダリングしてくれるPlantText UML Editor
Create your custom Apollo client for AWS AppSync to use Hooks
Apollo + Next.js, authentication and CSRF protection