フレームワークやアーキテクチャのできること

フレームワーク開発、アーキテクチャ設計。

これらは、あたかも
「空き缶やタバコなどのゴミのポイ捨てをいかになくすか」
という永遠の課題を追求してるようなもの、
と言えるかもしれません。

「一人一人が心掛ければゴミのポイ捨てはなくなる」

正論でありながら説明するまでもなくむなしい言葉です。

プログラムで言う「ポイ捨て」は、
以下のようなことが考えられるでしょうか。

A. 勘違いや操作ミス、実装ミスなど
B. やるべきことを面倒だと怠ること
C. 悪意を持ってプロジェクトを失敗させること
"A" は、ある程度仕方のないこと。人ですから。
そして、そこはフレームワークアーキテクチャが大いに
発揮するところ。発生してしまうことを許容しながらも、
できる限りことなきを得るような仕組みにしておくこと。

とてもわかりやすいところで、今回の焦点からはちょっと
外れます。アーキテクトはそのユースケースを想像しやすく、
ディベロッパー自身も "A" をなくそうと努力する人は多い。
幾らでも改善の余地はあるにしても、双方が歩み寄って
"A" タイプの「ポイ捨て」を無くそうとしてるから。
希望的です。
"C" は、ちょっと極端ですね。
もちろん、ブラウザやサーバ管理などの世界では本当の
意味での悪意を持った人を想定して提供しなければなりません。
フレームワークや(システム開発の)アーキテクチャは、
そうはいってもディベロッパー、主にプログラマが対象なので、
あまり神経質になることはないと言えるでしょうし、
というかそのようなプロジェクトに悪意のある行為がある場合、
フレームワークアーキテクチャごときで防ぎようがありません。
ということで話の焦点になるのは、"B" です。
「やるべきことを面倒だと怠ること」

え、仕事なんだから面倒で怠るなんてあり得るの?
って思われるかもしれませんが、あるのです。

もちろん程度の問題はあります。面倒くさがりやの人と
律儀な真面目な人、という個人差はあるでしょう。でも、
後者の人でも、人が本能的に持っている面倒という感情が
目に見えない形で出るということはあり得るでしょう。
なので、仕事だからどうだ、ということはありません。

人だからある程度仕方のないこと。ここまでは "A" と一緒。
大きく違うのは、"A" よりも "B" をなくそうと努力する人が
圧倒的に少ないだろうというところ。

"A" はわかりやすく結果に出やすいもの。そして、"A" を防ぐ
ためのプロセスは誰もが思い付きやすく実践しやすいもの。
また、人は "A" を反省しやすいもの。

"B" はあまり結果に出にくいものが多い。
「自分(一人)くらいはいいだろう」と程度が低ければ
大きな問題にならないと思ってしまう類のものが多く、
確かにその通りだったりすることはありますが、
「そう思うのが自分(一人)だけ」という保証はどこにもない。

そして、"B" を防ぐためのプロセスはとても難しい。
もろに性格がものを言ってしまうから。面倒と思う心、
そして、誰も見てなければいいやと思う心。一方で、
律儀な人でも目に見えない形で出ることも多い。
また、人は "B" をなかなか反省しようとはしないもの。

性格的に面倒なことがとても嫌いな人でも、改善欲の強い人なら
とても前向きです。吸い終わったタバコを持って歩いて、
灰皿まで持って行くのがとても面倒くさい。だったら、
最初から灰皿のあるところだけで吸う、もしくは、携帯灰皿を
常に持っておく。そんなノリで状況を改善してしまう人。
実は、そういった類いの面倒くさがりやこそが便利なものを
作ったり発明したりするという面もあります。
でも、そんな人は一部。大抵は、そのまま捨ててしまうでしょう。
(ポイ捨てされたタバコの吸い殻を見かけない町はない...)

現実の世界よりも、プログラムの世界の方が「しばり」を
入れるのは簡単じゃない?と思われるかもしれません。
その通りの部分も確かにあります。タバコの吸い殻が灰皿の
ところに行くまで指から離れないようにするっていうような
ことは技術的に可能かもしれません。ただ、アーキテクトは、
その「しばり」のさじ加減と常に格闘してると言えるでしょう。
「しばり」は使い勝手となかなか両立しにくいものです。
どの世界でも同じで、セキュリティを厳しくすればするほど、
ユーザビリティは悪くなりやすいもの、と言えると同時に、
モチベーションも下げてしまうという問題も発生させます。

