開発チームマネジメントについて 202306

この記事は 個人Qiita と同じ内容です

qiita.com/sekiyaeiji

開発チームをどのように運営すればよいか

開発組織を直接的に任される職能名、役割名は各企業の規模やフェーズによりさまざまだと思いますが、EM（エンジニアリングマネージャー）やPO（プロダクトオーナー）、TL（テクリード）やチームリーダー、SM（スクラムマスター）、開発責任者をはじめ、CTOやVPoEも状況に応じて、開発チームを直接的に任される機会はあるでしょう。

開発チームは組織された後、どのように運営されるべきなのでしょうか。

理想のチーム

チーム運営について考察するにあたって、チームが目指すべき状態、理想のチーム像について明らかにしておきます。

タックマンモデル

タックマンモデルとは、ブルース・タックマン（Bruce Wayne Tuckman、 1938–2016、心理学者）が組織の成長の段階を示したもので、組織は以下の4つの段階を経ることによって成長できる理想の組織になるというモデルです。

  1. フォーミング期 （Forming、形成期）
    • 様子見、表面的な関係
    • 否定が少ない
    • とりあえずやってみる
  2. ストーミング期 （Storming、混乱期）
    • ジレンマ、否定的な感情
    • 意見や価値の対立、議論
  3. ノーミング期 （Norming、統一期）
    • ジレンマの解消、規律の明確化、役割や手順の確立、共通理解、共通言語
    • 信頼感が増す
    • チームとして機能し始める
  4. パフォーミング期 （Performing、機能期）
    • チームへの自信
    • 臨機応変、柔軟対応、次の課題へ

チームは大小さまざまのタックマンモデルの機会を繰り返し得ています。
メンバーの増減や組織の方針変更、体制変更、組織目標の変更、プロダクトロードマップの変更、短期間なものではプロジェクトストーリーの1つ1つや1イテレーション、1スプリントに対しても、タックマンモデルの機会が発生します。

ここでマネジメントの採るべきスタンスは、タックマンモデルのプロセスを上手に活用することによりチーム成長の機会を最大化することです。

タックマンモデルでもっとも重要なステップは「ストーミング期」です。メンバー同士の価値観の衝突によりコンフリクトが発生します。これをチーム成長の機会と捉え、メンバー同士のコミュニケーションによる納得解の創造へと導くことが大切です。このときに必要なのは、メンバー同士が尊重し合うことと、前向きなディスカッションを心がけること、心の安全が担保されていることです。そのコンフリクトの中で、安易な妥協を選択せず、対立を超越した止揚（アウフヘーベン、aufheben）による高次元の解を目指すことが、ストーミング期の目標になります。

ストーミング期で発散、収束を経た解を模範解答として、成功・失敗を繰り返した試行錯誤の上でメンバー個々に暗黙知を育てるのがノーミング期です。失敗を含めトライを称賛する風土が必要になります。

パフォーミング期では、個々の暗黙知をチーム共通の認識である形式知に変換し、発散したチームを創造的に再結合することによって、メンバー同士の1+1が3や4になっていることを目指します。安易な仲良し集団ではない真のチームワークの醸成が目標になります。

一方で、形式知は創出されると直ちに陳腐化しますので、パフォーミング期が形成されたときが、新たなフォーミング期へ向かうべきタイミングになります。

現在の不確実性が高く正解のない環境においては、改善のサイクルを継続的に実行することによってチームは成長することができます。これはつまり、停滞することはチームの退化と同義であるということです。

チーム改善の本当の解

現在のマネジメントの文脈で必ず言及される「傾聴」において感じることの一つに、対話のなかで加工コストが高い、あるいは採用するのが困難なアイデア、というものが一定数あります。

  • WILLやゴールが存在しないアイデア
  • HOWを決め打ちしたアイデア
  • 見聴きしたまま受け売りのアイデア
  • 幻影に惑わされたアイデア
  • 他人や外部要因にフォーカスしたアイデア

これら一つ一つへの詳細な言及はここでは割愛しますが、これらに共通して言えることは、いまのチームの現状の生の問題点から自力、あるいは自チームメンバーの力で考え抜いて導き出した課題になっていない、ということです。過去のどこかの価値観やバイアスを通して、それがいまのチームの問題であるかのように感じて持ってきてしまった課題であると感じることが少なくありません。

チームの継続的な改善においては、チームの現在の本質的な問題点に言及し、そこからチーム全員で改善案を導き出し解決に取り組むことによってストーミング期の効果を最大限に活かすことができます。過去や他者の成功事例や価値観は参考にしつつも、自チームの問題は自チームのメンバーにしか深掘り、解決することはできません。

リーン開発、アジャイル開発系の書籍において、解決方法・解決事例に言及しているが解は与えてくれないものがありますが、私はそういう書籍は信頼に足ると思っています。なぜなら、解はチームごとに異なるからです。

チーム運営の実践

笑いの重要性

私がもっとも大切にしている価値観があります。

  • 明るくほがらかに
  • 楽しむ気持ちとユーモアを大切にできる
  • 常にポジティブ

表現はさまざまですが、チームについて論じている情報に多く言及されている、チームコミュニケーションの基本であり極意と感じます。ほがらかな笑いが絶えないチームはさまざまな局面でキャパシティが大きく耐性が高いと感じます。オンラインの音声だけのコミュニケーションが増えた昨今ではなおさらです。先述の通り、メンバー同士のコンフリクトを意識的に創り出す必要がある現状において、常にポジティブであるということはもっとも価値がある行為であり、意識的に実践することが必要です。

メンバー成長への向き合い方

チーム成長を促進する要因の一つに、個々のメンバーの成長があります。

かつて「育成」と表現した行為を現在では「成長支援」と呼ぶそうです。成長は他者からは影響できず、「成長」できるのは本人自身のみだからだそうです。成長支援で実践できることは、環境づくりや課題提案などでしょう。

現在のマネジメントにおいて、メンバーに最も伸ばしてもらいたいスキルは「創造性」と「自律性」です。人は本来自律的に行動できる状態を好む性質があり、自ら主体的に達成した自己実現において強い満足感を得るためです。タックマンモデルによる成長を促進するためにも、開発チームにおいてはメンバー一人一人が楽しむ主体になり、主役になる必要があります。マネジメントの仕事として、チーム成長と同じくらい個々のメンバーの成長支援が重要になります。

チーム成長において目指すべき方向性

以上で述べた通り、チームは成長の過程で発散と結合を繰り返すのが理想の状態です。よって、チームの発散力と結合力が両方とも高い状態において、チームの成長量はより大きくなります。どちらかが低い状態では、チームは硬直しているか、バラバラであり、良好なコンディションとは言えません。これらは、チームメンバーのチームに対する満足度で測ることができそうです。以下にチームの現状を測る指標の例を挙げます。

  • チームのユーザー価値提供に対する満足度
  • チームのアウトプットに対する満足度
  • チーム自体に対する満足度

たとえばこれらの向上を目指すことによって、チーム成長の状態を把握することができるかもしれません。

まとめ

あらゆることに正解が見えない現在、プロダクトやチームが大切にすべき価値や解決したい問題について、外から何かを提示してくれることは期待できないと腹を括って、自らの脳をフル回転して指標を設定したり方針を決定すると考えると、タスクは増加するかもしれませんが気持ち的には楽になります。メンバーと自分を信じ、勇気をもって進んでいきましょう。

DynamoDB Toolbox v 1.0 beta がでたので触ってみた

この記事は個人ブログと同じ内容です

DynamoDB Toolbox v 1.0 beta がでたので触ってみた

はじめに

こんにちは、back checkで SWE をしているぐっきーです。 最近 back check ではプロダクトの一角で DynamoDB を使い始めました。 DynamoDB 周りの使用技術としては主に Marshaling 目的で DynamoDBDocumentClient を、 Entity の定義と API パラメータの作成に DynamoDB Toolbox を使っています。

DynamoDBDocumentClient: DynamoDB とやりとりするデータは DynamoDB JSON という、primitive 型を含めた独自の JSON 形式で行われるため、これと可読性の高い一般的なデータ構造の JSON フォーマットと変換する役割。

DynamoDB Toolbox: Entity を DynamoDB の（主にシングルテーブルを想定）テーブルにマッピングしたり、Entity のスキーマに沿った API パラメータを作成してくれる役割。ただし型のサポートがいまいち行き届いていない部分があり、便利だけど改善してほしい部分もあるという温度感のツール。

そんなタイムリーなタイミングで DynamoDB Toolbox の v1.0.0 beta がリリースされたという記事を発見したので今回はどのような変更があったのか触ってみます。

結論

このブログにも書いてあるが、まだtransaction系だったりscanなどのAPIがサポートされていないこともあり、プロダクトで使うにはこれらのAPIが実装されてからアップデートを行った方がよさそうに思った。 個人的にはMapなどの内部まで型が適用できることによるポリモーフィズムの型推論が可能になったことなどポジティブな影響は大きく、latestとしてリリースされることが楽しみです。 今後の動向を要チェックといったところですね。

主な変更内容

  • 型の対応範囲が広がった。
  • betaで提供されるAPIはツリーシェイキングが効果的に行われるように書き直されているため、それぞれV2のAPIを利用することで軽量になる。
  • TableとEntityクラスのIFが大きく変更されたことにより、より型安全なコマンドやEntityを作成することができるようになった。
  • 既存のDynamoDBのデータ構造を保ちながらbeta版のAPIを利用することができる。
    • 0系から beta へアップデートの際に migration は必要

具体的にはこちら The DynamoDB-Toolbox v1 beta is here 🙌 All you need to know! の記事にて詳細な変更内容が掲載されているので割愛します。

dev.to

触ってみた

先にコードをみたいという方はこちら

github.com

今回大きな変更のあった箇所を中心に触ってみました。

TableV2 クラス

まずは TableV2 クラス。（旧Tableクラス）

主な変更点としては、partitionKey, sortKey が今まで文字列を直接指定するのみだったことに対して、v1.0.0 beta の変更では partitionKey, sortKey にプリミティブ型を指定することができるようになりました。

// v1.0.0 beta
const TableA = new TableV2({
  documentClient: DynamoDBDocumentClient.from(new DynamoDBClient({})),
  name: 'tableA',
  partitionKey: {
    name: 'pk',
    type: 'string',
  },
  sortKey:  {
    name: 'sk',
    type: 'string',
  },
})

// v0.8.5
const TableA = new Table({  
  indexes: {  
    GSI1: { partitionKey: 'gsi1pk', sortKey: 'gsi1sk' },  
  },  
  name: 'tableA',  
  partitionKey: 'pk',  
  sortKey: 'sk',  
})

懸念点として今まで Global Secondury Index の設定などをTable の indexes オプションで行っていたのですが、indexes がなくなったことでどのように GSI を指定するのかわからなくなりました。（もしかしたらそもそもの使い方が間違っていた可能性はありますが）

EntityV2 クラス

次に EntityV2 クラス。（旧Entityクラス） 大きな変更としては今まで attributes として定義していたスキーマが、schema メソッドに置き換わりました。

export const TableAEntity = new EntityV2({  
  name: "TableAEntity",  
  schema: schema({
    pk: string().key(),  
    sk: string().key(),
  }),  
  table: TableA,
})

また、timestamps オプションを設定することで作成、変更の日時を任意の名前で管理できるようになりました。

export const Entity = new EntityV2({
  ...schema,
  timestamps: {  
    created: {
      name: 'creationDate',
      savedAs: '__createdAt__',
    },
    modified: {
      name: 'lastModificationDate',
      savedAs: '__lastMod__',
    },
  }
})

Attributes の型

全部は紹介しませんが、Attributes の型の設定の仕方に大きく変更がありました。

number 型

schema: schema({
    // number
    age: number(),
})

string 型

schema: schema({
    // string
    email: string(),
})

PrimaryKey の指定 (string)

schema: schema({
    // PrimaryKey
    pk: string().key(),
})

enum

schema: schema({
    // type gender = 'male' as const | 'female' as const | 'other' as const
    gender: string().enum('male', 'female', 'other'),
})

list

schema: schema({
    /*  
    * skillsByList: string[]  
    */  
    skillsByList: list(string()),
})

map

schema: schema({
    /*  
    * skillsByMap: {  
    *   karate: '白帯' | '茶帯' | '黒帯',  
    *   kendo: '初段' | '二段' | '三段',  
    * }  
    */  
    skillsByMap: map({  
        karate: string().enum('白帯', '茶帯', '黒帯'),  
        kendo: string().enum('初段', '二段', '三段'),  
    }),
})

record<any, any>

schema: schema({
    // Record<string, string>  
    skillsByRecord: record(string(), string()),
})

set

schema: schema({
    // Set<string>  
    skillsBySet: set(string()),
})

