とある創業社長のお悩みとして、 「いつも社員が考えた企画案を最後にひっくり返す役割になってしまう」 ということについて、胸が痛いという話をしていた。 こういう経験がある人は特にベンチャーでは少なくないだろう。親会社などからこれを食らうのは辛い話であるが、小さな組織でも、それなりにダメージはある。場合によっては、ワンマン社長の元で、好きなことができないと絶望してしまう人もいるだろう。 しかし、これについて、そのように見方を変えられるかが生き残りのカギである。 「社長にエスカレーションされるまで企画案の問題点に気が付かなかった企画、チーム、組織の問題」 と。 創業社長は、その会社で一番、そのビジネスについて考えている立場である。ちょっとやそっとで創業社長を上回るアイディアを出せると思ってる方が考えが甘い。ある意味、ひっくり返されて当たり前だと思うほうが話し早く進む。 ここでミニCEOと呼ばれる

次世代教育フォーラムというデジハリのイベントに登壇させてもらった。 オープニングが稲見先生の基調講演から始まるというKMD生としても胸熱な展開。 僕はその３セッション目のG’s Academyとしてのセッション。G’s責任者の児玉さんがモデレータで山崎先生と僕が話す場でした。 まず、お題として「何故エンジニアが不足しているのか？」という質問。 毎日、なんらかしらの採用面接に携わっている身としてつくづく思うのだが、「エンジニアは足りなくて当たり前」という感覚を持っている。 雇用側という立場で「何故足りないのか？」と聞かれれば、「お断りもしてるし、断られてもいる、採用で妥協してはいけないので、我々のフェーズにおいて採用できるレンジは極めて狭い」ということだと思う。 それがチームフィッティングであったり、スキルレベルであったり。スキルレベルと言っても、人によってフェーズはまちまちで、まず完成して

以前、HIGHT OUTPUT MANAGEMENTという本が話題になっていたが積読で貯めていたので、ちと気合を入れて読んだ。本書は1995年に刊行されたアンドリュー・S・グローブというインテルのCEOだった人が自分の言葉で描き下ろした本である。 本書が画期的なのはミドルマネージャの重要性を説いていることである。 決して本書はトッププレイヤーのマネージャ（経営者）にだけ書かれている本ではない。 BASE社もインテルで開発されたOKRや1on1 mtgを取り入れているので、そのことが書いてある本書は非常に重要な本なのである。 しかしながら翻訳ということもあるし、決してライターが書いたわけではないので非常に読みにくい本で、ついつい、かなり飛ばして読んでしまったので、二度三度読むためにインデックスをブログに記録しておこうと思う。ちなみに、紙でまず購入して一通り読んで、次に電子書籍版を購入した。ど

例えば、今時の海外のゲームではAIがゲームバランスを調整していると聞く。 自動的なゲームバランスの調整にAI的なロジックが使われていて、ゲームとしての適切なグルーブ感を自動調整しながら、ユーザーの楽しさを継続させるという部分らしい。 文章に書くと昔からアルゴリズムで行われているこのようにも思えるが、きっと、もっと高度なことが行われていると、一旦仮定する。 いずれにせよ一番重要なのが「ゲームとして楽しいバランス」。これを決めるのは、ゲームクリエイターの味付けでありセンスであるというところ。 昔、天才ゲームクリエイターと呼ばれる人と一緒に仕事をしていたので聞かされた話があって、それは現在の業界的に正しいのかはわからないが、ゲームが完成する直前になってからがゲームクリエイターとしての勝負だということ。 決して単純なロジックやフローチャートでは語りきれない「天才だけがもっているセンス」をどうにかパ

BASE社のオフィスが最近増床しましてイベントスペース的な余裕がある今のうちにイベントをやろうということで、転職エージェントのアイムファクトリーさんとの共催でこんな話をさせていただきました。 この話を思い出したのは、まつもとゆきひろさんの素敵なお話の記事を読んだからでありまして、Ruby書いたことないけどRuby書いた人の講演に行った – みたぬメモ、おお、そういえば、俺も同じタイトルでしゃべってたなと、お恥ずかしながら共有させていただければと。 僕の場合は、どっちかというと普通の会社員として生きていくための生存戦略かもしれないですね。 スライドだけでどこまでご理解いただけるかは不明ですが。 むしろ、会場で質問をしていただける方々が多数いらっしゃいまして、そっちでの受け答えのほうが全然面白かったかなって個人的には思っています。 （あと、今思い出した。元Klab CTOの仙石さんのFaceb

