2015年1月14日
開発者の仕事が遅いわけではない！納期が遅れるホントの原因
本記事は、原著者の許諾のもとに翻訳・掲載しております。
“なぜ納期を守れなかったのだろうか？”
我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？
Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと︵S、M、L、XL︶、また種類ごと︵ストーリー、テスト、バグ︶に、完了までにどれくらいの期間がかかるかを追跡しています。
3点目‥チームは、“完了”から“テスト済み、デプロイ準備完了”に移るときにも苦労する傾向が見られます︵上の図のCompletedからAcceptedを参照︶。
あなたのチームが納品までに時間がかかりすぎると感じていますか？ もしかすると、開発者たちに責任はないのかもしれません。
Sprintlyで何かするときは、“ As a ___︵依頼者︶として、*so that* ___︵目的︶のために、*I want* ___︵機能︶がほしい”というように入力する必要があります。この形式で入力しなければ、機能は追加できません︵これにより、開発者は適切に機能を追加することが可能になります︶。－Darren Rogan、 Hack and Heckle︵ポッドキャスト︶
このフォームを使えば、特定の機能の方向性を具体的に定めることができます。また、ストーリーのスコープを確実に絞り込むことができます。
新たなタスクが追加された場合は、開発が何日延びるかをProgress機能が教えてくれます。
この場合、さまざまなことに対応するリード・デベロッパという仕事の性質が、タスク完了に要する時間に影響を与えています。
問題は、あなたがマネージャとして、開発者を途中で新たなタスクに移らせた時に起こります。あなたの中の優先順位が常にコロコロ変わると、 チームに莫大なコスト をもたらすことになるのです。
Joel Spolskyは 彼の投稿 の中でコンテキストスイッチを激しく非難しています。
ここで本当に学ぶべきことは、誰かが一度に2つ以上のことをやろうとするのを絶対に認めるべきではないということです。これを相手にもきちんと分からせてください。良いマネージャというのは、プログラマが1つのことに集中してそれをきちんと完了させられるよう、障害となるものを取り除くという責任を自覚しています。緊急の案件が出てきたら、プロジェクトに集中しているプログラマにその仕事を頼む前に、自分でなんとかできないかを考えてください。
当社が調査した動向について
1点目‥開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目‥変動があるのは、ほとんどがチケットが開始される前︵SomedayからBacklogまで︶の段階です。これは、関係者が仕様を理解して作業の優先順位を決定する段階です。“かんばん”の世界では、一般的にリアクションタイム︵チケットが作成されてから優先順位を設定するまでの時間の合計︶と呼ばれます。この段階で多くの時間が費やされます。
3点目‥チームは、“完了”から“テスト済み、デプロイ準備完了”に移るときにも苦労する傾向が見られます︵上の図のCompletedからAcceptedを参照︶。
あなたのチームが納品までに時間がかかりすぎると感じていますか？ もしかすると、開発者たちに責任はないのかもしれません。
開発が遅れる本当の原因は？
開発が遅れるのが開発者のせいでないとすると、原因は一体何でしょうか？ ヒントはあなたのプロセスにあります。あいまいな要件
良い仕様書を書くのは重要なことです。もし開発者が機能の内容を理解していなかったら、どうやって開発を始められるでしょう？ ほとんどの場合、仕様書の作成者は全てを考慮していなかったことが判明します。それはいつも、設計や開発を始めてから問題が起きて、多くの仕様に問題があるせいだとなってから判明するのです。－eagerMoose︵ Stack Exchange ︶ 関係者が機能についてきちんと検討していないことはよくあります。開発者は、ユーザはなぜその機能が必要なのか、それはどんな機能で、どうやって使われるのかを理解する必要があります。 Sprintly では、Mad Libsスタイルを用いた以下のフォームを使ってユーザストーリーを作成します。
Sprintlyで何かするときは、“ As a ___︵依頼者︶として、*so that* ___︵目的︶のために、*I want* ___︵機能︶がほしい”というように入力する必要があります。この形式で入力しなければ、機能は追加できません︵これにより、開発者は適切に機能を追加することが可能になります︶。－Darren Rogan、 Hack and Heckle︵ポッドキャスト︶
このフォームを使えば、特定の機能の方向性を具体的に定めることができます。また、ストーリーのスコープを確実に絞り込むことができます。
要件の変更
当社の調査によれば、開発者が2番目に不満に思うのは、仕事が始まったとたんに仕様が何度も変更されることです。 Hacker Newsのユーザ、cognivoreがこれを説明する 良い例え話 をしています。 私たち‥ ﹁たった今、屋根を取り付けて、全部の壁を仕上げたんです﹂ 相手‥ ﹁私たちは今すぐ全部の壁を移動してほしいんだ﹂ こうなる主な原因は、ワークキューに入れる前に機能のプランニングを適切に行わないからです。 開発途中で要件が変更されるのを避ける1つの方法は、実際の開発が始まる前にインタラクティブなモックアップを作成することです。 詳細なプロトタイプを作れば、工期は短縮するでしょう。私たちは、ユーザのフローや操作を十分に検討しないために、実装してから検討し直して、開発をやり直さなければならないことがあります。－Tobin Harris︵Pocketworks取締役︶ 迅速に仕事を進めることが求められるからといって、いつでも自由にスコープを変更していいわけではありません。理想としては、途中で学んだことは将来的に反復できるように全て把握、考察しておきたいところです。 要件の変更︵及びスコープクリープ︶をとどまらせるもう1つの方法は、進捗に焦点を当てることです。Sprintlyには、1つの機能の開発を終えるまでにあと何日かかるかを予測できる機能があります。
新たなタスクが追加された場合は、開発が何日延びるかをProgress機能が教えてくれます。
コンテキストスイッチ
開発スピードを鈍化させる最後の要因は、コンテキストスイッチでしょう。これには複数の形があります。 (一)開発者が タスクA の50%を完了したところで、それをストップして タスクB をやってくれと頼む。 (二)開発者が タスクA の50%を完了したところで、 タスクBも 追加でやってくれと頼む。 例えば当社には、多くのコードレビューやペアリング、ミーティングへの参加、トラブル対応などを行うリード・デベロッパがいます。 以下のグラフは当社のチームにおける開発者のサイクルタイムを示しています。
この場合、さまざまなことに対応するリード・デベロッパという仕事の性質が、タスク完了に要する時間に影響を与えています。
問題は、あなたがマネージャとして、開発者を途中で新たなタスクに移らせた時に起こります。あなたの中の優先順位が常にコロコロ変わると、 チームに莫大なコスト をもたらすことになるのです。
Joel Spolskyは 彼の投稿 の中でコンテキストスイッチを激しく非難しています。
ここで本当に学ぶべきことは、誰かが一度に2つ以上のことをやろうとするのを絶対に認めるべきではないということです。これを相手にもきちんと分からせてください。良いマネージャというのは、プログラマが1つのことに集中してそれをきちんと完了させられるよう、障害となるものを取り除くという責任を自覚しています。緊急の案件が出てきたら、プロジェクトに集中しているプログラマにその仕事を頼む前に、自分でなんとかできないかを考えてください。
責任を持つ
マネージャとして、開発者の仕事がうまくいく環境を整えることが我々の仕事です。開発者たちを指差して納期の遅れを責める前に、自分自身はどうなのかを省みるべきです。 以下のステップを踏めば、あなたがチームの仕事を遅くすることは確実になくなります。 (一)チームがビジョンを理解できるようにする。チームのメンバーと一緒に、どうやってユーザの生活をより良いものにしていくかというビジョンを設定しましょう。ユーザが求めている成果を明確にしてください。開発者を賛同させるのは大切なことです。機能に対する開発者の情熱が、開発スピードを大幅に加速させ得るのです。 (二)明確なユーザストーリーを書く。作成するそれぞれのタスクについて、Mad Libのスタイルやテンプレートを使いましょう。開発者は、タスクについて詳細な説明がなされるまでやらないと言える権利を持つべきです。 (三)タスクの切り換えのコストを減らす。開発者の邪魔をしてはいけません。彼らにメールを送ったり頼み事をしたりする前に、彼らの生産性に与えるコストをよく考えましょう。 とにかく、開発者を“遅い”と責め立てることには、くれぐれも慎重になってください。彼らの仕事を遅くしているのは、あなたの ワークフロー である可能性がとても高いのです。-
サンプルはAcceptedとScoredのデータで、サンプル規模は147,494件です。 ↩
監修者
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。
現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。
2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。
Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa
