クックパッド サマーインターンシップ2016の資料を公開します

技術部開発基盤グループの @moro です。

クックパッドでは、昨年に引き続き今年も、夏の技術職インターンシップを実施しました。 クックパッドのインターンシップは前後半に分けた構成になっていました。まず前半はWebサービス開発に必要な技術の中から6つの分野に関する講義や実習を行いました。さらに後半は、前半の座学に合格した方を対象に、メンターとなる社員と一緒に実際の開発現場に入り、具体的な問題解決に取り組んでもらいました。

その中で、前半の講義に使った資料を公開します。

---

1日目 Git (@moro)

昨年に引き続き、講義初日はGit, TDD, Railsを1営業日で一巡りするという、忙しい構成でした。

Git編では、すでにGitを使っているエンジニアも多いだろうと想定して各コマンドの紹介などは最小限に済ませました。代わりに、Gitの内部構造を説明し「コミットを覚えておけばなんとかなる」感覚を掴んでもらうことを主眼に置きました。Gitあるあるである「rebase していたらわけわかんないことになった」に陥ったときにも落ち着いて復帰できるようになったと思います。

資料: https://speakerdeck.com/moro/about-git-at-cookpad-summer-intern-2016-day1

1日目 TDD (@moro)

引き続き、TDDの講義を行いました。 「時刻」を表すバリューオブジェクトを、ユニットテストに導かれながらボトムアップで実装していくというコースです。 こちらも、テスティングフレームワークRSpecの使い方や気の利いたAPIの説明などはインターネット情報にお任せしたうえで、「なぜTDDするのか」「何を考えてテストに駆動させるか」という 気持ち を伝えたい構成でした。

資料: https://speakerdeck.com/moro/about-tdd-at-cookpad-summer-intern-2016-day1

1日目 Rails (@moro)

ボリュームたっぷり1日目のラストは、Ruby on Railsを使ったWebアプリケーションの講義でした。 こちらも「特定バージョンのRailsの使い方」のみならず、Webアプリケーションフレームワークを使った開発の一般論や、HTTPやREST、RDBMS、End-to-Endなテストを書くトップダウンTDDといった内容も理解してもらえるような構成を心がけました。 ひたすらボリュームが多い講義でしたが、参加者はみなさん頑張ってついてきてくれました。すごい。

資料: https://speakerdeck.com/moro/about-rails-at-cookpad-summer-intern-2016-day1

2日目 Android (@101kaz & @kmats_)

Androidの講義では前日に作ったRailsアプリケーションのAPIを題材として、クライアントアプリを作りました。 Androidアプリのライフサイクルの話や、レイアウトの作成、サーバとの通信方法、DBを使った永続化など、Androidアプリを作る上で最低限必要な知識を説明しました。 今年は非同期処理にRxJava、レイアウトにDataBindingライブラリを利用するなどより実践的な内容になっています。 たった一日しかない中で、FragmentやRxJavaやDataBindingなどを使いこなし、実際の現場とほとんど変わらないスタイルでのAnroid開発はかなり難しいものがあったと思いますが、みなさんとても優秀だったので、想像を上回るスピードで課題をこなしていました。

資料: https://github.com/cookpad/cookpad-internship-2016-summer/blob/master/android/README.md

3日目 iOS (@slightair)

iOSの講義では、簡単なアプリの実装を進めながらiOSアプリ開発の基本を学んでもらいました。 架空のネット通販サービスで商品を注文するためのiOSアプリを題材に、講義形式の解説と自分のペースで実装を進める演習を用意しました。

午前中いっぱいとお昼ごはん後の1時間くらいで、画面の実装やAPIリクエストの送信など、iOSアプリ開発に必要な知識をひと通り説明しました。 1日しか時間がないのもあり、結構駆け足で説明してしまった所もあってすぐに演習課題に取りかかれるのか少し心配していました。 そんな心配をよそに、皆さんとても優秀で黙々と課題に取り組んでアプリの実装を進めていくことができていました。すばらしい。

ちょうど台風が関東に近づいていた日でもあり、はやめに切り上げる事になってしまったのは残念でしたね。 この日の感想を読むと「時間があるときに残りの課題もやりたい」と書いてくれた人が多かったので、それなりに楽しんでもらえたのかなと思ってます。ぜひ取り組んでみてください。

