2010/09/25

うーむ

寝起きに書き殴ってるからちょこちょこと変だな。
まぁいいや。ちょっとづつなおそう。

2010/09/19

運用のこと2

続きです。

Do担当者がCheckを行うことが期待されていない(のに言ってくる)。運用設計がもともとそういう仕組み、つもりじゃないので、ボトムアップ型の運用設計をPlanに反映させるという意識や仕組みが無い。だからバーストしてて、原因はPDCAの意味の捉え方のズレ?というところでした。

 で例えば「自分の経験ではそんなことはない。現場での『気付き』をどんどん報告してくれ、という文化がある」という人もいると思うが、結果どうでしょう?E/Uからの期待や要求には細やかに応えられるようにはなったけど自分が楽になったか?と言われれば楽どころかその分手順が増えてきつくなる一方だという人も多いんじゃなかろうか。いや、私自身の環境がそんな感じだったので自分とこだけがヘッポコだったのかもしれないけども。これは文化があっても「仕組み」が無いということだったんだと思う。

それか、文化が浸透していない。部長は「どんどん意見をくれ」と言ってくるけど、課長(自分たちが直接報告する相手)に報告すると「チッ」とか言われる。この場合、文化や仕組みは部長の頭の中だけにあるのかもしれない。

まとめると、自分たちがPDCAだ!と考え、良かれと思ってやった事は・・・
・運用設計の見直しをする仕組みがあると
 <仕事>が<仕事2>に進化する。

・運用設計の見直しをする仕組みが無いと
 <仕事>が<仕事+対処>になる。


E/Uからの要求、取り扱うものの変化に応じて、前者は<仕事3>、<仕事4>・・・と変っていくけど、後者は<仕事+対処+対処><仕事+対処+対処+対処・・・>になってしまう。文字のバイト数で見たまんまのバースト具合になっていると思ってよい。前者はずーっと5byteの仕事、後者は要求が増えるごとに6byteずつ増えてる。(+は全角。)
 さらにこれ、対処方法ごとにマニュアルがとっちらかったり、管理DBが別システムになったりというオマケがつくこともザラなので、見たまま以上のバーストっぷりになることもある。

じゃあどうすれば良いかという話で締めたいけど、ちょっと大掛かり過ぎて、少なくとも現場作業員の工夫でどうこうなるような方法は思い浮かばない。自分が実践してたのはノウハウの抱え込みをして解決さえできれば違反があっても文句は言われないというポジションをゲットして、堂々違反する。という手段だけどこれは敵が多くなるのでやめた方が良い。味方も多くできるけど全体的な雰囲気を考えるとダメだろうな、と思う。

(でも自分はこうしていたおかげで、他のメンバーたちが終電で帰るのが当然だった中で、一人だけ毎日定時退社できてた。就業時間中もみんな昼飯も食わずにやってる中で、45分に一回席を外して休憩し、一度休憩に出たら20分は行方不明みたいなペースだった。違反というのは<仕事+対処+対処・・・>のルールに違反して、自分だけ<仕事n>の方法で働いていたということ。タチ悪いと思います。ほんとに。そこに行き着くまでにそりゃあ紆余曲折ありましたけども。こうなることが自分のリビングデッド(生ける屍)化だったわけです。)

メンバーは、現状、実態とプランのあわないところをどんどん報告するしかやることなさそう。プランを作るサイドの人間が、既存のルールにどれだけ手順を重ね合わせてそれを実現できるか、という考え方を持てるような、持たざるを得ないような仕組みを、更に上から押し付けることしかないかな。いまのところ。
 Pで対処できないようなものは報告もしねーで帰っちまえ。Pを考えたやつらが馬鹿だ。っていうのが素の自分の思いだけど、これはさすがにダメ。契約にもよるが。。。でもこうして対処できない問題が溜まっていくのが、再設計のきっかけとしては一番パワフルな気もする。

しかしここでいう「仕組み」てのを「フレームワーク」っていうのかしら?とりあえず
暫定対処法を恒久的に続ける事を恒久的対処法と呼ぶのはやめよう。

ということで。

2010/09/18

運用のこと

