@ledsun blog

無味の味は佳境に入らざればすなわち知れず

サービス開発チームの拡大期におけるリーダーのレスポンシビリティ移譲に関する1アイデア

開発組織に関するポエムです。

背景

常駐や請負で、サービス開発チームのお手伝いをしたことがあります。 私に依頼がくる時は、サービスは売れていて、開発チームは拡大期にあります。 その時、開発者の人数は増えているが、開発リーダーの負荷は減らず、逆に増え続けるという現象を観測したことがあります。 過去に2件、目撃しました。

課題

開発リーダーはすべての「問い合わせ」と「機能拡張の意思決定」に参加する必要があります。 おまけに自分の実装タスクも持っています。 必然的に労働時間は伸び、「いつ寝てんだこの人?」という働き方をしています。

はたから見ていると、何年も続けられる働き方はないので、いつか破綻しそうな危機感があります。 実際、2件のうち1件の開発リーダーは退職しました。

果たして、我々はこの状況に対して何かできるでしょうか?

経験談

開発メンバーの視点

開発メンバーからはリーダーが大変なことはわかります。 ただ、どんな問題を抱えているのかはわかりません。 この立場でできることは

  • 要件を一度でなるべく細く聞き取る
  • リファクタリングを避けてレビュー工数を減らす
  • 修正点を最小にしてレビュー工数を減らす

などでした。このためには、受け入れるタスクを小さくする必要があります。 タスクが大きいと、リーダーとの相談量が増え、リーダーへの割り込み量が増えます。

アウトプットが少ないと評価されるのを覚悟で、手戻りにリーダーを巻き込まない強い心が必要です。 実際は、これができる人とやっている人は、とても少ないように思います。

開発リーダーの視点

今年の9月から11月に掛けて、炎上プロジェクトのリーダーをやりました。 立場は違いますが、共通する点もあるかもしれません。

炎上中のリーダーは手を止めることができません。 次のいずれをやめても、プロジェクトの進捗止まります。

  • 各機能の仕様や実装方針の意思決定
  • ボトルネックになる機能の実装
  • 進捗の把握
  • 顧客への進捗の報告とスケジュール調整

特に困るのがタスクを切り出す作業です。 タスクとして切り出したものは、開発メンバーにお願いできます。 問題をどのように解決するか、考えタスクに落とす部分は一番負荷が高いです。 一方で、それまでの経緯などコンテキストへの理解が必要であり、簡単に移譲はできない部分です。

また、プロジェクトの遅れに責任を感じているリーダーから、「プロジェクトを一度停止して体制の修正をしたい」とは言い出しづらいです。

方法の一つとして、リソースプランナー役の人に入ってもらって

  • 進捗の把握
  • 顧客への進捗の報告

を巻き取ってもらうと、だいぶ楽になります。 経験するまでリソースプランナーは要らない役職だと思っていました。 実際はすごく頼りになります。 ただし、感覚としては20%ぐらい楽になるぐらいです。 すでに120%以上の稼働に達している場合は、それほど効果がありません。

問題

  • 開発メンバーからはリーダーの本質的な課題が見えない
  • 開発リーダーは作業を止めることができない

開発チームからボトムアップで状況を改善することは難しそうです。

イデア

ワイガヤやったらいいのではないかな?と思います。

この手のコミュニケーションのミスマッチは、「サービスに対する熱意の差」みたいな誤解に基づいている気がします。

  • リーダーは、俺がこんなに頑張っているのにメンバーのやる気が足りない
  • メンバーは、俺も頑張りたいのに、どう頑張ればリーダーの役に立つのかわからない

熱意とかやる気は、見た目に差があっても内部的に差があるかはわかりません。 一方で、サービスに対する興味のある点や価値観は、開発メンバー全員が違うはずです。 今のフェーズに、たまたま価値観が合っている人が「熱意がある」ように見えているだけではないでしょうか?

そんなわけでワイガヤです。 サービスの開発を数日止めて、 二泊三日の合宿でサービスに対する思いを表明しあってはどうでしょうか?

  • 次の施作案
  • 既存の気にくわない点
  • 俺の感じるかっこよさにマッチする点、マッチしない点
  • どんなユーザーに使わせたいか

色々なアイデアがあると思うので、決めるためでなくて、「みんな、そんなこと考えてたのかよ!」と思うための会をとことんやるといいのではないかな?と考えました。

参考:「ホンダ流ワイガヤ」実践のコツと方法を、元ホンダ 本間 日義氏にインタビュー |ビジネス+IT

実践したことはないので、与太話です。

うまくいけば

すくなくとも開発リーダーの気持ち面で時間は稼げそうです。 その隙に、「雑用タスク何でもできるマン」*1を投入して、開発リーダーの持っているタスクまで落ちていない作業をタスク化。 チーム内に振りまいていけばなんとかなるでしょう。 開発リーダーの稼働が80%ぐらいまで落ちれば、もともと優秀な人ですから、あとは自分で改善できるはずです。

*1:例えば、私。ただ、目に見えるアウトプットは、通常の開発者とは違うので、そういうjob descriptionの元でないと怖くてできません。