anyOf

schema: schema({
    /*  
    * job: {  
    *   type: 'engineer',  
    * } | {  
    *   licenseStartDate: string,  
    *   type: 'doctor',  
    * }  
    */  
    job: anyOf([  
        map({  
            type: string().const('engineer'),  
        }),  
        map({  
            licenseStartDate: string().required(),  
            type: string().const('doctor'),  
        })  
    ]),
})

any

schema: schema({
    // any
    metadata: any(),
})

Commands

各コマンドにも専用のクラスが用意されました。 尚、前述しましたが現時点でサポートされているのは Put, Get, Delete のみでありその他のコマンドについては今後実装していく予定とのことです。

PutItemCommand

const dummyData = {  
    age: 30,  
    email: 'example@example.com',  
    gender: 'male' as const,  
    job: {  
        type: 'engineer' as const,  
    },  
    name: 'John Doe',  
    pk: 'user_123',  
    sk: 'profile',  
    skillsByList: ['JavaScript', 'Python', 'SQL'],  
    skillsByMap: {  
        karate: '黒帯' as const,  
        kendo: '初段' as const,  
    },  
    skillsByRecord: {  
        framework: 'React',  
        language: 'English',  
    },  
    skillsBySet: new Set<string>(['Guitar', 'Singing']),  
};  
  
export const putCommand = async (): Promise<void> => {  
    await TableAEntity.build(PutItemCommand).item(dummyData).options({  
        condition: {  
            attr: 'pk',  
            exists: false,  
        }  
    }).send();  
}

GetItemCommand

export const getCommand = async (primaryKey: PrimaryKey<typeof TableA>): Promise<string> => {  
    const { pk, sk } = primaryKey  
    const { Item } = await TableAEntity.build(GetItemCommand).key({ pk, sk }).send();  
      
    if (Item === undefined) {  
        throw new Error('Item is not found')  
    }  
      
    if (Item.job.type === 'doctor') {  
        return `${Item.name} is a doctor. License start date is ${Item.job.licenseStartDate}`  
    }  
      
    return `${Item.name} is a ${Item.job.type}`  
}

DeleteItemCommand

export const deleteCommand = async (primaryKey: PrimaryKey<typeof TableA>): Promise<void> => {  
    const { pk, sk } = primaryKey  
    await TableAEntity.build(DeleteItemCommand).key({ pk, sk }).send();  
}

Thanks

DynamoDB のサンプルコードのベースをお借りした mukaihajime さん、ありがとうございました！

参考資料

苦しいペアプロに苦しむ話

この記事は個人ブログと同じ内容です

note.com

こんにちは、株式会社ROXXの agent bankでスクラムマスターをやっている坂本です。
うちのチームはペアで作業をするというのを頻繁に行っています。
その中で、メンバーの様子を見ていたり話を聞いている中で感じた（または直接聞いていたかもしれない）ので、ペアプロ（もしくはペア作業）の苦しみを書いてみます。

その前に注意事項

  1. 具体的なやり方・メリットの解説はそんなに本気でやりません。
  2. ここで出てくる苦しみは、うちのチームで起きていて感じた事です。他の人からすると別に苦しくないことかもしれないです。だけど、「その苦しみわかる〜」と盛り上がってくれると嬉しいです。
  3. ここで取り上げる課題に対しては絶賛取り組み中でまだまだ試行錯誤してます。「まだ試してないけどね」なことも書きます。

まずはペアプロの良いところから

まずメリット書かないと暗い悲しい記事になっちゃいますね。

ペアプロのメリットはあります！
うちのチームで自覚できていることとしては以下があるのかなと思います。

  • 早い段階での検査を行えること

  • 知識を集合させて困難に立ち向かえる

  • 知見を共有しあえる

  • 楽しい

軽く補足していきます

早い段階での検査を行えること

特に、難しい課題やタスクや考える要素が多い時に、完了したと思って成果物を共有したりしてレビューをもらったら「あれ？全然見当違いのことやってない？」みたいなことが発生することありますよね。あれを複数人で対応することで、より早くに検知して軌道修正できています。

または、ハマってしまった際にペア内で助け合って解決したり、限界に早めに気づいてペアの外に助けを求めよう！という会話を生むみたいなこともおきています。

知識を集合させて困難に立ち向かっている

人によって知識の差があることは当たり前だと思います。業務知識であったり、技術的な知識だったり、他にもいろいろあるかと思うんですが、得意不得意、知ってる知らないをお互いに補うことで、一人では解決できないことを解決していくよ！みたいな感じですね。

知見を共有しあえる

若干ひとつ前のものと被ってるとこあるかもですが、人によって詳しい部分得意な部分を補ったり、複数の視点から見ることでわかる気づきをお互いに共有しあって、チーム内の知見の偏りを減らしていきます。
これにより、過度な属人化が減りチームとしてできることも増えていきますね。

楽しい

うまくいっている時はこれを感じます。やり取りの中で生まれる新しいアイデアや気づきが生まれるなどして、一人では体験できないような、動きができてい時に感じるんでしょうね。コラボレーション！！
毎回これを感じれるようになりたい。

こんな風にペアプロを苦しんでた

では逆に、苦しんでいる時って何が起きてるんでしょう？

様子を見ていたり、話を聞いた感じでは、一般的にペアプロと呼ばれるものとは違う何かをやっていたり、ペアプロのアンチパターンと呼ばれるものを踏んでいたってことなのかなと思います。

  • ドライバー、ナビゲーターの交代がない

  • ペア同士のスキル差、知識差が大きすぎる

  • ペアの方針の合意がないままになんとなく進んでいる

ひとつづつ簡単に補足していきます。

ドライバー、ナビゲーターの交代がない

ペアプロってめっちゃ集中します。ペアプロに関する記事を見て回ったんですが、大体どこも「6時間が限界」とか「終わる頃にはヘトヘト」などと書かれています。実際にメンバーのからもそんな感じのことを聞きます。

ヘトヘトになるのは、当たり前だろうし悪いことではないと思います。しかし、実際に起きていた（又は、現在進行形で起きている）ことは、「長時間役割の交代をしないまま続けていることによる疲労」のようでした。

具体的にどういうことかというと、一般的には役割と定期的にスイッチしましょう（所によっては10分とか短いスパンでの交代）と言われているところを、NO交代で2-3時間以上進んでいることがたまにある。そして、集中しての疲労を超えた先の何か別の疲労が生まれている。

