個人とチームで働き方はどう変わる? ソロプレイヤーの視点から見たチームワーク。


以前個人事業主であったころ、わたしは純然たるソロプレイヤーでした。基本的にひとりで決め、ひとりで開発し、ひとりでリリースするというワークスタイルで、デザインからフロントエンド、バックエンドまでひとりで行うワンストップ体制で15年以上にわたって業務を行っていました。

そんなわたしがチーム開発にはじめてジョインしたのが現在所属している Gaji-Labo のプロジェクトでした。はじめて本格的なチームワークに触れ、環境の違いに驚き衝撃を受けたことを覚えています。

この記事ではソロとチームの違いについて、実際にチームの中で揉まれながら常々考えていることを言語化してみたいと思います。

ソロとチーム、なにが違う?

ソロとチームとで根本的に何が違うかというと、当たり前ですが人数が違います。ひとりではやれないことができるのがチームの強みで、逆にひとりの方が効率的にやりやすいものがソロの強みとなります。

では具体的にどのようなところで差が生まれるのでしょうか。いくつか挙げて掘り下げてみたいと思います。

  • 裁量と責任と自由度
  • 仕事のスケール
  • 視点の数

裁量と責任と自由度

個人の場合裁量権は全て自分にあり、その裁量の内において完全に自由です。依頼された仕事を受けるも断るも自分だけで選択できます。さまざまな事項を自分の責任においてクライアントと交渉し、決定することができます。自分の中で完結するのでとても小回りが利きます。

対してチームでは、一人に責任を集中させずメンバーへと分散されます。必ずしも裁量権は自分の手にあるわけでなく、例えばプロジェクトの重要な決め事があれば、チーム内で検討して決めることとなります。

これだけ聞くと個人の方が自由であるかのように思われるかもしれませんが、一概にそうとも言えません。個人が自由なのはあくまでも「自分の能力の枠の中で」という条件付きなのです。つまり自分の能力を超えるオーダーは選択できません。「自由」を「可能性」と言い換えた場合、メンバーの能力によって可能性を広げることができるチームの方が、より自由であるとも言えます。

また、個人は自身に全責任が集中することになり、プレッシャーもそれだけ大きなものになります。チームではプレッシャーもまた分散されます。

仕事のスケール

個人は一人分のリソースしか使えないので、一人分のスケールの仕事しか請け負うことはできません。時間単位で限られたリソースをやりくりするしかないので、ひとつ大きな仕事を進行しているところへ他の大きな魅力的な案件の打診が来たところで、自分のリソースに収まらなければ涙を飲んで見送ることになります。

チームの場合は、もちろんメンバーの人数分だけリソースの絶対量がはるかに大きいという前提もありますが、それに加えてメンバーのリソースには少なからず余白があるため個人に比べると調整の余地が大きいです。上手にリソースパズルを組めばより多くの案件を進行できますし、その中でチャレンジをすることもできるでしょう。

また、仕事のスケールというのはリソースの話だけでなく、職種や能力においてもその制限があります。

個人では、自分自身が理解できる範囲の仕事しかできません。わたしの場合は出来るだけ手広く案件を獲得したかったのでデザイン・フロントエンド・バックエンドまで「広く浅く」という、ともすれば器用貧乏とも言われる方針で活動していました。しかし、個人が独自で蓄えられる知見はそんなに多くはありません。「広く浅く」「一部深く」はできても「広く深く」は無理です。

しかしチームには様々な職種のエキスパートがいます。チームがひとつの存在ならば、「広く深く」を完全に体現出来ていると言えるでしょう。これはソリストでは手に入れることができないものです。

視点の数

チームには、メンバーの数だけ異なった角度の視点があります。これはレビューなどのシーンで非常に重要で、自分が進行中のタスクで「当事者すぎて気付けない」ポイントに着目してもらうことができます。

例えば、ひとりで何時間も悩んでいた問題が、メンバーの視点からもらったアイデアで一瞬で解決した経験はないでしょうか?解決してしまえば「なんだそんなことか!」という物だったりするのですが、ひとりで作業をしていると一人称視点による思い込みにとらわれて気付けないことがよくあります。

個人の場合は視点はひとつだけで、客観的視点をもつことはとても難しいです。スイッチングすることである程度他の視点をもてはしますが、それは想像以上に大変でコストが嵩むものです。

特にレビューはプロダクトの品質を担保するために必要不可欠なプロセスですが、「自分が作って自分がレビューをする」というのは視点を変えられなければほとんど無意味です。考慮漏れなども発生しやすく、それをリリースするというのはとても恐ろしいことです!

人が集まればチームになるか

では、人が集まればそれでチームになるのでしょうか?

残念ながら、集まっただけではただの「集団」であってチームではありません。集団がチームになる条件は「同じ目標に向かって行動できる」ことだと考えています。英英辞書に team の定義を尋ねると、「目標のために一緒に行動する集団」といったような意味合いだと教えてくれました。チームには目標が必要なのです。

良いチームになるための条件は色々ありますが、それらのどれもが目標達成のためのものです。心理的安全性や当事者意識、知見の共有などを推進剤にして、より大きな目標にたどり着くためにチームは成長していきます。

ソロとチーム、どっちが良いか

ここまでチームの良い部分ばかりを挙げ連ねましたが、ソロのメリットも挙げなければフェアじゃないですね。

ソロの良いところは、コミュニケーションコストを最低限まで抑え、最高速度を維持したまま進行できるところだと考えています。小〜中規模のスケジュールがタイトな開発でリリースまで走り切らなければならないようなケースでは、小回りの効くソロプレイの方が機動力を発揮できるかもしれません。チームを組んでいる組織の中でも、「スポットでソロプレイをして成果を出す」という戦略が効果的なシーンもあるのではないでしょうか。

おわりに

小難しい話は抜きにして、ひとりではないということはそれだけで価値があり、可能性を感じるものです。なにより、チームにはひとりでは味わうことのできない喜びや楽しさがあります。

しかし、万年ソロプレイヤーだった者がチームにダイブするというのは勇気の要ることでした。チーム内での正しい振る舞い方がわからない、ちゃんと成果を出せるかわからないという不安がありました。そんな心配を払拭して背中を押してくれたのは、チーム側の受け入れ体制であり、見本を示してくれる頼もしいメンバーのサポートです。

わたしたち Gaji-Labo は、チームワークを提供します。良いチームは、新たにメンバーを迎えてチームを強く大きくしていくことにも強い関心があります。今後もより高い価値を生み出せるように、チーム全体で一歩ずつ成長していきたいと思います。

Gaji-Labo は新規事業やサービス開発に取り組む、事業会社・スタートアップへの支援を行っています。

弊社では、Next.js を用いた Web アプリケーションのフロントエンド開発をリードするフロントエンドエンジニアを募集しています!さまざまなプロダクトやチームに関わりながら、一緒に成長を体験しませんか?

もちろん、一緒にお仕事をしてくださるパートナーさんも随時募集中です。まずはお気軽に声をかけてください!

求人応募してみる!


投稿者 Oikawa Hisashi

フロントエンドエンジニア。モダンなJavaScript開発に関心があります。 デザインからバックエンドまで網羅的にこなすマルチデザイナーとして長く活動してきた経験を活かして、これから関わる様々なものをデザインしていきたいです。チームもコミュニケーションもデザインするもの。ライフワークはピアノと水泳。