photo by Niels van Eck
基本
要件
顧客がその局で得たい点数
要件定義
顧客の得たい点数と周辺事情(手持ちの牌、場の流れなど)を考慮し、目指す役と配牌を決定させること
設計製造工程
配牌からツモを繰り返して「役」を完成させること
設計製造工程の目的と基本的なルール
ツモという不確定要素によって刻々と変わる状況を判断し、役を完成して上がりを実現させることが目的。
本物の麻雀と異なり、配牌やツモ内容やツモ回数は状況（客との力関係・開発規模・コスト・業務の複雑性etc...）によってコントロールできる/されることがある。以下のような状況であるとかなり「楽」に進めることができる。
- 配牌をコントロールできる
- ツモが見える
- 場の流れが見える
極論を言えば、配牌の時点で上がり形になっていればただ倒すだけで天和で役満である。ただし、本物の麻雀と同じくそんなことは滅多に起こりえない。
人系
以下に挙げた複数の人間が同時にツモと捨牌を繰り返す。
IT土方
指定された牌を引けるまでただひたすらツモを続ける単純作業者。麻雀のルールはおろか、自分が引く牌がどんな意味を持つのかさえ理解していないこともある。
コーダー
ある面子の完成に対して責任を持ってツモを続けられる作業者。待ちや符、ツモるコツなどの基本的事項を会得している。プログラマとの差は想定外のツモをした時に即捨てしてしまうか、なんらかの判断ができるかどうか。
特殊能力者
コーダーとほぼ同じ特徴をもつが、ペンチャンや特定の字牌など「通常得るのが難しい」特殊な形で必要となる牌の取得を得意とする人物。
この能力のおかげで点数が一段アップしたり上がりに劇的に近づいたりするので、スキル的にはコーダーと同程度であっても食いっぱぐれにくい。
プログラマ
ある面子とその周辺手牌に対し、ツモと状況判断ができる人物。
牌を引き入れ現状の形をより良い形に変えたり、手牌全体に対する提言や改善をしたりできる。
このレイヤーから上は単純作業ではなくなり、状況判断や調整力、俯瞰力といったものが必要になるし、役割間の境目も曖昧になる。
アーキテクト
現在の手牌全てに対して状況を把握し、プログラマやコーダーに適切に指示を出す人物。配牌からの状況判断と戦略立案、人物配置も含む（というかこちらが主）
ここがいい加減だとプログラマやコーダーが判断を迫られたり無駄を生み出したりして、全体の生産性が激減する。
PM
アーキテクト以下がモノにフォーカスしているのに対し、ヒト・カネの管理を行い、上がりのためのサポートと責任を負う人物。要するに上がれなかったらどうしますとか、負けたら何しますとかそういうことを調整する人。
アーキテクト以下はスーパープログラマが兼任することがよくあるが、PMは政治的能力が求められるためアーキテクトとの兼任は少ない。
要件定義者(コンサルタント)
顧客の要求点数と使える牌(周辺状況や自社資産)を整理し組み合わせて配牌と役を定義する人物。
本来的な意味でいえば顧客の要求と顧客の持つ牌を整理するのが役割であるはずで、その能力に長けたものが多い。が、実際にはそれでどんな役ができるかくらいまでは決めないとビジネス的に話が進まないので役や配牌を"適当に"決めることが多い。
スーパーマン
神ヅモを意図的に引き出して状況を劇的に改善する能力を持つ者。みんながこんな人がいたらなあ、と思っているが架空の人物である。
プログラミング系
デザインパターン
いわゆる好形のこと。不確定な状況における上がりの可能性を高めるのが主目的のため、「広い受け」を実現させるものが多い。パターンの目的をよく理解して手牌に組み入れることが大事
フレームワーク
あらかじめ配牌に組み入れることができる塔子。あと1牌で面子が完成することが確定しているので、上がり時間短縮に大きく貢献する。最近は三面張の順子が初めから完成しているものなど、かなりの時間短縮になる大規模フレームワークも多い。
当然、上がり形はフレームワークが持つ構成に依存するため向き不向きがある。
設計力
短期的・結果論的な設計力はツモ運に依存する。
長期的視点でみると数学的に最適な待ちを選択できる能力が基本にあり、そこに場の流れを加味した形を選択できることが設計力であるといえよう。もちろん基本のルールや定石手やフレームワークを理解できていることは大前提となる。
コーディングルール
牌の並べ方（萬子筒子索子の順とか、左に小さいのを置くとか）のルールのこと。
複数人が同時に手牌を見るため、並べ方の違いによる間違いや勘違いを避けるため。
その他イベント
要件変更
顧客が得たい目標点数が変更されること。普通に考えれば想定できる通り、通常は上方修正される。
当然、終盤になればなるほど修正は難しくなるし、鳴いていた場合などは修正することが物理的に不可能なこともある。
機能割り当て型開発
麻雀は一部の役を除いて、3枚の組み合わせx4＋2枚の組み合わせで役が完成するので、その5パターンに対して1人ずつ担当を割り当ててツモを行わせる。管理はとてつもなく簡単になるが、効率は最低になる。当然、複数の面子が絡み合った役は（偶然以外では）実現できないので、点数も少なめになる。
外部リソース活用
鳴きに相当。ツモの不確定さから脱却して確実に面子を完成できるが、状況が変わった時にその面子を再構成することはできないという欠点を持つ。なお、そもそも条件が揃っていないとこの手は使えない。
バージョンアップ・改修
完成した役の一部を流用して、新しい役に作り変えること。これがあるかないかでファーストバージョンでとるべき戦略も異なることになる。
訴求ポイント
ドラ・赤ドラに相当。それがあるだけでビジネス上大きなインパクトをもたらす単機能のこと。スマートフォン対応、とか、集計分析機能、とか。
ただ組み入れるだけで要件をクリアしやすくなるのでありがたいが、他の牌と絡みが全くないと困るのは麻雀と同様。
プロジェクト管理系
コスト見積もり
どのプレイヤーに何回ツモさせて上がりが形成されるのかを予測すること
ウォーターフォール型開発
顧客の要求点数やそれに基づいた配牌を決める要求定義フェーズと、ツモを繰り返して上がりのために牌を組み替える設計製造フェーズを、期間的にも人的にも契約的にもはっきり分ける開発手法。
一見効果的に見えるが、そもそも要求点数・配牌・上がり形・ツモは完全に相関しているため、役作りやツモの専門家の意見を聞かずに決められた配牌を一切動かさない、という仕組みには無理がある。
なので、建前上はフェーズが分かれていても、人や期間はオーバーラップし、また設計フェーズに入っても「配牌にあった面子を崩していいですか」とか「点数は変わらないので役を変更していいですか」とか、そういう調整をする仕組みが常設されていることがほとんどである。
スパイラル型開発
一局を複数の単位に区切って、都度都度ゴールを設定し直す開発手法。対子場なのでトイトイか暗刻を目指すが、10ツモごとに状況を確認してゴールを再設定しよう、といった状況で使われる。
本来はなんらかのリスクが予想されるときにその対処として選択すべき手段であり、リスク顕在化条件とスパイラルの区切りを明確化すべきである。例えば、場に3枚目の1索が出たら上がりの可能性が低まるので見直そう、とか。
が、だいたいそのことは理解されず、形だけ真似されて「10ツモごと」などの意味のない単位で区切ってしまい本来の目的を達成しづらくなる。
状況報告
もともとどんな役を目指していたところ、どんな障害が発生したため、何をして、結果か的にどんな影響が出るか、が言えればよい。
3色を狙っていたが、カンチャン残り1枚になったので、上がりを優先して両面に切り替えました。ツモ率はx%上がりますが、その場合の点数は予想よりx点低くなります。 といった具合。
ただし、ともかく予定通りにしろ、とか点数だけは死守しろ、と言われることも多い。
デスマーチ
残りツモ数が少ないのにまだ上がれておらず、なんとか上がりまで持っていかなければならない状態。
テンパイしてあと一つ引いてくるだけ、といった状況であれば人を投入して物量力技でなんとかするといった対策が可能だが、牌は揃ったけど役がない、というような状況だと手の打ちようがない。
よくある話題系
設計やプログラミングは決められたものを作るだけなのにどこが難しいの？
最初からイーシャンテンで、なにとなにを組み入れてなにを捨てればいいかが明確な手牌であれば楽な勝負であろう。
順子系塔子が一つ、対子系塔子が一つ、絡みがなくてもドラは必ず残せ、狙うのはハネ満以上、というような条件がついた状況であるなら、難しい勝負になるだろう。
簡単に思えるのは前提条件を誤解しているから。
要件定義でなにもかも決めておけば配牌でつみこんで天和一発じゃん
まず、要件定義は要件定義で難しいことが多い。ここでは、みんなが知ってる麻雀牌じゃなくて、その業務固有の記号で行われているゲームの解析を行わなければならないから。
8000点欲しいといわれて、わけのわからない記号が書かれた牌を渡されて、これは麻雀でいうとこの牌ですか？ってなことを麻雀を知らない顧客とうまくお話しなきゃならない。要件定義者はその翻訳能力だけで手一杯になる。
それで、麻雀は麻雀でまた難しい。符の計算やら場の流れやらの考慮はもちろん、日々向上する他家に対して競争力を維持して変化していかなければならない。
その2つを乗り越えてがっつり配牌を固めても、客側はあとになって「実はこういう牌もありまして」なんて言ってきたりする。だからまあ、そうなれば最高なんだけどそこまで分野をまたがれるスーパーマンはいないからやりたくてもできないというのが本当のところかと。
トラブったらともかく人投入すればいいんでしょ？
デスマーチのところでも書いたが、テンパってるのに役なし、という状態のところでIT土方を投入しても仕方がない。そもそもテンパってるのに役なしなんて状態になったのは戦略立案者（アーキテクト）が全く役割を遂行していないのだから、まずそこをなんとかすべき。
当たり前のことだが、少なくとも麻雀で起こりうる状況を正しく把握できるだけの前提知識がないとトラブルは解決できない。
プログラマはなぜ偉そうなのか
ある一定以上の能力をもつプログラマはひとりで状況を判断して最適な上がり形を作れるし、その根拠も説明できる。ハネ満っていったってこの手はほぼほぼこれ以上伸びないんだから7700でさっさと上がっとけよ、的な。
そこに符計算も役もろくにわからないようなやつがきて、なんで7700なんですかハネ満って言ったでしょやり直してください、てなことを言われる。そしてその大変さを説明してもわかってもらえない。明らかに麻雀初心者に向かって「ここで聴牌崩してこっちの待ちに変えると状況が悪くなるんですよ。テンパった時に西家に当たりそうでしょ？あ、配牌くらい読めますよね？ていうか言ってることわかってますニヤニヤ」なんて専門用語まくしたてられてるならそれなりに理由があるのではないかと思う*1。
このプログラマに共感するか、ビジネス要件を理解していない哀れな社会人と見るかは純粋にポジションによるんでないかな？
クソな上流設計はなぜ起きる？
実際に麻雀をしたことがないから。
ツモって必ず思い通りの牌が出るわけでもないし、場に4枚出てる牌は絶対にツモれない。そういう種類の単純なことすらわからないで、役と手牌と参考書だけを見て計画をたてるからそんなことになる。
よくある営業対開発みたいな対立項って麻雀に例えると？
設計→営業：
この配牌で跳ね満を狙うなんて絶対無理無理。なに適当なこといってんのクソ営業
設計→コンサル（要件定義者）：
「同じ牌を揃える、続き牌を揃える」くらいの知識しかない奴がなんで配牌まで決めてんの。目標点数と役だけ決めてこっちに回せよバカ
Excel方眼紙とはなにか？
麻雀のゲーム性や難しさとはあまり関係がない。以下のようなほとんど意味が見出せない理不尽な作業を強要されること。
- ツモ牌予想を紙に書いて提出しろ。予想と間違っていたらなぜ違っていたか理由をつけて提出しろ。
- 捨牌判断でいちいち手牌を見に来るな。自分の牌くらい覚えておいて、その場で捨てるか組み入れるか判断しろ
- 牌を捨てる前に所定の3人の承認を得た上で、確かにその牌を捨てたことを今日の日付の新聞とともに写真に記録しておけ。一局終わった後の場の捨牌写真で代用することは不可とする
- 赤ドラなんてルールは知らないし、記録表に書けないからツモったら必ず捨てろ
いかがでしょう。書き始めた時はいけるやんと思ったのですがやはりグダリましたw 麻雀の醍醐味である他者との駆け引き系があんまりなかったからかな。
何かの参考になれば幸いです。
かしこ
