Zenn
🐕

Web開発版「手が遅い」ことへの処方箋（手付け、手戻り編）

2022/10/13に公開
設計
レビュー
idea

これを読んで欲しい人のターゲット像や前提について

  • Web版開発の話をしています
  • ITのソフトウェアエンジニアの話をしています
  • ある程度チームのやり方に対して影響を与えられる権限がある人
    • マネージャーかメンバーかはあまり気にしないです
    • 「発言するのは自由だが聞き流されるだけ」ならこの記事を読む意味はないです
  • ある程度裁量権があり、ビジネスサイドとも話ができるチームのメンバーを想定しています

作業の流れの前提について

  • チケットがあって
  • 作業者がそれを取って（自分で取るのか他人にアサインされるのかは問わない）
  • PullRequestの形でレビュー依頼をかけてレビュワーがレビューする
  • OKならmergeしてそのうち本番デプロイ
    • 間にQAが入るかもしれないけどそこは問わない

手が遅いとは何か？

ある作業者のサイクルタイムが他の作業者に比べて長いこと

100の大きさの作業があるチケットを渡した際に、ほかのエンジニアなら着手からだいたい3日で終わる作業を、ある作業者は着手から完了まで平均5日かけていたとします。
この場合多くのリーダーやマネージャーはこの作業者を「手が遅い」と判断するでしょう。

「100の大きさ」は一定の人日あるいは一定の見積ポイントの作業と解釈してください。
単位量あたりの作業日数をここでは話題にしています。

サイクルタイムとは何か？

着手から完了までにかかる時間のこと
起票から完了までにかかる時間はリードタイムで、ここでは扱いません。

なぜ時間がかかるのか？

色々理由はあると思います。

  • 何らかのステータスが不足
    • 基礎的な知識がない、派遣会社がスキルを思いっきり盛った
    • そもそもやる気がない
  • 心身に何か問題がある
    • 前のプロジェクトで酷使され過ぎて心身が燃え尽きた
    • 家庭環境に深刻な問題があり、精神的にボロボロ
      • 離婚調停で揉めているとか、愛猫が余命幾ばくもないとか
      • 同担ズッ友だと思っていたパートナーが担降りしたとか
  • 環境に問題がある
    • パワハラ気質の上位者と耐性の低いメンバーの組合せ
    • 実は執務室が人口過密で酸素濃度が低く、心肺能力が低いので常に酸欠で失神寸前

とりあえず今回はそういう話は扱いません

もう一回言いますが今回はそういう話は扱いません

今回の記事では「手戻り」と「手付け」で進捗が悪くなる人の話をします

「手戻りが多い」とはなにか？

ウォーターフォールにおける手戻り

ウォーターフォール型開発モデルにおいては工程ごとにやるべき作業を常にやり切ってから次の工程に移ります。
この時にある工程で、前の工程でやるべき作業になんらかの瑕疵が見つかって、前の工程に差し戻されることを「手戻り」と言います。
手戻りは嫌がられます。
なぜなら発覚するまで次工程で行った作業のほぼ全てが無駄になるからです。

Web開発には工程がない。しかし手戻りはある

すみません工程がないはちょっと言い過ぎました。

しかしチケットを取って設計相当のことをして実装作業を行い、テストコードを書いて作業者が手元で実行確認を行い、プルリクエストの形でレビュワーにレビュー依頼する、という作業を行います。
これは実質「設計〜実装〜テスト」の工程をほぼ単独で作業者が行い、その上でレビュワーに見せます。

この際に設計の部分などで要件の見落としが発見されることもしばしばです。
この場合実質設計からやり直しする「手戻り」が発生します。

たとえばこの場合3日で終わる作業で2日分の時間を使い切ってからレビュー段階でほぼ全部ダメ！差し戻し！と言われて再作業になります。
それで再び3日分の時間をかけて作業をするから「３日で終わるはずの作業」を2＋3日で5日かかってしまうわけです。

往々にしてこの場合、作業者は「早くコードが書きたくて、設計をいい加減に終わらせてしまった」と評価されがちです。
あるいは全体の一部分のいいやり方が浮かんだのでそこを実装を始める > そこに合わせて他の部分のやり方も見えてくる > 一気に作業を進める
そしてレビューで全部差し戻される、というパターンです。

こういうメンバーの話を聞くと上司から「作業が遅い」と詰められ、より早く完了させようとして拙速に作業開始 > 見落とし発見 > 差し戻し > サイクルタイム悪化 という悪いパターンにはまっているように見えます。
「作業が遅い、早く作業をしろ」と詰められて早く作業開始しようとした結果ドツボにはまっているわけです。

「手付けが遅い」とはなにか？

チケットに着手してから、コードを書き始めるまでの時間がかかり過ぎている場合です。
あるいは何のチケットにも着手していない時間が多い場合もあります。

なぜコードを書き始めるまでが遅いのか

判断しかねているのです。

なぜ判断しかねているのか

横断歩道で信号が赤なら止まります。青なら進みます。
ここで3秒も迷う阿呆はいません。
車道にいて、信号は赤だけど直進と左折の矢印が出ていたら、初見なら2秒くらい迷うかもしれませんがそれは例外です（何度も迷うようならもう一度教習所へ行ってどうぞ）。

不確定な要素が多いとそれだけ人は判断に迷います。
そして不確定な要素の数と曖昧さは指数関数的に認知や判断の負荷になります。

「不確定な要素の数と曖昧さ」は同じ作業でも作業者によって異なる

