Cybozu Inside Out | サイボウズエンジニアのブログ

 

サイボウズはiOSDC Japan 2023 にプラチナスポンサーとして協賛します!

iOSDC2023 Logo

こんにちは!サイボウズモバイルエンジニアの森嶋です。
今年も iOSDC Japan の時期が近づいてまいりました!

サイボウズは2023年9月1日から9月3日に開催される「iOSDC Japan 2023」に、プラチナスポンサーとして協賛させていただきます!

「iOSDC Japan」とは、iOS関連技術をテーマとしたiOS技術者のためのカンファレンスです。
今年は昨年に引き続き現地開催 + オンライン配信でのハイブリッド開催が予定されています。

サイボウズでは kintone や サイボウズ Office など4製品のモバイルアプリをリリースしており、SwiftUI や Combine、Swift Concurrency、TCA、swift-dependencies の導入に加え、Swift Package によるマルチモジュール構成や Command plugins の活用など新しい技術の取り込みを積極的に行なっています!
そこで、普段からお世話になっている iOS 関連技術コミュニティを一緒に盛り上げるべく今年も協賛いたしました。

今年はサイボウズとしては初めてブース出展も行いますので、現地にご来場の方は是非お立ち寄りください!
また、パンフレットもiOSDCトークンチャレンジと絡めた挑戦的な内容として作成していますのでそちらもお楽しみいただけると幸いです。

社員登壇情報

2023/09/02 11:35〜 Track C
6年間運用したiOSアプリのリアーキテクトについて具体的に解説
登壇者:松元 大樹(@daikimat)
登壇者コメント:サイボウズ製品であるkintoneのiOS アプリ開発で行っているリアーキテクトについて話をする予定です。 失敗談も含めて包み隠さずお話しできればと思います。皆様とお話しできることを楽しみにしています。

fortee.jp

2023/09/03 13:00〜 Track D レギュラートーク(40分)
作って学ぶBluetoothの基本攻略〜スマートキーアプリを作ってみよう〜
登壇者:岡 優志 (@oka_yuuji)
登壇者コメント:スマートキーアプリの作り方を通してBluetoothに関する基本的な概念から実践的な部分までお話しする予定です。 本トークをきっかけに少しでもBluetoothを用いた開発に興味を持っていただき、今後の開発への第一歩となれば幸いです。

fortee.jp

関連イベント情報

9月26日(火) 19時より、株式会社アンドパッド / WED株式会社 / GO株式会社 / STORES 株式会社と合同で「後夜祭 iOSDC Japan 2023」を開催します!

各社ショートトークとiOSDC Japan 2023の感想戦をYoutubeLiveにてオンライン配信する予定です。
詳細は以下URLからご確認ください。沢山のご参加お待ちしております!
hey.connpass.com

おまけ:iOSDCトークンチャレンジ

今年のiOSDCパンフレットのサイボウズページにはコードクイズを掲載しています。
コードクイズの回答と下記のコードを組み合わせることによってiOSDCトークンを生成する仕組みとなっていますので、ぜひお楽しみいただければと思います!

protocol Tokenizable { func tokenized() -> String }

extension Q1: Tokenizable {
    func tokenized() -> String {
        switch selecting {
        case .ans1:
            return "I"
        case .ans2:
            return "We"
        case .ans3:
            return "Cybozu"
        }
    }
}

extension Q2: Tokenizable {
    func tokenized() -> String {
        switch selecting {
        case .ans1:
            return "Cybozu"
        case .ans2:
            return "Love"
        case .ans3:
            return "did"
        }
    }
}

extension Q3: Tokenizable {
    func tokenized() -> String {
        switch selecting {
        case .ans1:
            return "Teamwork"
        case .ans2:
            return "CybozuMobile"
        case .ans3:
            return "CybozuQuiz"
        }
    }
}

let quiz: [any Tokenizable] = [
    Q1(selecting: /* Your Answer */),
    Q2(selecting: /* Your Answer */),
    Q3(selecting: /* Your Answer */)
]
let iOSDCToken = quiz.map { $0.tokenized() }.reduce("#", +)

さいごに

サイボウズでは「チームワークあふれる社会を創る」という理念を実現するべく、iOS エンジニアを絶賛募集中です!
詳しくは下記をご参照ください。 cybozu.co.jp

 

SCIM連携ができるまで

