  |
はてなキーワード: スクリプトとは
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーごとに作っていてOSもベンダー謹製だよ。性能はいいけどメチャ高いよ。
システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。
オープンソースソフトウェアとは全然関係ないよ。
Q3.使いまわしってどうやってやるの？
A3.80年代とかに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語にコンバートしてリコンパイルするよ。
DBのデータも階層型データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。
あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。
コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。
COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。
Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん
A4.お金が無限にあればできるよ。今の時代にお金があった時代のシステムをフルスクラッチで再開発するととんでもない予算になって市役所内の決裁が通らないよ。
しかも汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから、費用はさらにかさむよ。
Q5.そんなんでよく運用できてたな
A5.当時はSEが汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
https://anond.hatelabo.jp/20170921111601
とりあえずの解決方法を調査したので紹介。chrome対象（firefoxでもできるかは不明）。
※なんか広告除外系の拡張機能の外部フィルターに起因してるっぽい。
■ublockの場合（adblock plusとかだと少し違うかも）
設定 ＞ 私は上級者です にチェックを入れる
b.hatena.ne.jp * 3p-script allow
b.hatena.ne.jp doubleclick.net * block
を追加して保存、コミットする。（２行目はトップページに広告の枠が残るのを防止）
はてぶページを再表示で星が復活する・・・はず
■技術的な所感
外部スクリプトの絡みで発生してるっぽいが、複合的な問題らしく
とりあえず↑の設定で広告非表示＆☆復活できたので自分は満足。
なお広告消したいがために発生している問題っぽいのではてなに文句を言う案件ではなさそう。
■参考サイト
https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-rule-syntax
Allowについて "Thus they are most useful to create finer-grained exceptions, and to un-break
web sites broken by some static filters somewhere." ←まさに今回のための機能。
https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide
（ここでいうシステムというのはビジネスモデルの事ではなくて、サーバーサイドのシステムの話）
嫁がメルカリで出品される商品を買いたいがすぐに売れてしまったりするというのでアラートが欲しいと言い出した。
どうも標準である"保存した検索条件の新着通知"という機能はスピードや精度などがいまいちで使えないらしいのだ。
で、調べてみたところ2個ほどアラートアプリがあるようなのでそれを入れてみるように言ってみた。
しかし、それらのアプリでも通知結果が変だったりするらしい。（新商品の通知がきたのに、メルカリ本体で検索するとひっかからないなど）
うーん？アプリが悪いのかな？
と思ったので簡易的に通知スクリプトを書いてみることにした。
一行で書くと、
「検索結果ページを定期的にGETしてHTMLを解析して商品一覧を抜き出し、前回の結果になかったものがあれば通知すればいいだけ」だ。
うん。楽勝だべ。
よし、検索結果のページを解析するために見てみよう。何々、1件から48件まで表示中です。。
ふむふむ。で、結果がページ下にずらりと並ぶのか。
いーち、にー、さーん、・・・(中略)・・・・、よんじゅーろく。。 あれ？なんど数えても46件しかないぞ!
皿を数えるお岩さんの気分で何度も数えてみる。。が、やっぱり46件しかない。
「二枚足りなーい！うらめしやー！」
まあ、こんな事は些細なことさ。(CSSクラス名の単数形、複数形がおかしいとかももっと些細なことさ。)
とりあえずスクリプトを完成させるぜ。
・・しこしこしこ・・
じゃじゃーん！というわけでスクリプトはすぐにできたので、試しに走らせてみた。
・・・・
・・おお、結構な頻度で新商品がでるんだな、さすが大手サイトだ
・・
・・てか出品おおすぎね？こんなマイナー商品を検索しているのに1分間に7件も出品されるなんて
・・
・・( ,,`･ω･´)ﾝﾝﾝ？
・・
なんだこれは！検索結果にときどきゴミが混じっているではないか！
例えるなら、ドラえもんを10回検索したら、3回ぐらいの割合で巨人の星やマツコ・デラックスがでてくるような感じ。
通るかこんなもーん！！！
【結論】
2ちゃんねるには2つある
この2つだ（今はGoogleも「こいつらケンカしてるだけだ」とわかったのかだいたい等価だ、しかし.netがサーバ移転元のスレを止めないという間抜け処理をしたため検索有利性が木阿弥に）
で、おそらくはscのほうに書き込んだのだろう
先人のあとを辿る。
mode2で信号を記録して、整形後にconfファイルに貼り付ける。
スクリプトを作って変換してもいいけど、
-mオプションをつければ、最初から貼り付け可能なフォーマットで保存できる（ただ、後述の分析時はつけないほうがよい）
ここまでは良かった。
ところが、エアコン以外は操作できるのに、肝心のエアコン（ダイキン製）は操作できない。
原因は記録時にpulseとspaceの割合がずれること。
エアコンはデータ量が多いためか、周期(ticks?)が短く、
ズレの影響が許容値を超えるんだと思われる。
本当は1:1になるべきところが、5:3とかになる。
なので、pulseとその次のspaceを足して２で割った値を並べ、あるべき時間を推測する。
つまり、データビットは1:1か1:3なので、そうなるように補正してやる。
(pulse'=pulse-⊿、space'=space+⊿）
ただ、ときどき変な長さが交じるので、
ちゃんと長さを読み取って、あるべき時間を吐かせるとなお良い。
その他
おわり。
金曜日に switch を買う決意をしたが、通販はどこも定価では売り切れ。在庫が出ても一瞬で売り切れる。店頭も毎日列が出来ているのに買えないと聞いた。
周りの人たちにはスクリプトを書いて買うことを勧められたが、自分は知らない情報を知っている人を見つけその情報を利用して何かを成し遂げるのが好きなので、そうやって買うことを決めた。
ここ数週間の販売実績を確認。使ったのは主にヤフーのリアルタイム検索とtwitter。
先週ぐらいは今までに比べて少し入手しやすくなっていたようだが、今週はお盆で入荷がストップしているのか、全体的にかなり厳しめ。
セブン、ヨドバシ、アマゾン、楽天ブックスがたまに入荷しているが、数十秒ほどで売り切れている模様。
入荷情報を拾ってつぶやいてくれる twitter bot があるが、そちらが呟いた通知が届いてから HP にアクセスしてみても正攻法ではとてもじゃないが買えない。
カゴに入れることはできたりもしたけど、購入までたどり着けない。同じことを数百人(?)がやっているから当然か。
ということでこちらは早々に諦める。
7,8 店舗に電話をかけてみたけれど、入荷が厳しくなってからは再入荷出来たところはなさそうだった。
そんなわけでこっちも諦める。
この状況でも入荷実績はコンスタントに積んでいる模様。
ただし、どの店舗に入ってくるかが全く読めず、また抽選になっていることもかなり多い模様。
毎朝毎朝販売されるかどうかもわからないのに並んでいる人たちの列が出来ていて、SNS 上では怨嗟の声が溢れている。
どう考えても厳しい。
とくに今週は在庫ゲットがかなり厳しいようで並んでいた人たちに販売できなかった店舗が多かった。
ただし調べていくと、朝イチでは販売できなくとも11時とか13時とか、中途半端な時間に販売を開始(ゲリラ販売というらしい)するケースが多いことが見えてきた。
在庫が入ってき次第販売をしているのでそういうことになるらしい。
なのでこちらに目をつけた。
自分が行けそうな店舗のここ数週間のゲリラ販売の実績を確認したところ、新宿のヤマダ東口が確率が高く、かつヨドバシにも行きやすいので少しでもゲットできる確率が高まりそうだった。
(注：実際のゲリラ販売の台数や回数はわからないが、ネットに書き込まれることが多かった)
これを踏まえて今日午後から行動開始。(ちなみに行動中はずっと"switch 新宿" "swich ヤマダ" "switch 在庫"とかのリアルタイム検索を見っぱなし)
一番可能性が高そうなヤマダ東口に行ったところ、当然のように在庫なし。
次に可能性が高いヨドバシ西口に行ったところ、「今日は販売なし」との張り紙。
近くまで行ったのでヤマダ西口にも行って店員さんに確認したところ、やはりここ数日販売していないとのこと。
もうこうなるとヤマダ東口一択だな〜でもヨドバシ東口も可能性あるのかな？と思いつつ、東口に向けて移動していたところ、twitter で「新宿ヤマダで switch 販売」との情報をつかむ。(14:00)
この時点でかなりヤマダの近くまで来ていたので、そこから店までダッシュ。
店に到着してからは早歩きでゲーム売り場に行き、無事買うことが出来た。(14:02)
15分ぐらいで完売していたようなので、買えて本当に良かった。
headに解析タグを入れれるタイプの解析スクリプトだと大丈夫かと。
これなら思ったように集計とることができてよかった。
analyticsもいいんだけど、
重いし使い慣れた解析スクリプトの方が便利な人も居るかも知れないしね。
[追記]
http://f.hatena.ne.jp/moni01/20170814124005
http://f.hatena.ne.jp/moni01/20170814124004
画像がないからというわからんという指摘がありましたので、具体的な記載方法載せてみました。
headに記述出来るって時点でピンとこないのかいな？ｗって思ったけど、
というか、headに解析タグ入れるだけやで。
ちゃんと思った通りに解析できてるので私は満足。
門外漢からするとこんな風に聞こえてる。（所々適当に書いてるし書いてる内容は嘘デタラメ）
「gulpでbowerしてsassをgruntでビルドすれば、cssがストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWSと連携させてWebGLとTensorflowやらchainerやらと組み合わせればブラウザでDQNとかA3CとかDCGANも動かせるスクリプトがリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsでカスタマイズしたりタスクランナーでプロセスをマネージメントできるからもはやjsでtensorflowを含めたpythonのラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinのマインングをサポートしていてブラウザ上でウォレットからマイニングのセットアップまでできるんだって、ブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータを分散してサーバーに保存できるみたいなこともあるんだって。」
自分の転職の顛末を時系列で書きたい。内容は、自分の中で溜め込んでいたもの。録音や証言確保などの対応はとっていたものの、当時は恐ろしさと鬱で動けず、その後は諦観と鬱で、少数と共有する以外は、表に出して活かす機会を作れなかった。ただ溜め込みつつも、恐怖や後悔、憎悪の感情がずっと自分の中で渦巻いていて、耐え難くなっている。だからここに吐出させて欲しい。
知り合いに紹介され、20代に都内のIT企業に転職した。新卒から務めた緩い企業からの転職で不安も大きかったが、当時仕事やスキルアップが楽しめており、期待も大きかった。
転職後、すぐ遠方の客先にフルタイム常駐することになった。なおこの出張フルタイム常駐は、数年後退職するまで続くことになる。この常駐先には複数人同僚が派遣されていた。その中で自分はリーダーAの下に付き、二人一緒に業務を進めることになった。このリーダーAが後に精神を病む原因となる。
リーダーAは同じく転職入社したばかりで、直属の上司からの期待を強く受けているようだった。初印象は悪くなかったものの、働いて会話を重ねるうちに、以下のような傾向が顕になっていき、怖さを感じるようになった。
なお初印象は良いが、密に・継続的に関わると評価を落とすというパターンは、自分以外でも結構あったようだ。仕事での顧客評価も、概ねこの竜頭蛇尾のパターンを繰り返していたと思う。
振り返ると、この時点で危険を感じて逃げるべきだった。そうすれば精神と体が壊れ苦しむこともなかった。ただ自分には、それに気づいて逃げる能力がなかった。
リーダーAと1、2ヶ月働いている中で、怖い傾向はより強まっていった。相手に応じた態度の切り分けも荒が目立つようになり、例えば上司に、気に入らない顧客プロパーについてナイフで刺してやるといった過激な報告を行うようになった。また長く一緒にいることで、報告や悪口に、呼吸するように嘘や誇張を織り込んでいることに気付かされた。例えば自分の提案失敗を、叩きやすいターゲットの問題に転嫁するといったことを行っていた。
そして一緒に働いている中で、自分が攻撃のターゲットにされるようになった。はじめは、仕事ができない、自分のフォローで無用に忙しくなっている、といった仕事の指摘から始まり、お前は無能である、性格が劣悪であるといった説得を頻繁に自分に行うようになっていった。後に案件仲間から、見えないように、自分の悪口を頻繁に上司に展開していたという話も教えられた。
ただ当時、自分は期待される成果を出せていなかったし、転職で業界を変えたばかりで、能力的にも問題があると自覚していたので、リーダーAの言葉や怒りに応え自分を改善しなければならないと考えていた。また、会社ではパワハラ自慢（こんなにひどいパワハラを耐えた、自分は無能をパワハラで潰してきたなど）が目立ったので、この程度は転職の試練であり一人で耐えて当たり前のものと考えてしまっていた。この考えは心を壊すまで変えられなかった。
その後、出張状態のまま、リーダーAと二人だけで、別現場のフルタイム常駐に移った。後に派遣や準委任のメンバーの方が増えたものの、基本リーダーAが管理し、自分が下につく、プロパー二人組で仕事を進める形となった。本社とのやりとりはリーダーAがすべて統括したため、自分視点での会社同僚はリーダーAしか見えない世界となった。
この本社からの監視がきかない体制になってしまったことで、リーダーAの攻撃は露骨にエスカレートするようになった。例えば次のようなことを何ヶ月も継続して行うようになった。
また指示される作業も単純作業が多くなっていった。例えば以下のようなものだ。
当時高い単価で常駐していたので、単価に見合わない上記のような単純作業を強要されるのがまた別の苦しみとなった。
一方で、周りに対する演出には力を入れていた。例えば、本社での会議の参加を禁じたり、本社とのやり取りを自分が見えないように済ませたりして、本社と自分のコミュニケーションを断絶させるように動いていた。また「殺す」と脅迫するなどまずい言動を取るときは、周りの目や耳のない状況下で行っていた。あとは従順な派遣社員を見つけて、主張に箔付けに使うなどしていた。例えば悪口を裏で本社に展開する際に、その社員をCCに入れて、この悪口は自分だけの勘違いではないと演出する気配りを行っていた（ただこの方には、裏でやりとりされている悪口・中傷や、リーダーAの内心などの情報を後にもらえるようになった）
こうした状態は半年近く続いたが、その中で自分の精神はおかしくなっていった。仕事中に泣く、顎が痙攣して歯がカチカチ鳴る、ネガティブな独り言を言うといった、外目から異常と思われるだろう様相を晒してしまっていた。ただリーダーAにとってはそれは笑い飛ばす程度の扱いだった。例えば自分が精神的に参っているから慰労会をやろうとリーダーAに飲みに連れて行かれることがあったが、リーダーAが一方的に侮辱の言葉を投げて笑い飛ばすだけの不快な場になるしかなった。
なおこの頃からさすがにこれは異常だ・危険だと言う思いを強くして、証拠を残すようにした。例えば勤務中にずっと録音機を動かし、殺すといった脅迫を録音するようにした。客先社員から同情してくれる方も出てきた。同情してくれた方から内情ももらえるようになった。
しかし激昂し犯罪者的な言動を取るリーダーAに抵抗するのは当時とても恐ろしく、証拠を残せても、証拠を活かす行動をとれなかった。また入社後即フルタイム常駐していたので、気軽に相談できる会社同僚もいなかった。そして、自分が無能であり、まずはリーダーAの言う通り改善しなければ後がないという考えを持ってしまっていた。恐ろしさから逃避しながら苦しみを軽減したいという思いで、リーダーAに従い続けた。
一応本社の人間に相談することもあったが、抱え込まずに相談して良い、というコメントを貰った以外は、本社側で具体的な対応はとられなかった。あとは、退職時に人事から詳細情報を聞かれる程度だった。
上記のような状態は一年以上続くことになったが、そのあいだ自分は大きく変わった。基本的に、次のようなネガティブな変化ばかりだ。
なお上記は、もう死ぬまで元に戻ることはないと感じている。器質的に脳が変化・死滅してしまっているようだ。苦しみを経験すると強くなるとよく聞くが、苦しみで心を壊すとむしろ大きく弱体化してもう戻らないというのを、30を超えて学んだ。
その後の展開だが、リーダーAは、顧客に大言壮語やダメ出しを多くする一方で、成果を出せず、評価が得られなくなっていたようだ。そしてその頃から特定の先輩社員に嵌められて仕事がうまくいっていないと吹聴するなど、被害者的な言動が多くなる。そして最後は案件から逃げていった。
ただ元凶のリーダーAが抜けてからも、苦しみがなくなることはなかった。
仕事では、リーダーAが案件から逃げた尻拭いをして、関連会社メンバの業務確保と案件維持に奔走させられた。リーダーAの代わりに本社の上司や関係者と関わり合うようになったが、リーダーAが散々悪口を刷り込んでいたせいか、馴染みの薄い上司とは、最初から関係がギクシャクしていた。
これを心が壊れ、精神薬・アルコール・カフェイン漬けで体を無理やり動かしていた状態でこなすのは、本当に苦しかった。
その後、苦しみながら遠地に常駐し、売り上げ確保に努めていた。しかし半年ほどたった所で、復帰したリーダーAが、自分の目に届く会社MLで活発に発言するようになった。自分はそれを目にする度に、過去の出来事がフラッシュバックして恐慌状態となってしまい、もうこの会社では過ごせられないと信じるようになった。そして、ずっと常駐で会社への帰属意識がなかったなど、他の理由も複数揃っていたので、会社を辞めた。
振り返っても、失ったものが多く、後悔の数多い数年間だった。
大きな後悔としては２点。１点目は、リーダーAのようなタイプの人間とは、唯一の対策として距離をとるべきだった。２点目は、状況が異常であると認識して、もっと強く本社や上司に状況改善を訴えるべきだった。この対応ができなかったのは自分の未熟さによる。だから、転職に必要な能力が足りないまま転職してしまったというのが、問題要因として大きくあると思う。
あとは、仲間を作るべきだった。退職間際で、別地域を担当する案件仲間と話し込む機会があったが、そこではリーダーAの異常性を感じ取っていて、仕事から排除するように動いていたという。またリーダーAから悪口の報告を受けていた人間の中には、虚言癖を見破っていて信じないようにした人がいたと聞いた。同情してもらえて、自分の見えないところでのやり取りを情報共有してくれた関係者もいた。そういった人達と早くから関係を持っておくべきだった。
そして転職や、フルタイム常駐は、巡り合う人次第のギャンブルだというのも知った。転職した会社にも、尊敬すべき人格者は結構いた。会社も技術力が高く、業績好調で、外から良い評価を得られている優良企業だった。唯一、リーダーAと巡り合ったのが問題だった。
ただもう後悔しても何も変わらない状況になっている。今は乱れた心身が残り、恐怖・後悔・憎悪が入り混じった感情が自分の中で渦巻き続けている。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
