zak blog

近況

Sat, 08 Dec 2012 23:25:58 +0900

木曜、未明から金曜日まで寝込んでました。数年ぶりの突然の悪寒から高熱(38℃～)だったのでインフルエンザを疑ったのですが、金曜日に病院で検査したところ陰性とのこと。ただの風邪だったのか。でも、陰性だったので、来週出社できるので一安心。

土曜日も丸一日寝ていたのですが、やっぱりこの半年間続いている悪夢のため身体の疲れは取れず。寝過ぎのせいか、首と腰もかえって痛くなってしまい散々な状態でした。

悪夢に囚われているのは、おそらくは、私欲にこだわっているからなのだと思うのです。私欲は捨て、公益のために生きることが回避できる近道なのではないかな、とふと思いました。安易な逃げの考えなのかもしれませんが、腑に落ちたので記録としてこの場に書き記します。(2012/12/08 23:34JST)

業務委託に関する契約３類型について考える

Sat, 07 Apr 2012 22:22:03 +0900

PMBOKでは業務委託契約について３つのタイプに整理して説明しているが、それぞれについてのポイントを考えてみた。

【定額契約（一括請負契約）】

一般的な請負がこの類型に相当する。金額を固定にして業務の完成を請け負う性格上、契約を締結する時点で、最終的な完成の着地点が見えていないと非常に危険である。

もちろん、バッファーを多く乗せて、リスク管理に長ければ、着地点が不明瞭、作業内容及び範囲がはっきりしていない案件であっても、この方式で十分やれるのであるが、実際に仕事をやらされる人間は不幸になることが多い。

【実費償還契約】

これも業務の完成が完了の前提になるのであれば、請負ということになるだろう。

ただ、目標価格（稼働）がコミットメントを意味せず、超過すればその分請求し、減少すればその分割り引くという性質から、あまりITの世界では使われない（土木工事では使われる事例もあるらしい）。

発注者側から見れば最終的にいくら掛かるか見えない契約は結びたくないだろう。

減少した場合、アワード、インセンティブとして報奨する方法もあるが、やはり、そのような体制でやれるのは自社内部での案件とか、関連子会社との取引に限定され、全く独立した会社間の取引では使いづらいように思える。

【タイムアンドマテリアル契約(T&M)】

派遣、SES、コンサルタントなどがこの類型に相当する。法律行為の代理であれば委任、そうでない有償のものは準委任である。

派遣、SES、コンサルタント、それぞれ毛色も違えば、費用感も全く異なるが、共通していることは、稼働単価に対しての支払いであり、業務完成に対する支払いではないことである。

従って、最終的に物事を完成させる責任を負わせる事はできず、悪く言えばお手伝い、よく言っても助っ人ということになる。期間も長期間ではないスポットであり、それが故に多少割高なリストプライスであるのはしょうがない。

ただし、コンサルタントも人間なので、理不尽な顧客に無茶な要求を出された場合にはなるべく距離を置いて早めに離脱できるように、信頼できる顧客に対しては、最大限尽力したいと言う風に変わるようだ。

謹賀新年

Thu, 05 Jan 2012 00:00:44 +0900

2012年、平成24年始まりました。
旧年中にはお世話になった皆様へありがとうございました。今年もよろしくお願い致します。

2010/2011年の目標はコントロールを取り戻すことでした。結果、ある程度の成果が得られたもと考えています。

今年は変革の年にする。
勉強も再開したい。
薬も減薬のフェーズにトライしたい。
そろそろ世のために働くことを意識したい。

業務システム開発と運用とは本質的に思想が異なる件についての考察

Fri, 30 Dec 2011 16:42:25 +0900

業務システムの開発と、そのシステム運用について２年ほど携わった経験を振り返っての所感。きちんとウラを取ったものではなく、個人的な考えをまとめたドラフトなので、間違っているかもしれない。

なんで、こんな事を考えるようになったかと言うと、本物のミッションクリティカルなシステムについて、たまたま開発と運用の両方をPLとして主管する期間があり、いわゆる想定外の事象（考慮漏れ）と、人為ミスを繰り返してきた過程で、これは実は思想的な問題があるのではないかな、と思った次第。レベル分けすると、以下のような壁で分断されているように思うところである。

想定外の事象　>>>(あり得ない壁)>>> 想定内の稀な事象(一部手運用だが検証済の手順有り) >>>(コストの壁)>>> 想定内の事象(システムが自動リカバリする) >>>(運用と開発の思想の壁)>>> 要求された開発要件にあるエラー処理

※(2011/12/31追記)
ミッションクリティカルにもいろいろあって、止まると自社の業務が停止して、株価に影響が出るとか、最悪つぶれるというものも該当すると思うけれど、ここで言っているものとは違う。社会インフラの一部としての情報システムが停止した場合、社会生活に大きなインパクトがあり、そういった分野では、出来る・出来ないが問題ではなく、常に低リスクを選択しなければならない、というところです。

業務システム開発と運用とは本質的に思想が異なる件についての考察（ドラフト 2011.12.30）

【システム開発】

（思想）
開発は「プロジェクト」つまり、リリース・納品という明確なゴールが存在する。

（基本形）
開発要件を期限内に満たしてリリースするために最善を尽くす。
最善は尽くすけれども、バグを0にすることが不可能であるということと同様に、開発の途上、リリース後に想定外の事象が出るのは当然のこととして考えている。

（非機能要件）
明確に要求仕様で提示されれば、それを満たす要件定義を行うが、要求が無いところに要件はなるべく増やさない（∵やることを増やしたくないので）。

（商用機の取り扱い）
運用中は基本的にＮＧ、運用側の要請が無い限り開発は手出し無用。
ただし、停止を伴うような大規模リリースは開発サイドで主管する。

【システム運用】

（思想）
運用は「プロジェクト」ではなく、ゴールは存在しない。常に改善あるのみ。

（基本形）
安定運行が第一優先。
何事も問題を起こさないために何が出来るか、想定外を想定内に収めるためには何ができるかを考えている。
→そのためには、初めて実行するコマンド、手作業は絶対NG（どうしても必要なときにでも、必ず手順を明らかにして、検証を行った後に実施。）

（非機能要件）
安定運行のために、（レスポンス性能、データ保存期間、状態監視、障害時対応フローなどなど）非機能要件の洗い出しと設計（マニュアル化）を必要とする。開発が意識しない（≒やりたがらない）事項についても注意喚起を行う。

（商用機の取り扱い）
運行業務の主管として、運用作業手順に従った操作を行う。
人為ミス防止への取り組みは重要なテーマ。

想定外の事象が発生した場合、もしくは発生する可能性が高い場合には、仕様だけでなくシステムの実装まで理解している開発スタッフにも臨場をお願いする。

※追記
DevOpsの話も知っていますが、これって開発と運用の違いを理解した上での次のレベルなんだと思うのです。

http://www.publickey1.jp/blog/11/devops.html

MySQL Clusterその後（これから使ってみようと思っているみんなに）

Thu, 24 Nov 2011 04:20:13 +0900

以前に書いた、MySQL Clsuterを使ったシステム本運用開始直後のログから2年近くが経過しました。ちょうどいい機会なので、その後の運用を踏まえての感想と、今後の展開について記録を残します。現時点で秘密でない事項についてのみ書きます。

１．SunからOracleへ

知っての通り、MySQLはSunを経てOracleの所有物になりました。
気がついてみるとOSSの主要なデータベース技術のうち、Berkeley DB、InnoDB、MySQLがOracleになってしまいました。

（よかったこと）
GPLのデュアルライセンスは今のところ守られています。そのためMySQLにお金を払ってくれるユーザは、今まで通り限られたままで財政的には厳しいはずなんですが、今のところOracleはMySQLに対してコミットを守っているようです。特に変わったところとして、「リリースのスケジュールが守られるようになった」、「GA版のソフトウェア品質を高いものにするためによりコストをかけるようになった」、「リファクタリングを積極的に展開している」というような話を、しばしば聞く機会が多くなりました。