ご覧いただきありがとうございます。

皆様は RFC7644 SCIM と呼ばれる仕様はご存じでしょうか。 SCIMとは"System for Cross-domain Identity Management" の略で、システム間でのID管理を自動化する機能です。 この機能を実装すると、Microsoft Entra ID(旧Azure AD)やOktaなどのID管理システムでのユーザー情報の変更を自動的に連携先のシステムに反映させることができます。

Microsoft Entra IDやOktaなどId管理システムは連携用のカタログを公開しており、数クリックで連携させることができます。

本記事ではSCIMを実装するための要件検討からMicrosoft Entra ID, Oktaに申請するまでに必要な技術情報を扱います。 今実装しようとしているものが、Id管理システムのId供給側(Id Provider)の場合、他の情報源を当たるようにしてください。

用語について

  • SCIM: SCIMとは"System for Cross-domain Identity Management" の略で、システム間でのユーザーや組織情報の同期を行うための仕様です
  • Identity Provider(IdP): ユーザー・組織情報を提供する側のシステムを指します
  • Serivce Provider(SP) : ユーザー・組織情報を利用する側のシステムを指します
  • Microsoft EntraID: Microsoft Azure Active Directory(Azure AD)の新名称を指します。この文章では Microsoft EntraIDで統一しています

SCIMって?

SCIMは基本的なhttp + JSONメッセージのhttp APIで構成されます。概念図を下に示します。

SCIM概要図

1. 初期プロビジョニング

IdP/SP間でユーザーの存在確認を行います

  • GET /Users リクエスト : SPのユーザーをすべて取得します
  • POST /User リクエスト : SPに存在しないユーザーを作成します

2. IdPで変更されたユーザー情報をSPへ差分適用する

  • GET /User/{id} リクエスト : IdP/SP間で連携用のIDを使ってユーザーの存在を確認します
  • PUT /User/{id} リクエスト : IdPで行われたユーザー情報の変更をSPに適用します

3. IdPで作成されたユーザーをSPにも作成する

  • GET /Users?filter= リクエスト : IdPで作成されたユーザーがSPに存在するか確認します
  • POST /User リクエスト : IdPで作成されたユーザーをSPに作成します

連携目標のシステムを決める

前述のとおり超大手のID管理クラウドシステムは連携ギャラリーを公開しており、SCIMを実装することになったらギャラリー登録を目標にすると良さそうです。

Microsoft Entra ID, Okta以外にもプロビジョニング機能を持っているサービスは存在します。

  • Microsoft Entra ID
  • Okta
  • OneLogin
  • Google workspace
  • Ping Identity

ギャラリーや開発支援ツールの充実度や参考にできるドキュメント量からMicrosoft Entra ID,Oktaをcybozu.comでは連携目標に定めました。

仕様を概観する

目標となる連携先を決めたら、仕様をざっくり理解していきましょう。よいドキュメントを公開してくれていますのでこちらを読んでざっくり理解します。

ざっくり理解できたら必要に応じてRFCを読み込んでいくとよいでしょう。次にまとまっています。System for Cross-domain Identity Management

詳細なhttpリクエストやレスポンスボディの詳細は、上記ドキュメントによく書かれているので割愛します。

認証方法を決める

Id管理システムから開発しているWebシステムの認証方法を決めます。以下3点から、方針を決めるとよいでしょう。

  • Id管理システムから利用可能な認証方式
  • 開発中のWebシステムのアーキテクチャで実装可能
  • できる限りセキュア

Id管理システムによっていくつかの認証方式が提供されています。例となる認証方式を次に示します。

  • OAuth2.0プロトコル
  • httpヘッダー + シークレットトークン
  • ベーシック認証

OAuth2.0のプロトコルに沿ってで実装したかったのですが、弊社のアーキテクチャでは実装が困難でした。 このため、httpヘッダー+シークレットトークンによる認証を採用、実装しました。

実装する範囲を決める

実装する範囲を決めます。ユーザーだけでなくグループのプロビジョニングも仕様としては存在しています。 適宜、工数や開発システムと相談の上、実装範囲を決めましょう。