資料: https://github.com/cookpad/cookpad-internship-2016-summer/blob/master/ios/README.md

4日目 サービス開発 (@ryo_katsuma & @transit_kix)

「唯一コードを1行も書かない日」のサービス開発の講義では、前後半2パートの構成でした。

前半では、昨年に引き続きクックパッドでのサービス開発に対する考え方を講義形式で学んでもらい、 後半ではグループワークとして1人の社員の課題を解決するプロトタイプ作りとユーザーインタビューを行ってもらいました。

サービス開発において正解は誰も分からないものです。 そのためにもクックパッドでは、仮説を検証できるものを早く形にして、ユーザーの反応を見て「学びのある失敗」をしながら正解を探るアプローチを取っています。

今回も、たった1人の社員を満足させるためのプロトタイプであっても「これは私は使わない」「むしろこういうものが欲しい」など、全く想定していなかったフィードバックを参加者全員もらう流れになりました。

なかなか大変なグループワークだったと思いますが、学生のみなさんには「思い込みでつくるサービスがいかに意味がないか」「ユーザーのフィードバックがいかに大事か」など、普段ではなかなか体験できないであろうことを実感してもらえたかと思います。

資料: https://speakerdeck.com/katsuma/service-development-at-cookpad-2016-summer-internship

5日目 自然言語処理＆機械学習 (原島純)

5日目は自然言語処理と機械学習の基礎を学んでもらいました。自然言語処理の講義では基礎解析からアプリケーションまで、その仕組みを大まかにお話ししました。また、それらがクックパッドでどのように使われているかもお話ししました。実習ではクックパッドのデータを使って、形態素解析器に触れてもらいました。

機械学習の講義では基礎知識から深層学習までをおおまかに学んでもらいました。こちらの実習でもクックパッドのデータを使って、機械学習のモデルを作ってもらいました。機械学習を初めて学ぶという方が多かったのですが、皆さん、素晴らしい成果を見せてくれて、大変驚きました。

資料: https://speakerdeck.com/junharashima/internship2016

6日目 プログラミングパラダイム (青木峰郎)

最終日の6日目は昨年に引き続き、プログラミングパラダイム……のはずが、それとはまったく関係なくJavaScriptコンパイラーを書くという課題をやってもらいました。

この課題のテーマはずばり、「すぐには役に立たないことをやる」。これまで言語処理系を実装したこともなかったエンジニアが、インターンに参加してくれたからと言って、すぐその日からプログラミングパラダイムについて一家言持って語れるなどということは正直ありえません。であればせめて3年後に語れるようになるための礎としてこの日を使ってもらうのがよいだろう、というのがこの講義の趣旨です。

さて、実際に講義をやってみて、去年も今年も多かった間違いが1つありました。それは、「プログラムを実行するコードを出力しなければいけないのにその場でプログラムを実行してしまう（インタープリターを作ってしまう）」という間違いです。この点はある意味コンパイラーの肝とも言える特徴なので、ここに悩んでもらえるのは講義をやった甲斐があるというものです。存分に悩んでいただければ幸いです。

なお、今年の反省として、流れを改善したことにより全体的に進捗がよくなってしまいました。来年は進捗をより絶望的にするために、もっと難易度を上げようと考えています。ネイティブコード出力とかがいいですかね？

資料: https://speakerdeck.com/aamine/cookpad-2016-summer-intern-programming-paradigm

---

今年もかなりのボリュームの講義でしたが、参加した皆さんは一生懸命取り組んでくれていました。 来年も、よりパワーアップして実施する予定です! お楽しみに!

(2016-09-06T19:07にスライド展開しました)

新規アプリのデザインで心がけたい5つのこと

こんにちは、株式会社トクバイ出向中のデザイナー 吉井です。

まだあまりご存知ない方も多いと思いますが、株式会社トクバイは2013年にクックパッドの新規事業としてスタートした「クックパッド特売情報」を分社化し、今年7月に設立されました。 それに伴いサービス名も「トクバイ」と改め、この夏Android / iOSの両アプリをリリース致しました。

※9月5日現在、iOSアプリはAppStoreのおすすめにフィーチャーされています！

トクバイは日々の特売品やチラシ、タイムセール情報など、リアルタイムで自分の近くのお店の買物情報を閲覧できるサービスです。

