T

今日から出勤しない

初の「今日から出勤しなくていい日」がやってきました。ついついうっかりして、新しい職場となる自室で朝7時から働いてしまいました。

ケータイ向けサービスの開発会社に5年間勤めて、今日から自営業を本格的に稼働させています。おそらく年内はこんなかたちで主に自宅で働いていくことになります。が、自営業を続けるつもりは毛頭ございません。パートナーとして現在仕事をもらっている人たちと何らかのかたちで(って法人化する以外ないんですが)起業することになります。

それにあたって、あんまり大きなことばかり考えても仕方がないので、2つだけ目標を作りました。ひとつは、「長く続けられる仕事をする」です。退職金があるわけでもなく、とにかく世間でいうところの定年まではローンもあるので仕事を続けていかなくてはいけません。そこで、「長く続けられる仕事」というものを深く深く分析して、やがてひとつの結論に至りました。ここで特別にみなさんにもお裾分けします。すなわち:

「長く続けられる仕事」 = 「ゆとりのある暮らしができるだけの収入」 + 「働きやすい環境」

「真面目に考えろ!」と怒るだろうな、という顔がいくつか思い浮かびます。でも、これはとても真面目な考察です。そう見えないなら、騙されたと思ってください。思ったところで何も変わりませんが。それでも説明しますと、会社を辞めてしまえば、業務に関わるいろいろなことを自分でコントロールする必要があります。何に投資してどれくらいの仕事をしていくのか、匙加減を間違えるとたちまち仕事や生活は破綻してしまいます。とはいえ、手元の資金はほとんどない状態なわけですから、最初から選択肢は限られています。なので、どれを取ったら最適なのかを判断すればいいだけのことです。そして、その判断の基準となるものが、上に挙げた非常に難解かつ禅問答的な公式なのです。

収入に関していえば、最低でも税金や生活費、ローンの支払いが終わっても貯金できるくらいの金額である必要があります。サラリーマンの年収の平均である533万円、可処分所得の中央値である480万円程度は確保されるべきでしょう。この点には議論や妥協の余地はありません。また最低でも数ヶ月程度、それだけの収入の見込みがなければ、開業するべきではないでしょう。

働きやすい環境を定義すると、もちろん業務内容によってそれは大きく異なるわけですが、ウェブアプリケーション開発というかなり特殊な職種であれば、ジョエルテストの点数を満点にすることから始めるのがいいでしょう。WEB2.0的な物言いが嫌いな方は、そうですね、壁に飾る認定証が足りなくて夜も眠れないで暮らしているに違いないでしょうから、ソフトウェア品質技術者資格認定でも受験すればいいと思います。止めはしません。ひとつだけアドバイスするとしたら、そんなのを受験するくらいだったら、こんな駄文を読んでいる暇なんかないんじゃないでしょうか。

さて、ジョエルテストで12点取ればいいでしょう、と簡単に言いましたが、別にそれが簡単というわけではありません。第一、企業としてのインフラ整備が出来ていてはじめてジョエルテストでチェックする意味があるわけですから、チェックする前にやらなければいいけないことがたくさんあります。それに加えて、例えば、お金をかけずに、という条件がつくことがあります。

そうそう、ここらでもうひとつの目標を挙げておきます。それは

「小さな会社、投資家は無し」

です。これまでみてきたいろいろな会社で起きていた問題の大半が、その根本的な原因は、堅実なビジネスプランのかわりに絵空事の成長予測を据えて、出来もしない規模の拡大計画で無茶な案件をこなすのに体力を消耗し、みすみす機会を棒に振ってきたことによるものでした。成長しないという選択肢もあるわけですから、身の丈に合った仕事を長く続けられるよう、適正な規模であり続けるのも大事だと思います。ですから、しばらくはオフィスも持ちたくありません。設備投資は最小限にします。

