“GigAgile” もう一つのアジャイル開発 – Gig Economy とソフトウェア開発

GigAgile とは

GigAgile とは Agile をベースとした開発プロセスであり、ソフトウェア開発サイクル(下図)におけるメソドロジーの総称です。

スクラムの骨格である「経験主義」「リーン思考」に基づいた各種エッセンスをそのままに、Gigの良さである、集合知によるラストワンマイルのクオリティ向上、特定分野に囚われないプロフェッショナルで弾性の高いチーム構成をプラスしたもので、TC3 とその基盤となった Topcoder から合わせて20数年の Gig とのやり取りにおいて積み上げられてきたノウハウの結晶です。

今回の記事では、GigAgile を形成するメソドロジーの一つ「Scrum with Gig」について解説します。

GigAgile については過去のブログでも触れていますが、ソフトウェアを作る側に向けた紹介はこの記事が初となります。

• GigAgile: 世界レベルのスキルを活用した実用最小限のプロダクト（MVP）の開発手法のご紹介 (2020)
• 第5回 ”Gig”abyte: アジャイルのプロセスにギグ・エコノミーの力を 組み込むGigAgileを探索！(2021)
• リーゴの地域見える化・連携プラットフォーム『エリアコンパス』の内製開発をTC3のギグエコノミーを活用したGigAgileで支援 (2023)

Scrum with Gig に入る前に少し弊社固有の前提知識の補足をする必要があります。それは、人々の働き方に関する2つの定義です。

タスクコミット型な働き方の普及

人材の流動性が高まるにつれ、優秀な開発者を長期間抱え込む前提の開発プロセスは現実的ではなくなってきています。

数名の開発メンバーを社員やフリーランスで常時維持するコスト、メンバーが離脱し蓄えた経験や知識が無くなってしまったときに減速してしまう開発スピード。それに引きずられて発生する想定外の遅延と売上の機会損失。どうしようもないことも当然ありますが、そんな中でも針の穴を通し、絡んだ糸を解くように改善を続けることがエンジニアリングというものです。

TC3が定義するチームにメンバーを迎える方法には大きく2つあります。

名称	説明	向いている仕事	向いていない仕事
ロールコミット型	役割を遂行することが仕事。 期間を決めて定期的に決まった金額を支払う。	成果を直接計測しにくい仕事。E.g. プロジェクトマネージメント	特定領域に秀でたスキルを必要とする場合、タスクコミット型が向いている。 理由: – 秀でたスキルや知識を、時間あたりの金額に換算しにくい – 研究開発のようなことでない限り継続的な仕事がない
タスクコミット型	成果や行動を達成することが仕事。 タスク単位で報酬を支払う。	短期間に成果を出せる仕事。E.g. 難易度の高いアルゴリズムの実装	難易度の低い仕事はタスクコミット型だと報酬が低くなりがちで、悪く言えば安く買い叩く人が出てくる。その場合にはロールコミット型が適している。

プロジェクトマネージメントでも「１スプリント無事に終えたら」のようにタスクコミット型にすることは可能です。プロジェクトの規模や仕事を請ける人のワークスタイルに応じ、同じ仕事内容でもどちらのコミットタイプにするかを選べるものがほとんどです。また「向いていない仕事」に書いたように、仕事の難易度に応じて避けるべきコミットタイプというものもあります。基本的な考え方は「報酬を公正に」です。プロジェクトのコストを抑える矛先が「作る人の報酬」になってしまわないよう、依頼をする側とされる側が Win-Win になるよう心がけています。この視点から、要求される仕事の難易度に応じた適切なコミットタイプを定義しています。

要求スキルレベル	説明	ロールコミット型	タスクコミット型
L1	ITリテラシーを必要とする	◯	△ *非推奨
L2	基礎的なソフトウェア開発のスキルを必要とする	◯	△
L3	応用的なソフトウェア開発のスキルを必要とする	◯	◯
L4	特定領域に秀でたスキルを必要とする	△	◯

ロールコミット型とタスクコミット型のどちらにするかはケースバイケースで、予算や納期、解決したい課題などによって変わってきます。

一般的なウェブアプリケーション開発であれば L2 に定義されるタスクが多く、一部が L1 や L3 のタスクに該当します。L4 が必要となることはあまりありません。どういうケースが L4 が該当するのかというと、例えば100秒かかっている計算処理を1秒にしたいというときや、あと少し精度が高ければ実用レベルなのにそのあとちょっとに到達しないというケースです。

