案件が重なった月、チームで何が起きていたか。

受託開発をしていると、既存案件の稼働が埋まったところに、次の相談が入ることがあります。

一人で仕事を受けているなら、断るか、納期を延ばすか、自分の稼働を増やすか。

誰かに渡すとしても、売上とクライアントとの関係まで失うのではないかという迷いが残ります。

TamaTでも、複数の案件が同じ時期に重なった月がありました。

そのとき動いたのは、実装担当だけではありません。

案件を取ってきた人が持ち続ける責任、実装を担う人の成長機会、社内での評価も一緒に動いていました。

過去2回の対談では、AIを使った実装と、各自が異なる道具を使いながら開発フローを揃える過程を取り上げました。

第3回は、田中と増田が実際の案件配分を振り返ります。

稼働100%のところに、次の相談が来た

増田： あの時期、たけさんは何を持っていましたっけ。

田中： Next.jsとStripeを使うECサイト案件だね。

要件定義をして、ワイヤーフレームまで自分で引いていた。

そこから実装に入るタイミングで、メンバーに振ったほうが成長につながると考えた。

増田： 自分の場合は、別のクライアント案件で稼働が100%埋まっているときに、リードから新しい相談を受けました。

自分だけでは持てないので、TamaTのなかでシェアすることにしました。

田中： 片方は、設計まで進んだ案件の実装が始まるタイミング。

もう片方は、すでに稼働が埋まっているところへ新しい相談が来たタイミングだった。

重なり方は違ったけど、一人の予定表だけでは収まらなかったのは同じだね。

「持てない」と言うまでの距離

増田： 誰かが様子を見て「これは危ない」と気づいたというより、最初に出したのは抱えている本人からでしたね。

田中： そうだね。

ただ、日報で各自の稼働状況はいつも共有しているから、相談を受けた時点で「いま何%埋まっています」と一から説明する必要はなかった。

空いている人に、その場で技術スタックや案件の条件を伝えて、興味があるかを聞けた。

増田： 毎日顔を合わせていることも効きました。

同じ内容でも、メールで「案件のご相談があります」と届くと仰々しく見えるし、受ける側にもプレッシャーがかかる。

対面なら、要件と稼働を見ながら「これ、どうですか」と聞けます。

田中：引き受けたあとも、わからないことがあれば、その場で質問できる。

案件を渡した時点で、自分が連絡を絶つわけではないからね。

稼働が見えていることと、短い会話ですぐ条件を確かめられること。

この二つが揃っていたため、新しい会議や正式な依頼文を用意する前に、担当を動かせました。

実装を渡しても、案件の責任までは渡さない

増田： ECサイト案件は、どこから切り出しましたっけ。

田中：要件定義とワイヤーフレームは自分で持って、実装を切り出した。

単に手が足りなかったからではなく、使ったことのない技術スタックを経験してもらう意図もあった。

Next.jsとStripeを組み合わせたECサイトは、次の案件にもつながる経験になるから。

増田： 要件定義から全部を渡したわけではなかったんですね。

田中：そこは案件ごとに違う。

この案件では自分が要件を詰めていたし、実装中に質問が出たら自分がバックアップする前提だった。

担当を替えても、案件オーナーとしての文脈は持ち続けていたよ。

増田： 自分が新しく相談を受けた案件では、最初の接点は自分がつくり、初回ミーティングにも参加しました。

ただ、案件規模を考えると、その後も二人分のリソースを割く必要はなかった。

要件を詰める段階から先は、担当するメンバーに任せました。

田中： その場合も、クライアントとの接点は増田が持っているんだよね。

増田： はい。日々の開発は担当者に任せながら、クライアントとの関係を持つ立場は自分に残しています。

同じクライアントから複数の相談を受け、それぞれの案件をTamaTのなかで担当できる人に振り分けるイメージに近いです。

二つの案件では、切り出した範囲が異なりました。

一方は要件定義と設計を田中が持ち、実装を渡しました。

もう一方は最初の商談を増田が持ち、その後の要件整理と開発を担当者に渡しました。