ユーザーのプロビジョニング機能を動作させるために実装したエンドポイントを次に示します。

  • POST /Users (新規ユーザーの作成)
  • GET /Users (全ユーザーの取得)
  • GET /Users?filter=... (絞り込みを使った複数ユーザーの取得)
  • GET /Users/{id} (ユーザーの取得)
  • PUT /Users/{id} (ユーザーの更新)
  • PATCH /Users/{id} (ユーザーの更新)
  • DELETE /Users/{id} (ユーザーの削除)
  • GET /Schemas (スキーマ情報の取得)

連携するId管理システムによっては上記のAPIの中に不要なものもあります。要件の状況に応じて実装するAPIを決めるとよいでしょう。

スキーマ設計をする

Microsoft Entra ID とcybozuのユーザーのマッピングを次に示します。

Microsoft Entra ID ユーザー SCIMユーザースキーマ cybozuユーザー
IsSoftDeleted active 使用状態
displayName displayName 表示名
surname name.familyName
givenName name.givenName 
mail emails[type eq "work"].value Emailアドレス
user-PrincipalName externalId SCIM 拡張ユーザー項目として新規に用意
mailNickName/onpremisessamaccountname/user-PrincipalName userName ログイン名
なし id SCIM 拡張ユーザー項目として新規に用意
なし meta.created 作成日時
なし meta.lastModified 更新日時
設定項目未定 password パスワード

SCIMの仕様ではほかにもたくさん属性があります。開発するシステムに合わせて決めるとよいでしょう。

実装する

Id管理システムによって投げるリクエストに特徴があります。そのため注意が必要です。 次の例は同じPATCHリクエストです。各社で微妙に構造体が異なります。気持ちを強く持って実装することが必要です。

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "value": {
        "emails[type eq \"work\"].value": "TestBxfpl@test.microsoft.com"
      }
    }
  ]
}
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "value": {
        "emails": [
          {
            "value": "newvalue@cybozu.onmicrosoft.com",
            "type": "work"
          }
        ]
      }
    }
  ]
}

複数社のId管理システムを対応すると共通仕様とは名ばかりではないかと叫びたくなる気持ちになります。 その気持ちを抑えながら実装しきることが大切です。逆説的ではありますがPATCH周りの細かい話でつまづくと完成は近いので、がんばりましょう。

やや古いAzure ADとの連携を想定するときには以下に目を通しておきましょう。健闘を祈ります。

Known issues and resolutions with SCIM 2.0 protocol compliance of the Azure AD User Provisioning service

試験する・インテグレーションする

自動試験ツールを提供されています。実際のID管理システムとインテグレーションして動作確認する前に利用できます。 連携想定のId管理システムと結合する前に自動試験ツールで動作確認しておいた方が賢明でしょう。

ローカルの開発環境で試験する場合はngrok が便利です。セキュリティ規約で社内ツールとして利用可能なツールか確認するようにしてください。

ギャラリーを公開している企業に申請する

ギャラリーへの登録を申請して作業を進めていきましょう。

ここからが一番大変で、時間がかかります。 (社内で協力してくれた皆様、ありがとう)

執筆 : @yokotaso

 

QA Gathering Day 2023 の開催レポート 〜社内のQAエンジニアの横のつながりを強化するために〜

こんにちは!QAエンジニアの矢引です。先日サイボウズ東京オフィスで開催された「QA Gathering Day 2023」の開催レポートを公開します。「QA Gathering Day」は、サイボウズのQAエンジニア系の職能のメンバーが集まる社内イベントです。

イベント概要

  • 開催日:2023年7月26日(水) 、27日(木)
  • 場所 :サイボウズ東京オフィス
  • 参加者:総参加者数 約50名(QAエンジニア、プロダクトセキュリティエンジニア、クラウド基盤エンジニア(SET))

背景

サイボウズ開発本部では2019年に組織変更を行い、チーム主体の組織構成となりました。ここで言うチームとは、製品開発をミッションに持つkintoneやGaroonの他、他のチームを支援するAgile Coachや生産性向上といったチームです。(組織変更の詳細について詳しく知りたい方はこちらの記事をご覧ください。)

blog.cybozu.io

この組織構成によって各チームの自律性は高まりましたが、その一方で、以前と比較すると同じ職能であっても他のチームのことがやや見えにくくなったと感じています。また、コロナでリモートワークがメインになり、業務で直接関わらないメンバーとの偶発的なコミュニケーションが少なくなっているため「名前は知っているけど業務内容や人柄をよく知らない」といった人が増えています。