先日、僕がメンターで参加させていただいている、デジハリのG’s Academyという起業家養成学校の企画で、SIerで働く人が、Web系企業に転職するためのお話をさせていただきましたので、加筆修正したスライドを公開します。 Web系と言っても、Webがコモディティ化し、社会の中で当たり前の存在になっていく中でなんだよそれって思う人もいるかもしれませんが、そうは言っても、まだまだ壁があるのも事実。その辺を整理した上で、カルチャーが違う世界にダイブするにはどうしたらいいか？ということを書いてみました。 ご興味がある方、全画面表示じゃないとちゃんと見えないかもしれないので、PCの全画面表示などでご覧いただくのをオススメいたします。 この資料を作っていて、BASEにおいても、SI出身者も採用できたらいいなと改めて思いました。 人材紹介会社からのSI出身の人を止めていたりしてたんですが、少し、選考方

Huluで配信されている「シリコン・バレー」というスタートアップを描いたドラマがある。 主人公のリチャードは、いわゆる非コミュで、少し偏執的でオタクのエンジニア。彼が開発した技術が優れていて、同じシェアハウスにいた腕利きだがワガママなエンジニア達と起業するのだが、元々、ライバルだった彼らは、お互いの立場を譲らない。 シーズン１の２話で、リチャードのエンジェルであるアーリックが言うセリフがある。 「お前は会社のためにイヤな奴になれ」 リチャードは、非常に優しい奴で、ワガママなアーリックに対しても、他のメンバーに対しても、文句を言えない。 投資家から、スリムな組織にするという要求を受けたリチャードは、同じシェアハウスのメンバーから、誰をメンバーにして、どのようなストックオプションの配分にするかで揉める。リチャードの親友で、良い奴だが能力のないビッグヘッドを切ることができない中で、メンバーから突

WELQ問題は、永江さんとbuzzfeedあたりの対応を起点として？、ついにWELQの広告販売の停止まで来たらしい。 僕は誰を応援するとか批判するか、というよりは、今後起きる、現象に興味があってこの記事を書いています。 Yahoo!さんだったら、Y!ポータルに掲載して、情報を買えば良かったんだろうが、ポータルを持たない会社、かつ、とくに専門家ではない人達がSEOを踏み台に、医療カテゴリのメディアでトップランクまで上り詰めるのは、さすがだなと思いつつも、 さすがに、こういうのを見ると、うーん、という気にはなってくる。 WELQのリライト記事の危険を医師が訴える ビジネスでメディアを運営するって難しい。 SEOについては、SEOの専門家である辻さんが書かれているとおりの流れ SEO専門家が語る「GoogleがなぜWELQをBANしないのか」によって見えるその狡猾さ Googleも批判されるべき

うだうだ記事を書く。あんまりブロガーさんのように、懇切丁寧に説明する意識はない。うざかったら途中で離脱推奨です。 とある理由で、本番のデータを修正することになった。休日だったので僕が対応したのだが、その部分のデータ修正の経験がなかったので、ソースコードから調べて依存関係を解決するSQLを書き、Slackを通じてコードレビューをお願いして、無事修正タスクは完了した。 所要時間は、作業開始から40分。 日常的にソースコードをいじっていて、データ構造を熟知しているメンバーなら、５分もかからないで終わる作業だろう。もしそうならば、８倍の速度差が生まれている。 その８倍の速度差が顧客満足度に影響をおよぼすのであれば、その人は、僕よりも8倍速で得られる顧客満足度の分だけ、仕事ができると評価ができる。 その人材がいれば5分、いなければ40分。この差はとても大きい。その差が大きいと思うのであれば、そういう

組込み技術者向けキャリアガイドの開発という記事から、開発管理職としてのキャリアパスを読み解く。 プロダクトマネージャへのパス（開発担当部長級） ソフトウエアエンジニア（エントリ）→ソフトウエアエンジニア（ミドル）→システムアーキテクト（ミドル）→プロジェクトマネージャ（ミドル）→プロジェクトマネージャ（ハイ）→プロダクトマネージャ（ハイ） プロジェクトマネージャとして、数多くのプロジェクトを完遂させたマネージャが、経営的な視点を持ってプロダクトの企画・研究・開発・販売・保守のプロダクトのライフサイクルを理解した 上で、プロダクト全体のマネージメントを行えるようになった時に到達できる。 ハイスキルソフトウエアエンジニアのパス（エキスパート、シニア級） ソフトウエアエンジニア（エントリ）→ソフトウエアエンジニア（ミドル）→システムアーキテクト（ミドル）→ソフトウエアエンジニア（ハイ） ソフトウ