定期的なスイッチで何を期待しているのかというと、視点をかえるだとか、気分転換とか、リズムを作るとか色々ありますよね。どうしても役割によって思考やできることが固定されちゃうっていうのがあるので、それをリフレッシュするためにやるのかなと思います。それが抜けることで、結構つらい状態になっていました。

  • 視点の切り替えができないので、ハマっても抜け出せない。

  • そもそも、ハマっていることに気づけない。

  • 集中が途切れて、お互いに役割を果たせない。

  • なんだか、ただただ長時間監視されながらの作業になりプレッシャーが残るだけ。

原因としては、リモートでの作業のために、頻繁にスイッチすることへのハードルがあるとか、集中していたら交代することを忘れていたとか、もう少しで終わりそうなので継続をしていたら、結局1-2時間そのままとか…やばいなんだか色々ありそうですね。

なんにせよ、定期的にスイッチできていないこと自体に別の問題がありそうなのと、スイッチできていないことによりまた問題が生まれているっていうのはあるみたいです。

ペア同士のスキル差、知識差が大きすぎる

最初に断ると、この要素だけでは特に問題ではなかったかもしれないです。「ペア同士のスキル差、知識差が大きすぎるけど、ペア内に差があることをちゃんと認めれきれてなくて、ペアの動きに反映できてなかった」がここで言いたい苦しみかもしれないです。

最近、チームにメンバーが新しく入ってくる機会が何度かあったので特にチームからでていた問題です。
ペアプロする際に、同じぐらいのレベル感の人同士でやっていく分には今までそれほど問題はありませんでした。しかし、ギャップがあるペアを組んだ際に初心者の方がプレッシャーやできないことをとても感じてつらいと感じたり、熟練者側も教育・指導的な負担が大きくてつらいみたいなことがあっていました。

もう少し具体的にしてみます。ギャップが少なく同じくらいの場合は、漫才の掛け合いをするごとくお互いに発言しあって、作業を進めていき結果として学び合う高め合うような状態になることが多いです。逆にギャップが開いていると、初心者の方がなかなか意見が言えない、聞くばっかりになってしまう。また、熟練者から意見を求められても瞬時には出せないのでプレッシャーになってしまう。こんなふうに初心者すぐに答えを出すことが難しい話題に対して、息をつく間も無く「これはどう思う？」「これは？」「これは？」と出題が続き、つらい…ってなっちゃう。

実はこれ、今熟練者としてペアに入っている人も自身が入りたてのときに感じてたことだったらしい。さらにつらいことが、チームとして解決につなげることができずに、毎回気合いで乗り越えてしまったので、またこうして課題が出てきてしまっていることですね。

もしかすると、ギャップがあっても、なるべく速度を落とさず、熟練ペアのように進まなければいけないみたいな意識があったのかもしれないです。

あと、初心者が何もできないうちに熟練者が進めていって自信が持てないとか、個人としての達成感が持てないみたいな話もありました

speakerdeck.com

同じようなことを（モブプロの話ですが、）抱えているチームも他にもいるみたいですね。ここら辺はチームとして共通認識を作っていって「チームとしての成果」と感じれるようになっていけるといいなあ。

ペアの方針の合意がないままになんとなく進んでいる

前の二つにつも通じることかもしれないんですが、割とペアでの作業をはじめるときに何となく初めていることが多いです。

そのため、作業のゴールに向かうまでの方針がないままの二人で手探りをずっと続けていたりだとか、一方はどうすればいいか知っているけど一方は目隠しの状態みたいなつらい状態が起きることもありました。

ペアとしての振る舞いに関しても合意が取れてないので、スキル差、知識差のある状態の際に、初心者側がペアプロにどう参加したらいいのかわからず進むみたいなこともあったみたいです。

苦しみ考察

苦しみを並べてみて思ったのは、これって結構3つ全て紐付いて起きているのかもしれない？
ペアの中で失敗しても良い雰囲気作りができてなかったため、苦しみが生まれていたのかもしれない。スキルや知識の差があるけれど、お互い合意を取れてないので、自分が変なことやっちゃったらどうしよう。ペアの進捗を遅めちゃうなぁ、プレッシャーだ…。しかも（交代がないので）このまま失敗し続けたらどうしよう…しんどい…。タスケテ…

ああ、助かりたい！

苦しみから解放されたい

こうすればいいのかな？こんなこと試してみてるよ？を書いていきます。

ドライバー・ナビゲーターは交代しよう

「でも…」も「だって…」も許さず、一定時間経ったら絶対交代する！っていうのを徹底するしかなさそう！そのためにもペアを作ったときに、「じゃあ〇〇分経ったら交代しようぜ」みたいな合意をするとか、そもそもチームとして30とか15分経ったらスイッチしなければならないみたいなのを定めるとかやってもいいのかもしれない。

他社でアジャイルをやってる方にこの悩みを相談した時に、お聞きした実際にやってるプラクティスは、モブでやっている時の交代は銅鑼を鳴らして強制的に交代させるっていうものだった。徹底ですね。
有無を言わせず交代。無理矢理交代していくうちにありがたみが分かってくるぞ？ってことかな。

ちなみに、短い交代がうまくいってないことばっかりではなく、これまでも何だかペアうまく進めてるな！みたいな時は、自発的にそろそろ交代しようかとか交代させて！とかやり取りしつつ、時間や作業の区切りで数十分単位で交代を繰り返していました。今だってできてる時はできてる。ついつい忘れちゃって〜ってときがたまにあって、それがあると苦しみが生まれがちなのです。

スキル差があっても「あと数分経ったら交代するんだし思い切りやるぞ！」ってなると良いなあ。（ナビゲーターも、ドライバーもどちらもね）

あ、あと休憩もちゃんと取る。

ペアで進め方の方針を決めて進める

ペアプロではちょうど、役割の名前をナビゲーターとドライバーという運転に例えた表現をしているので、運転を始める前にペアの中で地図の共通認識を持ってどのゴールに向かうので、この道筋が良さそうだねみたいな会話ができるといいんでしょうね。（前任のスクラムマスターの受け売り）

また、役割ごとにどう振る舞うとか、初心者、熟練者としてどうペアプロに参加するみたいな認識も合わせると、より発言しやすくなるかもしれない。チームとしてペアプロのルール・約束的なものの認識がぼやけているような気もするので、ちょっと整理したい気持ちが出てきた….やりたい。

