🚩
【プロジェクト】開発者はプロジェクトの時間収支に厳しいので、依頼のボールは丁寧に梱包して、時間泥棒にならないように渡そう

2025/08/01に公開
 はじめに

 対象開発者に仕事を依頼するときに気を付けるポイントが知りたい方向け。

 気づけば開発者が事務的プロジェクトで以下のような現象が起きていないでしょうか。
開発者に作業を依頼したが、なかなか動いてもらえない。
開発者からの確認が多く、やり取りに時間がかかる。
作業進捗が芳しくなく、工数も膨らむ。
少し前まであんなに親身になって対応してくれていたのに。いつの間にか作業を依頼しても「チケット起票しておいてください」と抑揚のない返事が返ってくるだけ。
それ、もしかしたら時間泥棒になっているサインかもしれません。
この記事では開発者との連携をスムーズにし、時間泥棒にならないための「ボールの渡し方＝依頼方法」について、現場で得た知見をもとに解説します。

 なぜ開発者は時間に厳しいのかなぜ開発者が事務的な反応を返すようになってしまうのでしょうか。その背景には開発者ならではの、時間に対する価値観があります。ここからは開発者がどんな視点で依頼やコミュニケーションを捉えているのか、もう少し深掘りしてみましょう。

 礼儀2.0に真似ぶ時間対効果
礼儀2.0の本質はシンプルで「いかに相手の時間を奪わないか」というものです。別件ですがタイムパフォーマンス（タイパ）なんて言葉も流行るくらいです。時間はもはや仕事と趣味とを問わず貴重なリソースといっても過言ではないでしょう。
さて開発者は多かれ少なかれ、同じ業務をいかに効率的に消化できるかを重視する生き物です。数時間かかる作業を自動化し、数分にすることに達成感を感じます。社内目標で自動テストのコスト削減や作業効率の向上を掲げているところもあるようですしね。
開発者は時間を奪う行為には、滅茶苦茶シビアです。汗水垂らして5分削減したのに、平気で30分奪われたのでは興ざめです。タイパが悪いところから改善を求めるのは当然で、見込みなしと取られれば余計な仕事を増やしてでも、時間を奪われないように行動を開始します。
このため自分にできる範囲で「いかに開発者の時間を奪わないか」という観点が重要です。
プロジェクトは複数人の役割の違うメンバーが、相互に関わって運用されます。開発者はその役割の一つに過ぎません。開発と営業、開発と運用、あるいは開発者間でのボールのやり取りにおいても、この「いかに開発者の時間を奪わないか」という暗黙の了解のような原理は働きます。

 プロジェクトの時間を奪わない流儀
このプロジェクトという集団全体でいかに作業効率を高めることができるか、つまり常にプロジェクト全体の時間収支を意識することが重要です。例えば相手の時間を奪わないために、自分の時間を無限に譲渡するという行為は、あまり褒められたものではありません。
もし開発者に依頼すれば5分で終わる作業を、運用が相談なしに20分かけて行ったとしたら、プロジェクト全体としては15分の損失です。教育目的であえて時間をかける場合や、他の作業で既に手が塞がっていてやむを得ない場合など、例外を除いてです。
プロジェクトの時間収支が見えているメンバーは、「どの役割のどのメンバーが、どこまでの作業を済ませて、どこから次のメンバーにボールを渡したら、最も効率が良いか」を常に考えて動いています。単に自分の仕事の消化しか見えていないメンバーとは見えている世界が違うのです。
だからこそ収支がマイナスに振り切った瞬間に赤字に悲鳴を上げ、メンバーからの上手いパス回しを受けて称賛し、必要なところで時間を投資できる余裕に感謝する訳です。
そしてこの時間収支鑑定スキルは、マネージャーやリーダーなどプロジェクトの計画を立てる層と、納期を厳密に決められがちな開発者に多いのです。

 開発者へのボールの丁寧な渡し方では「どのようにボールの渡し方を工夫すれば、開発者の時間を奪わずに済むのか」を具体的に見ていきましょう。

 テンプレートを活用して抜け漏れを防ぐ