最近、スタートアップにおいて、LLの進化、型言語への意識が高まっている。LLを横目にJavaをやってきた人達からすると、「ほれ見たことか」という意識もあるのではないか？ 少なくとも以前、僕の部下だったJavaのエンジニアは、当時Perlが隆盛だった頃にそのようなことを言っていて、いずれJavaの思想に近づいていくだろうと予言をしていたら、絶賛、今、そうなってる。 まぁ今更、何がどうなって、結果そうなったのかは、どうでも良い。その間に当時のスタートアップはチャレンジフェーズから、巨大になり、社員を増やし、社会的責任が増えた。その結果として、安全な型言語や、TDD、継続的デリバリーなどを通じて、Javaの世界にあった設計思想に近づいていっただけなのだと思う。 「とりあえずやってみる」「やれることから初めてみる」、スタートアップの初期フェーズは、当たるかもわからないフェーズだし、ソースコードも全

「きっと何者にもなれない自分というエンジニアとしての生存戦略」 という記事が僕の周りでbuzzってた。読んだ限り、そのままでいいんだよ、と、恐縮ながら声をかけてあげたいと思ったわけですが、３点ばかし思うところがあったので雑で恐縮ですが書いてみます。 １．自分は何をしたいのか？願望を持つ重要性 「きっと何者にもなれないエンジニアの生存戦略」として以下の項目を挙げられていた。 1.有名OSSにContributeする。 2.起業する。 3.CxOとしてJoinする。 4.副業として顧問になる。 5.サービスを立ち上げる。 これのいくつか大部分は、「自分がこうしたい」という強い気持ちが必要なので、それがないなら無理に焦らないほうが良い。 OSSでContributeしてる人に話を聞くと、必要に迫られてやったという話をよく聞きます。つまり、issueがあるかないかで変わってくるでしょう。残念ながら

モバツイのサービス終了が発表されました。 Twitterクライアント「モバツイ」がサービス終了へ　12月14日まで jig.jp、「モバツイ」と全関連サービスの提供を12月14日に終了 「モバツイ」と関連する全サービスが12月14日に提供終了となることが決定 あと半年とちょっとで１０周年なんですよね。 １０周年までは持ってほしかったけど、昨今のTwitterの売却騒動も含めて、雲行き大丈夫かなと思っていたところ、この発表のちょっと前にサービス終了の連絡をいただいていました。 サービス譲渡後の現場を知らないので、何が困難だったのかを感じ取れてないのですが、外野から見えるサービス譲渡後に起きたこととして、大きな問題は、 ・Twitterの利用規約変更によるサードパーティクライアントの締め付け ・SSLのセキュリティ問題による、Twitter本家の証明書強度のバージョンアップからのログイン画面に

滅茶苦茶なことを書いてるのでスルー推奨です。 企業が大きくなっていくと、おのずと社会から、その会社は「ちゃんとすること」を求められます。 それまで、全然ちゃんとしていなかったのに、突如ちゃんとすることを求められると、困惑します。 スタートアップも、 「ちゃんとしていないフェーズ」で活躍していた人、 「ちゃんとすることで、会社がつまらなくなってしまった人」 「ちゃんとしている方が力を発揮する人」 「ちゃんとする方向にシフトできずに苦労している人」 など、さまざまな軋轢が起きます。 「ちゃんとする」とは何でしょうか。 先日、鹿児島のさくらじまハウスという、さくらじまで開催されたエンジニア向けイベントで、さくらインターネットの田中社長が、こういう一言を仰っていました。 「メリットを求めると、熱量が下がる」 この言葉、すごく刺さりました。 「メリット」というのは、企画を立てた時のやる理由の説明責任

皆さん、部下を信用していますか？ もちろん、私は信用しています！と言ったあなた。 言葉で言うのは簡単ですが、それは正しい信用ですか？ 信用とは、「それまでの行為・業績などから、信頼できると判断すること」と言う意味だそうです。 「信頼」とは、「これをやってくれそうだと期待して、実際にそれが実現した時に抱くもの」だそうです。 つまり、 部下に「期待」という投資をして、リターンが適切に返ってきたら、結果に対して抱くものが「信頼」です。 それらの実績を元に「この人はこれぐらいやってくれる」という適切な見積もりができた時にあるものが「信用」ということになります。 結果として、適切な粒度、適切な難易度のタスクアサインと、良質な結果の組み合わせに現れるハズです。 適切に部下の能力を信用するためには、 「これだけの期待をしてみたら、こういう良い結果が出た」 というファクトベースでの信頼の積み上げを、ちゃん