というわけで、まず作業場である自宅にBフレッツのオプションとして固定IPアドレスを追加しました。ASAHIネットのサービスで月額840円でした。これでリモート開発の準備完了です。次にメインの開発言語はRubyにして、簡単な案件はRuby on Railsで構築することにしました。理由は、herokuが使えること。データセンタでラックを借りたりサーバやネットワーク機器の管理を続ける余裕はどこにもないので、どうしてもホスティング会社に頼る必要があります。herokuであれば開発時は無料のプラン、そのまま本番環境として運用する場合は規模に合わせて有料の適当なプランに変更、と状況に合わせて損の出ないやり方を選べます。Gitとの連携もあるので、Railsでの開発に最もストレスとなるデプロイの問題も特に気にする必要がありません。SSLの必要な案件でもない限り、herokuは有力な候補となるでしょう。もちろん、Railsだけで完結しない案件もあります。たいてい本番運用時の環境はクライアント様が用意したものになるので、そんなときは開発環境に自宅のマシンをサーバとして利用します。nginxのリバースプロキシで各環境を束ねてVMWare ESXiで複数のOSを起動していますが、ハードウェアはhpのProliant ML115 G5、よくオンラインストアで15,000円くらいで販売されているやつです。昨年購入したのですが、キャンペーン価格で12,000円でした。それにAMDのPhenom II(クアッドコアです)CPU、2TBのHDD、メモリは8GBと増設していって、合計で50,000円くらいかかりました。大きな買い物ですが、たぶんそこら辺のレンタルサーバよりは快適な環境です。吹っ飛ばしてしまっても仮想環境なのでまあ問題ないです。電気代も少々かかりますが、夏のエアコンほどではありません。それから、企業インフラとして欠かせないメールサーバやファイルサーバ、スケジュール管理はGoogle Appsを申し込んで無料で済ませてしまいました。運用管理のコストを考えると専用の環境を用意するなど問題外でした。可用性について問題視する向きもあるかもしれませんが、それでもたいていの自社管理のメールサーバよりマシなんじゃないかと思います。それからRedmineを導入して進捗の管理などに活用しています。

開発会社の体裁を整えるだけなら、そんなに投資額は要らないみたいですね。

不安がないかといえば、おおいにあります。余裕なんかどこにもありません。でも、そもそも勤めているときだって経済的には非常に苦しかったので、年収の平均額を考えればこのままでいるよりも失うものより得るものの方が大きいだろうという予測はありました。家計が赤字だったので、どうせ赤なら真っ赤になって、南の島で燃えて死ぬ、くらいの勢いもありました。でも、どうせ勢いでやるにしても、ちょっとくらい戦略があってもいいよね、と考えたのが上に書いたことです。今のところ、順調に仕事はもらえています。このまま、もう少ししたら福利厚生の部分を整えてきちんと法人化していきたいと思います。

組織と集団

食事中の方には申し訳ないが、「凌遅刑(レンツェ)」という処刑方法がある。ずっと前に、確かジョン・ゾーンのプロジェクトでアルバムタイトルとジャケット用写真に使われていたので知ったのだが、要するにこれは公開処刑の一種で、死刑囚を直立した状態に縛りつけ、体のあちこちを少しずつ切り取ってネチネチとなぶり殺しにするやり方のことだ。清朝の中国まで行われていたので、探せば写真による記録も見つかる。ジョルジュ・バタイユに至ってはその写真からあれやこれやの考察をものしているくらいだから、それなりに有名だ。

組織というものについて考えるとき、まあたいていは夜中にひとりで考え事をしているときなのだが、よくこのレンツェについて想像を巡らせてしまうことがある。身内を殺された人ならともかく、赤の他人にこんな残酷な処刑をすることができるのは、相当なサイコパスか、そうすることを命じられた人しかいない。誰だって生きたままの人間の手足を切り刻んでうれしいわけがない。そう、うれしいわけがないようなまねをするのは、サイコパスか組織に属した人間しかいないのだ。

集団の面白いところは、人間は社会性というもののせいでいろいろと利他的な行動を取ったりするようになる一方で、集団に属していることで「上からの指示」や同調圧力とやらで倫理のタガが外れたような残虐なまねをすることもあり、そうでなくとも人間というのは複数で集まればセックスや金の見栄の張り合いみたいなことをして喜んでいる変な生き物なのだ。だから、会社の同僚のことを考えるとき、ちょっと病的かもしれないが、もし彼らが残酷きわまりない皇帝から俺のことをレンツェに処するよう指令を受けたとき、こいつは俺を助けるだろうか、それとも迷いつつも処刑するのか、あるいは淡々と便所掃除のように割り切って俺を切り刻むのだろうか、と想像することがある。

当社比100倍のススメ

ウェブ開発の世界で、コードや設計の見直しが必要なのに、あまり時間や労力を割いてもらえないのが、速度の問題である。セキュリティなら見直しどころかとにかく素早く確実に対処する必要があるわけで、これは有無をいわさず誰もが取り掛かるであろうが(そうでなければ転職するべき)、遅いソフトウェアについては、まあ動いてはいるわけだし、もっと優れたハードウェアに載せ替えることで対応できるならそちらを選択するのも現実的だと考えられがちだ。高速化なんて、実際やってみても成果が上がるとは限らず、また開発者も無理な日程でリリースしてきたコードを今更また眺めるのは苦痛でしかない。いっそ書き直してやるならまだしも、あれやこれやと最適化するのは考えるだけでも面倒くさい。