私はクックパッド特売情報の頃からデザイナーとして一連のサービス開発に携わっていますが、今日はその「トクバイ」も含め新規アプリをデザインする際、私が心がけている大きなポイントを5つご紹介します。

ユーザーをしっかりと理解する

まず基本中の基本ですが、価値を届けたいユーザーを知らないことには良いサービスは作れません。

そのなかで私個人としては、ユーザーと直接対話したことがあるかどうかで、実際のプロダクト開発に与える影響が格段に変わってくると考えています。

今回のトクバイの開発でも、「買い物」という行動はあまりに日常的で普遍的であるため、とりあえずなんか（我々が思うに）良さそうで便利なアプリにしよう、という感じでぼんやりしたままに進めてしまうと、結果なんだかよく分からないモノになってしまいかねませんでした。

また、レシピサービスであるクックパッドの内部に同居していたこれまでとも状況が異なります。

今まではレシピに紐付く形で買物情報が提示されていましたが、今回単体のサービスとしてクックパッドから切り離されることで、ユーザーのアプリの使い方が今までとは変わってくることが予想できました。

そこで私も含めた開発メンバーで、開発に入る前に実際に色んな属性のユーザーの方（クックパッド特売情報のユーザー）にお会いしてみるという試みをしました。

実際に10名以上のユーザーさんとお会いしてお話を聞いてみると、やはりそれぞれで持つ課題感が微妙に異なることが分かります。

子連れでゆっくり買い物できない、買いたいものがいつも決まらない、色んなお店の情報を比較して見たい...

ユーザーさんと直接対話することでより身近に課題感を感じられたことは、その後の開発プロセスにおいて具体的なイメージがつきやすくなるなど様々な好影響がありました。

本エントリでの詳細は省きますが、このあたりはプロダクトオーナーである弊社三浦のエントリも是非合わせてご参照ください。

最初にコアとなる価値を作りこむ

現在トクバイではスーパーに加え、ドラッグストアやクリーニング、ホームセンターなど、食品に限らない生活領域に関する様々なお店からも日々情報をお届けしています。

それが我々の持つコンテンツのひとつの強みではあるのですが、ただその情報を並べて表示するだけでは、他の競合サービスと何ら差別化が図れません。

そこで我々は前項で掴んだユーザー像をもとに、「複数のお店の情報から効率的に欲しい情報へアクセスできる」ことをコアとなる価値として設定し、それを実現するためのプロトタイプの作りこみを先に進めていきました。

特に「トップ」と呼ばれる複数店舗の情報を集約して表示する画面については、これまでのクックパッド特売情報にも存在しないものでありながら、上記のコア価値を体現する画面としてかなり多くの時間を割きました。

その名の通り起動して一番最初に開かれる画面でもあるので、アプリの「顔」となるべく相応しいものを、とメンバー間で議論を重ねに重ね、何度もプロトタイプを作り直しています。

ProttやFlinto for Macを用いてそれらを再度ユーザーさんや社内スタッフにも触ってもらいながら、率直な意見・感想を吸い上げ、組み立てては壊し...の繰り返しです。

苦しい時間が続くときもありましたが、粘り強く検証を繰り返すことでようやくひとつの形が見えてきます。

ここであまり固めきらずにある程度柔軟性を残した形で次のフェーズに移りますが、この部分の試行錯誤を早くから重ねておくことで、早期に足元が固められたような実感がありました。

我々のコアはこれだ、とチームで共通認識が持てるようになることで、その後の議論の不要な発散を抑えられ、腰を据えて開発を進めやすくなる効果があったと考えています。

早く全体像を捉える

コアが見え始めてきたら、次に思いつく限り、このアプリをリリースさせるために必要な画面の総量を洗い出します。

個人的に手法は何でもいいのですが、とにかく明確な画面単位、または機能単位で洗い出すようにします。 これも開発初期の早い段階で「今からやらなければいけないことの全体像を把握できている」という状態を作れていることが大事だからです。

そうして洗いだしたタスク量をもとにざっとマイルストーンを敷いていくわけですが、これを開発メンバー間にも見えるようにすることで、

• 決まっていないことがいつまでに決まっていないとまずそうかが分かる
• 時間をかけて考えるべき画面とひとまずそうでもない画面のバランス感が分かる
• タスク消化がどれだけ遅れだすと後半の巻き返しで余裕がなくなるが分かる
• 工期に対してできないこと、やらないこと（優先度）が早いうちに見極められる

