自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話
元後輩?から「どんな人を創業メンバーに選ぶべきですか?」質問をされたので、自分なりの回答をした。
正直今の会社の創業メンバーは、前職同期である社長の素晴らしすぎる人脈もあって、奇跡的な能力のゴールデンバランスと性格的相性の良さを兼ね備えた6人が手を上げ起業している。
なので、このこと自体は全然参考にならないよという前置きをおいたあとに、自分なりに思ったことを述べた。
コストを払わない人と一緒にやるとチームが自然解散する
起業前によくあったのは、エンジニア1人+企画2人とかのパターン。
大抵が本職がある状態でのプライベートプロジェクトで、土日のどちらかで1, 2週に一回集まって企画を考えてプロダクトに落として行くということをやっていた。
で、よくあるのが企画中はみんなでかなり盛り上がって笑い合って、じゃあこれで行こう!絶対いける!みたいになるんだけど、はいじゃあ実装開始ってなるとエンジニアが1人でモクモクやってるパターン。
一緒にやるメンバーが企画(そしてしゃべること)しかできない人だと、実装中はエンジニア一人だけで他のメンバーは何もやってない状態になる。
この状態がまだ2週間(集まりで言うと2回、工数で言うと2人日以下)とかだけなら、最低限自分も向こうも我慢できるんだけど、実装が難しいやつだったり、エンジニアも初めての技術を使っちゃってる場合は、2日動いたくらいじゃ全然プロトもできなくて、そうこうしていると期間としては1ヶ月くらい(作業は4,5人日以下)経っちゃって、そのうち企画だけしかできないメンバーの心が離れていく。
リリース当日に自分だけ作業していて、他の二人は新しく買ったクロスバイクで横浜までサイクリングに行っているって謎状態とか昔あった。
こんな状態になるとエンジニアの方は「なんで俺だけがんばってるんだよ、できないことがあってもそばにいるくらいしろよ」ってなって、製品やメンバーに対する愛着を失う。
「みんなが自分と同じだけ製品にコストを払ってくれる人じゃなかったら、多分今起業してないよ」
こういう経験を過去何回か繰り返してるうちに、逆に成功パターンもあって、どういうときに成功するかというと「チームのエンジニア・デザイナーの比率が過半数以上」の状態。
もしくは企画だけやってる人も、雑務や力仕事やユーザーインタビューなどを自分の時間を割いて、やってくれている状態。
つまり手を動かす人が多い、もしくはそういう人たちだけで構成されていると、割りと最後まで不満も出ずにプロダクトの完成まで行ったりする。
違いはなにかなぁって思ったんだけど、結局はタイトルにもある通り、
「製品に対して自分と同じくらい他の人もコストを払っていることがわかる状態にある」
ってことかなと。
週一の集まりとかも、自分だけが進捗を披露するみたいになると、エンジニアはモチベーション沸かないし、他の人もできてないときに白けてしまう。
でも集まれば必ず各々進捗があって、ああでもない、こうでもないってなっていると、自分以外の人も頑張っていることもわかるし、自分がやったことの還元もあるし、次回も自分がやらないわけにはいかない、頑張ろうみたいな心理になる。
チームの人数も重要
あと人数も重要で2, 3人だと、自分が休んでも影響少ないしいいかってなる。
でも例えば8人集まる会なら、自分がいないことで迷惑をかける人が7人いることになるので、流石にそれは申し訳ないってなってちゃんと遅刻しないで出席する気持ちになる。
(※もちろん仕事ならアポの相手が1人だろうと遅刻やすっぽかすなど論外ですが、プライベートプロジェクトの場合はこの気持がぐっと下がるのが常かなと思います)
コスト→愛着
こんな感じで、何週間かやっていると、全員がそれなりのコストを払い始めるので、他人に迷惑をかけたくないって気持ちもそうですが、自分がコストをかけたプロダクトに愛着が生まれてくるようになります。
この愛着が生まれてくると、リリース当日に集まらないとかありえない状況ができてくるわけでです。しかも能動的に。
人間はコストをかけたものの方が愛着を感じるものです。イケア効果ってやつですね。
まとめ
なので僕が言いたいのは、どんなに能力が高くて性格の相性が良くても、多分全員がコストを払って、製品に愛着を持つようになってないと、解散の危機があるということです。
しかも重要なのはコストを払わせることなので、最初めぐりあったときに性格的に相性が合うかわからなくても、向こうもエンジニアだったり、企画でもユーザーインタビューに奔走しているとかであれば、ある程度チームとしては続いていくことになるとは思います。
もちろん反例は認めるけど、最初に考えるべきチーム構成としては全員がコストを払う構造があることは必要条件だと思うんですよね。
☆株式会社フォトシンスでは、一緒に愛着を持ってプロダクト開発をしてくれるエンジニアを募集中です☆
ロングセッションでの効率的な資料の作り方
先日YAPCで50分の発表を行って来ました。
Twitterで「何十分もの発表は資料をつくるのが大変だから」という理由で、応募しなかったり落選してよかったと言っている人を過去も含めて何人か見かけたので、今回は自分が50分の資料をつくるためにやったことを話します。
スライドツールを使う前にアナログな方法で仮設計する
ここで仮設計とは、
- トーク時の風景を頭でイメージする
- シャワーを浴びているときや通勤時歩いているときなどに、何を言いたいか頭の中で考える
- 試しに何もスライドがない状態で、一体何分間喋れるか録音しながら話してみる
といったことです。
特に最後の「録音しながら話してみる」は、効果絶大で日々寝る前にとりあえず20〜40分くらい最初はだらだら、思考が固まるごとに、より正確に喋れるように訓練を重ねました。
スライドのない段階でトークを録音する効能は、
- 実は50分喋れないんじゃないかという不安をなくす
- 頭の中にあることを強制的にアウトプットする
- あまり順番は気にしないが、必要そうな分量については吐き出し切ることに注力する
- 人に話すようにしゃべることで、半分は当日のしゃべり方の練習にもなる
ここでもし半分の25分も喋れなかったら、「なんで俺応募したんだろう」ってことになるので、自信がない場合は本番一ヶ月以上前の段階で録音テストを行い、内容が足りなければ、1日数時間余分に時間を取ってスライドの内容をつくって行った方が良いでしょう。
自分は割りと”無意識時に勝手に頭が整理してくれる機能”の存在を信じているのですが、実際「考える」のあとに「全然関係ないことをしてインターバルをおく」は重要で、その間に発表の設計イメージが固まっていきました。
本設計は紙とペンだけで
ここでもまだスライドツールは使いません。
これが異常に捗ったのですが、上の写真のようにノートにスライドの枠を書いて、仮設計しながら頭の中で形成されていたイメージをどんどん書き出していきます。
発表はシリアルなものなので、スライドから次のスライドへの変遷時に言う繋ぎの言葉も考えながら書き出していきました。
これを最後まで出し切って、精読して問題がなさそうなら本設計終了です。
最初からスライドツールを使わない理由は、思考が一度詰まってしまったときに、どこが悪いかが俯瞰して見えなくなったり、時間を掛けてスライドをつくってしまったせいで、変更に対する心理的なコストが上がってしまうからです。
紙とペンでやってるだけなら、見渡すのも直すのも簡単です。
スライドを実装する
僕はMarkdownで書いたら自動でスライドにしてくれるツールを自分でつくって使っていたので、本設計の内容をMarkdownに書き出していきました。
前回のブログにも書いたのですが、スライドツールはTalkie.jsを使い、Markdown2Slideなツールは自分でスクリプトを書きました。
これは一旦は単純作業ですが、途中々々で図が出てきたときは、MacのKeynoteで作成して、作成した図をコピーしたら、ToyViewerを起動して⌘+Shift+Vで図を都度画像化して貼っつけて行きました。
実はKeynoteは今回初めて使ったのですが、パワポよりも使える図形の数が少ないものの、図の位置の調整が神がかっていて、スムーズに作成できました。
あとは発表練習をしながら改善していく
ここから真の発表練習を開始です。事前に録音を何度かやっていたならスムーズに行くはずです。やってないで前日とか迎えると、結構このタイミングではまずいです。
しゃべりながら変な部分がないか確認していき修正していきます。
合計として資料の精度だけでの直し3回、発表練習は5回しました。 あと絶対に前日に成功パターンの発表練習を終わらせておき、練習と発表時間との間に睡眠を挟んでから本番に望みましょう。
寝ている間に整理されるはずです。
僕の練習時の発表時間は、
20分(スライドを読み上げただけ)→60分(スライドちょっと増やして話し方も修正)→55分(微調整)までが前日
当日朝6時に置きて、追加でスライドの精読と何度か練習をして50分ほどに調整
本番もちょうど50分ちょいで発表を追えることができました。
まとめ
- 何もない状態から発表内容を録音するのは仮設計としゃべりの練習ができて一石二鳥
- スライドツールを最初に触るのではなく、紙とペンで本設計する
- エンジニアなら使い慣れたMarkdownで資料をつくるのもあり
- 発表練習は入念に
Enjoy Presentation!
YAPC::Asia 2015で「Web由来の組み込みエンジニア」について発表してきました!
YAPC::Asia 2015 一日目の11:10より、東京ビックサイトにて、「Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜」というタイトルで登壇して来ました。
最後のYAPCということもあり、発表の選考に漏れてもいいように「個人スポンサー」も申し込むという万全の体制で待ち構えていましたが、運良く採択されたため、ピンクとオレンジのダブルストラップ体制という形でYAPCに発表に望めました。
Talkの概要
発表のスライドはこちらになります。
Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜
なぜ発表したか?
最後のYAPCなので、絶対に発表しておきたかったというのはあります。また去年のYAPCで発表する内容やリソースが自分になくて歯がゆい経験をしたというのもあります。
ですが、一番は今の日本のベンチャーにおいてこんなにも「IoT」している企業が弊社以外にまだまだ少なく、またこういう場所で発表を行う企業もまだまだないだろうということです。「IoT」をやっている企業として「IoT」を実際にやって製品開発をしてみての経験がとても貴重なものであり、それを外に出したいと思いました。
今回の発表は個人的にはすごい「エモい」発表になっていると思っています。本当はもっとソースやデモやアーキテクチャの構造や開発ノウハウなのどを公開したかったですが、それには50分はあまりにも短すぎました。
今後たくさんブログを書く予定ですので、それによって徐々に公開していきたいと思います。
もし聞きたい話があればリクエストください。
スライドの作成方法について
スライドの作成には、id:ahomu さんのTalkie.jsというのを使わせていただきました。
僕は基本的にはREADME.mdでざっと草案をつくったあとに、それをslideに変換することが多いので、今回もmarkdown2talkiejsな簡単なコードを書いてスライドを作成していました。
こんな感じの書捨てスクリプトですが、これで十分満足することができます。guard + livereloadも追加していたので、リアルタイムに反映しながら作成していきました。
#!/usr/bin/env ruby # coding : utf-8 require 'erb' require 'pry' html = File.read('README.md') html.gsub!(/^(#|##|###) ([^\n]+?)\n<!-- image (.+?) -->$/m) { "</template>\n<template layout=\"cover\" invert type=\"text/x-markdown\" backface=\"#{$3}\" backface-filter=\"blur(0px) brightness(.3)\">\n#{$1} #{$2}\n"} html.gsub!(/\n\n(#|##|###) ([^\n]+?)$/m) { "</template>\n<template layout=\"bullets\" type=\"text/x-markdown\">\n#{$1} #{$2}\n"} html.sub!(/<\/template>/, "") html += "</template>" html = ERB.new(File.read('template.html.erb')).result binding open("index.html", "w") {|f| f.write html}
スライドの全体のソースはここを見るとわかります。
README.mdを変換するメリットとして、githubなどで見た時に構造化された文章として出力されることです。
最後に
一番最初の発表ということで半分あきらめてますが、ベストスピーカー賞を狙っているので、まだ投票していない方は投票の方をお願いします!!!
この前書いたgitブランチ運用方針
- 勝手に
git push [--force|-f]
をした奴は殺す- 過去は変わらないのだ!
- タイムパラドックスだ!次元の歪みに吸い込まれるぞ!
- 場合によってはrebaseも許されない!
- 危険性をわかってない人は一読のこと → http://cpplover.blogspot.jp/2013/11/jenkinsgit-push-force.html
2015年にもなってObjective-Cコーディング規約
起業してほぼ一人でコードを書いていたのですが、そろそろ人が増える可能性もあるのでコーディング規約にしたがっておこうかと思います。
ベース
安定のクックパッドさん
https://github.com/cookpad/styleguide
触発フロー
まずモダンな記法を頭に入れる
http://clang.llvm.org/docs/ObjectiveCLiterals.html
Appleのお膝元で膝枕した後に
https://developer.apple.com/jp/documentation/CodingGuidelines.pdf
githubの技を見たあと
https://github.com/github/objective-c-style-guide
最後にNYTimesに触発されて
http://raimon49.github.io/2015/03/21/review-nytimes-objective-c-style-guide.html
クックパッドに戻る
めんどくさい人へ
ちなみにwantedlyはなんか上記が混ざっている
https://github.com/wantedly/objective-c-style-guide
Swift
個人的にはiOS9が出る前に完全にSwiftに移行させたいです。
2014年を振り返りたい
振り返りたい。
うん、振り返りたかった。
でも明日も仕事なんだ。
起業したもんね。
追記
やっぱりちゃんと書こうと思います。
自分にとってやはり2014年は一番記憶に残る一年でした。
1月、「あ、転職しよ」
あ、そろそろ転職しないとな、って本気で思い始めたのが2014年の最初の方でした(正確には2013年末かな)。
自分なりにある程度力がついて来たなという実感と、今のサイクルを回すだけで本当にいいのか?という葛藤が走っていた時期でもあります。
新卒というものは人にもよりますが、「理想と現実のギャップ」に良くも悪くも悩むものです。
それが、1年、2年と立ちだんだんと昇華されてきて、今の状況にあるのは全部自分の責任なんだと思い、無駄口言わずに自分のプラスになることをどんどん吸収しようとしていました。
それまでは、本を読む時間やノートに文章をまとめることに時間を割くことが多かったのですが、だんだんとそれもなくなり、コードとちゃんと向き合うこと、プロダクトをちゃんとつくるために時間を使うようになりました。
インプット<アウトプット
今の新卒みたいに最初からある程度プログラムが書けたわけではない自分は、ゆっくりゆっくりと低い角度で、でも確実に山をのぼっていくしかないと思っていました。
これは今もそうですね。
2月、会社の同期とつくっていたアプリがちょっとバズる
Music Hack Day Tokyo 2014 | Peatix
Music Hackathonというイベントで、ちょっと色々アプリを取り上げてもらい、大きな大きな音楽会社の人達からも声をかけられ舞い上がっていた時期がここです。
入社当時から同期たちとは色々コンテストに応募したり、アプリをつくろうとしたりしてきたのですが、全然報われない状態が続きながらもやめずに続けていました。
それが3年経ってようやくちょっと認められたのかなと思った瞬間でした。
つくったのはこれ。今動くかは不明です(でぷりけーとな機能を使っていたはず)。コアのおもしろい部分は僕の担当だったので、僕の名前で出さなかったのはちょっとこころ残りですが、まあやる気の素は分散させた方がいいかなということで、これはこれで。
3月、前職の新規事業開発メンバーとなる
会社で大きな改革があって、その流れでエンジニア主導の社内スタートアップを始める感じになり、自分もそのメンバーに選ばれました。
福岡にいたCTOから僕の携帯に直接電話があって「kazuphくんって色々体験してみたい人でしょ?数ヶ月でもいいので新規事業の立ち上げに参加してみない?」みたいな感じに言われたので、その場で「そういう流れに僕が参加しないのはちょっとないな、って思っていたので是非参加させてください」みたいな感じに返答したのを覚えています。
ここでプロダクトの最初の0→1(ゼロイチ)の部分から少しですがテレアポ、営業、そしてもちろんWebサービス開発などひと通り体験しました。
この時期になぜかスクレイピングにハマってしまって、色々スクレイピ倒したのですが、それは良い思い出。
僕的には簡単なサイトならruby+mechanize、JS使ってるサイトならruby+Capybaraかなって思っていたのですが、最近ではnodeでスクレイピングしてますね。
今後もスクレイピングはnodeでいいかなって思ってます。rubyはビルドがめんどくさい。
参考:
【総計5万はてブ!】QiitaのAdvent Calendarのはてブ数をNode.jsで集計してRactive.jsで表示する - Qiita
あ、あとリーンアナリティクスという本をエンジニア3人で輪講するということもやってました。
英語の勉強になるかなって思いましたが、僕の英語力は他の二人に比べてクソなままでした。。。
Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)
- 作者: Alistair Croll,Benjamin Yoskovitz
- 出版社/メーカー: O'Reilly Media
- 発売日: 2013/03/08
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
なんでやぁ、、、
4月、今の起業のきっかけとなるプロジェクトにジョインする
WeTunesは今の会社の社長(というか同期)と一緒にやっていたのですが、社長が別に並行でやっていたプロジェクトも他にありまして、それが今の起業のネタとなるものでした。
WeTunesでBluetooth(Classic)は使っていて、これでもBluetoothを使っているしアプリとサーバーサイドできる人いないから一緒にやらない?みたいな感じでジョインしたと思います。
5月、クソアプリをリリースするも敗北
実際には↑にジョインした後のしばらく平行して「いわゆるクソアプリ」開発を1ヶ月くらいやっていたのですが、それは案の定くそな状態で終焉して、めでたく本起業につながるプロジェクトで本腰を入れるようになりました。
クソアプリの詳細は言えませんが、golangでスクレイピングしたサイトをgolangでHTMLつくって、iOSのガワアプリで表示するみたいなクソさでした。
あ、僕Golangでもスクレイピングしてたんですね、ウケるwwwww
6月、「会社をやめるなら年内」
確かこの時期に「会社をやめるなら年内」って言葉にしていました。
まさかそれが本当になるとは、、、。
7月、週末プロジェクトが日経新聞に乗る
めっちゃテンションあがった
8月、勢いでほぼ会社をやめる
会社をほぼやめて、フルコミット開始。
9月、書類上で正式に起業、IoTベンチャーを創立
がんばろうと思った。
10月、退職
ちょっと御厚意で長居してしまったのですが、10月に完全に退職しました。
11月、12月、組込みエンジニアとなり晴れて全レイヤーのプログラム開発を経験
元々サーバーサイド、スマフォアプリ(iOS/Android)とだんだんと領域を広げて来たのですが、ついに組込みエンジニアデビューしました。
正確には9月くらいからやっていたかな?
今、頑張ってます。
終わりに
後半雑ですいません。
今年もたくさんの方々に御世話になりました。 来年もがんばります。よろしくお願いします。
日本のエンジニア系Podcast四天王
- rebuid.fm
Rebuild - Podcast by Tatsuhiko Miyagawa
最新の技術ネタ、リモートワーク、組織論、マネージメント論などエモい系の話からゲームネタまで。司会のmiyagawaさんは日本の超有名ハッカーなので、その辺のレイヤーのエンジニアの方々がゲストに来るので、普段の職場では聞けないような話が凝縮されていて平エンジニアの自分としては、時間あたりの「ためになる率」がかなり高い。
naoyaさんは準レギュラー。
個人的には燃料を投下してくれるKennさんの回が増えてくれることを願っている。
なお会話あたりのEmacs率も、他のPodcastにくらべて格段に高い。
- backspace.fm
Latest Episodes – backspace.fm
ザ・ガジェット系Podcast、だと思っているとPinterestなどのウェブサービスを詳しく紹介する回もあったりと幅が広い。Web系の人なら基本的に楽しめるはず。
また個人的にはIoT製品を開発しているので、回の中で自然に登場する日を夢見ている。
- mozaic.fm
Web界隈のマニアック系のネタが多い。WebComponents, HTTP2, REST, VirtualDOM, Node/JS系。ゲスト選びも秀逸。 聞き流せる感じじゃないので、勉強のために聴くという感じ。なんども聴いて深める感じ。
- admins.bar
ビールを飲みながら話しているので気軽に?聞ける。
クックパッドのmirakuiさん界隈の人たちの話が聞ける感じ。
「あれの○○の部分どうやってる?」「あれは○○して△△してます」みたいな自分も引っかかったことがあれば刺さる系の話も多い。
直近の回はISUCON運営メンバーの苦労話が聞けるので、参加が聴くと面白いかもですね。
おわりに
勝手に四天王にしてしまいましたが、他にもおもしろいものは多いと思うので、もしあったら教えてください。