チーム・ジョブ・ディスクリプションを作ってはどうだろうか？という話

概要

チームに同質性と多様性をもたらすにはどうしたらええんやろか？って考えてたらチーム・ジョブ・ディスクリプションに辿り着いたので、その話を少しだけ書き残そうと思います。

もしチーム・ジョブ・ディスクリプションやチーム憲章を作るチームがありましたら一報ください。全力でお手伝いします。

同質性と多様性が必要である理由

同一性と多様性についての説明は割愛します。ググれば何となくわかると思います。

チームを「人」として見た時に同質性と多様性の必要性は簡単に説明することができます。例えばボールを拾って宙に放り蹴るという動作をするとしましょう。これはチームで言えばタスクをこなすとかになります。
この時に手足がお互いを気にせずバラバラに動いた場合、ボールを拾うどころか下手をすればその場に立っていることもままなりません。ボールを拾うには、まずボールの近くまで歩いて行かなければなりません。手が仕事をするのに足が必要になります。ボールを拾って宙に放っても足が蹴らなければ目的は達成できません。手がいつボールを放るのか、どこに放るのか、手と足の連携が必要になります。ボールを蹴る時に体のバランスが崩れていると足がボールに当たりません、転んでしまうかもしれません。手は体のバランスを保つために何かしらのアクションを行わなければなりません。

このように何かを成す時にはぞれぞれがぞれぞれの機能を正しく機能させるだけではなく、何を成そうとしているのか、他の機能がどのように働いているのか、どのような特徴や癖があるかを理解しなければなりません。コンテキストを理解してそれぞれの機能を働かせることが必要になります。

先の例で言えば手や足は「これから何を成そうとしているのか」を理解している必要があります。これがチームにおける「同質性」です。手や足は成そうとしていることにどのようにアプローチをするか（手でボールに触っても蹴るとは言いませんよね）、手段の「多様性」となります。

同質性と多様性を持つことでチームはブレることなく成すべきことに集中でき、多様性を持つことでたくさんの選択肢（手段）を得ることができます。

何となく理解してもらえたでしょうか。同質性と多様性の話では「山に登る」も例え話としてたくさん出てくると思います。山に登るという目標に対してどこまで車で行くのか、ロープウェイは使えるのか、どこからは歩いて行かなければならないのか、登るという目標に対して様々な手段の組み合わせがあります。チームも同様で目標に対してたくさんの手段が考えられると思います。同質性が担保されていれば、の話ですが。

同質性の元になるもの

チームで同じ目標を持てば良いと簡単に言いましたが、「みんなで頑張ろー！」とかは非常によろしくないです。何を成すのか、何を大切にするのかを明確にシンプルに本質的に掲げなければなりません。
では、「何を成すのか、何を大切にするのか」の元になるものは何でしょうか。多くの企業は会社組織がその案件・チームに求める「ミッション」という形で定義されます。

しかし、実際に現場で期待されることは会社組織がその案件・チームに求めることだけでしょうか？契約形態や業務内容に影響を受けますが、おそらく多くの人は「No」と言うのではないでしょうか。現実は「自社」「営業（≠お客さん）」「現場（プロジェクト）」の3方向から様々な期待を寄せられます。中には相反する期待もあるかもしれません。これらの期待を明確に表面化したものがチームに同質性をもたらすためのキーになります。

まずは率直に本音で以下を聞いてみましょう。

・組織が自分のプロジェクトにどのような成果を期待しているか
・営業（≠お客さん）がチームにどのような成果を期待しているか
・自分達が自分達にどのような成果を期待しているか

これらが「ミッションを多角的に捉えたもの」になります。成果と書きましたが、売上とか成長、場合によってはノウハウやアンチパターンの収集も成果になり得ます。
多分たくさん出てきます。こんなに無理だよーって思うぐらいに出てくると思います。が、それが現実なので、一旦受け取りましょうね、一旦。

同質性を定義する

ここからが本番です。先程は「各方面」からの期待を集めました。次のステップでは「各観点」で期待を整理して同質性を定義していきます。と、言葉で書くと難しそうですが実際はそこまで難しくないです。先の期待を以下の観点で整理するだけです。

・我々が扱っている案件は社内（社会）においてどのような価値を持つか
・我々は案件に対してどのようにコミットしなければならないのか
・我々はお客さんにどのような体験をもたらさなければならないのか

