  |
はてなキーワード: 単体テストとは
単体テストというのは、画面を手動で操作してスクリーンショットを撮る仕事だった。エクセルで仕様書を書き、レビューをしていたが、レビューアーはテストケースよりも、枠線の整え方に気を配っていた。
誰かが自動テストを導入しようと言い出した。「再現性がある」「保守性が高まる」「もっと良くなる」と口々に言われていた。
でも、テストコードを開発する工数はどうするのか、開発コードが増えればさらに大変になるのではないかと不安があった。
それでも、これが実現すれば、何かが大きく変わる予感がした。
アプリケーションフレームワークはStrutsだった。フォームをポストする瞬間にカオスが生じ、50行の無駄なコードを書き、100行の読みにくいコードを理解することが技術者の条件だった。
ある人が「レイヤリング」という概念を持ち出し、別の誰かが「DI」と言い出した。アプリケーションアーキテクチャという言葉も登場し、ファウラーという人物の名前も聞こえるようになった。
新しい構造が提案され、それに影響を受けながら、「いつかは美しいアプリケーション構造が生まれるのかもしれない」と夢を抱いていた。
当時、PerlでCGIを作っていたが、PHPやRubyが登場した時は、正直Web"サイト"を作るためのものだと侮っていた。
しかし、次々と洗練されたWebアプリケーションフレームワークが生まれ、StrutsやJavaEEよりもはるかに使いやすくなっていった。
数多くのWebフレームワークの中で、どれを選ぶべきか悩みながら、「いつか完璧なWebフレームワークが現れるかもしれない」と期待していた。
サーバーは冗長化され、ReversProxyを使い、セキュリティのために構成を変更してきた。そしてクラウドが登場し、Dockerなんて本番で使えないと言っていた時代から、
気がつけばどこに存在するのかもわからないクラスターの中で、コンテナアプリが動いている時代になった痛快だ。
かつてLinuxマシン一台を「鯖」と呼んでいた時代から、世界は目まぐるしく変化し続けるとかと思っていた。
誰かがAjaxと言い出し、別の誰かがReactと言い出した。「こんな方法でHTMLを作って良いのだろうか？」と疑問に思いつつも、「Webはアプリケーションだ」という感覚が強まっていた。Webアプリケーションがどう進化していくのか、未来を感じることができた
私たちは、ソフトウェアを開発すること自体に大変さを感じていた。新しい技術やフレームワークが次々と登場し、その都度課題が解決される一方で、新たな課題が生まれる。これほど面白いことはなかった。そしてエンジニアたちには一体感があり、誰もが自分なりの方法で課題を解決し、そのフィードバックループが世界を動かしていた。だからこそ、今は少しつまらない。変化は穏やかになり、「お金を稼ぐ」という目標だけが共通となり、課題は個々の事象に閉じ込められている。しかし、それが悪いことではない。ただ、私たちの時代が変わったのだ。
かつては、私たちの目の前には普遍的な課題があり、それぞれがそれぞれの場所で課題を解決し、そのフィードバックループが世界を動かしていた。
生成AIで例えると、それをどう使うかではなく、エンジニアが一丸となって生成AIをチューニングしていた。世界情勢で例えると、世の中の飢餓を全世界の人がアイディア出して、解決しようとしてたいた。
今でも、普遍的な課題は世界中に転がっているが、それらは高度で、私たちには手が届かないものが増えてしまった。
ITは面白かった。プログラミングが分かるだけで、世界の課題を一緒に解決できる時代だった。それぞれが自分の場所で働くだけで、世界を動かしていた。そんな時代が終わってしまったと感じる。
老害といえば昔話だろ！
偉っそうなリーダーがいてね。
普通はこの手法は最後の手段として使用するもんでしょう。他の方法を試して、それでもダメだった時に最後の手段として上司経由で指導するもんでしょ。
リーダーとしていろいろ試行錯誤してから、最後の手段として上司に報告とかすべきでしょ。
この問題、相手も正しい。ミスはダメなことなのだから。自分は強くは相手に言えない。ミスしたのは自分なのだから。しかし腑に落ちない。
いろいろ考えてみたが、騒音トラブルなどの近隣トラブルで例えると次のようになる。
横の家が21時頃なのに煩い。
どちらも正しいだろう。
人間関係を築く必要のない赤の他人になら、①がベストだ。相手も不快にはならない。
しかし、相手が子ども会などで接点を持つ可能性がある相手だと、いきなり警察に通報するのはカドが立つ。②がベストになる。
この事例はとても近いと思う。人間関係を築く必要があるかないか、の違いだ。つまりこれは、リーダーには人間関係を築く気がない、ということだ。リーダーを仲間と思ってるのがダメなのだ。リーダーは第三者の人。客先の嫌な人、と思えば良いのだ。
ひとまず、作業をするとミスをする可能性が増えるので、なるべく作業することを控え、何度も確認を行うことでミスを発生させないようにした。これまでは自主的に目についた問題は積極的に対応してきたが、依頼があったものだけ直すようにした。
そしてこんな働き方は性に合わないので仕事を辞めることにした。
ミスについて：
ミスをする人=能力の低い人、ではない。人間誰しも作業をすれば必ずミスは発生する。確認すればミスは減るが、それでも限界がある。バグのないシステムはない。
私はそこそこ仕事が早くミスもない人、と職場に思われていたはずだ。仕事を辞めると伝えた時は引き留めが入ったし、○○さんがいなくなった後が怖いです、なども言われた。
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check, Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの？」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか？
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか？
それをなぜ、個々のチームに依頼する？
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/15 10:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法。
1. 主要なシステム オブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
3. データフローを実現するために API とその戻り値をコーディング。
4. 単体テストを使用して API の予想される使用法を文書化。
5. 各 API に必要な量の既定のデータ (別名、ダミー データ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7. コードをリファクタリングし、システム オブジェクトを調整し、完了するまでこれを続ける。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1359 | 国土交通省 ネガティブ情報等検索サイト | www.mlit.go.jp |
| 1087 | ゲームを趣味にしている人の割合が多いのはどのくらいの収入の人たちなのか調べてみた - nonameのノート | noname774300.hatenablog.com |
| 854 | マシュマロ！｜高河ゆん｜pixivFANBOX | kouga-yun.fanbox.cc |
| 850 | トコジラミ根絶方法 ｜ 害虫・害鳥獣を安全に対策します｜株式会社 オオヨドコーポレーション Ｐテックス社 | oyodo-pmp.com |
| 847 | ラマヌジャンは本当に何も知らなかったのか | mathlog.info |
| 774 | 裏紅白歌合戦2023 | jiyujoho.a.la9.jp |
| 679 | 水は変わった物質 | vitroid.github.io |
| 671 | しずかなインターネット | sizu.me |
| 606 | 日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ | simplearchitect.hatenablog.com |
| 498 | 『ゼルダの伝説 ブレスオブザワイルド』が品質を高めてくれた。売上10万本超え、R18インディーゲーム『洗脳アプリで高慢なお嬢様を好き放題するシミュレーション』開発者インタビュー - AZ-LINE あずらいん！ | az-line.jp |
| 484 | ChatGPTに社内文書に基づいた回答を生成させる仕組みを構築しました - コネヒト開発者ブログ | tech.connehito.com |
| 475 | 超映画批評『ゴジラ-1.0』90点（100点満点中） | movie.maeda-y.com |
| 465 | メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou | sizu.me |
| 454 | 「直接会って話したほうがはやい」は速いだけ｜araya | sizu.me |
| 438 | ベンダが提供していない決済モジュールの不具合による情報漏洩事故 東京地判令2.10.13（平28ワ10775） - IT・システム判例メモ | itlaw.hatenablog.com |
| 436 | Othello is Solved | arxiv.org |
| 435 | 池田大作氏の御逝去の報に接し | kishida.gr.jp |
| 424 | https://ip.guide/ | ip.guide |
| 421 | ナポリタンが究極の味になる！ほんのひと手間に「やって大正解」「今度からこうする」 - macaroni | macaro-ni.jp |
| 421 | 大麻、少年の性被害、男らしさの病（松本俊彦）[第12回] 酒をやめられない文学研究者とタバコがやめられない精神科医の往復書簡 | ohtabookstand.com |
| 407 | 変なドメイン取るな.net | www.henna-domain-toruna.net |
| 401 | ｍＲＮＡのひみつ ｜ まんがひみつ文庫 ｜ まんがでよくわかるシリーズ ｜ 学研キッズネット | kids.gakken.co.jp |
| 377 | 【雑記】セキュリティガイドライン類 約300時間 読み漁ってみた - 2LoD.sec | nikinusu.hatenablog.com |
| 374 | 弊社元幹部社員の不正について/日本海テレビ | www.nkt-tv.co.jp |
| 368 | t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog | swet.dena.com |
| 361 | コラム・寄稿「なぜドイツ人にできることが日本人にできないのか」 | www.rieti.go.jp |
| 360 | 令和時代の個人サイトの作り方：suama works | techbookfest.org |
| 356 | 【楽天市場】SPUの特典内容変更について｜SPU（スーパーポイントアッププログラム） | event.rakuten.co.jp |
| 345 | 国産プレミアムウイスキー 一部商品の価格改定について | www.suntory.co.jp |
| 335 | Mini vMac | lrusso.github.io |
ブラックボックステスト (英: black-box testing)は、内部構造や動作を覗き見することなく、アプリケーションの機能を調べるソフトウェアテストの手法のこと。アプリケーションを見えない箱として扱い、入力と結果の整合性を確認する。このテスト方法は、ソフトウェアテストのすべてのレベル（単体テスト、統合テスト、システムテスト、受け入れテスト）に適用できる。仕様ベースのテストと呼ばれることもある[1]。
「ブラックボックス？飛行機に付いてるやつ？」という反応が多かった。
ドッグフーディング (英: dogfooding) または「自社のドッグフードを食べる」「ドッグフードする」(Eating your own dog food、Drinking your own champagneとも言う)は、コンピュータ業界において、自社製品を開発して利用する組織の習慣で[1]、組織が実際の使用法で日々自分たちで製品を利用しながら製品テストを行うことである。日本語では単に「ドッグフード」ということもある。そのため、ドッグフーディングは品質管理として機能し、開発者自身による製品の自信を表す証言広告となる[2][3]。尚、日本企業では自社実践(じしゃじっせん)という言葉が相当する意味の言葉として使われている。
「プログラミングに必要なのはググる力だ」などとまことしやかに言われます。が、これは嘘なので、プログラミング初心者は（中級者以上も）真に受けないで下さい。そして、プログラミング教育に携わる人は、こういう有害な嘘を広めるのはやめて下さい。
なお、ここでいう「プログラマ」とはプログラミングを仕事にする人、または作成したプログラムを公開する人を指しています。純粋に趣味でプログラミングをしており、ソースコードもソフトウェアも公開するつもりの無い人は、どんな方法でプログラミングをしようと自由です。
プログラマに（プログラマに限らず）必要なのは、自身の専門分野に関する基礎的かつ体系的な知識です。それらが不足していては、「ググる」ことさえままなりません。英語で喩えれば、時制や不規則動詞という概念を知らずに辞書を引いて、「I saw him yesterday. 」の「saw」をのこぎりのことだと思い込むようなものです。要するに、調べたい事項が何に関するものなのかを理解していなければ、調べようがないのです。
それでは、プログラミング初心者にとって必要な基礎知識は具体的にどのようなものでしょうか。
まず当然ですが、自分が使っているプログラミング言語やフレームワークの機能は一通り知っている必要があります。組み込みのデータ型や制御構文はもちろん知らなければいけません。高階関数、クラス、非同期処理等の発展的な機能も知る必要があります。言語だけではなく、パッケージマネージャ、タスクランナー、単体テストツール等の周辺ツールの理解も必要です。また、「コードコンプリート」とか「Effective ○○」のような書籍に書いてあるような設計・コーディングのベストプラクティスも知らなければいけません。要するに、現代のプログラミングの「常識」は全て知っている必要があります。
そもそも「そういう機能が存在する」と認識して初めて「調べる」ことができるのです。列挙型という機能の存在を知らずに「Javaで列挙型はどう書くのだろう」と調べることはできません。非同期処理の存在を知らずに、「JavaScriptで非同期処理はどう書くのだろう」と調べることはできません。
では、そのような一通りの知識を身に着けるためには、どのようなリソースから学ぶべきでしょうか。
逆に、Wikipedia、Qiita等の個人が趣味で書いた記事、プログラミングスクールの記事、プログラミングスクールや家庭教師、etcを主体に学ぶのはやめるべきでしょう。
もちろん、特定の話題について調べる過程で、非公式の情報に行き着くことはあるでしょうが、そこで使用されているライブラリ等の仕様については、必ず公式ドキュメントで裏を取るべきです。
時々、こういった正式なドキュメントを読むことが、初心者にはハードルが高いと言う人がいます。しかし、冒頭で述べたようなプログラミングを仕事にしようとしている人達が、こういうことができないのはおかしいです。
実際、公式ドキュメントを読むことはそれほど難しいことではありません。有名な言語やライブラリ等のドキュメントであれば、高校程度の数学力英語力とある程度のコンピュータ操作の経験があれば、理解できるように書かれています。その程度の素養も無いのにプログラマ（特に職業プログラマ）になろうとすることが、そもそもおかしいのです。運動が苦手なのにプロスポーツ選手になろうとするようなものです。
Steamで買った『Recursed』というゲームを全ステージクリアしたので、記念に感想を書く。
Steam：Recursed
https://store.steampowered.com/app/497780/Recursed/?l=japanese
一見すると『Recursed』は2Dのレトロな雰囲気のアクションゲームである。操作はシンプルで、方向キーで左右に移動し、アクションはジャンプと物をつかむ/投げるだけだからだ。部屋の中を移動してブロックをつかんで足場を作ったり、鍵をつかんで扉を開錠したりしてゴールへと到着（crystalを獲得）すればステージクリアだ。
ステージの始めはチュートリアルの様に簡単だが、ステージを経るごとに難しくなり、そのうち何度も試行錯誤したり難しさのあまり何十分も頭を抱えたりもした。
この複雑さを生み出す要因は箱(ゲーム中表記ではChest)である。このゲームでは箱の中へジャンプすることで部屋の内に入れるが、一度箱の外にでると箱の内部状態はリセットされてしまうのだ。よって箱の中にブロックや鍵などのオブジェクトを持ち込んでも保存することはできないし、ブロックの位置もリセットされるし、開錠した扉もまた施錠されてしまうことになる。
さらに大きな特徴として、箱を持ち歩いて移動することができるのだ。それにより、箱を持ったまま別の箱に入ったり箱を持って箱の外にでることもできる。
そして、ステージを経ると箱の中の部屋は箱の外と同じ部屋という場面に出くわす。Recursedは『再帰呼び出し』という意味らしいが、まさにこのゲームのタイトル通りの現象が起こるのだ。そして、以降のステージでは再帰を交えることでパズルの複雑さはより深まっていく。
再帰は数学的帰納法やアルゴリズムでは定番の概念だが、それがパズルとなってプレイヤーの思考回路を奪ってくる。私はかつて社畜プログラマとしてJavaプログラミングを経験していたので、箱に入ることはメソッドを呼び出すことの様に感じた。オブジェクトを持って箱に入ることは引数を使ってメソッドを実行することであり、オブジェクトを持って箱の外に出ることはreturn文でメソッドを終わらせることであった。
「ゴール前の段差が大きくブロックが必要だから、ブロック生成メソッドを呼び出してブロックオブジェクトを返り値として渡さなくてはいけないけど、そうすると鍵オブジェクトをゴールメソッドの引数として渡すことができなくて……、いっそのこと、ブロックメソッド内からゴールメソッドを呼び出すべきか……、メソッドの返り値は一つだけだが何度も呼び出せばいけるか？ この緑色のオーラはなんだ？ Staticを意味するのか？ Staticなオブジェクトの位置情報をあらかじめ変更しておけば、ゴールメソッドで引数渡しをする必要がなくなるのか？」
こんなことを一つのステージをクリアするだけのために何十分も考えていたのだ。念のために書いておくが、ゲーム内には数学用語やプログラミング用語は一切出てこない。ただ単に、私にJavaプログラミングの経験があるからその用語でパズルを考えていただけだ。ゲーム内で箱から出入りしたりオブジェクトを箱の中から出し入れするとどうなるかを、Eclipseでステップ実行するように想起していた。ちなみに、ゲーム内で存在しない部屋や壁の中に移動しようとするとparadoxが発生して強制的に特殊な部屋へ移動されるが、私はその度にステップ実行でExceptionに遷移されたことの様に感じた。他の言語に精通するプログラマだったり数学畑の人ならば、私とは異なる概念でパズルを思考をするのだろうか。
プログラマを辞めて何年もプログラミング的思考をしてこなかった私でも全ステージクリアすることができたのだから、学校でプログラムを学んでいたり現役でプログラミングをしてきた人ならばこのゲーム『Recursed』をクリアすることは可能だろう。いっそのこと、『Recursed』のクリアすらできない人にプログラミングができるのか？ と煽ってみたいくらいだ。
ちなみに、もし私が社畜プログラマ時代にこのゲームをやったらブチ切れていただろう。なんで仕事でプログラミングで脳を酷使した上に自宅のゲームでも同じようなプログラム的な思考をしなければならないんだよと。プログラミングから何年も離れていた今の私にとって『Recursed』は、プログラミングや単体テストが無事成功した時の快楽を思い出させるものだった。
『Recursed』はパズルとしての難易度は非常に高いが、理不尽な解法を求められることはない。理不尽な解法のクイズやパズルには怒りが湧いてくる。ひと昔前のクイズ番組を見たことのある人なら『モヤッとボール』を投げつけたくなる、と言えばその感情が伝わるだろう。『Recursed』はどんなに難しいステージでも、ただただ開発者のパズル作成能力に感嘆するだけで怒りは湧いてこない。
似たようなアクション風パズルゲームとして有名なのは『The Witness』であろう。『The Witness』も私が好きなパズルゲームであり、ゲームとして高い評価を得ていることに間違いはないのだが、しばしば理不尽な解法を求められるパズルがありその度に私は怒りが湧いてきたものだ。そう考えると、『Recursed』はパズルとしての洗練さだけなら『The Witness』を超えるものだと私は思う。
具体的にパズルを解説するととただのネタバレになってしまうので（もっとも、文字だけでパズルの解法を説明できないのだが）、『Recursed』で私が好きなステージを述べる。順番は攻略順に並べた。
チュートリアルの様に簡単だったこれまでのステージから突如再帰の概念を見せつけられることで、このゲームのタイトル名の意味を理解することになった。
鍵を手に入れたら扉に到達できず、先に扉に到達したら鍵が手に入らずで、まさにインターロックの名前に相応しいステージだった。
一画面だけのオブジェクトが少ないシンプルなステージだが、氷の壁に阻まれてゴールできず苦戦した。試行錯誤の繰り返しの末クリアできたが、何故クリアできたのかがわからない。
The Voidのステージはどれもこれまでの集大成という感じでやりごたえあったが、中でも頭をひねらせたのがこれ。ゴールの部屋を水没させたり水の無い状態で入ったりして鍵を運搬するのに苦労した。
箱を左右へ投げて移動を繰り返して、高い位置にあるゴールを目指すのがまさにEscalateというステージ名そのものだった。paradoxを発生した後のパターンが複雑だったのが印象に残っている。paradoxを発生させたらcrystal獲得（通常のクリア）できないのかよ……という落胆は大きかった。しかし、それだけにcrystal獲得とdiamond獲得（paradox発生によるクリア）のどちらも大きな達成感を得られた。
簡単そうに見えて難しく、唯一ステージを飛ばして次のステージへと進んだので印象に残っている。後に複数日に及ぶ数時間の試行錯誤で改めてこのステージをクリアができて、クリアにかかった時間が最も長くなったステージでもある。しかしながら、おそらく開発者の想定外の方法でのクリアであり。初期画面から右の方へ一切行かずにOobleckさえ使用しないというクリア方法にスッキリしなかった。といっても、開発者の想定を無視するゴリ押し的なクリアを見つけたのはこのステージだけだった。
The Void/Escalateと似たコンセプトのステージだが、釜（JavaにおけるThread？）のギミックを利用したより複雑な構成となっている。高い位置にあるゴールを目指すのは、やはりFlightというステージ名そのものだった。
この記事を投稿する前にエンディングを見れていないことに気づいた。
全ステージクリア（全てのCrystal取得）したからと、この記事を執筆するためにネタバレを気にせず攻略情報を調べていたけど、エンディングなんてわかる訳ねえよ。The Void/Trilemmaの最後にCrystal取得とは関係ない意味深なオブジェクトがあることには気づいていたけど……。ちなみに、私のSteam実績によるとdiamondとrubieの全取得はできてないけれども、もう取得する気力はない。パズルゲームガチ勢にとっては、実績全解除を目指さない私は軟弱者に映るのだろうか？ 攻略を調べずに実績全解除できる人は、高い論理的思考能力を有しているに違いない。
