WARNING
この記事は麻雀の「完全先付け」「2役縛り」というルールを否定するものではなく、そのルールで打ちたい人はそのルールで打てばいいと思います。
ただし、この2つのルールに対する呪詛を十二分に含みますので、「完全先付けじゃなきゃ麻雀じゃない」「2役縛りは当たり前」と考えてる方にとってこの記事は精神衛生上よろしくないと思います。
でも「メテオフォール型開発」、テメーは滅びろ。
そもそもタイトルの3用語の意味は？(要件定義)
完全先付け
筆者は「最初の鳴きが役に関係していない」「全ての待ちに共通する確定役がない」場合にあがれなくなるという縛りを課すものと認識していますが、ルールの揺れが激しいようです。
要は「完全先付け」という用語に対する要件定義ができてないわけです。
要件定義ができていないプロジェクトは、メテオフォール型に付け入る隙を与えてしまいます。
2役縛り
3人打ちにおいて常に2役縛りとする場所もあるにはあるようですが、2役以上ないとあがれなくなってしまいます。積み棒が一定数(4本場か5本場ぐらいから)を超えると何故か
しかもこのルール、ありありにしていても確定で2役ないとあがれなくなるとかいう謎ルールがある(最終的に2役あればOKというルールもあるにはありますが少数派)上、メテオフォール的にこの縛りが課されることがあります。(というか筆者は2役縛りが発生したほとんどのゲームでメテオフォール的に課されてました)
メテオフォール型開発
詳しい説明はこのページに譲るとして、筆者が簡単に説明しますと……
"神"と呼ばれる1人または少数人数の都合にプロジェクトの全てが振り回される開発手法のことです。
……ということで、この「完全先付け」「2役縛り」と、「メテオフォール型開発」には共通点があり、その共通点を探っていこうという記事です。
ちなみに、解説に登場する人物の序列としては「A＞B」です。
その1「要件定義がない、あっても雑すぎる」
麻雀でいうと
A「このゲームなしなしな！喰いタンなし、完全先付け！」
B「あの……完全先付けは何があがれなくなるんですか……？」
A「はぁー！？完全先付けって言ったら完全先付けだろ！」
B「だからその完全先付けって言ってもルールの揺れが激しくて、あがってみたらチョンボって言われても困るんですけど」
A「完全先付けは完全先付けだろ！ほら、場所決めるぞ！牌取れ！」
開発現場でいうと
A「この機能を組み込め！あーで、こーで、それだ！」(Aにしかわからない言葉の羅列)
B「あの……あーで、こーで、それって、どういう機能を作ればいいんですか？」
A「はぁー！？あーで、こーで、それって言ったらあーで、こーで、そういう機能だろ！」
B「だから言葉の意味が分かりません、それだけ言われても要件定義できないんですけど」
A「あーで、こーで、それはあーで、こーで、それだろ！ほら、開発始めろ！俺は外回り行ってくるからな！」
解説
どちらの例においても要件定義の段階でグダってます。
当然、麻雀においても開発においても要件定義ができなければ、ゲームになりませんし開発も進みません。
要件定義はどのような機能を作って、どのような形になれば完成になるのか、ということを決める重要なパートであって、おろそかにしていいものではありません。
その2「序列だけで効率の悪い方法がまかり通ってしまう」
麻雀でいうと
B「ロン！ タンヤオ平和ドラ3、満貫で8000点です！」
A「おい！これ1萬であがったら平和だけ、3萬だったらタンヤオだけだろ！後付けでチョンボだ！」
B「えぇ……でも役があることは確定しているじゃないですか」
A「タンヤオか平和か確定してないだろ！チョンボの罰符払えオラッ！！」
(また別の局)
A「ツモ！ 18000点！」(門前ツモ、ドラ5)
B「あの……これロンだと役ないですよね……これって後付けじゃないですか……？」
A「門前ツモが確定してるからいいんだよ！6000点出せオラッ！！」
開発現場でいうと
B「よし……これでサーバーへの負荷が軽くできたぞ、これをコミットしてっと……」
(翌日Aから来たIssuesを確認する)
A「昨日のBのコードどういう処理してんのかわけわかんねーよ！ロールバックしろ！」
B「えぇ……でも今までサーバーが悲鳴を上げてたのはこの関数の処理が重かったからですよ」
A「とにかく俺がこの処理がどうなってるのかわかんねえんだ！ロールバックしろオラッ！！」
(また次の日、別の箇所の修正をAがコミットした)
A「あの部分、修正しといたぞ。B、動作確認しろ！」
B「わかりました……えっ、動作遅い……CPU使用率100%になってる」
(コードを確認)
B「ああ……ここで変なループ入れてるから時間かかるんですね、ループ使わなくてもいい方法があるのに……」
A「こっちの方がわかりやすいんだよ！リーダブルコードだぞ！お前はリーダブルコード読んでないのか？動作の速さよりコードの読みやすさだオラッ！！」(と言っているが実際そこまでリーダブルなコードになってない)
解説
序列の高さだけで序列の高い人に都合のいい結果にしたり、効率の悪い方法がまかり通ってしまう結果になってます。
ゲームにおいても開発においても、条件は対等でなければいけません。
序列的に縦社会であっても、ゲームや開発においては全ての人間が横社会にならなければならないのです。
その3「突然の変更」
麻雀でいうと
B「ツモ！ リーチ一発ツモメンホンダブ東、倍満8300オールです！次は東3局4本場です！」
A「よーし、ならこの局からは2役縛りな！」
B「えっ！？2役縛りって！そんなの説明してなかったじゃないですか！」
A「うるせえ！お前ばかり連荘してうぜえんだよ！2役縛りだ！」
開発現場でいうと
B「よし……システムテストOK……あとはリリースを待つだけだな」
A「おい！ここの仕様をこういう風に変えろ！」(現在の仕様とは大きくかけ離れた仕様を提示してきた)
B「えっ！？今までの仕様と大きく違いますよ！今から作り直してたら間に合いません！」
A「うるせえ！俺がこのプロジェクトのリーダーなんだ、作り直しを指示するのは当然だろ！ほら、修正しろ！」
解説
メテオフォールの真骨頂、「突然の変更」です。この「突然の変更」で何もかもがめちゃくちゃになる、それがまるで隕石でも落ちてきたかのようということから「メテオフォール」とも呼ばれます。
せっかくここまで積み上げてきたものを無にされたり、めちゃくちゃにされたりする……こんな悲劇はあってほしくないものです。
結論
メテオフォール型開発は、本来開発においてあってはならないことです。
麻雀においても、プロ団体やフリー雀荘においてはしっかりとルールの設定、つまり要件定義をしっかりとして、それに基づいてゲームを進めています。
要件定義、(このパートは説明できませんでしたが)設計、開発、その3つのいずれも、おろそかにしてはいけないものです。
メテオフォール型開発と完全先付けと2役縛り、これが一刻も早くなくなってくれることを願って、この記事の締めとさせていただきます。
……以上、自戒を込めて。