一元的なトレードオフ構造に落とし込んではいけないという話

ソフトウェアの設計の話でもあるし、それよりももっと広い意思決定全般についての話でもある。

何か問題を発見し、それを解決するためのソリューションを生み出し、実現のための設計に落とし込んでいく時に、人はよく「トレードオフ」で物事をとらえる。この思考を行う時に気をつけていることがあるというのを言語化してみようと思ったので書く。

例えば、Aという問題があったときに、それを解決することで、Bという別の問題領域に対してデメリットを引き起こしてしまうことがある。大抵の場合は、その時の状況や制約を考慮してBという問題領域のデメリットをある程度受け入れながら設計を行い、物事を前に進めるための意思決定をしていく。要はバランスである。こういうものの考え方をこの記事ではトレードオフと呼んでいる。

この考え方自体は筋としては悪くないとは思うが、考え方に癖がついてしまうと、すぐに一元的なトレードオフ構造を見出して、あたかも正解を導いたかのように急いで結論を出そうとしてしまう。これをやってしまうと、結果的に一時的に問題を遠ざけているだけのような短期的な解決になってしまうことが多い。これは避けなければいけない。

過去に自分はとあるサービスの改善プロジェクトで「動画配信システムのストレージコスト削減を行う」という課題解決にチームのみんなでチャレンジしたことがある。このとき、単純化されたトレードオフで考えると「コストを削減すると、ユーザー体験を犠牲にする必要がある」となり、こういう考え方は結構一般的なものかとは思う。この場合ソリューションは結構単純に生み出せる。例えば、動画を保存するストレージを安いアーカイブ環境に載せ替える、ただし、ユーザーのリクエスト起因でアーカイブから復元するのには一定時間がかかる、などである。これ、実装してもいいんですがめちゃくちゃ大変そうですよね？しかも大変な割にユーザー体験は著しく悪く、誰も喜ばない結果が見えます。

細かいことは端折るが、サービス全体として本当にやりたい・やるべきなのは「コストを削減しつつ、ユーザー体験を維持もしくは向上する」であって、それが実現できるのが良い設計のはず。その課題に向き合っていたとき、結果的にどういうソリューションを生み出したかというと、「コストを削減することができる。また、多くのユースケースではユーザー体験は向上する。ただし、限定された一部のユースケースではユーザー体験を犠牲にする」という結論に落とし込むことができた。

この経験は自分の中では割と成功体験になっていて、「限定された一部のユースケース」という範囲をいかに極小化することができるのかが、アイデアと設計スキル、問題分析スキルの見せどころなんだと思うようになった。

つまり言いたいのは、一元的なトレードオフを見出してあたかも課題解決できたかのようなソリューションを設計するのではなく、もっと立体的・複雑に構造を捉えて影響をさせられる変数を見つけ、極小化された場所でのみトレードオフの構造を作り、ほとんどの場合ではあらゆる問題を同時に解決できているような設計ができるように妥協せずに思考していくことが重要なんだと思う、ということ。

多分これ、ソフトウェア設計のシーンだけでなく、組織マネジメントとかプロジェクトマネジメントとか、あらゆるシーンで通用する話だと思う。そして、この設計能力をトレーニングするためには、やっぱりソリューションと設計の組み合わせを「もう出ない！」っていうくらい何パターンも考えていくようなことが必要なんだと思う。