2018年1月に羽生章洋著『はじめよう！ システム設計 ～要件定義のその後に』が発刊され、2015年から続く『はじめよう！ 要件定義 ～ビギナーからベテランまで』『⁠はじめよう！ プロセス設計 ～要件定義のその前に』の上流工程三部作が完結しました。2回目である今回は、著者である羽生章洋氏に『はじめよう！ 要件定義』についてお話を伺います。

――『はじめよう！ 要件定義』は、当初の対象読者である「経験豊富な人が抜けてしまって疲弊していた人たち」には届いたんですか？

羽生：今もって、それはわかんないんですよ。

――でも、売れましたよね。

羽生：うん（笑⁠）⁠。びっくりしたのがね、エンプラ系ではなくて、ウェブ業界のほうに刺さったことなんですよ。主にウェブディレクターって呼ばれる人たちですね。仕事的に「企画」とか「要件定義」とかやらなきゃいけないんだけど、他の技術書と見比べたときに、この表紙が心に響いたみたいなんです。

――「エンプラ系」「ウェブ系」といっても、状況としてはよく似てると思うんですよね。会社の雰囲気が違うくらいで。要望はだいたい同じですよね。

羽生：そうなんだよね。あと、他にも刺さったところがあって。角さん相手に言うのもどうかと思うんだけど、アジャイルがいいらしいと聞いたんだけど、何をやっていいのかわかんないし、取り敢えずやってみたけど、ぜんぜんうまくいかない人たち。いくらなんでもそれはアジャイルじゃないだろ、みたいなのってあるじゃないですか。

――まあ、あるあるですね（笑）。

羽生：そのあたりのアジャイル難民（笑）な人たちにも刺さったみたいなんですよ。あのね、本当は「ITって何だろう」とか「システムを入れるって何だろう」とか、そこら辺から書き始めたかったんですよ。だけど、それだと書籍のスコープは定まんないし、読者もブレブレになっちゃうし、要件定義にたどり着く前に一冊になっちゃう。それで、一度書いた原稿をぜんぶ書き捨てたんですよ。

――要件定義って、人によって定義が違うところがあるから、前提をちゃんと共通化しておかないと後から大変になりますよね。反発もありそうだし。

いきなり本筋に入りやがった

羽生：そうそう。それで、何だかんだで4年くらいかな、いよいよもって書けないってなってたときに、久々の富野由悠季の新作「ガンダム Gのレコンギスタ」（⁠※1）が放映されて。単純にファンだから毎週楽しみに観てました。ただね、情報の圧縮と整理の仕方がすげぇなって思って。5話まで行ったときに「このやり方だったら本書けるわ」って思って。

――このやり方だったら？

羽生：Gレコの舞台である「リギルドセンチュリー」を理解するには、大量の前提知識が必要なんですよ。で、本来なら最初の数話で前提知識を説明するはずなんだけど、Gレコは1話からいきなり本筋に入りやがった（笑⁠）⁠。

――説明なしで（笑）。

羽生：ナレーションもなしにね。僕ね、コンサル会社でプレゼンの仕方とか、文章の書き方とか、ストラクチャー型でやれってトレーニングされたんだけど、「⁠新訳 機動戦士Zガンダム」っていう劇場版の1作目を見て、あのスピード感にやられて。ああ、プレゼンも文章もこれでいいんだって思って。ストーリー型っていうか。それとGレコの「いきなり本筋」とで、ストリームでガーっと行くノリに変わったんですよ。

――ストリームというのは、（前回の）スマホでTwitterのタイムラインを見ている人たちの話とも近くなってきましたね。

羽生：そうそう、話がどんどん流れて行くよねっていう。そういう時代と合ったんだと思います。

――そうですね。

羽生：たぶんエンプラ系よりも、ウェブディレクターのほうが、時流には乗ってるんですよ。だけど、ウェブディレクターはリテラシーとしてのエンジニアリングは知らないから、自分たちが企画したものが、どう実装につながっていくのかというのを提示できないわけですよね。

――前職がエンジニアじゃないと、なかなか知識が追いつかないですね。

羽生：「こんな画面をやりたいから、あとはなんとかしてよ」ってボンと投げられても、エンジニアからすれば、いやさすがにそれだけだといくら僕たちが優秀でもちょっと作れないよ、ってなる。このギャップができるわけですよ。

――そういう意味では、『はじめよう！ 要件定義』がウェブ系の人たちに刺さってよかったですね。

