本記事は DMMグループAdvent Calendar の16日目です。
私はDMMでエンジニアリングマネジメントに携わっています。
自身の現在の担当領域を Engineering Manager Advent Calendar 2019 の 広木 大地さんの記事のEM定義を元に表現すると、おおよそ以下のような割合です。
| 領域 | 割合 |
|---|---|
| ピープルマネジメント (人事労務管理や組織設計を含む) | 60% |
| テクノロジーマネジメント | 10% |
| プロジェクトマネジメント (部門横断案件など) | 20% |
| プロダクトマネジメント | 10% |
はじめに
プロダクトを開発運用していく際、DevOpsを実現するためにある程度確立されてきた開発手法やツール群は存在するものの、人同士のコミュニケーション(通信的不確実性)に対して言及されることが少なく感じているため取り上げたいと思い立ちました。
TL;DR
- 事実 / 解釈(意見) / 判断 を区別する習慣をつけ、状況に応じた必要情報が何かを整理しておく
- 緊急障害対応時は、時系列の事実・対策(何をどこまで試したか)・暫定対応・恒久対応を一覧性が高い状態で見える化する
- 緊急度の高い要件の対応時は、関わる作業者の情報同期タイミングを決め、スコープ(やらない事)と次に誰が何をやるかを明確に伝達する
- 仕掛かりのタスクは、全体像(目的)・手順・ステータス(どこまで終わった)を明確に伝達する
申し送りとは
申し送る こと
→仕事などを引き継ぐとき、必要な事項を後任者に言い伝える こと
〜ベネッセ国語辞典 電子特別編集版 より〜
辞典から引用すると上述の通りですが、特に医療(看護)・介護の現場で耳にすることが多く、ソフトウェアプロダクト開発運用の現場だと同様の意味合いとして「引き継ぎ」と丸めて言ってしまうことも多いと思います。
「引き継ぎ」と「申し送り」の違いについて、厳密な定義が存在する訳では無いですが、私は前任者から後任者へ担当が移る際の猶予(許容可能な)期間の差だと考えています。
| 用語 | 猶予(許容可能な)期間 | 特徴 |
|---|---|---|
| 引き継ぎ | 長め (数時間〜数ヶ月) | タスクや業務など、比較的大きな粒度 |
| 申し送り | 短め (数分〜長くても2時間以内) | 特定の役割での現状共有 |
なぜ必要なのか？
連続的(継続的)なサービスの提供や対応が求められる状況下で、何らかの理由で同じ人が対応し続けられない場合があると思います。具体例としては以下のような事が挙げられます。
- 24時間(基本的に土日祝も)稼働するサービスの各種窓口対応
- 定時付近に何らかの障害や緊急の問題が発生し翌日に持ち越すが、外せない休暇や別業務の予定がある
- 自身の体調不良・私事都合・社用・環境要因(天候など) による早退/欠勤
- フレックスタイム制や時短勤務による勤務時間のズレ、海外地域との時差
- 属人性・優先度の高い、同時並行で進めざるを得ない割り込み作業
このようなシチュエーションでは、スピーディな作業担当の交代が求められることは想像に難くないでしょう。
申し送りの技術
便宜上3点に分けました。
全て重要なのですが、もし順番を付けるとしたら上から優先度が高いです。
①事実/解釈/判断を明確に分ける
マッキンゼーの問題解決フレームワークの1つとして「空・雨・傘」が有名です。
コンサルタントの問題解決というと如何にも難しそうな印象を持つ人も居ると思いますが、普段の業務にも欠かせない考え方で、部分的にはフレームワークを知らなくても出来ている人も多いと思います。
| 種別 | 用語の対応関係 | 補足 |
|---|---|---|
| 事実 | 空 (事実認識・事実把握) | 情報(起きたこと)・データ ≒ 証拠・根拠 を収集する |
| 解釈 | 雨 (分析・解釈・意見) | 証拠から何が言えるか、自分の考え |
| 判断 | 傘 (判断・行動・提案) | だからどうするのか、どうして欲しいのか |
良く起きがちなミスは、以下が挙げられます。
- 事実と意見が混ざっている(切り分けられていない)
- 意見や提案だけを言うので根拠が不明瞭で判断できない
- 主語が抜け落ちており、事実の正確性や情報量に抜け漏れがある
- 事実と解釈を言うまでに留まり、何をして欲しいのか伝わらない(伝えられていない)
勘所としては「論理を飛躍させない」ことと「単語や表現を正確に発言する」ことに気をつけたいところです。
②時系列と項目別を使い分ける
ソフトウェアプロダクトの特に運用においては、稼働し始めるとそう簡単に止められないことが多いと思います。システム保守のためのメンテナンスを実施する時でさえ、綿密な事前準備と計画の上、停止時間が最小になるように工夫されています。
だからこそサービス運営において困るのが、何らかの要因による障害や緊急度の高い要件の対応です。
事前予測が難しく(出来ないことが多い)、発生してしまった後は早期に対処が求められるため、開発運用の他作業を一時中断する割り込みタスクとなる訳です。
障害対応と緊急要件対応で、それぞれのコツがあります。
障害対応
以下の点に、一覧性が高い状態で見える化しながら対処する。
- 時系列の事実・対策(何をどこまで試したか)
- 暫定対応
- 恒久対応
医療に例えるなら、まずは血を止めることが最重要であり、どこから血が流れ出ているのかを特定することが必要となる訳ですが、該当箇所を含めた原因を特定するための調査がファーストステップになります。
そして二次被害(対処したことによって被害を拡大・悪化させること)を避けるため、事実・対策の見える化が必要になります。見える化には、物理的に近い1箇所で作業できる場合、ホワイトボードを用いることが多いです。
緊急要件対応
以下の点に、スコープと分担を意識しながら対処する。
- 関わる作業者の情報同期タイミングを決める
- スコープ(やらない事)を明確にする
- 次に誰が何をやるかを明確にし、伝達する
緊急度の高い要件は、発生理由が様々あると思いますが、事前把握が少ない状況の場合は調査が必要でしょうし、どこまでの範囲で対応するかを関係者の間でやりとりして決める必要もあると思います。
障害対応の場合は、期待する動作が明確(動いていたものを動くようにする)なので問題が起こることが少ないですが、緊急要件の場合は「期限がなるべく早く」とされゴールやスコープが最初は曖昧な事が多く、曖昧なまま進めてしまうと手戻りや方向性のズレが起きてしまう危険があります。
仮に1人だけで対応する際でもこのようなリスクが高い状況なので、1日の営業日内で対処が終わりそうにないことが分かった段階で、早期に対応人数を増やしたり交代に備え情報共有の方法を整理する必要があるのは、想像に難くないと思います。
③目的・現在状態・ネクストアクションを意識する
普段から属人化しない(最低限、1人だけしか出来ない状態は生まない)ような業務の分担・ドキュメント化・育成などは、とても重要ですが、全員が漏れなく出来る状態には現実的に中々できないと思います。
そのような中で開発運用のタスクを各自進めている訳なので、特定の誰かが緊急対応しなければならない割り込み作業が発生した際は、仕掛かりのタスクを誰かに任せざるを得ないことも出てくると思います。
仕掛かりのタスクを任せる場合には、以下の点を漏れなく伝えるようにしたいところです。
| 観点 | 気をつけるポイント |
|---|---|
| 目的 | 目指すゴールやDoneの定義を明確にし全体像を意識する |
| 現在状態 | 手順が明確になっているものは、どこまで進んだか 手順が曖昧なものは、どこまで考えたか |
| ネクストアクション | 次に何をしようとしていたか 関わる他者が居る場合は繋いでおく |
おわりに
申し送りの技術と題していますが、スピード感が求められる状況で有効なものは、緊急のものでなくとも普段から手法を取り入れることで広い業務範囲のスピードアップに繋げられると考えています。
まずは申し送りに適用頂いた後は、適用範囲の拡大にチャレンジしてみて頂けますと幸いです。
参考資料
- エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド(広木 大地, 2019)
- エンジニアリング組織論への招待：リファレンスガイド第１章/第２章(広木 大地, 2018)
- 【資料公開】Effective DevOps(株式会社アトラクタ 吉羽龍太郎, 2018)
- 「空・雨・傘」フレームワークは論理的思考の道しるべ(本気経営.com, 2016)