えー、その筋の人は「PDCA」ってイヤになるほど聞かされてる言葉だと思いますが、これ、実際には何をやるものかを勘違いしてる人も多そうなのでちょっと記そうと思いました。前職の現場での理解では、P(プランを立てて)->D(実行して)->C(見直し、練り直して)->A(実施) と解釈してるバ。。人が多く、またこれが改善サイクルで現場の自浄作用と捉えてるように見受けられました。ずいぶん前に読んだITILの参考書にもそんな風に書いてあった記憶があります。自浄はともかく、どんどん良くなっていくスパイラル的な説明だったかと。

ところが実際はというと、そのPDCAが実行され、成果が出ているところを見たためしが無いんですね。何かが起きる毎にPDCAだPDCAだとギャアギャア言う割りに、運用が良くなっていく現場とは縁がない。ここで多くの人は「(PDCAという言葉の流行の発端になった)ITILは聖書」として「できれば素晴らしいんだろうけど、できれば苦労しない」と諦めたりとか、「実際の現場に沿ったフレームワークへの落とし込みがどうのこうの」というところに腐心したりする。資格のための知識と割り切って諦めてしまえばもうそれで良いかもしれないし、それで運用を設計する側にも行きたければ行けるでしょう(私が今ココ)。しかし諦めたらモヤモヤしたまま残業してなきゃいけないし、実行部隊から抜け出して万歳!じゃ解決してない。そしてまた新しいアルファベット3~4文字の手法に踊らされて運用現場に余計な仕事が増えていくと。

でも違うよね。と。ITILなんてそもそも顧客(英政府かなんか)から押し付けられたもの。そうじゃなくて「運用ってもっと楽にできる余地がすごいある気がするのに、なんでこんなバースト??」という現場のモヤモヤ感を立脚点にして、考え直す必要がある。ITILがOSI参照モデルとすると、TCP/IPにあたる具体的なプロトコルも必要じゃないか。それが無いからいろいろダメっぽい。と思った次第。
「フレームワークへの落とし込みどうのこうの」はその中間をすっ飛ばしてる感がある。

それで状況を整理するためにWikiでPDCAサイクルの項目を見てみると、一発で何もかもわかった気がしたので(というか自分の勘違いに気付いた)この記事を書くに至った。wikiでの説明は次の通り。
  1. Plan(計画):従来の実績や将来の予測などをもとにして業務計画を作成する
  2. Do(実施・実行):計画に沿って業務を行う
  3. Check(点検・評価):業務の実施が計画に沿っているかどうかを確認する
  4. Act(処置・改善):実施が計画に沿っていない部分を調べて処置をする
「実施が計画に沿っているかどうか」ですよ。「計画が実施(実情)に沿っているかどうか」でなく。

最初のプランがどんなに現場の仕事に合ってなくても、それを修正する仕組みはこの中には無い。これまでのみんなが「見直し、練り直し」だと解釈していたCは、最初のプランに違反してないかどうかをチェック(Checkだぬ)するパートだし、AはCでの違反部分をPに沿ったものに戻す、という工程だったりする。Actの説明文に改善って書いてあるけど、これはCで違反があった場合は当初のPより「悪い」からそれをPになおすこと。に留まってる。Pをより良くしようとする改善ではない。

でもITの現場は取り扱うものや技術の進化がすごいと言われているし(他の業界知らんけど)、そうして変化したものや技術を使ってる側からの要求は当然一つの進化に対して複数生まれるので、もっとすごい。だからむしろ当初のP計画が今のD実情に体系を与えることができているかどうかを見直す必要がある、ということ。

で、PDCA本来の意味がどうであれ、Cが現状に即したプランへの練り直しとAがその実行という意識でみんな、特にDに一番詳しいはずの作業者が行動しているなら、うまく回らない理由にならないじゃないかと考える向きもあると思うが、ほとんどのバーストしてる運用の問題点はむしろここ、というのがwikiを見てバーンと思いついた。