（よくなかったこと）
僕達のようなユーザ側にしてみると契約絡みが面倒になった以外では良くなかったことというのはありませんでした。とはいえ、Oracleと言う会社はそういうことをやって大金を稼いでいるわけで、商品・役務の売り方と、契約には個人的には興味深いです。

２．MySQL Clusterのバージョンについて

導入時には7.0.8aを使用し、当時はまだ7.1.xはGAになっていなかったわけですが。２年を経た現在においては２つともGAになっています（7.0.28、7.1.17が最新）。community版では7.0.xの積極的な配布は行わず、最新版は提供されていないようです。

品質としてはかなり安定的であるように感じます。バージョンアップ不可避な事象に当たったのはこの２年で１回で、データが壊れる、不整合が生じるといったようなデータベースとして最低限守らなければならないラインで疑義が生じた事はありませんでした。ただ、コンサルタント、サポートも知らなかった隠れた仕様、性能限界、その裏にある設計思想が導入後に明らかになったことは残念でした。

7.0.x系と7.1.x系はEOLのスケジュールが同時タイミングに設定されており、今すぐ新規構築するのであれば、7.1.x系(7.1.17)になるでしょうし、既存の7.0.x系のシステムが動いているのであれば、7.0.28になるでしょう。
ただ、噂では7.0.xの最新版には7.1.xの新機能がバックポートされているため、完全なメンテナンスリリースとも言い難いという話もあるようです。

本当はバージョンアップはなるべく近いバージョンで細かく実施することが、継続的デリバリ(CD)の観点からは必須なのですが、現実には、商用環境において、DBのバージョンアップは、相当難しく、セットアップした使ったバージョンを使い続ける傾向があるため、バージョンの選択は慎重にする必要があります。

何故バージョンを上げないかというと、業務システムのような特殊なアプリでは発行されるクエリは一定のサイクル（時間、日、週、月、年）で似ているため、そうやって一回商用環境で業務を遂行したこと自体が、（DBを含む）システムが枯れた、と認識されるからなのです。このため、逆にDBのバージョンアップとは、それが故の問題が発生する可能性が否定出来ないリスクの高い行為と考えられ、業務が全部問題なく遂行できるだけの担保が求められてしまいます。（※もっとも自社サービスであるならば、状況は違うかもしれません）。

これに答えるための方策として、まだ、僕自身うまい方法を考えついていないのですが、全く同じデータをコピーした新環境に全く同様にクエリを旧環境と新環境の両方にミラーして投げ続けて検証する、といったことができないかな、と考えています（RBRミラーリングではデータはコピーされますが、データベースへのクエリを再現することはできないですし）。

３．初めてMySQL CLusterの導入を考える皆さんへのアドバイス

MySQL Clusterに求める機能として、【高速な読み書き】、【Active/Active構成の高可用性システム】のどちらかに大きなメリットを感じないのであれば、採用を見送ることを考えるべきでしょう。特に、今はSSDという選択肢もありますから、まずはそれで十分か、不足があるかの観点で考えてみてはいかがでしょうか。

以下には、MySQL Cluster導入時の検討事項について導入後～２年間の運用を振り返って記載します。

・MySQL Clusterの皮を被ってはいるが、完全ではない。できることが、できなかったりするので、差違について十分に調査・見当すること。そのままInnoDBがオンメモリになったつもりで使うと、GCP Stopが発生する。

・高速な読み書きができるのは、基本的に主キー（プライマリキー）に帰着できるケースのみ。インデックスを使ったアクセスは性能上の限界値が低い。

・JOINは使えるがパフォーマンスが出ない（開発中の7.2のAQLで改善の見込みあり）。

・ユニークインデックスは主キーに次いで高速なアクセスを実現するけれども、特別なサポートテーブルを内部に生成するため、それが故の制約が存在する。

