とあるダラスの開発手法 (前編) #Arumon

こんにちは！こんにちは！
Arumon のもりしんと申します。
現在、Dallas (ダラス) のとあるソフトウェア会社にて、マーケティングに関連する自社製品の開発に携わっています。

ダラスに来てかれこれ半年になるのですが、こちらの働き方・開発手法を紹介できればと思い、筆をとった次第です。

私は米国で働くのはこれが初めてなので、記事の内容がこの会社特有のものなのか、米国の大部分に当てはまることなのかは定かではありません。
あしからずご了承下さい。

ダラスってどんなところ

まず最初に、ダラスについて簡単にご紹介します。
テキサス州の北部に位置する米国有数の世界都市であり、経済・金融の中枢として機能しています。
気候は一年を通して比較的暖かい (暑い) です。

ダラスの西側に位置する臨空工業都市 Fort Worth (フォートワース) と合わせて、Dallas-Fort (ダラス・フォートワース複合都市圏) と呼ばれることもあります。
2025年には、Dallas-Fort を結ぶ高速鉄道 Texas Central Railway も開業予定です。

ダラス北西部の郊外には Grapevine (グレイプバイン) という、文字通りワインで有名な街があり、多くのワイナリーやブドウ農園を有しています。
ですので、ダラスは高品質なワインをリーズナブルな価格で楽しめる場所でもあります。

また、これはテキサス全体に言えるかもしれませんが、銃とカウボーイの歴史・文化を色濃く残しています。
もしあなたがダラス (テキサス) に対して、ボリューミーな肉とビールを豪快に摂取するイメージを持っているのであれば、それで大体合っています。(バーで何気なく頼んだビールのアルコール度数が10％もすることもあります)

私が今いるのは、ダラス北部の郊外に位置する Frisco (フリスコ) というところです。
フリスコは元々ベッドタウンとして機能していましたが、近年は大きなショッピングモールができたり、日系企業のヘッドクォーターが移ってきたりと、次世代のビジネス街として発展しつつあります。

ダラス中心のダウンタウンに比べると、フリスコは道が舗装されていてゴミ一つ落ちていないくらい綺麗ですし、銃を突きつけられたこともないので治安も良いと思います。多分。
(誘拐を知らせるアンバーアラートは隔週くらいで鳴り響いていますが...)

ダラスでのアジャイル開発手法

前座はこれくらいにして、さっそく開発手法について書いていきます。
今のプロジェクトでは、いわゆるアジャイル開発と呼ばれる形態でソフトウェア開発を進めています。

【アジャイル開発とは】
アジャイルソフトウェア開発宣言と、その背後にある12の原則に基づく開発手法の総称です。
アジャイル開発を具体的な開発手法・方法論に落とし込んだものとして、スクラムや XP が挙げられます。
アジャイル開発を一言で述べるのは難しいですが、私は「変化を許容し、より良くあろうとしている状態、またはその心意気」と解釈しています。
アジャイル開発とは何ぞやというテーマだけで、一つの記事に収まりきらないくらい長くなってしまうため、詳しい話は割愛させて下さい。

ただ、スクラムや XP (エクストリームプログラミング)、もしくは SAFe といった、一般的によく耳にする手法と異なり、この会社独自のアジャイル開発手法をとっています。
これといった名前はついていないのですが、ここでは便宜上 SQUADS (仮) と呼ぶことにします。

最初に SQUADS の流れを一言で述べておくと「各ロールがスクワッドを組み、開発と QA を繰り返し、スプリントごとにプロダクトをリリースしながら、チームとチケットの見直しを行っていく」となります。
用語の意味が分からないところもあると思うので、次の項目から詳しく説明していきます。

SQUADS のフォーメーション

SQUADS ではプロジェクトリーダーの下、文字通り複数の Squad (スクワッド、分隊、開発チーム) がぶら下がり、並列に開発を進めていきます。
一つのスクワッドの規模は、ピザ二枚を囲える程度の人数 (およそ4～9人) がちょうど良いとされています。
二桁人数になるとちょっと多いな、という印象です。
私が現在関わっているプロジェクトでは、一つのプロダクトを4～5個のサブプロダクトに機能分割し、それぞれのサブプロダクトに対応する形でスクワッドが存在しています。

スクワッドのメンバーには Role (ロール) と呼ばれる役割、職能、専門領域、もしくは責任範囲のようなものが存在します。
詳細は後述しますが、具体的には PO やアンカーといったロールが挙げられます。
各ロールは一つのプロジェクトにフルコミットすることが基本です。
二つのプロジェクトに半々で関わるといったことは、余程のことがない限りはしません。

【ロールの決まり方】
気をつけなければならないのが、ロールは人に紐づくものであり単なる仕事の分担ではないという点です。
言い換えると、例えプロジェクトが変わっても、その人のロールは変わらないということです。
「前のプロジェクトでアンカーだったキミは、次のプロジェクトでは PO をやってくれ」とはなりません。

このあたりは日米の雇用形態の差もあるかもしれませんが、米国では基本的に Job description (ジョブ・ディスクリプション、職務記述書) に沿って雇用契約を結びます。
そのため誰かを雇う際も、そのロールのスペシャリストとして雇うことになります。
「まずは色々経験を積ませて、ある程度何でも出来る人材になってもらおう」というジェネラリスト指向の日本企業とは真逆といえます。

また、ロールにはあまり上下意識がなく、フラットな関係になっています。
「誰が一番偉くて、何かあったときに誰が責任を取るか」という考え方ではなく、「各々の専門領域があり、その領域に対してプライドと責任を持つ」という考え方です。
例えば仮にリーダーと呼ばれる人がいたとしても、あくまでリーダーというロールを担っているのであって、リーダーが全責任をとる偉い人というわけではありません。
もちろん会社組織である以上、ある程度のヒエラルキー (職階) が存在することはありますが、プロジェクトは基本的にホラクラシーな体制で進めていきます。

ここまで説明したフォーメーションについてまとめると、以下の図のようになります。

ここで黒い箱で表しているのがロールとなります。
なんだかよくわからない単語がたくさん出てきました。
では次に、それぞれのロールについて具体的に説明していきます。

PO / Product Owner (プロダクトオーナー)
プロダクトの要件を完全に把握している人であり、ステークホルダーの間を取り持つような存在です。
ステークホルダーの様々な声を吸い上げて、ユーザストーリー (ユーザにとっての価値、プロダクトがユーザに与える効能) **をつくります。
スクラムにおける PO と同じですね。
SQUADS においては、Project lead (プロジェクトリーダー) たる Super PO** と、各スクワッドが担当する要件を把握している Sub PO とに分かれています。
Super PO はプロジェクト全体で1人だけ、Sub PO は各スクワッドに1人だけ存在します。

Anchor (アンカー)
テクニカルマネージャ的な存在であり、tech lead とも呼ばれます。
技術的な雑用がメインで、後述する Dev ロールが何か問題を抱えた場合にヘルパーとして活躍してくれます。
ですがタスクに直接取り組むことはありません。
また、PO が作成したユーザストーリーのタスク化なども行います。
他のアジャイル開発手法ではあまり聞かないので、SQUADS 特有のものではないかと思います。
スクラムにおける SM (スクラムマスター) の役割を技術方面に特化させたロールと言えます。
基本的にはスクワッド内に1人だけ存在します。

PM / Project Manager (プロジェクトマネージャ)
日本企業の一般的な PM のイメージとは異なり、雑用がメインのお仕事です。
アンカーが行う技術的な雑用以外の、汎用的な雑用を全て引き受けてくれる、サーヴァントリーダーのような存在です。
PM は、プロジェクトメンバーが気持ち良く (集中して) 働けるよう工夫を凝らします。
スクラムで言うところの SM に近いロールと言えます。
PM の数は各スクワッドに1人、もしくはプロジェクト全体で1人以上となります。

Dev / Developer (デベロッパー)
そのまま文字通り開発者、エンジニアです。
Dev はタスクチケットを消化していくことに集中・邁進します。
自分で思いついたことがあれば、Dev 自身でチケットを起票することもあります。
Dev の数は各スクワッドにおよそ2～4人です。

QA / Quality Assurance (クオリティアシュアランス)
品質保証担当、テスターです。
Dev がクローズしたチケットをテストして、品質に問題がないかを確認します。
スクワッド内の QA は往々にして、ブラックボックステストしか行いません。
これは品質に対する価値観の違いによるものだと考えています。
すなわち QA が担保するべき品質とは、99.9％のバグを潰すことではなく、ユーザのニーズにマッチしているかどうか――ユーザストーリーの Acceptance Criteria (受け入れ条件) をクリアしているかどうかを確認することです。
従って、ユーザから見えるソフトウェアの振る舞いにのみ注目します。
ホワイトボックステストは、プロジェクト開始時にテスト自動化などの形で仕組みとして組み込んでおくか、テストに特化したスクワッドを別に用意しておく形になります。
このような品質に特化したロールがいるのは、SQUADS ならでの点です。
QA の数は各スクワッドに2～4人、できれば Dev との人数比が 1：1 だと理想的です。

Designer (デザイナー)
UX を設計したり、その UX をもとに UI を設計したりする人です。
プロジェクトによっては UI と UX でロールが別れている場合もあります。
デザイナーはこれまで紹介したロールとは異なり、特定のスクワッド内ではなく、各スクワッドを跨ぐ形で存在します。
プロダクト全体でデザインの一貫性を保つためであると考えられます。

Architect (アーキテクト)
プロダクトのアーキテクチャ＝全体設計を考える人です。
開発に際して、採用するソフトウェアスタックや基盤方針を固めます。
デザイナーと同様、プロダクト全体でアーキテクチャの整合性を保つため、各スクワッドに跨ぐ存在です。

QA lead (クオリティアシュアランスリーダー)
プロジェクト全体の QA を管理・指導する立場の人です。
プロダクトの QA を担保するというより、QA の仕事そのものについて考え、環境をより良くしていくロールです。
QA にとってのアンカーのような存在と言えます。
プロジェクト全体で1人以上存在します。

長々と説明してきましたが、冒頭に掲載した図を再掲します。
PM、デザイナー、アーキテクト、QA リーダーはスクワッド外のロールであるため、Super PO の直属という見方が出来ます。

ここまでの用語説明のおかげで、SQUADS の具体的な開発フローを知るための準備が整いました。
次はいよいよスプリントに沿って、SQUADS で実際にどんなことが行われているかを説明していきます。

...と言いたいところですが、少し長くなってしまったので前後編に分けることにしました。
(決して疲れ果てて眠くなったとかそういうことではありません)

次回をお楽しみに！お楽しみに！

▼Arumon公式サイト
https://www.arumon.net/