ペアでの決め事決めて進めるみたいなのでいうと、ふりかえりとかで定期的に上がってくるのが、実装開始前にmiro(オンラインホワイトボードツール)で、ざっくりの実装方針や、設計的なものを整理した上で始めると、めっちゃよかったみたいな事がある。これが習慣化してきたりすると最高だ。

（書いてみたら「ペアとしてどう振る舞う？」と「ペアがこのタスクをどう進んでいく？」の認識合わせるの2軸の話が混じってるような気もするけど、まあよし）

ソロを増やしてみる

とりあえずペアで進めるのを、一回やめてみるですね。

「大事なことは無くなってから初めて気づく」とか言ったりするし、うまくできてなくてつらい、糸口がわからないであれば、一旦全体としてペアプロ廃止にしてみるトライをやってみてもいいのかもしれない。（極端にやるとしたらね）

本当に必要ならまた再開しようぜ！という声が上がるだろうし、出てこないのならチームがそういう状態じゃないのかもしれない。（とはいえ、ペアプロはやってほしいので、うまく機能するようにサポートしたい）

極端に全部やめてみるっていうのはまだ試してみてはいないんですが、チームのアクションとして、ペアじゃなくても良さそうと判断できるものは、ソロでも進めても良いっていうのをやっています。実際にやるべきことがシンプルでかっちり固まっている系のタスクだったり、ちょっと時間をとって探索する系の調査タスクだったりソロで進める方が結果的にもよかったという声が出ています。あと印象的だったのが、「ちょっとこれはペアじゃないと不安」みたいな感じで、ペアの効果の再認識みたいなことも起きるようになっています。

他には、今はペアプロの選択肢の他にバディプログラミング的なものも実施してみている。レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス に載っているらしい。それを少しカスタマイズしたやり方で、バディ（二人組）でタスクの初めにお互いのやることを確認→分散してそれぞれ並行作業→一定時間（1hくらい）経ったら合流して報告し合うみたいな進め方を初めてみた。ギャップがある状態での、プレッシャーからは解放され、初心者は限られたタイムボックスの中で自分のペースで集中して探索を行うことができる。
（実際にやってどうだったかはもう少し試してみて記事に書けると良いなあ…）

最後に

今回書いた以外にもまだ認識していなかったり、書き漏れている苦しみもあるかもしれません。そこについても、日々の活動や定期的なふりかえりでチームとして認識して、良くしていけるといいなとおもいます。トライについても多分もっとやれること、やった方がいいことがあるでしょう！

取り組む話題や、人によって複数人でやる方が良いとか、一人で進める方が良いとか色々あるかとは思います。
ただ個人的には、チームで進めることによって一人ではできないこと達成できるみたいなことにとても喜びを感じるし、実際にそんな体験をしてきていると思うので、これからもチームがチームとして成果を出せるように精一杯働いていきたいなと思った。

あとは個人的にチームでモブプロやりたい欲が芽生えてきているのでここにもトライしたい。

「データドリブンな組織を目指す」？ データ基盤が整ってきたら、データを使うカルチャーができてきた

PdM

この記事は個人ブログと同じ内容です

note.com

---

こんにちは、株式会社ROXXでagent bankのプロダクトマネージャーをしている粕谷です。
最近、社内のデータ基盤が整ってきて、組織内でデータ活用が進んだように感じているので、ここに至るまでのデータ活用の状況を振り返ってみました。

以前はデータを活用できる人が限られていた

agent bankは、人材紹介会社様と求人企業様をつなぐ人材紹介のプラットフォームです。このプラットフォームには、月間1万件を超える選考情報が蓄積されています。
私がROXXにジョインしたときにはすでに、BIツールが導入されていて、SQLが書ければプラットフォームの数字を分析できる環境がありました。ただ、データガバナンスの責任者がいたわけではなかったので、欲しいデータにたどり着くのが難しかったり、一度CSVで落としてからデータを加工する必要があったりと、手間がかかっていました。セールスやCSが日常的にデータを活用するには、少しハードルが高かったと思います。

当時の課題

  • 作成されたクエリが散在していて探すのが難しい

  • 重要な指標でもクエリを書いた人によってフィールド名や計算ロジックに表記揺れがある

  • ちょっと見てみたいだけという理由では、エンジニアにクエリの作成を依頼するのは難しい

  • CSVを出力してから、手元で加工することが多い（時間のかかるルーティン作業があったりする）

課題がある一方で、もっとデータを活かす余地があるという期待もありました。
当時、しばらく自分でデータ分析をしてみたことで実感したのが、データをいくら眺めても、それだけではお客様に何が起きているか想像できないということです。それがCSチームにデータの読み解きをお願いすると、お客様の現状を踏まえて、数値から推測される課題をリアルに説明してくれるのです。
定量データは、定性データやドメイン知識があってこそ、活かすことができる。だからデータに気軽にアクセスできるようになれば、CSやセールスはもっとデータからインサイトを得られるのではないかと思っていました。

最初は、手間を減らしたかっただけ

そうは言っても、最初から「データドリブンな組織を目指そう」みたいな明確な目標があったわけではありませんでした。前述の通り、データ分析のために、CSVを出力して加工する作業を行っていたので、自分のルーティンワークを無くす方法を考えていました。
そんな折、BigQueryの導入が進んで、分析用のデータを試しにGoogle Data Portal（現LookerStudio）に繋いでもらえることになりました。このとき作ってもらった仕組みが、いまではヘビーユースされているダッシュボードの基礎になっています。
プラットフォームの基本的な数字が可視化されて、いつでもLookerStudioでレポートとして見れるようになり、ついでに重要指標の名前と計算式を統一することができました。使えるデータは限られていましたが、CSVを加工する作業から解放されたので、個人的な最初の目標は達成です。

ツールがいきなり浸透するわけではない

LookerStudioはデータソースさえ揃っていれば、非エンジニアでもUIを自由に編集できて、目的に応じたレポートを作れるのでとても便利です。
とはいえ、せっかく環境が整ってきても、いきなり誰もが自由に使い始めるようにはならないのが現実でした。
データ分析の専任を置くのは人員リソース的に難しかったのと、誰でも自由に使ってほしいという思惑もあったので、まずは誰でも触れる状態を目指して、LookerStudioの操作方法と、利用可能なデータソースについて説明会を実施してみました。
認知は進んだかもしれませんが、正直なところ活用の促進にはそれほど効果はなかったと思っています。

行動変容につながるデータかどうか