羽生：ほんとにね。ただ、ちっちゃいプロジェクトだと、要件定義がうまくできてなくても、エンジニアがカバーできるんですよ。でも、数十億の案件になるとね、このままだったらヤバってみんな言うんですよ。さすがに。それでいて、僕のコンサル費の数万円を値切ろうとするからね、意味わかんないよね（笑⁠）⁠。

エロゲーですよ。18禁。

――『はじめよう！ 要件定義』では、お客さんの体験（エクスペリエンス）というか、インターフェイスの部分を重視していると思うんですけど、これは羽生さんがモバイルゲームに携わっていたのが、反映されてるのかなあと。

羽生：エロゲーね。

――え、エロゲーだったんですか？

羽生：エロゲーですよ。18禁。もう、だからね、子どもに言えない仕事。いろいろ考えされられました。（⁠このあとしばらく書けない話が続く）

――まあ、内容はさておき（笑）。ゲームのインターフェイスをエンプラ系に持ってくるべき、みたいな主張がされているのかなあと、本を読んで思いました。

羽生：ズバリ、その通りで、そういう講演をさせてもらったこともあります。これからはゲームUIというのを見習うべきだよ、マニュアルなんかいちいち見ねぇよ、みたいなね。でもね、僕はゲームやったことなかったんですよ。子供の頃は家にファミコンもなかったし。実は僕ドラクエやったことないんですよ。マリオもないんですよ。

――それでよくゲームの仕事をやろうと思いましたね。

羽生：時代はソシャゲでどうのこうのって言ってたからね。やっぱやんないとダメだよなーって。40半ばでね、厄年過ぎて。

――仕事の内容は要件定義だったんですか？

羽生：火消し。

――火消し……。

羽生：「要件は全部定義されてます」って言うから行ったら、すごい雑な企画書しかなかったという。先任者が鬱になって、何人も変わってますみたいな。そんなプロジェクト。

――でも、ゲームのことは全然知らないんですよね。

羽生：知らないんですよ。ソシャゲよりも「ゲーム」がわからないから。お昼休みに本屋に行って、片っ端からゲームの本を50冊ぐらい眺めて、10冊ぐらい買って。で、ディレクターに「何のゲームをやったらいいですか？」って聞いたら、業界的にはこれがベンチマークですってことで、「⁠艦これ」を紹介されたんですよ。

人生はじめてのゲームが「艦これ」

羽生：人生はじめてのゲームが「艦これ」（⁠※2⁠）⁠。理解しないと自分の仕事が進まないから、サーバーがすいてる朝早くにカチカチ家でやって、それから現地に行くんですよ。やってるうちに、なんでここは処理が速いんだろうとか、なんで先に判定が出てるだろうとか、いろいろ考えているうちに見えてきて。「⁠これは業務システムと同じだ」ってわかって。画面上で戦闘してるって思っちゃいけなくて、これはレポーティングシステムと同じなんだ、っていう感じでね。

――ゲームと業務システムをつなげるのはおもしろいですね。

羽生：手元で伝票を組み立てて、あっちに送ったら、後ろでバッチが起こって、できあがった結果はこれですと返ってきて、みたいな。月次の締めのサイクルを瞬時に回してるだけなんだよね。

――そういえば、販売管理や在庫管理もありますね。

羽生：そうそう。アイテムとかね。そこらへん全部、手書きでね、シーケンス図みたいなのを描くわけ。

――データベースの設計も一緒に？

羽生：書く書く。「⁠艦娘」と「ドック」とはこういう関係で、「⁠入渠」ってこういう関連だわーとか。やっていくうちに「やっぱサーバーでこういう処理してるわ」とか、触ってたら「あ、絶対次にネットワークエラー起こるわ」とか、段々わかってきて。

――マニュアルを読むんじゃなくて、システム解析をしながら。

羽生：そう。艦これの気持ちがわかった、みたいな。で、本業のほうで「ほんとにこれで性能でんの？」みたいに言われても、同じやり方でさ。バトルのフローチャートを書いて、JavaScriptで試しに全部書いてみて、クライアントサイドでも性能はこれくらいは出ますよって言って。

――ノウハウが生かされてますね。

羽生：ねぇ。でもね、そもそもの企画書がすんごい雑でね。「⁠魔法により適切なダメージを与えることができる」って書いてあるんだけど、いやいやすいません、具体的に何の魔法が発動したら、どれくらい適切でダメージを与えるんですか？ と。そもそもダメージっていうのは、何のパラメータを下げるんですか？ 艦これで言うと何ですか？ みたいな。

