スクラム開発チーム解散!? 効果的な引き継ぎを考える

2019年7月9日アジャイル開発,スクラム開発,チームビルディング,ファシリテーション,モブプログラミング

お疲れさまです! ソリューション開発部の本間です。

ここ数年「モブプログラミング」が盛り上がっているようです。そんな中、私の仮説に「モブプログラミング(モブワーク)をしていれば、引き継ぎは不要なのでは?」というモヤモヤがあります。

「モブプログラミング」を簡単に説明すると、チーム全員で

・同じ仕事を、
・同時に、
・同じ場所で、
・同じコンピュータで、

行う活動です。

Mob programming – Wikipedia

“プログラミング" とありますが、プログラミング以外の作業(ドキュメンテーション等)も含んでいることが多く、「モブワーク」という言葉の方が実態に即している気がします。(この文章では「モブプロ」で用語を統一します)

モブプロ自体についてはいろいろな方の記事があるので、検索して参照していただくのがおすすめです。

モブプロしていれば引き継ぎは不要になる?

AgileHandover」(邦訳は「アジャイルな引き継ぎ」)というMartin Fowler氏の文章があります。この記事では幾つか引き継ぎ事例を上げていて、それらに共通することとして、渡す側と受け取る側が一定の期間一緒に働く、ということが読み取れます。この「一緒に働く」が、まさにモブプログラミングと重なるように思うわけです。

このように強力な後ろ盾を(勝手に)得たことで、私の仮説は自信を深めつつありました。

そんなときにあの出来事が起こったのです…!

そうです、チーム解散と引き継ぎです。

前提

解散といってもチーム全員がバラバラになるといった「強い」ものではなく、配置転換で数人が抜けるという実態です。とは言えメンバーの増減があればもう同じチームとは言えません。いったん区切りとしての「解散」と残るメンバーへの引き継ぎをする運びとなりました。

私たちチームのこと

私たちはこんなチームでした。(過去形)

  • 8人のスクラムチーム
    • うち、開発チームは5人
    • メンバーの開発経験年数は幅広い
    • スキルセットはバラバラ
  • スクラムチームを結成してから10カ月
  • 開発チームはモブプロをしている(いつも一緒に作業をしている)

私たちの「モブプロ」は、プログラミングだけでなく、設計・調査・作業計画づくり・ドキュメンテーション、はてはCI環境の構築といったことも一緒に行っていました。(まさに「モブワーク」…!)

一緒に作業することの効果

そんな働き方をしていると、メンバー間で共有できていることは意外と多いことに気が付きます。

  • プロジェクトの目的/スケジュール/進捗状況/進め方/体制
  • 開発成果物(アプリやサービス)の使い方
  • アーキテクチャ
  • クラス設計やデータモデル/UI設計
  • ソースコード自体(コードの共同所有)
    • 設定ファイルの項目と意味
    • ログの読み方
  • コーディング標準やパッケージ構成/ビルド手順/デプロイ手順
  • CI環境
  • gitの運用ルール
  • クラウドなどのアカウントや、クラウド上の資材
  • 作ってきたドキュメントと、それらがどこに置いてあるか
  • どういった経緯/基準/設計判断で現状になっているか
  • 何を選んできたのか、何を選ばなかったのか(その理由も)
  • 決定を遅延させていることと、今後取りうる選択肢

こうやって列挙してみると、これ以上何か、残るメンバーへ引き継ぐことがあるのか…? といった気持ちになってきます。

引き継ぎについて、一般的なこと

次に、チームの中の観点から離れて、一般的な観点から引き継ぎのことを考えてみます。(頭の体操)

引き継ぎ資料

一般的に
「引き継ぎ」
と聞いてどんなアクティビティが頭に浮かぶでしょうか?

そう、引き継ぎ資料を作ることが、頭に浮かぶのではないでしょうか。

  • 引き継ぎ資料を作る
    • 業務のうち、何を引き継ぐ必要があるか洗い出し、資料を作る
    • 定常業務はもちろん、緊急対応についても記載する
    • 悩んだときに頼ることができる相談窓口を記載する
    • 相手のスキルに合わせて、記載内容を過不足なく書きたいですよね
  • 次の担当者へ引き継ぎ資料を説明する
    • できれば、実際に仕事をやって見せながら説明する

資料に記載する内容を考えてみると… 私たちはシステムを開発しているので、次のような内容になるでしょうか。

と一度列挙してみたのですが、前述の「一緒に作業することの効果」項に上げた内容と丸かぶりしてしまったので省略します!

丸かぶりどころか、上の一覧で強調表現したような点は、「引き継ぎ資料を作る」という観点からは出て来づらい傾向があるのでは…? (個人的調べによります)

こういったことは資料に書くことが難しく、また書いてあったとしても読み手が理解するには書き手のコンテキストをまず理解する必要が出てきそうです。

(再掲)

  • どういった経緯/基準/設計判断で現状になっているか
  • 何を選んできたのか、何を選ばなかったのか(その理由も)
  • 決定を遅延させていることと、今後取りうる選択肢

→ 私たちチームでは、引き継ぎ資料に書くようなことはモブプロによって共有されているので、あらためて引き継ぎ資料を作る必要性は低そうです。引き継ぎとは別に、必要なことはドキュメント化してきていますし。ただメンバーのスキルに差がある分は何らかのフォローがあると、ありがたそうでもあります。

もう少し自問自答してみる

次に「引き継ぎ」の成功条件について考えてみます。

問い: 「引き継ぎが成功した状態」とは?
答え: 「後任者によって、業務が問題なく行われている状態」と考えます。(もちろん、引き継ぎ資料は大切ですよ!)

問い: そもそも、どうして引き継ぎが必要なのか?
答え: その人しか「その仕事」をできないから。

