コラム
開発者が罹りやすいと言われる「どんなものでも釘に見える」という恐ろしい病についてのお話です。
どんなものでも釘に見える
開発手法に関する何かの本で、「ゴールデンハンマー症候群」という言葉を読んだ覚えがあります。海外のものの翻訳版でアンチパターン（ソフトウェアの設計に関する用語で、失敗につながる「あるある」のようなもの）に関する説明だったと思いますが、なんという書籍だったかちょっと忘れてしまい、少し調べてみましたが定かになりません。
とは言え、近い情報はWikipediaで見つけられました。
「一つの目的に作られた物を複数の用途に使用する行為についての、確証バイアスのこと。心理学者のアブラハム・マズローが、「興味深いことに、金槌しか道具を持っていない人は、何もかも釘であるかのように取り扱う」と言ったことから。」
ちなみに、開発関連用語としての「銀の弾丸」自体、「人月の神話」という私が非常に気に入っている本から広まったものです。
さて、元の本に正しくはどう記述されていたかはちょっとわからなくなっていますが、私が自身の理解として長らく気に入っているゴールデンハンマー症候群は、次のような症状です。
- どんな釘でもキレイに打てる金の金槌を手に入れた者は、どんなものでも釘に見えてきてしまい、それを叩かずにはいられなくなり、やがて滅茶苦茶に叩き潰してしまう
海外の技術書にありがちなジョークということもあり、もともと大げさに面白く書いてあった覚えがありますから、だいたいこんな話だったと思います。
その力が悪いのではない、悪いのは力を使う人である
さて。
先の警句の解釈として、私が気に入っている部分は、「ゴールデンハンマーそのものは素晴らしい機能を有している」ということです。なにせ、どんな釘でもキレイに打てるのです。なんのデメリットもありません。
しかし、なぜそれがアンチパターンの説明として登場するのか。それはまさに上記の確証バイアスによる誤用リスクのためですが、これをもう少し具体的な例で考えてみます。
もう随分と昔のものですが、Javaを利用してWebアプリケーションを構築する際の有力なフレームワークとして「Struts」というものがあります。これは業界的には一世を風靡したといってもよいほど広く利用されました。
当時すでにECパッケージの設計を担当していた筆者も、周囲から「なぜStrutsを使わないのか？使えば簡単にシステムが構築できて、しかも開発者も皆すぐに理解できるのに」といった声（提案や要望、というよりはもはや批判に近かった覚えがあります）が届いていました。
しかし、Strutsは確かに優れたフレームワークではあったものの、そこに組み込まれた様々なフィーチャー（MVCパターンに沿ったアーキテクチャの実現、永続化やバリデーションの仕組みなど）は、どれも「ECとしての要件を満たしてはいない」と私には感じられました。つまり、ECのシステムとして普遍的に求められるであろう認証・認可の機能不足や、受注取引の管理における一般原則が組み込まれていないことなどです。
もちろん、それを追加で実装することは不可能ではないでしょう。ただ、Strutsが万能のフレームワークであると思い込んでしまった開発者には、ECシステムでもStrutsで「普通に作れば十分なものが出来るはずだ」という思い込みが生じてしまうと思います。
そして、大勢で開発するシステムでは様々な機能をいろいろな・・・スキルの意味でもいろいろなエンジニアが分担しますから、その結果、ECとして作り足されるべきフィーチャーは欠落するリスクが多分にあります。
結果としては、私の身近なところではないですが、Strutsを利用したEC（あるいはそれに近い分野）のシステムで情報漏洩等の事故の報道がその後に何度もありました。ここでニュース記事のリンクを貼るのはいやらしいのでしませんが、中には弊社のビジネスにも間接的な被害をおよぼしたものもあります（ですので私のStrutsに対する怨嗟は深いものがあります！）。
とは言え、Strutsは優れたフレームワークです。今となれば批判も多いでしょうが、当時にあれだけ広く受け入れられたということが、それが優れたツールであったという証左に他なりません。
そして、ここから今、ERSとして学ぶべき教訓は「優れたフレームワークはしばしばゴールデンハンマー化するリスクを秘めている」ということです。
逆説的ですが、優れた道具だからこそ、そのポテンシャルの高さが使用者に「これで何でもできる」と思わせてしまい、何もかもをそれで充足させるべきだと思わせてしまう可能性があります。
ゴールデンハンマーとしてLexica
Lexicaは、ECに関わる多くのことを実現し制御できます。（「あらゆることを」と言いたいところですが、私は営業ではなくエンジニアなので、ここは正確に。あらゆることが出来るシステムは存在しません。）
そもそもLexicaの機能スコープは一般的なECパッケージのそれよりもだいぶ広くなっています。そしてそれらを動的に組み合わせることが可能であるため、従来のパッケージ機能と外部ツール連携の前提において論理的に為しえないような業務機能を実現することができたりします。
具体的なユースケースの列挙は別の資料に譲りますが、こうしたLexicaの特性は、これまで導入いただいたお客様にも驚きをもって評価されているポイントです。
ただ、先の通り、優れた道具にはゴールデンハンマー化のリスクが伴います。
「このシステムならできる！」という喜びが、「このシステムの通りにやらねばならない、そうすべきだ」という呪縛になってしまっては本末転倒です。
このような思い込みは、それこそ呪いのように、いつのまにか静かに根を張って運用担当者の判断を鈍らせてしまいます。
Lexicaを利用していて、ふと「あれ？呪われている？」とお感じの際には、ERSのサポート窓口にご相談ください。多くのエキセントリックなユースケースを経験してきたECシステムのエキスパートが、新たな視点で業務改善のお手伝いを致します。
最後に、開発者に伝わる格言として他にも私が長らく気に入っているものがあります。
TMTOWTDI 参考：Wikipedia
これは、略語としてまったく言いやすくないレベルの略語であるところが笑いどころのジョークなのだろうと私は思っているのですが、私が初めて触れたPerlというプログラミング言語（もはや古代語と読んでいい代物かも知れませんが）の教科書に記載されていたスローガンです。この教科書は言語の開発者本人により記述されたもので、全編、ウィットに富み、楽しく読めるものでした。
その中で上記のスローガンが何度も出てくるのですが、これはつまり「 There's more than one way to do it（それをやる方法はひとつじゃない）」のアクロニムです。
Lexicaには、TMTOWTDIの精神が込められています。ですので、何かの機能を利用していて上手くいかない場合にも、目の前のメニューの設定項目に捉われず、本来の業務的な目的に立ち戻って考え直せば、別のメニューや機能で目的を達成できることがしばしばあります。
これを読んでいるあなたが；
- もし、すでにLexicaをご利用中のお客様である場合には、いまシステムで実現できていないことがあっても、『Lexicaでは仕様上無理なのだ』とは考えないでご相談ください。
- もし、Lexicaの導入をご検討中であれば、いま目の前に列挙している精査済みの「要件一覧」以外の要件がどのみち近い将来に生じるであろうということ、その時に対応できるシステムとはどういったものか？ということをぜひご検討ください（そして我々にご相談ください）。
- もし、ERSでの採用にご興味をお持ちのエンジニアであったならば、「既存機能がいかに問題なく、追加開発の高いコストがいかに妥当であるかについて、お客様を説得し続けることがミッションのシステム保守」ではなく、TMTOWTDIのマインドに基づき建設的にお客様と議論し、互いに成長できる関係で仕事をしてみませんか？とお伝えしておきます。
それでは皆さま、失礼いたします。