「WACATE 2012 冬」参加レポート（その4）――エンジニアリングとブリコラージュの二人三脚
こんにちは、第3バイオリンです。
「WACATE 2012 冬」参加レポートも今回が最終回です。今回は、2日目のクロージングセッションの様子と、今回得た気づきについてお届けしたいと思います。
■クロージングセッション「CFD++ 〜デバッグ工学の夢〜」
デバッグ工学研究所の松尾谷 徹さんのセッションです。
松尾谷さんは、まずソフトウェア工学の発展の歴史について説明を始めました。ソフトウェア工学の始まりは、1968年、NATO（北大西洋条約機構）主催の国際会議です。当時は冷戦のまっただ中、アメリカはいち早くソフトウェアを軍事に取り入れていました。しかし、当時はまだコンピュータ黎明期ということもあり、ソフトウェア開発はトラブルの連続でした。トラブルの尻拭いをするためには莫大なお金がかかります。しかもそのお金の出どころはNATO加盟国の税金です。さすがに税金を湯水のごとく使うわけにはいかないので、ソフトウェアを工学で管理しよう、という話となったわけです。
というわけで、複雑で難しいことを実現するために科学的、工学的なアプローチをすることになりましたが、そこには思わぬ欠点がありました。複雑で精巧なものは、少しでもミスがあるとまともに動かないどころか、下手をすると害をおよぼすことになりうるという一面があります。そうなると、誰でもタッチできるようになるのは危険ということで、専門性を高めて素人が簡単にいじることができないようにする必要が出てきます。
ここで松尾谷さんは「ソフトウェア工学とは、本当に『工学（エンジニアリング）』なのでしょうか」という質問を投げかけました。
松尾谷さんは、エンジニアリングの対義語として「ブリコラージュ」という言葉を挙げました。ブリコラージュとは、「その場で手に入れられるものを寄せ集めて新しいものを作る」という意味の言葉です。エンジニアリングとは「理論や設計からものを作る」ことですから、まさに対極にある言葉です。ブリコラージュを行う人を「ブリコルール」といいます。例えば職人（すでにある材料や道具からものを作る）や、シャーマン（すでにある事実や価値観から過去や未来の物語を作る）もブリコルールにあたります。
ここまで説明したところで、松尾谷さんは「情報システムを組み立てる技術者はエンジニアではなくブリコルールです。そういう意味では、今日のソフトウェア工学は厳密なエンジニアリングではなく、エンジニアリングとブリコラージュが混ざり合ったもの、と言えます」と語りました。
その根拠として、プログラミングの習得過程を例にしてみます。プログラミングの習得が早い人は、たいてい「考えるよりも実際に手を動かしてプログラムを書き、実行して失敗したらすぐ修正する」を繰り返している人だと思います。「すぐ実践し、すぐ失敗してその場で学ぶ」この過程はいかにも職人的、シャーマン的です。逆に、習得が遅い人は先に理屈を考えます。「まず理論を理解して、それから応用する」この過程は科学的といえます。そのため、ソフトウェアの世界はプログラミングとデバッグを繰り返すブリコルールが牽引しているともいえます。
それでは「ソフトウェアの世界ではブリコルール最強！」となるのかというと、そうとは限りません。ブリコルールにも弱点はあります。それは「ブリコルール同士は合意できない」ということです。例を挙げると、職人やシャーマンが身につけてきたスキルは個人の経験と感性にもとづくものです。そのため、職人同士、シャーマン同士はお互いのバックグラウンドが異なれば話が通じなくなります。これでは個人としてのスキルが高くても、大規模なチームになるととたんに上手くいかなくなります。
松尾谷さんは「ソフトウェアとうまく付き合うには、エンジニアリングだけでは解決できない問題があります。しかし、ブリコルールだけでもうまくいきません。ソフトウェアには表の世界と裏の世界があります。表とはコンピュータに意図したことを伝えるプログラミングの世界、裏とは意図したことが伝わっているかどうか確認し、リペアするデバッグの世界です。デバッグにエンジニアリングが必要なのです。それも、ブリコルールを排除するためではなく、助けるためのエンジニアリングです」と語りました。
その、デバッグにエンジニアリングを持ち込むための手段のひとつがCFD（原因流れ図）です。もともとCFDは、松尾谷さんが30年ほど前に、当時携わっていた汎用OS開発プロジェクトに取り入れるために考案したものです。
松尾谷さんは当初、プロジェクトに原因結果グラフを導入しました。それにより検査部隊の生産性は4倍アップしました。しかし、どうしてもそれ以上に良くなることはありませんでした。松尾谷さんは、その理由が原因結果グラフの本質にあると気がつきました。
原因結果グラフは、その名のとおりグラフで論理を考えるためのものです。また、原因結果グラフで扱う原因は2値（0か1か）です。プログラマはプログラミングをするとき、グラフではなく制御の流れで論理を考えます。また、プログラムの制御は必ずしも2値とは限りません。
先にも述べたとおり、ソフトウェアの世界はブリコルールの世界です。ブリコルールを助けるためには、彼らのやり方を無理やり変えたりしないような手法が必要です。そこで松尾谷さんが考案したのがCFDです。
CFDを使うことで、制御の流れを図示することができるようになり、2値に限らず多値の論理も扱えるようになりました。しかし、CFDはあくまで道具です。使い方には工夫が必要ですし、CFDさえ使えば万事OK、とはいきません。CFDはブリコラージュ的な手法です。誕生した後にも、いろいろと追加修正が入っており、今なお進化を続けているからです。
松尾谷さんは、今でもCFDについて論文を書き続けています。CFDが進化しつづけていることも理由のひとつですが、その他にも底上げ教育がなかなかうまくいかない、ということもあります。松尾谷さんは「すべてをテストでカバーするのは限界があります。最初からテストをしやすい設計が必要なのです。プログラマやテストエンジニアはもちろん、もう少し上の人にも頑張ってもらいたい。一緒に協力することで相手の成長を促して、お互いが伸びていけるようになればいい」と締めくくりました。
夜の分科会でもエンジニアリングと職人技の対比の話が出ましたが、まさにそれを言い当てられたような感じでした。職人になるには長い年月が必要ですし、誰もが優れた職人になれるとは限りません。また、職人には職人の苦労や悩みがあるはずです。職人ではないわたしは、職人をうらやんだり、変に張り合ったりするのでなく、職人の力をうまく引き出して、味方になってもらえるようなやり方を身につける必要があるのかも、と思いました。
■いつやるの？ 今でしょ！？
今回の参加レポートで何度か書いたことですが、わたしは今後のキャリアについてかなり迷っています。このコラムを書き始めたころは、テストの仕事がとにかく楽しく刺激的で、もっと勉強してもっとデキるテストエンジニアになって……と、将来が楽しみで楽しみで仕方ない状態でした。
ところが、ここ1年くらいでしょうか。その気持ちに少しずつ変化が起こってきました。
わたしの年代（30代前半）にはよくあることかもしれませんが、少し上の、30代後半から40代くらいの世代には、今まさに業界のトップを牽引するような人がたくさんいます。憧れを抱く一方、かなわないなあと思うわけです。
さらに、すぐ後から追いかけてくる20代後半の世代には、それと同年代だった頃のわたしよりもスキルが高く、情熱も人一倍な人がたくさんいます。テストの未来は明るいと思う一方、やはりかなわないなあと思うわけです。
そういう世代に挟まれていると、どうしても自分の限界を感じることがあります。このあたりで仕切り直しの時期にきているのだろうということは何となくわかりますが、一方で「ずっと『仕切り直し、仕切り直し』と言ってるうちに結局何もしないまま終わってしまうんじゃないだろうか」という不安もないわけではありません。
やっかいなことに、この手の問題は1日2日、考えたくらいで答えが出るものではありません。何ヶ月も、場合によっては何年も考える必要があります。すぐに答えが出ない、というのはなかなかしんどいものです。
このようなことを考えつつ、今回のWACATEで、テストエンジニアのキャリア、職人技とエンジニアリング、いろいろなお話を聞いて思ったことは、「今すぐ答えが出ないことを必要以上に悩んでも仕方ない」「しかし、今できることは今からやるべき」ということです。
将来のキャリアについては今すぐ答えが出ることではありません。また、自分よりもスキルが高く、精力的に活動している人と今すぐ同じようになることもできません。そういう人は、わたしが知らないところでたくさんの努力や経験を積み重ねてきたのです。すでに自分のキャリアを構築している人、具体的な目標を見つけて加速している人をうらやんでも仕方ないのです。
しかし、だからといって今何もしなくていい、というわけではありません。今始めないと、差は広がる一方です。1日目の清水さんのセッションでも少しお話がありましたが「今日から君がリーダーだ」と言われたとき、それまで何もやっていなかった人よりも、少しでも何かやっていた人のほうがうまく立ち回れるはずです（そもそも、前者の人はリーダーに任命されること自体ないかもしれません）。
とはいえ今できることもそれほど多くなかったりするのですが、何かできることを見つけて進んでいきたいと思います。
「WACATE 2012 冬」参加レポートは以上です。「WACATE 2012 冬」で出会ったすべての方に感謝いたします。また、ここまで読んでくださった読者の皆様にもお礼申し上げます。