開発組織に関するポエムです。
背景
常駐や請負で、サービス開発チームのお手伝いをしたことがあります。 私に依頼がくる時は、サービスは売れていて、開発チームは拡大期にあります。 その時、開発者の人数は増えているが、開発リーダーの負荷は減らず、逆に増え続けるという現象を観測したことがあります。 過去に2件、目撃しました。
課題
開発リーダーはすべての「問い合わせ」と「機能拡張の意思決定」に参加する必要があります。 おまけに自分の実装タスクも持っています。 必然的に労働時間は伸び、「いつ寝てんだこの人？」という働き方をしています。
はたから見ていると、何年も続けられる働き方はないので、いつか破綻しそうな危機感があります。 実際、2件のうち1件の開発リーダーは退職しました。
果たして、我々はこの状況に対して何かできるでしょうか？
経験談
開発メンバーの視点
開発メンバーからはリーダーが大変なことはわかります。 ただ、どんな問題を抱えているのかはわかりません。 この立場でできることは
- 要件を一度でなるべく細く聞き取る
- リファクタリングを避けてレビュー工数を減らす
- 修正点を最小にしてレビュー工数を減らす
などでした。このためには、受け入れるタスクを小さくする必要があります。 タスクが大きいと、リーダーとの相談量が増え、リーダーへの割り込み量が増えます。
アウトプットが少ないと評価されるのを覚悟で、手戻りにリーダーを巻き込まない強い心が必要です。 実際は、これができる人とやっている人は、とても少ないように思います。
開発リーダーの視点
今年の9月から11月に掛けて、炎上プロジェクトのリーダーをやりました。 立場は違いますが、共通する点もあるかもしれません。
炎上中のリーダーは手を止めることができません。 次のいずれをやめても、プロジェクトの進捗止まります。
- 各機能の仕様や実装方針の意思決定
- ボトルネックになる機能の実装
- 進捗の把握
- 顧客への進捗の報告とスケジュール調整
特に困るのがタスクを切り出す作業です。 タスクとして切り出したものは、開発メンバーにお願いできます。 問題をどのように解決するか、考えタスクに落とす部分は一番負荷が高いです。 一方で、それまでの経緯などコンテキストへの理解が必要であり、簡単に移譲はできない部分です。
また、プロジェクトの遅れに責任を感じているリーダーから、「プロジェクトを一度停止して体制の修正をしたい」とは言い出しづらいです。
方法の一つとして、リソースプランナー役の人に入ってもらって
- 進捗の把握
- 顧客への進捗の報告
を巻き取ってもらうと、だいぶ楽になります。 経験するまでリソースプランナーは要らない役職だと思っていました。 実際はすごく頼りになります。 ただし、感覚としては20%ぐらい楽になるぐらいです。 すでに120%以上の稼働に達している場合は、それほど効果がありません。
問題
- 開発メンバーからはリーダーの本質的な課題が見えない
- 開発リーダーは作業を止めることができない
開発チームからボトムアップで状況を改善することは難しそうです。
アイデア
ワイガヤやったらいいのではないかな？と思います。
この手のコミュニケーションのミスマッチは、「サービスに対する熱意の差」みたいな誤解に基づいている気がします。
- リーダーは、俺がこんなに頑張っているのにメンバーのやる気が足りない
- メンバーは、俺も頑張りたいのに、どう頑張ればリーダーの役に立つのかわからない
熱意とかやる気は、見た目に差があっても内部的に差があるかはわかりません。 一方で、サービスに対する興味のある点や価値観は、開発メンバー全員が違うはずです。 今のフェーズに、たまたま価値観が合っている人が「熱意がある」ように見えているだけではないでしょうか？
そんなわけでワイガヤです。 サービスの開発を数日止めて、 二泊三日の合宿でサービスに対する思いを表明しあってはどうでしょうか？
- 次の施作案
- 既存の気にくわない点
- 俺の感じるかっこよさにマッチする点、マッチしない点
- どんなユーザーに使わせたいか
色々なアイデアがあると思うので、決めるためでなくて、「みんな、そんなこと考えてたのかよ！」と思うための会をとことんやるといいのではないかな？と考えました。
参考：「ホンダ流ワイガヤ」実践のコツと方法を、元ホンダ 本間 日義氏にインタビュー ｜ビジネス+IT
実践したことはないので、与太話です。
うまくいけば
すくなくとも開発リーダーの気持ち面で時間は稼げそうです。 その隙に、「雑用タスク何でもできるマン」*1を投入して、開発リーダーの持っているタスクまで落ちていない作業をタスク化。 チーム内に振りまいていけばなんとかなるでしょう。 開発リーダーの稼働が80％ぐらいまで落ちれば、もともと優秀な人ですから、あとは自分で改善できるはずです。
*1:例えば、私。ただ、目に見えるアウトプットは、通常の開発者とは違うので、そういうjob descriptionの元でないと怖くてできません。