データ基盤の拡充の一環で、提供できる分析レポートも増やしていったのですが、分析レポートを作る過程でひとつ気をつけていたのは、「レポートから得られるインサイトが、見た人の行動に影響するか」という点です。プロダクトのさまざまな数字が可視化されても、それだけではわざわざデータを見に行く理由になりません。
レポートを作れる環境が整ってからは、CSのキーパーソンに、どのようなデータが見れたらお客様の課題を理解するのに役立つか、ヒアリングをしながらレポートを作っていきました。
数値に基づいて現状を把握し、何が起きているか、何故それが起きているかをお客様と話し合い、改善策が決められたら、一定期間が経過してから結果を数値で確認する。作ったレポートを実際に使ってもらいつつ、フィードバックをもとにブラッシュアップして「使えるデータ」を整えていきました。
プラットフォームのレポートが充実してきたのは、示唆を与えてくれた方々のおかげです。

インパクトが実感されると、データの価値が認められる

必要に迫られないと、新しいツールを触るきっかけがないことも往々にしてあると思います。
おそらく一番早い段階でLookerStudioを使ってもらうことが多かったのはCSチームでした。例えば、お客様との会議の準備では、以前なら情報を集めて加工していたような時間が無くなって、分析に時間を使ってもらえるようになりました。そして、（データの有無は要因のひとつでしかありませんが）お客様の課題により深く具体的に切り込めるようになり、コンサルティングの質にも明らかな変化がありました。
その頃には、CSチーム内でデータの積極活用が呼びかけられるようになり、気がつけば日常的にデータを参照することがあたりまえになってきました。

誰にとっても使いやすい状態を維持するために、一定のガバナンスはあった方が良いと思っています。PMチームでは継続して、アクセシビリティをなるべく担保できるように整備したり、組織内で用やロジックを統一したり、データ利用に関するルールを定めたりしています。
しかし、データ基盤さえ整備されていけば、データ活用によって明らかな実績が認められたときに、データ活用が自然と組織レベルに広がっていくのではないかと感じました。

余談：開発チームにデータの価値をフィードバックする

これまでデータソースの作成は、すべて開発チームにお願いしています。
開発チームには、依頼の背景や目的を伝えたうえで、データテーブルの設計から参加してもらっています。
しかし、一度リリースされてしまえば、データを作る人と使う人の関係はそこで途切れがちで、どのように使われているか、どのようなインパクトをもたらしたか、詳細なフィードバックをする場はなかなかありません。いつもデータを作ってくれている開発チームに、感謝はお伝えしているつもりなのですが、作ってもらったデータの価値は全然伝えられていない気がしていました。
とにかくすごいんです！と主張するだけでは語彙力不足なので、事業部にお願いして、アンケート形式で実際にフィードバックを募ってみました。

・意思決定がスピードアップした
・データに基づいた会話や意思決定が日頃からなされている
・業務工数削減ができた（最大2-3時間/日の削減になったという回答も）

（アンケート回答の一部を要約）

開発チームへのフィードバックを目的としたアンケートでしたが、全体として、データドリブンな意思決定が増えてきているように感じました。

振り返ってみると、もっと戦略的に「データドリブンな組織を目指す」道はあったような気がしますが、結果的にこの一年で大きくデータ活用に関する状況が変わってきました。
ここまで環境を整えてくれた開発チームと、データ活用に示唆を与えてくれた方々に感謝しつつ、今後の組織におけるデータ活用を考えていきたいと思います。

クリエイティブなものに触れてきた【2023年上半期】

デザイン

 

こんにちは
株式会社ROXXでback checkのプロダクトデザイナーをやってる青野です。

 

コロナが落ち着きつつあり、おかげで外に出かけられる機会も増えてきました。

6月が終わるタイミングで、2023年の上半期に出会えたクリエイティブな体験を、時系列にふり返っていきます。

 

 

 

1月：Dior展

artexhibition.jp

連日すごい混雑していた展覧会。予約は諦めて（友人が）開館前に並ぶことでチケットがとれ、観ることができました。
ドレスの美しさもさることながら、展示空間も圧巻で楽しかったです。

「ディオールのドレスは動きが計算されているから」ということで、バレリーナにドレスを着せ、踊ってるときの残像を表現した写真が一番印象的でした。
ハイブランドのドレスは、セレブとモデルだけの服だと思っていましたが、ダンサーも対象になれるんだという発見ができてよかったです。

 

 

 

2月：洞窟のレストラン「メゾン・アウル」

maison-owl.com

山口県 宇部市にある、創作フレンチのレストランです。2月にして2023年のハイライトを迎えてしまいました。

美容院で建築を紹介する雑誌（住宅特集、GA JAPAN）を読んで、このレストランの存在を知りました。レストランに行くと、この洞窟ができていく制作過程を映像で見せてもらえます。

美味しい料理とロウソクの明かりだけの空間に、人類最古のクリエイティブである 洞窟壁画や、「最後の晩餐」に描かれるワインとパンに思いを馳せたりしました。壮大な気持ちになりたい方におすすめ！

 

 

 

2月：福岡アイランドシティ

ic-centralpark.jp

先述のレストランに続くかたちで、福岡へ。伊東豊雄の建築があるということで行ってきました。

ラピュタみたいな雰囲気で、建物の汚れもジブリみがありました。館内は人が少なくて落ち着いています。本を読んでくつろいでる人がいて、地元にこういう空間あるの羨ましいなと思いました。

天窓がいくつかあり、奥には植物がある建物内の空間

伊藤豊雄 建築の特徴は曲線と柱がないこと

 

 

 

4月：ケリス・ウィン・エヴァンス展

bijutsutecho.com

あの、和紙の照明で有名なイサム・ノグチが作った空間です。作品が合っていておしゃれなコラボレーションになっていました。

この展覧会は終わってますが、石庭はいつでも体験できると思うので、ぜひ行ってみてください。石でできた空間を “石庭「天国」”っていうセンスすごい。どんな哲学をもとに作ったんだろう

 

 

 

4月：ヘザウィックススタジオ展

www.artagenda.jp

これは「海外旅行したい」という気持ちになる展示でした。めちゃくちゃ海外に行きたい。国がアートやデザインに理解があると、こうも面白そうなプロジェクトが生まれるんだな〜。

交通などのインフラの整備、文化の継承、廃棄物への配慮、すべてにはデザインやアートが必要なんだ、というのが分かりやすく事例で紹介されている展示でした。