しかし、実際には遅いウェブサイトは機会損失であり、いくら昔と比べてハードウェアが安価になり、仮想化技術が発達したとはいえ、それだって無料だったり無限に増設可能なわけではない。PCサーバ1台の増設をサービスのプロデューサに納得してもらうのは結構難しいことだ。仮想環境だってたくさん立ち上げるにはそれなりの実環境が必要になる。不景気の中で運用コストが上がる解決方法しか提示できないのは競争力に問題があるといわざるをえない。よって、スケールアウトは常に正しい解決ではない。

もちろん、最初から最大限に速度を追求してシステムを組むのは素晴らしいことで、誰もが実践するべきだ。しかし、そんなに簡単なことなら速度が問題になることなどあり得ないわけで、実際にはこの点を追求し過ぎるとリリースしなければいけない期日を守るのがとても難しくなってしまう。遅いのも機会損失だが、リリースできなければ機会が存在さえしなくなってしまうので、エンジニアリング過多は根治されるべき疾患だ。

期末が近づいてきたので、この2年くらいの自分の仕事をざっと整理してみたのだが、一昨年の暮れから今年の始まりにかけて、よく考えたらずっと既存のソフトウェアの高速化ばかりやってきた気がする。最初の立ち上げから1年以上経過したサービスがとうとう音を上げてしまったこともあれば、作ったばかりなのに社内の別チームから要求された速度が到底達成不可能だったので急遽なんとかしなければいけなくなったケースもある。恨み言をいわせてもらえば、ハードウェアやシステム構成の選定は当の検品屋連中だったりするので、そいつらの見積りが甘いのが原因なのだが、お客さんの求めるものがあってのソフトウェアであるわけで、理不尽だと叫んでもプログラムは速くはなってくれない。

そんなとき、誰もが思いつくのは、出力データや処理結果をキャッシュして速度を稼ぐ方法だろう。ご多分に漏れず自分もだいたいいつもそうやってきた。ウェブ上のプログラムには、大変ありがたいことにエントリーポイントがひとつしかない。そう、リクエストを受け付ける場所だ。出所の同じHTTPのリクエストは同時に一ヶ所にしか届かない。そこから、中間の処理があって、出力先は最終的にはリクエストを送ってきたクライアントになる。

前提条件 => 処理実行 => 処理結果

ネットワークの遅延や巨大なレスポンスによるクライアント側の負担といった問題は、普通はそんなには起きない。単純に考えると、結局はウェブ上のサービスはリクエストという前提条件があり、ソフトウェアによる処理があり、レスポンスという処理結果があるだけだ。

ということは、前提条件と処理結果の関係を把握して、その近道を探すのが高速化の第一歩ということになる。ここでのチェックポイントは

「前提条件(リクエスト)と処理結果(レスポンス)の関係」

の検討だ。自分で作業する場合は、まず

(1)リクエストをグループ化することができるか

を考える。メソッド(GETや、POSTときどきDELETEやPUTみたいな動詞)、リクエストURI、クエリで処理結果が同じになるグループを作成することができれば近道は見えたようなものだ。

例:GETのみ、docomoのゲートウェイを通過、FOMA端末、/listsへのアクセス、クエリは「type=used&maker=toyota」であればレスポンスは共通

この場合、リクエストを受け付けた際に既に同じレスポンスを返したかどうか判定して、していなければ通常の処理を実行してキャッシュを作成、キャッシュが作成済みであれば処理をすっ飛ばしてキャッシュからデータを返す、という単純な対応が可能かもしれない。キャッシュの実装内容はシステムのI/O負荷により異なるだろうが、そこは後で検討すればいい。ストラテジーパターンで変更できるようにするとか、まあいろいろ手はある。

そこで問題になるのが、動的コンテンツを提供する場合、まあ当然ながら静的なコンテンツで速度が問題になるのはほとんどあり得ないだろうから当たり前だが、レスポンスとして返されるコンテンツの内容の更新頻度だ。リクエスト毎に内容が変わるのであれば、単純なキャッシュでは対応できない。そこで

(2)更新頻度のグループ化

について検討することになる。いまどきカウンタなんか載せているサイトは絶滅しているだろうが、それでも刻一刻と在庫状況が変化したり、コメント数が増えていくようなコンテンツはたくさんある。

ページ全体が同じ頻度で更新されることは稀だろう。同じリクエストとみなしていいグループに常に新しいContent-typeを返すことはあり得ないが、オークションの入札状況のようにサーバ側のリソースに変化があればそれを常に反映する必要のある部分もあれば、人気の検索語のように1時間くらいに1回更新しても誰も気づかないようなものもある。