――そうやっていると、段々とドメイン知識が高まりますね。

羽生：最初の頃は「ゲームだったら常識じゃないですか」ってマウンティングされてたんですけど、艦これ用語にしていったら、こっちのほうが詳しくなって。

――それが要件定義の話とつながってるんですね。

エロゲーでもIFDAMを使えば勝てる

羽生：だから、言葉遣いをちゃんとしましょうってことですよね。項目名を決めましょうと。「⁠回復呪文」の説明が「回復する」って書いてあって、それで具体的に何が回復するんですか？ と。体力とか、攻撃力とか、何とか力、何とか力、っていっぱいあるんですよ。でもほら、うちの艦娘たちにはそんなのはない！ とか言って（笑⁠）⁠、きちんと説明してもらって。そうなる理由ってのがね、結局ね、UIがはっきりしてないからなんですよ。あとでデザイナーが上げるから、とか言って具体的に項目が現れるものがどこにも出てこない。ステータスゲージなんか、指差しして確認できるUIのスケッチすらない。

――要件を書いているのは、ディレクターなんですか？

羽生：そうなんだけど、このときのディレクターって単なる営業なんですよ。企画営業で案件を取ってくるだけ。そのための企画書はあるんだけど、ゲームに何も思い入れがないから、競合他社のいいとこを全部取ってきて、キーワードを並べてるだけなのよ。だから辻褄が合わなくって。

――あ、ああ、あああ。

羽生：だから、魔法一個ずつ、これが発動すると相手の何がどうプラスされるとか、それが使えるのはこの属性のやつでとか、ゲームの攻略本みたいなのを僕が全部まとめたんですよ。それを元にデータモデルを正規化していったの。ほら、書類があれば正規化できるから。そしたら、ゲームバランスもあとになってから調整したいよねーとか言われたので、何言ってんだよと思いながら、何とかマスターっていうパラメータいじれるところを用意するんですよ。そこに簡易スクリプトを書いたら、その数式が使えるようになるとかね。そしたらもう、これってDSL[3]じゃないですか。DSLの仕様を書いてたら、さすがに「俺、要件定義の火消しで来てるはずなんだけど……何で？」みたいな感じになってきてね（笑⁠）⁠。

――そういう話を聞くと、『はじめよう！ 要件定義』にあるように、そこまでやっておかないと「要件定義」じゃないなーって感じにもなりますね。

羽生：そういうのをやりながら、「⁠あ、これ知ってる。在庫管理だ」「⁠これ金融の案件でやった」「⁠これはもう製造業でやった」とか、出てくるんですよ。でもやっぱ、生産管理って出てきーへんなー、MRP[4]回すってのはやっぱ特殊なんやなーとか思うようになって。

――業務システムと思えるなら、自分の領域になりますね。その経験が「IFDAM」[5]につながるんですか？

羽生：えっとね、逆。IFDAMはその前にもうあったから、エロゲーでもIFDAMを使えば勝てるんだってのがわかった感じ。

画面遷移図って、あれほど書いたあとにムダだと思うものはない

羽生：IFDAMはね、2009年から2010年にかけて、大学の社会人向け講義のテキスト用に作ったものなんです。もう亡くなっちゃったんですけど、原浩一郎という僕の盟友がいまして。彼と二人で、いったい俺たちは何でこんな酷い目に遭うんだろう？ っていう話を延々とやってるなかで、「⁠画面遷移図って、あれほど書いたあとにムダだと思うものはない」という話をしていて。

――確かに。今だともう静的な「図」にできる感じでもないですしね。

羽生：あんなの使わねぇし、見ねぇよねって。でも、あれないと不安になるの何でだろうみたいな話をしていて。それで、画面って非正規形のモデルだから、エンティティじゃん。エンティティからエンティティのトランジションというか、流れがあるなら、これDFD[6]じゃね？ って話をしたんですよ、二人で。

――DFDの延長で、データとプロセスを整理しておけばよかったんだと。

羽生：そう。「⁠画面」って言葉に引っ張られすぎてんじゃないかと。あれは単なる非正規形の構造化データにすぎなくねって。というか、非構造化でもないよねと。だって、構造を書けるじゃん。JSONで書けるじゃん。

――なるほど。