など、自分のスケジュール管理の範囲を越えて様々なメリットが生まれました。

何か具体的な画面がなければ体験がどうこうという議論もしづらく、エンジニアも実装計画が立てにくくなります。

プロダクトの輪郭を浮かび上がらせていくことはデザイナーのひとつの職責であると思っているので、ここを率先して進めていくことが、大きなトラブルもなくリリースまで至れた一つの要因であったと考えています。

都合の良いケースだけで考えない

トクバイは、全国各地のお店から投稿いただいたチラシ情報を掲載することで成り立っています。

そのため各コンテンツに付随する情報量や、そもそもの投稿の有無はお店の裁量に委ねられる部分が多く、地域やお店の日毎の投稿状況によって、ユーザーさんに届くコンテンツの量や密度に少なからず差が出てしまうのが現状です。 （すべてのユーザーさんに均質な価値を届けられるよう、鋭意改善を重ねています）

デザイナーであれば心当たりがある方がいるかもしれませんが、要件を深く理解しないままついつい都合の良い理想的なデザインだけを作って、それだけで満足な気持ちになってしまったことはないでしょうか。

もちろんそういった状態を見越してデザインを作り上げていくことも大事ですが、足元を見ずに一部のケースでしか成り立たないものを作っていてはあまり意味がありません。

今回の開発でも、ここでいう「お店からの投稿が少ないなど、ユーザーの期待に反するがっかりなケースはなんだろう」と私個人が常に頭に置いておくことで、デザインのパターンを深く網羅的に展開できるようになりました。

複数のケースを想定する意識を強く持つことは、デザインを決定へ導くにあたって議論に深みを持たせ、実装面でも考量漏れによる工期遅延やデザインの練り直しなどのリスクが減らせるため、新規開発に限らず重要であると感じています。

また副次的な効果として、そういった「がっかりなケース」を減らしていくためにはどういう打ち手を仕掛けていくべきか、というネクストステップの手がかりが掴めてくるのも、この点を徹底していて良かった、と感じる点です。

シンプルな体験を追求する

デザインとはユーザーの体験をいかに心地よく設計できるかが一つの重要な要素であり、決してセンスよく、オシャレに、だけで語られるものではありません。

そのためトクバイのリリースバージョンでは、まずはシンプルでミニマムな、最低限ストレスのないユーザー体験を作っていく、ということに重点を置いて進めました。

例えば、Material Designに代表されるトランジションのアニメーションですが、確かに見ていて気持ち良く、新しいことを自由に試せる段階ではつい取り入れたくなることもあるかと思います。

しかしあれは本来ページ前後の関係を分かりやすくする、一連した体験を提供する、などの目的を持って設計されているものであり、「なんとなく今っぽいイカした感じのアニメーションをつける」ことが目的にすり替わっては本末転倒です。

トクバイの開発でも、写真がついたUIパーツをタップした時のトランジションについて、商品写真を拡大しながらシームレスに次ページへ遷移するといった演出を試みたタイミングがありました。

やや分かりにくいですが、プロトタイプ上だと下図のようなイメージです。

しかしこの内容でエンジニアに実装してもらったものを端末上で確認してみると、遷移時に微妙なチラつきが発生するなど細かな違和感があり、思っている品質に届かせるにはまだいくらかの調整が必要であると感じました。

工期に比較的余裕があればその後のブラッシュアップにも時間をかけるところですが、私の経験上このようなアプリ開発（特に新規）の現場においてそういったことは多くはないのではないかと思います。

勿論、今回の我々の場合も例外ではありませんでした。

局所的な調整に時間をかける余り、他の部分がおざなりになってしまい、アプリ全体を通した品質が犠牲になっては折角の苦労も意味を成し得ません。 上記のトランジションを検討した際にも、今後の開発量を見据えると今この調整に時間をかけるべきではないと判断し、単純にページングをするようなシンプルなトランジションに変更して進めました。

他にも「あったら便利そうな気がするけど仮説の検証が不十分な機能」「細かなビジュアルの作り込み」など、目指すべきユーザー価値を担保できない、あるいは明確に価値を向上させるものではない、と判断したものについては、初期の段階では適度に諦めて優先度を下げるようにしました。

細かな枝葉に拘ることよりも、まずは幹となるシンプルなユーザー体験を追求することを何よりも優先させ、アプリの持つ本質的な価値の向上を重視すべき、と方針づけたのです。