1つ目に「社内（社会）」と書きましたが、ここはプロジェクトによって切り替えて問題ありません。ただし、両方はNGです。ここで整理する時に重要なことは各観点に対して文章は長くなっても良いのですが、「本質的に意味することは1つだけである」状態にすることです。また、抽象度は高くしすぎず、解釈はある程度の方向に収まるが具体ではない程度の抽象度が良いと思います。抽象のハシゴ（牝牛ベッシー）で言えば5段階程度だとちょうど良いのかもしれません。
サンプルですが、以下のような形になるかと思います。

■我々が扱っている案件は社内においてどのような価値を持つか
初めてのラボ開発案件であり、実験的位置付けとなる。
ラボ開発におけるプラクティスまたはアンチパターンの収集に対し大きな価値を認める。

■我々は案件に対してどのようにコミットしなければならないのか
既存システムは稼働中であり、いかなる理由であってもシステムが止まることはお客さんの業務が止まることとなる。案件へのコミットは様々な観点があるが、我々が最も重要視することは「お客さんのビジネスを止めないこと」である。

■我々はお客さんにどのような体験をもたらさなければならないのか
ラボ開発においてお客さんが強く感じる不安は「納品が無く、どのように進めたら期待を満たす働きをしてもらえるかどうか」であると考えられる。
チームの状況が見えづらいためお客さんは不安を覚えられると思うが、「状況を可視化し、チームが受け身ではなく、お客さんの期待を満たすために能動的に率先して動いてくれるという『安心感』をもたらす体験」を届ける。

文章はやや長いですが、本質的なものは「ラボ開発におけるプラクティスまたはアンチパターンの収集」「お客さんのビジネスを止めない」「『安心感』をもたらす体験を与える」になります、短くシンプルで本質的ですね。解釈の方向はある程度収まりますが、具体的に何をすると明言はしていません。多分これぐらいがちょうどいいと思います。これらを成し遂げるために様々なバックボーンや考え方（多様性）を持つメンバーが活躍するイメージですね。
今作ったこれが「チーム・ジョブ・ディスクリプション」になります。気が付いたら作ってましたね。

ここから先はおまけです。

チーム・ジョブ・ディスクリプションから「チーム憲章」を作る

チーム憲章とはチーム・ジョブ・ディスクリプションから「チームがどのように機能したら、ジョブを満たせるか」を定義するものになります。どのような内容を記載するかはチーム次第ではありますが、チーム・ジョブ・ディスクリプションから1段階抽象度を低くしたチームの価値観や尊ぶべき行動等を定義していきます。弊社で考えると以下の内容を記載するのがベターかなと思います。

・ミッション（我々は何を成すのか）
・我々の最も大切にしている価値観
・我々が考える最高のチーム像
・デリゲーション
・我々が最も尊ぶべきこと
・我々が評価する行為や行動
・WorkingAgreement
・我々の「これまで」
・我々の「これから」

少し内容が多いですが、網羅を意識して多くしてあります。不要な項目を削除したり観点を変えたり追加したり、カスタマイズしてチームに最適化してもらえたらと思います。

おそらくこんな感じになるだろうと思うサンプルを以下に記します。
（サンプルなので内容は薄いです、雰囲気だけ理解してもらえたらと思います）

○○チーム憲章（例）

■ミッション（我々は何を成すのか）
我々は○○の保守運用を通して以下のことを実現する。
・ビジネスに直結するシステムの継続的安定提供
・システムを介したユーザエクスペリエンス向上
・お客さんのビジネスを加速させる機能開発
・ラボ開発におけるプラクティスまたはアンチパターンの収集

■我々の最も大切にしている価値観
我々はエンドユーザに素晴らしい体験を届けることを最も重要な価値観として持つ。

■我々が考える最高のチーム
・統一された明確な意思をメンバー全員が持っていること
・意見や提案に対して正しく衝突することができていること
・ユーザエクスペリエンスファーストであること

■デリゲーション
※チームが「どのような権限を有しているか」を明記する

■我々が最も尊ぶべきこと
我々は以下のことを尊び・真摯に向き合い、真摯に向き合っている人に最大の敬意を払う。
・契約交渉よりも顧客との協調
・計画に従うことよりも変化への対応

■我々が評価する行為や行動
・プロダクトに関わる全ての人と「謙虚」「尊敬」「信頼」を持ち接すること
・不確実なことに対する挑戦の結果として得られた失敗
・「願い」と「戦略」の分離

