昨年の 8 月にアジャイル事業部に異動した taiju (id:jdg) です。
ゲームのやり込みの一種に「縛りプレイ」というものがあります。
縛りプレイとは、ゲームの中で自主的に制約を課して、その制約下でゲームをプレイすることで、ゲームの難易度を上げて達成感を味わったり、ドヤったりするプレイスタイルのことです。
例えばドラゴンクエストのようなロールプレイングゲームであれば、初期装備で全クリとか、仲間なしで全クリとかが縛りプレイです。
今回はゲームの話をしたいわけではなく、ソフトウェア開発のスキルを獲得をする上で、この縛りプレイが役立つ (または役立った) よという話をします。
たとえば、自分はかな入力使いなのですが、かな入力を習得する上で、かな入力縛りという縛りプレイの時間が必要不可欠でした。
ローマ字入力であればタッチタイピングができるにも関わらず、かな入力を習得するために、無理矢理かな入力で仕事をした期間があったのですが、これはメールを一通返信するだけでも、発狂するほど効率が悪く時間がかかり、不自由極まりありませんでした。
ただ、この縛りプレイを経て、かな入力を習得できたので、スキルを獲得する上で取り組んでおくべき重要な工程だったと思っています。
その他にも、Vim から Emacs に移行する際は Emacs 縛りプレイという工程を経ましたし、Vim を習得する時も、当時使用していたウェブサービス (Google 検索, Gmail, Livedoor Reader, Remember The Milk など) やブラウザ (Vimperator)で Vim キーバインドを無理矢理使い続ける (Vim キーバインド縛りプレイ) ことで、Vim に慣れていったことを思い出します。
ソフトウェア開発での縛りプレイも紹介しましょう。
自分は関数型プログラミングに慣れるために、JavaScript で式縛りという縛りプレイをやっていたことがあります。
具体的にどんなことをやっていたかと言うと、文を使うことを禁じるために、関数の本体の 1 行目に return を書くというプレイスタイルです。
function foo() { return /* 後はこの中で何とかやってください */ }
これによって、常に式で考えることを強制され、関数型プログラミングの考え方の基礎を身に付けることができました。
また、オブジェクト指向プログラミングにおいては、ThoughtWorks アンソロジー に掲載されているオブジェクト指向エクササイズが、まさに良い縛りプレイになります。特に自分は Getter, Setter, プロパティを使わないというルールでオブジェクト指向プログラミングをプレイしてみたことで、苦手なりにも多少はまともなクラスを設計できるようになった気がしています。
リレーショナルデータベースでは、UPDATE 禁止縛りプレイをしたことで、NULL のないイミュータブルなデータモデルにも少し慣れました。(参考: 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践, system-sekkei/isolating-the-domain)
ここまでの内容は、何かを得るために無理矢理に何かを縛るという感じがしますが、よく考えてみると縛りプレイというものは、意識せずとも身の回りにあって、知らず知らずにその恩恵を受けているものだとも思います。
例えば、新しいプログラミング言語を学ぶ時は、そのプログラミング言語縛りプレイでソフトウェアを書いているとも言えますし、例えば React に Hooks API が登場した際は、以前から React を使っていた人は、しばらくは関数コンポーネント縛りにして Hooks API を習得したことでしょう。
DDD (Domain Doriven Development) や MVC なども、言ってしまえば一種のアーキテクチャ縛りプレイだとも言えます。
ゲームでは、縛りプレイを経験してしまうと、そのゲームを縛りなしでプレイした時にぬるゲー (難易度がぬるいゲームのこと) になったりしますが、これと同じ現象が、ソフトウェア開発での縛りプレイによっても生じる気がします。
ぬるゲーとは言わないまでも、視野が広がったり、選択肢の幅が広がったり、モノの良し悪しがわかるようになったり、慣れによって生産性が上がったりはするんじゃないでしょうか。
というわけで、この記事で言いたかったことは、何かの概念やスキルを習得したい場合は、積極的に縛りプレイをすることをおすすめしたいということです。
クリアした暁には強くなった新しい自分を手に入れることができます。縛りプレイをはじめてしばらくの間は苦労はしますが、その苦労をどんどん乗り越えて、たくさん強くてニューゲームしましょう。