ロンドンオリンピック聖火台のプロジェクトをみて、東京オリンピックの開会式を思い出してしまい、胸がチクチクしました。笑

 

 

 

5月：跳躍するつくり手たち展

www.tokyoartbeat.com

足の捻挫が治ってないのに京都へ。このせいで完治まで長引きました。

京都ほど古さと新しさが共存してる街はない、クリエイターたちのサバイブに思いを馳せられる、ということで京セラ美術館での開催に意味があったようです。

どうしてもこの展示が見に行きたかったのは、セクション構成の言葉が身近な感じがして面白そうだったからです。

展覧会のセクション構成
1.　ダイアローグ：⼤地との対話からのはじまり
2.　インサイト：思索から生まれ出るもの
3.　ラボラトリー：100年前と100年後をつなぎ、問う
4.　リサーチ＆メッセージ：未来を探るつくり手の現在進行形

伝統工芸を守りながら次なる表現を模索していたり、今までの価値観を問うような作品があって刺激になりました。

 

 

 

6月：Design Matters Tokyo 23

note.com

オンラインですが、デザインイベントにも参加しました。

テーマは、AIとの共創、インクルーシブ、持続可能性、アクセシビリティといったもので、今聞きたかった内容ばかりでした！

上記noteに、各セッションの内容を簡単にまとめています。

 

 

 

 

以上、上半期で体験してきたことです。

コロナ禍で我慢した反動もあり、いろんなとこに行ったな〜。旅行いくと自己肯定感があがる気がする。

 

最後に

ROXXでは「時代の転換点をつくる」というミッションのもと、一緒に取りくんでいけるデザイナーを募集しています！

気になった方はカジュアル面談でも、気軽にお話しましょう〜〜！

 

🎉ab_dev入場エントリ🎉 〜チーム開発を知る！〜

はじめまして

はじめまして。鈴木といいます！4月より業務委託でROXXのab_devチームに参加しているエンジニアです。
agent bankの開発や保守などをしております。
今年で社会人7年目、性格はワクワクしたい冒険家タイプ...ですかね？

最近は4年くらいかけてやっとリリースされたブループロトコルをずっとやってます。アステルリーズで僕と握手！

ブログ記事なんて高校生以来なので緊張してます。お手柔らかに〜。

経歴

ざっくりと順番を最初に出しますと
大手会社内のセキュリティ部署、ベンチャー、SES、一人での業務委託、ROXX（いまここ）
です。

セキュリティ部署在籍中は学習がメインで、基本・応用情報に出る内容ではあるものの実際のシステムとのつながりを考えながら学んでいきました。 しかし学習ばかりのためにマンネリ気味に（3年は経過するまでシステム触れないとのこと）。
その折ベンチャーに誘われる機会があり、PGからやった方が身につくと考えそちらでモリモリ開発。DockerやGoを初めて触りエンジニアリング最高！な気分に
その後体力不足で体を壊しかけたあと、エージェント会社経由でSESに。三年Laravelと過ごしながら顧客折衝、設計、実装、リリースまで全部を担当。新卒育成も行い力をつけていきました。
SESもやれることは楽しかったのです。が、今後の昇給テーブルと自分がどうなりたいかを考えたところ、少なくともここは違うと考えて離脱しました。
その後最初の業務委託は、フルリモートのチーム開発と思っていたら、実は一人開発となってしまって合わずに離脱といった形です。

こう見ると結構転々してますね。何をなしたかと言われると輝かしいものがあると言えない経歴で恥ずかしい。
ただ、働いてる中でエンジニアリングに限らず新しいことに挑戦していたのは良かったのかなと思います。

入社理由

出会い自体はROXXからのオファーでした。
夢中になった理由は、エンジニアが働きやすい仕組みがほぼ全部盛りで整っていたからですね！

ROXXに入る前に自分を見直すと、少なくとも一人食べていくには十分なスキルが身についていました。
その上で何がほしいかと言われると、収入もそうですが今後へ向けての成長や働く気持ちよさかなと思っていました。前職、前前職でモヤモヤしてたためです。
特にチームについては今まで理想的な開発チームに所属したことがなく、運用が整っているチームに入ってみたいと考えてました。

そう思ってた矢先、ROXXからオファー詳細が来たときには衝撃を受けたことを覚えています。 以下原文ほぼそのままです。

フルリモート
基本はdiscordを繋げて適宜コミュニケーションを取りながら進めていくスタイル
フロント、バック両方対応をお願いする想定で、アジャイルで勧めていただきます

でぃ、discord〜〜〜！？！？！？え、常時通話〜〜！？？！？！ アジャイル〜〜！！？！？

お恥ずかしながら前職のフルリモートで誰かに見られてないと中々パフォーマンス出して働けないダメ人間と気づきまして...。
常時通話は一回チャレンジしてみたいと思ってました。 また手探りでアジャイル開発を少しやったことはあるものの、これもまた全力でできてなかったモノであります。ますます興味あり。

そこから会社としてのROXXを調べ、事業を調べ、今も絶賛夢中になっております！Love！！

ROXX ab_devの魅力的なところ

簡単に箇条書きをしていきます

  • 常時通話
  • 基本ペアプロ
  • ユニットテストめちゃ書く
  • PRレビューほぼ必ずする
  • アジャイル（スクラム）開発が運用されている
    • 朝会夕会で進捗や不確実な部分を適宜確認
    • 毎週末にステークホルダーを呼んでスプリントレビューで発表
    • プランニングやふりかえりにじっくり時間を取る。次週の改善点もみんなで練り練り
  • リモートで足りない雑談・相談専用の1on1の時間がある
  • チーム外だと、毎週事業内、社内での進捗・リリースプレゼン会がある
    • みんなプロダクトに熱心！アツい！

などなどです！詳細に書くこともできるのですが、別記事にまとめたほうが良い文量ができてしまうので、またの機会に。

入社して感じたこと

フルリモートでこれほどの熱量を生み出せるのが素晴らしいなと。
先に上げた進捗会や、スプリントレビュー、常時通話などなど。。。
これを祭りとして盛り上げよう、仕組みとして作っていこうが共通認識、文化としてあるというのが大きいのかなと思います。最高。
エンジニアとして見ても、テストあるしペアプロするし、CIインフラも整ってるしと、事前情報を超えるこれ以上ないほどの環境の良さでした。

現在の担当業務

