問題解決ダンジョン

ソフトウェアエンジニアリングにおいて、問題解決のプロセスはゲームなどでよくあるダンジョン探索に似ているように思う。

何かしらの問題があったとして、それを解きましょうとなったとする。 まず前提として、多くの場合、問題に対する解空間が広いということを理解する必要がある。 問題を解くというのは、たった一つの冴えたやり方を見つけるのではなく、広い空間の中から何かしらの解を１つ選ぶという行為である。“解く”と言いつつ”選んで”いる、というのは重要な視点なように思っている。多くの場合に妥協を伴うということを理解しないと前に進めなくなってしまう。 この、解空間を探索して解を選ぶ、というのがなんだかダンジョンを探索してお宝を１つ持ち帰ってるみたいだなと思っている。

問題が与えられると、解空間の”ダンジョン”が現れるので、それに潜るわけである。 全てのダンジョンに対して隅々までマッピングして、もっとも良いお宝を持ち帰ろうとすると時間がかかるが 労働において工数は金を消費するので、頃合いをみて切り上げる必要がある。 探索はやりまくれば良いというわけではない。

探索を短く済ませるにはダンジョンの形がわかっていることが重要である。 例えば、よくある構造として「工数」と「機能」みたいな”軸”（≒“次元”）がある。工数をかけるほど豊かな機能が実装される。 当然のことである。この２軸においてお宝を選ぶ方法としては、松竹梅メソッドなどが知られている。

それ以外にも色々な軸があり、例えば、セキュリティ、プライバシー、負荷、コスト、互換性、信頼性などは多くの問題でひとまず考えてみると良さそうな軸である。クラスターのdesign docのテンプレートは、全てのダンジョンにおいて、まずはこれらの軸があるかどうかを考えてみるべし、という心得になっているように思う。

対象の問題が100%技術的なものだとしても、組織やチームやプロダクトやユーザーが解空間の構造に影響を与えてくるので、同じダンジョンは１つとして無い。 目の前のダンジョンに潜って何かを持ち帰るのは自分たちにしかできないということも重要である。

逆にいうと、世に出回っている開発手法・パターン・メソッドなどは何かしらの具体的な問題（の集合）に対して選ばれて、一定の成果を上げた解答なわけだが、自分の目の前の問題に対して通用するかはわからないということになる。通用するかもしれないし通用しないかもしれない。どれを選ぶかは自分たちで決める必要があり、それに責任を持つ必要がある。

このような前提にたったときに、ダンジョンを探索するソフトウェアエンジニアにとって有益な情報とはなんだろうか？ まず、こういう問題に対してこういう解を発見した、という情報は有益である。 もっというと、どういう構造を発見したかはより有益である。何を選び、何を選ばなかったかという情報があると嬉しいわけである。 そして、選んだ解は実際どうだったかという話もまた有益である。実際やってみた結果どうだったかはやってみないとわからないわけで、それはとても貴重な情報である。

なんだか、とりとめのない感じになったが、まとめると、問題を解くというのは、広いダンジョンを限られた時間の中で探索し、何を持ち帰るかを選ぶということである。 同じダンジョンは１つとしてないので、銀の弾丸を望まずに自分の足で歩く必要があり、その選択の責任は自分たちにしか負えない、ということが言いたかった。

それはそうと、ダンジョン攻略情報というのは商売道具のはずだが、カンファレンスやテックブログなどで公開されることが割と多く、 そういうカルチャーが自分は結構好きである。 採用などの目的もあるのかもしれないが、利害は違えど皆ダンジョンに潜っている、という謎の仲間意識で成り立っている文化なのではないか、と勝手に思っている。