羽生：ただ、当時はそれを試す現場がなかったんで、昔の案件にこれを適用したらどうやる？ っていうのを僕と原さんでよくやったんですよ。昔に嫌な思いをしたプロジェクトを引っ張り出して、IFDAMを適用してみて、「⁠いけるじゃん」「⁠これもいけるじゃん」「⁠これもいけるじゃん」ってなって、ある程度確証を持って。そのあとで、あるプロジェクトで試させてもらったら、すげぇスムーズにいったんですよ。あらビックリ（笑⁠）⁠。その成果を大学のPBLのテキストにしたんです。

――それは、要件定義のPBL[7]なんですか？

羽生：そう。2ヵ月間のPBL。なんだかんだでね、10年ぐらいそれ（PBL）に関わってたんですけど、IFDAMを使った場合が一番スムーズだったんですよ。でね、ゲーム開発でもね、IFDAMを書けば、アプリケーションのところは割と早く押さえられたんですよ。でも、何が問題になったかというと、キャラのデータがわかんないこと。企画に書かれてる戦士はこんなことができるんですとか、勇者はとか、魔法使いはとか、個別のスペックがわかんないから、データの項目がわかんない。

「UI」「機能」「データ」の三点が揃わないことには、何をどうしても開発は困っちゃうんだよな

羽生：とはいえ、大きい動きは（IFDAMで）全部書けるんですよ。例えば、クエストに行くっていうのは、こういう流れなんですよね、とか。要は、クエストっていうのは細かい話を抜きにしたら、旅をしてることにして、そこでこれぐらい体力が減るのと引き換えにこのパラメータが増えて、みたいなのをIFDAMの機能定義のところに箇条書きで書いておくだけ。そうすると、オフショアでも「やれます」みたいになる。このときに必要なデータモデルとなると、体力やパラメータなどの情報をこうやって扱いたいんだって、決めるだけなのね。

――画面にない部分なので、決めるしかないわけですね。

羽生：そうそう。リアルタイムのゲームは違うのかもしれないけど、サーバーにリクエストして処理してもらうのって、伝票入力と同じでしょ。メッセージのフォーマットが完全に決まってて。知ってる知ってる、これメインフレームだよと。

――今だとマイクロサービスっぽくなってるから余計に。

羽生：角さん、いいこと言った。だから、クエストはクエスト、バトルはバトル、育成は育成で、それぞれステートレスのサービスがあって。サービスの結果が出たら、共有のところに記憶するだけ。でもって、ゲームだとユーザーからはみ出して書き換えるステートフルな情報って、たぶんほとんどないんですよ。

――限定の課金アイテムくらいですかね。

羽生：そうね。でも、本当に管理してるのかどうかね（笑⁠）⁠。トランザクションが効いてなくて複数のユーザーに行っちゃっても「テヘペロ」みたいな、そんなノリだったりもするので。元が雑すぎるからさ。

――（笑）。

羽生：マイクロサービスの観点で見ても、サービスの「機能」を呼び出して、その結果で「データ」を更新して、そこから「UI」を切り替えてっていう、この三点が揃わないことには、何をどうしても開発は困っちゃうんだよなと。ってか、それが要件定義だろうっていうのが『はじめよう！ 要件定義⁠』⁠。

――新規開発でもリプレースでも、両方に使えるんですよね？

羽生：うん。新規だけじゃなくて、既存システムのリプレース案件でも使えます。この三点を決めないことには、結局あれってどうなるんだっけ？ って話にやっぱなっちゃうんで、この三点セットだけは合意事項として成り立たせないといかんのだよなっていう。そういう意味では、あのエロゲーはね、辛かったけど、学びは多かったですね。

――子どもにも話せるんじゃないですか？

羽生：いやーそれはないなー。話せないことが多いし、もう二度とやりたくない（笑⁠）⁠。要件定義がちゃんとできるためには、前段階の企画がちゃんとできないとダメで。さらに前のレベルのこともきちんとできてないとダメで。そもそもシステムって何のためにやるんだとか、このゲームっていったい何なんだとか。

――要件定義以前の話だと。

羽生：結局、プレイヤーを「ユーザー」って言っちゃってるゲーム企画って、僕はダメだなと思ってて。僕は他のゲーム知らないけど、「⁠艦これ」のすごいところは「提督」という呼び名を付けたところだと思うんですよ。ユーザーじゃなくて「提督⁠」⁠。何とかしてミッションを達成するんだっていう、動機付けですよね。僕、嫁持ちの提督ですから（笑⁠）⁠。

次回予告：さらに前のレベルの話をする！