目次
03日 停電･節電
06日 入学式・入園式
11日 花見
18日 難しい見積もり
21日 情報の扱い
22日 「戻る」ボタン自由自在
27日 誕生日
すでに世の中に山ほどの節電・停電対策情報がある。
なので、わざわざそのような情報を書こうとは思わない。
以下は、単に日記として、３月中の我が家の様子を記すものである。
３月１１日の地震発生時、すぐに停電。５時間半後に復旧。
最初にやったことは、仕事先のサーバーが生きていること（サービス無停止だったこと）の確認でした。
幸い、２３区内にある仕事先サーバーは停電せずに生きていた様子。
これ、後から考えたら「不慮の停電」ではなく、輪番停電が発表される以前に行われた、輪番停電ですね。
まだルールが定まっていなかったら「３時間」以上停電していた、というだけで。
この最中にやったことは、以前の日記に書いたとおり。
最初はこれが「計画的な停電」だなんて思っていなかったので、３日程度電気が来ないことを覚悟して、炭火を熾して食材煮込んでおいたりしました。
その後、土日は大丈夫だが週明けから停電せざるを得ない、との発表。また、節電に努めて欲しいとのお願い。
まず最初にやったことは、夜中に充電池をできる限り充電することでした。
他の人が電力を使っていない時間であれば電力を使っても問題ないだろうから、その時間帯の電気を充電して、電力が使用される時間帯の停電に備えたわけです。
幸い、子供のおもちゃ（プラレールなど）用と、各種電子機器向けに、単３の充電池は３ダースほどあります。
また、土日の間にサーバーを整備。
もともと、Atom を使用した省電力サーバーを２台使用し、家庭内向けの仕事用と、外向けの WEB・メールサーバーにしています。
障害耐性をつけるために両方とも Xen を使用して仮想化しており、障害時にできるだけ迅速に対応できるように、毎日仮想サーバー（の仮想ディスクイメージ）をバックアップ、さらに、互いのサーバーに rsync で送ってありました。
これを、片側に寄せます。１台の中にバーチャルサーバー２台を入れ、１台はコンセントを抜く。
また、データバックアップに使用していた RAID-NAS を停止します。
RAID-NAS には自動バックアップ用の外付けハードディスクが接続してあったので、これも停止します。
自分が使用しているメインマシンは、毎日深夜に起動してバックアップを取ったり、ディスクのデフラグをしたりしています。これを停止。
深夜だからピーク時の節電とは無関係ですが、バックアップ先が停止した NAS なので、いずれにしても無意味なのです。
この後、物流が滞り、供給量が落ちたことで、小売店は軽いパニックに陥っていました。
パニックに陥ったからこそ「いつもより少し多めに買った」人はいるようですが、棚に商品がないのは、政府や AC が言うような「買占め」のせいではなく、供給量が落ちたためです。
１週間も耐えれば、ある程度状況は改善し、２週間で「不便ながら普通に生活できる」レベルになるだろうと目算をつけました。
幸い、米は買ったばかりの上に、新聞の購読契約の更新で 4Kg ほどもらっていました。
１１日が子供の遠足だったため、お弁当用にいろいろな食材も買った直後でした。
自動車のガソリンも入れた直後でしたが、できる限り車は使わないことに決めます。
お菓子が見えると子供は食べたがるので、普段のおやつ庫に少しだけ残し、保存が利くお菓子類を別の場所に移します。
非常時は情報収集が重要です。
生活をしながら常に情報を集められるように、積極的にラジオを活用。
テレビだと、見ていないとわからない情報も多いので生活ができなくなるし、何よりもこの状況下では電気を使いすぎます。
なぜ、節電を呼びかけるテレビ各社・AC が「今すぐテレビを消せ」といわないのかが不思議でしょうがない。
それを言えないのだとしたら、テレビ各社はまだ、本気で社会貢献しようとは思ってないんでしょうね。
計画停電初日である１４日は、我が家地区では結局停電はなし。
でも、停電しても良いつもりで行動し、良い練習になりました。
実際の初停電は１７日。１３時５０分からの予定でしたが、少しずれ込んで１４時過ぎから。
これも、停電を予定した行動を取っていました。
自宅で仕事をしているので、停電したら何もできません。そこで、停電中でも街で買い物ができるのか、視察に行きます。
震災後、本格的な買い物に行くのは初めて。（軽い買い物は近所の店などでやっていました）
…大船と言う街は面白いところで、普段から POS 等を使わずに電卓で計算している店が多いです。
大きくて品揃えが豊かで、かつ安い八百屋は、普段から電卓計算なので、停電でも混乱はないはず。
行ってみると、予想通り普通に営業していました。
この日は、福島産の苺が大安売りだったので買います。大粒で揃ったものが、４パック１箱で４５０円。
風評被害などで安くなっている、と噂に聞いた葉物野菜は普通の値段でした。買おうと思っていたのに。
普段 POS を使用している別の八百屋は、営業を続けてはいるけど多少客捌きが停滞気味。
肉屋のうち、普段使っている店は停電中は閉店。別の店は、店の奥から在庫を出してきて、路上販売に切り替えました。
他にもいろいろと視察し、仕事にならない停電中に買出しにでるのは可能だ、と判断。
もっとも、この判断は、その後今まで役に立っていません（笑）。昼に停電したのはこれ１回限りでしたから。
この日は寒く、「いっそうの節電を」と呼びかけていたため、居間のテレビ周辺にある、LAN の HUB 、無線 LAN ステーション、 Wii を、コンセントから引き抜いた。（テレビと HDD レコーダは活きている）
また、２階においてある２台目テレビと、その周辺にある、 LAN の HUB 、iMac 、 PS3 をコンセントから引き抜いた。
節電のためではなく、24時間換気の電源も切った。
昼間エアコンなしで過ごすのは少し寒いが、外気が流入しなければ多少暖気を保てる。
ただし、換気を切りっぱなしは危険なので、深夜に電源を入れて、ついでにエアコン暖房もかけさせてもらう。
スウェーデンハウスなら、最低気温 0 度の日でも、これでなんとか過ごせる。
次は翌日、１８日の１８時２０分から。
夜にかかるので、子供にあらかじめ予告しておき、早めに保育園に迎えに行って、明るいうちに風呂に入ってしまいます。
風呂に入れている間に妻が夕食の準備。実はまだ電気はつくのですが、途中で暗くなると怖がるかもしれない、と考えて、最初から「キャンプごっこ」で電気を使わずに食べます。
これは子供が結構喜んでいました。
そして、７時前に停電。
食事後は、将来子供部屋にする予定で、今は広い遊び場にしている部屋に移動します。
地震当日も、夜の暗い時間はこの部屋で過ごしたためです。あまり物を置いていないので、暗くても危険が少ないのです。
窓から見える月が、非常に綺麗でした。満月の少し前かな、と言う感じ。非常に明るいです。
満月が明るい、ということはちゃんと知っているのだけど、それにしても明るく感じる。周囲が暗いとこんなにも違うものか。
…後で知ったことですが、２日後が本当の満月で、しかも地球に一番近い「近星点」だったのですね。明るいわけです。
この日はそれなりに雲があり、月を隠すことも多かったのですが、子供たちは「お月様」を待ちながら、楽しい時間を過ごしました。
そして、窓の外の月を見ながら寝られるところに布団を敷くと、３人仲良く眠りにつきました。
実は、寝る直前の８時半頃に、停電が終了したのは気づいたのだけどね。
長男も気づいたようですが、妹たちが寝かかっているのを気遣って、電気をつけたいとは言いませんでした。
そして、２３日。こちらも１８時２０分から。
夜の停電も３度目ともなるとなれたもので、子供たちも騒ぐことなく協力します。
１８日は、妻は時間の都合もあり、暗くなってから風呂に入りました。
長男（６歳）が「暗いお風呂入ってみたい」というので、２３日は風呂のスケジュールだけ多少異なります。
＃後で聞いたら、暗いお風呂は「思ったより怖かった」らしいです。
この日は満月も過ぎた上に曇りがちなので、早い時間の綺麗な月には期待できません。
そこで、「電池節約のため」なるべく使わなかった懐中電灯の使用を解禁します。
食事も、天井に懐中電灯を吊り下げます。
いつもはガーデンライトで食事をしていたのですが、少し明るめ。
この懐中電灯の明かりが楽しいようなので、食事の後も部屋を移動せず、テーブルなどを端に寄せて居間で遊びます。
これは、長男と妻が風呂を出るのを待つ意味合いもあったので、その後はいつもの広い部屋に移動。
懐中電灯は２台あったのですが、妻が「取って置きの」１台を取り出してきます。
…えーと、妻がファンクラブに入っている「とある歌手」の実家の電気屋さんで買った懐中電灯。
だからどうした、と言うわけではないのですが、なんとなくファングッズで未開封。
３台で部屋を隅から照らすと、かなり明るくなりました。
僕が影絵遊びをしてみせると、長男も真似をします。
…どうもわかってなくて、ただ光を遮って暗いだけだったりもしますが。
３月中は、我が家地域で実行された計画停電はこの３回のみ。
震災当日の停電を含めて、夜３回、昼１回ですね。
その後の停電はありませんが、長女（３歳）は「何で停電無いの！」と怒ります。
暗い中での食事が気に入って、またやりたい様子。
一度など、長女が強攻策に出て、食事中に勝手に電気を消しました。これはこれで面白かったし、節電は悪いことではないのでそのまま食事をしましたが。
今日（４月２日）、子供たちが懐いている、妻の大学時代の友人が遊びに来ました。
本当は１２日に来てもらう予定だったのですが、その後のびのびになっていたのです。
妻の友人の住んでいる場所では、まだ計画停電が１度も実行されていないそうです。
そして、計画停電のグループ分けでは、２つのグループにまたがって該当する地区で、自分の家がどちらに属するのがわからないとか。
備えはしているそうなのですが、なにぶんまだ１度も停電を経験していないので、乗り切れるかどうかに多少の不安があるとか。
グループが不明なままなのも不安の種で、１度でも停電してくれればグループが判明するのに、と言っていました。
うちの地域の、計画停電３回が多いのか少ないのかは知りません。
でも、停電しない地域の人が喜んでいるのかといえば、そうではないのだなぁ、と思いました。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨日４月５日、長男が小学校に入学しました。
本日４月６日、長女が保育園の「制服組」（３歳児以上クラス）になりました。
そして、次女は…以前は「チューリップ組」で、今日からも「チューリップ組」。
０・１歳児は同じクラスなの。（一応、０歳チューリップとか、１歳チューリップと呼ばれることはあるが）
小学校はまだ給食が始まらないので、当分午前中に帰ってきます。
自宅で仕事をしている人間としては、仕事になりません。
段々と、一人で遊ぶ事を覚えてもらわなくては。
今年の頭くらいから、「どうぶつしょうぎ」を買おうと思っていた。
僕はゲーム好きだが、それはテレビゲームに限定しない。
むしろ、ボードゲームを皆で囲むのは好きだ。
子供がゲームを理解できる年齢になったら、一緒に遊びたいと思っていた。
で、「どうぶつしょうぎ」は、ブームが起きる前から注目していたのだが、子供が始めるのに十分な年齢ではない、と考えていたので購入していなかった。
それが、今年の頭くらいからトランプなど、様々なゲームに興味を持ち始めたので、買おうと思っていたのだ。
ただ、一緒に遊ぼうとすると問題なのは、長女や次女が「自分もやりたい」と言って邪魔することだった。
そして、買おうと思っただけで買わないまま、小学生が近づいてきた。
小学校に入ると、保育園ほど長い時間預かってもらえるわけではない。長女・次女は保育園にいるまま、長男は家で過ごす時間が長くなる。
そこで再び、どうぶつしょうぎを買おうと思い始めた。その矢先に震災が起きた。
節電しなくてはならない。
長男はテレビゲームも好きだが、こんな時こそボードゲームだ。
そこで、小学校で使う筆箱などを買うついでに、おもちゃ売り場のゲームコーナーに行き、どうぶつしょうぎを購入…しようとした。
隣に、オセロ（もどき）が置いてあった。
長男はオセロは遊んだことがある。戦略がまだわからないので全然勝負にならなかったが「オセロのほうが欲しい」という。
そのゲーム版は、オセロを含めて１０種類のゲームが遊べた。
見たところ、どうぶつしょうぎのほうが「初めて遊ぶボードゲーム」としては適しているのだが…
子供の希望は無視できない。欲しがるほうを購入。
早速オセロで遊んだ長男、他のゲームにも興味を持つ。
小学校１年生の漢字を大体覚えてきているので、漢字が駒に書かれている「将棋」に興味がでる。
でも、長男にはまだちょっと難しすぎる。
…なんだか、当初目的に戻ってきたぞ。
ペーパークラフトのどうぶつしょうぎを WEB で発見。
早速作り、遊んでみる。子供にもすぐ理解できたし、自分としても予想以上に面白い。
盤面が狭すぎて、常に詰め将棋状態になっている、というのが良い。
また、駒も少ないので、どの駒をどの駒が守っている、という状況が把握しやすい。
要素を大きくそぎ落としたことで、非常にテンポの良いゲームに仕上がっている一方で、そぎ落としたことにより不満を感じるような箇所はほとんどないようになっている。
このバランス感覚に脱帽。
一応ゲームの製作側にまわっていたこともある人間として書いておけば、市販されているどうぶつしょうぎと同じものを「ペーパークラフト」等の形で発表していることには、なんら法的な問題はない。
ゲームのルールは著作権や特許の保護範囲外にある。絵柄などを盗用していれば著作権違反だが、WEB で公表されているペーパークラフトは絵柄などはオリジナルだ。
でも、「問題ないからこれで遊び続けよう」とは思わない。
自分はゲームの作成側の人間だったし、今でもその一員であると思っているので、評価できるアイディアに対しては正当な対価を払いたい。
…すぐさま、楽天 Books でどうぶつしょうぎとどうぶつしょうぎのほんをセットで購入。
どうぶつしょうぎ自体はルールは簡単だが、それでも戦うための「コツ」はある。
そのコツを、子供にわかりやすいように解説したのが「ほん」のほう。
これは、どうぶつしょうぎが面白かったので、僕自身が戦略を知りたくて購入する側面もあります。
決して子供だけのためではない。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
毎年恒例、高校仲間との花見をした。
毎年、開花予想がでたころ…だいたい3月上旬に予定を立て、十分に参加者が準備できる時間を置いてから実施する。
ところが、今年はいつも花見の実施を呼びかける（呼びかけるだけで幹事はやらない)役の僕が、忙しくて呼びかけていなかった。
そして、3月11日の震災。
まだ混乱の収まらぬ15日ごろ、試しに「花見はどうする?」と呼びかけてみた。
呼びかけるからには、やる気は十分ある。
でも、この時点ではガソリンの供給は滞り、店にも商品は十分ではなかった。
話し合いの結果、この様な時に自粛を行うことは経済を停滞させるだけで、自粛すべきではない、との意見が多数。
その一方、僕も含めて子持ちが多いため、公共交通機関は乱れ、ガソリン供給にも不安がある状況では、実際問題として実施は難しい、というのも事実だった。
何よりも問題だったのは、毎年幹事を行っている友人が、会社から急な特命を受けて忙しく、余裕がないことだった。
急な特命とは、計画停電に対する対応として、数週間で会社の事務所を、関西以西に立ち上げること。
あまりにも無茶な要望だがやらざるをえず、家に帰る暇もないという。
というわけで、毎年やっている花見だが、今年は中止。
花見は「旧交を温める」ために行っているので、花が見られなくても余裕ができたときに集まろう、ということになった。
ただし、最初に書いたとおり、自分としては花見をやる気は十分。
個人的にでも花見をする人がいればかけつけるのでよろしく、と表明しておいた。
そして、５日ほど前。
後輩から、花見をしようと声がかかった。
毎年幹事をしている友人にも連絡を取ったところ、新たな事務所は立ち上がったが、計画停電も早期終了となったため、事務所移転は中止となって暇になっているそうだ。
（夏の停電に備えて、資材などは確保したままだそうである)
というわけで、急な召集でいつもよりは人数が減ったが、恒例の花見開催。
人間が、どんなにおろおろしていようとも春はくるし花は咲く。
良し悪しはともかくとして、時間は過ぎていくのだ。
自粛していたってなにも始まらない。止まっているより動いた方がいい。
今回花見の会場とした川の土手では、多くの人がそれぞれの方法で春を楽しんでいた。
子連れが多かったのが微笑ましい。
ところで、最初に僕が開催の是非を問うたときに「自粛する」と答えた後輩がいる。
花見の席で、参加した後輩が、自粛するとと言った後輩に、メールで現状を尋ねたらしい。
…別の場所で家族で花見してた。それなら来ればよかったのに。状況を見極めた前言撤回は、別に恥ずかしいことではない。
同じテーマの日記(最近の一覧)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
長年プログラマをやっているが、見積もり作業と言うものが難しい。
…というか、プロとしてこんな事を言うのはどうかと思うが、はっきり言ってやり方がわからない。
プログラマではない方には関係のない話と思うが、暇ならお付き合いを。
プログラマで独立したいと思っている人は、他山の石として読んでいってください。
独立プログラマの仕事と言うのは、まず相手から「こんなプログラムが欲しい」と依頼されるわけだ。
この時点で、要求は漠然としている。場合によっては、自分が何を求められているのかすらわからないことがある。
でも、相手は言うのだ。「どれくらいで作れますか？」と。
ここで「どれくらい」には２つの意味がある。日程と金額だ。
この２つは無関係ではないが、独立している。でも、相手はそのことすら知らない。だから「どれくらい」という曖昧な言い方になるのだ。
自分が似たようなものを作ったことがあるなら、ある程度勘が働く。
でも、そればかりではない。そういう時は、細かな作業工程を想像し、積み重ねて概算を出さなくてはならない。
ところが、ここで矛盾が生じる。相手が依頼している内容が漠然としているので、細かな作業工程など出せないのだ。
かくして、まずは作業内容確認のカウンセリングから入ることになる。
本当に欲しい機能はなんなのか。どういう状況で使おうと思っているのか。必須機能はどれで、あれば便利だと思っている機能はどれなのか。
大抵はお客様は何らかの業務で思い悩み、コンピューターの力を借りれば解決できるのではないかと考え、どうすれば良いのかの方策を考えてから「プログラムは作れるか」と相談に来る。
しかし、プログラムの専門家ではない人が考えた「理想のプログラム」は、実現不可能な要求を盛り込んでいることが多い。
そこで、依頼以前の、業務の何で思い悩んでいるのか、と言うところにまで立ち戻って話をして、本当に必要としているプログラムはなにか、と言うところから一緒に考えなくてはならないのだ。
ともかく、いよいよ作られるプログラムの「要求仕様」が固まったとしよう。
この時点で、要求仕様は実現可能であることが前提だ。
「いい人材を見分けるプログラム」なんてものは実現不可能だが、アンケートや簡単なゲームを通じてなら、適正を見極めることができるかもしれない。
そういう、具体的方法論にまで踏み込んだものが「要求仕様」だ。
さて、これが「どれくらいで」作れるかを答えなくてはならない。
でも、これが実のところ、不可能なのだ。
個人で仕事を始めてから、初期の頃には荒見積もりを出すことの難しさに悩んでいた。
結局決めかねて「いい加減な嘘をついて」それらしい見積書を作るのだが、良心の呵責があった。
でも、プロジェクト進行について書かれた専門書なんかでも、この「荒見積もり」は不可能だ、と言うことが明記されているのね。
だから、大企業でもそれらしい嘘をつく。
作業に入る前に工程表を作ることなんてできない。
これは、プログラムに限らない。単純プロジェクトならともかく、ちょっと複雑なプロジェクトでは、全てそうなのだ。
特に、誰も経験したことがないはじめての作業を行う時には、工程表なんて絶対にまとめられない。
でも、それでは困る。見通しがたたなければお客様は発注はできないし、結局は自分にも仕事が来ず、お金が入らないのだ。
だから、嘘でいいから工程表を書く。それらしく書く。
まず、思いつく限りの細かい工程に全体を分解する。次に、それぞれの工程が「順調に行けば」どれくらいの時間で終わるかを見積もる。
ここでの見積もりは、間違えたって構わない。
初めての仕事だから難しそうだ、と思っていたものが案外簡単だったり、過去に似たものを作っているからすぐできるだろう、と思っていたものが、前提条件の違いで想像以上に苦しんだりする。
作業工程はできるだけ細かく分解しているが、実際に作業してみると想像外の作業が発生したりもする。
でも、細かな作業工程の個々の見積もりが間違っていたとしても、全体を通せば平均化される、と期待して見積もる。
ともかく、一度全体を「順調に行けば」どれくらいの時間で作れるか、を算出することが重要だ。
順調に行った場合の時間見積もりが出たら、これを１０倍する。
…いきなりそんな、１０倍なんて乱暴な。
そう思う人も多いだろう。当然だ。
僕も独立した頃は、何倍かに見積もらなくてはならないことはわかっていたが、何倍にするのが妥当なのかわからなかった。
３倍？ ５倍？ でも、経験則から言えば、５倍くらいの見積もりでは苦しいばかりで割に合わない。
答えは、ちゃんと古い本に書いてあった。「人月の神話」に、少なくとも９倍せよ、とある。
理由は簡単。
まず、技術者は、作業見積もりを出す時に技術面の難題を中心に考える。
実際には、難題以外にも、細かな作業が多数ある。それらは、難しくはないが時間がかかる作業だ。
そして、実はこうした作業の方が全体の中での比率は多く、難題部分に多くの時間が取られたとしても、その２倍は「簡単な部分」の作業に必要なのだ。
だから、簡単な部分も作るためには、時間を３倍して考えなくてはならない。
次に、技術者は技術面以外の事を考えない。
技術的に動くプログラムができたとしても、実際にはそれを「使いやすく」まとめる作業も必要だし、マニュアルなどを整備して、誰が見ても使える状態にする作業がある。
これらの、プログラムの本質ではない作業は、実のところプログラム本体の作業よりも長い時間…２倍はかかる。
だから、「動くプログラム」を「製品として使えるプログラム」にするのには、時間を３倍して考えなくてはならない。
結果、最初の見積もりの少なくとも９倍が、実際に作業に必要な時間だ。
僕は、計算のしやすさもあって１０倍を目安に考えている。それが、先に書いた１０倍の意味だ。
「人月の神話」では古すぎる、今はもっといい算出方法があるはずだ、と言う人もいるかもしれない。
でも、比較的新しい「デスマーチ」にも、今でもこの方法が有効だと書かれていることも追記しておく。
（デスマーチも、すでに古典ということにされてしまっているらしいが…）
本質的な問題として、作業工程を見積もる方法なんてない、確度の低い見積もりに安全係数（ここでは１０倍）を掛ける方法以外ないのだ、と知っておかなくてはならない。
初めて見積もりを書く、駆け出しの独立プログラマーは、ここで安全係数を掛けない見積もりを出して、全然割に合わない仕事をしたりする。（自分の過去の失敗談だ (^^; ）
作業時間が算出できれば、金額も算出できる。
１日は８時間労働、なんらかの専門家の日当は通常５万円なので、単純に計算すればよい。
１週間は５日間なので、それで計算すれば納期も算出できる…
ことになるが、それは少し伸ばした方が良い。
1.2倍にするか、1.5倍か、思い切って２倍か…は、人による。僕の場合、複数の仕事を同時に抱えることもあるので、先方に納得してもらった上で２倍の日数をもらっている。
しかし、実際にはこの日数は「保険」でもある。
先に書いたように、作業に入る前に作業工程を見積もることが、そもそも不可能なのだ。
最初に見積もった作業工程を１０倍することで、「想像外の作業」の発生は大体吸収できる。
でも、それらの想像外の作業が困難の連続になったとしたら？ ここで、納期を長めに取ることに意味が出る。
もし困難が多ければ、長めにもらっていた納期日数の中で収拾がつけばよい。
長めにもらった分については、金額を発生させていない。だから、ただ働きだ。
しかし、それは自分が見積もりを失敗した結果なのだから、甘受しなくてはならない。
逆に、想像以上に仕事が早く終わる場合がある。それは自分が優秀なのだから、お金は有難く頂戴すればよい。
いずれにせよ、見積もりと言うのは「お客様にとっての」保険に過ぎない。
見積もりで出した日数内に終わり、金額も見積もりどおりなら何の問題もないのだ。
余りにも困難で当初の納期に間に合わないとか、十分実現可能と思っていた要求仕様が、実は矛盾があって作成不可能だった、と言う場合もある。
そういう時は、問題の発生がわかった時点で、すぐにお客様に連絡。丁寧に事情を説明すれば、普通は納得していただける。
追加作業が必要だから金額を上げて、については了承されない場合が多いが、矛盾があるから仕様を変更したいとか、納期に間に合いそうもないから一部機能をカットしたい、など、交渉の方法はいくらでもある。
工程表を最初に作り、あとは何の状況も説明せず、では、最後になって「言っていたことと違う」という論争になりかねない。
できることなら、定期的に現在どの作業を行っていて、どこまで出来ているかを報告するのがよいだろう。
全体に遅れているのなら、素直に早い段階で「遅れています」と言われていたほうが、納期が来てから「出来てません」といわれるよりも良い。
完成していなくても、途中経過を時々見てもらうのも効果がある。
思ったものと違っていた、など早く気がつけば修正も楽だし、それがお客様側からの要望で当初予定とは違う修正になる場合は、追加料金をもらえる場合だってある。
途中からの修正の場合、実は遅れている工程がある場合には、その遅れ分も「修正に必要な時間」に内緒で入れ込んでしまって納得してもらう、というようなテクニックもある。
…と、急にプログラマーの仕事の一端を書いてみたが、これはプログラマに限った話ではない。
最初に書いたとおり、ちょっと複雑で、誰もやったことがないようなプロジェクトであれば適用可能な話なのだ。
東京電力が、福島第１原子力発電所の事故を収拾するための工程表を発表した。
早速、遅すぎるとか、本当にこの通りに実行できるのか、等といった批難が相次いでる。
先に書いたとおり、やったことがない作業の工程表など作れない。実行期間の正確性など、保証出来るわけがない。
しかも、今回の作業工程表は、実際のところ作業内容すら見えていないのだ。
「漏水を止める」と言っても、どこから、どのように漏水しているかもわからない。
つまり、プログラムで言えば要求仕様もまとまっていない段階で作られているのだ。
それでも、作ったことに意義はある。それは、作成依頼に対する「荒見積もり」と同じで、ある程度の概要を示すことが出来るからだ。
今後、作業が遅れそうなら、素直に遅れると、理由を説明して発表すれば良い。
もちろん、未知の作業に対して十分な余裕は見積もって工程表を作っているだろうから、前倒しになる作業もあるだろう。
実際に作業をされる方々には、幾多の困難が予想される。
見守るしかない我々としては、作業が前倒しになったり、遅延したりするのに一喜一憂していてはいけない。
作業工程表とは、もともと「その通りには行かない」性質のものなんだと理解しておくことが重要だ。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
spam に困っている人は多いと思う。
あれは食べ過ぎると太るしね。スパむすびおいしくて困っちゃう。
…というボケは置いといて、いわゆる「迷惑メール」のことね。
ホーメルフーズ社は、同社の商品である肉の缶詰は SPAM 、迷惑メールはspam と書けと言っているので、ここでは「spam」の話をする。
最初のボケを書いたせいで、何の話かわからなくなってしまった。
えっと、つまり「情報の扱い」の話をしたい。
spam を分類するのにベイジアンフィルタが有用だ、というのは多くの人が聞いたことある話だろうし、既に使っている人も多いだろう。
ベイジアンフィルタって何？ と言う人でも、Gmail を使っていれば自動的に適用されているし、メーラーに内蔵されているような場合もある。
あれがベイジアンフィルタなんて呼ばれていること自体、確率を真面目に研究している人からは怒りの対象らしいし、そうでなくてもよく使われている「確率式」が、素人目に見てもおかしなものだったりするのだが、ともかく実用上は動作している。
＃一応、仕事でベイジアンフィルタ自作してみたりもしたことをお断りしておく。
ところで、ベイジアンフィルタは、メールが「何かである確率」を出してくれるに過ぎない。
普通は、spamである確率を出す。これは学習型フィルタなので、学習次第でどんな確率でも出せる。
友達から来たメールである確率、会社から来たビジネス文書の確率、似たような「おすすめ商品のお知らせ」でも、自分が好きそうな商品か否かで分類することだって可能だろう。
でも、それはあくまでも確率だ。明確に分類できているわけではない。
そこで、ある程度の確率のところに線を引き（閾値と呼ばれる）、それを超えた場合に「spamである」などと断定する。
ここで問題になるのが、今回のテーマである「情報の扱い」だ。
閾値をどこに引くのが適切なのか？
spam である確率が 0% であれば、spam ではないだろう。
100% であれば、誰がなんと言おうと spam である。
では、60% なら？ 70% 、80% では？
どちらかといえば spam 寄りなのだから、spam として扱うべきだろうか？
実のところ、spam 扱いしてもよいのは、spam である確率が 90% 以上など、飛びぬけて高い場合のみである。
なぜなら、spam 扱いするということは「見ないで捨てる」可能性が高くなるからだ。
メールを見た結果、spam を見つけてうんざりする方が、重要なメールを見ないで捨ててしまうよりも良い方法なのである。
spam に限らず、膨大な情報を処理し、一部だけ抽出して後は捨てる、と言うことは日常で普通に行われている。
この際、情報を捨てた結果どうなるか、拾った結果どうなるか、情報の中身に応じてよく考えた上で扱いを決めなくてはならない。
５年間しまいこんであった箪笥の中の服を整理するのであれば、基本的に捨てる、という方針で臨むことが正しいだろうし、癌検診の医師は少しでも異常があれば拾って再検査に回す、という方針で臨むことが正しいだろう。
情報の扱いとは、画一的に方法が決まるものではない。
正解はないが、その状況によって正しい方法を熟考し続けないといけない性質のものである。
と、急にこんな事を思ったのは、携帯に溜まった緊急地震速報の履歴を追ってみたから。
…なんだ、また大震災がらみの話か、とお思いの人もいるだろう。申し訳ない。
2010年9月29日の17時00分に、関東地方の携帯電話向けに緊急地震速報が通知された。
福島県で地震発生、との内容だった。
＃改めて確認したら、福島だったのね…。後知恵だが、予震だったのだろう。
これ、FOMA が「普及期」に入ってからは初めてだったこともあり、結構話題になった。
僕も初めて受信したので驚いた。
でも、実際には大きな揺れは観測されなかった。
これは「速報」という性質上仕方のないことだったと思う。
地震、という、生命を脅かす危険のある情報の扱いとしては、僅かでも確率があるならば、拾った方が良い情報なのだ。
福島で地震があった、と言うのは事実だ。その地震から僅かな時間で、地震の影響範囲を計算し、影響が強いと予想される範囲に対して警告を行う。
しかし、この範囲は「予想」でしかない。結果論として、関東で揺れはほぼ観測されなかった。
関東で観測されなかったとしても、福島で大きな地震があった、という事実は変わらない。
なのに当時、「誤報だ」として気象庁が叩かれた。マスコミに叩かれたのみならず、政府にも見直しを命じられ、実際に「速報をあまり出さないように」システムが改変された。
その結果どうなったか。
2011年3月11日の震災本震発生時には、東北地方のみが通知範囲とされた。
関東北部は、緊急地震速報の想定する「震度３以上」を観測したが、通知範囲外だった。
ちなみに、この２日前の 3月9日午前11時45分にも、宮城で震度５弱を記録しているが（これも予震だったのだろう）、緊急地震速報はでていない。
（関東に、ではなく、警報そのものが出ていない）
生命にかかわる情報は、誤報といわれようがなんだろうが、通知しなくてはならない。
昨年９月の緊急地震速報を、誤報だと叩いた人間は（マスコミに限らず、全ての人は）深く反省しなくてはならない。
この震災で、ネットワーク化された地震計などの設備が損傷し、復旧に至っていないため、十分なデータが得られない状態が続き、緊急地震速報に「誤報」が多くなっている。
…と、少なくとも公式には、気象庁はそう説明している。
ネットワークが寸断されたのも、地震計が壊れたのも事実だろう。
そのためにデータが十分でなく、予想が難しくなっているのも事実だろう。
しかし、それは単純に「誤報が多い」ことには繋がらない。
単にデータが足りないだけなら、緊急地震速報の発報が行われない、となることの方が多いはずだ。
（緊急地震速報は、速報性を重視しているため、最初の１つの地震計の揺れで発報する。しかし、近隣の地震計が揺れなければ、即座にキャンセル報が出される。つまり、ネットワークが寸断されれば、キャンセルだらけになるはずだ）
現在の状況では、強い余震が警戒されている。しかし、観測体勢が十分ではなくなっている。
となれば、システムのパラメータを改変して、情報の扱いを「疑わしければ拾う」側に寄せてあるのではないか、と推測する。
つまり、気象庁が言うように、単純なシステムの不具合ではなく、不具合を修正できない状況下においても、最悪の事態を防ぐ方向で、わざと誤報を増やしてある、ということだ。
これは推測に過ぎないが、情報の扱いとしては正しい。
先日、緊急地震速報が発報された直後に twitter を（厳密に言えば buztter を）見ていたら、「誤報が多いので、通知しない設定に切り替えた」と言う人が沢山いた。
これは、情報の扱いとして正しくない。
緊急地震速報は天気予報のような「予報」ではなく、確実にどこかが揺れたことの「速報」だ。
たとえ速報値による推測が間違っていて、自分が住んでいる地域が大して揺れなかったとしても、軽く見てはならない。
次の警報では、致命的な揺れがくる可能性がある、と常に警戒していないといけない。
どんな状況においても、情報を正しく扱うことは、自分の身を守る第一歩だ。
…と、強く思っているからなのだが、誰が読むかもわからない日記に、最近「情報の扱いの話」ばかり書いている気がする。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 自体：事態の表記違い、他ページも含めて指摘ありがとうございます。修正しました。 (2015-04-07 12:03:02)【校正エージェント】 「…なんて呼ばれていること事態、」 (2015-04-05 10:52:01) |
WEB の CGI プログラミングの話。
単に WEB ページを見せるのではなく、わざわざ CGI を使用している場合は、状況によって表示する内容が刻々と変化することが多い。
この「刻々と」は、つまり「ユーザーの操作によって」の意味である。
ユーザーの操作は積み重なっていくが、データが少ないうちは、URL にデータを入れ込んで置けばよい。
ところが、データが多いとそれは無理となる。
この場合、サーバ側にデータベースなどを持ち、URL には、そのデータベースのアクセスに必要な最小限のデータだけを持っておくことになる。
この場合、問題となるのは、ブラウザの「戻る」ボタンを押されることだ。
データベースには常に最新のデータしか保持されていないのに、ユーザーが閲覧するページには古いデータが残っている状態となり、データの不整合を起こすのだ。
多くの CGI プログラマーが、頭を悩ましている問題である。
解決策の１は、戻るボタンを押したらエラーを出すことである。
データベースには、常に更新されるチェックデータを用意しておき、URL の一部としてこのチェックデータを入れておく。
最新のページからアクセスがあった場合は、URL に入っているチェックデータと、データベースのチェックデータが一致する。
しかし、一致しなかった場合は「エラー」とする。
これで、戻るボタンが押されることでデータの不整合がおきる、と言う問題を回避できる。
めでたしめでたし。
…この方法の問題点は、WEB ページにとって「お客様」であるユーザーに、非常な不便を強いることだ。
ブラウザの「戻る」ボタンは、非常に使われる頻度の高い機能である。
使わないつもりでいても、うっかり押してしまうこともある。
そして、エラーが表示されるのだ。
これはページを見てくれる人を追い返すには十分。
最悪の解決方法である。
解決策の２は、戻るボタンを消してしまう方法。
JavaScript を使用して新しい window を開く時に、ツールバーを「表示しない」ようにすれば、戻るボタンは消えてしまう。
消えれば押されることもないわけで、解決。
…これも、解決策１とたいして変わらない。
うっかりエラーがでて最初からやり直し、という最悪の事態にはならないが、「戻る」ボタンが使えないという不便を強いることに違いはない。
それどころか、「戻る」以外の機能も全部巻き添えで使えなくしているわけで、ユーザーに大変な不便を強いることになる。
解決策３は、Javascript で戻るボタンを無効化する方法。
<script>
history.forward();
</script>
を全てのページのヘッダ内に書いておくだけ。
これは、「履歴の次のページにすすむ」というプログラムである。
通常のアクセスであれば、これが実行されても「次のページ」は存在しないため、何も起こらない。
しかし、戻るボタンが押されて開かれたページでは、次のページが存在するため、より新しいページに進む。つまり、最新ページが常に表示された状態で固定される。
結果、戻るボタンは表示されているが、機能的には無効化されている。
ユーザーの不便は最小限かもしれないが、「戻る」という重要な機能を失っていることに変わりはない。
以上３つの解決策が「悪い解決方法」なのは、戻るボタンの歴史的意義を理解していないためである。
WWW 開発以前にも、ハイパーテキストは存在した。
そして、ハイパーテキスト研究の重要問題の一つが、「迷子問題」と呼ばれるものだった。
ハイパーリンクは、テキストに対する説明や、関連話題として示される。
そこで興味を持ってリンクを辿るうち、元のテキストに帰る方法がわからなくなる。
…単純に言って、これが迷子問題である。
これに対する初期の解決策が、「戻る」ボタンであり、現在ではハイパーテキストの閲覧に必須と言ってよいほどの機能となっている。
だから、戻るボタンの機能を無効化してはいけないのだ。
無効化することは、つまり「テキスト閲覧お断り」を表明しているに近い。
閲覧して欲しいからページを作っているはずなのに、本末転倒である。
昔を懐かしむわけではないが、携帯電話向けに策定された HDML では、「戻る」ボタンに自由な機能を割り振れるようになっていた。
先に書いたように、「戻る」ボタンはハイパーテキストの閲覧に必須の機能であり、無闇な書き換えは推奨されない。
しかしまた、HDML では「戻る」は、直前に閲覧したページに戻る事を意味しなかった。
複数のページを「機能的なひとまとまり」として定義する方法があったため、「戻る」ことにより機能を途中で抜け出したり（機能に入る前のページに戻る。時には数ページ前となる）、正常に完了した機能のページは「戻る」の対象から外されたりした（完了した機能内のページには戻れず、その機能の前のページに戻る）。
つまり、HDMLにおいては「戻る」とは、直前のページではなく、ユーザーが「戻りたい」と思う場所に適切に戻るための機能だったのだ。
そして、この方針に従う限り、「戻る」ボタンによって新たなページを読み込むことも許容されていた。
戻るボタンの機能を書き換えるとき、機能を「無効化する」ような書き換えを行うのではなく、WEBページ提供側に対しても、閲覧側に対しても許容できる箇所に戻るように気を使わなくてはならない。
というわけで、今回仕事で必要だったので開発したテクニック。
戻るボタンの機能を書き換え、指定された特定ページに進ませる。
注意点として、先に書いたように、閲覧者が違和感を感じないようなページ遷移にすること。
少なくとも、戻る機能を書き換えたことで袋小路に迷い込んだり、来たこともないページに飛ばされたりするのはよくない。
仕掛けとしては、解決策３で示したスクリプトの拡張にすぎない。
解決策３では、「次のページがある（戻るボタンで戻った）ときは、強制的に次のページへ」進むようにしていた。
これを、「戻るボタンで戻ったときは、最新のページで指定された URL へ」進むようにする、というだけ。
とはいえ、単純ではないので、まずは説明から。
まず、問題なのは「最新のページで指定された URL 」という部分。
基本的に、JavaScript はページ（ドキュメント）の中で完結して動作するため、変数などでデータを受け渡すことはできない。ページ遷移が行われれば、変数が破棄されるのだ。
そのため、最新のページで指定された、という「指定 URL データ」をどう渡すのかが問題となる。
とりえる方法は幾つかあるが、ここでは window.name を使う。
window.name は、ドキュメントの入れ物である「ウィンドウ」の特定に使われるものであり、ページ遷移してもデータが破棄されない。
これは、ページ間のデータ受け渡しに使用できる。
つまり、最新ページでは、読み込まれた際に window.name に、「指定 URL」を書き込む。
「戻るボタン」で戻られたことを検出した際には、この指定 URL に飛ぶようにプログラムを書く。
これで、「戻るボタンを押したら指定 URL に進んだ」ことになり、目的は達成できる。
しかしここで別の問題が発生する。「戻るボタン」で戻られたことは、どうやって検出するか？
JavaScript にできることは、「ページを表示する際にプログラムを実行する」ことだけで、その表示理由が、読み込まれたからなのか、戻ってきたからなのかは判らない。
ここでもまた、window.name が活躍する。
ページが読み込まれる毎に増加する値を JavaScript 内に用意しておき、プログラム実行の最後に、window.name の中にも書き込むのだ。
window.name への書込みよりも以前に、この値を比較すれば、プログラムの実行理由が判る。
・JavaScript 内部の値よりも、window.name の値のほうが古い
→ページは新たに読み込まれ、表示された。
・JavaScript 内部の値よりも、window.name の値のほうが新しい
→「戻る」ボタンによりページが表示された。
単純に増加していればよいので、unixtime でも十分だし、アクセスカウンタがあるならその値を利用しても良い。
基本戦略としては、以上で終わり。非常に単純な話だ。
プログラム的には、window.name は１つしかなく、書き込みたいデータは２つあるので、文字列の連結・分割が必要となる。
カウンタは数値、url は文字列だが…両者とも「空白」（ASCII 20h）は含まない、という決まりがあるので、空白で分割できるようにするのが、おそらく一番簡単だろう。
プログラムは以下のようになる。
（CGI 側で、$time $backurl の部分に、適切な値を埋め込んで JavaScript プログラムを生成すること。
$time は unixtime 、$backurl は、戻るボタンが押されたときに進みたい URL が設定されている）
var p = window.name.split(' ');
if(p[0]>=$time) location.href=p[1];
window.name="$time $backurl";
たったの３行だ。解決策３の中央の１行の代わりに入れること。
（つまり、script タグで囲んでヘッダ内部に入れること）
実は、これだけでは FireFox で動作しない。
FireFox では、「戻る」ボタンで戻ってきた際には、JavaScript が動作しないためだ。
JavaScript が動作しない理由は、「最初に表示された時に JavaScript によって変化したデータを保持している」ためである。
再表示の際には、すでに JavaScript プログラム適用済みのデータを表示して高速化しているのだ。
しかし、onUnload という機能が設定されている場合は、この限りではない。
onUnload は、ページの表示を終了する時に JavaScript を動作させるための仕組みである。
この機能が設定されているということは、ページのデータは「再表示するのに適切でない」可能性があるため、初期状態のページから再度 JavaScript を起動させる。
というわけで、FireFox 対策に、次の１行を挿入する。
window.onunload = function(){}
以上の合計４行で、事実上「戻る」ボタンの機能を再定義したことになる。
window.name は、便利なので様々な Hack で使用される。
そのため上のテクニックが利用できない場合には、代替手段として以下のような方法もとれるだろう。
・Cookie を利用する。
ページ間のデータ通信さえできればよいので、Cookie を使ってデータを保存しても良い。
ただし、セキュリティのためにブラウザが Cookie を受け取らない設定になっていたり、プログラムがガジェットとして Frame 内で動作したりする場合に使用出来ないこともある。
また、JavaScript で Cookie を扱うのは「可能だが結構面倒」なので、プログラムが無駄に長い。
var p = document.cookie.split(';');
var v;
for(var i in p){
if(p[i].replace(/^\s+/,'').substr(0,2) == 'c='){
v = p[i].replace(/^\s+/,'').substr(2,999).split(' ',2);
}
}
if(v[0]>=$time) location.href=v[1];
document.cookie="c=$time $backurl";
・webStorage を利用する。
webStorage は、新時代の Cookie である。
Cookie の欠点がいろいろと解消されている一方、使用できるブラウザが限定される。
var p = sessionStorage.c;
if(sessionStorage.c>=$time) location.href=sessionStorage.u;
sessionStorage.c=$time;
sessionStorage.u="$backurl";
自分は仕事の都合でこの方法を編み出したのだが…仕事上の制約でいろいろ使えない機能もあったので、代替手段も一緒に開発することになってしまった。
基本戦略さえ理解してしまえば、他にも代替手段はあるのかもしれないが、自分は３つの方法を編み出した時点で「仕事上問題がなく使える技術になった」ので、ここで終了となった。
以上。
せっかく考えた技術なので、誰にも教えないで内緒で使いたいところだが、どうせ JavaScript なので、ソースを見られてしまえば何をやっているか一目瞭然なので公開した。
以上の話、３月１１日の日記に書こうと思って準備中だった原稿である。
その後、なんとなくアップロードするタイミングを失っていたのだが、今思い出してファイルを見直したら、書き終わっていたようなのでアップする。
推敲中だったと思うのでどこかおかしいかもしれないが、何を書き直そうとしていたのかも忘れた。
地震直前に書いていた、なんてことは忘れていたのだが、ファイルのタイムスタンプを見たら、作成が3/11 13:00:13 、最終更新が 3/11 14:13:05だった。
閲覧する方にはどうでもよい話だが、僕にとっては妙に心に残ったので、ここに記しておく。
後日追記
デモページを作ってみました。
戻るボタンの機能を書き換えているところを、実際に体験できます。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
長女と次女が相次いで誕生日。
４歳と２歳になりました。
しかも、保育園の「４月のおたんじょうび会」が、２１日でした。
というわけで、２１日は次女は保育園でみんなに祝ってもらい、家に帰ると大好きな焼き鳥にケーキ。
その理由はよくわかっていないみたいだけど、とにかくニコニコしていました。
ケーキは、コージーコーナーのチーズスフレ。
お誕生日プレートを乗せて、ロウソクを立てればこれで十分。
というか、生クリームだらけのケーキは、２歳児には食べにくいので。
次女のお祝いに対し、長女は「わたしもお誕生日？」。
まだだよ、と言うと「明日？ 明日の明日？ 明日の明日の…」。
週末をはさんだので、ことある事に誕生日を待っていました。
で、月曜日の２５日。朝起きるなり「今日はわたし誕生日！」。
保育園ではもうお誕生会は終わっていますが、今日が自分の誕生日である事をアピールし、みんなから「おめでとう」と…強制的に言わせてまわります。
僕はと言うと、夕食に向けて準備。
長女の好きなご飯は…焼き魚。とくにホッケの干物。
でも、それは御馳走感がない。
何より、やはり魚好きの長女の要望で、前日に回転寿司に言ったばかりです。
ということで、妻がポトフを作ろうといいます。
ポトフも長女の好きな食べ物。
じゃぁ、僕はパンを買ってきます。数日前に、「パンダ☆パンだ！ 食べたい」と言っていました。
これは、近所のスーパーに入っているベーカリーの作っている菓子パン。
名前の通りパンダの顔になっています。
小学生になった長男と一緒に買いに言ったので、彼の希望で「かめろんパン」も一緒に買います。
こちらは、カメの形のメロンパン。
同じスーパー内の不二家でケーキを買おうと思ったのですが…
こちらも、長女の要望あり。回転寿司のデザートに各種ベリーの乗ったケーキがあったのですが、「最後に食べる」と言っていたのに、お腹いっぱいになって食べ忘れたのです。
というわけで、要望は「苺のいっぱい乗ったやつ！」。
不二家には苺のショートケーキはあるけど、長女の欲しがっているものとは少し違った。
買い物を終えたら、その足で保育園に迎えに行こうと思っています。
余り時間はない。長男をせかして、車で少し離れたシャトレーゼのお店へ。
「チョコのケーキがいい」という長男に、でも長女が欲しがっているのは苺のやつだから、と説得すると、「じゃぁ、今回は譲ってあげるー」。
譲るも何も、長女の誕生日だから、長女の希望が重要なのだ。
大きいケーキだと、たっぷり苺やベリー類が乗っている。でも、高いし分量多すぎ。
小さなケーキだと、苺は５つ。ただ、中にも苺ムースや苺のコンポートが入っている。
…散々迷って、小さい方。ケーキの前の御馳走もあるし、これくらいで無いと食べきらないから。
お誕生日のお祝いに、長女はニコニコ。大喜びでした。
でも、ケーキを買うのに走り回って、父は重要な事を忘れていました。
前からせがまれていた、誕生日プレゼント買わなかったよ… (^^;;
誕生日当日は、大喜びでプレゼントのことは気にならなかった様子。翌日もまだ忘れてた。
３日目の今朝になってやっと「らくがき教室は？」と聞かれた。
次のお休みにみんなで買いにいこうねー、と誤魔化しました。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |