|
皆さんは「SOA」と聞いて何の略かわかりますか？「Service Oriented Architectureじゃん」と言えるあなたは幸せだ。我々の周りでは，SOAは「スーパー・大ざっぱ・アーキテクチャ」と呼ばれている。ベンダー仲介でSIをやると要件がまとまらずに，SOAという単語だけが一人歩きしてプロジェクトが体をなさないことが多いからだ。
とまぁ，こんな感じでこの業界でも独特な用語が存在しているが，他の業界と異なるのは表と裏があること。表でまかり通っている良いイメージが現場で覆され，現場では裏の意味で流行っているのが現実だ。今回は，これまでに著者が現場で出会った，裏のギョーカイ用語を紹介しよう。
テストファーストの実体は
雑誌などでシステムテストの重要性が指摘されるようになってから，多数のテストサポート・ツールが登場してきた。それらの中には，スクリプトで処理を自動化したツールもあり，特に再帰テストで威力を発揮している。ただ，ツールよりも前に技法がブームになっていたことを覚えているだろうか？ その技法とは「テストファースト」だ。ご存じのように，コードを書く前にテストコードを書いておくのがこの技法の特徴だ。
テストブームの中，この言葉も現場で威力を持つようになった。特にベンダーのお偉いさんは，会社のイメージ向上の意味でも品質に影響を与えるキーワードには敏感なので，この技法を徹底するようになった。ただし，このテストコード。テスト・ケースを決めなければ，当然コードは書けないことは言うまでもない。どんなテストもその本質は仕様の確認になる。そのため仕様が決まらないとテストコードが書けないのは誰でもわかること。
ところが，この現実をベンダーのお偉いさんという雲上人は理解できない。私が聞いたある現場では，お客様ヒアリングはベンダーが行い，製造をソフトハウスが担当することになっていたのだが，手ごわいお客様だったのでなかなか言質を与えてくれなかったそうだ。案の定，スケジュールに遅延が始まった。そこでベンダーのプロジェクト・リーダーが上司に連絡に行ったところ，「テストファーストでやれば，製造とテストを一緒にできるんだから時間はかからないので遅れないだろう」と「？」な一言。よくよく聞いてみると，この上司はテストファーストを取り入れると“実装とテストを平行してできる”と勘違いしていたのだ。
初めてこの話を聞いたとき，どういう意味なのかわからなかった私に，リーダーはゆっくりと解説してくれた。まずは，いつも私達が思い描くＶ字プロセスを思い出してもらいたい。このプロセスでは製造の後にテストがある。
これは時系列的に当然なのだが，ここを勘違いしていたのだ。この上司は，テストファーストなので工程が終わると同時にその試験は終わっている，つまり，製造工程の終了＝システム構築の終了，と思い違いをしていたのだ。さらに悲劇的なのは，要件定義と設計にもテストファーストを取り入れていると勘違いしていたので，製造が終わればプロジェクト終了，ぐらいの感覚でスケジュールをとらえていたことだ。
もちろん，そんなことはありえない。ウォーターフォールをやっていた年輩の方でも，そこまで厳密な品質チェックを上流でやることなんて無かっただろう。ところが，この上司はこともなげに「いや，できる」と繰り返し，弁解を始めると「なぜできない！」となる。そんなこんなで遅延を認めてもらえなかった一連の顛末を聞いた我々は「テストファースト（Test First）ではなく，テストファスト（Test Fast）ですね」とプロジェクト・リーダーを慰めてやることしかできなかった。
そう言った後で，我ながら納得したのだが，ほとんどの炎上しているプロジェクトではテストファストなのが現実ではないだろうか？ 要件定義と設計が遅れ，製造は間に合わず，やっつけでテストを“さらっ”と済ませ，システムテストで品質がボロボロなのでリリースが遅延する。現場では，テストはファースト（先にテストコード書く）ではなく，ファスト（時間が無いので早く済ませる）傾向が高い。もちろん，品質が高い物をリリースしたいのならこれではいけない。ファーストとはいかなくても，きっちり時間を取るようにしたい。
SEとは？
SEには，実はヒエラルキーがある。それは，システム・エンジニアを頂点とした以下のようなものだ。
- システム・エンジニア
- 少しだけ・エンジニア
- 信じられない・エンジニア
- ○んでもらいたい・エンジニア
皆さんの周りでも，システム・エンジニアではないSEがいるでしょう？ 今回は信じられないエンジニアと○んでもらいたいエンジニアを紹介する。どちらも同じプロジェクトにいたのだ，悲劇的なことに…。
専用端末向けに特殊なキーボードを作ることになったプロジェクトで，弊社とベンダーの子会社で別々に機能を提供することとなった。ドライバの開発なので，機能の切り分けからそれぞれのインタフェースまで，きっちり決めてから開発を始めた。Windows向けのドライバだからWDMのアーキテクチャに従って，両方ともフィルタ・ドライバにした。キーボードの処理をトレースし，特殊キーが押された場合の処理を組み込むだけの，難易度の低いドライバだ。
ところが，しばらくして先方の開発が滞っていることが判明した。何もわからないベンダーの管理者は一蓮托生で我々をも攻めてくることが予想できたので，先方と一度打ち合わせを開いて対策を立てることになった。
先に触れたように，そのころMicrosoftはドライバ・アーキテクチャをWDMへ変更していた。しかし，信じられないことに，その子会社の社員は古いアーキテクチャで開発をして，「インストールできない」と悩んでいたのだ。いったい，この人は何をやってるんだろうと思ったのだが，悪いのは開発者ではなく，この人を監督している親会社のベンダー社員だった。
子会社の社員は初めての開発ということもあり，開発経験がある親会社の社員が監督していたのだが，この人がWDMになったことを理解せずに，古いコードを渡して「これでできるだろう」と丸投げ状態。まずはインストールして動かしてみようとするのが基本なのでそれをトライしたのだが，当然インストールはできない。そのことを監督者のベンダー社員に言うと，「何もわかってないくせに！」と怒られていたそうだ。これでは仕事が進まないので，何とかこの監督員の目を盗んでWDMアーキテクチャで開発を始めてもらった。
ここまで読んだ健全な皆さんは「コード・レビューをどう逃げるの？」と思ったでしょうが，ベンダー社員は基本的に丸投げなので心配する必要は無い。ここまでを「予想通り！」と思ったあなたは玄人でしょう。
しかし，そんな彼でも「信じられない・エンジニア」レベルだ。リリース後にもっとすごいのが現れた。詳細は省略するが，リリース後にバグが頻出し，お客様からの猛クレームを受けているときの話だ。
当然，バグの調査を行いお客様に説明しなくてはならない。このときに現れたのが「○んでもらいたい」ベンダー社員。先ほどの丸投げベンダー社員のさらに上の役職の方で，他人ごと感を丸出しにして打ち合わせに出席してきた。
なんといっても感動したのが，彼が出してきた調査レポート。メモ帳に申しわけ程度に7～8行，これまでの調査手法が書かれており，バグの原因は書かれていなかった。それだけでも相当なマヌケだが，さらに許せないのはそのメモの題名。「言い訳.txt」とメモの先頭に書かれていたのだ。“言い訳かい！”と思わず突っ込みたくなるのを必死にこらえた私にできたことは，ネタとして社内に展開して笑いを提供したことくらいだ。
風刺されないために
このようにIT業界でも，はやり言葉はある。ネタと言ってもいいだろう。結局，この手の話は風刺であり，いつの世でもあったことだ。現場のガス抜きにはちょうどいいだろう。
問題は自分が風刺されないようにするにはどうしたら良いかだ。日々の研鑽！と一言で片付けるのは簡単だが，製造よりもお客様対応に追われることが多いベンダーの方には難しいだろう。そうすると，謙虚になって揚げ足を取られる（風刺される）機会を減らすのが最大の防御でしょう。
『Diminished Democracy』（Theda Skocpol 著，Univ of Oklahoma Pr 発行）という本にも指摘されているように，現場から離れて地に足がついていない作業ばかりするエリートに，現場の方針と賞罰を決める特権を与えると，その組織のパフォーマンスは劣化するのだ。それがいやなら寝る時間を削って努力するしかないですね。
