Shepherd.jsを除去して
driver.jsを再実装する作業を終えた。
これらはインタラクティブツアーを実装するソフトウェアライブラリであり、機能は著しく似かよっている。
いずれかを選択して使えば良いものではあるのだが、じつはdriver.jsの方が圧倒的に優れている。これは両方実装した今になって分かることだ。
「選定段階に何か見落としがあったからdriver.jsではなくShepherd.jsを導入してしまったのだろう」と反省して評価プロセスを再点検してみたところ、想像とはまったく異なる構造を発見した。
要するに、混沌に対峙するには直観に反するメンタルモデルが不可欠だった。とくに能率指向がカオスへの耐性を直接削いでいる。
この話は、昨年書いた
フェイク・テクノロジーのエピソードと言える。
状況は何も改善していないので、ケースの積み上げで前進するしかない。
今回の例では、両者の決定的な違いは、Shepherd.jsがスマートデバイスの狭い画面で適切な位置に表示できない点だ。
解説する対象がポップアップの裏に回って見えなかったり、画面から見切れたりする。
やむを得ない限界なのかと思っていたのだが、driver.jsはずっと適切にレイアウト計算できる。
レイアウト計算が動作品質の大きなウェイトを占めるという事実には注目しづらい。
Shepherd.jsとdriver.jsの両方を用いて実装し、見比べたから気づいたことであって、決してその逆ではない。
言いかえれば、あらかじめ効率的に比較して労力を節約できるような道筋は存在しない。
各ライブラリのPRサイトはそうとう適切に解説していて、掲載情報にもとづいて選択するなら優劣はつかないだろう。
サンクコストの際たるもの
最初に採用するライブラリがShepherd.jsとdriver.jsのいずれであるかは五分五分だ。
driver.jsの方が高品質なのだが、現実にはShepherd.jsからdriver.jsに乗り換えるプロジェクトはあまりないだろう。
それは逆にdriver.jsからShepherd.jsに乗り換える選択を想像すれば理解できる。
すでに動作している機能の実装にかけた過去の労力はとり返すことはできない。
サンクコストという。
この問題を的確に扱うには、サンクコストの理解は欠かせない。
見通しのために説明は省略するが、過去の労力やコストを無かったものと捉え直し、無視することが判断のポイントだ。
損失認識の矛盾
サンクコスト効果に対するベストプラクティスによれば、初回のライブラリ導入は存在しなかったものと捉えるのが正しく判断する条件だ。
これは現実には、初回プロジェクトは失敗したと捉えるべきという意味に限りなく近い。
一般的には、ライブラリを導入した結果エラーも出ずに動作しているなら、それは成功と認識する。
成功に見える成りゆきを失敗と認識すべき、という矛盾した論理の飛躍をつなぐものは認知の歪みである。
テーマは誤認識なのだ。
少し経営技術について補足する。
この意思決定は、除却損を認識するか否かという選択のケースがあり得る。
除却損となればより強く回避したい心情が働くだろう。会計技術が誤認識を強化するアノマリーと言える。
そもそもソフトウェアを資産だと捉える認識が誤りであり、その後の判断を歪める構造なのだと思う。
会計じたいが原因なのではなく、根底にある誤認識を会計技術が忠実に描写しているに違いない。
比較できないという不確実性
そしてもう一点、「使ってみない限りソフトウェアの優劣は評価できない」という性質が不確実性を決定的にしている。
Shepherd.jsもdriver.jsもオープンソースであり、技術情報に不透明な点はなく、ドキュメントも充実している。だからこそ分かったことは、評価する観点の網羅を保証するものは何もないということだ。
不確実性の研究から、人間は複数の観点で総合評価することが苦手であることが分かっている。
いくつかの観点を確認したという行動だけで「評価できた」と錯覚する挙動を satisfice と呼ぶ。多くのソフトウェア選定プロセスが satisfice に終わっていることだろう。
オープンソースであるため、 shepherdのコードと driver.jsのコードを見比べてみたのだが、コードからも優劣を導くことはできないという結論に至った。なお、リポジトリは後のリファレンスのためフォークした。
多くのエンジニアは、Shepherdのコードの方が品質が高い印象を受けるのではないかと思う。コード構成が現時点で人気のあるTypescriptのスタイルに近いからだ。
driver.jsのコードはTypescriptのインターフェースであっても、Javascriptをよく理解している人が書くスタイルになっている。おそらくTypescriptのコンバートに伴う不確定要素を制御する意図なのだと思う。
そして、コーディングスタイルは両者の実用上の挙動の違いとは関係がない。コードレビューで事前評価する場合、コーディングスタイルやコメントに注目しやすくなり、そのことによりむしろ品質に目を向けられなくなる。
今回の例では、レイアウト計算の違いが重要であることを事後的に知っているが、それはコードのごく一部でしかないため注目することが事実上不可能だし、コード全体が機能したときどのような表示になるのかを読み取ることは無理だと分かった。
また、テストコードは
Shepherdのテストが優れていると誰もが言うだろう。
driver.jsのテストはダミーのままだ。
評価軸の網羅性を保証できないこととテストの網羅性を保証できないことは同一の原因から来ていると思う。とくにUIをチェックするテストについては、人が目で見た際の妥当性を検査するための語彙が欠けているため、品質に直結する分野のテストケースを記述できないことが多い。
再実装だけが正しさの確証へ導く
このように、後知恵を活用して選定の際の見落としをチェックした結果、さまざまな可能性が否定され、消去法により「あらかじめ品質に関する確証を得る手段はないのだ」という構造を理解できた。
比較不可能な性質があるからこそ、ランダムにソフトウェアを選択することになり、一定の確率で不都合が生じることでサンクコストが発生するという関係にある。
そしてサンクコストを適切に認識したとしても、代替ライブラリを適切に評価する手段はない。
自明な性質の積み上げで理解できる対象なら分析もできるが、ソフトウェアには自明ではない性質が多く含まれている。
けっきょくのところ、ソフトウェアの品質は未来から後ろ向きに振り返ることでしか評価できない。
すべての選択肢を実装し、ベストなもの以外を破棄するのが手堅いアプローチなのだ。
ブラックジャックに例えれば、カードをひいた時に合計21を超えてしまえばアウトであるところを、21を超えたことを確認してから余分なカードを捨てることによって高得点を保証するようなものだ。
ここではSheperd.jsとdriver.jsについて確認したが、他の選択肢についてはなおオープンであり、未来の時点で後発のライブラリをどう評価するかという形で直面することにもなろう。
視野を広げる
議論を明確にするために具体的なソフトウェアを題材にしてきたが、広く一般的な難問にはこのような形をとるものが遍在しているように思う。
たとえば進化生物学の研究には、多様性のボトルネックと環境への不適応の関係を説明する定量的な分析があるはずだ。おそらく適者生存は派生と死滅のセットであって、そこに目的と正解を見出すことが誤認識なのだろう。
金融の
リアルオプションも類似のアプローチをとっている。
経済学には解析的な手法で分析する理論が多いが、リアルオプションはとりうる選択肢をモンテカルロ法などで生成する。
モンテカルロ法では生成された予測値は確率的なパラメータに過ぎないが、結果に対数オーダーの差が生まれるのであれば仮説構造は安定する。リアルオプションが戦略策定に用いられるのは、対数オーダーの仮定と親和性が高いからだろう。
このように大局的に見れば、むしろ演繹では理解できないうちに世界は生成し続けている。
「理解できた」という形式でクリアに理解できる対象は世界のごく一部であって、それを全体に適用すると誤る。
フレームワークを把握したところでもう一度ソフトウェア選定のテーマに戻ると、要するにソフトウェアは淘汰死滅のプロセスを適切に経ていない揺籃期に過ぎないのだろうと想像がつく。
インターネットやスマートデバイスが爆発的に普及したこともあって、多少のエンジニアリングの練習を積めば、誰でもパーツの組み合わせで思うがままのソフトウェアを作れると考えているのではないかと思う。
しかしそれには時期尚早と言える。
過去10年ほどの停滞を考慮に入れると、各種のライブラリやフレームワークが想像どおり動作する時代になるまで、少なくともあと20年はかかるのではないかと思う。
当面は各プロジェクトが局所的な検証に追加コストを払う必要があるだろう。