そこで「横(同じ職能)のつながり強化」によって知らないチーム/人を減らし、もっと協力して効率的に業務に取り組めるようにしていきたいと考え、今回のイベントを開催することにしました。イベントの企画・運営は、人材マネージャーと有志のメンバー6名で行いました。

チームビルディングを支援する社内制度を利用

サイボウズには対面でのチームビルディング活動に対して補助を行う「チムビル(対面型チームビルディング支援制度)」制度があります。 cybozu.backstage.cybozu.co.jp

今回はこのチムビル制度を利用して対面型のイベントを開催しました。このイベントの目的は次の2つとし、プログラムもなるべくチームを超えた横のつながりを構築できるようなものにしました。

目的
①QAエンジニア系の職能メンバーの横のつながりを強化する
②チームごとの取り組みや、困っていること・お悩みを共有し、他メンバーに気づきを与える

プログラム
▼1日目
・アイスブレイク
・参加者が所属する各チームのLT会
・チームビルディング:4象限で相互理解ワーク、他己紹介ワーク
・懇親会🍺
▼2日目
・アイスブレイク
・OST(オープン・スペース・テクノロジー)

各プログラムのダイジェスト

ここからは各プログラムの内容と当日の様子を簡単にご紹介します。

各チームのLT会

参加者が所属するチーム(計14チーム)がLTを行いました。

チームメンバーの紹介や業務内容の説明、その他アピールしたいことなどを各チームが話しました。おもちゃの太鼓を片手に自作のキャッチフレーズとともにメンバー紹介するチームや担当プロダクトの最新バージョンの機能紹介をするチームなどもあり、チームごとの個性が溢れていました。今回のイベントにいろんなチームから参加者が集まったことを実感できました。

LT会の様子 - その1
LT会の様子 - その1
LT会の様子 - その2
LT会の様子 - その2

チームビルディング

「4象限で相互理解ワーク」と「他己紹介ワーク」を実施しました。これらのワークのファシリテーションはチムビル制度を運営するチームワークサポートチームにお願いしました。

4象限ワークでは部屋を4つに区切り、「休日の過ごし方」「性格」「仕事に取り組む姿勢」について部屋の中を立って移動して自分の立ち位置を表します。「大らか かつ 平穏が好き」の象限に集まる人数がとても多いなど、今回のイベントの参加者の傾向を掴めておもしろかったです

他己紹介ワークでは5,6名で1グループとなり、ペア/トリオになってインタビューをした後、他のメンバーに他己紹介をしました。紹介者が想像して”盛った”話もまじえてOKなので(当事者は後の釈明タイムまで発話することは禁止されている)、予想外のエピソードがあったりしてとても盛り上がりました!普段業務で接する機会の少ないメンバー同士でグループを組んだこともあり、今回初めて会った方のパーソナリティを深く知ることができてよかったです。

4象限ワークの様子
4象限ワークの様子
他己紹介ワークの様子
他己紹介ワークの様子 - その1
他己紹介ワークの様子 - その2
他己紹介ワークの様子 - その2

OST(オープン・スペース・テクノロジー)

OSTは、話したいテーマ・解決したい課題を参加者が持ち寄り、参加者同士で話し合う場です。今回はOST形式で、事前に持ち寄ったテーマについて小さいグループを作って話し合いました。

テーマの例:
「ディベロッパーとのコラボレーションの工夫について聞きたい」
「今後のキャリア、みなさんどう考えていますか?」
「生成系AIをどうテストしていけばよいか」
「技術ネタのキャッチアップは皆さん普段どのようにやっていますか?」など

QAの業務に深く関わるテストに関する話題や車座で少人数で話すからこそ議論しやすいトピックなどもあり、どのグループでも活発に意見交換されていました。自分はQAのオンボーディングに関するトピックに参加しましたが、早速業務に活かせそうなアイデアをもらうことができてとても参考になりました!

OSTの様子
OSTの様子

感想

コロナでリモートワークがメインになってから初めてQAエンジニア系の職能メンバーが一同に集まる会でしたが、文字通り全国から(北は北海道、南は沖縄から!)参加者が集まるにぎやかなイベントとなりました。

今回は「知らない人をなるべく減らす」「楽しむ」をテーマにして開催しましたが、初対面の方ともたくさんお話する機会があり、今後やり取りする際にも心理的なハードルが下がった気がします。

開催後のアンケートでは「今後も横のつながりを大切にしていきたい」という声もあり、今回作ったつながりを活用してチームを横断した取り組みを盛り上げたりチーム間でノウハウを共有することで各チームでの活動を加速できるように、今後も社内の横のつながりを大事にしていきたいと思いました。

最後に

「QA Gathering Day」は今回初めての取り組みでしたが、(開催形式や内容は検討しつつ)今後も横のつながりを強化するようなイベントを継続して開催したいと考えています。

最後になりますが、サイボウズではQAエンジニア系職能のメンバーを募集しています。興味のある方はサイボウズの採用情報をご覧ください。

cybozu.co.jp

cybozu.co.jp

cybozu.co.jp

cybozu.co.jp

 

Cybozu Frontend Day 2023の社内開催と資料公開

主催のkoba04による写真

こんにちは、フロントエンドエンジニアの@shisama_です。
6月30日にサイボウズ東京オフィスで開催された「Cybozu Frontend Day 2023」の資料と開催レポートを公開します。
「Cybozu Frontend Day 2023」は、サイボウズのフロントエンドエンジニアが集まりフロントエンドに関する知見を共有する社内イベントです。

発表資料

発表資料は以下の通りです。発表者が公開している一部の資料については、発表者の許可を得て掲載しています。

Pages RouterとApp Routerでのi18n対応の違い

発表者: @nissy_dev

zenn.dev

誰でも簡単⁉️👀 絵文字ができるまで😃👍

発表者: @oguemon_com

speakerdeck.com

Node Streamでメモリ性能改善、そしてWeb Streams APIへ / Improving memory performance of the CLI tool using Node Stream

発表者: @tasshi_me

speakerdeck.com

View Transition APIの仕組みまとめ

発表者: @irico

docs.google.com

Intl.MessageFormat Introduction

発表者: @teppeis

www.docswell.com

Deopt ExplorerでWebアプリのパフォーマンスを改善しよう!

発表者: @b4h0_c4t

speakerdeck.com

Standing on the shoulders of giants

発表者: @koba04

speakerdeck.com

Do you like Storybook?

発表者: @nus3_

speakerdeck.com

カチカチするたびランダムに回転する僕の作り方with Astro

発表者: @Shitimi_613

www.docswell.com

開催レポート

サイボウズ東京オフィスでオフライン開催し、20名以上が参加しました。参加者は基本的にプレゼン発表するというレギュレーションで開催したため、多くの知見やチームの活動を共有できたと感じています。

本編終了後には懇親会を開催し、普段は別々で働く他のチームメンバー同士が交流しました。

懇親会の飲食に関しては、会社からの飲食費補助制度を使ってビールやピザなどを注文しましたが、地方から参加したメンバーが持ってきた地酒なども楽しみました。

懇親会の様子

同時通訳について

今回のイベントには非日本語話者のメンバーも参加していました。
そのため、通訳と翻訳を専門にするチームに協力していただいて同時通訳用のZoom部屋も用意しました。また、数名の日本人が英語での発表に挑戦しました。

最後に

今回初めての取り組みでしたが、今後も継続して開催したいと考えています。
可能な範囲で発表資料を公開したり開催レポートも書く予定です。

最後になりますが、サイボウズではフロントエンドエンジニアを募集しています。
興味のある方はサイボウズの採用情報をご覧ください。

cybozu.co.jp

cybozu.co.jp

cybozu.co.jp

 

開発チーム作成ガイドを公開します

こんにちは。シニアスクラムマスターの天野 @ama_ch です。

サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。

フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。

そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践しているチームでもそうでないチームでも参考にすることができる「開発チーム作成ガイド」を作りました。こちらを本記事で一般公開します。

組織の枠を超え、健全なチームが増える一助になれば幸いです。

開発チーム作成ガイド

はじめに

レガシーなアーキテクチャからの脱却を図るため、サイボウズの開発組織では各所でチーム分割の議論が進んでいます。世間では、チームトポロジーユニコーン企業のひみつSpotifyモデル)などが話題になり、チームを主体とした組織づくりが現代的なソフトウェア企業には必須になってきています。このようなアジリティの高い組織を作るには、まず機能する「チーム」を作る必要があります。機能するチームが組織の最小単位になります。