この方針をチームにも浸透させていくことで、チーム全体でひとつの方向を向いて、一丸となってスムーズに開発を進めることができたように思います。

最後に

デザイナーとして心がけた、としていくつかの内容をご紹介してきましたが、クックパッドの開発文化を受け継ぐトクバイでは、これらのマインドは私に限らず広くメンバーに備わっています。

トクバイアプリは開発期間が数ヶ月と、かなりのスピード感を持って進められたと感じていますが、それもこれらの共通理解が開発メンバーに根付いていたことがひとつの要因だったのかもしれません。

アプリもリリースしたばかりでまだまだこれからといった段階ですが、これからもユーザー視点を第一によりよい改善を重ねていきます。是非ご利用ください。

(★ダウンロードはこちら Google Play / AppStore)

なお、トクバイでは買い物の未来を楽しくするデザイナーを募集しています。 一緒に素敵なサービスを作っていきましょう。

Ruby on Rails アプリケーションにおけるモンキーパッチの当て方

技術部の牧本です。 今日はモンキーパッチの話をします。

モンキーパッチとは何か

そもそもモンキーパッチ (monkey patch) とは何でしょうか? 端的に言えば、言語の組み込みクラスやライブラリ、その他外部ライブラリの挙動を、動的に拡張する仕組みをモンキーパッチと呼びます。 *1

例えば、Ruby のモンキーパッチのすごく単純な例として以下のようなものがあります。

module NilClassExtension
  def empty?
    true
  end
end

NilClass.prepend(NilClassExtension)

インスタンスが空であるかどうかを判定するメソッドとしての #empty? は String や Array など様々なクラスに存在しますが、 nil を唯一のインスタンスとする NilClass には本来は存在しません。 このモンキーパッチを導入することで、通常はメソッドがないことによる例外が発するはずの nil.empty? というメソッド呼び出しが、 true を返すようになります

さて、このようなパッチが読み込まれたシステムでは、予想外の挙動が起きます。 例えば、 method_missing を用いてフォールバックするようにしているライブラリがあるとすると、 nil は本来 #empty? メソッドを受け取れないはずが、パッチが存在するためにフォールバックせず、挙動が変わってしまいます。

ここで例に挙げた NilClass に #empty? メソッドを追加するモンキーパッチは、あとで述べるように、モンキーパッチとしては行儀の悪い部類です。

しかし、このパッチは、実はかつて実際にクックパッドに存在していたものです。

クックパッドの中心となるアプリケーションのレポジトリは最初に作られてから10年弱が経過しており、歴史的経緯から様々なモンキーパッチが存在します。 われわれは、これらのモンキーパッチとうまくやる方法を考えていく必要があります。

そこから得られた知見をもとに、本稿では Ruby on Rails アプリケーションにおける、モンキーパッチの当て方、そして、モンキーパッチの外し方について紹介します。

モンキーパッチの当て方

さて、あなたが Ruby でアプリケーションを書いていて、ライブラリなどの標準の挙動を変えるためにモンキーパッチを導入したいと考えたとします。 その際、まずは最初の原則を当てはめましょう。

最初の原則 - モンキーパッチを使わない

まず、本当にモンキーパッチを当てる必要があるかを考えましょう。 それが何らかの不具合に対する対策だとしたら、ライブラリを最新バージョンにアップデートすることで対応できませんか。 発想がモンキーパッチになってはいけません。 何らかの組み込みクラスの挙動を変えたい場合、クラスそのものを拡張する以外の方法は取れないか考慮するべきです。

冒頭述べた NilClass#empty? について言うならば、 nil が入る可能性がある変数に対し、 var.empty? と呼んだときに true が返ってほしいのは理解できなくはないですが、Rails アプリケーションでは var.blank? というほぼ同等の代替手段があるので回避できるはずでした。 そういう観点ではこのモンキーパッチは入れるべきものではなかったと言えます。

それでもモンキーパッチを当てたいとき

とは言え、モンキーパッチを使わざるを得ない場面が起きるかも知れません。 よくある例として、外部のライブラリになんらかのバグがあるがそれが修正されたバージョンがリリースされていない場合、または、ライブラリのアップデートによる影響範囲が大きく別途検証が必要なためにすぐにアップデートできない場合などです。

