現場リーダーの視点からみたQCDSのはなし

3-10名程度の開発チームリーダーをやってきた中でのごく個人的な見解です。
SaaSでアジャイル開発をたしなんでおりました。
役割はスクラムマスター的な管理者^[1]兼エンジニアリングマネージャー兼プロダクトマネージャー少々という感じでした。

なんの話？

おなじみアジャイル「荒ぶる四天王」の話です。
半年ほど前にもちょっと話題になりましたね。

ネタ元は名著「アジャイルサムライ」の第5章です。似たような話題は探すと定期的に浮上しているみたいです。

そもそもアジャイルサムライにはこのように書かれています。

予算と期日は厳守すべきとされる傾向が強く、スコープは見境なく気ままに広がり続けていきがちだ。そしてもちろん、品質は常に最優先事項だ。

で、別にわたくしから真新しい見解（優先順位とか）があるわけではないのですが、これらについてチームを回す役割の者の視点の生の声があまり見当たらないので記事にします。

開発リーダーはとにかく「船を沈めない」が役目

私の開発リーダーとしての役割は中世の貿易船の船長のような感じでした。
ナビも自動航行もないし急にシケは来るし航海中に人員が潤沢になることもない。その中で時には航路を変更し、時には積みすぎた荷物を一部諦めたりしながらなんとか生きて目的地までたどり着く、そしてまた次の航海に向かう。というのが職務を果たす中での心象風景です。

その中で開発に関する優先度としては

1. 船を沈めないこと（サービスを提供不能にしないこと）
2. メンバーを潰さないこと
3. できる範囲で要求を実現すること

といった順でした。「要求」の中に納期、品質、スコープが含まれますね。

正直リリースできないことよりチームが崩壊するほうがヤバい

たいてい失敗したり炎上したりするケースは欲張って要求の実現を最重要視することで無謀な航海が強行され、結果として座礁したり破損箇所が取り返しつかなくなったりするのかなと思います。
そしてなんとか港に着いても乗員が寝込んだり愛想を尽かしたりして離脱すると次の航海にでるのもままなりません。

そのためメンバーを大事にすることを重視しました。無理をさせても次に続かないのなら意味がありません。
もちろん甘やかしはしませんが、無益に苦しめる必要はないです^[2]。

本題：スコープを削るかメンバーのライフを削るか

＜Q＞品質を落とすとエンジニア体験が落ちる

Developer Experienceとか言われるやつです。（これDXって略すんですかね？）
昨今、エンジニアの転職は当然のことです。良好なエンジニア体験を提供できなければメンバーの退職リスクが高まります。仮に人員補充があったとしても、再教育コストや有識者メンバーの失われた知見などを考えれば大損です。

低品質なリリースは苦痛

職人肌のエンジニアにとって、満足いかない品質のまま機能を世に出すことはプライドを損なう体験です。今後も同じように楽しくないリリースが続くと考えると、チームから気持ちが離れることもありえます。

リリース後も胃が痛くなる

そもそもバグや障害はどうしても出るときは出ますが、低品質なコードをリリースするということはその懸念をさらに高めるということです。
私は「出たら直せばいい」と図々しく考えていますが、責任感の強いエンジニアは非常に気にします。また後続のスケジュールに不確定要素が増えるので、見通しが立たないことがストレスになる人もいます。

いずれにせよメンバーにいらん精神ダメージを与え、離脱リスクが高まります。

＜C＞戦力は増えない

人月の神話系の文脈で語られることが多いですがそれ以外で。

そもそも間に合わない

頭数を増やしてもまともに戦力になるまで3ヶ月はかかります。そのうえ業務委託を最速で入れても募集を掛けてから入社まで1ヶ月を切ることはないです（正社員なら良くて2ヶ月ですかね）。
アジャイル的にはそれほど長くかかる機能開発はあまりなく、遅延が発生してから人を増やそうとしてももはや手遅れです。

急に人を増やすのは既存メンバーに負担

人員を戦力にするには当然育成が必要です^[3]が、それには「教育担当メンバー」が先に必要です。で、それは既存戦力メンバーです。
そもそも新入りの面倒を見ることで工数を奪われる問題はもちろんありますが、それ以上にマトモな教育体制ができないうちに人を増やすのは新参メンバーにも教育担当メンバーにも心理的負担があります。
また人に教えるのが苦手なエンジニアもいるので、そのあたりのケアも必要です（幸い、私のチームメンバーは面倒見のいい良い先生ばかりでした）。