■WorkingAgreement
※「チーム内」での約束事
・ミーティング中に議事録係以外は携帯やPCを触らない
・残業はしない
・テストはモデル必須。E2Eは画面系があれば必須。
・レビューが通過したものだけマージ化
・毎日10:15にデイリースクラムを行う
・振り返りでWorking Agreementの見直しを行う

■我々の「これまで」
所謂チームヒストリー、各対象期間は各チームに任せるが目標設定サイクルと同じで良さそう（弊社の場合四半期）。

■我々の「これから」
弊社の場合はOKRを記載すればOKかな
　□Objectives
　　Objectivesそのまま記載
　□KeyResult
　　KeyResultそのまま記載

判断に困った時やどうしたら良いかわからなくなった時に「困ったらここに立ち返れば大事なことは思い出せる！」と言えるのがチーム憲章、というイメージで持ってもらえたらと思います。

チーム・ジョブ・ディスクリプションとチーム憲章から「ジョブ・ディスクリプション」を作る

ジョブ・ディスクリプションについてはこちらを参照してもらうとイメージが付きやすいかなと思います。

イメージとしては以下のような内容になるかと思います。

フロントエンジニア・ジョブ・ディスクリプション（例）

■ミッション
○○システムのUI改善を通じてUX向上を図る

■必要なマインド
・チーム憲章に共感できること
・エンドユーザファーストであること
・自己の正解ではなく対話を通してチーム・プロダクトの最適解を導くことを楽しめること
・調和に必要な対話を正しくできること

■職務内容
・企画・デザイナーと連携してUI改善を通し、UX向上に寄与する
・新規システムのPoC作成

■要件（Must）
・Reactを用いた開発経験
　State管理やビルドシステム周りの理解があること
　Jestを用いたUnit Testの経験
・Git知識
　reset, revert, branch, checkout, marge, rebase等の基本コマンドが扱える
・スクラムでのチーム開発経験があること
　チーム開発における礼節をわきまえていること
　自己のテリトリーにこだわり過ぎていないこと
　開発者としての参画経験1年以上

■要件（More）
・Reactを用いた開発経験
　Jestを用いたComponent Test、E2E Testの経験
・Git知識
　ブランチ戦略（Git Flow, GitHub Flow）への理解
・スクラムでのチーム開発経験があること
　スクラムマスターとしての経験

ここでのジョブ・ディスクリプションを作る目的は人事評価ではなく「個々のミッションに集中できるようにすること」と「人の出入りがあった時にチームの戦力を可能な限り維持する」ことが目的になります。それぞれの目的を少し説明します。

個々のミッションに集中できるようにすること

チームに役割があるのと同様に、それを達成するためにメンバーには役割（ミッション）があります。これを明確にすることで個々が不要な価値観や意見に惑わされずに自己のミッションに集中することができると考えています。しかしながら、これはデメリットになり得る要素（自己のミッションに拘り過ぎてしまう可能性）も孕んでいるため、ジョブ・ディスクリプションを作る時はミッションやスキルだけではなく、「必要になるマインド」についても記載すべきかと思っています。チームカルチャーへにフィットする人で無ければパフォーマンスも上がりませんしチームも苦しくなり、Lose-Loseになってしまいますね。

人の出入りがあった時にチームの戦力を可能な限り維持する

「チームを守る」ということにも繋がるのですが、人の出入りが多いチームはチーム全体の戦力（生産性やパフォーマンスと言い換えても良いかもしれません）を維持することが非常に困難です。必要な技術のキャッチアップ、業務知識の引き継ぎやオンボーディング、カルチャーフィット等、要因は様々ですが多くの場合、人の出入りがあった場合には一時的に戦力の低下が起こります。
業務知識に関しては仕方ない部分はあるのですが、技術やカルチャーフィットに関してはジョブ・ディスクリプションを作っておくことで、この内容にマッチするか否かでチームに人を採用するひとつの基準になり得ると考えています。言い方が少し雑になりますが、最低限のレベルを担保できるとも言い換えられます。
人の出入りが多いチームではない場合も事業・プロジェクトにの拡大に伴い人を入れることがあると思います。その時にも役立つでしょうし、採用の場においても「どのような人が求められているか」をリアルな現場ベースで求められている人が可視化されるので人事観点でも作成しておくと良いと思います。