「俺が若い頃は」の危険

以前、家庭教師の勧誘をしていたことがあります。その時に「俺が若い頃は」の危険を実感しました。

私がやっていたのは学生に声をかけて家庭教師に登録してもらうというバイトです。自分の在学していた学校に言って適当に声をかけます。キャンパス内でやっていいのかどうか微妙なところはあると思いますが当時はあまり疑問に思いませんでした。その仕事が専業というわけではなく、家庭教師の事務スタッフとしてのバイトの一環でした。

バイトは採用後しばらくの期間を経た後に外に出されます。ここでまず学生を家庭教師に登録させるべく勧誘を行ないます。いかに多くの学生を誘ってくるかで優劣がつきます。そして優秀なバイトから実際の家庭、中学生や高校生のいる家庭に派遣されて親を相手に商売をします。

この教師勧誘は思ったよりも難しいものでした。まずスーツで声をかけると「ああ、この人かわいそうに」と汚物を見るような目で見られます。あやしげな宗教だってバカ高い教材を売りつける英会話だって最近ではスーツで勧誘しません。それでも私服で勧誘するとせっかくネームバリューのある家庭教師事務所なのに信頼してもらえないかもしれません。スーツで押し通すことにしました。

スーツで話しかけても逃げない人は第一関門を突破です。考えたら第一関門なんて甘っちょろいものでした。第二関門の家庭教師事務署名です。「こんにちわ。○○○○です。（文字数は必ずしも関係ありません）」というとほぼ完全に逃げられます。丸一日勧誘しても2,30人しか捕まらない、そんな状態でした。声をかけたのはその50倍くらいだったのではないかと思います。

それで事務所に帰るとタイトルの声をかけられます。相手もバイトです。バイト歴2年くらいの先輩です。「俺がこのバイト始めた時は200人を超えたことがあった」とのこと。そうやってめちゃくちゃやったから逃げられるんだな、と妙に納得しました。なお勧誘しながら事情を知る人に教えてもらったところでは、勧誘した相手に個人的に携帯電話に連絡を取るなどして異性関係のトラブルを起こしたり、芸術関係の学科の学生に国立大志望の高校生の指導を行なわせて教師・家庭の双方からの激しいクレームを引き起こしたりということがあったそうです。そういえば入学して間もなくそういう噂を聞いたな、と思い出しました。

ついでに回想するとその後なぜか「異例の早さ」とかで家庭に派遣されました。なんとかがんばってマッチングしたり相談に載ったりしましたが1か月くらいで限界を感じてやめました。別に高い教科書を売りつけたりというのはせずにピンはねだけで生きている業者だったのですが、そのピンはねがすごいのと、事務所も教師も無責任すぎるところが精神的につらかったからです。高いピンはねするならスタンバイの教師を1人くらい置いておけばいいのですが、定期テストの直前に先生が辞めて試験対策が全然できないなどのトラブルが少なくありませんでした。先生が1人責任を放棄したら何もカバーする仕組がありませんでした。その先生が逃亡した件では担当の営業という責任から自分で先生をしにいったのですが「できればこのまま先生をしてくれ」と頼み込まれて緊張の糸が切れました。営業バイトとして登録はしていましたが、家庭教師の経験も研修も何もしていない自分が「先生をしてくれ」と頼まれるとは普段どんな教師を派遣しとるんじゃい、と。仮にも営業マンというカテゴリの仕事をしているのに自分が売っている商品を知らない、それだけでなく商品が信頼できなくなってきた、その事実を前にバイトを辞めることを決意しました。時給としては随分良い仕事でしたし、仕事の勉強をするにはもってこいの環境でしたがやってらんねぇという気分でした。なおこのことをけんじろうさんに相談したら「まじめだねー」と笑われてしまいました。確かに今だったらエンジン出力70％くらいでゆるゆると流すかもしれません。

ものすごい前置きが長くなりましたが、システム開発の現場でも「俺が若い頃は」の危険が転がっていると思います。

HOST全盛の時代に設定された「リリース時には障害率を何キロステップあたり何件にとどめること」という指標だけが一人歩きしてクラサバやweb系のシステムにまで根拠のない数字管理を徹底している現場がないでしょうか。要員1人あたりであるとか、予算100万円あたり、1画面あたり、などの指標は開発の記録を大量に集めて分析をするには効果的なことがありますが、契約書を取り交わして開発金額が確定したところで「このプロジェクトは障害3件いないか。厳しいな。」と思うことが精神論以外のところで障害を抑制してくれるとは思えません。

確かに「ITはドッグイヤーだ」という言葉で「障害は起きても仕方ない」ということを主張するのは後ろ向きであり建設的ではありません。しかし何年も見直しの無いまま「障害率を前年比10%減にする」などの目標が続けられることも果たして意味があるのかどうか疑問があります。

また、技術的に高度なものを扱うようになったために障害が発生しやすくなっていることもありますが、お客様の業務がシステムに強く依存することで「障害」とみなされる範囲も大きくなっているように思います。処理を投げてから帰ってくるのに数分かかるようなシステムでは、画面が10秒固まったといって騒がれる事はないでしょう。今ではITmediaのトップページにアクセスして10秒レスポンスが無かったら不安に感じる人が多いのではないでしょうか。

加えて、一人当たりの生産性の追及という点でも障害が発生しやすい環境が広まりつつあります。テストの自動化、E-RモデルからのDBオブジェクトの自動生成、モデルからのコードスケルトン出力など、技術者1人が担当するコードの量はどんどん増えてきています。また、個人が責任を負えないようなフレームワーク側のバグやOSのバグなどもありますし、リリース後のセキュリティパッチの適用なども障害の源泉となります。端末に入っているツールとの競合もあります。

重ねて言いますが「だから昔より障害が多くなっても仕方ない」ということを口に出してはいけません。口に出していいのは「俺が若い頃は」の基準からの脱却と、現状の正しい把握、そして代替案でしょう。

不況に伴うコスト削減により仮想化技術の採用が進んでいるといいます。仮想基盤が枯れてくるまでは「あるゲストの障害に巻き込まれて落ちない『はず』の別のゲストが落ちた」などの悲惨な事象が発生することでしょう。現在のこういった環境を見渡せば、障害発生率の全社的な基準などというのは何をもってすれば客観的な指標を設定できるのだろうか、と悩んでしまいます。