例:更新頻度最大 = 入札状況、更新頻度中程度 = 残り3時間以内の商品、更新頻度低 = ホットな検索語

更新頻度のグループがあまりに細分化されている場合は、運用者とよく話し合って、可能な限り単純化していくことが必要になる。サービスの品質に影響がない程度に、できれば3パターンくらいになるとちょうどいい。

3パターンくらいであれば、キャッシュした全体のデータに部分的なキャッシュを組み合わせてレスポンスを作り上げるだけのプログラムをリクエストを受けた場所で処理して済ませることができる。

それから、もっとサーバに楽をさせてあげたいときは

(3)クライアント側に処理を肩代わりできるか

を検討する。PC向けサービスであればクッキーに格納できるデータもあるだろう。JavaScriptにあらかじめ呼び出されそうなデータを格納してしまってもいい。検索候補を表示するのに正直にデータを毎回取得したりせず、サーバ側からは定期的に更新するだけのデータをブラウザ側に先に送っておけば、毎回非同期通信が走ることもない。

もちろん、第三者からアクセスされてはいけないデータもあるので、なんでもかんでもこのやり方が正しいわけではないが、なんでもかんでもサーバ側で処理するのも同様に正しくはない。でも、推測不可能なハッシュ値を格納しておいてそれをキーとしてmemcachedにデータを探しに行って、なければDBに問い合わせるといった対応も可能だ。

3はちょっと話が逸れたが、1と2は「前提条件(リクエスト)と処理結果(レスポンス)の関係」の検討だ。これらがクリアになれば、途中の処理をどれだけ端折ってレスポンスを作成することができるか考えるのはそんなに難しいことではなくなる。

そうなると次にやるべきことは

「処理実行の副作用への対処」

ということになる。アクセスログのように勝手にサーバ側で実行される副作用なら深く考えることもないだろうが(カスタム形式に必要な処理があれば別だ)、検索履歴の保存やアフィリエイトからのアクセスの記録など、サーバ側に直接レスポンスとは関係のない副作用が生じるケースがあれば、それに対応しておかないとサービスには深刻な影響がある。関数型言語をかじったことのある人なら、ある関数が副作用を持つことで前提条件と結果の関係だけで安心することができないことを充分教育されているだろうから、この副作用というものについては手続型言語しかやったことのない人に比べれば敏感かもしれない。

というわけで、単純な考察に相応しい単純な結論として、高速化が可能なプログラムを作るには、上の手続きの反対をまず心がけることだ。リクエストがグループ化可能なレベルになるように要件を定義して、出力するコンテンツの更新頻度をなるべく単純なグループに分類可能に保ち、それから副作用に慎重になる。RESTfulなサービスにする意味はリクエストのグループ化に貢献することにある。更新頻度の単純化と副作用を最小限にすることはキャッシュ戦略を容易にしてくれる。アルゴリズムやプログラミング手法で高速化することも非常に重要であり、キャッシュは万能ではないが、ウェブサイトを100倍速くしたいなら、まずはこんなところから手をつけてみるといいのではないかと思われる。

当然ながら、RAMが128MBでCPUがCeleronの500MHzというサーバで1秒間に100もの動的コンテンツへのリクエストを受けるといった無謀な環境で大冒険している人は、こんなことを検討する必要はこれっぽっちもない。手元の中古のデスクトップを抱えてデータセンタに駆けつけてケーブルを引っこ抜いて差し替えて、全部のリクエストに「ごめんね」と返すだけの設定が完了したら、あとはなるべく遠くまで逃げることだ。追いかけてくる連中も、そんなに賢いことはあり得ないので、深刻に気に病むこともない。

DON’T PANIC

コンピュータのトラブルシューティングに適した性格とそうでない性格がある。まあ、態度というか姿勢といってもいいが、どちらも性格から出てくるものだから、ここではまとめて性格と呼ぶことにする。

仕事でいつも対応しているのはウェブアプリケーションのトラブルだから、ここではその話に限定する。プリンタが動かないとか、マシンが重くなったとか、そういった問題は全部再インストールすればなんとかなることだから何もかも忘れてリストアして遠くの店に昼飯でも食べに行けばいいと思う。

ウェブアプリケーションのトラブルといってもいろいろある。これまで実際に直接または間接的に経験したものでも、アプリケーションのレベルの単なる不具合から、日頃のケアを怠ったせいで累積した問題が(比喩的にいえば)爆発してサービスが提供できない状態になっていたり、はたまたデータセンタが文字通り火事になっていたり、とにかくトラブルの原因も現象も千差万別だ。