ゴミがずっと手に引っ付いてるというのは、恐らくダメ。
そんなのいやでいやでしょうがない。もともとゴミを捨てずに
ゴミ箱まで持っていくつもりの人までなんかいやな気分になる。
(宿題をやろうとしたところに「宿題をやりなさーい」と言われて、
「今からやるところだったのにー」という気分に!?)
というか、手が塞がってしまうので、その他のことができなく
なってしまう。利便性だってとても悪い。

せめてベンチに座って一休みするときに、ベンチの上に空き缶を
置くことは許さないと。ベンチを検出するのか?そんなこと可能か?
ボタン一つでゴミを外せるなら、多分みんなすぐに押して捨てちゃう。
ベンチから離れるときに、自動的にまた手に引っ付くようにするか?
手に引っ付くんじゃなくって、背中とか邪魔にならないところに
引っ付くようにさせるか!?

とにかく、ゴミ箱に持って行くまでのレールを敷いて、
できるだけそれがあまり負担にならないように。

もっと発想を変えて頑張ってみる。

ゴミ箱がすぐそばにあればみんなちゃんとそこに捨ててくれるかも。
でも、ゴミ箱だらけになるよ。誰がその大量のゴミ箱を作る?
誰がゴミ箱のゴミを回収する?
ゴミが出そうな場所を予想しておいてゴミ箱を配置しておけば、
コストをそこまでかけずにある程度はポイ捨てが減るんじゃないか!?

さらに頑張ってみる。

既にゴミがあると、つられてゴミを捨てやすいものだから、
そもそも綺麗な環境にしておければ、その綺麗なところにゴミを
捨てようとはなかなかしないんじゃないか?
ある程度は理にかなっているけど、逆にこれみよがしに捨てる人も。
(実際、通勤で通るとても大きな公園の「とても綺麗な芝生」には
常にタバコの吸い殻が...)

ベタだけど「ポイ捨て禁止だよ」って張り紙書いておくとか。
その禁止という張り紙のデザインも工夫して心に響くようにとか。
でも、電車の優先席の「携帯OFFしてー」ってでっかい表示が
ありながらも携帯いじって遊んでる人のいる世の中、Wikiに
「こんなコード書いちゃダメだよー」って書いたところで...

もうやけくそになって頑張ってみる。

「かかし」を置いておけば、人に見られてる気分になって、
「誰も見てないからいいや」って感じの人は捨てなくなるかなぁ。

もうちょい真面目に立ち戻って頑張ってみる。

ゴミをポイ捨てすることの方が面倒、と思うような仕組みにしてみる。
ゴミを捨てると大音量が鳴って恥ずかしい思いをして余計に面倒とか。
罰則的な感じじゃなくて、ゴミ箱に入れることでその人が直面してる
問題が解決に役に立つというような前向きな仕組みに...うーん。
ここまで来るとゴミの話では思い付かないけど、システムで言えば:
エラーメッセージを読むのは面倒な作業である。でも読みさえすれば
問題は解決するというようなエラーメッセージをしっかり出すよう
にすれば、ちゃんとエラーメッセージを読んでもらえるかも。

ガチガチなしばりが成り立たない以上フレームワークができるのは、
実はポイ捨てされないようにこういった形で「促進すること」だけ。
最近では、コードフォーマッターとかチェックスタイルとか、
FindBugs とか、コードレベルのある側面ではかなり色々とチェック
できるようにはなりました。でも、開発というのはもっと立体的な
作業であって、まだまだチェック仕切れてないところが多いし、
また、仕切れるものでもないでしょう。
o 問題を全て根絶やしにすることはできない
o 安全性と利便性はなかなか両立しない

それがわかっていながら、

どういう仕組みなら「ポイ捨て」しなくなるんだろう

と、なんとか問題の「程度」を解決しようと頑張るのが
フレームワーク開発であり、アーキテクチャ設計であると
言えるのかもしれません。少なくとも、何年にもおよぶ、
長かった DBFlute 開発はこの繰り返し、そして、これからも...

なので、なおさら「唯一の最善策」はなかなか存在しないから、
複合的な解決策で様々な方面の都合にバランスをとった微妙な
「ちょうどいい」を探して、提供することが求められるわけです。

// 一つの問題に対する解決法は単一とは限らない
http://d.hatena.ne.jp/jflute/20110215/solutions

逆に言うと、
(特に若い人でこれから目指す人に伝えたい)

この正解のない、でも正解に近づかなければならない、
バランスという抽象的なゴールへの生みの苦しみ

を理解できなければ、良いフレームワーク、
良いアーキテクチャを作ることはできないと。

ふと、考えたことでした...