共通していたのは、クライアントとの接点をつくった人が、担当変更後も関係と責任を手放していないことでした。

案件を渡した人の評価はどうなるか

増田： フリーランスとして一人で受けていたら、案件を渡すことは、そのまま自分の売上を手放すことになりやすいですよね。

TamaTでは、実装をほかのメンバーに渡した場合、評価はどうなりますか。

田中： 仕事を取ってきたこと自体を評価するし、顧客と折衝している人の優先度は高い。

顧客との接点をつくり、何を作るべきかを決めていく仕事は、現時点のAIでは代替できないから。

増田： 実装を渡しても、自分が遂行した案件としてカウントされる仕組みですよね。

案件を見つけて、社内の担当者につないだ仕事が消えるわけではない。

田中： AIを使いながら実装を進める技術も、別のスキルとして評価する。

顧客との接点を持つ人と、実装を担う人のどちらか一方だけで案件が進むわけではないから、役割ごとに見ている。

この評価方法では、案件を取った人の実績と、実装を担った人の実績が同時に残ります。

担当を抱え続けることだけが、社内で評価を守る方法にはなりません。

手が空いた時期に回ってきた案件

田中： 逆に、増田の手が空いていた時期はどうだった？

増田： 安定して案件をシェアしてもらっていました。さっきのECサイト案件も、その一つです。

田中： 案件を渡すとき、技術レベルはどう見ていた？

増田： その時点の技術レベルで無理なく終わるものというより、少し上の要件を求められる案件が多かったと思います。いい成長機会になりました。

開発者として案件に入り、わからないところは出社したときにすぐ聞ける。経験のない技術が含まれていても、質問先がわかっているので取り組めました。

フリーランス同士で融通する場合との違い

増田： ここまでなら、「フリーランス同士でも案件は融通できる」と言われそうです。会社であることの違いは、どこにありますかね。

田中： フリーランス同士で別の人に案件を渡すと、契約によっては再委託の形になる。

クライアントがそれを嫌がることもあるし、問題が起きたときに誰が責任を持つのかが見えにくくなる。

紹介した側も、自分の評判をかけて相手に任せることになるよね。

増田： そうですね。同じ組織のなかで担当を替えられるので、案件をシェアする体制は組みやすいと思います。

あと、エンジニア視点で見ても、個人間の信頼だけで続ける場合と比べて、会社には契約上のつながりがあります。

田中： 顧客から得た信頼を、一つの看板に預けられることも大きい。

誰か一人の実績で終わらず、複数人が同じ看板で仕事を重ねるほど、次に別のメンバーが入るときの信頼も積み上がる。

個人間の善意だけに頼ると、契約、責任、評判を案件ごとに調整する必要があります。

TamaTでは、クライアントとの契約と評価を会社に残したまま、実装担当を変えられます。

次に重なったとき、先に整えたいもの

田中： 全案件のオンボーディング資料は、まとめておきたいな。

自分が獲得して別のメンバーが進めている案件でも、その後の実態を細かく把握できていないことがある。

緊急時に入ろうとしても、最初に確認する情報が揃っていない。

増田： プロジェクトが属人化していて、緊急対応をシェアしづらかったこともありました。

客先から個人に発行されたメールアドレスやアカウントを使う案件は、別の人がすぐ入れる状態になっていません。

少なくとも連絡先とアカウントの所在は、どの案件でも管理しておきたいです。

田中： 案件を渡す判断ができても、アクセス権や連絡先が個人に閉じていたら、緊急時には動けないからね。

TamaTでは、稼働が埋まった人から別のメンバーへ仕事が移りつつも、丸投げではなく、オーナーシップを持って顧客との関係と評価を維持し続けることを大事にしています。

また、手が空いた時期には、別案件の実装が移り、経験のない技術は気軽に知見のシェアができました。

一人で案件の波を受け止める働き方に限界を感じている方へ。

TamaTの仕事と働き方に興味があれば、[採用サイト](https://recruit.tamat.jp/) をご覧ください。