そんな日常の中で、唯一といっていいほど必ず効果的なトラブルシューティングの手法があって、この逆をやると間違いなく二次災害や余計な手間になったり、運が良くてもその場の人間をみんなうんざりさせたりするのだが、それは

パニくるな

という黄金律で、とにかくこれが出来ない人間は絶対にトラブルが発生した現場に居てはいけないし、対応するなどもっての他だ。パニックを起こす理由はいろいろある。その人が全財産を投資して構築したシステムが目の前で崩壊しているのかもしれないし、単純に持っているスキルでは何をしていいのか見当もつかないのでひたすら慌ててしまっているのかもしれない。たいした能力もなく気が小さいくせに日頃から威勢のいいことを言いふらしておのれの実力以上に自己宣伝しているので急に本番がやって来て追いつめられたのかもしれない。だが、理由はともかく、パニックを起こしても問題解決にはいっさい何も寄与しない。

それから、自分がパニックしているかどうかを自分だけで知る方法は、自分の足を引っ張って空を飛ぶのと同じ要領で、つまり存在しない。だから、トラブルが発生したときに「ちょっと黙っててもらえますか?」「うるさい」などの言葉を投げつけられたり、トラブル対応中の人に何か質問しても無視されたら、これは自分がパニックしている証拠だと考えなければいけない。もちろん、そんなことを考えられるくらい冷静なら、そもそも文句などいわれないしパニックなど起こしてはいないので、結局は何の意味もないのだけれど。

ジーン・ウルフの短編によれば、未来世界でも「はた迷惑な人」をなんとかする薬は発明されていないそうだ。さもありなん。

バッチ処理の集中管理

携帯端末向けサイトの管理者Aは悩んでいた。とある携帯キャリアの課金体系ときたらひどい仕様で、入会日から一か月後に入会状態の継続が確定するのだが、他のキャリアのように月初に〆日があるのと違って、特に月末になるといったいいつ継続確定すればいいのかまったくもって判断がつかない。2月28日の翌月って3月28日なのか?翌々月は?1月31日の翌月は?直感で解決できない仕様は悪い仕様である。開発者の悩みは尽きない。

しかし、管理者Aの悩んでいるのは、そんなことではなかった。仕様書を読めばわかる問題なら、散文には慣れている文学部出身のAにはたやすいことだ。過ちを恐れるあまり舌が凍りついたような文面に、ご丁寧にもコピープロテクトまでかかった小癪な仕様書も、彼の読解能力の前には交通安全の標語とさして違いはない。数日の内に、バッチ処理は仕様通りに動作するよう完璧に設計され、実装され、凄まじいテストにも完璧に耐え、crontabの美学に完璧にのっとってスケジューリングされた。開発チームは祝杯をあげ、バッチ処理はもう半年間ずっと問題なく動いている。

だが、問題は起こった。ある朝、彼の携帯電話がけたたましい音を鳴らして気だるい春の空気を切り裂いた。サーバから直接送信されるアラートだ。件名を見ただけで、彼の眠気は吹き飛んだ。完璧な上にも完璧な例のバッチ処理が動作していないのだ。ユーザ情報の集計処理は来るはずのデータを待ちながら悲鳴を上げている。そんな馬鹿な!完璧なことピンポン玉のごときあのバッチ処理が失敗するなんて!

会社のサーバに繋がる秘密の端末からキーを叩く彼は驚愕した。完璧なバッチは完璧なまでに詳細な実行ログを残すことになっている。しかし、ログは一切残っていない!どういうことだ!crontabは変更されていない。プログラムに手を加えられた形跡もない。

ふと、管理者Aは/var/log/cronを覗いてみたい誘惑に駆られた。そして、恐る恐るコマンドを叩き、犬にしか聞こえない周波数帯で悲鳴を上げた。

$ sudo grep "perfectBatch.sh" /var/log/cron | grep $USER \
awk '{print $1 " " $2 " " $3 " " substr($8, 2)}'
password:
.............
Mar 22 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 23 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 24 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 26 04:00:00 /usr/local/bin/perfectBatch.sh
............

ない!ない!25日がない!

完璧なバッチは、完璧に作られ、完璧に設定されている。しかし、まさかcronに無視されるとは誰も思っていなかった。死すべき定めの人間の現実は、そんな思いを平気で踏みにじるのか。管理者Aは、ふと故郷の景色を思い出した。

と。

まあ、そんなわけで、割と負荷の高いサーバを運用した経験のある人なら、cronが実行されなかったのであわてたことがある人も結構いると思う。かくいう筆者も同じで、原因を調査してもこれといって手がかりもなく困り果てていた。1台や2台のサーバならなんとか確認して運用することもできるが、100台にもなるとそうはいかない。