→ 私たちチームでは、残るメンバーが業務を行える状態と言えるので、どちらも解決していそうです。スキル差によるものについては前項と同様です。

と、一般的なことについて思考実験してみました。「モブプロは引き継ぎを不要にする」仮説が補強されたように思います。

私たちの引き継ぎアクティビティ 〜 不安を表明して緩和する 〜

※免責事項!
「これが良い!」と強くオススメするものではありません。
「こういうやり方もあるよ」という1つの実装として読んでいただけましたらと。

さて、引き継ぎしなきゃとチーム内で会話したところ、前述のように意外と多くのことを共有できていることに気が付きました。そうは言ってもメンバーが抜けることへの不安はあります。

「XXさんがチームから抜けたら、困る場面がありそうだ…」


こういうときは、不安だ不安だと言っていてもしょうがないので、不安なこと/困りそうなことを表明し合うことにしました。ホワイトボードとふせんの出番です。(実物はお見せできないので再現イメージです)

ホワイトボードと付箋紙で不安なこと/困りそうなことを表明しあう。

メンバーごとに1列になっています。上エリアのふせんは自分が書きます。

  • 作業や知識が自分に偏っていて、引き継いだほうが良いと考えていることを表明する。
    • 個人で作業して、まだ共有できていないこと
    • チーム外との連絡の窓口になっているようなこと

下エリアのふせんは、自分以外の人が書きます。

  • その人がチームから抜けたら困りそうなこと、今のうちに聞いておきたいことを、その人にリクエストする。
    • 特定のジャンルに強いこと(製品や言語)
    • 強いジャンルへのキャッチアップ方法
    • 決定を遅延してきたことについて、今後その人だったらどう判断するか

そして、ふせんのテーマ1つずつについて話し合いました。時間は1テーマについて10分くらいかけ、質問者の意図や不安な点を引き出し、質問された人が考えを伝えました。一方的に説明するというよりは、テーマについて意見を述べ合うというスタイルでした。

テーマの傾向は、「現状についての説明」ということよりも、「今後どうしていこう」という指針を求める内容が多めだったように思います。

ここまで話し合うことで不安が緩和され、仮に引き継ぎ漏れがあったとしても「やることはやったのだから(想定外のことが起きても)仕方がないや」、という覚悟が定まったように思います。

ところでこのアクティビティって、汎用性が高いと思うのです。どうでしょうか? (「自分からの開示」と「他者からのリクエスト」のセットと考えると使い所がありそうですよね)

私たちの引き継ぎを評価する

10年以上前のものですが、日経BPのサイトに「続・深刻なシステムの引き継ぎ問題」という記事を見つけました。開発現場での引き継ぎにまつわる困りごとについてアンケートし、幾つかを取り上げている内容です。

こういった困りごとが、私たちの状況にどれくらい当てはまるか、リトマス試験紙として扱ってみようと思います。(私たちと状況が同じではないので、若干フェアではありませんが)

記事には5点が上がっています。

  • 経緯がわからない
  • 資料が多すぎて把握が手間
  • いざ修正しようとする段になって、修正する箇所がすぐに分からない
  • 資料が古く、現状のシステムと乖離がある
  • 定常業務はこなせるが、修正やトラブル対応のやり方が分からない

これらを私たちに当てはめてみると…

経緯は一緒にやっていて共有できているからOK、資料にまつわるものもOK(資料ベースで引き継いでいないため)、将来の修正についてはコードを共有しているのでおそらくOK、といった具合です。心配がゼロとは言い切りませんが、かなり低いと考えます。

気づいたこと/学んだこと

ここまでお付き合いいただいてありがとうございます。
(思いのほか、文字数が増えてしまいました…。詰め込んでしまったかも)

引き継ぎ手段について、資料ベースと、一緒に作業するという対立軸を、モブプロという観点から考えてきました。結論めいたこと、気づいたことを最後に記します。

「モブプログラミング(モブワーク)をしていれば、引き継ぎは不要なのでは?」という仮説に一言で答えると「担当者たちがそれで納得すれば」です。納得がそれは、画一的な「引き継ぎ」というものはおそらく無く、引き継ぎを減らすにはどれだけ普段から情報共有できているか、というコミュニケーション設計が大きく影響するでしょう。

引き継ぐために日常的なコミュニケーションを設計することはあまりしないと思いますが、情報共有のためにコミュニケーションを設計することは多かれ少なかれやっていると思います。

情報共有度を上げていくことで、副次的に引き継ぎ作業の必要性が下がっていく、という逆相関関係になっていそうです。

あらためて、モブプロの懐の深さというか、守備範囲の広さを感じました。「現状」の共有はできると想定していましたが、次のような表層に現れづらい事柄も共有できていることに気づいたのは収穫でした。

(再再掲)

  • どういった経緯/基準/設計判断で現状になっているか
  • 何を選んできたのか、何を選ばなかったのか(その理由も)
  • 決定を遅延させていることと、今後取りうる選択肢

過去にあったことなのですが、引き継ぎを受けていても作業の成果物がどうも違うな… という場面があり、その原因は上記の事柄が引き継げていなかったためなのだろうな、と思い至ることができたためです。

引き継ぎが予定されている場合は、Martin Fowler氏が書いたように、一緒に働く期間を計画するのが良さそうです。その一手段としてモブプロするのは効果を期待できるでしょう。(いろいろ考えた割には、Fowler先生の手のひらの上から出られていない感が…)

みんなもモブプロしたら良いと思います。書いてきたような良いこともありますし、純粋に楽しいですよ。

ではまた。

  • Zabbix Enterprise Appliance
  • 低コスト・短納期で提供するまるごとおまかせZabbix