注意していただきたいのは、L4 のスキルを持っている人が L3 の仕事をこなせるということでもありません。普段 L1 の仕事を請けている人がL2 の仕事をすることもあります。これは仕事に要求されるスキルをカテゴライズしたものであり、その仕事にあたる人の能力にラベル付けをするものではありません。

そもそもなぜ「ロールコミット型」と「タスクコミット型」で分けているのかと疑問に思う方もいると思いますので、ここで２つ数字をご紹介します。

1) 日本のフリーランサーは5年で640万人増加

出典:
– Freelance Forward 2022 – https://www.upwork.com/research/freelance-forward-2022
– 新・フリーランス実態調査 2021-2022年版 – https://speakerdeck.com/lancers_pr/xin-huriransushi-tai-diao-cha-2021-2022nian-ban

2) ハイレベル人材を扱う世界のギグエコノミープラットフォームは5年で150社以上増加

出典:
– オンデマンド型の人材プラットフォームをどう活用するか – https://dhbr.diamond.jp/articles/-/7413

こういった背景からも、期間や時間に制約が少ないタスクコミット型な働き方と向き合うことが重要になってきているのです。

Scrum with Gig

Scrum のプラクティス上、一般的には「ロールコミット型」のメンバーで構成されますが、これに「タスクコミット型」の要素が加わっていることが GigAgile のコアメソドロジーである Scrum with Gig (※) の特徴です。

※ 普段は略して「スクラム」と呼んでいます。

基本的には以下のチーム構成が推奨されます。

• プロダクトオーナー
• スクラムマスター (ロールコミット型)
• テックリード / ソフトウェアアーキテクト (ロールコミット型)
• 開発者 / インディビジュアルコントリビューター (タスクコミット型)

レトロスペクティブやスプリントプランニングといったスクラムの各種イベントには通常、プロダクトオーナー、スクラムマスター、そして開発者全員が参加しますが、Scrum with Gig の場合には開発者の代表としてテックリードのみが参加します。また、通常のスクラム開発ではスプリントプランニングに数時間かけて各開発者がプロダクトバックログのタスクを細分化してスプリントバックログを作りますが、Scrum with Gig では、このほぼ全てをテックリードが担うことになります。このままだとテックリードに負荷が集中してしまうことに加え、他の開発者に知識の伝搬がスムーズにできません。このメソドロジーではドキュメントの作り方、他開発者とのコミュニケーションを工夫することでそのデメリットを補えるようになっています。

テックリードが開発者とコミュニケーションを取るために最低限必要なドキュメントは2つあり、
1) 一つはスペック (仕様書) と呼んでいるもので、そこに作りたいモノのほぼ全てが明記されます。
2) もう一つが、タスク (指示書) と呼んでいるもので、適宜テックリードが作成し開発者に渡されます。

タスクはスペックの任意の範囲を切り取り、それを実現するためのインプットとアウトプットが明記されたものです。さらに事前にタスクの内容と金額に合意をすることも大事です。タスクの内容が、いざやってみると実は複雑だったりすることがありますので、それは別タスクとして切り出したり、金額を増やすなど柔軟に対応しています。

今後はスペックやタスクの書き方についてのノウハウも広く公開し、 Gig とソフトウェア開発をする文化を広めていきたいと考えていますので興味のある方は当TC3ブログをウォッチしていただけると嬉しいです。

とはいえ、タスクコミット型の働き方を選択する人たちとソフトウェアを共創していく中で、まだまだ課題があります。例えば、

• 言語、文化、タイムゾーンの違い
• 適切な報酬額を決めるのが難しい
• バラバラな開発者に依頼をすると全体の品質を維持するのが難しい
• コミュニティが成熟しておらずすぐにリーチできる開発者が少ない

ですが、それを差し引いてもありあまる以下のようなメリットがあるのも事実です。

• 開発生産性をニーズに応じて柔軟に変えられる
• 仕様書をしっかり書くと最終的な品質が上がる
• コミュニケーションや報酬に透明性が出てくる
• 世界中の優秀な開発者にリーチできる
• 作れるものの幅が広がる
• 単体でみたときの品質は比較的高い
• 開発速度が早い

依頼者の心得五箇条

最後にテックリード(依頼者)の立場として開発者にタスクを依頼する際の心得五箇条を紹介して終わりにしたいと思います。

1. 性善説に立ち相手と接する
2. マイクロマネジメントは成果を最低にする
3. テックリードであって、マネージャーではない
4. 成果を厳しく評価し、公正に報酬を支払う
5. 期待した成果が出なかったなら依頼者の能力不足と考える

Author: Yuki Sanada