そこで、cronはそもそもちゃんと動かないという前提で、確認の手間を省くことでなんとかならないかと考えることにした。思いついた方法は2つで、

(1) サーバ内に問題検知エージェントが稼働している
(2) 全てのバッチ処理は完了通知をリモートサーバに投げる

1の場合、エージェントの稼働を監視する方法がないので、結局同じことになる。2の場合、どこかに集中管理用サーバを用意して、いつどのサーバからどんな通知がこないといけないかをデータとして保持したアプリケーションが通知を受け付け、問題を検知する。この場合、集中管理サーバだけ確認しておけばいいので運用は簡単だ。バッチ処理の側に終了通知を投げる機能の追加が必要だが、これから作るものに適用していって、うまくいくようなら全部のマシンのバッチ処理に適用すればいい。

そんなわけで、バッチ処理の集中管理システムというものを作ってみたくなったのだが、そもそもこの手の問題にはみんなどうやって対応しているのだろうか。もっといい知恵があれば知りたいし、そんなのとっくにあるよという方がいれば教えてほしい。キモは、cronが無視するタスクの検知だ。

CRUDかCpRUpDか

小さな疑問。

もともとはデータベースの処理を意味するのだが、最近ではウェブアプリケーションの新規登録、閲覧、更新、削除フローの呼び名としても知られるCRUDという言葉があって、データモデルを指定するとアプリケーションを自動生成してくれるフレームワークもあちこちにあるのだが。

普通、新規登録とか更新のときって、いきなりデータを保存しないでプレビュー画面を出すはずだ。でも、自動生成されたCRUDアプリケーションにプレビュー画面機能はたいていなかったりする。

これが不思議で仕方がない。新規登録や更新用フォームがWYSIWYGエディタあればわからないでもないのだが。

そういえば、RESTとCRUDのミスマッチとかいう記事があったが、RESTにしてもプレビューはどこにも定義されていないはずだ。PUTとかDELETEの結果を前もって確認して、最後に決定したいというようなやりとりは基本的にはクエリ的なアクションになるのだが、どちらかといえばトランザクションといえるかもしれない。だったら、CRUDの範囲にはおさまらないだろうし、そのへんはいったいどうなってるのか。

マイクロマネジメントの定義

以前のエントリ「恫喝的マネジメント」の中で触れていたマイクロマネジメントがWikipediaにエントリがある言葉だと知った。当時はマネジメントについてこれまで経験したことはどうも間違っているのかもしれないと思い始めて、あれこれ勉強するようになった頃だから、それにしては内容は外していないと自画自賛したい。他に褒めてくれる人がいるわけではないし。

ただ、Wikipediaのエントリには触れられていないが、会社規模でマイクロマネジメントがまかり通っているケースもあり、マイクロマネジメント絡みの問題は決して管理者個人の資質の問題ではない。もっとも、その場合でも、単純に会社全体が軍隊的な制度で運営されているだけとは限らない。なんというか、管理の性格は複数の管理手法のネットワークで全体が形成されているものであって、個々のノードの性格が全体の反映であることはあっても決してそれがすべてではない。余計わかりにくいな。

いわゆる大量雇用を続ける企業にはマイクロマネジメントがまかり通っているケースが多い気がする。退職率が50%の一部上場企業、なんて実は探せば結構あるわけだが、そんな企業ではよほどのことがない限り誰もが最低限の選抜基準をクリアして採用され、そして徹底的に鍛えられて、半数以上が途中で力尽きて辞めている。鍛えるといっても業務スキルとかじゃなく、どちらかといえば精神破壊に近いことが行われる。教育の総仕上げに声が嗄れるまで公衆の面前で社是を絶叫させられたりする(「社員同士のぉ!思いやりをもってぇ!コミュニケーションをぉ!」とかいうシュールなセリフもあったりする)。

以前は、こういう環境に身を置いたことがないので、なぜこんなことがまかり通っているのか不思議に思っていた。だって、ちゃんとした採用プロセスで有能な人間を集めていくより明らかに無駄の多いプロセスにみえるし。

採用の敷居が低く、そしてマイクロマネジメントが唯一の教育である企業というのは、ようするに軍隊と同じような性質をもっている。採用は徴兵であり、徴兵は適任者を探すプロセスではなく頭数を揃える作業だ。創意工夫でのし上がっていく少数の変態を除いた他の連中の扱いは軍隊の伝統にもとづき「勤勉で有能なやつは司令官に、怠惰で有能ややつは現場の指揮官に、怠惰で無能なやつは前線の兵士にすればいい。ただし勤勉で無能なやつは射殺しろ」でなんとかなる。人間は資源であり資源に重要なのは必要なときに揃っていること、と割り切れば、軍隊が精巧な採用プロセスや思いやりのある人事考課を進めても効率が悪くなるだけだ。