メンバーの負荷を下げるには以下の気の長い準備をすべきでしょうが、まずはそこに時間を割けるだけの余裕が以下略🐔🥚

• 教育資料や仕様を整理した資料の整備
• ヤバいコードを減らす
• CI/CDや環境構築手順の整備

既存メンバーを寄せるのはコスト管理ではない

特定の遅延タスクを人手で解消する、という意味では「別タスクの担当を寄せる」という視点もありますが、これは結局チーム全体で見たら別タスクのスコープを削っているだけなのでコストコントロールではありません。

＜D＞リリース日を延ばすのもよくない

締切が延びても間に合わない

これは確信を持って言えます。
なぜなら私が夏休みの宿題を終わらせられない人間だからです。自由研究の提出日が9月1日から9月10日になったところで間に合いません。10月1日でも一緒です。

エンジニアは作り込む生き物ですし、延長を決定してからさらなる見落としに気づく生き物でもあります。
実際の開発でもあと1週間で間に合うと思ったら2週間、1ヶ月かかることは珍しくないです。

もちろん以下どちらかならアリです。
・途中で大々的に計画が狂った
・マジであと1日あればってレベル

リリースを延期するとめっちゃ気に病むメンバーもいる

実装担当者が若く真面目なひとの場合、スケジュールを乱すことに責任を感じることがあります。
（個人的には破綻した計画引いたやつが悪いと思いますけど）

で、この目先のリリースを延期するということは次のタスクも遅れるわけで、年間の開発スケジュールを乱すことになります。これもまた責任感を感じる案件です。

＜S＞スコープはある意味贅肉

スコープはなんなら削ったほうが良いことも大いにあります。スコープを削るのは、機能群の中で優先度が低いものの対応を辞めるということだからです。
大抵の機能開発はなんだかんだ過剰機能になります。設計段階でどうでもいい機能まで盛ることもありますし、実装者がついついオーバーエンジニアリングに突き進んでしまうこともあります^[4]。

MVP的な考え方に近いですが、中核的な機能さえあれば多くのユーザーにはそれなりの価値があります。のこりは一部のユーザー・利用シーンにしか意味がなかったり、提供側の自己満足で実は大した価値はなかったりもします。
であればそういうものはとっとと削ってしまえば、時間もお金も掛からず、仕様がシンプルになることで品質維持もしやすくなります。Less is Moreってやつですね。

まとめ：結局はリーダーの腕前が問われる

やることが減ったらメンバー的には嬉しいですが、とはいえスコープの優先度付けや削っていいかの判断はリーダー層（スクラムマスターやPdM）の役割です。また社内のビジネスサイドや声の大きい顧客など、各種ステークホルダーと適切にコミュニケーションを取り制御できなければ成立しません。

私の場合、船を沈めないために必死^[5]だったのでとにかくメンバーとコミュニケーションを取り遅延やトラブルの芽に気を配り、社内の諸方面に「あまりにも工数が足りない」「既存メンバーが1人でも離脱したら詰む」「でかい障害出ても詰む」と手を替え品を替え刷り込むことでなんとか業務が回り続ける状況を作れました。

いい感じの締めの言葉は特に浮かばないですが、皆さんも楽しく日々の開発にあたっていただけたらいいなーと思います。

脚注

1. 非スクラムのアジャイルだったので、あくまでスクラムマスター「的な」役割です

2. そもそも仕事ごときで他人を苦しめたり追い詰めたりする正当性は誰にもないです。

3. 「育成」以外に「選抜」という手法もあります。「生き残った使えるヤツだけいればいい」というカスみたいな人間性のアプローチです。そういうチームは居心地とかいう概念がないのでこれまたエンジニア体験も悪いです。

4. オーバーエンジニアリングはアジャイルのほうが症状がひどくなる印象ですが、仕様書が明確なウォーターフォールでも「もうちょいキレイに書きたい」と思ったりして発生します。

5. 私が担当していたサービスでは未対応要望山積み、人員は慢性的に足りない、毎月（下手したら毎週）なにかのトラブルが出てくるという状況でした。その中で基盤バージョンアップや発掘された不具合の解消をやりながらなんとか新機能を作っていくカオスでした。そのうえ社内では私が担当するもの以外にも複数のプロダクトが併存していて、そっちがボコスカ離任者が出ていました。これがうちのチームに波及するとマジで沈没すると容易に想像できたので却ってメンバーのケアに本気で当たることができました。