このドキュメントでは、機能するチームはどのようなものか、どうやって作るかの一例を基本の型として示し、開発組織のみなさんがパフォーマンスの高いチームを作れるようになることを目指します。

本ガイドでは、スクラムと同じ用語が登場しますが、スクラムチーム以外でも使えるものになっています。

3行まとめ

  • 5-9人のクロスファンクショナル(職能横断)チームを作る
  • チームの方向性を決める役割(プロダクトオーナー)とチームを健全に保つ役割(スクラムマスター)に責任を負う人を置く
  • チーム内で意思決定と仕事が完結するよう必要な権限・リソースを確保する

もう少し詳しいまとめは 機能するチームの基本の型

優れたチームの効果

優れたチームは、一般的に、タスクに関する成果(顧客満足、予算と納期の順守、高い品質etc)人に関する成果(このチームで働き続けたい、成長できる、幸せだetc)を両立します。重要なのは、これらを両立させるという点です。

タスクに関する成果を重視しすぎると、燃え尽きや低いモチベーション、高い離職率などの問題が発生します。人に関する成果を重視しすぎると、仲良しのぬるま湯のようなチームになったり、顧客を無視して技術的な課題を探究してばかりのチームになってしまったりします。

優れたチームの効果(タスクの成果と人の成果の両立)は、チーム活動の結果として得られるものです。優れたチームの効果を得るまでには、入力(チームの設計)、プロセス(チームワーク)、出力(チームの効果)の過程が存在します。

チームの入力(チームの設計)、プロセス(チームワーク)、出力(チームの効果)の図
チームワークとその向上方策の概念整理 より引用

入力(チームの設計)を整えないままプロセス(チームワーク)を頑張っても、得られる出力(チームの効果)は大きくなりません。素晴らしいチームワークを発揮し、優れたチームの効果を得るためには、チームワークの前提となるチームの設計を整える必要があります。

効果的に機能するチームの特徴

効果的に機能するチームは、仕事の進め方にいくつかの特徴があります。

  • 自律的
    • 外部からの指示によらず、チーム自身が目標を設定して活動する
  • 自己管理(自己組織化)
    • 目標達成のために行う日々の活動をメンバーが自分たちで考えて決める
  • 相互依存性
    • メンバー同士で互いに協力し密接にコミュニケーションを取りながら業務を遂行する
  • 独立性
    • チーム外への依存は最小限で、チーム内で意思決定から業務遂行まで完結できる

広義のチームと自己管理型チーム

一般的に、チームは「共通の目標を達成するために役割分担して協力する集団」のように説明されることが多いです。これを広義のチームと呼びます。この定義にもとづくと、サイボウズのような1,000人単位の組織もチームと言えます。

一方、前項のような特徴を持ち、高いチームワークとパフォーマンスを発揮するチームを実現するには、より多くの条件を考慮して設計する必要があります。広義のチームと区別できるようにするため、本ガイドで実現を目指すチームは自己管理型チーム (self-managing team) とします。

本ガイドで用いる「チーム」という単語は、すべて自己管理型チームを意味しています。

チームの設計で特に考慮すべき条件

いくつかの書籍・論文の情報とこれまでの現場での実践を踏まえ、サイボウズの開発組織でチームを設計する時に特に考慮すべき条件をまとめます。

人員規模

チームの人員規模は、5-9人が適正サイズです。

ダンバー数や2ピザルールなど関連する情報は多くありますが、7±2名という数字がよく使われます。5名が最適という研究結果もあります。概ね小さい方が日常のコミュニケーションや会議を円滑に進めやすく、チームワークを発揮しやすい傾向があります。5人未満でも機能しますが、3人未満になると、必要なスキルが不足する・相互作用が少なくなるなどの問題が発生しやすくなります。

チームを適正サイズに維持することは極めて重要です。チームの規模が10人以上になると、十分な意思疎通ができない・メンバー同士の信頼関係を構築できない・ミーティングが時間通りに終わらないなど、チーム運営上致命的な問題が発生します。

目的

チームが自律的に活動するためには、「このチームは何のために存在しているのか?」という存在目的(パーパス)が必要です。チームは目的を達成するために日々活動します。チームの目的は、チームにとってしかるべき人物が決める必要があります。チーム内のメンバーであることもあれば、チーム外の上司であることもあります。

