成長期のベンチャーにおける採用の失敗 – Isoparametric – Medium
成長期のベンチャーにおける採用の失敗2011年2月「任侠道」などのゲームがヒットし、売上が伴ってきたとき、それは終わらないマラソンが始まったことを意味していた。 そして、以後横展開した「道」シリーズがヒットを飛ばしていくために、様々な問題が噴出し始める時期である。 プロジェクトを広げようにも、どのプロジェクトも人が足らない。 加えてエンジニアだけではない「初期の頃のメンバー」が退職を重ねていく時期でもあった。 バックオフィスも開発も、見よう見まねでやっていたところに経験者が入ってきて、ポジションが入れ替わるようなことが頻繁に起きていた。 「自分の好きだったgumiは死んだ」というような事を言って辞めていく人たちもいた。 開発現場でも、のんびりと仲良く売れないゲームを運営していれば良い時代は終わってしまったのである。 「任侠道」が明確なヒットを飛ばしている傍らで、のびのび結果のでないプロジェ
知らないうちにどんどん人が増えていく会社 – Isoparametric – Medium
知らないうちにどんどん人が増えていく会社gumiに入って一ヶ月か二ヶ月が過ぎたころ、チームに所属して様子を見てみると、gumiには一ヶ月の間にかなりの多くの人（5人とか10人とか）が入ってくるのに気がつかされた。 幾つかのチームが組成され、それぞれがゲームを開発、運用しており、解析班などと呼ばれるようなチームもあった。 （そして、それは機能していなかった。売れてないのだから、解析する内容などあるはずもない） そして、入ってきたプログラマは時折適当にプロジェクトにアサインされたりした。 私のチームにも新しいプログラマがやってきたわけだが、そのことを切っ掛けに、うやらプログラムがまともに組めない（仕事を任せられない）人が入ってきていることに気がつかされることになる。 困ったので当時のCTOにどういう基準で人を採っているのか訊いてみた。 特に基準はない、みんな頑張ればできる、とのことだったので、
株式会社gumiを退職して2年が経った – Isoparametric – Medium
株式会社gumiを退職して2年が経った株式会社gumiを辞めてから2年が経った。 なので、あの頃のことを少しずつ書ける範囲で書いていくとみんなの役に立つんじゃないかなということで、書き始めてみる。 私がgumiに入社したのは社員数40人くらいのときで、正直よく考えてgumiに入った訳ではない。 「ソーシャルアプリ開発現場の今」というイベントで見かけた國光さんが夢を語るのが面白そうだったり、Pythonを使っていることが面白そうだったり、gumiというSNSは800万人もユーザーがいるというのを見て面白そうだと思ったからだ。 800万人もユーザーがいるなら、面白いことができるだろうという漠然とした期待もあった。 しかし、登録数とDAUは決して一致しないという悲しい現実がそこになあるのだった。 そういえば、面接の時に國光さんがアバター（映画）がメチャ凄いという話をしていたのを今でも憶えている。
ユーザーインターフェイスにおける明示的アクション／暗黙的アクションの違いと設計の考え方 – usagimaru – Medium
明示的アクション／暗黙的アクションについてずっと言語化できていなかったので、このたび記事にまとめてみました。馴染みのあるMac OSそしてiOSを例に、画面上のオブジェクトを操作するための二つのパラダイムについて説明します。 2005年頃の Apple Human Interface Guidelines (HIG) を開いてみると、そこには「Explicit and Implied Actions – 明示的および暗黙的アクション」と呼ばれるデザイン原則が示されています。Mac OSのユーザーインターフェイスでは、明示的アクションと暗黙的アクション、この二種類の操作体系が同時に提示され、ユーザーは好きな方法を選択することができるようになっています。 明示的アクション明示的アクションとは、すなわち画面上に明示された手段を選択してコマンドを実行するというものです。Macを例にすると、ユーザー
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
「チームワークが苦手」という人が本当に苦手なもの。
この記事を読んでふと思ったんだけど「チームワークが苦手」「団体行動が苦手」という人って、チームプレーさせてみると、実はそんなにチームプレーが下手でもないし、「チームワークが大事」って言ってる人よりむしろチームワークが上手い人が多い、ってこと。 チームワークが苦手、ストレスだって言ってる人が本当に苦手なのは、気持ちが悪い馴れ合いや、意味のない社内政治、皆の意見を尊重しているように見せかけて、その実、チーム内の「政治屋」が集めたマジョリティだけで、せっかくのいいアウトプットを殺す「エセ民主主義」だと思う。 本当に大事なのは、チームの目的をしっかり理解した上で、お互いが妥協なく、素晴らしいものをつくるために発揮するプロフェッショナリズムと、その効果的な「合力」だ。 ところが、「馴れ合い」や「エセ民主主義」は一見「チームワークを向上させるもの」のように見えるだけで（文字面だけ聞くと、そのことを否定
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
日報共有アプリケーションをOSSとして開発している話
日報一覧画面最近、プライベートな時間をつかってRepostというオープンソースの日報共有アプリケーションを開発しています。 投稿した日報に対して、コメントや絵文字でリアクションすることでチームでのコミュニケーションを活性化させることを目的としています。日報版Slackのようなイメージです。 まだ開発着手から1ヶ月ということもあり、バージョン0.0.1でまともに稼働できる段階ではないですが、開発のモチベーションを高めるためにも記事を書いてみました。 技術スタック チャンネル作成画面RepostはフロントエンドにReduxを採用し、SPAとして構築しています。APIサーバとしてのバックエンドはRuby on Railsで開発しています。また、エディタ部分はDraft.jsを用いてMarkdownエディタを実装しているところです。 Draft.jsについては、過去にとあるプロダクトに採用した経験
なぜ優秀なエンジニアを低待遇で採用してはいけないか
この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので本当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな
とにかく雑に作れ
学生たちを見ていると、きちんと議論して、きちんと設計して、きちんと何かを作ろうとするみたいです。ときには副作用を考慮して、やっぱり作るのやめようかという話になり、再び議論に戻ることもあります。 ああ、もったいない、もったいない。私は適当な人間なので「なんてマジメなんだ、とりあえず何か作ればいいのに」と思います。デザイン思考ではそのことを「クイック＆ダーティプロトタイプ」と呼んだりしますが、それだとなんだかカッコよすぎるので、私は「雑に作れ」と言ってます。 でも、言葉だけでうまく伝わるはずもなく、「どうすれば雑に作れるのか？」と再び議論を始めたりするので、なかなか難しいところです。 それでも「締め切り」というのは効果的なもので、次回までに何かを発表しなければいけないとなると、「議論してばかりじゃ話が進まない！」となり、ある種の覚悟を決めて雑に作ってくれるようになります。 私が印象的だったのは
フロー状態という幸せを得るために働く
仕事や勉強をしていると集中して没頭する瞬間がある。それを「フロー状態」と呼ぶらしい。そんなフロー状態について聞いた話から着想を得て。 フロー状態になると、周りから雑音が消えて、その対象に集中し、高い生産性を発揮することができる。アイデアなら次から次に湧いてくる、プログラミングなら次々とコードが進む。 そんな状態は、脳も喜んでいるらしい。そのフロー状態になっていること自体が、幸せな状態なのだと言える。詳しくは知らないけれど、おそらく脳内物質が分泌されているのだろう。 もし、仕事をしていてフロー状態になれるのだとしたら。フロー状態になって幸せになれるのだとしたら。それはもはや、仕事をすること自体が幸せになる手段だと言えないだろうか。仕事は手段ではなく目的なのか。
「チームは仲間集めからはじめよ」
いきなり人集めて「我々はチームです」ってやるからうまくいかないんじゃないの？という話を考えてみた。さっき風呂入ってる時に思いついたので書いてみるけど、最初から人を集めてチームを作るっていうのがそもそも不自然なのではないか。 本来は、中心となる人物が、何かを成し遂げたくて、そのために必要な仲間探しからはじめないと行けない。そして、仲間を集めるのは、一気に増やすのではなく、ゲームや漫画のように、一人づつ口説いていかないといけない。 つまり、チームという人の組織体自体も、いきなりではなく徐々形成されるべきであり、いきなり集まってってやるから話が複雑になるということなのではないか。 人を集めてから「僕らはこれをやるために集まりました。じゃぁチームを作りましょう」とやるから「集まった中で、バスに乗る人・降りる人」とか「キックオフで目的の共有」とか余計なことが必要になる。想いのある人が、一人づつ、夢を
Swift snippet #9 — then
You can find its Gist here! Whenever we have to safely unwrap an optional value, we generally have 2 options — if letguard letBoth solutions are great & there’s nothing wrong with them 👍 But I feel safely unwrapping could get little better 🤔 Thus I made an extension on Optional & created a function then which executes a closure having its unwrapped value only if some exists! It could be used som
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
WEBエンジニアがプロダクト開発を通じて学んだチームビルディングに関する5つのTIPS
インタ ーネットの世紀のプロダクト ・マネジャーの役割は 、最高のプロダクトの設計、エンジニアリング、開発を担う人々とともに働くことだ — 『How Google Works』 本記事は Livesenseその3 Advent Calendar 2016 の24日目の記事です。いきなり格好つけた言葉から入ってしまいましたが、クリスマスイブなので。同様に以下ポエミーかつエモ目の記事となります、ご容赦ください。 私は転職会議というWEBサービスの開発に携わっており、2年ほど前から開発チーム（エンジニア/デザイナ/ディレクタの混成チーム）のマネージャーとしてプロダクトオーナー（PLは持たない）兼エンジニアマネージャーのような仕事をしてきました（最近では二足のワラジに限界を感じてプロダクトマネージメントのみに集中していますが）。 本記事では、プロダクト開発に携わってきた中で、グロースに繋がったと思
スター不在のWebサービスデザイナー、その現状と対策
Webサービス系インハウスデザイナーの人材不足が深刻だ。なんと言っても母数が絶対的に少ない。こりゃあ大変だ、という事で急に書き始めました。 発端は何気ない会話から始まった。 同僚「デザイナーでTwitterのフォロワー数の多い人って誰ですか？」 僕「デザイナーでフォロワー数が多い人ってそんなにいないんだよね〜」 （ちなみに僕は恐ろしく少ないから誰でも良いのでフォローして頂きたい。Twitter：hiro2969） ちなみに上の会話で言っている「デザイナー」というのは、「Webサービス系のインハウスデザイナー」の事になります。 「グラフィックデザイナー」「広告系Webデザイナー」「アートディレクター」などは含みません。 実際に同僚とTwitterを見ながら調査してみた。 結果、フォロワー1,000人もいれば多い方で、Webサービス系インハウスデザイナーでのトップクラスはフォロワー3,000人
エンジニアからプロダクトマネージャーになるときにやること – EM.PM – Medium
今日は自分がエンジニアからプロダクトマネージャーと言う役割を担うことになったときの話をします。FiNC Developer Advent Calendar 2016 11日目の記事です。 最近日本のソフトウェア界隈でもよく聞くようになったPM=Product Managerという職種ですが、エンジニアから実際どうやってジョブチェンジしていくの？って話はあまり聞いたことがないので書いてみます。 「プロダクトマネージャー(PM)とは」を知る事前準備プロダクトマネージャーとしてやることやってみてわかったこと1.「プロダクトマネージャーとは」を知るまずは王道に、その職種の役割を理解しましょう。 最初に言っておくと、この定義は実際の現場によってある程度かわることが多いようです。ですがまずはメジャーなPMの役割を知っておきましょう。 結論自分の解釈では、プロダクトマネージャーは「ユーザーに製品の価値を
UI談義のすすめ
https://dribbble.com/shots/1679085-Mobile-UI-Blueprint-freebie私の職場ではUIについてのマニアックな談義が行われることがあります。アプリやwebだとかのデザイン会社なので周囲にはUIやUXのプロフェッショナルが集まっていて、『UI談義』の文化が根付いています。 UIを解剖するためのUI談義UI談義とは、UIオタクで集まってUIのことをひたすら考察し合うだけの集まりです。ここには職種問わず誰でも参加が可能で、UIデザイナーはもちろん、iOSデベロッパー、Androidデベロッパー、PM、マネージャーなどなど、あらゆるタイプの人が集まります。 UI談義のテーマは突如設定されます。普段利用しているアプリのちょっとしたインタラクションが気になったらそこでUI談義が始まります。iOSのアップデートでApple純正アプリのUIが変わったタイ
Swiftポエム — null安全編
Swiftのおかげで人生豊かになったと言っても過言では無いので、ポエムを書きます。 Objective-Cという色々突っ込みどころの多い言語を使いこなさないとiOSネイティブアプリを書けない辛い時代でした。 しかし、そんな中でもiOSは… ミスったところは大体コンパイルエラーにしてくれてます。 Scalaなどと同様、関数型言語の性質も取り入れた書き方も出来ますし、かといっていわゆる関数型言語みたいな堅い縛りもなく、共存しやすいです。 一時期Haskell入門してモナドなど勉強して挫折気味でしたが、Swiftでそれ系の記事読んだり触れたりして理解深まりました。 SwiftでOptionalというnull安全のための言語仕様があることはもちろん嬉しいですが、個人的にはそれはそこまで重要では無いと思っていて、「型が強い」ことの一要素程度に思っています。 静的言語 vs 動的言語僕は静的言語大好き
デザイン・プロセスの話はもうやめよう
photo cred: Enric Martinez on Flickrデザインについて考える前に、料理についての話をしましょう。初めて料理をした時、皆さんはレシピ通りに作ったのかもしれませんね。材料はどれくらい必要でどう調理すれば良いかレシピを参考にしたことでしょう。 料理が上手くなるにつれ、材料についてはざっくり確認するだけで済ませ、調味料も目分量で大体分かるようになります。オーブンの予熱についても細かく温度を調べなくとも経験をもとに設定できるようになるでしょう。かなり上達してくると、手元にたまたまあるものを上手く利用したり、興味を引く初めての材料を使ってみたり、食事を一緒に楽しむ仲間の好みを考えたり、旬の野菜を使ってみたりと様々に試して新しいレシピを考え出すはずです。 レシピに書かれている順序やプロセスは新しい料理を始めるきっかけや手ほどきにはなるかもしれません。しかし、あなたを本物
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