軍隊という長い歴史を持つ組織のマネジメント手法が通用する企業があるのも別に不思議なことではない。社員の発揮するべき技能がコモディティと化してしまっていて(挨拶をきちんとする、遅刻しない、接客マニュアルに従う…)、数は必要だが交換可能な存在でしかない集団を率いる場合、このマネジメントは強力だ。

とはいえ、人間というのは間抜けなことをしても総体としてはさほど馬鹿なわけではないので、会社全体がマイクロマネジメントの花火が飛び散る状態であれば、単純に金銭的目標を達成すれば辞めてしまうくらいの分別はある。でも、上で書いたように会社のマネジメントは一枚岩的なものではなくて、複数の管理手法が絡み合って全体をなすようなところもあり、たとえば週末にバーベキューに出かけたり部署やチームのレベルで仲間意識を強めてガス抜きが行われたり、自分が叩かれたら立場上もっと弱い人を叩いて憂さ晴らししたりして、マイクロマネジメントが横行する職場環境でさまざまな調整弁が活躍していることがある。そうなると、軍隊的管理はさらに生き延びやすくなる。

さて、延々と書きながら特に結論は用意していないのだが、以前「恫喝的マネジメント」というエントリを書いたとき、ここで管理されている人の仕事はコモディティと化したようなものではないという前提で論を進めていた。まあ、自分自身のことなわけだが、これは実は今でも変わっていない。もし、ソフトウェア開発会社に勤務するプログラマで、自分はひどい労働環境にいると感じているなら、仕事で企業に提供している技能がコモディティ化してしまった陳腐な手技でしかないのかどうか検討し、そうでなければ「お前なんか雇ってくれる企業なんかいねえよ」などという脅しに負けずに転職するか起業する他に手段はない。マイクロマネジメントは病気であり、おのれを振り返って状況を改めるようなゆとりを管理者自身にさえ許さないものだからだ。

取引先の悪口をいわないこと

むかつくクライアントやどーしよーもないベンダにうんざりしている人は大勢いると思うのだが、社内メールでうっかり悪口を書いてしまって、それが当のクライアントやベンダに誤って送信されてしまうケースは結構あると思う。というか、結構そういうのを受け取ることがある。それだけ悪口をいわれているのだという事実が問題なのかもしれないが、ソフトウェア開発で不具合や問題が起きるのはある程度は仕方がない(300億円で発注してくれたら対策します)。

ついさっき、こんなメールを受け取ったので、さっそく「重要」タグをつけて保存した。

○○さん

こちら了解です。いちおう××(うちの会社の略称らしい)にもいっときましょう。知ってるとは思うけど、やつらたまにポカするんで…

明らかに社内メールの誤配信である。月曜日には不思議な魔力を備わっているようで、どこから突っ込んでいいのかわからないシュールなメールに朝からドキドキだ。だって、こっちがポカするって内容のメールがまさにそのポカとやらでこちらに送られてるんだもの。

この手のミスは社内文化としてクライアントやベンダの悪口をいわないというルールで対応する他はどうしようもないと思う。メールなんて送ってしまえばたいていもうどうしようもないし、宛先は間違えやすいものなのだ。関連ソリューションもないわけではないが、そこにお金をかけてもあまり意味はない。もちろん、機密情報が漏れてしまうことについて懸念するのは大事だが、それだって取引先との関係次第でなんとかなるのが大人の社会ってものだ。だから、社内メールだからといって安易に誰かの悪口を書くのは下品だし社内文化としてとがめられてしかるべきという社風を日頃から作っていくのが健全な対応方法だと思う。ミスしても相手側の好感度が上がるなら儲けもの。ビジネスからなれあいを取り去ったら、残るのはつまらない人生だけだ。

もちろん、先のメールにはあえて反応せず、続きがどうなるのか手ぐすね引いて待っている。今のところ先方の誰からも返信はない。もう気づかれてしまったのだろうか。悪口が書かれていなければ、担当の誰かにこっそり電話して誤配信について教えてあげていたのにね。

スカウティングメールに返信した

エクストリーム・ヘッドハンターズ株式会社*1 ○○様

はじめまして。八木と申します。LinkedInからのアクセスでしょうか。

ご紹介いただいております案件ですが、正直なところを申し上げれば残念ながら特に技術的な興味を引く内容ではありませんでした。申し訳ございません。