幅広くやらせてもらってます！
経歴的に言うとLaravelとVue、AWS、設計が少々でした。
こちらに来てからはさらに、dbtでデータ基盤を修正したり、Metabaseでクエリ書いて他部署向けに欲しい情報出したり
監視ツール見てエラーの原因特定したり...たりたり！
経歴上一番大きな規模のPJに関わっているのでやりがいあって嬉しいですね。
つらみを言うならば、大きい分、分からない箇所が多い(ドメインとPG両方含む)ところでしょうか。
ただ、これも私は楽しんでますけれども！(先輩方にはまだまだお世話になります m( )m

さてお次は？

ご縁があって大変うれしいと思ったのが4月。エンジニアリング楽しいし、売上も伸びて業務委託だけど聞いてて嬉しい。
5月になってドメイン知識も増えてきて仕事も分かってきた。もっとエンジニアリングが楽しいし、チームとして動くのが気持ちよくなってきた。
けれどもつい先週あたり、社長の中嶋さんから聞いた言葉が頭に染み付いて離れません。
「成長市場にいるんだから会社として売上伸びるのは当たり前。じゃあ個人としてどうか、どう成長したかできるか考えてみよう」

安定しだしたのと同時に、2ヶ月で背筋が曲がり始めているのにも気づく...

ネトゲしてる場合じゃねぇ！

と、いうところでお時間来ましたので以上とさせていただきます！また！

Terraform Cloud のススメ

今年4月に Terraform Cloud を利用し始めて２ヶ月が経ちました。

back checkでは主に AWS 環境を terraform で管理しているため、AWS 環境での使用感も交えて記事にまとめようと思います。

Terraform Cloud とは

Terraform Cloud (以下TFC)は Terrafrom を使ってインフラ管理をする上で、辛みになってくる部分を解消してくれるクラウドサービスです。

例えば以下のような点です。

  • terraform のCI/CDの作り込み
  • AWS認証情報や権限の管理
  • workspaceを跨いだstateの参照
  • variables の管理
  • tfe provider で Terraform Cloud も terraform 管理

それでは詳しくみていきましょう。

Terraform Cloud の料金

まず、最初に気になるであろうTFC の料金について簡単に説明します。

TFCのStandardプランの料金は

  • 1リソース, 1時間あたり $0.00014 (記事執筆時点)

となってます。

ユーザ数による課金は無くなったのでチームで使いやすくなりました。 （その分ヘビーユースしている小規模チームは割高になりましたね・・・）

また毎月500リソース*１ヶ月分の無料枠があります。

1000リソースをプロビジョニングしている場合、無料枠を超えた500リソース分課金され約50$になります。 リソース数は terraform state list | wc -l で大体数えられます。(dataもしっかりと含まれます)

利用規模によりますが、調査や検証で利用する分には無料枠で十分足りそうです。

CI / CD の作り込み

Terraform では コーディング (write) → 変更内容の確認 (plan) → 変更の反映 (apply) というワークフローでインフラを構築していきます。

PRを出したらplan, マージしたらapplyみたいなことがやりたくなるわけですが、GitHub Actions Workflow等で作り込んでいくのはなかなかに時間がとられます。 特にworkspaceの数が増えてきたり、mono repo にしようと思うとかなり辛くなってきます。

TFC の場合はGitHub Appsとしてリポジトリにインストールし、TFC 上のworkspaceでVCS連携を有効にするだけです。

  • speculative plan を on にするとPRでplanが自動実行される
  • 指定したbranch(デフォルトはGitHub上のデフォルトブランチ) にマージするとplan→applyが実行される
  • trigger patternにファイルパターンを設定すると、特定のファイルに変更があった場合のみplan, applyが実行される

設定の幅は広くないですが、必要十分な機能を備えていると思います。

AWS 認証情報や権限管理

Terraform で AWS 環境の管理する場合、多数の認証情報を管理する必要が出てきます。

  • CI / CD で plan/applyするための認証情報
  • 開発者のローカルからplanして事前確認したり、検証環境にapplyするための認証情報

TFC を利用すると（設定によりますが）TFC 上でplanやapplyが実行されます。 AWSの認証はTFCで設定すればOKで、個々の開発者にTerraformのためのAWS権限を配る必要がありません。

TFC 上のどのworkspaceで何ができるかというのは、ProjectやTeamといった機能で管理できます。

開発者はローカルで terraform login するだけで自分に割り当てられたworkspaceで作業できるようになりますし、 VCS連携したworkspaceは手元からのapplyが自動で禁止されるので、勝手にメチャクチャになってしまう心配もありません。

コーディング時点で事前に本番planできるといったメリットを享受できます。

workspaceを跨いだstateの共有

workspaceはデプロイの単位になるのでシステム単位や環境単位で分けたくなります。 workspace間の参照は terraform_remote_state で行えるわけですが、これを使うにはbackendに対する認証が必要になります。

一方TFCの場合は tfe_outputs でTFC上の他workspaceのoutputを簡単に参照できます。

workspaceの設定でstate共有先のworkspaceを選択 or organization全体で共有をすれば、他workspaceから tfe_outputs で参照できるようになります。 認証情報等も不要です。

terraform_remote_state による他workspaceのstate参照は権限周りの複雑さも相まってかなり導入ハードルが高く感じていましたが、 tfe_outputs であればすぐに導入できます。

これもかなり嬉しいですね。

variables の管理

TFCではworkspace単位でvariablesを設定できる他、Variable Setsという機能があります。

これは複数workspaceやproject単位, organization全体といった複数のスコープにまとめてvariableを設定できるような機能になります。

backcheck では以下のような用途に使っています。 - dev, stg, prodといった環境名をenv というvariableに共通で渡している - datadog API key のようなproviderの認証情報をまとめて設定

TFCを使わない場合はそもそもvariablesをどこで管理するのかというのも考えなくてはいけないため便利な機能ですね。

tfe provider

ここまで書いてきたTFCの機能、設定を全てterraformで管理することができます！ それを可能にしているのが tfe provider です。

backcheckではTFC ×tfe provider ×mono repo という構成を採用していますが、 これによってかなり生産性が上がったのを実感しています。

例えば

dev, stg, prod の３環境に新システム用のworkspaceをそれぞれ作ってCIの設定をし、AWSの認証情報も設定する のような作業が30分もかからずにできるようになりました。

コードジェネレータを使えばテンプレ化もできると思います。

おわりに

TFC は Terraform を活用している場合はかなりフィットするサービスかなと思います(あとはお財布と相談)

無料枠もあるのでぜひ試してみることをおすすめします！