DX Criteriaから学ぶDX基礎知識（Vol.1 チーム編）

![ダウンロード (7).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/c9287fd3-a252-515e-5055-e7e7ce27f6dd.png)

# はじめに
企業内でシステム開発に携わる方々に向け、以前こちらの記事で[日本CTO協会](https://cto-a.org/)の「[DX Criteria](https://github.com/cto-a/dxcriteria)」をご紹介しました。

[技術負債の削減に向けた提案～「DX Criteria」の活用～ - Qiita](https://qiita.com/yasuoyasuo/items/4dab8988ce793603265c)

この「[DX Criteria](https://github.com/cto-a/dxcriteria)」は、DXに前進させる上で有益な指針かつチェックリストであり、弊社でも積極的に活用しています。

ただ資料中には前提知識を要する言葉もいくつか登場し、経験年数や職種を超え幅広いメンバーが正しく理解を深めるには一定の時間がかかりました。

そこでより多くの企業やチームの方に「[DX Criteria](https://github.com/cto-a/dxcriteria)」を活用読んでいただくために、弊社内で用意した資料に出てくる用語や背景をまとめたメモを、再構成の上こちらで公開することにしました。

今回は5つのテーマの中から、「チーム」についてご紹介します。他のテーマについても順次公開していきたいと思います。お役に立てば幸いです。

関連記事：
- [DX Criteriaから学ぶDX基礎知識（Vol.2 システム編） - Qiita](https://qiita.com/yasuoyasuo/items/168f0bb85ecbf0ea0c7a)

# 「[DX Criteria](https://github.com/cto-a/dxcriteria)」のおさらい
![ダウンロード (8).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/3c8097d5-83f9-c684-2ee5-b50c5e0f717d.png)
![ダウンロード (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/037e6022-02ee-42db-3940-526062274823.png)

# （１）チーム
![ダウンロード (13).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/959a579e-8220-fc17-b664-714f31673df6.png)

## 01 チーム構成と権限委譲
![ダウンロード (14).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/69874756-51e0-7602-2893-6d51f2f0a410.png)

###ピザ2枚ルール：
「会議は参加者が多いほど、生産性が低下する」という考えを元に、Amazon社で用いられている会議の参加者をを限定する考え方です。
参加メンバーを2枚のピザを分け合える人数に抑えるという例えから来ています。

参考：[ジェフ・ベゾスの秘策｢ピザ2枚｣ルール。 アマゾンはこれで無駄をなくした | Business Insider Japan](https://www.businessinsider.jp/post-34471)

###RACI図：
個人やチームに割り当てられた役割をマトリクス形式で表現した図のことです。
RACIは、実行責任（Responsible）、説明責任（Accountable）、協議先（Consulted）、報告先（Informed）の4つの頭文字です。

参考：[責任を持つとは？　〜RACIチャートの紹介〜 | Developers.IO](https://dev.classmethod.jp/articles/raci/)

### デリゲーションポーカー：
7枚のカードを用いて、権限ごとの認識を管理者とメンバーとですり合わせながら権限委譲を行うゲームです。
例えば、就業時間やツール選択など様々な意思決定事項に関して、以下の7段階で権限移譲のレベル感をすり合わせていきます。

1. 指示する ：管理者として意思決定を行う
2. 売り込む ：意思決定についての人々を納得させる
3. 相談する ：決定する前に、チームからの意見を得る
4. 同意する ：チームと一緒に決定を下す
5. アドバイスする ：チームによる意思決定に影響を及ぼす
6. 問い合わせる ：チームの決定後のフィードバックを求める
7. 移譲する ：特に影響を及ぼさずチームに任せる

参考：[権限委譲で自己組織化を促す！デリゲーションポーカー×実践的ワークショップのススメ | CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/archives/13234/)

###フィーチャーチーム：
組織の枠や担当領域にとらわれず、目的指向でフィーチャー（顧客やユーザーの求める価値）の実現を目指すチームのこと。
縦割りの機能分担型のコンポーネントチームとの対比で語られることが多いと思います。

参考：[フィーチャーチーム](https://featureteamprimer.org/ja/)

<img width="365" alt="フューチャーチーム.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/742a4c78-5e1f-b9a6-7d82-128d6b6eb55c.png">
引用：[フィーチャーチーム入門](https://featureteamprimer.org/jp/feature_team_primer_ja.pdf)

ポケモン世代にはこちらのサイトが参考になるでしょう。
[ポケモンで学ぶ！コンポーネントチームとフィーチャーチームの違いって？](https://www.kotanin0.work/entry/2019/02/03/195900)

## 02 チームビルディング
![ダウンロード (15).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/86d23617-b5da-05e8-1f16-1d6f55801fc9.png)

###プロジェクト憲章：
プロジェクトの目的とゴールを示した資料。その後のプロジェクトにおける意思決定の指針となります。

参考：[プロジェクト憲章の意味と、その実践方法とは？（Vol.26）](https://products.sint.co.jp/obpm/blog/project-management-charter)

###インセプションデッキ：
プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。

参考：[インセプションデッキ | ネスケラボ](https://blog.nextscape.net/research/agile/inceptiondeck)

###オンボーディング：
企業が新たに採用した人材を職場に配置し、組織の一員として定着させ、戦力化させるまでの一連の受け入れプロセスや姿勢のことです。

参考：[オン・ボーディングとは | 人事用語集・辞典 | 人事のプロを支援するHRプロ](https://www.hrpro.co.jp/glossary_detail.php?id=101)

## 03 心理的安全性
![ダウンロード (16).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/e2171163-9e69-a14e-4435-564f5dc649f4.png)

###心理的安全性：
一人ひとりが恐怖や不安を感じることなく、安心して発言・行動できる状態のことです。Google社のレポート以来、非常に重要視されています。

参考：[心理的安全性の作り方・測り方。Google流、生産性を高める方法を取り入れるには | d's JOURNAL（dsj）- 採用で組織をデザインする | 採用テクニック](https://www.dodadsj.com/content/190318_psychological-safety/)

###オフサイトミーティング：
職場から離れた非日常の環境で行うミーティングのことです。

参考：引用[オフサイトミーティングとは？メリットやデメリット、成功させるための準備まで徹底解説！ | 五番地 / GOBANCHI公式HP](https://gobanchi.com/2019/02/06/off-site-meeting/)

## 04 タスクマネジメント
![ダウンロード (17).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/1c687857-ae5f-7415-6fa4-b25ccea7d293.png)

###ステークホルダー：
利害関係者です。プロジェクトチーム内に留まらず、ユーザーや関係会社などにもおよびます。

参考：[知っているようで知らない？「ステークホルダー」の正しい意味と用法 | リクナビNEXTジャーナル](https://next.rikunabi.com/journal/20180918_s01/)

###ポストモーテム：
インシデントに対する再発防止策を検討した資料。直接的要因だけでなく、より組織文化的に踏み込んだ深い考察が求められます。

[ポストモーテムとは｜CAMPFIRE 開発チーム｜note](https://note.com/campfire_dev/n/n2a46e3832207)

## 05 透明性ある目標管理
![ダウンロード (18).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/9bd9b17b-1f8f-e439-4e58-5691c7dac8d4.png)

### OKR：
目標（Objective）と主要な成果（Key Result）をベースに達成を振返り成長を促す一種の評価制度です。

[OKRとは？ 【Google、Facebookが使う目標管理ツール】KPI・MBOとの違い、導入・運用・目標設定方法について解説 - カオナビ人事用語集](https://www.kaonavi.jp/dictionary/okr/)

## 06 経験主義的な見積りと計画
![ダウンロード (19).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/8c5c4ec1-6bb4-3df7-554a-dc62c389cc2a.png)

###ベロシティ：
いわゆる開発チームのシステム開発推進力を指標化したものです。例えばスクラムにおけるベロシティとは、1スプリントにチームが消化したポイントの合計のことを指します。ポイントはタスクごとにつけられているため、どれくらいの量の作業を1スプリントにそのチームができたかを示す数値となります。

[ベロシティとは | masaytan's blog](https://masaytan.com/archives/715)

## 07 ふりかえり習慣
![ダウンロード (20).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/d0e452bb-c52a-17ae-d13e-6231de934fe1.png)

ふりかえりの手法は[KPT法](https://studyhacker.net/kpt-jissen-hokoku)をはじめ複数あります。以下のような資料を参考にすると良いでしょう。
参考：[ふりかえりを拡張する「ふりかえりチートシート」 - Qiita](https://qiita.com/viva_tweet_x/items/b06f56ce83038fc2bb8f)

## 08 バリューストリーム最適化
![ダウンロード (21).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/80fe3bdc-2b94-d460-e784-9f39f5e88964.png)

###フロー効率性：
プロセス間の待ち時間を最小化し、作業の流れにおけるボトルネックをなくそうとする考え方です。プロセス内の生産性を高める「リソース効率性」と対比して用いられます。

参考：[「フロー効率」をチームの常識にする - 『This is Lean』の内容をチームメンバーにレクチャーした話 - TechとPoemeの間](http://t-and-p.hatenablog.com/entry/2018/01/08/%E3%80%8C%E3%83%95%E3%83%AD%E3%83%BC%E5%8A%B9%E7%8E%87%E3%80%8D%E3%82%92%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AE%E5%B8%B8%E8%AD%98%E3%81%AB%E3%81%99%E3%82%8B_-_%E3%80%8EThis_is_Lean%E3%80%8F%E3%81%AE)

###バリューストリームマッピング：
製品やサービスを顧客に届けるために必要なプロセスを可視化するための手法（ツール）です。
システムで言うと、ユーザーのニーズから仕様の検討、設計、実装やテスト、デプロイやリリースまでの作業の流れと関係する環境を可視化することで、プロセス改善のヒントを見つけるのに役立ちます。

https://dev.classmethod.jp/devops/value-stream-mapping/

###ペアプログラミング/モブプログラミング：
ペアまたは複数で画面をみながらプログラミング（またはそれに準じた作業）をすること。手数は減るが、複数の視点を入れることで設計や実装の品質を高め、不要な手戻りをなくしたり内部品質を向上させることで、チーム全体としての生産性を高めるための手法。

参考：[モブプログラミングを実際にやってみた - Qiita](https://qiita.com/TAKAKING22/items/31e027dfb6ea8b1a8d69)

# 最後に

色々と「DX Criteria」を周りの皆様ご紹介したところ

- 「DX Criteria」を使ってみたいけどもう少し詳しく中身を知りたい。
- 自分たちが依頼しているITパートナー企業に適用したいけどその依頼や監査を自社だけでやるのは不安

という方も多くいらっしゃることがわかりました。

そこで弊社で「DX Criteria」の適用を支援するサービスを用意しました。

 [IT組織 DX対応度診断サービス](https://ari-jp.com/lp/dx-survey/)

もしよろしければ上記ページからお問い合わせください。