はじめに

うめりんです。前回は意思決定のためのトレーニングでした。
まだご覧になっていない方は、記事に順序性は無いので後からでもご参考にして頂ければと思います。

③すぐにトレードオフの説明ができるように、普段から思考を整理し情報が集まるようにしておく

考え方はエンジニアに限ったものでは無く、誰でも応用可能なものです。

なぜ必要なのか？

リーダーになると「(1)プロダクトやサービスにおける目に見える機能」だけでなく「(2)関連のあるシステムや仕組みの全般」にも、常に気を配らなくてはならなくなります。
ここでは便宜上、(1)をビジネスサイド要件、(2)をエンジニアサイド要件、と仮に呼ぶことにします。

ビジネスサイド要件は、エンジニアを含めた関わる全ての人達から依頼がくる可能性があり、絶えることはほとんど無いと思います。
しかし、エンジニアサイド要件は、エンジニアから発信しないと他の誰も気にしていないことが多く、往々にして事前予測が難しいため後から出てくることが多いです。
そのため、ビジネスサイド要件で予定の100%が埋まっていると、エンジニアサイド要件が出てきた際、どう詰め込むのかという議論が起こりがちです。
また、エンジニアサイド要件の検知・相談・対処が遅れると思わぬ被害が出ることも少なくありません。

具体的に何をすれば良いのか

まずは、トレードオフそのものについて詳しく知ってください。
wikipediaも参考になりますが、ソフトウェア開発においては、QCD（Quality：品質、Cost：コスト・価格・費用、Delivery：納期）のそれぞれが"トレードオフの関係にある"と表現されることが良くあります。
ただし、これらはゼロかイチかでは無く、バランスを取ること（妥当な基準の合意形成）が重要になります。
そして、今回のビジネスサイド要件とエンジニアサイド要件におけるトレードオフの対象となるのは、最初は「時間」です。
例えば、ビジネスサイド要件に割り当てる時間を90%に減らし、エンジニアサイド要件に割り当てる時間を10%とした際に、ビジネスサイド要件に割り当てる時間が100%だった時に得られるはずだった売上・利益・価値（顧客体験など）が何かしら失われるはずなので、ビジネスサイド要件で失われるものと、エンジニアサイド要件を実施することで得られるもの（またはエンジニアサイド要件を実施しないことで失われるもの）とを天秤にかけて、どちらを選ぶか（最適な、両要件の割合・QCDの割合）を判断するという流れになります。
トレードオフを語る際にQCDだけを引き合いに出すと「品質が高ければバグが起きないはずで、バグが起きないなら費用も納期も守れるはずだ」と一見正しそうなことをおっしゃる方がいるので、そういう時のためにも「誰に対しても有限である時間の観点をセットで会話すること」が望ましく、過剰品質や過剰性能という言葉も覚えておいた方が良いです。

次に、エンジニアサイド要件を列挙し、何らかの変更が起きる可能性と影響範囲を洗い出す方法を考えておきましょう。
エンジニアサイド要件の観点例（変更や発覚の可能性）は、以下の通りです。
・扱うコンピュータ環境全般における、OS/コンパイラ/インタプリタ/ミドルウェア/ライブラリ/エンジン/ツール/SDK/IDEなど、のバージョン
・ソフト受け入れ側（顧客やプラットフォームなど）の、審査基準・検収条件・システムプロトコルやレギュレーション
・システム動作環境における、リソース（CPUコア、メモリ、ストレージ、ロケーション、通信帯域など）の数/管理方法（省電力、アクセス権限など）
・意図しない挙動、技術的負債（処理速度、データ構造、データ量など）、セキュリティ脆弱性
可能性と影響範囲を洗い出す方法は、変更頻度が分かっているものは時期を明確にしておく、資料で受領する類のものは内容をしっかり確認し有識者にも教えを乞う、発覚する類のものはコミュニケーションフロー（起きた時に誰から誰に連絡するか）を明確にしておくなどが挙げられます。

そして最後に、「何らかの変更」を検知できる仕組みを作っておきましょう。
検知と表現すると真っ先に通知を自動化するが思い浮かぶと思いますが、それ以外にもリリースノートやロードマップを定期的に確認する担当メンバを割り当てたり情報感度の高いメンバをアサインしたり、変更を見つけたら教えてくださいと全体に言っておくだけでも一定の効果はあるので、デジタルなエンジニアリング以外の方法も併用して無理のないやり方を模索してみて下さい。

おわりに

エンジニアからエンジニア以外の人達に対してもそうですが、1人のメンバーからリーダーに対しても使える考え方ですので、お試し下さい。