プロジェクトマネージャー、ブリッジエンジニア、デザイナー、フロントエンド、バックエンド、モバイル、QAが揃ったチームです。長年一緒に納品してきたため、基準やレビューの習慣、引き継ぎの形式が、貴社の案件で発明されるのではなく最初から存在します。
こんな場合に向いています
- 採用プロセスではなく、来月から動くチームが必要
- プロダクトの構想はあるが、それを作る開発組織がない
- 職種ごとに別の発注先ではなく、納品全体に責任を持つ窓口を一つにしたい
- フリーランスを個別に集めてみて、調整に時間を失った経験がある
こんな場合には向きません
- 購買部門が法人、法人契約、または適格な請求書を要求する場合。そのために用意しているベンダー契約の選択肢をご覧ください
- 20名以上、あるいは途中で急に増員が必要な場合。フリーランスチームには上限があり、後で判明するより先に申し上げます
- 日本のオフィスへの常駐が必要な場合
- 最安値を求める場合。私たちは最安ではなく、長年一緒に働いてきたことがその理由です
得られるもの
一つのチーム、一つの基準
個別採用では買えない部分です。
- コードレビューの習慣と完了の定義が、貴社案件の前にすでに合意済み
- デザイナーと開発者が、互いへの受け渡し方をすでに学んでいる
- 完成画面ではなく受け入れ基準から始まるQAプロセス
責任の窓口が一つ
7人ではなく、私と話していただきます。
- デザイン、実装、テストを通した単一の計画
- 納品全体について週に一度の書面報告
ベトナム語、英語、日本語で対応
オフショアでは意思疎通が実際のリスクになりがちです。
- 貴社側と実装チームの間にブリッジエンジニアを置く
- 仕様と引き継ぎ文書は、貴社チームが読む言語で
進め方
工程 1
仕事に合わせてチームを組む
職種構成は作るものによって変わります。
- モバイル製品と社内向けWebツールでは必要な構成が異なる
- 氏名と担当責任の一覧をお渡しします
工程 2
意図的に小さくした最初の有償スプリント
2週間、実際の成果物、抜けやすい設計。
- 判断材料になる成果が出る範囲を切り出す
- 合わなければここで終了でき、四半期ではなく2週間の損で済む
工程 3
本格的な納品
固定した週次のリズム。
- 毎週の計画、デモ、書面報告
- テストケースは実装前に合意する。実装後ではない
工程 4
引き継ぎ
誰も文書化を好まない部分まで含めて、貴社が所有します。
- コード、テストケース、環境構築手順、デプロイ手順
- 引き継ぎ後の支援期間を、最初に書面で合意
よくある質問
実際のメンバーは誰ですか。
仲介サイトからではなく、これまで一緒に納品してきた人から案件ごとに編成します。確約の前に氏名と担当をお渡しし、私が直接一緒に働いた人とそうでない人も明示します。
契約と請求はどうなりますか。
チームと直接です。経理部門が法人契約、適格請求書、あるいは紛争時に追える法人を必要とする場合、この選択肢は合いません。ベンダー契約が合います。
途中で誰かが離脱したら。
私が穴を埋め、その役割を交代させます。これは会社と比べたフリーランスチームの正直な弱点であり、ベンダー契約の選択肢が存在する理由でもあります。
自社の開発者と混成で進められますか。
できますし、多くの場合そのほうが良い形です。混成チームは責任範囲の線引きをより明確にする必要があり、それは技術ではなくプロジェクト管理の課題です。