よくあるケースに不具合報告の情報が不足しているというものがあります。
環境・バージョン
ログインユーザーの種別
画面URL・操作方法
実際の結果・想定する結果
多くのプロジェクトではテンプレートを用意し、それに沿って記載すれば抜け漏れなく事象が把握できるようになっています。テンプレートを無視した簡易的な報告では、どうしても不足する情報が出てきてしまい、追加のヒアリングや調査により多くの時間がかかってしまいます。
報告者が不具合画面のURLを控えていてくれさえすれば、想定する結果をきちんと書いてくれていれば、この時間コストが生じることはなかったのに。そう思い至った開発者は、本来は必要のなかった時間を奪われていると感じてしまいます。
これは何も開発者の時間だけではありません。ヒアリングのための打ち合わせ時間、チャットでの仕様確認や返事待ち、不具合を再現して思い出しながらの追記。抜け漏れだらけの報告は結果的に、報告者自身の時間をも奪い、関わった人全ての時間を奪います。

 雑な梱包を蔓延させないための施策
多くの場合、テンプレートがないか、テンプレートを無視した運用に至る原因には、以下のようなものが考えられます。
仕様・製品に対する理解が追いついていない。
チケット管理ツールのスキルが不足している。
業務内容がキャパシティをオーバーしている。
開発者ならこのくらいで分かるだろうという過信。
この状況を解決するためには、上記の原因を一つずつ解消していくしかありません。例えば、
製品や仕様に関する理解を深める勉強会を定期的に実施する。
各種ツールの使い方の勉強会・参画者への説明を行う。
メンバー補充や業務内容の見直しを行う。
でしょうか。
残念ながらこれらの施策をもってしても、上手く荷造りができない方は出てきてしまいます。というよりも出来る方はこれらの施策をしなくてもできるし、出来ない方はこれらの施策をしてもできないというのが、現場で遭遇した実態です。
次善の策として報告業務を代行してもらうという方法があります。例えば運用や営業などの役割ごとに報告責任者を決めておき、彼らに対して口頭で報告してもらい、事象を確認した報告責任者がチケットを起票するという方法です。これは余剰人員が確保できれば有効な方法です。
それでも厳しい場合は「原則出社に切り替え、問題が起きた時点で開発者をデスクに呼ぶ」のが最も確実でしょう。その場で事象を再現し、必要な情報を控え、直接ヒアリングを行い、自身でチケットを起票する方法です。
最後の方法は開発者の時間消費こそ激しいですが、プロジェクト全体で見れば、あれこれ施策を実施するより遥かに低コストで受取が可能です。ただ、ここまでくるともう梱包の上の発送ではなく、スーパーに行って段ボールに商品を詰めて持ち帰る方が、例えとしては近いかもしれません。

 他のケースに応用する
ここまで不具合報告の例を通して、開発者へのボールの丁寧な渡し方を説明してきました。しかし実務では他にも多くのボールのパス回しがある筈です。顧客からの要望に対する突発的な開発作業や、仕様に関する調査などです。これらもパターンごとにテンプレート化しましょう。

 テンプレート＝約束事を守るということ
テンプレートが揃ってくると業務上のボールのやり取りがずっと楽になります。その理由は伝えるべき情報の予測が付くようになるからです。これは丁度、荷物を送ろうとしたとき「郵便番号・住所・氏名・電話番号などが必要だ」と思い浮かぶのに似ています。
更にテンプレートは改善していくことができます。業務に合わない部分が出てきたら、より優れたものに更新していけばよいのです。毎回の小さな改善の積み重ねが、将来的なボールの受け渡しコストをとても安く抑えてくれます。
テンプレートを無視する＝約束事を守らないということは、これらの恩恵を受けられないということです。また約束事を決めたにも関わらず守らないという行為は、相手の信用を減らします。
テンプレートはいわば梱包材と送り状のようなものです。本来は粗雑な梱包や住所に不備のある荷物は、窓口で断られて然るべきです。ところが開発の現場では時々、通販サイトでも考えられないような状態の荷物を玄関に放置し、苦情は一切受け付けないということもあるのです。
このようなプロジェクト運営を続ければトラブルが頻発し、開発者にまともに取り合ってもらえないばかりか、下手をすれば部署異動や転職すらも視野に入ってくるでしょう。そのくらいでと思うかもしれませんが、そのくらいの積み重ねがやがて亀裂を生むのです。

 おわりに
テンプレートによる手続が基本ルールに組み込まれている現場は、ボールのやり取りがスムーズに進んでとても働きやすいです。
現場では一人ひとりが時間を大切にしていました。ケチるとか節約するとか、そういう意味ではないですよ。必要な時と場面でというか、自分の時間の使いどころを把握してるというか。ああいうのを時間の使い方が上手いというんでしょうか。
少しずつでもいいので、プロジェクト全体の時間収支の意識と、業務上のやり取りのテンプレート化を進めてみてください。まずは形からでもやってみましょう。