これって、Doは現場の人が実行するんだけどPとCとAは現場にいるより上の人間がやってる。運用フレームワークはDoをする人間達をきっちり管理する目的で導入されてて、自浄ではないという本質がある。だから現場でCheckを行っても現場判断で勝手にActするわけにはいかない。でもとにかくその場はやらなければしょうがないので直属の上長に相談?報告?して承認され、Actの前例は増えていく。これはつまり作業員目線の場当たり的な対処が増えてくことで、上の人からみたらどんどんPlan無視の方向に進んでいるように見える。

 さて、管理対象の作業員達が、管理者の決めたプランに従わずに仕事をしていて、忙しい忙しいと言って来たら管理者はどう思うだろう?現場の風潮にもよるだろうが、まずはPを守れ、定量的なデータを出せ、その上でデータの分析・問題点の抽出を行い、話はそれからだ。というのがよくある流れじゃないだろうかと思う。でもそもそも、Doする人たちにとってCheckは余分な工数だし、工数としてでなく思考の中でCheckが行えているなら追加の工数をとらずに説得力を持たせるのはなかなか難しい。大抵の(自ら自身の作業に対してCheckを行う良心的な)作業員はここでモチベーションを失ってリビングデッド化するんじゃないか?

 もうちょっと食い下がる人なら業務終了後に残業し、定量データをまとめて、考察つきのレポートを出すかもしれないけど、これもすんなり受け入れるような文化の土台が日本には無いように感じてるし、そのレポートの内容が尤もだとしても、必ず何かのケチはつくもんだと思う。
 ある管理者は作業員にドキュメント作成のスキルを身につけてもらおうという良心からレポートのレイアウトを指摘するかもしれないし、別の管理者は自分の仕事を増やされたくないという思いから、効率がどうであれSLAは満たしている、と言って相手にしないかもしれない。レポートを受け取って、「わかった。考えとく」と言ったきり何も無いという管理者も実にいそうだ(爾後確認に行ったら大した説明も無く「ああ、あれね。ダメだった」とか言われる)。

作業員はPを修正させたい。運用設計者は設計しなおすためのデータが欲しい。間にいる人間はトップダウンを守らせるつもりでいて、ボトムアップをPに反映させるきっかけになるポジションという意識があまり無い。だから作業者から上がってくる対処法を都度承認して終わる。承認された対処法は毎度OKが出るもんだからすぐにそれが仕事の一部と考えられるようになってしまい、運用の再設計をする人間がわけのわからないまま現場はバーストしてる。こんなところじゃ無いかと思う。
 これは、間にいる人間がバカだとか悪いとか言うんじゃなく(気は利かないと思うが)運用再設計に至る仕組みがないのが問題だということで、それが「有る」と作業者に誤解させているのがPDCAという言葉なんだろうなぁ。ということ。

長くなってしまったのでまた帰ってきてから続きをします。でかけなきゃ(・ω・`

2010/09/14

PHPて

スクリプトといえば最近、先にLuaとかやっちゃったので(WarHammerOnlineのアドオン書いてみただけですが)どうもPHPがオバカな感じに見える。VBイヤになってC挫折してDelphiやり始めた時のことを思い出した。そしてHaiku全然触ってない。。

2010/09/12

PHP+MYSQL -> HTML, Javascript+CSS

動作するところを作ったらユーザインタフェースと例外処理が待ってて、これが面白くないのでペースダウン中。よくもまぁこんな増改築を繰り返しすぎて迷路になっちゃった旅館のようなもんを皆使うよなぁ。と感心することしきり。(IE対策(pgr) とか。まぁIEが行儀悪いんだろうけど。)

HTML5 で状況改善するもんだと思ってたら、ぐちゃぐちゃな現状に無理やり体系の方をあわせたような進化っぽいので、こちらもあんまり覚えようという気力がわかず。

2010/09/05

今日はPHP+MySQL on Vista

で、大ハマり。

バージョンとかも書かないでアレですが、似たような環境の人のために(もういっぱいほうぼうに書いてあるけど)。DOS窓(っていうのか今も?ターミナル?コンソール?)からはMySQLサーバに接続できるのにPHPからは接続できない人。Vista以降のWindowsはデフォルトでlocalhostの名前解決してくれません。hostsファイルを編集するか、"localhost" っていうサーバ名を使ってるところを"127.0.0.1"にしたら動いちゃうかも。

・・・・それだけが原因というわけでもないですが。

こんなのとっとと片付けてHaiku触りてぇ。

#9/14追記)DOSプロンプトでした。

2010/09/04

パンクロックが好き。

でも、何か色々音楽聴いて「俺こういう感じの曲好きだなー。何ていうジャンルだろ、、、パンクロックってゆーのか。」程度。 なので、やれ”どこのバンドの誰が何年に脱退して加入して” とかいう話はサッパリ。俺はパンク好きであって、パンクバンドおたくではないからこれでヨシ!と思ってる。

自然な流れ?でメロコアも好きですなー。

2010/09/02

毎日とても眠い

暑い思いをした日、は猛烈に眠くなってしまい、やりたい事が色々とできずにいる。。。Haikuいじりとか。