どういうワケ？
最近、こんなツイートをしました。
フレームワーク周り、仕組み周りで挙動がなんか変だな？って思ったら、まず最新版で試してみましょうがお約束。古いバージョンでああじゃないかこうじゃないかってやっても時間の無駄になる可能性が大。実際にはアップできないって事情があっても、最新版との比較で回避策見つけるかもだし。
https://twitter.com/jflute/status/1046728446540300288
まあ、あれこれ相談されて分析して...
「結局、最新にしたらOKだった」そんなことよくあります。(まあ自分でも時にあります)
多少はしょうがないにしても、あまりにこういうのが多く、しかも長い時間ハマっているのを見ると、最初っから最新だったら良かったのに...ってどうしても思ってしまいます。
(もちろん、ハマること自体も改善が必要ですが)
切羽詰まってバージョンアップ
o 現状バージョンで致命的なバグで困った
o 現状バージョンでセキュリティ問題が出た
o 環境を変えたら現状バージョンで動かなくなった
というような理由でアップグレードされるのをよく見かけます。あわてふためきながら。
理由がはっきりしているので、業務タスクにしやすく何よりも最優先で対処されます。
というか、場合によっては、
これらの理由以外でアップされることがない
なんて現場もないでしょうか？
理由がないと、バージョンアップしないのでしょうか？
現在バイアスに勝てない
なぜでしょう？
「いま動いているという強いブランド」と、「バージョンアップによる動かなくなるリスク」の合わせ技に...
「バージョンアップすることによる嬉しさ」と「バージョンアップしないことのリスク」が勝てないからです。
人は、なかなか「現在バイアス」に勝てません。
いま動いている => 安心
動かなくなるかも => こわい ☆
新しいもの嬉しいよ => まあそうだけど
このままだと大変かも => なにが？ ☆
でも不思議ですよね。☆マークが付いているところ、どちらも推測なんですよ。
でも人は「留まるリスク」を過小評価します。
でもって「すすむリスク」を過大評価します。
これは自分もよーく気持ちがわかります。諦めるべきでしょうか？
責任回避に勝てない
さらにそれを助長する感情があります。
「責任」です。
「バージョンアップしてトラブったー」
「ん？バージョンアップしたやつ誰だ？」
「バージョンアップしなかったからトラブったー」
「ん？バージョンアップしなかったやつ誰だ？」
いやいや、なかなかそうならないですよね。
行動をした結果の負の責任は明確で、
行動しない結果の負の責任は曖昧で。
これは周りがそういう風に捉えるというよりも、自分がそう思ってしまうことが大きいでしょう。「バージョンアップしようぜ」って言ってトラブったら、言った自分がすっごい悪く見られてるように感じる。言わなければトラブっても安全地帯だったのに。
これは自分もよーく気持ちがわかります。諦めるべきでしょうか？
提案A. 嬉しさとリスクを学ぼう
まず、過小評価される、
「バージョンアップすることによる嬉しさ」
「バージョンアップしないことのリスク」
これを正しく学ぶことも大事だなと。
例えば...
最新版にしていなかったから、セキュリティ問題が発生しててんやわんや
なんてことも実際にあることです。最新版にしていなかったからトラブル...もっとフォーカスされても良いことです。
そして、なぜ最新版にしてなかったのか？深く反省して良いことだと思います。
もっと早く最新にしていれば、もっと便利な機能で開発がスムーズになってたかも？もっと無駄な不具合対応が減っていたかも？
悔しがっていいと思います。
最新版がオープンソースへの貢献
特にオープンソースプロダクト、多くの人が利用されていると思いますが、バージョンアップしないことのリスクは高いものです。
...
リソースが限られたオープンソース開発は、最初から良い品質のものは出せません。ソースを公開して、みんなに使ってもらって、フィードバックが来て、修正をして、そう... "五月雨に" 品質が上がっていくものです。バージョンも細かく上がっていくことでしょう。
最新版を使わないというのは、低品質の地雷を踏む可能性を残す
ということになります。
...
また、リソースが限られたオープンソース開発は、古いバージョンをサポートすることができません。何か問題があったときは最新版に対して対処がされます。古いバージョンに対してパッチが当てられることは、相当に稀なことだと思います。
古いバージョンを使い続けて最新版と離されたら、いざってときにすんなりアップグレードできない
ということになります。
(もたもたしてる内に致命傷を負うかも)
そしてまた、コミッターに質問や相談したとき、古いバージョンだと良い対処は期待できません。ズバリ！覚えてないものですし、思い出すのにも古いバージョンの環境を作るのにも、多大なコストがかかります。実質的にまともなサポートはできないでしょう。(基本的に)コミッターにはその義務もありません。
オープンソースで「サポートが切れた」という話で、世の中がてんやわんやしているのを見てきました。個人的には「そこまで重要なことかな？」と思う一方で、じゃあ重要なのであれば、"実質的にサポートされない遠い古いバージョン" を使い続けているのはなぜ？
...
そのオープンソースを応援しているのであればなおさら、最新版を使ってあげることが貢献です。
提案B. 受け入れて仕組みを作ろう
まずこういった、わたしたちの特性を受け入れること。わたしたちは自然とは "すすむリスク" に立ち向かえない。その上で、人間の心理を克服するような仕組みを構築すること。
例えば...
三ヶ月に一度はライブラリをバージョンアップするチケットを必ず作るようにする
とか。要は定期点検ですね。(こまめにやったほうが安心)
リスク回避というものは、「動かなくなったー」とかのイベントドリブン的なものではないですから...
「期間」をきっかけとするしかない
わけです。
...
ちなみに...
マンションの管理組合の理事長とか何年もやっていたのですが...消防設備点検とか、なんとか点検とか、なんとか部品の交換とか、いっぱいあって、住民の負担もかかるし、お金もかかります。
大抵、管理会社の方から言われるのが...
「法律で点検しないといけないことになっています」とか「法律で何年以上たったら交換を...」(正確に覚えてないけど) とか。
まあ、同じですよね。将来のリスクの話です。放っておくと絶対にやらなさそうです。まずやらないでしょう。だからもう法律で定められてみんな(いやでも)納得するわけです。
なんかもう、法律で「新しいバージョンを使わないといけない」とかになった方が楽なんでしょうかね？笑
ポイントを絞って無理なく
とはいっても、jflute自身もなんでもかんでも最新にできているかというと、そーんなことはありません。ツールは山ほど身の回りにありますから、あれも！これも！これも！あれも！もれも！れもれ！よーく見るとバージョンアップの対象がハチャメチャある（＞＜。
それだけで随分と時間を使うものです。目をつぶってバージョンアップもできないでしょうから。(Exampleとかなら目をつぶってやっちゃいますけど笑)
なので、ポイントを絞って現実的なラインを見つけていくのも大切です。
S. バージョンアップの効果の高そうなもの
T. バージョンアップリスクが極端に低いもの
"S" は、例えば、DIコンテナ、Webフレームワーク、O/Rマッパーなど、不具合が出ると影響のでかいもの、嬉しさの影響も大きいもの、そういったものは率先してアップしていく、というような感じで優先度を付けていくのも良いでしょう。
"T" は、例えば、UnitTestのライブラリや、開発支援ツールなど、何かあっても本番運用に影響が出るのはほぼ考えにくいようなもの、これは目に入った瞬間からアップしていっても良いでしょう。(まあ、依存関係とかは確認してね^^)
また、プログラミング言語のDBMSのバージョンなど、大きなものは、また別のタイミングで考えたほうが良いでしょう。ついついその気になるとあれもこれもで全部一気になりがちですが、バージョンアップタスクが重すぎると、"S" や "T" などもっと気軽に上げられるはずのものが、時間がかかって先延ばしになる可能性があります。結局、挫折して「すべてがパーッ」と言うこともあるでしょう。
そして、メジャーバージョン、マイナーバージョンという軸もありますから、一言で最新版と言っても一つに決まるわけでもありませんし。必ずしも行儀の良いリリースがされているとも限りませんし。自分たちで、
「これは、どのくらいにしておきたい。あれは...」
って考えることが大事かなと。正解はありません。
最新バージョンを知ろう
そもそも、最新バージョンっていくつ？って知らなければどうしようもありません。
セキュリティ問題が発生して「うわーっ」となってから、オフィシャルサイト見たら...「ああ、こないだリリースされてたじゃーん」ってのも、もったいなくてしょうがないです。
誰か一人でもオフィシャルサイトを見ていたら、そのセキュリティ問題は発生しなかったかもしれません。
現状は、個人の趣味に任されているのがほとんどでしょう。そういうのをチェックするのが好きな人がチームに一人二人いて、時々チャットで共有してくれるみたいな。いなかったらジ・エンドです。そういう現場も多いでしょう。
そこは本来、責任ある営利のサービス運営・システム開発の組織としては、属人的にすべきところではありません。
利用しているライブラリ (多すぎるので絞るのもOK) の、最新版リリースの情報をウォッチする役割の人を明示的に決めたり、持ち回りでチェックするようにしたり、自動的にSlackで流れるようにしたり、そういう工夫があって良いと思います。
いつでも理由はある
さて、理由(ワケ)もなく？というブログタイトルでしたが、こう考えると、理由はありますね。常にありますね。
最新バージョンがリリースされていたら、バージョンアップする理由がある
のです。
そして、現実的な妥協点として、「期間」を理由にするというのも十分前向きです。「三ヶ月経過したらバージョンアップする理由がある」
...
さて、DBFlute, LastaFlute を運営しているjfluteとしては、ちょっと書きにくいブログでした。自分の都合をすごく主張しているみたいで。
でも、jfluteは現場のメンバーでもあり、他のフレームワークやライブラリのユーザーでもあります。それぞれの立場をそれなりに理解しているつもりですから、だからこそ自分が書かないと、と思いました。
現場もコミッターも、そして、システムのユーザーも、Win-Win-Win になるために。
...
【追記】バージョンアップしやすくするためにも!?
=> フレームワークの思想、意識して使っていますか？