例えば、フロリア(kintone フロントエンドリアーキテクチャプロジェクト)ではプロジェクトリーダーのkoba04さんから「フロントエンドに Autonomy をもたらす」という目指す姿(目的)が掲げられています。

責任と権限

チームの目的を実現するための活動がチームの業務になります。そのためにチームの職務を設計し、必要な権限・リソースを確保します。職務設計では、チームが提供する価値のエンドツーエンドのフロー全体を扱うようにします。フロー全体に責任と権限を持つことで、顧客からのフィードバックをもとにパフォーマンスを最適化できるようになり、チームのモチベーションも高まります

例えばプロダクト開発チームであれば、次のような権限が必要です。

  • プロダクトの方向性を決める
  • 利用するツールを自分たちで選べる
  • 任意のタイミングでデプロイできる
  • インフラを自分たちで触れる
  • ユーザーの声を直接聞くことができる
  • 利用状況を分析できる

技術的な事情などによりすぐに実現するのは難しいものもありますが、原則としてチームの目的達成に必要なものはすべて自分たちで触れるようにします。

適切に業務を設計し権限を確保することで、チームはオーナーシップを発揮して責任を果たせるようになります。

スキルの多様性

チームの目的を達成するには、日々複雑な問題に向き合わなければいけません。チームは、複雑な問題を解決するためのスキルを統合する装置と見なすことができます。複雑な問題に対処できる多様な専門性を確保するために、複数の職能からなるクロスファンクショナルチームを形成します。

メンバーの多様性については、職能の他に属性・経験・心理的特徴といった観点からも捉えられますが、チームのパフォーマンスに影響があるのは、属性の多様性よりも職能の多様性であることが明らかになっています。

安定性

頻繁にコミュニケーションするチーム活動の性質上、チームとして安定した成果を出すためには、メンバーを安定させることが重要です。できる限りメンバーの入れ替えは避け、安定したチームはなるべく解散しないようにします。

ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ by アラン・ケリー 『Project Myopia』

チームの成果を安定させるためには、基本的には専任でチームの活動に参加することを推奨します。専任が難しい場合は、チームとして成果を出すために必要なレベルのコミットメントについて合意するようにします。兼務が増え、コミットメントのレベルが下がるほど、チームのパフォーマンスは下がりやすくなります。

また、誰がチームメンバーで誰がそうでないのかというチームの境界を明確にすることも重要です。境界が曖昧なチームは、意思決定が遅くなり、低いパフォーマンスにつながります。

役割分担

自律的なチームは、バラバラなメンバーの集合体というよりも、ひとつの生き物のように振る舞います。そのためには、チームとして一貫して意思決定できること・レジリエンス(困難な状況から回復する力)を備えることが必要です。

チームにこれらの機能を持たせるために、チームの方向性を決める役割(プロダクトオーナー)とチームを健全に保つ役割(スクラムマスター)を分担します。

プロダクトオーナーは、チームに一貫した方向性をもたらします。チームが目指すゴールを示し、活動の優先順位を判断し、成果を最大化するために何をするか(What)に責任を負います。

スクラムマスターは、チームを健全な状態に保ちます。コーチとしてチームを支え励まし、継続的な改善をサポートすることで、チームがより良い方法で仕事を進められるようにすること(How)に責任を負います。

プロダクトオーナー/スクラムマスターを置いただけでは効果的に振る舞うことは難しいため、継続的にコーチングを受けることも重要です。

機能するチームの基本の型

チーム設計時に考慮すべき条件を満たすチーム設計として、下記を基本型として提示します。

  1. 5-9名の複数職能からなるクロスファンクショナルチーム
  2. チームには存在する目的がある
  3. 目的達成のために必要なすべての業務を遂行する権限がある
  4. メンバーの入れ替えは最小限で安定している
  5. 誰がチームメンバーで誰がそうでないかの境界が明確
  6. チームの方向性を決める役割(プロダクトオーナー)とチームを健全に保つ役割(スクラムマスター)の責任者がいる
  7. メンバーは必要十分なレベルのコミットメントをしている

自律的な複数のチームが共通のゴールに向けて活動する様子
チームの基本の型

サイボウズの開発組織ではスクラムを採用しているチームが多いため、プロダクトオーナーとスクラムマスターの役割をチームの機能として抽象化し、スクラムでないチームにも適用可能にしています。プロダクトオーナーとスクラムマスターがそれぞれリーダーシップを発揮することで、優れたチームの効果を得やすくなることを意図しています。

