こんばんは、モチベーションで仕事するな、が信条のku-sukeです。
仕事の満足度には、いろんな要因があるんだけど、マイナス（不足）要因とプラス（やる気）要因の２つに分けて考えたほうがいいというのを読みまして、ハラオチしたので書いてみます。
エンジニアのしあわせみたいなので、マズローの５段階欲求を紹介する記事を見たことがあって、それなりに同意してたんですがなんかしっくり来ないと思っていて、今回の分けるという考え方がそのしっくり来ない部分をうめてくれたように思います。
最近は見かけるかどうかわかりませんが、エンジニアがパフォーマンスよく働ける職場です！自由に新しい技術の挑戦とかできます！（だから給与は安くてもいいよね！）みたいな求人が一部あったように思います。いまもあるか。
■やる気を掻き立てそうなプラス要因
・新しい言語やフレームワークなどチャレンジできる
・自分が思い通りコードベースの設計ができる
・多くの人が期待・利用しているプロジェクトに参加
・自分より優秀な人と一緒に働ける
→成長できそうとか、責任あるポジションとか、すごいところに参加できる感とか。
→もっとわかりやすく言うと、０～プラスで揺れ動きそうな要素。
■不足を感じるマイナス要因としてはどうでしょう
・給料低くて生活が厳しい
・マシンスペック低くてEclipseの起動に3分かかる
・周囲がうるさかったりミーティング多くて集中できない
・空調や労働時間とか体調をくずしてしまう
→足りない系は、マイナス～０の範囲で揺れ動きそうな要素
マイナス要素をガシガシ埋めてあげても、プラス要素がないとやる気にはならないし、プラス要素だけ伸ばしてマイナス要素を放置していると、最悪つぶれてしまいます。
これは僕の中でかなりすっきりする考え方でした。
一人の男の奮闘を見て目頭が熱くなったぼくですが、脊髄反射的にエントリ書いてみようと思う。
ビジネスサイドから見たクローン開発
ぼくは早々に技術サイドとビジネスサイドの2足のわらじを履くことを決めた中途半端な人間だけど、その立場からも色々書いてみる。結論は2点です。
・クローン開発は経営手法としてはナシではないこと
・開発プロセスに対する無理解こそが問題じゃね
クローン開発はビジネス手法としてまっとう。
これについては興味がある人はコピーキャットを読んでみるといいとおもいます。
ビジネスサイドから見たクローン開発
ぼくは早々に技術サイドとビジネスサイドの2足のわらじを履くことを決めた中途半端な人間だけど、その立場からも色々書いてみる。結論は2点です。
・クローン開発は経営手法としてはナシではないこと
・開発プロセスに対する無理解こそが問題じゃね
クローン開発はビジネス手法としてまっとう。
これについては興味がある人はコピーキャットを読んでみるといいとおもいます。
→創造的模倣かパクリか。コピーキャットを読みました。
この世の大半のイノベーションは、なんかしかのコピーである。という本なんですが、なにかうまくいっていることがあれば、それを流用して新しいものを作ること自体はなんら問題ない、まっとうなビジネス判断だと思います。
かつ、上記コピーキャットの中では、他社のビジネスやシステムは表層的にしか見えないから正しくコピーすることは難しいが、社内のある工場のプロセスを別のプロセスにコピーすることは、その設計の複雑に絡んだ考え方も含めてコピーできるのでより確実な成功を生み出す。的なことが書いてありました。
もちろんコピペすれば成功するってわけじゃなく、その難しさや、たとえば格安航空会社（LCC）の成功モデルを真似してうまく言った会社とうまく行かなかった会社の例など、自分の業界に置き換えてみると面白いです。
開発、という面から離れて、そうやってコピーして開発したプロジェクトの運用フェーズになってメリットを感じる事は多々ありました。たとえば、そのシステム利用者に対する「振る舞い」もコピーできるし、たとえば広告チーム、CSチーム、品質管理チームとかとやりとりするときに「あ、○○と一緒でお願いします！」の一言で8割位解決することが有りました。
2.開発プロセスに対する無理解とか
ここからはやや内輪的な話になりますが、既存のシステムを活かした開発というのは、非エンジニアにとって「コストが掛からない、あるいは楽ちんな手法」と感じられている点がエンジニアの不幸を生んでいる原因だと思います。
料理に例えると少しわかりやすいかもしれません。
サラダ スープ 肉料理 パスタ デザート の組み合わせで成功した料理があるとして、件のエントリで言うと、料理を目の前にならべられて、「同じものを作りつつ、サラダのドレッシングを変えて、肉料理の付け合せを変えて、パスタをナスじゃなくて魚介にして」みたいな状況かと思います。
レシピもあるにはあるけど、材料のグラム数が書いてあるわけではなく、肉の厚みが書いてあるわけでも、火を通す時間も具体的にはわからない。
この料理を作ったシェフはいるにはいるんだけど、別のお店をやってるから、隣に立って手取り足取り教えてくれるわけじゃない。
そこで、新店オープンのシェフたちは、目の前の料理を味見しつつ、自分たちで再現できるように料理しますが、問題が起こります。サラダのドレッシングをクリームベースに変えたら、次に出てくるクリームスープと相性が悪く、スープに合うサラダの試行錯誤をしなければいけませんでした。。
結果、あきらめてお皿を変えるだけで料理内容はそのままそっとしておき、コーヒーをプラスしてお茶を濁しました。と。
そんな店でシェフやってて楽しいの？みたいな。
どうやれば幸せになるのか
僕の立場で言うと、以下の2点がうまくバランス取れればいいと思っています。
・ビジネスとして正しいプロセスである、プロジェクトのコピー
・開発として正しくない、ブラックボックス化した秘伝のソースを継ぎ足し継ぎ足し
決してスモールとはいえない、多種多様なスキルレベルを持った組織でダークサイドに落ちないためには、ビジネスモデルを細部に至るまでドキュメント化し、メンテナンスすることではないかと思います。これが少数精鋭のチームであれば、ソースコードがドキュメントだの、テストカバレッジを上げていこうという方が正解だと思うんだけど。
あとは、先の例で言うと、元々の料理のシェフがひとりでも入れば、それほど問題はなかったのかもしれない。師匠から弟子にではないが、生きるドキュメントがいればだいぶ違う。平均質問回答時間が5分なのと30分なのでは、1000回質問をするだけで416時間の差、８時間労働なら52日、16時間労働なら26日の差がついてしまいますね。
ほかにも、そもそも元のシステムがクローンされることを前提に作られているかという問題が有ります。
総勢数百人の部門で、ビジネス要件がころころ変わるプロダクト群を扱い、チームのスクラップ＆ビルドを頻繁に行うビジネス環境で、最も大切なのは仕様の伝達を強化することかなぁと思っています。業務要件がドキュメントとしてメンテナンスされ続けていれば、エンジニアはより各々のポリシーにおいて力を発揮することができるのではないかな。
コピーキャットの例でもあるけど、自社コピーが有効に働く条件は「複雑に絡まった設計の考え方などの完璧なコピー」なので、そのプロセスをないがしろにしてたら、苦労するのは当然なのかも。（なんで、片足ずつ、どっちもに突っ込んでる自分が頑張らないといけないのかもと思って。）
以上、理想論かもしれないけど、コピープロジェクト＝悪みたいなのじゃなく、たんに仕事の進め方の問題だよねってことが言いたかった。私からは以上です。
補足：コピーキャットにもある通り、ど新規はど新規で、既存の知見を生かせないトラブルに見舞われるけど、それはまた、別のお話。
追記：そもそも一人いたら違う、クローンを前提に作られていないんじゃね、というご意見をいただき追記
こないだ、一番ぱつってる日の日報でうちの新卒系リーダーが、「正しい決断ができなかった」って反省文臭く書いてたので、反論しておこうと思う。
まず、正しい決断なんてないこと。
なぜなら正しいかどうかは「時間軸」×「評価軸」の数だけ正解があるからです。
たとえば時間軸で言うと、目先の利益（＝単月スパンでの正しい判断）ばかり考えて３年前とかにまだ十分利益が出ているガラケーのビジネスに固執してほかをみずに進んでると、３年経った現在市場がなくなってしまって困ってしまいます（＝３年スパンでの正しくない判断）
次に評価軸もそれぞれです。ITの現場から離れて、
「イニシャルコスト」という評価軸だとガソリン車を選ぶのが正解だけど、「燃費」という評価軸だとハイブリッド車を選ぶほうが正解。５年間保有コストでみると・・・？また違った答えが出るかもしれないし、「0-100の加速度」でみるとまたちがうよね。
じゃあどうしてあの結論に至ったか
※知らない人はなんの決断かわからないと思うのですが内輪向けブログなのですいません。
まず、評価軸のうち、自社・あるいは自組織で大切にしている評価軸はなにか。ということを考えます。また同時にそれを得るためのリスク評価を行います。
僕とかが気軽に意思決定できるのは、このリスク評価を自分に対して行っているからです。大失敗しても最悪クビになるくらいだからまぁいいや。という感じ。
自分が許容可能な範囲のリスクに収まっていればその判断が鈍らず、どうすればいいかということにだけフォーカスすることが可能です。（なお弊社は数千万円失敗しようがペナルティを課さないようです。挑戦と安心はセット）
次に、A案とB案を比較し、ゲイン（得られるもの）とリスク（失敗したらどうなるか）を評価します。ゲインについてはAとBでAのほうが月間で20%くらい良さそうです。
リスクについては、A案は多少拙速の範囲を超えており、問題が起こることは明らかでした。
しかし問題ゼロを目指すかというとそうではない、ではどのような問題なら許容範囲かという検討に進みます。さらにB案にしたらそのリスクがどの程度減るかということも合わせて評価しました。
その結果、A案とＢ案の抱えるリスクにはあまり差がないことがわかりました。リスクをおさえたければBをより慎重にしたC案を採用しないとダメで、そのばあいゲインが40%くらい減る可能性がありました。
ゲインが減る、ということ自体がひとつのリスクですので、A/B/Cを勘案した結果、Aで基本すすめつつ、多少B/Cの要素も可能であればわずかに取り入れるという決断になりました。
もう一つ大事なこと
意思決定において重要なのは、「いつまでに」意思決定するかです。前述のABCは時間軸がずれていたため、１日意思決定がずれるとA案のリスクが倍程度に高まることがわかっていました。
本当はもっと入念に意思決定に必要な情報を集めたかったです。クリティカルな問題が起きる可能性がどの程度あるのか、ゲインの算定基準は本当に根拠があるものなのか。
しかし限られた時間で決定を下さないとより悪化することがわかっている以上、決定しなければないりません。意思決定者というのは、間違った決断をすることよりも、決断を先延ばしにすることのほうが罪なのです。
限られた情報でもやがかかったまま、それでも右に進むか左に進むか決めないといけない。間違った道を選べば責められる、それが意思決定者です。辛く孤独でいいことないのでその分お給金が一般的に高めで設定されています。
私からは以上です。
まず、正しい決断なんてないこと。
なぜなら正しいかどうかは「時間軸」×「評価軸」の数だけ正解があるからです。
たとえば時間軸で言うと、目先の利益（＝単月スパンでの正しい判断）ばかり考えて３年前とかにまだ十分利益が出ているガラケーのビジネスに固執してほかをみずに進んでると、３年経った現在市場がなくなってしまって困ってしまいます（＝３年スパンでの正しくない判断）
次に評価軸もそれぞれです。ITの現場から離れて、
「イニシャルコスト」という評価軸だとガソリン車を選ぶのが正解だけど、「燃費」という評価軸だとハイブリッド車を選ぶほうが正解。５年間保有コストでみると・・・？また違った答えが出るかもしれないし、「0-100の加速度」でみるとまたちがうよね。
じゃあどうしてあの結論に至ったか
※知らない人はなんの決断かわからないと思うのですが内輪向けブログなのですいません。
まず、評価軸のうち、自社・あるいは自組織で大切にしている評価軸はなにか。ということを考えます。また同時にそれを得るためのリスク評価を行います。
僕とかが気軽に意思決定できるのは、このリスク評価を自分に対して行っているからです。大失敗しても最悪クビになるくらいだからまぁいいや。という感じ。
自分が許容可能な範囲のリスクに収まっていればその判断が鈍らず、どうすればいいかということにだけフォーカスすることが可能です。（なお弊社は数千万円失敗しようがペナルティを課さないようです。挑戦と安心はセット）
次に、A案とB案を比較し、ゲイン（得られるもの）とリスク（失敗したらどうなるか）を評価します。ゲインについてはAとBでAのほうが月間で20%くらい良さそうです。
リスクについては、A案は多少拙速の範囲を超えており、問題が起こることは明らかでした。
しかし問題ゼロを目指すかというとそうではない、ではどのような問題なら許容範囲かという検討に進みます。さらにB案にしたらそのリスクがどの程度減るかということも合わせて評価しました。
その結果、A案とＢ案の抱えるリスクにはあまり差がないことがわかりました。リスクをおさえたければBをより慎重にしたC案を採用しないとダメで、そのばあいゲインが40%くらい減る可能性がありました。
ゲインが減る、ということ自体がひとつのリスクですので、A/B/Cを勘案した結果、Aで基本すすめつつ、多少B/Cの要素も可能であればわずかに取り入れるという決断になりました。
もう一つ大事なこと
意思決定において重要なのは、「いつまでに」意思決定するかです。前述のABCは時間軸がずれていたため、１日意思決定がずれるとA案のリスクが倍程度に高まることがわかっていました。
本当はもっと入念に意思決定に必要な情報を集めたかったです。クリティカルな問題が起きる可能性がどの程度あるのか、ゲインの算定基準は本当に根拠があるものなのか。
しかし限られた時間で決定を下さないとより悪化することがわかっている以上、決定しなければないりません。意思決定者というのは、間違った決断をすることよりも、決断を先延ばしにすることのほうが罪なのです。
限られた情報でもやがかかったまま、それでも右に進むか左に進むか決めないといけない。間違った道を選べば責められる、それが意思決定者です。辛く孤独でいいことないのでその分お給金が一般的に高めで設定されています。
私からは以上です。
「Re:サイタル」というソーシャルゲームが事前登録を開始しました。みなさまよろしければぜひ。
さて、もうひとつのブログに半年前くらいかいたんですが、「ゲーム」という存在からとっても遠い自分が、はじめてゲーム作りに携わって勉強したことをメモしておきます。ビジネス視点なのでゲームクリエイター視点ではありません。
おもしろさ について
ソーシャルゲームをやらない人は、あんなポチポチゲーなにがおもしろいの？と揶揄するのですが（ぼくもそっち側の人間です）半年間いくつかのゲームをやってみて、色々とわかったような気がします。気がするだけかもです。
ゲームとはなにか？をいくつかのゲームプランニングの入門書を読んでみましたが、どうもつきつめると、一定のルールに基づき自分自身や他人と競うインタラクティブな娯楽である。ということのようです。
プロジェクトの企画フェーズで「なぜこのゲームが楽しいのか」を文字に起こさないといけない場面があり（プロモなど関係者にイメージを伝えるためです）まったく書けずに相当悩んでいましたが、上記の定義を考えて結局諦めました。「おもしろさ」というのは膨大な要素のバランスの上で成り立っているので、誰が見てもわかるようには文字などで書き起こせる情報量ではないのです。
娯楽産業だということ
広く「娯楽」、特に1人で楽しめるもので例えてみましょう。オーケストラを鑑賞しにいった時に感じた面白さを、クラシック音楽をまともに聞いたことがない人に伝えるのはすごく苦労すると思いますし、ほかにも僕は「ヒトカラ」の魅力を言葉で力説されてもあんまり魅力が伝わる気がしません。言葉で伝えられる娯楽の「おもしろさ」というのはその程度だと思う気がします。
しかしながら、伝える相手を限定すればできなくもありません。例えば、○○という似たゲームをひと通り遊んだユーザに対してであれば、差別化要素のみを伝えることで「おお、それは面白そうじゃん」となります。さっきのクラシックだと「あそこのオケ、中盤のストリングがほんとに感動的で！」みたいなポイントだけでおもしろさを共有できるわけです。（話はそれますが、相手の立場を想像するみたいな伝え方は、伝え方が9割の本に書いてましたね。）
そこで、社内、同業の人に伝えられるためにいろいろな要素があることを意識しました。なぜ「楽しい」「心地よい」かはいくつかの要素に分割できると思います。例えばおしゃれなレストランの良さを説明するのであれば
・みせの雰囲気
・ドリンクの豊富さ
・料理の美味しさ
・店員の態度
・価格
と言った要素があると思います。どれか一つがよいだけでは人気のお店にはなれません。どんだけワインが美味しくて(差別化要因)も、店員がムカつく感じだったらダメですね。ゲームも、グラフィックやゲームシステム、レスポンス速度や文字のラベリング、課金設計などいくつかのポイントが同様に有ると思います。
ソーシャルゲームビジネスってどうなの？
ビジネス的な面でわりとこれが一番感じたものに近かった。※個人の見解です。
http://anond.hatelabo.jp/20110918202040
立場上、この増田と違い集客力がある大手に分類されるので、ちゃんとリリース時にフルスペックで投入することと、あとはクオリティを上げていきましょうねという話だった。某社や某社の中の人にも聞いてみたけど、世の中がネイティブ化の流れとはいえ多くの会社はまだ売上の大部分をブラウザカードゲームに依存してて、その売上があるうちにネイティブ「も」投資していこうというフェーズなんじゃないかと思います。
ただ少なくとも、カードゲームもカードゲームなりに進化していないとダメで、絵師の確保や、サクサク動くようなチューニングは本当にコストを掛けてやってるなと感じる。あと、売上の多くはイベントによって発生してるっぽいので、イベント運用はどんどん進化しているなーと感じます。
チームが一番勉強になった。
今回のチームは、自分がゲームも、アニメも、全然からっきしだったので、ゲームを面白くとことん追求したい人とうまく対立側に回って、とにかく日程内に終わらせる担当をしました。以前にもかきましたが、2つの意見をぶつからせてるほうが健全なので、「もっとちゃんとしたい、こんなんじゃダメだ！」派と「うるせぇあと2週間しか無いんだこれで行くぞ！」派がぶつかって結果いいバランスに落ち着けた気がします。リソースは有限ですし。
また、上で学んだ要素、に関してはほんとうに勉強になりました。レイドイベント中に、こういう事を出してあげないと萎えてやる気なくて辞めていく。とか些細なポイントだったり、この絵の肩の角度は実際だとおかしいからレタッチしないと違和感が出ちゃう。とか素人目だと気づかないところでも、before/afterをみくらべるとたしかに。と感じます。
とりあえず作業が終わらずブログに現実逃避でした。ひぃ。
さて、もうひとつのブログに半年前くらいかいたんですが、「ゲーム」という存在からとっても遠い自分が、はじめてゲーム作りに携わって勉強したことをメモしておきます。ビジネス視点なのでゲームクリエイター視点ではありません。
おもしろさ について
ソーシャルゲームをやらない人は、あんなポチポチゲーなにがおもしろいの？と揶揄するのですが（ぼくもそっち側の人間です）半年間いくつかのゲームをやってみて、色々とわかったような気がします。気がするだけかもです。
ゲームとはなにか？をいくつかのゲームプランニングの入門書を読んでみましたが、どうもつきつめると、一定のルールに基づき自分自身や他人と競うインタラクティブな娯楽である。ということのようです。
プロジェクトの企画フェーズで「なぜこのゲームが楽しいのか」を文字に起こさないといけない場面があり（プロモなど関係者にイメージを伝えるためです）まったく書けずに相当悩んでいましたが、上記の定義を考えて結局諦めました。「おもしろさ」というのは膨大な要素のバランスの上で成り立っているので、誰が見てもわかるようには文字などで書き起こせる情報量ではないのです。
娯楽産業だということ
広く「娯楽」、特に1人で楽しめるもので例えてみましょう。オーケストラを鑑賞しにいった時に感じた面白さを、クラシック音楽をまともに聞いたことがない人に伝えるのはすごく苦労すると思いますし、ほかにも僕は「ヒトカラ」の魅力を言葉で力説されてもあんまり魅力が伝わる気がしません。言葉で伝えられる娯楽の「おもしろさ」というのはその程度だと思う気がします。
しかしながら、伝える相手を限定すればできなくもありません。例えば、○○という似たゲームをひと通り遊んだユーザに対してであれば、差別化要素のみを伝えることで「おお、それは面白そうじゃん」となります。さっきのクラシックだと「あそこのオケ、中盤のストリングがほんとに感動的で！」みたいなポイントだけでおもしろさを共有できるわけです。（話はそれますが、相手の立場を想像するみたいな伝え方は、伝え方が9割の本に書いてましたね。）
そこで、社内、同業の人に伝えられるためにいろいろな要素があることを意識しました。なぜ「楽しい」「心地よい」かはいくつかの要素に分割できると思います。例えばおしゃれなレストランの良さを説明するのであれば
・みせの雰囲気
・ドリンクの豊富さ
・料理の美味しさ
・店員の態度
・価格
と言った要素があると思います。どれか一つがよいだけでは人気のお店にはなれません。どんだけワインが美味しくて(差別化要因)も、店員がムカつく感じだったらダメですね。ゲームも、グラフィックやゲームシステム、レスポンス速度や文字のラベリング、課金設計などいくつかのポイントが同様に有ると思います。
ソーシャルゲームビジネスってどうなの？
ビジネス的な面でわりとこれが一番感じたものに近かった。※個人の見解です。
http://anond.hatelabo.jp/20110918202040
立場上、この増田と違い集客力がある大手に分類されるので、ちゃんとリリース時にフルスペックで投入することと、あとはクオリティを上げていきましょうねという話だった。某社や某社の中の人にも聞いてみたけど、世の中がネイティブ化の流れとはいえ多くの会社はまだ売上の大部分をブラウザカードゲームに依存してて、その売上があるうちにネイティブ「も」投資していこうというフェーズなんじゃないかと思います。
ただ少なくとも、カードゲームもカードゲームなりに進化していないとダメで、絵師の確保や、サクサク動くようなチューニングは本当にコストを掛けてやってるなと感じる。あと、売上の多くはイベントによって発生してるっぽいので、イベント運用はどんどん進化しているなーと感じます。
チームが一番勉強になった。
今回のチームは、自分がゲームも、アニメも、全然からっきしだったので、ゲームを面白くとことん追求したい人とうまく対立側に回って、とにかく日程内に終わらせる担当をしました。以前にもかきましたが、2つの意見をぶつからせてるほうが健全なので、「もっとちゃんとしたい、こんなんじゃダメだ！」派と「うるせぇあと2週間しか無いんだこれで行くぞ！」派がぶつかって結果いいバランスに落ち着けた気がします。リソースは有限ですし。
また、上で学んだ要素、に関してはほんとうに勉強になりました。レイドイベント中に、こういう事を出してあげないと萎えてやる気なくて辞めていく。とか些細なポイントだったり、この絵の肩の角度は実際だとおかしいからレタッチしないと違和感が出ちゃう。とか素人目だと気づかないところでも、before/afterをみくらべるとたしかに。と感じます。
とりあえず作業が終わらずブログに現実逃避でした。ひぃ。
これ、若い人にありがちな悩みだと思うんだけど、結構相談されることが多いのでブログにしておきます。
「L◯NEみたいに大きなプロジェクトやってみたいです！」
「自分の力で自由に新しいもの作ってみたいです！」
だいたいこの２つがよくある「やってみたいこと」を聞いた時の反応ですが、この２つはほぼ相反します。そしてどちらに所属することになっても文句をいう人は文句を言うし、輝く人は輝くので、輝ける人が少しでも多くなるように心の準備を提供したいと思います。
でっかいプロジェクトのメリット！
・とにかくたくさんのユーザが使ってる。ヘタしたら友達も。
・各職種に凄腕のリーダーがいたりして、ヒトカネモノのリソースが充足している。
→こんな凄いプロジェクトに携われてる幸せ感。
デメリット！
・レギュレーションとかルールがしっかりしてて冒険しにくい。
・でっかいサービス の中の ごくごく一部 しか携われない。
→プロジェクトが大きいと「あなたの」仕事が相対的に小さく見えてしまう。
無名な新規プロジェクトのメリット！
・デザインやインフラ設計からマーケティングまで0から10まで携われる。
・デザインで言うとトンマナや、システムで言うとフレームワークなんかも自由に決めれる。
→プロダクトに対してオーナーシップを感じやすい（俺が作った！）
デメリット
・一般的に売上が立っていない投資フェーズなのでヒトカネモノが不足しがち
・リリースしても無名過ぎて誰も見てくれない可能性が高い。
→とにかく存在が小さいので、大きく育てないとなんにもならない。
というわけで、「隣の芝は青く見える」ことも相まって、でかいプロジェクトの一部分に入ってるときは自分でサービスやりたい、もっと自由にしたい欲がでて、逆に小さな新規サービスの所属になると、アレが足りない、これが○○だから無理。となってしまいます。
なので、メリットデメリットもわかった上で、自分が好きな方を選んでいくといいんじゃないかと思います
自分はどっちも楽しいです！
✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
「L◯NEみたいに大きなプロジェクトやってみたいです！」
「自分の力で自由に新しいもの作ってみたいです！」
だいたいこの２つがよくある「やってみたいこと」を聞いた時の反応ですが、この２つはほぼ相反します。そしてどちらに所属することになっても文句をいう人は文句を言うし、輝く人は輝くので、輝ける人が少しでも多くなるように心の準備を提供したいと思います。
でっかいプロジェクトのメリット！・とにかくたくさんのユーザが使ってる。ヘタしたら友達も。
・各職種に凄腕のリーダーがいたりして、ヒトカネモノのリソースが充足している。
→こんな凄いプロジェクトに携われてる幸せ感。
デメリット！・レギュレーションとかルールがしっかりしてて冒険しにくい。
・でっかいサービス の中の ごくごく一部 しか携われない。
→プロジェクトが大きいと「あなたの」仕事が相対的に小さく見えてしまう。
無名な新規プロジェクトのメリット！・デザインやインフラ設計からマーケティングまで0から10まで携われる。
・デザインで言うとトンマナや、システムで言うとフレームワークなんかも自由に決めれる。
→プロダクトに対してオーナーシップを感じやすい（俺が作った！）
デメリット・一般的に売上が立っていない投資フェーズなのでヒトカネモノが不足しがち
・リリースしても無名過ぎて誰も見てくれない可能性が高い。
→とにかく存在が小さいので、大きく育てないとなんにもならない。
というわけで、「隣の芝は青く見える」ことも相まって、でかいプロジェクトの一部分に入ってるときは自分でサービスやりたい、もっと自由にしたい欲がでて、逆に小さな新規サービスの所属になると、アレが足りない、これが○○だから無理。となってしまいます。
なので、メリットデメリットもわかった上で、自分が好きな方を選んでいくといいんじゃないかと思います
自分はどっちも楽しいです！
✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