最近我々は、 CapGeminiの Steve Jones氏(SOA思想家)が彼のブログで、いかにITが考えよりも技術に価値を置いているか、を述べた記事を伝えた。それがこのInfoQと氏のブログで多くの議論を呼んだ。そのコメントは、概ね彼に心から賛同するものと、しない読者に二分したようであった。しかし、幾つかのコメントには、この問題はしばしば、技術やクライアントに話されたことは、正しい、というクライアントの信条よりも、ITにいる人々のスキルと質によって済ませる、という共通の信条がある。コメントの１つがこのことを要約している。
このマーケットの状況は、現代の（無知な）消費者が彼の車を修理工場に入れる時のような状況とかなり似ています。済んだ仕事が高品質か、あるいは、必要なのかさえも知るのは、簡単ではありません。人々は、多くの明白な詐欺が修理工場で起きていることを広く受け入れています。しかし、何らかの理由で、ソフトウェア開発プロジェクトでは、何十億ドルもかかってしまうことはない、と思い込んでいるようです。
氏は、彼の 最近のブログ投稿で、このトピックに関して、どのようにしてハッタリ屋を見抜くかを尋ねている。
ここで私が意味するのは、彼らはクズなので、自分がこけ脅しだ、とは本当に考えていない人々、あるいは、あなた方がクズだと考えているのでハッタリをかます人達です。それはTerry Pratchett Architects (PArchitects?) の挑戦に関係しています。これは、知識によって技術をけなす人と無知によってけなす人をどう見分けるかを言っています。
氏は、「インタビューしたIT関係のシニアの内、95％はハッタリ屋の見分け方を充分理解していない」（恐らくこの業界での彼の経験に基づいている。記事中にはこの数字を証明するデータがないからである）。そしてこれらの経験を基に、氏が信じているのは、彼が定期的に出くわす上級の人々は、単に「流行りの知識のレベル」に基づいて現在の役割を担っている。なので、彼が以前に概略したような一般的な問題に寄与するような本当のスキルや知識は持っていない。このような状況を改善する助けをしようとする取り組んでいる時に、氏は、インタビュー中にこれらのハッタリ屋を見分ける幾つかの助言を思いついた（そのような人間を雇ったかどうかみるのは、読者の演習とする）。
- 1. フェーズ１の技術、フェーズ２の人事インタビュープロセスそれをしないこと。ファーズ１の中で中間フェーズを追加する。
- 2. フェーズをで以下のことを尋ねる。
- 製品向けに最後にコーディングしたのは、いつか？どの言語で、どのプラットフォームで行ったか？
- 最後に概念的、論理的データモデルを作ったのはいつですか？どのプラットフォームですか？
- 文字列処理でRegex, Regular Expressions 、Perlの違いは、何ですか？
ITアーキテクトは、余りの現実から離れてしまって、自分が設計を助けたり、影響を及ぼしたプラットフォームがどのように動いているかを知らない、ということは許されない、と信じているのは彼だけではない。更に、アーキテクトは少なくとも、最後に携わったプラットフォームがどのように動いているかを覚えているだけでは、不足だと信じている。これが質問2.1と2.2の理由である。質問2.3は、全く彼の個人的経験から生まれたものだ。
[...] 最後の質問は、かつて私を非常に愕然とさせたものである。それは、私がインタビューしている人が「私は、 Regexをやった」と言い続け、その後で、「そのプロジェクトで Regular Expressionsを我々は使った」と言ったのです。私は彼に２つの違いを聞きました。彼は、Regexは言語で、 Regular Expressionsは、別の言語だ、と答えました。ここでのポイントは、この人は、言語やプラットフォームについてある程度の専門性を持っている、と言った、ということです。
氏の複数フェーズアプローチのポイントは、第一フェーズでハッタリ屋が知識があるかを見極め、第一フェーズの第2部で、そのイカサマを剥ぎ取ることである。我々はこれまでの幾つかの記事で、何が良いアーキテクトを生み出しかについて述べてきたし、アーキテクトや開発リードの役割は、明らかにプロジェクトの成否に極めて重大である、といってきた。ごく最近、The Pragmatic Architectと題する、IEEEの記事（再発行されている）も助けとなるだろう。しかし、氏の目的に戻れば、インタビュー中にこの複数フェーズを使えば、ハッタリ屋を見分ける助けになる。これを上手く行かせるには、ちゃんとしたインタビューチーム、時には各フェーズで違うチームが必要である。
第二部のインタビューには、本当に洞察力のある開発者を入れるべきで、彼らに本当に意味のある開発者向けの質問を指せるべきです。「この人が言語Xの3流プログラマーであること」を期待するのではなく、「聡明ではないにしても、自分の仕事に関連することを総じて知っているようだ」ということを確認します。避けなければいけないことは、「こいつは、これまでXを使ったことがある、とは思えない」などのような意見です。
ここでのポイントは、ハッタリ屋がどこに深い技術を持っている、と言っているのかを見出す最初の段階と次に、もし矛盾点があればそれを暴き出す第二段階が必要なことである。もちろん、氏の当初の焦点は、アーキテクトであったが、かれは、ハッタリの負荷を全部アーキテクトに負わせたいと思っていない。
同様なアプローチ、しかしもっと抽象的なアプローチがPMやBAに対して使われるべきです。すなわち同じような技術的なプロジェクトをやってきたPMやBAに対して質問をする時に使われるべきです。私は、「機能」SAP BAに会い、その人達を本当の機能専門家に紹介したら、その領域で散々でした。「使ったことがある」、と言っていたSAPモジュールの頭字語すら知らないことがありました（「供給者管理をやってました。SAPでそれを何ていいましたっけ」）。私はこのような人達に会って愕然としたことが何度もあります。
もし氏の原点に戻るなら、IT関連の人々は、考えることを望んでおらず、これがハッタリ屋が繁盛するのに理想的な状況なのだ、と彼は信じている。彼の元々の論点に関して、多くの評者が指摘しているように、このような状況に取り組むのを助けるために、我々の業界には幾つもの変化が起きる必要があるが、恐らくそれが全てインタビューの段階で始まるのだろうか？ 氏がほのめかしているように、もしITが自分は理解していると主張するテーマを本当に知っている人達を雇うならば、恐らく技術よりも考える人に感謝することに回帰するだろう。しかし、これは非常に明らかなソリューションように聞こえるので、IT会社やグループが本当にJohns氏が信じるほど、ハッタリ屋に馬鹿にされているのだろうか？