元nanpi wadapさん呼びかけのイベント。CTOだったNightに登壇しました。 今もCTO職をやらせてもらってるけど、それより前のモバツイ時代のCEO/CTOの話をさせていただきました。 一旦、ネットにもプレゼン資料をアップしてみたのですが、イベント内容がCTOを辞めた理由やぶっちゃけ話を話せという趣旨だったので、どちらかというと「こうすればよかった」という取らぬ狸的な話になったので、イベント会場の文脈では良かったのですが、ネットに公開するのは気がはばかられたので、朝起きてやっぱり資料を消しました。 夜中に見ることができた100人ぐらいの方々はラッキーだったということで。 で、記事も一旦非表示にしてみたのですが、都合の良い所だけは公開しようと思いまして、今後、CTOをやっている人ややりたい人に、このイベントで話した内容から抽出した、３つのCTOの心得なる遺言を偉そうに書いておきます

開発内製をしている組織が、業務委託で外部の方の力を借りて開発をお願いするというケースにおいて、発注者側が業務委託で仕事をお願いする時に思ってることを書いてみようと思う。 エンジニアで独立心が高い人であれば、技術顧問だけじゃなくても、部分的な工数を切り売りして複数のプロジェクトに関わりあいたい気持ちもあったりと思うので、そういう人に向けても一助になれば幸いです。 前提条件 ここ背景的な追記事項なんですが、基本的な対象者は、「社員になってもらえたら超ラッキーみたいな人が、すでにフリーランスだったり、自分の会社を持っていて、別の仕事もやっている」という先方都合が上位なケースにおいて、業務委託でのみ契約に至る時に考えたりしたこと、という前提条件を追加しておきます。 ちょっと一般化して書いてみたら、もっと世界が広かったようで、そちらの世界の方で誤解を生んでいるケースもあるように思えました。それは純粋

（言葉遊びみたいな記事を書きますね。その上、用語の使い方が間違ってたらごめんなさい。） 一時期、フルスタックエンジニアって言葉流行りましたよね。ふと、要件どこまでだっけ？と思って調べようと思ったんですが、日本語で調べると、妄想が暴走してロクな話が出てこなそうなので、英語の方で調べてみるとわかりやすい。 What is a Full Stack developer? Server, Network, and Hosting Environment. Data Modeling Business Logic API layer / Action Layer / MVC User Interface User Experience Understanding what the customer and the business need. 個人的には、ネットワーク監視やデプロイなどのインフラ運用

この話、誰に言っても通じない話なのですが、 かつての名作にストリートファイター２ってゲームありますよね。 僕は、そんなに得意なゲームじゃないんですけど、ゲームセンターの対戦プレイでこれをやると喧嘩になるという戦い方があるそうです。 それが、 「最速の足払いをひたすら使って、相手の大技を封じる」 というものです。スト２が面白いのは、大技は相手に巨大なダメージを与えられますが、技を繰り広げる前に、ちょっとしたダメージしか与えられない小技である足払いを食らうと、大技が出せなくなってしまう作りになっています。 それ故に、ひたすら足払いで防御することで、相手に徐々にダメージを与えていくという技があります。 何せ、技を出そうとすると、足払いで潰されるわけですから、姑息な技とイライラされるので、対戦で足払いで勝つと喧嘩になることもあるそうです。 似たようなことが、僕らの日常のタスクマネジメントにおいても

wantedlyで、CTOから新入社員にむけてのメッセージというブログを書いたのですが、 新入社員の転職戦略 by 藤川 真一えふしん | BASE株式会社 内容的には、普通の会社員の生き方の話であって、改めてよくよく考えると「CTOから」と書いてあるのだから、もしかして期待されてることが違うんじゃないかと思ったので、もう少し技術寄りのバージョンをここに書いてみます。 お題は「ソフトウエアエンジニアは時間外に勉強をすべきか？」ということに触れてみたいと思います。 エンジニア採用系の記事が増えたことで、少し過激な表現として「ソフトウエアエンジニアは、時間外に勉強すべき！」という言説がネットで出回っていて、これについて賛否両論あるようなので、議論してみたいと思います。先に書いておくと、この文章、長くなってしまいました。 そして、この記事の結論を先に書くと「他人を出し抜く機会が時間外にこそある」