ここで厄介な点は「不確定な要素の数と曖昧さ」が作業に影響するという点です。

その会社や仕事に古くから関わっている人間ならそれは不確定な要素ではないものがあります。
そういうものは、知識のある人間にとってはほぼ定数に近いものであり、あるいはどうすれば簡単に解決するのかを知っています。
「曖昧で不確定な要素」の数には含まれません。

しかし社歴の浅い人間など知識のない人間にとってはそれは分かりません。
「曖昧で不確定な要素」のままです。定数にはなりません。

ここで言っているのは以下のような物事です。

  • 水は何度で気体になるのか
    • 1気圧なら摂氏100度
  • 最高気温が何度ならジャケットやネクタイなしで出勤していいのか
    • 気温は関係ない。人事部のクールビズ期間を参照のこと
  • １年の毎月が何営業日で構成されるかはなにをもとにどうやって判断すればいいのか
    • 閏年、前年の政府発表の祝日の2つ。社内向けならさらに人事部が決める営業日カレンダーを加えた3つで判断できる
  • 「人生、宇宙、すべての答え」はなにか？
  • XXシステムのこの部分の正しい仕様はどこに書いてあるのか
    • 基盤開発部の古泉さんの脳みその中。古泉さんに聞いて。
  • 会社の全国の拠点一覧に記載されていない「阪神基地」とは何を意味するのか？
    • 大阪基地(泉南除く)と神戸基地は一部のシステムでは同一扱い。泉南支基地は含まない点に注意。
  • オブライエン「2たす2はいくつになるんだ？ 」

「不確定な要素の数と曖昧さ」が異なるとどう困るのか？

これはノエルティシー教授の提唱するラーニングゾーンの図です。
普通はComfort Zoneを出てLearning Zoneに進めという話に使われます。

今回は使い方が違います。
「不確定な要素の数と曖昧さ」が多すぎるとこの図で言う"Panic Zone"に作業者が突入してしまいます。

"Panic Zone"に突入すると

  • ミスが増え
  • 作業効率が著しく落ち
  • 不安やストレスが著しく増えます

Panic Zoneに突入してしまったために設計作業が遅々として終わらないのです。
あるいはそもそも不安やストレスが強過ぎてtwitterで現実逃避しているのかもしれません。
それで実装作業に入ることが遅れるのです。

「手付け」が遅れる要因

普通の作業者であれば、この設計作業はLearning ZoneやComfort Zoneに属する作業で半日で終わります。
しかし設計作業がPanic Zoneに属してしまう作業者にとっては効率が落ちてこの作業で１日以上かかってしまいます。
また設計の品質が低いために手戻りにもつながります。

それって、問題のある作業者の作業のスピードや品質が低いって話ですよね？

端的に言えばそうでしょう。
しかし作業者に対して「お前は作業のスピードや品質が遅い。なんとかしろ」と言って解決する問題でしょうか？
違いますよね？
なによりこのスタイルはマネージャーが丸投げし過ぎていて無駄に作業者を焦らせ、パフォーマンスを低下させつつミスしやすくするだけです。

能力不足を叱責しただけで挽回できるのは、問題が軽い場合だけです。
当人の能力不足をどうにかできる方法があるならそうした方がいいと私は考えています。

じゃあどうすんの？

基本的に上で挙げた問題は、設計作業あるいは「頭出し」のフェーズで作業者の知識や経験が足りず、品質的に不正な設計であるにもかかわらず設計作業を完了させた、あるいは無駄に長く設計作業に時間をかけてしまったことに由来します。

なので対応すべきは設計作業です。

基本はペア作業(in 設計)

能力や知識が足りない人間が、設計作業に非効率に取りくみ、ノーレビューで終わらせてしまうことに上記の問題があります。
なので能力や知識を備えた人間と組ませる、あるいは目玉をもう１揃い用意することで
設計作業を通常通りの効率で取り組み、レビュー済みで終わらせることを狙います。
ホワイトボードなどで大きく図を書いてやるのもよいですし、作業画面配信しながらやるべき場所にTODOコメントを打っていくのもいいでしょう

ここで解消したい問題

  • 能力や知識の足りない人間が設計作業に非効率に取りくむこと
  • チケットの説明だけでは足りない頭出し作業を知識のある人間と行うこと
    • 人間は知らないことを知ることは難しい。「有識者の視点」 があれば気付ける
  • 設計段階で犯した問題がノーレビューのまま実装やPRレビューまで進むこと

私が実際にやる場合の運用

私が実際にやる場合はさらに1commitずつ精査するためにfeature branchきって非常に細かい単位でmergeさせていくことになります
実装の足跡まで追跡するのを大きい単位で行うのは難しいので

これは能力が高い人間に能力が低い人間をカバーさせているだけではないのか

ペア設計作業を導入しない場合、要件漏れを含む杜撰な設計をもとに書かれた大きなPRのレビューがいきなり発生することになります。
この差し戻しやいちいち指摘するラリーの負荷は能力の高い人間にかかります。

ペア設計作業はこれを設計段階という「より前の工程」に転嫁しています。
不具合は埋め込まれてから摘出されるまでの時間が短い方がコストが短いというセオリーに沿った行動です。

いずれにせよ能力が低い(≒知識や経験が浅い)人間の作業は他のメンバーに降り注ぎます。
であれば教育効果が高いことで再発が予防できる、そしてコストが低い方法で対応できるペア設計作業の方がよりベターに見えます。

Discussion