これらの条件を整えれば必ずしも優れたチームになるわけではありませんが、成功する可能性を高めることはできます。条件を整えるためにできる手段を尽くすことが、リーダーやマネージャーの責任です。

整えた上でうまくいかない場合は、適切なコーチングを受けることで改善できるかも知れません。ぜひアジャイルコーチチームを頼ってください。

よくある質問

  • 必ず条件を整えないとダメ?

条件を整えても成功を約束できるものではないので、必ずしも全部の条件を整える必要はありません。すべての条件が整っていなくてもうまく機能するチームもあり得ます。特に役割分担については、プロダクトオーナーとスクラムマスターで分担する以外の形はいくつも考えられます。ですが、その他の条件はほぼ満たしていないと、現実的に成功する可能性は著しく低くなると考えています。

  • POってPMとは違うの?

本ガイドでのプロダクトオーナー(PO)は、チームの「外部からの指示によらず自律的に動く」という機能を実現するための役割です。プロダクトマネージャー(PM)は一般的に存在する職能で、製品の企画や仮説検証を行うプロダクトマネジメントの専門家になります。

チームの意思決定役としてのPOは、必ずしもプロダクトマネジメントの専門家である必要はないため、POはPMとは異なります。POはチームに1名必ず存在しますが、PMは1人で複数のチームを担当することもあります。

  • POはプロダクトに1人では?

その通りです。プロダクトという単位で見た時に、1人の人物がPOとして振る舞うことは重要です。サイボウズの規模では、プロダクトチームは複数のチームの集合体になります。プロダクト全体の意思決定を担うPOがいるのと同時に、各チームが自律的に活動するためにチームPOが存在する、というフラクタルな意思決定構造にすることで、全体の方向性を揃えることと各チームの自律性を高めることを両立できます。

  • チームに所属しないで働いてるんだけど?

組織はチームだけでできているわけではないので、必要に応じてそのような動き方もあり得ると思います。今の働き方に疑問がなければ、そのまま継続で問題ありません。もしやりづらさがあったり問題が顕在化しているようなら、チームに入ってチームの仕事にすることを検討してみても良いかも知れません。

  • 単一職能のエキスパートチームはダメなの?

ダメではないです。チームの目的次第では、エキスパートチームが向いていることもあります。非常に専門性の高い問題を解決するチーム、他のチームを支援することが目的になるチームなどが例として挙げられます。チームトポロジーでいうところの、イネイブリングチームやコンプリケイテッド・サブシステムチームの多くはこれに該当します。

  • 入社や異動で定期的にメンバーが変わります

チームを安定させるためにメンバーの頻繁な入れ替えは避けるべきですが、環境にあわせてチームも変化します。新しいメンバーの入社・キャリアの挑戦のための異動などの「自然な代謝」は問題ありません。むしろメンバーが何年もまったく変わらない方が、サイロ化・社会的手抜きなどの問題が起こりやすいです。

目安としては、半年に1名くらいの変化は自然な代謝の範囲と考えて良いと思います。毎月メンバーが入れ替わるレベルになると、明らかに安定性を欠いています。

  • チームにPO/SMをやりたい人がいません

基本姿勢としては、強制してやってもらう役割ではないと考えています。

経験がなくてできるか不安ということであれば、ぜひお近くのスクラムマスター/アジャイルコーチにご相談ください。一緒に考えます。持ち回りでやってみて一度経験してみるのも良いかも知れません。

純粋にやりたくない・モチベーションが湧かない場合は、チームの成り立ちや置かれている状況に何か問題があるのかも知れません。力になれるか分かりませんが、一度お話を聞かせてください。

  • 条件を整えられる気がしない

条件を整えるための相対的な難易度は、現場によってかなりばらつきがあります。新たに立ち上げるチームでは比較的簡単に整えられますが、これまで長く活動していたチームで後から条件を整えるのは非常に難しいです。無理せずできるところから整えていきましょう。

条件を整えるにはチームの形や仕事のやり方を大きく変える必要があるので、条件を整えることはリーダー・マネージャーの重要な責任だと考えています。実行はアジャイルコーチ・スクラムマスターも推進していくので、ぜひ気軽にご相談ください。できる限りの支援を尽くします。

参考資料