それだけでは何なので、僭越ながら、私が職業について個人的に重視する項目についてざっとご説明申し上げたいと思います。お忙しい中、大変恐縮ではございますが、ご関心があればお読み頂ければ幸いです。*2

■作業環境

開発の効率化をお題目に挙げている開発会社はいくらでもありますが、実際に効力のある手段を実現しているところはそう多くはありません。n個の「K」で始まる問題を抱える職業なりに、多くの企業がこの点を問題として会議の議題にしていることは間違いありません。

しかし、実際には、この問題の答えは非常に明確かつ単純であり、やる気になればそう難しいことではありません。

それが無料の食事や飲料の提供ではないこともいうまでもありません。

私が考えるもっとも効果的な生産効率向上手段は、静かなオフィスです。冗談のように思われるかもしれませんが、これまで経験した中でこれ以上に効果的な手段はありませんでした。もちろん、手旗信号の方がまだましなひどいネットワーク環境や停電続きの建物などは論外ですが、営業の電話がひっきりなしに鳴り続け、コーディング中のプログラマが管理者たちのこれ見よがしな自慢話にイヤホンで抵抗するような作業環境では、どんなプログラミング言語もツールも役に立ちません。

さらに驚くべきことに、ソフトウェア開発の現場について上のようなことが指摘されたのはかれこれ20年以上も前のことです。

しかし、現実には、何人もの管理者が寄り集まって(私も時折その中の一人であるわけですが)、開発ツールをEclipseにするべきか、言語をJavaにするべきか、などなど愚にもつかない議論を繰り返すばかりで、プログラマはせめてオフィスが静かになる夜にようやく落ち着いて作業に取りかかっているといった具合の開発会社は枚挙に暇がありません。

私が転職するとすれば、そこが静かで集中できる職場であることが必須条件です。

■組織

日常生活においては人間同士のつながり、付き合いは引き起こされるストレスと密接な関係にあり、非常に重要なものですが、キャリアとしての仕事を考えれば、やはり企業は人よりもまず組織が重要です。

社内である程度の技術力を発揮して認められたプログラマが、よき友人たちに囲まれて、給与も上がり(残業代はなくなり)、そしてひどい作業環境で悪戦苦闘する哀れな若いプログラマたちの管理を任され、そんな状況なので不具合は浜の真砂の如く尽きることはなく、メールの返信の手を休めることなく障害報告書をクライアントに送り続けるようになるだけのキャリアパスしか用意されていない企業で失われた若さを嘆くのも人生ですが、ソフトウェア開発者の未来としてみればそれが魅力的な人生であるかどうかは意見の分かれるところです。

ある職が用意されているとして、それはキャリアにどのような意味を持つものなのか、組織がどのようにそれを定義しているのかが重要なことだと私は思っています。

■その他

さて、上段に構えてえらそうなことを書き連ねましたが、ウェブ開発におけるキャリアとして面白そうな職場があれば興味があるのは確かです。面白い仕事があれば是非お話をお伺いすることができればと思います。

では、よい週末を。

*1 もちろん、実在の会社名ではない。

*2 もちろん、実際にこの内容で返事を書いたが、その後の返信はなかった。

おもてなしとしての公衆無線LAN

Twitter経由

会議室では来客用に公衆無線LANを用意しておくのが常識! になってほしいとお前ら思いませんか

確かにその通りである。家なら、ブルース・シュナイアーも語るように、おもてなしの一種として無線LANくらい提供するのも不思議なことではない。

でも、会社で来客に無線LANを提供するのは、プライバシーマークやISMSとの絡みで出来ない企業も多いはずだ。

事業規模の大きな会社では、こういった類の認定は部署ごとに取得していて、そうでないと不便で非効率極まりない業務フローになってしまうのだが、小さな会社の場合は全社的に取得してしまって融通が利かないところも多いのではないかと思う。

ただ、それはさすが「支配者にとっては植民地がこうだったらいいよね」という規格であるISMSの定めるところなだけあって、利便性などあまり考慮されていない単なるルールだ。物事を便利にするのがテクノロジーの存在理由であるわけだから、方向性としては著しく間違っている。

もっとも、こういう不便さにつけこんだ商品でもって変なルールに風穴をあけるのがIT産業ってものなので、たとえばISMS対応の企業向け公衆無線LANという道はある。誰か時間と金のある人はなんとかしてくれたまえ。銭の前ではみんな平等という、資本主義ほど革命に向いている考え方は他にちょっとないので、これは商売でもってISMSという現代の経済奴隷制度を解放する真の資本主義者になるだけの簡単なお仕事です。