アヒルちゃん人形でミスを見つける「ラバーダッキング」は日常業務でも使えるか?

プログラマーさん、ITエンジニアさんが行うコードデバッグの手法のひとつである、「ラバーダッキング法」をご存知でしょうか?

ラバーダッキング法、別名「ラバーダック・デバッグ」。

この「ラバーダック」というのは、お風呂などに浮かべて遊ぶ「ゴムのアヒル人形」のことです。なんでも、このアヒル人形の存在がとても大切な手法なのだとか。

例えばプログラマーが、自分の書いたコードのデバッグ(※)作業を行うとき。

モニター脇においたゴムのアヒル人形にコードの目的や内容を声に出して説明することで、本人が気づいていなかったコードの問題や改善点に気づくことができる……というのが、ラバーダッキング法の概要です。

※ コンピュータープログラムのミスや誤り(=バグ)を見つけ、取り除く作業のこと

えっ、あの難しそうなプログラムのコードを?アヒルちゃん人形に説明するだけでどうして?

「ラバーダッキング法」、なんだかとても気になってきました。

ゴムのアヒル人形があればチャレンジできる問題発見法、プログラマーでなくても普段の仕事に導入することはできるのでしょうか?

ラバーダッキングは、「説明できなくなる場所を見つける」手法

筆者と編集者

▲この記事の筆者(左)と編集者。Zoomでじっくり相談しながら、ラバーダッキングについて考えるのに付き合ってもらった

黒木

黒木

ラバーダッキング法、プログラマーやITエンジニアじゃない自分からしてみたら、「なにそれ、本当にあるやり方なの?」って感じなんですよね。
それなんですよね。 チャレンジにあたって実際にラバーダッキング法をやっている人に話を伺おうと思ったんですが、それがなかなか難しいようで。
伊藤

伊藤

登場人物紹介

伊藤

伊藤:企画の実践者で、この記事を書いている人。プログラミングの経験はないが、ラバーダッキング法を知ってから、アヒルちゃんに仕事を助けてもらいたい気持ちを我慢できないでいる

黒木

黒木:この記事の担当編集兼、伊藤の相談役。ラバーダッキング法のことは知らなかったが、仕事中の独り言は多い

伊藤

伊藤

心当たりのある方や身近なプログラマーさん何人かに相談したのですが、方法を実践して、かつ解説していただける方がなかなか見つからないんです。 「手法としては知っているが、しっかり説明するのは難しい」とのことで。
そうなると、「どなたかにレクチャーしてもらう」のはちょっと難しそうですね。
黒木

黒木

伊藤

伊藤

とはいえ、以前にSNSでラバーダッキングが話題になったこともありましたし、「デバッグ作業の際に良いとされている“いち手法”」であることは間違いないと思うんですよね。 実際にエンジニアさんとお話ししたときも、実践したことがなくても「確かに効果はあると思う」という印象を持つ方が多いようでした。
なるほど。 そもそも、どうしてアヒル人形に説明するのが問題解決の手段になるんでしょうかね?
黒木

黒木

伊藤

伊藤

そこなんです。 例えば、一節分のページを割いてラバーダッキング法を紹介している『プリンシプル・オブ・プログラミング』(上田勲著、秀和システム)では、その方法についてこう書いてありました。

プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明します。すると、問題の原因に自ずから気付き、自己解決できることがあります。

この場合の「誰か」は、バスタブに置いたゴムのアヒル(ラバーダック)のように、話を聞きながら定期的にうなずくだけで良いのです。何かを言う必要はありません。

(『プリンシプル・オブ・プログラミング』P.253 より)

伊藤

伊藤

そして、気になったのは直後のこの部分です。

他人に問題を説明するには、まずコードを通読し、その中に存在する暗黙の仮定を明確にしなければなりません。

〈中略〉

また、その過程において、間違ったコードに到達した時点で、「説明ができなくなる」あるいは「説明とコードが合わなくなる」ことに気づき、不具合箇所を発見できることもあります。

(同上)

黒木

黒木

ああ、なんとなくわかる気がします。 自分の考えを声に出して説明していると、「あれ、なんか言っていることおかしいぞ?」とふと我に返る瞬間、ありますよね。
まさにそれです。 この「説明ができなくなる」状況って、つまりは自分の論理の破綻に気づいた瞬間じゃないですか。 「コードを書く」という行為って、とてもシンプルに言うと「コンピューターへ、自分の意図に沿って動くよう指示を出す」ことですよね。 そして、プログラマーが出したかった指示と、実際に書いたコードの内容がズレていたら、それが「バグ」になる。 「説明する」ことで、この「コード本来の目的と、実際に書かれた内容のズレ」に気づける、ということなのかな、と。
伊藤

伊藤

無機物が相手のラバーダッキング、人が相手の壁打ち

黒木

黒木

説明することで自分の間違いに気づく、ということですね。 そう考えるとそう考えるととても身近な行為に思えてきました。
「説明すること」の効果としては、「自己説明」という名前ですでに研究も行われているようです。
伊藤

伊藤

黒木

黒木

自己説明?
認知科学や教育学の分野で使われる言葉で、「自分が学習したことを他人へ説明することで、学習の理解度をより高める」やり方で、説明を声に出すことで、副次的に「自分の対象への理解度が測れる」メリットもあると言われています。
伊藤

伊藤

黒木

黒木

説明で理解度を測るというのは、ラバーダッキングで「説明中に矛盾に気づく」瞬間と似てますね。
また、プログラマー向けの他の書籍『CODE COMPLETE 完全なプログラミングを目指して』(スティーブ・コマネル著、日経BP)では、ラバーダッキングに類似する方法として「告白デバッグ」が紹介されていました。これは一言でいうと、バグ発見のために「自分ではない誰か」にコードの意図を説明する、というものです。
伊藤

伊藤

黒木

黒木

これってつまり……まさに今、伊藤さんが僕にやっていることですよね。
そうなります。 「壁打ち」(※)という言葉もありますし、これを実践しているビジネスマンはなかなか多いですよね。 説明を人に対して行ったら「壁打ち」もしくは「告白デバッグ」になって、無機物を相手にやったら「ラバーダッキング」になる、という感じでしょうか。

※ スポーツの練習法ではなく、思考を整理するいち手法のこと。誰かに自分の考えていることを話しながら、思考やモヤモヤを言語化し、整理していくやり方を指すことが多い

伊藤

伊藤

テディベア・デバッグ

▲ラバーダッキングは「テディベア・デバッグ」「ベアプログラミング」と呼ばれることもあり、使用するのはアヒル人形じゃなくても大丈夫。話しかけたい気持ちさえあれば、デスクに置いたサボテンなどでも良いらしい

黒木

黒木

「壁打ち」を1人でやるときの相手としてのアヒル人形……。そう考えると、一見とんでもないやり方に思えるラバーダッキングも、普段の我々の仕事からそう遠くない方法論に思えてきました。
そうですね。ひょっとすると、この記事の相談相手もアヒル人形で良かったのでは?
伊藤

伊藤

黒木

黒木

おっと。急に失礼なことを言い出しますね。

アヒルちゃんに相談して、関係者同士の折衝をしよう

それではさっそく、自分の日常業務でラバーダッキングを実践していきます。

本来のラバーダッキングが「バグを見つけるため」の手法であることを考慮し、今回は日常業務における「問題を発見する」プロセスで、ラバーダッキングの導入方法を考えていきます。

例えば、「行き詰まったプロジェクトのボトルネック探し」や「プレゼン資料のツッコミどころを無くす」など、「加点箇所を増やす」のではなく、各プロセスにおける「減点箇所をへらす」シーンであれば、その特性が生かせるのではないでしょうか。

そんなとき、ちょうどよいタイミングで折衝が必要な状況が発生しました。

お取り引きのあるクライアントと、自社からお仕事をお願いしているデザイナーさんとの間で、理想としている制作スケジュールに行き違いが発生。両者の間を取り持って、お互いが納得できる形で制作スケジュールを引き直すのが自分の役割です(※)。

今回は、この「関係者同士の折衝」というシチュエーションで、ラバーダッキングを試してみましょう。

※ 今回のケースは、実際に起きそうな出来事を想定したフィクションです

アヒルちゃんに相談
伊藤

伊藤

…………。
…………。
アヒルちゃん

アヒルちゃん

登場人物紹介

伊藤

アヒルちゃん:ラバーダッキングの検証用に購入(税込み633円)。本来はお風呂用のおもちゃだが、今日は仕事の相談を聞くために連れてこられた不幸なラバーダック。

伊藤

伊藤

あのー…………。
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

ちょっと相談があるんだけど、聞いてもらえますでしょうか……?
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

いま制作している記事なんですけど、クライアントさんから急な相談があって。今日になって、記事を5日に納品してほしいって急に言われちゃったんですよ。
アヒルちゃんに相談
伊藤

伊藤

でも、デザイナーさんは7日じゃないとどうしても難しいって言っていて。これ、どうにかならないですかね?
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

普通に考えると、「デザイナーさんに作業を早めてもらう」「クライアントさんに納品日を遅らせてもらう」のどちらかだと思うんですけど、どっちかが辛い思いをするのも申し訳ないんですよね……。
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

というか、お願いしているデザイナーさんは作業が早い人だし、7日の予定でもかなり急ぎだと思うんですよね。
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

そうなると、デザイナーさんに作業を早めてもらうのはあまりお願いしたくないなあ。であれば、クライアントさんに交渉するしかないかな……。ああもう、どうして5日までなんて急に言いだしたんだろう……。あれ?
------
伊藤

伊藤

そういえば、予定が急に5日までになったのは本当にどうして?びっくりしたから聞き逃しちゃったけど、これを知らないことにはなにも判断できなくない?
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

であれば、慌ててスケジュールを調整する前に、まずはクライアントさんに前倒しの理由を聞くところからだな。理由によっては別の選択肢が見つかるかもしれないし。
…………。
アヒルちゃん

アヒルちゃん

伊藤

伊藤

とりあえず、先にクライアントさんへ連絡してみるよ。ありがとう!
…………。
アヒルちゃん

アヒルちゃん

アヒルちゃん

仕事の問題発見を、アヒルちゃんに助けてもらいたい

黒木

黒木

で、実際にラバーダッキングをやってみて、どうだった?
話しているのはアヒルちゃんなのに、喋りながら頭が整理されていく、不思議な感じでした。喋っていると「あ、これも説明しておかないとアヒルちゃんが理解できないな」という気付きがたくさんあって、どんどん話すことが増えていくんですよね。
伊藤

伊藤

黒木

黒木

その「整理される不思議な感じ」は、やってみてようやくわかるものかもしれないです。
アヒルちゃんと筆者
伊藤

伊藤

あと、アヒルちゃんに説明する時には、「一から十まで説明すること」はとにかく心がけたほうがいいと思いました。トラブルの説明をするにも、相手が「自分の仕事内容を全く知らない人」だと思って説明したほうがいい。 「誰が、何を、どうした」とか「最終的な目標」を、説明しながらおさらいする感じでしょうか。 そうしないと、前提や共通認識のような「説明するまでもないこと」を飛ばしてしまうんですよね。 でも、そこまでを言語化してようやく見えてくる部分も多いので。
そこは、「アヒルちゃんに向かって、とにかく丁寧に、優しく手を引きながら簡単な言葉で説明してあげる」意識が大事、ということですね。
黒木

黒木

伊藤

伊藤

だから、作ったプレゼン資料に対する想定質問を考えるときも、「とりあえず10個、出そうな質問を考える」と自分で決めて、無理やりひねり出すくらいがちょうどいいと思います。 あとは、「あの上司だったらどんな質問をしてくるかな?」みたいに、話し相手に仮の人格を設定しながら説明するのも良いかなと思ったんですが…… この方法はそもそもラバーダッキングの範疇なのか、という疑問もありますね。
ラバーダッキング法で行う「擬似的な対話」の精度を上げていくイメージですね。
黒木

黒木

伊藤

伊藤

そしてやはりラバーダッキングの最も良いところは、本来だったら誰かに協力してもらってやるようなことを、無機物を対象にして「自分ひとり」でもできるようになる、ということなんですよね。
壁打ちのように、誰かの助けを借りるのはいつでもできるわけではないですし。
黒木

黒木

伊藤

伊藤

ラバーダッキングであれば人の助けを得る必要がないので、時間や場所を気にしなくてもいいし、なんなら他人にはしづらい相談だってできる。 3時間喋りっぱなしでも、アヒルちゃんから文句を言われることは無いですからね。
そうですね。 数時間ぶっ通しでアヒル人形とお喋りしている人がいたらそれはそれで心配ですが……。
黒木

黒木

伊藤

伊藤

逆に「新規事業のアイデアを出す」というような、いわゆる「ゼロイチ」が必要なときは向いていないかもしれません。 その時は誰かにお願いして、壁打ちに付き合ってもらうほうが良さそう。
3時間アヒル人形と話すよりも、誰かとみっちり1時間話すほうが新しい発見があるかもしれない、ということですね。
黒木

黒木

伊藤

伊藤

あくまでもラバーダッキングは「簡易的な壁打ち」ということになるのかな、と。 ですので、今回の記事の相談相手に黒木編集に入ってもらったのも決して無駄ではないですよ。 おかげで考えがとてもまとまりました!
いえいえ。 フォローしてくださったんだと思いますが、次回以降の相談相手は、なるべく「アヒルちゃん優先」で選んでもらえると助かります。
黒木

黒木

伊藤

伊藤

長時間ありがとうございます……。

〈参考資料〉 伊藤貴昭「自己説明効果の理論と実践」、『慶應義塾大学大学院社会学研究科紀要』59、P.29-36、2004 上田勲『プリンシプル・オブ・プログラミング』、秀和システム、2016 多鹿秀継、中津楢男、加藤久恵、藤谷智子、堀田千絵、野崎浩成「メタ認知方略としての自己説明の特性」、『神戸親和女子大学研究論叢』3(49)、P.41-51、2016 Steve McConnell『Code Complete 第2版 完全なプログラミングを目指して』(上・下)、クイーブ訳、日経BP、2014 Andrew Hunt、David Thomas『新装版 達人プログラマー 職人から名匠への道』、村上雅章訳、オーム社、2017

文=伊藤 駿/図版とイラスト=かざまりさ/編集=ノオト