不確実性耐性と問題の樹形図
この記事は
道草 Advent Calendar 2025 - Adventar
23日目の記事です。
はじめに
ソフトウェアづくりでの不確実性をどのように操っているかを書いてみる。
ソフトウェアを開発にするにあたって、不確実性耐性が重要だと言われることがままある。これは、ソフトウェアで実現したいものが何か、どのように実現できる・すると良いのか、どのような順で実現していけるのかといった問題が、単純な問いではなく、曖昧で、ときに途中で変化するからだろう。やりたいことや実現方法、進め方が明確にならないと動けないのではソフトウェア開発は難しい。
著者はそういった曖昧な問いに対して、無意識的に樹形図を使って考えていることに気づいた。要するに「分解」と言えばそれまでなのだが、「分解」したものを全て解くわけではないというのが「分解」という言葉のイメージと異なるものだと考えている。
エディタ開発を例に
著者は自作のReact製のWYSIWYGエディタを持っているから、その開発を例にとって樹形図のイメージを説明しよう。
https://github.com/kumachan-mis/react-clay-editor
React製のエディタを開発にあたっては、いくつかの問題を解くことになる。今思いつくものを列挙してみると次のようになる。
- 新しい表示要素のサポート
- 冗長な表示要素の削除
- レンダリングの高速化
- APIとしての使いやすさの向上
- 動作環境の拡大
- Reactなどライブラリのバージョン追従
- 内部ロジックのシンプル化
- よりモダンな開発環境への移行
これらをざっくり分類しようとすると、以下のように分けたくなるように思う
- エンドユーザー向け
- パッケージ利用者向け
- 開発者向け
こういった「名詞による分類」はしばしば用いられるが、ひとつひとつが扱う範囲が広く、曖昧になってしまう。何より、ひとつひとつの小さな問題たちが、一体何に繋がっているのかを見失いやすく、モチベーションを保つのも難しくなってしまうだろう。
問題を樹形図で考える
そこで問題を樹形図で考えてみよう。先では問題の名詞による分類を行ったが、問題を樹形図にするのであれば、分類もまた問題になる。
- ユーザーにとって必要十分なエディタの機能はなにか？
- 多くエンジニアに使われるパッケージであるために必要なことは何か？
- 開発しやすいリポジトリであり続けるためにやるべきことは何か？
これらの問題は曖昧だが、より具体的な小さな問題を最初に考えているから、構えずに考えやすくなる。また小さな問題たちを解く価値も分かりやすくなる。そして究極的には、以下の問題を考え続けていることになる。まさに「根本の問題」と言ったところだろう。
- 「良い」エディタライブラリとはどうあるべきか？
不確実性耐性が高い人は、一見すると「ユーザーにとって必要なエディタの機能はなんだろう？」のように、抽象度の高い問題を考えているように見えるかもしれない。しかしながら、実際には「表が書ける機能ってあった方がいいのかな？どう作ろうかな？」と考えていて、ただその価値を表す上位の問題を忘れていないだけなのである。
樹形図の探索点同士にポインタを張る
著者の問題の解き方が1本道ではなく樹形図である以上、複数の問題を同時に考える瞬間はしばしば訪れる。例えば、作ってしまったけれどいかにも使われない機能を消す問題は、同時に内部ロジックのシンプル化を呼び起こす。エンドユーザーを意識していた対応が、開発者のためにもなっているということはしばしば起こる。
こういったことに気づくために、樹形図の探索点にポインタを張っておく。より正確には、ある問題を解いたときに、実は同時に扱いたい問題も解いた、あるいは解きやすくなったという変化がないかを考えている。隣同士の問題もそうだが、上下の問題についても同じだ。今解いたこの問題をもって、ユーザーにとって必要十分な機能が揃っていて、実はさらに足そうとしていた別機能は必要なさそうだとわかる、なんてこともある。これが、冒頭に、問題の樹形図化が「分解」とは異なると述べた意味である。
終わりに
ソフトウェア開発での不確実性耐性について、問題を樹形図にするという立場から述べた。樹形図と言いながら、この文章の中に図は出てこなかったが、これを読みながら整理することも、また不確実性耐性の一環ということでご容赦願いたい。頭の中で図を書いて、解けるところから解いていき、探索を続ける。これが不確実性耐性だと著者は思っている。
