親愛なる友人へ、
いかがお過ごしですか？
「技術的負債を解消しない限り、進めません」
「KPIへの悪影響があるので、その変更は認められません」
このような判断と発言が、ソフトウェア開発の領域では、しばしば見受けられます。そして、このような判断によって、変化が留められ、前に進むことも、前に進みやすくすることも、いずれもができなくなる、ということがしばしば起きています。そして、これによって、苦しんでいる人や組織の話は、枚挙に暇がありません。
別に、この話を取り上げて、誰かを非難するつもりも、変化への免疫を示す人たち一般を責めるつもりも、私にはありません。ビジネスのこれまでを理解している人の意見は聞くべきですし、一般論として、人も組織も変化を好むものではありません。
しかし、これからのこと、そして、トレードオフをどうするか、という問いは投げかけねばなりませんし、答えられなければなりません。例えば、冒頭の判断がもし私の眼の前でなされたのなら、私は次のように問うでしょう。
「技術的負債の解消は、変更コストをできる限りフラットにするためのもののはずです。その解消が終わらない限り変更できないというのは、これからのリターンに見合うのでしょうか？ そして、その解消はどれほどに優先しなければならないのでしょうか？」
「そのKPIが2~3%未達になっても、この変更による将来に渡って得られるリターンが大きくなるのであれば、この先、このKPIはどうあるのがよいのでしょうか？ そして、いつこの変更をするべきでしょうか？」
これらの問いに、彼らは答えられなければならないです。
私がここで、開発都合によるビジネスの停滞と、ビジネス都合による開発の停滞を、それぞれ例として取り上げたのは、ただサンプリングしたのではなく、意図的です。というのも、
アーキテクチャに正解も誤答もなく、
ただトレードオフがあるだけ
であることを明示的に示したかったからです。
もちろん、人々が自分たちのできる限りでベストを尽くしていることは疑う余地はありませんが、開発もベストで、ビジネスもベスト、というのはおそらく存在しないでしょう。理想的な状況であったとしても、そこには、良いトレードオフの分析があるか、もしくは、より「まし」な選択があるか、というのが実際のところでしょう。
ある程度のシニアな職責の人なら、正解のない状況下で、このトレードオフをどうするか、ということについて、ソフトウェア、組織、ビジネス、いずれの次元においても、そして、それらの間においても、判断し、議論し、決定し、行動する、というのは当然できているでしょう。かといって、技術的負債を理由にするエンジニアも、KPIのことばかり考える営業職も、無能なわけでもEvilなわけではありません。ただ、トレードオフについて考えていないだけです。もしかしたら、組織の評価設計が悪さをしている可能性もあります。というのも、それらの言い訳を作れる力を持っていることや、評価で期待を寄せられていること、これらから推測するに、その人たちは、これまでの事業を理解し、そして推進する力を持っているはずだ、と判断できるからです。とするならば、言い訳をしている彼らにこそ、アーキテクチャを導いてもらうべきです。彼らにこそ、トレードオフについて考えてもらうべきです。
とは言っても、現実の業務の忙しさというのは残酷で、トレードオフやアーキテクチャについて腰を据えて考える時間なんてないよ、と言われるでしょう。ソフトウェアに限っても、可用性やパフォーマンスなどの構造特性、メンテナンス容易性や拡張性などの運用特性、セキュリティや達成可能性などの横断特性、これらの中と間にあるトレードオフを考え、アーキテクチャがどうあるべきかを考えるのは、少なくとも常にできることではないでしょうし、頻繁に行われるものでもないでしょう。
しかし、そのトレードオフについて、どこかで考える時間は絶対に必要だと私は考えます。理由は2つあります。1つは、そもそもトレードオフを分析し、念頭に置いていなければ、偏った判断になりがちだからです。これは、各々がそれぞれの領域で実現したいことや満たしたい特性を満たそうとすることであり、つまりは、全てを満たそうという無謀な挑戦をしていることになります。これは悪手です。
もう1つの理由は、トレードオフについて考える時間がないということは、そもそものトレードオフに変更を加えることもできなくなるからです。それは、変化や変更ができない状況を意味します。そして、悲劇的なことに、エンジニアや営業に限らず、すべての人が望んでいるはずの貢献したいという欲求の実現を阻害することになります。先日、逆コンウェイ戦略の誤謬についてNewsletterでお伝えしましたが、あれもまた、トレードオフについての判断に変更を加えるのを難しくする、変化しにくい環境づくりです。
「技術的負債があるから」、「KPIに悪影響があるから」と理由付けをして、変化をしないという判断がなされた時、トレードオフはどうなっているのかを考えるべきです。アーキテクチャはトレードオフがすべてです。それは、ソフトウェアの次元においても、ビジネスの次元においても、組織の次元においても、そして、それらの次元の間においてもそうです。たとえ答えが出なくても、変化が起きないとしても、トレードオフについて考え、アーキテクチャについて考えなければ、緩やかながらも確実な死が近づき、そして、私やあなたが望む知の発展も遅れるでしょう。
そして、トレードオフを分析する時、過去にどうしてそう判断したのか、今どうしてそう判断するのか、これらの理由もまた重要となります。事業のこれまでを理解し、事業を推進してきた人たちは、過去の理由と今の理由、さらには将来ありうる理由も分かるはずです。だからこそ、事業のこれまでを支えてきた人たちが、トレードオフの分析をし、アーキテクチャを導くべきです。
知の発展の場合も、アーキテクチャとその理由は重要です。どうしてそう判断したのかという理由が、その後の発展に影響を与え、そして、発展を促します。
もしあなたが、ソフトウェアや仕事に限らず、類似した状況に出会ったと思ったのなら、HOWを考えたくなるのを一旦は堪えて、WHYの部分を考え、トレードオフ、そしてアーキテクチャについて考えてみてください。それがあなたにとっての助けとなるはずです。
それでは、
青を心に。
Stephen S. Hanada
"Gentleman Philosopher"