・ストレージエンジンが異なるテーブル通したトランザクションを張ることはやめるべき(InnoDBとNDBなど、分離レベルも異なるし、出来ないと考えるべき）。

・ここで言うところの高可用性は、Active-Active構成で、SPOF無しの構成を本気で組む前提がある場合で、そうでないならば、無理にMySQL Clusterではなく、通常版のMySQLを使用することを勧める。

最初に書いたとおり、MySQL Clusterと通常版のMySQLは似て非なるものです。普通のMySQLの知識は30%くらいしか通用しないので注意して下さい。できれば、そばに詳しい人を置くか、最低でもサポート契約が無いと、プロダクション環境で使用するのは厳しいと思います。

４．今後の展開に期待すること

昨年ぐらいにNoSQLがもてはやされましたが、MySQL ClusterのベースとなっているNDBはもともとそのNoSQLで、NoSQLは速いけれど、スキーマを投入してデータ抽出をSQL構文でやりたいというのがそのモチベーションなわけで、ある意味、時代を先取りした部分もあると考えています。

SSDが安価になり、性能観点で、無理にインメモリDBにこだわる時代では無くなりましたが、超高可用性と、比較的容易にスケールアウト可能なアーキテクチャーであることにはまだまだ魅力的な所があります。僕は試していませんが、NDB Disk storageも（スピードは出ませんが）安定して動いているという噂です。

今後もMySQL Clusterが主要な柱となるべく開発リソースが投入され続けるといいですね。

小休止を考える

Wed, 07 Sep 2011 01:50:52 +0900

2010年2月から続いていた「ちょっと手伝って」の仕事について、ようやく軌道に乗ってきた感がある。事業としての不透明性は確かにあるが、業務執行を行う組織作りとして完成に近づきつつある。今期中には完成するだろうか。

情報処理のマシーンとして、大混乱の中、ひたすらアウトプットをしてきたけれど、そろそろ、情報のインプットをすべき時期が戻ってきたように感じている。

夏期休暇

Fri, 05 Aug 2011 04:04:14 +0900

2011/8/5～2011/8/9の５日間を夏期休暇とすることにしました。

一年前は、５＋１名（ほぼ全員新人）だったチームメンバーは、１２＋１名に増強されました。システム開発上、運用上の課題はいろいろありますが、やっと交代ができるようになったと思うことにしたい。

日産LEAFに乗ってみた

Thu, 05 May 2011 23:33:07 +0900

電気自動車(EV)である、日産LEAFがレンタカーで借りられるそうなので、昨日(5/4)借りて実際に運転してみた。以下は感想。

（良いところ）
・静かで走りはなめらか、かつ加速力も十分

　見た目は普通の車なので、全く違和感なく乗ることが可能（現に、陪乗した彼女は僕が教えるまでEVであることを全く気づかず）。操作感はガソリン車と比べて全く遜色がないレベルに達していると言える。

　エンジンではないので、モータをふかすというような概念は存在しないけれど、アクセルをちょっと踏み込むとすばらしい加速力。これまでの電気自動車の（せいぜい20km/hしか出ないカート）概念を打ち壊された。
　停止状態～50km/h～100km/hまでの加速も滑らかで、風のような走りと僕はその日形容した。

　もちろん、ポルシェのようなスポーツカーと比べれば全然まだまだ、だけれども、普通車としては高級ガソリン車の域に達している。

（不満なところ）
・航続距離が130km程度とまだまだ短い

　貸し出し時に、「充電から多少時間が経っているので、80%残容量、航続距離120kmくらいですので、途中の公共充電器で充電して下さい。満充電にする必要はありませんが、ほぼ空の状態で返却はやめて下さい」と言われた。

　当日は、東京の木場～神奈川の藤沢までの60km弱の旅程だったんだけれど、これだと帰りは足りない。バッテリーが完全に上がってしまうことを、ガソリン車になぞらえて、EVでは「電欠」と呼ぶらしい。

　しかも、行きの旅程では調子に乗って加速性能とかを試すために、かなりアクティブに走らせてみたところ、バッテリーをみるみる消費してしまう。。。

　ECOモードという節電モードもあるので、切り替えてみると、急に車に元気が無くなってしまう。それでも、軽自動車(CVT)くらいの加速力はあるのだけれど、正直、走る上では全く楽しくない。

・充電に時間がかかる

　自宅でも充電ができるのかな？と思い、トランクの充電器を見てみると、200Vの専用コンセントでないとダメらしい。。。しかも、数時間レベルで時間がかかる。

　急速充電器ならば30分で80%まで充電できる、とのことで、設置されている場所を探してみると、藤沢市役所にあるらしい。電話して行ってみた。

　急速充電器は電源ケーブルが、ガソリンスタンドのホース並に太く、かつ、中身は銅線なので非常に重い。。。女性ではちょっと厳しいかも。装置も物々しいし、「絶縁試験中」ですとのメッセージも出るので、ちょっと一般人には怖いかも。後で調べたところ、400V 100Aでしかも直流(DC)で給電する装置だったらしい。。。交流ならまだマシか、と思っていたところ、直流だとすると、これは何か間違いがあると即死事故が発生しかねないように思える。

・高音周波数は耳に触る

最初は電車と同じだからしょうがないと思っていたけれど、やはり、高音周波数が耳にさわるところがあまり良くない。これはLEAFに限らず、プリウスでもよく言われてはいるけれどね。

（総論）
航続距離の事さえ除けば、既にガソリン車を十分以上越えた存在になっていると思います。

価格面でも、まだまだプレミアム感が強いところではあるけれど、（優遇税制も活用すれば）買えない金額でもない。

航続距離がどうしても限られてしまうので、ルートが限られているような営業車、あるいは近くに買い物にしかしかない人なら十分。

しかし、自動車の最大のメリットである、「どこにでも行ける」がまだガソリン車には及ばないところは、まだまだ電気自動車が主流にはなり得ない所なのかもしれない。
もし、例えば、航続距離が一回の充電で350km以上、一回の充電を10分以内とすることができれば解決すると思うけれど、それにはまだまだいろいろなハードルがある。

一区切り

Sat, 30 Apr 2011 00:52:52 +0900

4/27の無停止リリース成功。皆の努力の結果だ。呪いが解けたかのように順調。

これでやっと一区切り。

新年度

Sat, 23 Apr 2011 02:21:07 +0900

年度末から新年度明けまで、日記をかく暇もない状況でした。
昨年末からずっと業務が混乱していてずいぶん消耗していますが、
まあまあ、元気です。人間なかなか斃れないものだなと実感しています。

今週中に2.5リリース工事完了。来週中に1.5fixリリース予定。

それが終わっても、結局開発案件が並列に動く状態は解消しないのですが、徐々にカオスな状況から収束に向かわせたい。

自分自身のコントロールを取り戻すことが昨年度の課題でしたが、ある意味では過酷ではありますが、リズムが作れてきたかもしれません。今度はチームと、メンバーのコントロールがミッションとなりました。

でも頭を冷やして今後のことを考える余裕がまだ無いのが現状。夏前にはやりたい。

・・・
管理職として、毎日の日報報告を受けるのだけれど、毎日10名以上の報告を聞くのは結構大変です。

近況

Sun, 23 Jan 2011 18:57:07 +0900

年初からいろいろありますが、何とか活動しています。

来月に鎌倉を引き払って、東京に引っ越すことにしました。

2011年正月

Sun, 02 Jan 2011 01:54:42 +0900

謹賀新年。

昨年の目標はコントロールを取り戻す、であったけれど、３末まで３月を残した状態でいえるところとしては、少なくとも毎日規則正しくを起きることが出来るようになったということがある（もちろん、彼女の助力あってのことですが）。

年末続いていたデスマーチについては、まだ完全には収束はしていないが、落ち着く傾向にはあるようです。こちら側が混乱をさらにかき回していうように思え、僕個人が落ち着いた思考をすることが出来ない状態です。家と部屋の内部がカオスになっているのは、僕の脳の中身とそう相違がない（当然、ＰＣのデスクトップも同様である）。

教えてもらった吹き替え動画について、笑ってしまうが、ここまでひどくは無いが、部分的には真実にあることだったり、まさにそういう発言をしてしまったりしているは気をつけるべき。

http://www.youtube.com/watch?v=CFZiil0DfMc

http://www.youtube.com/watch?v=3dkec0M-7zI&feature=fvw

対外的には打つべき手は打ってきたつもりではあるけれど、ここへ来て状況が動きそうなので、これもより僕に取って好ましい形になれるように、アクションを取ってゆくつもりである。

インフルエンザ

Wed, 10 Nov 2010 03:22:34 +0900

今年はインフルエンザのワクチン接種を受けた。大人は１回で良いらしい。針が進歩しているせいか、あんまり痛くない。むしろ、接種後にかゆくなるくらい。

８月～状況はいろいろ変わっているが、とても忙しい。他のことを考える余裕が今は全くない。OHIMからのOppsitionの件と、DEからの暫定的拒絶通報について対応したいが、今は無理だ。

今の優先順位は、

１．月末のリリース工事に収まること
２．事故を起こさないこと

だけれど、どちらも最重要課題なので難しい。
しかし、人月稼働でmax８人使ってもまだ足りないとは。。俺の管理能力のレベルがまだまだ低いということか。

このまま来月頭の本格リリースを迎えた後に、一息付けるかどうか。まだ判らない状況。そのまま、同時並行で走る残り４本のプロジェクトはどうしたものだろうか。今の計算だと厳しいかもしれない。

とりあえず、ここで斃れるわけにはいかない。

１０月近況その２

Wed, 13 Oct 2010 02:31:30 +0900

10/2(土)ぐらいから喉が不調で、10/4には完全に風邪引きモードになってしまった。夕方にシステム障害（事故）が発生し、青くなるかと思ったが、熱で熱いのか、状況が熱いのか判らないの緊張感。ある意味で戦場。

たまる、会社の目の前の病院に駆け込んだところ、８０過ぎくらいの院長先生で、「いや、薬はやるよ。でもやっぱり養生せにゃ」というのを５回くらい聞かされる。いや、いちいちごもっとも、ではありますが、そういうわけにも行かない。弱い薬をもらって、ゆりゅると直しようとしている途上(10/7)

1と２は譲れないとして、3はまあまあ、妥協。あとは住環境が何とかならないか。
この２～３習慣は特別体制で対応で、家に帰れない、帰る。という選択肢も考える必要があかもしれない。

引っ越しは金の問題があるがめんどくさいので、誰かアレンジしてくれないものか。

１．仕事
２．家族
３．食生活
４．住環境
５．余暇

１０月近況

Wed, 06 Oct 2010 03:33:07 +0900

仕事が異常に忙しい。メンバーがこれから１１月末にかけて派遣駆けつけも入れると、１０名のチームになってしまった。今年の２月は要員＝俺一人だったのだが。

そんなわけで、
自分のことは一切優先的に出来ない。周りの進捗状況の確認をず～っとやり続け、指示を出しつつ、戻ってきた質問に回答して、さらにお客さんからの問い合わせ（先方も７名）にも対応する。
PMの仕事ってそんなもんだよ、とは言われて納得はしているつもりだけれど、まだまだみんなPGレベルのスキルで、今やっているシステムを理解出来ていない、ということからか、いろいろな面で考慮が足りない、詰め甘い、などいろいろ、制御範囲外のことがごろごろ出てきている。

なんとか、要件定義を集中審議してfixさせたい。でないとこのプロジェクトは炎上し、デスマーチと化してしまう。そして失敗すればニュースになるだろう。きっと。

＊＊＊＊

先週の木曜の夜くらいだったが、歩いて帰宅途中で迷い犬に出会った。首輪の痕はあるようだけれど、極端に人を畏れていて、虐待されていたのかもしれない。がりがりにやせているわけではないけれど、足下がおぼつかず、道路を横断しようとしてつまずいたりして危なっかしい。

ぼくは、それを１５分ぐらい見続けたあと、向こうの方に何とか道路を渡ったところで、バイクと車の人が見つけていた。

今の僕にはどうすることもできない。無念。