ピクトリーの開発で大切にしていること
TechCrunch さんに紹介されました
ありがたいことに弊社のアプリ「ピクトリー」が好調です!
先日、TechCrunch さんでも、ピクトリーについて取り上げていただきましたので、もし興味があればご覧ください
匿名画像投稿サイトから画像SNSにピボットした「Pictory」、中高生人気を集めて月間1億PVを突破 | TechCrunch Japan
もっともっとスピード感が欲しい!
今までは、 id:mizzusano と二人で開発してきたのですが
もっともっとスピード感欲しい!
人材募集しています!
というわけで、このピクトリーをより発展させていくために採用を始めることにいたしました!
Wantedly のページも作ってみたので、もし良かったら見てみてください
毎日15時30分には退社したいエンジニア募集 - カクテル株式会社の求人 - Wantedly
ぜひぜひ!よろしくお願いします!
弊社で大切にしていることを紹介します
せっかくこういう機会なので、今日はちょっと僕たちが働き方として大切にしていることを紹介してみたいと思います
働き方として、特に大切にしていることは
- 分業しない
- 不確実なことを先にやる
の 2 点です
1. 分業しない
弊社では、ディレクター、デザイナー、プログラマーなど人を業種で分けないようにしています
全員が全部やる!という感じでやってます
分業すると「空き時間」が生まれてしまう
分業しない理由として一番大きいのは「仕事の不均衡」です
業種によって仕事量って一定じゃないんですよね><
例えば、弊社の最近の仕事量はだいたい以下のようになってます
これをもし業種で分けるとすると
こんな感じでしょうか
みなさんの会社ではどうでしょうか?業種ごとの仕事量って結構偏ってませんか?
また、仕事量は時期(開発フェーズ)によってもどんどん変化しますよね?
「あなたはデザイナー、僕はプログラマー」のように担当を決めてしまうと、どうしても誰かに「空き時間」が生まれてしまうんですよね><
この時間を単純になくすことができるだけでも、分業をやめるメリットがあると思っています
「空き時間」を「ちょい足し」的な仕事で埋めようとするのは更にダメ
分業してる状態で「空き時間」が出来ると、その時間を有効活用しようと「あ、ここちょっと改善しとこー♪」みたいな感じでちょい足し的な感じで仕事してしまいませんか?
「空き時間」そのものより、そういう「ちょい足し仕事」が本当に悪習だなあと思っていたりします
「ちょい足し仕事」は結果として
- 別の人の仕事が増えて、短期的にリリースが遅れる
- 長期的な開発スピードにも悪影響が出る
というようなことが多いような気がします><
「ちょい足し仕事」は、別の人の仕事を増やす
多くの仕事は、単純にその仕事だけで終わらないことが多いです
やっぱり、プロダクトの開発作業って複雑に絡み合っていますから、一人の作業のみで完了する仕事ってあまりないんですよね><
ちょっとした仕事のつもりで初めても、気が付くと他の人を巻き込んだりしていたりします
暇だったので良かれと思ってやった仕事が、別の人の仕事増やしちゃうってことって、結構ありませんか?
「ちょい足し仕事」は、長期的にも悪影響
基本的にどんな仕事でも「プロダクトの複雑さ」を等しく増大させます
プロダクトの開発フェーズが進むにつれて、プロダクトは複雑さを増し、機能追加にかかる時間はどんどん増加していきます
つまり、どんなプロダクトでも徐々に開発スピードが遅くなっていく運命にあると思っています
ですので、我々は、常に一番重要な仕事だけを行うべきで、要るか要らないか分からない「ちょい足し仕事」のような仕事は一切やらないほうがいいと思います
参考までに、ピクトリーの未消化タスク数の推移を紹介します
時間を経るごとにプロダクトがより高機能になり、作り込みにかかる時間が増えていることがわかります
Android 版の最初のバージョンには、投稿する画面と新着を表示するタイムラインしかなく、コメントやお気に入り機能もないようなものだったのを覚えています(当然ユーザーページやフォローなんてものもなかった)
やっぱり小さな会社ですから、「最低限の機能」で「素早くリリース」というのを心がけていきたいものですよね(^^;
専門外のことでも意外とやれる
分業をやめると当然、専門外のことをやらなければいけない問題があります
ただ、
- 「ちょい足し仕事」をやるよりも、専門外でも必要な仕事を頑張ったほうが良い
- 後で得意な人がレビューをすればいいんじゃない?
- むしろ勉強になるので、苦手なことこそガンガンやったほうがいいかも
などの理由により、割りとなんとかなってます
弊社でも当初は、 id:amachang が「プログラマー」で id:mizzusano が「デザイナー+企画者」と担当を分けていて、お互いの専門外の仕事は避けていました。ただ、その壁を実際に取っ払ってみた後、「意外と役に立てるものだなあ」と思ったりしています
特別難しくてスキルがないと出来ないことって極一部だけで、ある程度勉強すれば誰でもやれることって意外と多くないですか?
分業をやめると判断が洗練される
メンバー全員がプログラマー、デザイナー、企画者など様々な視点を持つことによって、様々な場面で「何を行うべきか」という判断が細かくでき、洗練されると思います
やはり、得意なことが一つだけであったり、担当が決まっていると、問題に対して自分の得意分野で対応してしまいがちです
例えば、「荒らし行為行うユーザーへの対策」をする必要があったとして、
- ブロック機能を強化する
- 投稿に対する監視を強化する
- 荒らしユーザーの IP アドレスや機種からのアクセスを制限する
- 荒らしユーザーが使う言葉を機械学習で学習して、フィルタリングする
- 荒らしユーザーとして使いにくいナビゲーションにする
いろいろやり方がありますよね
そういうときに、つい自分の得意な方法を優先してやりたくなりませんか?
メンバー全員が様々なスキルを身につけることによって、よりフラットに自分が本当にやるべきことは何なのかを判断できるようになると考えてます
あと、デザインに保守性や拡張性の視点が入ったり、コードの細かい部分にユーザ体験への考慮が入りこんできやすくなるという効果もあると思っています
2. 不確実なことを先にやる
弊社では、何事にも「不確実なこと」を先にやるということを重視しています
それは、「次に何をリリースするか」といった比較的大きな視点から、「次にどのコードを書くか」という比較的小さな視点まで様々です
どんな場面でもまず何が「不確実なこと」なのかをはっきりさせ、まず何を試すべきかを考えること重視します
試さなければ分からない機能を先にリリースする
弊社では、結果が分かりきった機能は、なるべく作るのを後回しにします*1
成果が上がることが分かりきった機能であれば、それは結局どの会社でも実装できる機能であり、ベンチャー企業が率先してやるべきことではないと考えているためです
ですので、弊社では「可能性はありそうだけど不確実」な機能を先に作り、それがユーザにどう受け止められるかを先に試します
例えば、弊社のアプリの iPhone 版にはまだプッシュ機能がなかったりもします(^^;
プッシュ機能が確実に数値を伸ばすことは分かっているので、後回しになってしまっているという実情があります
(そろそろ作らないといけないですね><マジでごめんなさいごめんなさい)
不確実なコードから先に書く
また、細かい作業(コードを書く順番や、パーツを作る順番など)でも、不確実なことから先にするようにしています
例えば
- 実際に触ってみないと判断できない UI 部分
- 実際に試してみないと分からない外部連携部分
など、実際にモックを作って触って感じてみないと判断できない部分です
こういう触ってみないと分からない系のコードは、必ず開発の最初期に作って試すようにしています
また、実際に試すときは必ずそのコードを書いてない人と一緒に触わるようにします(コードを書いていると「個々の構成部分」にばかり目がいって、「全体としてのどうなのよ」という観点が失われてしまうので)
試し方にも、ちょっとコツがあって
- 必ずコードを書いた人の席に集まって試す
- 触る過程のちょっとした「指の迷い」や「操作ミス」に着目する
- 仕事を持ち越さない。保留しない。代替案があったらその場でコードを書き換えて、もう一度試す(難しい場合は、ある程度のエッセンスだけでも可)
この 3 つを守って、短い時間でトライアル&エラーをなんども繰り返し、理想的な動きがどのようなもので、それが実現可能なのかを確認します
これを終えることで、不確実な要素がなくなった状態でコードを書くことができ、細かい部分まで迷いなく作ることができるのです
「これ本当に使いやすいんだろうか?」とかそういう不安感も払拭されて、非常に気持ちよくコードが書けて精神衛生面も安定しますよ(^^
というわけで
弊社が開発するうえで、大切にしていることを書いてみました
僕たちは
- プログラミングだけじゃなく、コミュニティの運営やデザイン、会社の経営、など広い視野を持って働いてみたい人
- まだ世の中に試されていない不確実なことをどんどん試したい人
そんな人と一緒に働いてみたい!
そう思っています
Wantedly で採用ページを作っていますので、ぜひぜひご覧ください!
毎日15時30分には退社したいエンジニア募集 - カクテル株式会社の求人 - Wantedly
友達の紹介とかも大歓迎です><
それえでは!
(痩せる...!)
*1:実際には、ユーザーからの要望の具合なども含めて複合的に判断していますが