以上のような理由でモンキーパッチを当てなければならない場合、最大限パッチをコントロールする必要があります。

パッチを隔離する

モンキーパッチを導入することを決めたとき、まず行なうべきはモンキーパッチ用のディレクトリを作成することです。 これによって、他のモジュールやクラスに影響を与えるコードを一箇所に集めることで一覧性を高め、読み込みのタイミングを統一します。

クックパッドでは #{Rails.root}/lib/monkey_patches というディレクトリがよく使われており、このディレクトリをイニシャライザで require しています。

# config/initializers/000_monkey_patches.rb
Dir[Rails.root.join('lib/monkey_patches/**/*.rb')].sort.each do |file|
  require file
end

アプリケーションから見えるインターフェースを変えない

モンキーパッチを当てる場合に気をつけることの一つに、パッチを当てたことによってアプリケーションコード (モンキーパッチを当てたライブラリを使う側のコード、 Rails の場合は app ディレクトリ以下にあるコードなど) を変更させるべきではないうものがあります。 つまり、たとえライブラリにパッチを当てたとしても、新しいインターフェースを増やしたり、既存のインターフェースを変更させないということです。

これによって、モンキーパッチを外すときの労力がかなり下がります。

例えば、最初に論じた NilClass に #empty? を追加するというパッチは、この原則に則しておらず、実際にパッチを除去する際に大きな労力を要しました。

パッチが不要になったときに外せるようにする

さて、影響範囲を最小限にするという観点では、パッチが不要になるタイミングで適切にキャッチアップしてパッチを削除することができるようになるべきです。

最低限やるべきは、なぜそのパッチを導入することになったかをコメントとして残すことです。 さらに、どういう状態になればパッチを外して良いかまで明記されていると、将来の自分やチームメンバーがそのパッチを外せるかどうかで悩むことを防げます。

より良い方法は、パッチが不要になったら開発者が自動的に気づけるようにすることです。 例えば、ライブラリの特定のバージョンの挙動に依存してパッチを当てざるを得なくなった場合、以下のようにライブラリをアップデートしたら例外が発生するようにして、もしパッチを消し忘れてもテスト実行時などに気づけるようにします。 *2

# lib/monkey_patches/nanika_ext.rb
require 'nanika/version'
unless Nanika::VERSION == "2.2.0"
  raise "Consider removing this patch"
end

module NanikaMonkeyPatch
  # monkey patches go here...
end

Nanika.prepend(NanikaMonkeyPatch)

このように、大規模なアプリケーションにモンキーパッチを当てる際には細心の配慮をもって対応する必要があります。

モンキーパッチの外し方

さて、当てたモンキーパッチはいずれは外されなければなりません。 次に、どのようにモンキーパッチを外すのかについて論じていきます。

モンキーパッチを当てるときに注意を払えば、開発者はどのタイミングで外せるかを気づくことができるし、安全に外せるようになっているはずです。

モンキーパッチを外す作業は、外部ライブラリのアップデートや内部ライブラリの挙動を変更した場合の対応とほぼ同じです。 つまり、影響範囲を調べて、動作確認をして、問題なければリリースするという手順を踏みます。

先述の通り、ライブラリのインターフェースはパッチを当てた場合も外した場合も同じであることが期待されるので、基本的にアプリケーションのコードを変更する必要はないはずです。 しかしながら、実際はパッチによる副作用によって思わぬ場所で不具合が発生するかも知れないので、一度入れたパッチは細心の注意を払って外すべきです。

まとめ

本稿では、 Ruby on Rails アプリケーションにおけるモンキーパッチの当て方について記述しました。 先に述べたように、モンキーパッチを可能な限り使わず、使うときは最小限の影響範囲に留めて、なるべくふつうの Ruby、ふつうの Rails を使うことがアプリケーションの寿命を延ばす秘訣であると考えます。

*1:そもそもなぜ「モンキーパッチ」と呼ばれるようになったかについては、ある出典 によれば、 Zope の開発者内で使われ始めた用語であり、他のコードと衝突する可能性のあるパッチが ゲリラパッチ (guerilla patch) と呼ばれていたが、音が似ていることによって ゴリラパッチ (gorilla patch) に転じ、さらにそこから モンキーパッチ (monkey patch) になったとあります

*2:われわれのチームでは、これを「パッチに賞味期限を設定する」と呼んでいます